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.
Frequently Asked Questions
Why are security requirements harder to formulate than performance requirements?
For performance, there are established building blocks: the quality scenario with a precondition, context, trigger, outcome, and a metric. A stakeholder specifies a concrete number, such as one second in 99 percent of cases during normal operation. When it comes to security, many teams lack precisely these linguistic building blocks. The problem lies not in the complexity of the topic, but in the fact that security is discussed in overly abstract terms.
Is confidentiality always the most important protection goal?
No. For a public website or a professional profile, confidentiality is actually undesirable because the content is meant to reach as many people as possible. What matters there is integrity: no one should be able to modify the content without consent. Which protection goal applies depends on the specific asset. Without a specified asset, every security requirement lacks substance and is therefore unverifiable.
Can security objectives be combined arbitrarily?
No, security always involves a trade-off. In addition to confidentiality, integrity, and availability, there are other security objectives such as authenticity, non-repudiation, and anonymity. Anonymity and non-repudiation directly contradict each other: If you want to verifiably attribute actions to a person, you cannot simultaneously keep them anonymous. Such conflicts must be consciously resolved rather than attempting to meet all requirements at once.
Is a catalog like the OWASP ASVS sufficient as a basis for security requirements?
No. The ASVS is well-suited for audits and provides concrete guidelines, but it only works based on established requirements. It is all-encompassing and does not specify which parts are relevant to a given system. No one needs to seriously consider the cryptography chapter if there is no confidentiality-related data in the system. Which of the three compliance levels applies is also determined by the requirements.
Is a penetration test shortly before release sufficient?
No. A penetration test only verifies what has already been decided: You can’t test quality in. Before release is the most expensive time to discover a security flaw because the design decisions have already been made. After release, with real customer data, it becomes even more expensive. Incorporating security into architecture and design requires known requirements.
When should a team repeat its threat analysis?
Whenever the original basis for decision-making changes. Four typical triggers: new functionality that introduces new data into the system; major refactorings, after which security properties must be reevaluated; publicly disclosed attacks that raise the question, “Would that have worked on us?”; and new technologies such as AI components with attack vectors like prompt injection.
How can teams without security expertise get started with threat modeling?
Through card games with real rules. “Elevation of Privilege” by Adam Shostack, developed by the security team at Microsoft, is licensed under Creative Commons; OWASP offers a variant called Cornucopia, and Cumulus is available for cloud scenarios. The game is played similarly to a trick-taking game with a trump suit: Points are awarded when someone explains why the scenario on the card is relevant to their own system. Taking notes is sufficient as documentation.
Who is behind the vast majority of attack attempts?
Mostly opportunistic IT firms that scan systems en masse to see if they can make money from them. Some vulnerabilities they find are simply documented and resold—for example, to groups that install ransomware. The situation is different for critical infrastructure such as energy providers or airports: in those cases, state-funded groups may have a motive. The question of the motive for an attack belongs in threat modeling.
