What is threat modelling and why your business needs it

What is it?

The architect, Frank Lloyd Wright, said, “You can use an eraser on the drafting table or a sledgehammer on the construction site”. Luckily for us, software is significantly easier to adapt than bricks and mortar. We build, we release, we learn, we improve and we release again; it’s how software is developed.

The same cannot be said about cyber security. When it comes to the risks posed by cyber threats, there is no room for experimentation. You cannot release, solicit feedback and try again. Cyber security needs to baked in, upfront, from the start. The alternative is something far worse than a sledgehammer.

Simply put, threat modelling is a process for analysing and identifying relevant threats to a system (and its data) and defining appropriate responses and mitigations. One 'deceptively simple' way to understand this process is through Adam Shostack's Four-Question Framework: "What are we working on? What can go wrong? What are we going to do about it? And did we do a good job?".

Why you need it

1. The threats posed by cyber criminality are simply too great for any business to ignore. Cyber security is now a #1 priority of every organisation and software engineering team.

2. You may already be investing in security tooling, but without threat modelling, you're essentially setting up security cameras without first figuring out what you're protecting and where intruders might enter.

3. Most security breaches exploit vulnerabilities that could have been identified through threat modelling - at a fraction of the breach's eventual cost.

4. Regulations increasingly require proof of systematic security approaches - threat modelling provides documented evidence of your security due diligence.

Developers today are responsible for quality. They are responsible for performance. Why shouldn’t they also be responsible for security?

Adam Shostack

The business impact

When organisations implement threat modelling, they typically see:

• Reduced risk: Large reduction in security-related production issues.

• Reduced costs: Significant decrease in security remediation costs.

• Increased delivery: Faster time-to-market as security issues are caught early.

• Bolstered reputation: Improved customer and investor confidence in your digital security posture.

The reality check

Your development teams may already be thinking about security, but without structured threat modelling:

• Security measures are often misaligned with actual risks.

• Vulnerabilities are discovered too late when fixes are expensive or existential.

• Teams lack a common language to discuss and address security concerns.

• Security becomes a bottleneck rather than an enabler of innovation.

How to do it

Threat modelling is a structured approach to identifying, analysing, and addressing potential security threats in software systems. Structure helps answer the questions of 'what can be wrong' and 'what are we going to do about it'.

Choosing the right model depends on your context, but many opt for STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) for its structured approach to risk identification. Here’s how decision-makers can guide this process:

1. Define the scope of the system

• Engage stakeholders: Gather perspectives from technical and non-technical teams to ensure alignment. This process often builds a shared vocabulary (domain language), fostering better communication across teams.

• Clarify the purpose: Establish clear business goals for the system and key workflows.

• Identify the boundaries: Map out the application, systems and infrastructure involved.

2. Diagram the system

• Decompose the system: Creating use cases to understand how the application is used. From this identify entry points, exit points, data stores, assets, trust levels and external dependencies, tabulating each in its own table with an ID, name, description and other related information (such as trust levels for entry points).

• Data Flow Diagrams (DFDs): Illustrate how data moves through the system, including components, users and external dependencies.

  • Consider using visual tools to map the system architecture.

  • Keep the diagram simple, but detailed enough to highlight key interactions (entry points, exit points, data stores) and assets (e.g. user details, cloud credentials).

  • If it is getting too cluttered, considering using Level 0/1/2 DFDs to show flows accordingly and better decompose your system understanding.

3. Apply the STRIDE model

For each component in the diagram, analyse the system through the lens of STRIDE, adding any considerations to a table.

• Spoofing: Could an attacker impersonate a legitimate user?

• Tampering: Can data be maliciously altered?

• Repudiation: Are there sufficient logs to track and verify actions?

• Information Disclosure: Is sensitive information adequately protected?

• Denial of Service: Could an attacker disrupt service availability?

• Elevation of Privilege: Are there mechanisms to prevent unauthorised users from gaining higher access?

4. Prioritise threats

• Assess risks based on their likelihood and impact on the business.

  • You might add risk calculations here depending on your needs. This may include sensitivity, criticality etc, after a CIA (Confidentiality, Integrity, Availability) assessment.

• Rank risks and focus on high-risk areas first, ensuring that critical assets are prioritised for mitigation.

If you try to protect everything, you protect nothing

Simon Whittaker (Head of Cyber Instil)

5. Identify and implement mitigations

• Work collaboratively to determine solutions, such as encryption, authentication controls or robust monitoring.

• Ensure recommendations align with business objectives and constraints, avoiding over-engineering.

• Define test implementations and permitted results to make it clear that mitigations are effective.

6. Document

• Record findings and decisions for future reference.

• Schedule periodic reviews to reassess threats as the system evolves.

7. Revisit

The biggest flaw in how teams implement threat modelling is not coming back and revisiting as per the schedule. Security needs will change on a regular basis, so we need to anticipate, review and document on a regular basis too.

Related Insight

Learn how to model and protect your software from cyber vulnerabilities

An expert-led, one-day threat modelling workshop for engineering teams.

How to get started

Our threat modelling workshop transforms security from a reactive expense into a proactive advantage:

• Teams learn practical threat modelling through hands-on exercises.

• 80% of the workshop is practical application.

• Results are immediate and can be applied to current projects.

• Builds on existing team knowledge and practices.

Your organisation is likely already doing pieces of this informally - we help formalise and strengthen these practices for maximum business impact. Contact our team to discuss how threat modelling can protect your business while accelerating your digital initiatives!