Developing security requirements as a team

Generic security requirements such as “the system must be secure” are of exactly zero help in software testing. Instead, concrete protection goals are needed: What data must remain confidential? What must not be changed under any circumstances? And what does it really cost if the system goes down for an hour? If you clarify these questions early on and model threats in a playful way, you save yourself expensive pentests and can finally make security testable.

Podcast Episode: Developing security requirements as a team

This time I talk to Markus Geiger about a problem that many testers are familiar with: Security requirements are often formulated so abstractly that you can’t do much with them when testing. Markus shows how to talk about concrete protection goals such as confidentiality, integrity and availability - and why teams without security experts can use simple methods such as threat modeling card games to find out for themselves where their vulnerabilities lie.

“We don’t just talk about security, we talk about protection goals.” - Markus Geiger

Markus Geieger is a project manager, trainer and architect at WPS - Workplace Solutions. Markus studied Communications Engineering in Esslingen am Neckar and Distributed Computing Systems Engineering at Brunel University in London and has more than 25 years of experience as a software developer, software architect and coach in many projects in the industrial, logistics and retail environment. In addition to software architecture, he is particularly interested in IT security and the secure development lifecycle.

Highlights der Episode

• Formulate security requirements according to the CIA model: Confidentiality, Integrity, Availability - don’t talk about “security” in the abstract.
• Pentests are only verification at the most expensive point - security requirements must be clear beforehand.
• Threat modeling card games such as Elevation of Privilege make security discussions in the team low-threshold and playful.
• Attacks are attempted every hour - mostly opportunistic, not targeted by hacker elites.
• Cyber Resilience Act demands common sense: proactive communication, updates, no more orphaned cheap hardware.

Security requirements in software development - How teams make security testable

Software is attacked every day. This is no exaggeration, but everyday life, as Markus Geiger emphasizes in the podcast episode. But how do development teams manage to understand security not just as an abstract requirement, but to implement it in concrete terms? This article sheds light on why security requirements are difficult to grasp, how this can be changed and how teams with little prior knowledge can still achieve a great deal.

Security as part of software quality

Security is an important quality characteristic - and just as difficult to translate into concrete requirements as many other aspects of software quality. Typical scenarios can be formulated for performance or reliability: “How long can the response take?” or “How many users must the system be able to handle at the same time?”. There are simple, comprehensible metrics for these questions.

When it comes to security, many teams find it more difficult. This is because protection is often described with general phrases (“Our system must be secure”). But that doesn’t help anyone and certainly not the testers. They need tangible criteria.

Turning security goals into requirements

The first step is to break down security requirements. The so-called CIA principle helps here:

• Confidentiality: Who is allowed to see information?

• Integrity: May data be changed - and if so, by whom?

• Availability: How long can the system be down before it becomes critical?

Such objectives make it possible to ask clear questions: What happens if this file becomes public? Will customers lose money if our application is offline for 30 minutes? These questions create a tangible framework for discussion - and suddenly requirements can be made testable.

Recognize protected objects: What is actually worth protecting?

The decisive factor is what security objectives relate to. Every application processes data, but not everything is equally important. For some elements, integrity is more important than confidentiality. For others, the opposite.

Markus Geiger suggests first identifying so-called “security assets”: These are the things that really need to be protected. These include the actual data (e.g. customer data, payment information), but also supporting components such as servers or databases.

If teams know which assets they want to protect, they can formulate requirements much more precisely - and then look for suitable measures.

Catalogs help - but only in the second step

Many turn to security catalogs such as the ASVS from OWASP. These are lists with very detailed requirements from the security scene. They can be a useful tool - but only if you know in advance which requirements and protection objects are really relevant for your own system.

What is the point of implementing an entire chapter on cryptographic security if no confidential data is processed in the system? Such catalogs are more like maps with potential branches than a rigid plan for every project.

Discuss threat models together

Threat modeling sounds technical at first, but is often nothing more than a structured discussion: What dangers threaten our application? How could attackers try to circumvent our protective measures? This team knowledge not only helps to identify vulnerabilities earlier. They also create a shared security awareness.

Incidentally, this does not require experts in hoodies. Methods such as security card games (e.g. “Elevation of Privilege”) make it easier for everyone to participate. They bring lightness to the team and are an easy way to discuss threats together and derive measures.

Team mindset instead of lone wolf mentality

Security is not a task for individuals. One or two “security officers” cannot cover everything. It is much more effective if interest in security is awakened in the team and small steps are established: Paying attention to security aspects more often during refinement makes it possible to identify problems early on - and not just in the expensive penetration test shortly before release.

The most important steps: Identify assets, define goals, discuss together. It sounds simple, but it is very effective and better than working through every checklist blindly. If you tackle the issue as a team, you can make security requirements testable and manageable step by step - and thus really protect software better.