Six Steps to Get Your Threat Model Started

Threat models are a hugely valuable resource for modern tech businesses. They provide a framework for reducing risk and shifting security left, which is why they are used across leading tech firms all the way up to the major cloud providers.

But how do you make a meaningful start? The process is collaborative, involving a team of people. Here are six steps to get started.

---

Step 1: Define the scope

At the start of the process, decide exactly what is being threat modelled. Working with the development and security teams, clearly define the system or set of software processes that will make up the threat model. Starting with a well-scoped system makes everything that follows more manageable.

Step 2: Gather the team

Aim for at least three people from the engineering team responsible for the system in scope, plus a threat modeller or security expert with previous experience, and a business stakeholder who can give insight into risks from the perspective of the business.

Try to keep the room to six to ten people. If you need significantly more than that, it is usually a sign that the system you are trying to threat model is too large. Consider breaking it into smaller scopes.

Step 3: Orientation

Led by the threat modeller, orientation introduces the team to the approach, the session objectives and the expected outputs. This is important even for teams that have done security work before, as it sets shared expectations and gets everyone aligned on how the session will run.

Step 4: Data flow diagram

A data flow diagram (DFD) shows how data moves within the system, highlighting flows between components and across trust boundaries. The DFD is a useful visual tool for understanding the system and finding threats. At this stage, risks inherent in the system design are also captured.

Do not get too hung up on the diagram being perfect. You do not need the system fully designed, just an abstraction that represents how it works. A rough but accurate picture is more useful than a polished but incomplete one.

Step 5: Discover threats, identify impacts and risks

Using frameworks such as STRIDE, the team works through potential threats and captures them. Each threat is linked to a business risk with an associated risk level.

An important rule here: resist the urge to jump into solutions. Do not start discussing how to fix or mitigate specific threats until you have the full picture in front of you. Solving problems before you understand them in full almost always means missing things.

Step 6: Select controls

Starting with the most severe threats, the team examines each one and explores possible controls to reduce the risk. Each threat typically generates three to six possible controls.

This gives multiple options for reducing risk, which can be chosen to fit other constraints such as release cycles or available engineering time. If time is short, you may focus this step on High-risk and Critical threats and defer the Medium and Low ones.

---

Understanding security risk matters because it is how all businesses make decisions, not just in security. By working through these steps you will see your risks laid out clearly, and then start to see those risks come down as controls are implemented.

Controls from the session can be added as stories to your engineering backlog, with risk level determining their priority. As stories are completed, update the threat model to reflect the work done and reduce the associated risk level accordingly.

The result is a living document your team can use to reduce security risk over time, show stakeholders the progress being made, and demonstrate the value of security work in language the whole business understands.