IT security: how can I deal with hundreds of security requirements?

Regardless of any possible residual risks such as zero days, our adesso experts and the global security community in general have extensive knowledge of what needs to be done in terms of IT security, be that with respect to the infrastructure, applications or in other areas. Well-known organisations such as OWASP, NIST and BSI (IT-Grundschutz) have issued several hundred security requirements, that much is certain. Knowing how to deal with each of these requirements is a real challenge, including how to implement them accordingly, also because there are so many of them.

In this blog post, I would therefore like to discuss two possible approaches and share my personal opinion based on my experience to date. In simplified terms, I will describe two polar opposite approaches here, one being a more traditional requirements engineering strategy and the other being an iterative approach.

Approach 1: traditional requirements engineering

In traditional requirements engineering, all non-functional requirements are compiled and documented at an early stage in the project. Implementing these requirements can then be planned in different ways. For example, they can be prioritised via the backlog or by means of a dedicated roadmap.

In the largely agile world in which we operate, this approach no longer seems to work well because so much work must be done in advance. And who really wants to start off a project with hundreds of security backlog items?

Admittedly, this is an overly simplified description of the problem, but as you can see from my previous blog posts, I am in favour of a different approach.

The goal it seeks to achieve is quite similar to the one pursued under a fully structured requirements engineering strategy. I want to meet the security requirements to the fullest extent possible to ensure that the product I deliver contains only acceptable risks. The main difference is that I:

• a) take a different approach to achieve the goal; and
• b) factor in the risk dimension.

Approach 2: the iterative approach

The second approach is built on an initial threat model in which an architecture, if at all possible not overly detailed, is analysed from the top down without any claim to completeness. What comes out in the end is a security map that highlights the critical items (risk assessment) and defines as well as determines the next steps. A typical example involves identifying a public interface and deriving high-level measures such as input validation or http security based on this.

The iterative process of fine-tuning then begins with this first step. This means that measures are defined as backlog items based on the initial findings (if the risk is unacceptable). A backlog item from the first iteration is often defined in very general terms, with the task then being to fine-tune it in the first sprints and derive specific implementation measures based on it. This meshes well with the saying you may be familiar with, namely that security is a fractal problem. Why fractal? Because as you zoom in on the ‘image’, new details emerge, which in turn can be broken down into other elements. Unfortunately, I cannot remember who said this first.

Conversely, however, this also means that new analyses have to be performed all the time, especially whenever any changes are made to the design. Security is therefore an issue that requires constant attention. Speaking for myself, I would always entrust this to a security engineer who has this specific task to carry out in the project (they do not have to work full-time on the project). To achieve the desired level of quality (or completeness), the security engineer naturally draws on their existing knowledge of the topic as mentioned above. This also includes, for example, a comparison with existing generic requirement lists.

My project experience

I took this same approach in a project some time ago. The requirements were drawn up in parallel, even though the project was on a tight schedule. Here is what the customer had to say after two workshops and a report on the results from the first iteration: ‘Super fast and super dirty, but the results are amazing’.

This does not mean that you can do security ‘quick and dirty’, but you can start without any claims to completeness and provide a quick and targeted introduction to the complex topic of security, drawing on the risk assessments. There is clearly a long way to go. That said, would it not make infinitely more sense to keep an eye on security issues from the outset and re-prioritise them if necessary as better information becomes available?

Under the shift-left principle, it is important to deploy suitable tools to achieve a more balanced approach, seeing as the initial phase is heavily focused on the design and requirements. Here, too, it is important to avoid having a large number of unresolved security issues right before deployment. Would it not be much better to provide the person making the decision with information on the status and potential residual risks associated with going live too early than to be shown a red light in a release quality gate?

Conclusion

One quick question before we wrap up the blog post: does it make more sense to start a conversation about security early on and complete the list of requirements over time, or would it be better to make this the first step in the process? As you have seen, I prefer the iterative approach because it makes it possible to integrate security considerations earlier on and uses risk assessments to prioritise requirements. As I see it, the aim is not to get a complete list of security requirements immediately, but instead to address security issues early on in order to be able to make gradual improvements. Use of suitable tools and continuous monitoring minimise the risks prior to implementation.

If you want to learn more about security-related topics at adesso and the services we offer to support companies, check out our website.

You will find more exciting topics from the world of adesso in our latest blog posts.

Also intersting

• Security professionals and the brain surgeon paradox