Updated: 22 November, 2024
19 October, 2024
Introduction to software security requirements
Despite clearly understanding the importance of security requirements, organizations seem to struggle with figuring out how to implement security requirements for their SDLC (secure software development lifecycle). In this blog, we will provide an in-depth analysis and insights on how to do this right.
Requirements in general and security requirements in particular establish the common theme throughout the software development lifecycle (SDLC).
- The whole product and solution development starts with business analysts specifying what needs to be developed. Requirements are the building blocks for those specification documents.
- The architects create a software architecture that implements those requirements.
- Developers implement those requirements conform to the specified architecture.
- Then verification engineers and quality assurance (QA) teams validate that the implementation correctly addresses all the requirements.
- Finally, the customers use the product and achieve their initial goal.
In a nutshell, requirements are like a checklist of things you need to build something the right way. They help you stay focused and make sure you don’t forget anything important. Security requirements are just requirements.
It is safe to say that this practice has the highest impact on all other activities in your SDLC.
Why do we need software security requirements?
Security requirements essentially provide a plan for addressing potential threats, ensuring compliance and reducing risk. Here is a non-exhaustive list of reasons we need security requirements.
- Create a common language. Security requirements provide a shared understanding of what security controls are needed among developers, security teams, and business stakeholders. “Make sure all passwords are at least 12 characters long” is a lot clearer than just saying “make sure authentication is strong” or “make sure passwords are secure”.
- Security by design. One of the axioms of software engineering is that fixing early costs exponentially less than fixing late. Security requirements ensure that security defects are tackled at the specification stage.
- Compliance and regulatory adherence. CRA, NIS2, NIST SSDF, GDPR, DORA, HIPAA, PCI-DSS is just a couple of regulatory standards many organizations have to adhere to. These regulations provide a list of requirements you should comply with and they are non negotiable.
- Security testing facilitation. Clear security requirements serve as a benchmark for security testing activities (e.g., requirements driven testing, penetration testing, static code analysis).
Let’s have a look at what happens if we don’t have explicit security requirements in place.
What happens if we do not have any security requirements?
Developing software without well-defined requirements – both general and security-specific – can lead to a whole bunch of issues. Here are the two main issues looking at it from a helicopter view:
- Some risk!
- More risk!
- A lot of risk!
I know you were expecting more from me. So let’s zoom into risk.
- Lack of requirements may lead to losses and project failure. If the project ends up consuming a lot more resources than initially planned it might be cancelled.
- Security requirements provide early prevention of vulnerabilities. Not having security requirements in place may lead to vulnerabilities. These are a special class of bugs that could be exploited by malicious users and lead to breaches. In turn breaches may lead to fines and reputational damage at the very least.
- Higher long-term costs. Fixing a vulnerability is always more expensive in production. It also takes time. Some organizations and teams have slower deploy cycles. Finding a trivial non-critical vulnerability (which is still a risk) may take 5 minutes to fix, but 3 months to get to production.
Honestly, I doubt anyone questions the need for security requirements. Let’s have a look at best practices and tips on how to deal with the security requirements practice in SAMM.
How to implement software security requirements in your SDLC
I often get the question about how to implement the security requirements practice. Honestly, I was also puzzled the first time I read this SAMM practice. The theory looks all nice, but here are the top questions to consider:
- Who should specify the security requirements and when?
- How do we train our developers to understand the security requirements?
- When do we implement the security requirements?
- Do we let the penetration testers verify the security requirements?
Here is the key phrase to help you out: security requirements are just requirements.
The processes
You should leverage the exact same requirements engineering process you already have in place. Obviously, your security maturity will depend on your general IT maturity. If your process for requirements engineering is very ad-hoc there is no way to implement a highly mature security requirements process.
Requirements specification
Most likely you have requirements specification at the planning and analysis stages of your SDLC. Make sure security requirements are part of that process. Ensure security requirements are SMART: Specific, Measurable, Actionable, Relevant and Time-bound. Some examples of bad vs good specification:
- “Ensure that passwords are secure” vs “All user passwords must be at least 12 characters long and checked against a known list of breached passwords”.
- “Ensure sensitive data is protected” vs “All sensitive data (e.g., user personal info, payment data) must be encrypted using AES-256”.
- “Implement audit logging” vs “The system must log all access to sensitive data and generate audit logs for review”.
Requirements implementation
There is nothing fancy about implementing the security requirements. It is just part of the standard engineering process.
Requirements driven testing
More importantly though, you need to ensure you have a process in place for translating all requirements (including security requirements) into automated test cases. On the screenshot we provide an example of a unit test that checks that the session ID token is regenerated after a successful authentication (to prevent session fixation attacks).
Even if you have unit tests in place, making sure that the security requirements are explicitly mentioned on the sprint planning will trigger another round of validation by the QA teams.
Feedback loops to and from other security practices
Feedback loops are about information transfer from and to other activities in your software development lifecycle. For teams striving to higher maturity it is essential to have these feedback loops. Here is a non-exhaustive list of feedback loops that are related to security requirements. We list only the strongest links.
Organizational policies and compliance obligations
You should distill security requirements from organizational policies and compliance obligations. Vice versa, security requirements could propagate back to refine the organizational policies and standards. For instance, you could unify authentication requirements and standards across all your application portfolios. Your policies could then state that all applications at your organization must require a two-factor authentication, strong password requirements or integrate with a known single sign-on provider.
Application risk profiles
If the inherent risk of your application is very high you might consider adding more stringent security requirements. For instance, imagine you are building an internet-facing software system where anyone can create an account. Moreover, the application processes sensitive data, such as user photos. You might consider adding additional requirements that mitigate session stealing.
Threat modeling
The threats you uncover during threat modeling sessions are ideal candidates for additional security requirements. Vice versa, having a list of security requirements in place is likely to improve your threat modeling sessions. For instance, imagine mobile applications are something new at your organization and a threat modeling session has uncovered that your mobile applications are storing a hard-coded client secret for the OAuth 2.0 authorization. You consult your mobile security experts that tell you about the Proof Key for Code Exchange (PKCE) protocol that is designed to solve this problem. From that point on you add the PKCE requirement to your mobile applications security framework.
Team security awareness and education
Your teams are often under such a time pressure that they are reluctant and even resistant to attend mandatory trainings. Having explicit security requirements in place will provide awareness and education for everyone in a very natural way. For example, your engineer who picks the security requirement that mandates all user input to pass through a sanitizer (or purifier) will learn about the dangers of storing unsanitized code.
Secure architectures
Some security requirements might have a profound impact on the selection of the concrete software architecture. Your architects should clearly keep the software security requirements at the back of their head when designing the architecture. They should also validate that the requirements have been correctly addressed during the architectural assessment. Imagine a software system that needs to store doctor-patient consultations. One of the security requirements is to store all consultations using AES-256 encryption. Additionally, the encryption key should be unique and stored in a digital vault. These requirements are going to have a major impact on your architecture as you will have to at the very least select a digital vault solution and integrate it securely with the rest of your solution.
Supplier relationships
If a third party is developing any code for your organization they should not only deliver a working piece of software, but also ensure the code is secure by design. In practice, that starts with a clear definition of security requirements that should be implemented. For instance, you could require your suppliers to implement a minimal set of security requirements that all your applications start from.
Security defects
Refining and distilling defects into new security requirements is essential to ensure that the same vulnerabilities are not reintroduced in future development cycles and that security practices evolve to address emerging threats. Imagine a new defect is accidentally uncovered in production that can exploit a vulnerability in a sanitizer library. The vulnerability may or may not be fixed as you are leveraging a third party sanitizer library. However your team decides to switch to a purifier pattern that is less prone to vulnerabilities. This propagates thus back to your library of security requirements as well as all other applications using a similar solution.
Requirements-driven testing
Requirements-driven testing in SAMM literally deals with ensuring your security requirements are correctly addressed in the implementation. This involves creating both positive and negative test cases to verify all security requirements. For concrete examples we refer you to our blog on security requirements driven testing.
Security testing tools
Static application security testing (SAST) as well as dynamic application security testing (DAST) tools are prevalent in today’s SDLC landscape. However it seems that most organizations are often leveraging the tooling out of the box. To reduce the number of false positives produced by the tooling it is essential to tune your tools. For instance, one of your security requirements states that you may never use the raw filter in twig templating engine. This filter reverts html escaping and could potentially lead to Cross-Site Scripting (XSS) attacks. SAST tools are ideal for incorporating this sort of rules.
The roles and responsibilities
The list of stakeholders involved in security requirements in their order of importance is as follows:
- Architect (lead) oversees the overall structure of systems or projects, ensuring that technical solutions align with business objectives and requirements.
- Product owner defines the vision and strategy for a product, prioritizing features and requirements and guiding the development team to deliver value to customers and stakeholders.
- Security evangelist acts as an advocate/champion within the team to integrate security best practices into everyday workflows and development processes.
- Defensive security tester proactively identifies and mitigates security weaknesses by maintaining threat intelligence, vulnerability assessments and incident response capabilities.
More specifically, the architect advises product ownership on security requirements. Security evangelist helps refine security requirements in the team. The defensive security testing team supports from their knowledge domain where needed.
The tools
There are many tools you could leverage for managing security requirements. Polarion, Microsoft Word / Excel, JIRA, Trello, YouTrack, etc. Most likely your existing tooling is sufficient to address the security requirements as well. In fact, I would advocate strongly against adding any new tooling for addressing security requirements. However you must make sure your tooling allows for annotating the requirements with the security tag. It is also a good idea to add the requirements source (e.g., standard requirements library, penetration testing, threat modeling).
Practical example: TurboScale Solutions
In this section, we will provide how a hypothetical organization called TurboScale Solutions (TSS) has implemented the security requirements practice. TSS is an agile engineer-led organization that has 2-4 week sprint planning.
TSS is a strong believer in OWASP Application Security Verification Standard (ASVS). ASVS the latter is an industry-standard expert-driven security requirements framework. It is safe to say that if your application systematically considers and implements the relevant ASVS requirements, you have literally nothing to worry about.
Security requirements specification
TSS has not developed any new product since introducing the security requirements practice to the organization. This means that security requirements are analyzed and created during each sprint planning. The issues are annotated with the <Security> tag. New requirements are of type either “Feature” or “Improvement”.
Aside from leveraging ASVS TSS has several additional sources for creating security requirements. Threat modeling sessions, automated scanning tool and penetration testing findings, application error log analysis all end up on issue tracking boards for their respective projects. After a subsequent analysis and triage these issues may end up as additional security requirements across all projects. This closes the feedback loop with all other activities.
Security requirements implementation and review
The lead architect discusses all issues with the engineering team during the sprint planning. After the implementation each issue must pass a code review that requires unit or integration tests. In the minority of cases the tests are not feasible due to technological limitations. However most security requirements have unit or integration tests.
Security requirements testing
Aside from unit and integration tests that are in fact part of the implementation stage, there are additional security requirements tests that follow. First of all, the QA team has to manually test all issues before clearing them as verified. Secondly, TSS leverages a SAST tool that has a number of tests for a certain class of security requirements that are very hard to automated with unit/integration tests. The SAST tool ensures that for instance, all data is escaped before presenting it to the users, there are no insecure redirects to external domains, etc. These are the so-called “ensure a certain pattern is not in the code” type of requirements.
Release Readiness Review
Finally, TSS also leverages a Release Readiness Review (RRR) checklist that is used by the QA team for acceptance testing. Note that many of the acceptance tests are automated with cypress and maintained by the QA team. A few RRR items are security-related as most of the security testing is expected to happen in the automated unit and verification tests.
SAMM maturity score for security requirements: 3.0
TSS clearly scores a maturity level 3 for SAMM security requirements practice.
- They leverage ASVS as a requirements framework that is probably the best across the industry.
- TSS has tight high-quality feedback loops across other stages of their SLDC that refines the security requirements.
- There is a clearly agreed structural notation for the security requirements (albeit not being too formal).
- Security and domain experts review the security requirements before propagating them to the sprint planning.
- All security requirements have mandatory test cases and they are highly automated, which guarantees their SMART-ness.
Conclusion
In this blog, we have presented an in-depth analysis of how to Implement Security Requirements for Secure SDLC. Security requirements are not just a checklist to tick off. They are the foundation of a secure development lifecycle. They ensure that security is built into your application from the very beginning, reducing vulnerabilities and risks long before they become costly problems. By defining clear, actionable, and measurable security requirements, you create a common language that guides developers, architects, and security teams to work together towards a shared goal of safeguarding your software. Implementing security requirements early, and refining them through continuous feedback, ensures your application remains resilient in an ever-evolving threat landscape. In short, strong security requirements lead to strong, secure software.
Links with other SAMM practices
This section provides a list of other SAMM practices that tie to security requirements. We provide the specifics of these dependencies in the feedback loops subsection. Note that we only list the strongest links. Note that we list only the strongest links.
- Policy and compliance provide additional input to security requirements. Security requirements also may make their way into refined policies and standards.
- Security requirements provide additional awareness in the Education and guidance practice.
- Threat assessment may result in new or refined security requirements. Existing requirements also help scoping the threat assessment.
- Security requirements should be part of your Supplier security relationships.
- Secure architecture should implement the security requirements.
- Defect management helps with refining security requirements over time.
- Requirements-driven testing ensures security requirements are correctly implemented.
- Security testing becomes more efficient driven by security requirements.
Resources and further reading
- Requirements Engineering: From System Goals to UML Models to Software Specifications. Axel van Lamsweerde. (https://www.amazon.com/Requirements-Engineering-System-Software-Specifications/dp/0470012706).
- Security Requirements Driven Development: the Best ROI for your SDLC.
- OWASP SAMM Fundamentals Course.
