Cyber Threat Modelling: From Scope to Attack Paths

The Cyber Security Agency of Singapore's 2021 guide presents threat modelling as a bridge between architecture and risk. Instead of beginning with a generic list of attacks, the method begins with the system: what sits inside it, how data moves, where trust changes, and which components matter most.

That ordering is the guide's strongest idea. It keeps the exercise grounded. A threat becomes useful when it can be connected to a real component, a plausible entry point, a path through the environment, and a business consequence.

The guide separates threat analysis into three levels. Management-level analysis considers broad adversaries, motives, trends, and geopolitical context. Equipment or application-level analysis goes deep into vulnerabilities, logs, hunting, and exploitation. Between them sits the system-level view—the focus of this method.

The levels support one another, but they should not be confused. Strategic intelligence can guide priorities and detailed testing can validate assumptions; the system model connects both to the architecture being protected.

1. 1

   The scope is vague. The team drifts toward fashionable threats or scenarios that do not fit the system. A clear boundary and purpose keep the conversation relevant.

2. 2

   The model stops at initial access. Real intrusions unfold in stages. Modelling only the first exploit hides the intermediate hops, privilege changes, and paths to the crown jewels.

3. 3

   The exercise is treated as finished. Architectures, dependencies, vulnerabilities, and adversary behaviour change. The model needs an owner and a reason to be revisited.

These problems all lead to the same failure: controls are prioritised against a weak picture of risk. The model should therefore be scoped, sequenced, and maintained as part of the wider risk-assessment cycle.

The guide describes four main modelling steps and then brings them together in a worked example. For day-to-day use, I find it clearer to treat the final synthesis as a fifth step.

1. 1

   Define the scope. Gather architecture and operational knowledge, agree what decision the model must support, and draw the perimeter of the system being assessed.

2. 2

   Decompose the system. Identify people and external entities, processes, components, and data stores. Connect them with data flows and mark every boundary where trust or authority changes.

3. 3

   Identify threats. Examine each component and flow for plausible threat vectors and events. Use a method such as STRIDE-LM to prompt questions, not to replace judgement.

4. 4

   Model attack paths. Link individual events into a sequence. ATT&CK can describe adversary behaviours; a kill-chain view can help explain the broad progression from preparation to impact.

5. 5

   Turn the model into decisions. Record entry points, actors, preconditions, attack steps, affected crown jewels, consequences, existing controls, gaps, and the actions that deserve priority.

Begin with what already exists: network and architecture diagrams, design documents, operational manuals, asset records, and interviews with system owners, administrators, engineers, and database specialists. The goal is not to perfect the documentation before starting; it is to expose enough of the real system to make sound assumptions.

• State the business service or decision the model is meant to support.
• List the components required to run and secure that service, including network and security infrastructure.
• Include external services and dependencies that can influence the system.
• Write down what is outside the boundary so that exclusions remain visible.
• Name the system's crown jewels: the data and functions whose loss, alteration, or interruption would matter most.

A useful data-flow diagram shows external entities, processes, data stores, and the connections between them. It should help the team follow a request or piece of data from entry to destination without needing a tour of every implementation detail.

Trust boundaries make the diagram security-relevant. Mark where data crosses between the internet and a DMZ, between user and administrative zones, between organisations, between cloud accounts, or between services with different identity and privilege models. Those crossings are natural places to ask what is authenticated, authorised, validated, encrypted, logged, and rate-limited.

STRIDE-LM gives the workshop a repeatable set of lenses. The value is not in assigning a label to every box. It is in asking how each type of failure could appear at a component, data flow, or trust boundary.

Threat intelligence can sharpen these questions, but more feeds do not automatically produce a better model. The guide recommends information that is timely, relevant to the environment, and actionable by the intended audience. A small amount of well-chosen intelligence is more useful than a queue the team cannot absorb.

Once the team has identified plausible threats, place them back onto the data-flow diagram. This makes it easier to see which components attract several threat types, where an attacker could cross a trust boundary, and how one compromise might create a path toward the crown jewel.

An event such as credential theft or SQL injection matters, but a sequence explains risk. Ask what the attacker needs first, what each step unlocks, which assumptions must hold, and what objective becomes possible at the end.

Neither framework generates the scenario for you. The system diagram, trust relationships, known exposures, and credible adversary behaviour still have to be connected by the people who understand the environment.

The guide's worked example follows a web application through its web, application, and database layers. It identifies the database as the crown jewel, applies STRIDE-LM across the data-flow diagram, and then sequences the resulting threats into attack paths.

A practical threat scenario can be recorded with the following fields:

• Point of entry: where the attacker first gains influence or access.
• Threat actor: who might attempt the scenario and what capability or access they require.
• Preconditions: the vulnerabilities, trust relationships, credentials, or connectivity needed for the path to work.
• Sequence: the ordered actions from entry to the target.
• Crown jewel and impact: what is exposed, altered, interrupted, or destroyed.
• Controls and evidence: what should prevent, detect, slow, or help investigate each stage.
• Decision: which gap will be treated, who owns it, and how closure will be verified.

• A stated purpose, scope, owner, and review trigger.
• A system and data-flow diagram with trust boundaries and crown jewels marked.
• Assumptions, exclusions, external dependencies, and open questions.
• Threat events tied to specific components, flows, or boundaries.
• A small number of credible attack paths, including post-compromise movement.
• Existing preventive, detective, and recovery controls mapped to the paths.
• Prioritised gaps with accountable owners and evidence required for closure.