Computer Security: How can I deal with hundreds of security requirements?

[ayshakhatun3113]

Regardless of any possible residual risks, such as zero-day vulnerabilities, our experts at adesso and the global security community at large have extensive knowledge of what needs to be done in terms of IT security, whether in relation to infrastructure, applications or other areas. Renowned organisations such as OWASP, NIST and BSI (IT-Grundschutz) have issued several hundred security requirements, that's for sure. Knowing how to address each of these requirements is a real challenge, including the corresponding implementation, also because there are so many.

In this blog post, I would 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 bc data requirements are collected and documented at an early stage of the project. The implementation of these requirements can be planned in different ways, for example, they can be prioritized via the backlog or by means of a dedicated roadmap.

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

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

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

a) I take a different approach to achieving the goal; and
b) I consider the dimension of the risk.
Approach 2: The iterative approach
The second approach is based on an initial threat model where an architecture, if possible not too detailed, is analysed from the top down without any pretensions to exhaustiveness. What results in the end is a security map that highlights critical elements (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 fine-tuning process then starts 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 of the first iteration is often defined in very general terms, the task being to fine-tune it in the first sprints and derive specific implementation measures based on it. This fits well with the saying you may know, namely that security is a fractal problem. Why fractal? Because as you get closer to the 'picture', new details emerge, which in turn can be broken down into further elements. Unfortunately, I can't remember who said this first.

However, this also means that analyses must be carried out constantly, especially whenever 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 perform on the project (they do not have to work full-time on the project). In order to achieve the desired level of quality (or completeness), the security engineer naturally draws on his existing knowledge of the subject, as mentioned above. This includes, for example, a comparison with existing generic lists of requirements.