Why You Should Model Your Threats

My first job out of university was as a sysadmin for a medical testing laboratory. The servers I was responsible for were in a computer room in the office. I could touch them, physically see how they were networked together and inspect the hardware installed. Each ran an operating system with applications directly on it. Our setup included an on-premise mail server, web server, firewall and data storage. Security was relatively simple: monitoring, firewall, patching, least-privilege access.

The environment most organisations run today looks nothing like that.

---

How security thinking has changed

The average user now does most of their browsing on a phone. Websites are larger and more complicated. Where we once had bare-metal servers in computer rooms, applications now run in cloud environments where resources are defined via APIs and created or destroyed on demand.

Approaching security in this environment is genuinely complex. Traditional security relied on lists of controls: recommended security settings for a given piece of technology. The equivalent lists for modern cloud systems are enormous. Useful to a security practitioner, but a list of controls does not help a business understand what it needs to achieve the security it wants, how long it will take, or what it will cost.

Even clients with large security teams continue to struggle with this. As an organisation's technology estate grows in size and complexity, the security needs expand with it. More organisations of all sizes are also building their own applications, and bespoke systems do not fit the generic mould that controls lists are typically written for.

Starting with risk rather than controls

A controls-driven approach asks "what can be locked down" and "what can be turned off." Starting with risk changes the question to "what matters" and "what will harm the business." The business comes first.

This matters for a simple reason. Though security is ultimately implemented through controls, the conversation about which controls matter and why is one the business must be part of. Risk-driven thinking makes that conversation possible.

What a threat model contains

Threat models are specific to the application you have built. Generic models for certain system types do exist, but a good threat model reflects your actual system.

A threat model captures several key pieces of information. It records the threats that could affect the application, where each threat could manifest, the business risks associated with each one, and the controls available to mitigate them. It also tracks what has already been addressed.

This information is captured in a threat modelling session, where the engineering team and a security expert work through the system together. With that information gathered, readers of the threat model are clear on what mitigations are available, what those mitigations protect against, why particular ones should be implemented, and what happens if they are not.

How it changes conversations between teams

Here is a practical example. An engineering team is building a public API using AWS Lambda and needs both a development and a production environment. They decide to host both in the same AWS account for simplicity.

To the engineers, that seems logical. To the security team, it raises a red flag. A brief threat modelling session can establish the risks. If the teams find the risk is not tolerable, mitigations or alternative approaches can be proposed. Everything is recorded in the threat model.

Whatever the outcome, both teams walk away with something they did not have before. Engineers understand the business risks around what they are building. Security has a threat model they can build on, use in future conversations, and draw on during incident response and audits.

More complex versions of this play out constantly. Questions about SSH bastions, exposing virtual machines to the internet, granting IAM credentials from a frontend, security boundaries in S3. These conversations tend to create friction between security and engineering teams in larger organisations because of their different goals. A threat model brings the right information to the surface and gives both teams the context they need to reach a sensible outcome together.

Why collaboration makes it better

The part I most enjoy about threat modelling is getting a whole team together to think through the threats they are responsible for. The focus on business risks makes the consequences of attacks concrete for everyone in the room. There is something valuable about a group of people bouncing ideas around, surfacing potential threats and mitigations together. It generally produces better results than a security expert working alone.

Collaborative threat modelling also makes security more visible. Visibility improves awareness of what the security posture is, why it matters, and how it is improving over time. It builds security culture, particularly among engineers who are at the practical centre of the work.

Security is everyone's business. Not everyone can engage with the technical detail, but everyone can engage with business risk. Understanding risk earlier makes it far easier to deliver quality security with less wasted effort.

One client had invested extensively in security tools for their cloud environment. When the Log4J vulnerability surfaced, they discovered that many of those tools could not answer the questions needed for incident response. That waste of time and money could have been largely avoided with a risk-led approach from the start.

Starting your security conversations with risk rather than controls turns security from something daunting into something achievable. And it means you can bring the whole business with you.