Software ArchitectureAtlas

Software Architecture Atlas

Gain an overview. Understand the connections.

ActivityChapter III · Security · Building block 2 of 7

Threat Modeling

Threat modeling examines how attackers or sources of error can affect a system and its data. The analysis combines goals worth protecting with plausible paths and verifiable countermeasures.

By Michael Meierhoff · Meierhoff Systems

  1. Path of attackThe way in which damage occurs.
  2. ThreatConcrete consequence for the goal.
  3. EvidenceA control must be verifiable.

Context

Why this is important

Without systematic consideration, a team secures the positions that come first. Threat modeling combines protection-worthy targets, attack paths and testable countermeasures. Trust Boundaries and Auth deepen their own building blocks.

This building block leads through a threat analysis. Trust Boundaries show transitions; Least Privilege limits the effect of granted accesses.

At a glance · Attack path meets target

An attack path leads from a source to an asset worth protecting; countermeasures close it and are verified.
Shop example · Secure the attack path

Attack path of the shipping message

The team looks at an incoming shipment message and asks if a compromised partner could change third-party order status.

This is how you read the picture

  1. Path of attack The steps from 'Partner sends message' to 'Status change saved'.
  2. Threat Threats 'Forge message', 'Insert foreign identifier' and 'Replay message', with their consequences.
  3. Evidence Under each control, such as 'Check signature', the test appears as evidence.
  1. Partner sends message
  2. Endpoint accepts
  3. Assignment to order
  4. Status change saved
  5. Bestellstatus von B-1042
Controls
  • Fake messageWrong delivery is shown as shipping status
  • Use a third-party identifierOrder of another merchant changes status without authorisation
  • Repeat messageStatus is reset or processed twice

3 of 3 threats remain open.

Switch on controls and see which threats to the order status are stopped.

Benefits & limitations

Helps if:

  • New interfaces and identity paths benefit from examining potential access and effects.
  • Sensitive data flows, tenant isolation and privileged operations require targeted assessment of potential harm.

Boundaries

  • The model becomes obsolete with each change to the flow; assumptions and data flows are retested for significant changes.
  • A measure without proof remains conjecture; a test or finding shows that the attack step is really blocked.
  • It identifies only known attack types; Trust boundaries defines the relevant zones, while Least Privilege limits the damage.

In practice

  1. Define assets and scope. Identify the data, functions and boundaries to protect, and the system version under review. Record assumptions about actors and permissions. This establishes a clearly scoped threat model.
  2. Derive abuse paths and controls. Trace potential attacks along data flows and map existing safeguards. Assess potential consequences and uncertainties against system goals. This enables prioritisation of the main risks.
  3. Back mitigations with evidence. Assign a safeguard, responsible role and verification method to each prioritised gap. Test effectiveness in the implementation or in operation. This connects the model, change and verifiable protection status.
Read the detailed explanation

Threat modelling connects assets, actors, data flows and trust boundaries to potential abuse paths. The analysis describes concrete events, their impact and existing controls. Categories such as spoofing or tampering support a systematic search. The model builds on Trust Boundaries and makes rules for Authentication & Authorisation concrete.

For relevant threats, record residual risk, mitigation and evidence. Evidence can be a negative test, a configuration or an operational rehearsal. The model applies to a design and its assumptions; new data flows, roles or interfaces can change the attack surface. Regular updates keep mitigations aligned with the actual architecture. Prioritisation considers entry paths, potential impact and existing detection. This directs limited security effort towards risks whose significance is clear.

STRIDE is a mnemonic for six threat categories: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service and Elevation of Privilege.

Check your understanding

Test yourself in three stages

  1. ReadingCheck in the picture

    Which control in the visual stops the threat 'Replay message'?

    View the solution with justification

    'Check sequence and transitions'. The evidence is a test with a replayed old message.

  2. ApplyingTransferred to a new situation

    A partner sends a validly signed message with a foreign identifier. Which threat is present, and what protects against it?

    View the solution with justification

    'Insert foreign identifier'. The signature is not enough; checking tenant responsibility stops it, with log and test.

  3. EvaluateWeighing an alternative

    The team only implements signature checking. What speaks for it, what speaks against it, and what do you recommend?

    View the solution with justification

    Advantage: low effort, forgeries are clearly testable. Disadvantage: foreign identifier and replay remain open, as they are validly signed. Recommendation: implement all three controls with evidence.

Explore further

These building blocks continue the thoughts of this page.

SecurityTrust BoundariesTrust Boundaries mark transitions between trust levels that require protection and validation.Opening SecurityAuthentication & authorisationAuthentication establishes identity; authorization checks whether an action is permitted.Opening SecurityLeast PrivilegeLeast Privilege limits access to the permissions a task actually needs.Opening

References

Continue on the learning path

Next in Security & risks: Least Privilege.

7 Building blocks

Continue withLeast Privilege