Threat modeling: from vulnerability to control

Data breaches and ransomware are no longer exceptions. Still, many organizations only take risks seriously once something has already gone wrong. That’s a missed opportunity. With threat modeling, you identify risks early and in a structured way, so you can prevent them instead of having to fix them later.

Purpose of threat modeling

Threat modeling helps you gain insight into potential threats to your system. These threats are not purely technical.

• Errors in code or architecture
• Unintended actions by users
• Misuse through social engineering

The key difference compared to traditional thinking? You don’t focus on use cases, but on abuse cases. Not: how should the system work? But: how can it fail?

Although technology is often central, threat modeling is applicable more broadly. Think of physical security for buildings or processes as well.

Start early and keep repeating

Prevention only works if you start on time. Ideally, you begin threat modeling before the technical design of the application. This allows you to incorporate risks directly into architectural decisions.

But it doesn’t stop there.

Software is constantly evolving. Think of new features, architectural changes, and integrations with other systems. Each of these changes introduces new risks.

That’s why it’s important to schedule sessions regularly:

• When developing new features
• When making architectural changes
• At least annually as a fixed part of your process

The four-step approach

An effective threat modeling session consists of four steps:

1. Mapping the application
2. Identifying threats
3. Prioritizing risks
4. Defining mitigations

It’s important to involve different disciplines. Developers, infrastructure specialists, security experts, and business stakeholders all look at the same system from different perspectives. That combination is what makes it effective. In practice, a brainstorm session with all disciplines involved works well.

1. Mapping the application

The first step is to understand how the application works, or how it is structured. You map out the different components and their interactions. So-called trust boundaries are especially important: the points where systems, services, or users interact. These transitions are often where vulnerabilities arise, making them a logical and effective starting point for analyzing risks.

2. Identifying threats

This is often the most challenging part. You systematically explore what could go wrong, from different perspectives:

• From the software: known vulnerabilities and patterns
• From the assets: what are you trying to protect?
• From the attacker: how would you break the system?

A practical way to make this concrete is to use personas:

• Hannah the hacker, professional and focused on data theft
• Scott the scripter, uses off-the-shelf tools
• Careless Diane, makes unintentional mistakes
• Angry Bart, has internal knowledge and malicious intent
• Unhappy Onno, wants to damage the company’s reputation

Thinking from these perspectives helps you identify more realistic scenarios.

Visualize this process, for example using post-its, and capture as many threats as possible. Even if they seem unlikely. Filtering comes later.

3. Prioritizing with DREAD

Not every risk requires the same level of attention. That’s why you prioritize, for example using the DREAD model:

• Damage: what is the impact?
• Reproducibility: how repeatable is it?
• Exploitability: how easy is it to execute?
• Affected users: how many users are impacted?
• Discoverability: how easy is it to find?

Assign a score to each factor, for example from 1 to 3, and calculate an average. This gives you a clear overview of what needs the most attention.

Document the outcomes carefully. Not only for follow-up, but also to improve your ability to identify risks over time. In some organizations, this is also part of compliance or security certification requirements.

4. Mitigations

After a threat modeling session, you have a clear view of the most important threats and their priority. You use this to make informed decisions. For new functionality, you incorporate risks directly into design and implementation. For existing systems, you address vulnerabilities based on priority. Keep track of what has been resolved and what is still open, so you maintain oversight and can steer effectively.

5. Challenges

When organizing your first threat modeling sessions, teams often run into similar challenges:

• The wrong people involved
• Too much focus on solutions instead of analysis
• Too much detail, or not enough depth
• Lack of structure in the session

The solution lies in repetition. By doing this regularly, threat modeling becomes a natural part of your development process.

Want to learn more?

At Betabit, we build and manage business-critical software, with security integrated from the very beginning. We use proven approaches such as threat modeling and Privacy by Design to identify and manage risks early.

We also share this knowledge through our training programs. In our threat modeling workshop, you and your team will work together to put threat modeling into practice under the guidance of an experienced trainer or coach. By the end of the workshop, you will have a clear overview of the vulnerabilities and a solid plan of action. In addition, we offer various training courses in security and software development to help strengthen your team.

Want to learn more or discuss your specific situation? Feel free to get in touch.