Security requirements are concrete, testable requirements based on three protection goals: Confidentiality, integrity and availability. They do not arise from generic catalogs, but from the question of which assets are worth protecting and why. Only then can it be determined which measures are necessary and how to appraisal them.
Key Takeaways
- Security requirements can only be formulated in a meaningful way if it has been clarified beforehand which assets are worth protecting and which protection goals, confidentiality, integrity or availability, apply to them.
- Performing a pentest shortly before the release is the most expensive time to discover a security error because all design decisions have already been made.
- Card games such as Elevation of Privilege or Cornucopia allow teams without proven security expertise to playfully identify and document threat scenarios.
- Catalogs such as the OWASP ASVS are useful, but can only be used if a team knows which protection goals it has to meet, otherwise there is no benchmark for prioritization and test depth.
- The background noise of attacks comes mainly from opportunistic IT companies that automatically scan for gaps, not from the stereotypical hacker with a specific target.
Security is part of software quality, not a special case
Security is one of the quality properties of software, just like performance or availability. Established tools exist for classic quality requirements: the quality scenario with precondition, context, trigger, outcome and a testable metric.
This works well for performance. You ask the stakeholder how long a transaction may take and get a concrete answer: one second in 99 percent of cases, in normal operation. This can be used to build a testable scenario, and in the end you can prove that the requirement has been met.
When it comes to security, many teams lack the linguistic building blocks to formulate exactly that. The problem is not the complexity of the topic, but that “security” is talked about too abstractly. If you want to make security requirements testable, you first have to make them expressible.
Why abstract security requirements are not testable
“We need a particularly high level of confidentiality” is not a testable requirement as long as it remains unclear what it refers to. The sentence only makes sense if you say what data is involved.
For example: confidentiality is not the goal of a public homepage or LinkedIn profile. On the contrary, you want the content to be seen by as many people as possible. Integrity, on the other hand, is important here. Nobody should change the content without your consent.
The need for protection therefore depends on the specific asset being discussed. Without this asset, any security requirement remains up in the air.
The CIA protection goals as a common language
Instead of talking about “security”, it is worth looking at the specific security objectives. The three most important can be summarized with the acronym CIA:
- Confidentiality: What happens if the information becomes public? Does it bother you, is it a problem, maybe even a violation of the law?
- Integrity: What happens if the information is changed unintentionally? Is that a problem, or does the correct state restore itself?
- Availability: Do you lose money if the system is down for half an hour? Or does nobody notice?
These key questions transform a vague security requirement into concrete requirements. There are other protection goals such as authenticity, non-repudiation and anonymity. These also show that not everything can be achieved at the same time: anonymity contradicts non-repudiation. Security is always a trade-off.
First the assets, then the requirement
The first step in the analysis is the question of what is worth protecting in the first place. A distinction is made between two types of assets.
Primary assets are the things that are actually worth protecting, the valuable data itself. Supporting assets are the components of the system that you need to process this data.
If you make this distinction clearly, you will find a systematic way to determine the need for protection. Only then can you decide what needs to be done to actually meet these protection requirements.
How do security catalogs fit into this picture?
Catalogs such as the Application Security Verification Standard (ASVS) from OWASP are useful, but they only work on the basis of requirements. The ASVS is well suited for audits and provides relatively concrete specifications on what needs to be done. This is precisely why it sounds technical.
The catch: such catalogs are all-encompassing. They do not say which part is relevant for your system. You can only assess whether non-compliance, i.e. failure to meet a catalog requirement, is a real problem if you know your protection goal.
You don’t need to talk seriously about the entire cryptography chapter if there is no confidentiality in the system. The ASVS recognizes three levels of compliance, levels 1 to 3. Which level applies to you and how exactly you need to check or review it is determined by the requirements. That’s why the requirements are at the beginning, not the catalog.
Threat modeling complements this from the other side. It shows how a security objective could be compromised and helps to prioritize countermeasures. But if you only model the threat, you still don’t know what to do. At this point, catalogs such as the ASVS provide concrete instructions for action.
Pentest is verification, not prevention
A pentest at the end is only an appraisal of what was decided beforehand. The same rule applies here as for any other testing topic: You can’t test quality in.
It is good if a problem is noticed before the release. Nevertheless, before release is the most expensive time to discover a bug. After the release with real customer data, it only gets more expensive. Thinking about security in architecture and design only works if the requirements are known. A truism that nevertheless has to be realized.
Security analysis is iterative, not one-off
Threat modeling and protection requirements analysis are not a waterfall step at the beginning. They are repeated whenever the original decision-making basis changes. Several triggers initiate a new round:
- New functionality: A new application part brings new data into the system whose protection needs must be determined.
- Major refactoring: After restructuring, it must be verified whether the code still has the same security properties. New errors may have been introduced.
- Publicized incidents: If an attack appears in the press or on blogs, it’s worth spending fifteen minutes with the team asking: Would this have worked for us?
- New technology: AI components bring new types of attack such as prompt injection or agents breaking out of their sandbox.
The OWASP Top 10 represent the classic web application world. Incidentally, they are not a security catalog, but an awareness document for communicating the important topics. There is now a separate AI Top 10 for AI attacks that takes these new scenarios into account.
Security needs a team mindset, not a central expert
Installing one security expert for every 200 employees to determine the direction of travel is of little use. Security is a mindset that needs to emerge in the teams themselves.
In many teams, there are people with an interest in the topic. They can be encouraged so that they become advocates: People who raise their hand during the refinement and say that security should also be discussed and not just the storage space in the database. This creates a bridgehead to the team, even without a designated expert.
Threat modeling as a card game
Threat modeling can also be approached with a team that has little security experience. One method for this is card games that use real rules of the game.
The best-known example is Elevation of Privilege by Adam Shostack, created in the security team at Microsoft. It is licensed under Creative Commons and has been adapted several times. OWASP has its own variant, Cornucopia, and there is Cumulus for cloud scenarios.
The games work in a similar way to trick-taking card games with trump suit. You get the point if you can explain that the attack scenario on your card is relevant to your system. Someone takes notes, and the points collected at the end are the potential attack scenarios.
This is a very low-threshold way to talk about threat scenarios and do threat modeling while playing cards for two hours on a Friday afternoon.
Markus Geiger
There are online versions, which is practical for remote and hybrid teams. Testers can also play along and contribute their perspective.
What does the real threat situation look like?
Attacks are happening all the time. If you look carefully at the logs, you will see an attempted attack practically every hour. However, it is not true that data is constantly being extracted everywhere, partly because standard frameworks do not provide poor security by default.
The image of the individual hacker in a hoodie is misleading. The vast majority are opportunistic IT companies that scan systems en masse to see if they can make money. In some cases, the vulnerabilities found are not even exploited, but simply documented and sold on to someone who then installs ransomware. This market, which generates billions in revenue, creates a constant background noise.
The situation is different for critical infrastructure such as a large energy supplier or an airport. Here, state-funded hacker groups may have a motive to compromise the infrastructure. This is precisely the question that belongs in threat modeling: How big is the incentive to attack you? For a small craft business, it’s about a few hundred dollars ransom for an encrypted hard disk. At the airport, it’s something completely different.
What the Cyber Resilience Act requires
The Cyber Resilience Act wants to force manufacturers to think about security at an early stage. So far, this has been slow to reach the masses. The first stage will apply from next fall, with the final expansion stage following a little later.
The legal text itself is difficult to read. The BSI’s technical guideline on the Cyber Resilience Act is more practical, with examples and instructions on how compliance can be tested. Much of the content is common sense.
Some of the requirements involve effort: manufacturers must proactively inform about security vulnerabilities, provide patches and offer an automatic update option for mass-produced products that can be switched off by the customer.
This is exactly what consumers want. Nobody wants cheap hardware with a five-year-old embedded Linux that never receives updates after purchase. This is exactly the state of many consumer hardware products today.
