Guest post originally published on the Snapt blog by Iwan Price-Evans
Hackers, malware, cybercriminals, and more threaten modern applications constantly. Malicious actors will try to uncover and exploit any vulnerabilities to steal private data, disrupt your service, and more. When designing our applications, we must prevent or mitigate these potential vulnerabilities as early as possible.
Identifying and fixing security gaps late in the development process can be very expensive. Many of the biggest vulnerabilities arise from poor design and require significant effort to resolve. You can avoid wasting time and resources by following the correct principles in the application design phase.
Follow these principles to ensure your application is ready to meet rigorous security demands.
- Confidentiality: Only authorized people (or processes) can get access.
- Integrity: The presented data is unaltered.
- Availability: The system and its data are available even under adverse circumstances.
- Authenticity: Users are whom they claim to be.
These security criteria should become embedded into your company’s operation and not just security guidelines for when you write code.
Include these criteria in your software design and functional requirements. Suppose requirements do not cater to a practical way of ensuring confidentiality across every part of a software system. In that case, even developers coding in a very secure manner is unlikely to resolve the issues.
It’s crucial to align your processes, architecture, developers, and other stakeholders with these principles to ensure that your business prioritizes secure design throughout the development journey.
Develop Use/Misuse Cases
Work with the architecture group to model use and misuse cases. While use cases depict the application’s functionality, the inverse of the use cases (misuse cases) helps you understand and address the software design’s security aspects.
Misuse cases are ways people can misuse the software to expose or exploit vulnerabilities. Convert these misuse cases into standard case templates for later security testing and security scans. Ensure that the software requirements consider all these cases.
Review Software Security Design and Architecture
Your security architect should review the software’s functional design and architecture. Try using the checklist approach because it is easy to follow and track.
The security architects must work closely with the software architecture team to generate a software security plan that details its design. The stakeholders can use this plan as a check-and-balance guide during and after development.
Model Threats and Risks
Threat modeling helps determine the software’s attack surface by examining its functionality for trust boundaries, entry points, data flows, and exit points. If you are not familiar with the technique, use a threat modeling tool to guide you through the process.
Risk modeling ranks the threats affecting the organization’s business objectives, compliance and regulatory requirements, and security exposures.
These can be rather lengthy processes for companies to perform. They can also frustrate the development team because restrictions designed to minimize threats and risks can reduce their freedom. However, considering how security vulnerabilities cost businesses dearly in fines, revenue loss, reputational damage, and customer experience, threat and risk modeling is necessary despite the potential disruption.
Open Design Principle
The Open Design Principle is the concept that the security of a system and its algorithms should not be dependent on the secrecy of its design or implementation. This principle is essential for the open-source movement that the software world is currently embracing.
While companies might want to protect their intellectual property and prevent others from accessing their code, the reason for this should never be security. If access to your code exposes a security vulnerability, then you should probably redesign the code instead of keeping it secret.
You can use scanning software to identify security vulnerabilities in your code. It would be best to look at how other systems interact with your code and prioritize security review in your development process.
Least Privilege Design Principle
The Least Privilege design principle provides the least amount of access privileges that any individual needs. Companies tend to give people and systems more access than they need when pursuing efficiency and velocity.
However, granting too much access allows improper use. For example, people can access or update data or execute commands outside the approved context.
The least-privilege principle attempts to limit data changes and prevent potential damage from occurring by accident or error by reducing the number of possible interactions with a resource.
Assigning access rights based on the least-privilege principle will limit users from attacking or damaging your systems – whether this is intentional or not.
The least-privilege principle is effective not only for human users but also for system-generated accounts. Software typically uses system-generated accounts to interact with other components or infrastructure. These accounts should have sufficient access privileges to complete their required tasks but no more. By following this principle, system-generated accounts cannot cause much damage if they are compromised or take unintended action.
Fail-Safe Defaults Design Principle
This principle goes hand-in-hand with the principle of least privilege. The Fail-Safe Defaults design principle assumes that access is forbidden unless explicitly permitted instead of being permitted unless explicitly forbidden.
By following this principle, user accounts can only access a resource if they need to. By default, users do not have access to any resources until an administrator grants them access.
This principle prevents users from gaining unauthorized access to any resources.
Separation Privilege Design Principle
The Separation Privilege design principle requires that users and systems fulfill multiple conditions before being granted resource approval to access a resource. For example, the system should validate a user’s active status and access to a specific resource. This approach is more secure than requiring that they meet only a single condition.
This method adds extra administrative overhead as it makes access more difficult. Still, this added measure can provide additional protection to ensure any users or resources do not behave in unexpected ways.
Least Common Mechanism Design Principle
The Least Common Mechanism design principle declares that mechanisms used to access resources should not be shared. This principle also adds overhead because development teams must create additional mechanisms to handle the permissions management and resources access.
Still, separating these areas reduces the risk should any system become compromised or perform incorrectly in any way.
The Economy of Mechanism Design Principle
You might already have noticed that most of the principles identified so far start with simple ideas expressed as simple rules. Still, it shows how vital simplicity is to building a safe and secure software system.
The Economy of Mechanism design principle requires architects to design systems as simple and small as possible. Simple code is easy to test, and this applies to security as well, as the different security scanning and security tests will be easier to write if the code is small and uncomplex.
Avoidable complexity increases the likelihood of missed testing scenarios and specific code faults going unnoticed.
Defense in Depth Design Principle
The Defense in Depth design principle says that layering the verification of resource access authorization reduces the chance of a successful attack. This layered approach to resource authorization means unauthorized users must circumvent each verification layer to gain unauthorized access to a resource.
Conclusion
When designing a system to meet a particular security specification, architects must consider the scope of the security needs and the minimum required security threshold.
Not every system will need to use all the security design principles described here. Architects will typically design systems that use one or more of these principles in combination, based on the required threshold for system security.
The security attributes of one software application contribute positively or negatively to a system’s overall security and performance.
System security architects need to consider how each application affects overall system security with particular attention to the minimum security threshold. If anything compromises this threshold, system architects and development teams must prioritize it.
If you need help identifying security vulnerabilities in your deployment, check out our SecOps managed service. If you need to secure application traffic in any environment or any architecture, Snapt Nova includes a high-performance intelligent web application firewall (WAF) optimized for cloud-native and distributed apps.