This post is all about the “big ideas” behind secure systems, like least privilege and separation of duties. These principles are surprisingly simple but form the backbone of how we design systems to stay safe from attacks.
In application security there are common design principles that are used to improve the security of software. These principles are often referred to as fundamental security principles and provide general best practices that apply to all applications. In this post we will dive into these principals and discuss why they are important. Knowing these principals will allow you to spot sharp edges in applications and help you identify impactful security issues.
Background
Before we discuss the fundamental security principles we first need to understand how applications are developed. This is important because these principles tie into common application development processes and procedures.
The application development process is most commonly defined by the Software Development Life Cycle (SDLC). The SDLC outlines six high-level phases that are used to iteratively build and operate software applications.
- Planning - The software development journey starts at planning, this defines the requirements and constraints of the software. For example, what problem are you trying to solve? How much is it going to cost? etc.
- Design - The next step is to take the requirements and identify the best solutions to create the software. This includes assessing technologies and architectures for the application.
- Development - The developers implement the design by iteratively delivering chunks of the design.
- Testing - The application is tested using a combination of automated and manual efforts to ensure the software meets the requirements defined in step 1. This is often where active security activities like penetration testing happen.
- Release - The application is deployed to a customer facing environment and is usable by customers.
- Maintenance - The software is maintained through the support of software developers. This includes resolving customer issues, monitoring performance, bug fixes, and software updates. Once this point is reached, the SDLC process starts again at phase 1 for new features and updates.
Historically security was not a primary consideration in the SDLC process, however, over time this has changed. Decades of software development has shown us that retroactively adding security does not work. This is because attempting to secure something that is inherently insecure is usually 1) not effective, and 2) expensive. It is much easier and cheaper to build security into the SDLC process.
Secure Design Principles
Shift Left
The concept of “shift left” refers to implementing mechanisms to detect and prevent security issues earlier in the SDLC process. For example, instead of a customer identifying an issue in the release phase, a mechanism prevents the issue from happening in the first place during the development phase.
The goal of shift left is to reduce the number of security issues in software applications after release. Shifting left has a disproportionate impact because fixing security issues after an application is released is almost always harder and more expensive. The earlier a security issue can be identified and fixed, the better.
In practice, the concept of shift left usually takes the form of using automation to check for security issues during the development phase. However, shift left can also be applied by considering security earlier in the SDLC process, such as during the planning and design stages. The holy grail of shift left is a mechanism that prevents an issue from happening in the first place.
Secure by Default
The concept of “secure by default” refers to the default configuration of an application resource being secure. For example, let’s say you store your photos in the cloud. A secure by default configuration would only allow you to access your photos. Whereas an insecure by default configuration would allow everyone to access your photos.
The goal of secure by default is to protect application users and promote a safe user experience. By having a configuration that is secure by default, it reduces the chances of user’s configuring application resources insecurely. This minimises the overhead of the maintenance phase of the SDLC process because it reduces user configuration security issues.
You might be thinking “you should make it secure all the time, not just by default”, that is fair but unfortunately it is not that simple. For example, in the previous scenario having the ability to share a photo with people is a valid use case. It is not inherently insecure, however, it introduces a risk that a user could accidentally share their photos and introduce a security issue. Putting safeguards around risky functionality is important and ensuring the default configuration of a resource is secure are both critical.
Defence in Depth
The concept of “Defence in Depth” refers to building multiple overlapping security controls into an application. The idea is that when one control fails there will be another control to prevent the issue from happening. This principle is particularly important because it makes exploiting security issues significantly harder. It is much easier to bypass a single control, than multiple overlapping security controls.
To demonstrate defence in depth, let’s say we are securing a bank vault. A basic security strategy would be to have a strong lock on the vault door. However, a defence in depth strategy would be to also have guards and motion detection in the vault. This means even if a threat actor was able to get through the vault door, they would have to also get past the guards, and the motion detection. These overlapping controls collectively reduce the likelihood of someone breaking into the vault, and the same principle applies to software.
Separation of Privilege
The concept of “Separation of Privilege” refers to splitting access rights and tasks across multiple individuals and systems. The idea is that this separation prevents single points of failure and reduces the impact when something goes wrong. For example, instead of a single system being able to do everything, split that system into smaller subsystems that each perform a separate function. This means when a security issue in a subsystem happens it will have a smaller impact because the subsystem has less access.
Separation of privilege is often applied architecturally (like we saw in the system example), however it can also be applied organisationally. The organisational aspect refers to limiting the access of individuals. That is, instead of one person being responsible for X+Y, make one person responsible for X and one person responsible for Y. This is particularly important because people are humans, and humans make mistakes. A good real world example of why separation of privilege is important can be seen in Lastpass’ Notice of 2022 security incident.
Least Privilege
The concept of “Least Privilege” refers to limiting the access of a person or system to the minimum required to perform their desired function. For example, instead of allowing an accountant to read all business and customer data, limit the accountant to only being able to read the data of customers they are actively serving. This minimises the impact of someone gaining control over the accountant’s user, or the accountant going rogue.
Least privilege has disproportionate security benefits because it limits the impact of security issues. To demonstrate this, let’s say a threat actor was able to gain control over a component in a system. The security impact of that happening scales with the level of access associated to that component. For example, the component having administrator access to everything has a greater impact than the component being able to read some data.
Applying the principle of least privilege is critical to system design. It promotes good behaviours and acts as a tool to highlight architectural issues. For example, if a system has one component that needs administrator access to everything, that highlights a problem. This can act as a signal to apply other principals like separation of duties to split a system into sub components. The least privilege and separation of duties principles are often applied together because they compliment each other well.
Open Design
The concept of “Open Design” refers to intentionally making application code and or processes transparent. The goal of this is to improve the security of the application through community scrutiny. The idea is that a wider audience will be able to identify and fix more issues than a smaller audience. An open design promotes a collaborative approach that enables strong security and earns trust with users.
Open Design has become increasingly popular with the rise of Open Source (software that publicly shares their source code) such as OpenSSL. However, most commercial software today is still closed source (not shared publicly). Not having an open design isn’t necessarily a problem. However, it becomes a problem when the security of an application depends on the operation and processes being unknown. This is often referred to as “security through obscurity” and it is not considered secure because a threat actor with enough time and resources can figure out how the system works. It is always better to design a secure system than trying to hide a system.
Discussion
The concepts discussed in the previous section are ubiquitous across the security and software development industry. The reason for that is that these concepts have practically proven over time that they tangibly improve the security of software applications. Knowing these concepts is important because it allows us to develop secure software, and provides valuable tools for us as security professionals. In the real world it is easy to tell which applications were built with security in mind, and which were not.
Understanding these fundamental security principles is particularly valuable for security testing, such as penetration testing. The reason for that is because knowing how software is built is the best way to identify security issues. Being able to reason on systems and shape your methodology to fit your situation separates average security people from great security people. For example, knowing these principles will make you ask questions like the following when you review a system:
- How is the software developed? (Shift left and open design)
- What is the architecture of the system? How many components are there? (separation of duties)
- How are those components scoped down? (least privilege)
- What security controls are there? Are there single points of failure? (defence in depth)
- How are resources configured? (secure by default)
Answering those questions and working backwards from the design principles will act as a mechanism to identify impactful security issues. For example, a system having an over privileged component highlights an important area that you should look into. This is because identifying an issue in that component would have a disproportionate security impact. You would not have thought of that unless you knew about the principle of least privilege! Use these principles to your advantage and ask yourself which principles would be hard to apply in your situation. More often than not, this will uncover sharp edges that you can use to shape your methodology.
Conclusion
The fundamental security principles discussed in this post are powerful tools for both software development and software security. Understanding them allows us to practically improve the security of software through tried and tested methods. From a security perspective, these principles are important because they can guide us and shape our methodology to securing software. From a software development perspective, these principles are valuable because it allows us to save time, money, and energy. These security principles allow security and software developers to speak a common language.
Despite the fundamental principles being presented individually, they are often combined. These concepts work best together because they compound off of one another. For example, least privilege and separation of duties, or defence in depth and shift left. By applying these concepts together you are able to selectively use the right tool for the job and take a holistic approach to security. This empowers you to make intelligent and calculated decisions while balancing the possible and the impossible. Remember, the most secure application in the world is one that does nothing. Fundamental security principles enable innovation by balancing user and security needs.