APOLLOSEC

Threat modelling

We map what could go wrong and who would do it, validate your concerns against how attackers really work, and help you apply the fixes.

Decide where the security budget goes

Security budgets are finite, and threat modelling decides where they go. It identifies the assets that matter, the attackers likely to come after them, the routes they would take, and the controls that would stop them.

It works at two levels. For a new system or product, it finds design flaws before they are built, when they are cheapest to fix. For a whole organisation, it connects the threat actors active against your sector to your own estate, so your defences match the attacks you are likely to face.

What we model

  • System threat models

    Data flows, trust boundaries and abuse cases for a new application, platform or integration, using STRIDE and attack trees.

  • Organisational threat models

    The threat actors targeting your sector, their techniques, and the assets they would go after.

  • Attack paths

    Realistic routes from initial access to your critical assets, mapped to MITRE ATT&CK.

  • Control review

    Which of your existing controls break those paths, and where the gaps are.

  • Validation

    Optional targeted testing to confirm the riskiest assumptions.

  • A living model

    A model your team can keep up to date as the system or the threat changes.

How the engagement runs

  1. Workshops

    Two or three short workshops with the people who design, build and run the system or service.

  2. Model

    We document assets, data flows, threats and attack paths, and rate each risk.

  3. Validate

    We check the riskiest assumptions against current attacker behaviour, and by testing where useful.

  4. Plan

    A prioritised set of controls and design changes, with owners.

What you get

  • A threat model you can maintain as things change.
  • Prioritised risks and the controls that address them.
  • Scoping input for penetration tests and red team objectives.

When to commission it

  • At design stage for a new system, product or integration.
  • When the architecture changes significantly.
  • When entering a new market or sector with a different threat landscape.
  • Before scoping a red team, so its objectives reflect real risk.

Questions we get asked

When should we threat model?

As early as possible for new systems, ideally at design stage, and again when the architecture changes significantly. For organisations, yearly or whenever your threat landscape changes.

Which methods do you use?

STRIDE and data flow diagrams for systems, attack trees for specific goals, and MITRE ATT&CK to map real threat actor behaviour. We choose what fits rather than forcing one method.

What do you need from us?

Architecture diagrams if they exist, and time with the people who design and run the system. Two or three workshops is typical.

How does it relate to penetration testing?

A threat model tells you where to test and what to test for. Many clients use it to scope penetration tests and red team objectives, so testing effort goes where the risk is.

Put your security budget where the risk is.

Talk to us