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.