model your threats

Table of Contents

Key Takeaways

• Threat modelling helps teams find and fix vulnerabilities early, protecting valuable data.
• Security by Design means keeping systems simple and focusing only on necessary features.
• Collaboration across roles is crucial—open discussions bring out the best ideas for system safety.
• Use proven methods like STRIDE and revisit threat modelling throughout a project’s life.
• Assigning a security champion in each team helps keep security top-of-mind and integrated.

Threat modelling (or a term I affectionately refer to it by, “evil brainstorming”) is a key enabler of building good, secure software and doing the best possible job of preventing any costly or expensive mistakes in relation to the exposure of your application’s biggest asset: data.

An enabler of this is thinking is Secure by Design and a key principle of security by design is keeping the design context and responsibilities itself as small as possible, in order to focus on creating what you need and doing it well. There is a huge overlap between good software design and secure systems, one often enables the other.

A few key concepts of security by design enables this;

• treat everyone who can actually access the system (be it over the air, or physically) as a potential threat
• the model of least privilege, and separation of concerns and privilege
• ensuring complete mediation
• sane, restrictive authorization defaults - define roles, deny everything first then allow what you need

Threat modelling delivers the most value when it is executed consistently and repeatedly, as part of an agile, iterative, feedback rich process - allowing developers to identify and prioritize fixing vulnerabilities.

The purpose of threat modelling however is not always to identify the most immediate risks to your system and is flexible to the ability, agility and responsibility of your team. Sometimes, you need to manage or accept the risks that a threat will pose - sometimes, you have to mitigate them and accept and open risk to that system.

Therefore, threat modelling can be used not only at the start of a project or delivery lifecycle (e.g. start of a sprint), but can also be retrospectively applied to existing systems and applications to identify and catalog the security posture of a particular app or system that, for example, may be in the middle of a migration.

There are many methods and examples of threat modelling (you could probably build a library with the number of books you can find). STRIDE (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege) is a popular and well-documented approach, and it’s usually where I would start with most of my teams.

Think of threat modelling as a conversation between people, interested in exploring the weaknesses of a system. The team should first agree on the intended behaviour of a system - agree what you are building. It usually helps to model the behaviour (aptly named, behaviour modelling) or to think of scenarios and map/draw them out (for example with a data flow or sequence diagram).

The output of this doesn’t need to be as formal as diagrams or detailed system specifications - it can be post-its on a wall, or stickies on a mural board.

Then think about the behaviour, shift your point of view to an evil actor. Think about the impact and cascading consequences of a given threat event, for example a threat may result in damage to physical assets, or may result in obvious financial loss. Indirect loss may also result from an attack -this all needs to be considered as part of the impact. Think of their intentions, their motivations, look at your threat and answer the question: what can go wrong?

It’s important to understand that not all threats are important - at least not equally important. Some may be out of your control, the only option being to accept and try to mitigate. Some you may be able to act on and potentially remove that attack vector entirely. But for all the threats and scenarios you have identified, it’s important to ask: What are we going to do about it?

This will help you to validate and prioritize your risks. The validation can be done in various ways. For a potential large scale vulnerability risk, you might conduct a pen test. You can also build (or buy) tooling and processes to help ensure continuous compliance via code scanning or code review. For validated threats that are above a risk threshold, implement additional controls so that you can mitigate the risks. Track the work in the backlog and prioritize it alongside other stories. There are usually a few options:

• Redesign the feature to eliminate the threat
• Implement a proactive control (e.g. XSS or SQL injection prevention)

In the case where you can’t do either of those things (e.g. downstream dependencies) you can also transfer the risk - usually by amending an agreement with your end-users to identify the potential risk and ensure that they are following best practice to ensure that it cannot be exploited very easily.

A key enabler of secure by design is DevOps, you may hear DevOps and Security married as DevSecOps - and there is a good reason for that. Secure thinking should be ingrained in the minds of those you trust to design and build your systems. Adopting a more open and agile model should allow you to shift-left your security thinking and make it a standard part of the behaviour modelling of the systems you intend to build.

It’s a collaborative effort - you always need representation, alignment and agreement from the main stakeholder groups. Ideally, this is an open session which is not restricted to the immediate squad if possible, people unfamiliar with how something should work often, in my experience, come up with the best ideas to make it not work how it should.

This usually means a workshop or session with a product owner, someone representing the customer, a security engineer or architect and someone from the development team.

You want to look at the system from the viewpoint of an attacker, what could go wrong? How could the system be misused by a bad actor? How can we ensure we protect the users’ data? What is the worst-case scenario? Its almost like behaviour modelling, but instead of happy or unhappy path, you’re exploring the evil paths.

It’s likely that if you’re just starting out on the design of a system, that this will be a very collaborative and iterative process - you may find value in several shorter threat modelling sessions with different audiences to ensure you are capturing the most diverse thoughts possible.

Threat modelling can also be part of a design review - if you don’t have direct control or responsibility over how something is being delivered but maybe are responsible for signing off on or reviewing the designs (for example) and you’re not confident that there is enough thinking being spent on secure thinking - make it part of the design review process. Demand that there is a conversation on the behaviour of a system from a bad actors’ path point of view.

If you are a truly agile team, you might already have secure design thinking and review as part of the iterative delivery of your software, and that’s great - but can you push it even further? Can you shift even further left? (the answer is almost always yes, btw)

How about introducing a Security Champion into each of your squads? Nominate a developer or engineer interested in security to champion the security interests of the team and of the system, enable them to ensure that the process is iterative, security first and Secure By Design.