After discussing the fundamentals of security requirements engineering, it is time to take the next steps. If you are serious about secure software development, you must be eager to establish security requirements engineering as the backbone of you SSDLC. Once you have reached mastery in this discipline, many of the benefits will arise organically from the underlying process and continuous improvement is already built in. Are you ready to build upon the fundamentals?
A guest article by Thomas Kerbl, Principal Security Consultant at SEC Consult in Vienna. Follow him on Twitter @dementophobia for updates on this topic. This article is part of the Secure Software Development Deep Dive series.
Once you have dipped your toe into the water of security requirements engineering, you are probably eager to take the next steps to get the full potential out of this important activity. Steering your development activities through security requirements is an elegant approach to introduce consistency and reliability in your software development lifecycle in regard to your security posture.
In this article I will show you how to build upon the foundation you have already established and how to reap the benefits of a mature security requirements engineering process. I will also share my quality level matrix with you, that helps you to get a first impression where you are currently standing.
This article is a continuation of the previous article in this series, which I recommend reading first. But if you are already well versed in the fundamentals of security requirements engineering, feel free to dive right into this one without a second thought!
Security Requirements Engineering Done Right
Your initial security requirements engineering process is in place? Your first projects utilized well-crafted security requirements? You even performed your first requirements-driven security tests? And the current OWASP SAMM assessment showed that your security requirements maturity surged above level 1 for the first time?
Well, looks like you are ready for the next steps! The following proved and tested tips and tricks will guide you along the way.
Consider your security requirements in all stages of development
When I talk about security requirements engineering as the backbone of the SSDLC, I really mean it that way. I regularly discuss the nuances of different security activities with my clients, and one of the phrases they hear me repeat most often is: “Well, it depends. Let’s look at our security requirements for guidance.”
This approach is so powerful because most security requirements must be addressed in several security activities. Let’s take a simple example:
“The internet facing API must have a DDoS Resiliency Score of at least 5″.
What does this mean regarding our security activities?
When defining your security architecture, you consider different Anti-DDoS patterns and technologies. During Threat-Modelling you analyze whether these measures can be circumvented by an attacker or if there are other attack vectors that break your DDoS resiliency. In case you need to integrate an external DDoS prevention service, you will include the relevant security requirements in your vendor contracts and SLAs. During the verification phase you need DDoS benchmark tests to verify whether you achieve the specified resiliency score. To ensure secure operation you need monitoring with appropriate alerting thresholds to detect stress levels that might exceed the capacity of your infrastructure.
Those are just some examples, but you get the picture. You don’t know what to do during most of the security activities without relating back to the security requirements.