Security Requirements Engineering - Reaching Mastery

Use identified security issues as source for improvements

You might not be happy about identified security issues in your systems and applications, but they are actually a good thing. You can learn so much from them during a proper root cause analysis. And, you might have guessed it, your security requirements are a key component of such an endeavor.

Let’s stick with our example from above. You perform a DDoS Benchmark test and realize; you clearly missed your goal. Resiliency Level 3.3 (instead of 5), that’s what the report says. But why, what went wrong? Here’s where a traceability matrix comes in handy. It shows you from start to finish, how a specific requirement has been addressed at every stage. I recommend to start with the actual security requirement and work yourself through the life cycle from there.

The requirement has been specified – check.

Design decisions were made and documented as part of the security architecture – check.

Threat-modeling showed some issues with the concept, but those were corrected in the architecture, and the threat-model showed no relevant risks during the second iteration – check.

Anti-DDoS measures were outsourced to the internet service provider and the security requirements considered – wait a second, yes, there is a contract. It also includes a set of metrics, but they do not relate to our specific requirement. Bingo, we found the issue!

Fixing the issue itself is one thing. You re-negotiate with the provider and ensure that you get the proper level of protection by performing another DDoS resilience test. But how do we make sure a similar issue doesn’t pop up again during our next project?

We need to dig deeper and find out, why this happened. Is it a problem with the procurement process itself? Was the requirement unclear to the responsible people in the procurement department? If so, why didn’t they seek help from the security experts? Or was it a simple oversight? Based on the answers to those and similar question you might want to ask, you will unveil the root of the problem and be able to address it. In our example, measures can include adapting the procurement process, strengthening the interaction between the procurement and the security department, or performing training of specific roles to avoid such mistakes in the future.

Root cause analysis can be a time-consuming task and sometimes is misunderstood as looking for someone to blame. What you are actually doing is investing now to avoid much higher costs later. Sure, doing an in-depth analysis might cost you several hours of your important key resources, but making the same mistake over and over again will be way more expensive over time.

Integrate domain-specific knowledge

When organizations start defining security requirements during development, they initially tend to rely on generic and usually very technology focused requirements aiming to increase resilience against different types of attacks. But this is just one part of the bigger picture.

Try to think about other sources of inspiration for security requirements. Policy and legislation? Prior incidents? Security standards for your industry? Security dependencies of your target environment for operation? Community, customer, and partner feedback?

Well, all of them are great answers, and all of them should be considered using a systematic approach. If you have established security champions, pull them in and use their knowledge. Discuss your initial set of security requirements with domain experts and get their feedback. Ask your legal advisors to ensure conformity with any relevant laws and regulations.

Long story short, broaden your perspective. Keep your well-established technical requirements and enrich them with domain specific knowledge.

Utilize a security requirements engineering framework

When we talk about using a framework for our security requirements, we are entering the highest maturity level defined in OWASP SAMM. But remember, we are not doing this for fame or to score points but to build secure and resilient applications. And in this specific case, as a bonus, to increase our efficiency significantly.

One of the reasons security requirements engineering isn’t done properly in many organizations, is the perceived overhead of this activity. I will spare you the typical rant about the importance of shifting-left and how much you can save in the long run by considering security early in your SDLC. You have heard it a thousand times and maybe this very idea brought you here in the first place. So, let’s skip to the good stuff.

Security requirements engineering done right can be very efficient and effective. And a framework tailored to your organizational culture makes all the difference. The goal of such a framework is ensuring that your security requirements are appropriate and complete. The key is providing reusable requirements as well as providing a set of sources that help you fine-tuning and enriching those generic requirements. It creates a structure to ensure a high level of quality.

I highly recommend formalize the actual definition of your security requirements as part of your framework. Especially when you are working in an agile environment it can be helpful to define what an “evil user story” looks like and how to consider your security requirements in your DoD (definition of done) and DoR (definition of ready). I will dive deeper into this topic in the Q&A section at the end of this article.

Common Mistake: Hiding Your Security Requirements From Penetration Testers

If you have attended my talk at the recent OWASP SAMM User Day or heard me speak at our Webinar, you have witnessed my anger about this issue first hand. I don’t want to dwell on it too much here and will get straight to the point.

There is no good reason to hide your security requirements from your security test team! It’s like going to the doctor for a general checkup and forget to mention that you are planning to run a marathon next week. Sure, the doctor will provide a good check-up and might even find critical issues you should address. But many of the most important checks relevant to someone planning to run a marathon will not be done within the limited amount of time the doctor can spend with you.

