Security Requirements Engineering – The Backbone Of Your SSDLC

On paper, I do agree. But once you take a closer look, it becomes obvious, how far reaching their effect is. Most of the activities in the later stages of development will refer back to the security requirements. How resilient must my security architecture be? What do I have to consider when building and deploying my application? Which security tests do I have to run? What are the parameters for secure operations? Should I patch fast or rather test new patches more carefully before applying them?

If you did a good job defining your security requirements in advance, you will be able to answer those and many more questions easily and consistently when they arise. It pains me to see organization struggling to make the right decision because they neglect the importance of security requirements as their main point of reference.

But we shouldn’t get ahead of ourselves. This idealized scenario I am painting here shows the potential of a fully integrated security requirements engineering process at a high maturity level. If you are just starting out, you need to build a solid foundation first before you can utilize the full range of capabilities of your security requirements engineering activities.

Quick wins to kickstart the security requirements engineering process

For those of you who are at the beginning of this journey, I assembled four tips and tricks that have helped other organizations getting started with security requirements engineering successfully.

1) Respect the fundamental principles of good requirements engineering

Requirements engineering is an established craft. Nevertheless, many organizations seem to forget about the fundamentals once security gets involved. I am an advocate for integrating all your security activities into your established development processes, and this holds true for security requirements engineering. Security requirements must follow the same strict guidelines all other requirements have to adhere to.

Requirement define What to do, not How to do it. They must be specific, measurable, and reasonable. I could go on and on, but you’ll find those fundamentals in any good book about requirements engineering. Don’t throw them overboard when writing down your security requirements. Badly written security requirements are often ignored or misinterpreted later on. Avoid this trap and stick to your best practices.

2) Use the OWASP ASVS as inspiration for your first security requirements

“Wait, what? The Application Security Verification Standard? But that is a guideline for security tests, not requirements engineering!”

Good catch, you are totally right. But it is nevertheless one of the best tools you can use to get into security requirements engineering fast. It is a very comprehensive and also well-structured standard, which makes it easy to navigate.

This works because we are using a dirty little trick, bending the process to our needs. In a perfect world, security requirements are supposed to be the source of security test cases. But remember, we are just starting out and are looking for reasonable shortcuts. The ASVS is a collection of well researched and established security test cases already. Why not go the other way round and try to derive useful security requirements from them?

Let’s look at an example. The current stable release of ASVS is version 4.0.1. Security verification requirement with ID 3.1.1 states:

Verify the application never reveals session tokens in URL parameters or error messages.

The initial question should be whether that is even applicable. Are you developing a type of application that uses URLs? Und are you using session tokens? Assuming we are talking about a web application with different users, chances are high that this is the case. So, let’s formulate our underlying requirement:

The application must not reveal session tokens where they are at risk of leaking to a third party (e.g. in URL parameters or error messages).

I took the liberty to formulate the requirement in a more generic way to catch a broader range of cases, but you can always go the easy route of simply changing “Verify …” to “Ensure …”. Just keep in mind that test cases tend to be a little more specific and aiming for a broader requirements definition is usually a good idea. The right way to do this would be the other way round; starting with the actual requirement and deriving a set of test cases to verify its implementation.

Please keep in mind that this is a shortcut to kickstart security requirements engineering and there will be many important aspects you are missing that have to be added later on to reach a high maturity level. You will probably miss application-specific security requirements, requirements based on policies and compliance, and you won’t have included any domain specific knowledge. But at least you dipped your toe in the water and got the ball rolling.

3) Implement proper verification of all security requirements

As I have mentioned before, security requirements have to be addressed in all stages of development. But in the early stages of integration, this might seem overwhelming; especially if you meet resistance in your organization. Instead of forcing the integration right from the start in all other security activities, I recommend easing into it with proper verification. Once people see how they can contribute to passing such a quality gate, they are usually more open to change.

I’ve witnessed this phenomenon far too often. Requirements are treated as strict rules that have to be follow. But call them “security requirements” and everyone starts to consider them as optional. As soon as this takes root, all the effort invested into designing proper security requirements is more or less wasted. Do not allow this to happen!

Make sure to enforce at least one quality gate that includes verifying the implementation of your security requirements. One important property of a security requirement is its testability. Use this to your advantage! The correct way of implementing proper verification early on depends on the culture of the organization. I have seen organizations having great success implementing this as a final acceptance test, for others it worked way better as regular team meetings reviewing the level of implementation together. Whatever works for you; the goal is to hold the responsible people accountable for implementing your security requirements with the same rigor as any other requirement.

Later on, when you have reached a higher maturity level, this will become more formalized, but to set the mindset straight right from the start, this can be a healthy method to drive home the importance of security. I have seen companies making solid improvements throughout the whole SSDLC just by implementing mandatory security review sessions. This kind of organic growth is exactly what you are looking for, especially when you are just starting out.

4) Ensure vendors follow the same security guidelines that you are committed to

Vendor management is such an important topic when it comes to security, that I will dedicate a full article to this topic in this series later. Nevertheless, it has to be mentioned in the context of security requirements engineering as well, even if just briefly.

Your security requirements define a security baseline for the application you are developing. But what happens if parts of your application are developed by a vendor? This might be a third-party framework, a micro service, or any other software component your application relies on. Shouldn’t they follow the same guidelines?

Well, of course they should! An attacker doesn’t care whether the broken part of your application has been developed inhouse or not. A vulnerability is a vulnerability, no matter who is responsible for this quality issue.

That’s why you have to ensure that your vendors follow the same security guidelines as you. Failure to do so will probably leave you with insecure third-party software that puts your whole application at risk and violates your compliance obligations.

I will dive into the best practices of vendor management from a security perspective in a future article, so stay tuned.

Common mistake: Relying solely on vulnerability classes to avoid

There are many mistakes to look out for when starting out with security requirements engineering but relying solely on vulnerability classes to avoid for your security requirements is the most common one. It is the Dunning-Kruger effect in action.

One of the first things people stumble upon when researching security are the OWASP Top 10. And that’s good, because the OWASP Top 10 are a great tool if used correctly. They represent a broad consensus about the most critical security risks to web applications. Understanding them and considering them during development is highly recommended.

But this does not mean that slapping a link to the OWASP Top 10 (or a similar list of vulnerability classes) into your requirements document can replace proper requirements engineering. That’s why I was a little hesitant to include the ASVS as inspiration for security requirements in the Quick Wins section above. Using generic sources for requirements can be helpful but many organizations get stuck in the illusory superiority zone of the Dunning-Kruger effect and never make it past this initial stage, leaving a lot of potential unused.

Summary and next steps

We covered a lot of ground in this article. We have learned about the importance of proper security requirement engineering and saw some tips and tricks to get started with this security activity in your secure software development lifecycle. We also discussed a common mistake that organizations make, leaving them stuck at a low level of maturity without realizing the lost potential.

After establishing the fundamentals of requirements engineering and communicating their importance and value, the next step is building upon those successes and aiming for a higher maturity level. This will be the main topic of the next article in this series. In addition, we will use our quality level matrix to help you decide whether your security requirements engineering process is fit enough for the protection profile of your applications or you have to up your game.

Was this article helpful to you? Are there any specific questions you would like to see answered in the next one? Let me know on Twitter and I will try to fit your preferred topic into the next release!

Click here to get to the complete SSDLC Deep Dive blog series.