It’s the same with a security test. You have a limited amount of time and budget. The test team tries to find the most crucial issues within those boundaries so that you can fix them. But if you don’t tell them, what is most important to you – the fulfillment of your security requirements – how should they target the right areas? Sure, they will cover all the standard tests, but were they able to get the most out of the test for you? Probably not.

So, please, don’t fall into this trap. Do not only provide your security requirements to your test team, but make sure they are actually deriving proper test cases from those requirements and focus on the areas that really matter.

After reading so much about security requirements engineering, you are probably asking yourself, where do you stand. The best way to assess your current level of maturity is conducting an OWASP SAMM assessment, but to get an initial gut feeling, I created a version of our quality level matrix for security requirements engineering:

In case you are not familiar with the role of the security champion yet, you can imagine it to be a well-versed security coach integrated in the development team. I might cover this important role and how to establish it in a later article.

Q&A

I was asked on Twitter, how to address business logic vulnerabilities in agile environments. That’s a great question that allows me to discuss requirements engineering in agile projects a little more. Please keep in mind that not all agile processes are designed identical and there is no one-size-fits-all solution for every organization. Take my approach as inspiration but make sure to adapt it to your specific needs and circumstances!

When we are talking about requirements engineering in an agile software development process, we are basically talking about epics and their user stories. That’s also the place where our business logic is designed, and security issues need to be addressed.

Let’s take a simple user story for a CRM application as an example: “As an account manager, I want to see the list of my accounts incl. their primary email address, so that I can get in contact with them.”

Let’s further choose a specific business logic vulnerability to avoid: “An account manager is able to list not only his own but all accounts in the CRM, violating data protection requirements.”

There are different ways to approach this from a security requirements engineering perspective. Let’s look at some possibilities.

Add security user stories to the same epic

Our user story is part of a larger epic. Analyzing and defining security requirements as user stories of the same epic is possible, although I am not a big fan of this approach. In our case such a security user story might read like this: “As the data protection officer, I want to ensure that account managers can only access data of their own accounts, so that compliance violations are avoided.”

The problem with this approach is the decoupling from functional user story and security user story. When prioritizing and assigning user stories to sprints, chances are that the functional user story gets implemented way earlier than the security user story, leaving the new feature exposed for several versions. Therefore, I prefer another approach – adding security requirements as subtasks to user stories.

Add security subtask to user story

During requirements engineering in an agile development process, subtasks are defined for user stories to specify the underlying technical requirements. This works for security requirements as well.

In our case the team would identify the need for a server-side filter mechanism that ensures, that only those accounts are shown, which are assigned to the account manager fetching the list. This technical requirement is added as a subtask and flagged as security relevant. And because our Definition of Done includes passing all test cases for security flagged subtasks, we have ensured that this specific business logic vulnerability won’t make it into production.

Create evil user stories

The evil user story is another approach that allows you to think about security requirements outside of specific user stories and epics. You create malicious personas and formulate evil user stories from their perspective: “As a disgruntled account manager, I want to copy all email addresses in our CRM so that I can take them with me when I switch to another company.”

You can either treat those evil user stories like actual user stories and mitigate them, or you can use them just as a tool for inspiration and consider them when analyzing your real user stories. If you decide to treat them like normal user stories, keep a close eye on their priority. Otherwise they might be shifted back in favor of functional user stories, leaving you open to attack.

I recommend playing around with those approaches and see what works best for you. As I said, there is no one-size-fits-all solution and you will have to tailor your approach to your processes. And once you have found the best solution for you, don’t forget to integrate it in your security requirements engineering framework, to get the most out of it!

Summary And Next Steps

You are still with me? Well done, I know that was a lot of content to digest! But now you have the basics to get started, establish, and optimize a solid security requirements engineering process.

Successful implementation is of course a totally different ball game and what sounds easy in theory is often a long and hard road in practice. If you need professional guidance along the way, me and my team are ready to help you.

After two articles dedicated to security requirements engineering, I will tackle another important aspect of secure software development next time: Building a secure architecture. We are basically switching from the what to the how in the SSDLC. If there are any specific questions you are dealing with in regards to security architecture, let me know on Twitter and I will try to fit your preferred topic into the next release or address your question directly in the next Q&A section!

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