Threat Modeling in Practice: Data Flow Diagrams and Trust Boundaries

Threat modeling is examining a design to find security problems before they are built. The frameworks get most of the attention; the practice is simpler than the frameworks suggest, and the part that determines whether it works is the diagram.

The four questions

A widely used framing, and a good structure for a session.

What are we building? A shared understanding of the system, which is where most of the value appears — teams routinely discover during this step that they disagree about how their own system works.

What can go wrong? The threat identification, structured by a taxonomy such as STRIDE.

What are we going to do about it? Mitigations, with owners.

Did we do a good job? Review and iteration.

The data flow diagram

The artefact everything else depends on, and it needs only five element types.

External entities — users, third-party services, anything outside your control. Processes — components that do something. Data stores — databases, queues, caches, files. Data flows — the arrows, labelled with what travels and over what protocol. And trust boundaries, drawn as lines the flows cross.

The trust boundaries are the point. A boundary is anywhere the level of trust changes: between the internet and your application, between a web tier and a database, between a container and its host, between your code and a third-party service, between one microservice and another.

Threats concentrate where flows cross boundaries, because that is where data from a less trusted context enters a more trusted one. If a session produces nothing else, identifying the boundaries and asking what validates each crossing is most of the benefit.

Keep the diagram at a level a whole system fits on one page. A diagram so detailed that it needs scrolling is documentation rather than a thinking tool, and it will not be updated.

Running a session

Ninety minutes, with the people who know the system — an architect, a developer, an operations engineer — and someone who will ask uncomfortable questions.

Draw the diagram live rather than presenting one. The drawing is where the disagreements surface, and the disagreements are findings.

Then walk each flow crossing a boundary and apply the taxonomy: could the source be spoofed, could the data be tampered with, is the action repudiable, what is disclosed, what happens under load, could this grant more privilege than intended.

Record threats as concrete scenarios rather than categories. "Tampering" is not actionable; "an attacker modifies the price field in the order request because the server recalculates nothing" is — and it is testable, which matters when it reaches the people who will verify the fix.

Turning threats into work

Every threat gets one of four responses: mitigate with a control, eliminate by removing the feature, transfer to another party, or accept with documentation. That is the same set as under risk appetite, applied at design rather than at portfolio level.

Put the mitigations into the normal backlog with owners and dates. Findings kept in a separate threat model document do not get fixed, and the accepted ones belong in the risk register rather than in a file nobody opens.

Prioritise with judgement rather than a scoring formula. Scoring models such as DREAD provide structure for the conversation and their numbers should not be treated as precise.

When to do it, and how to keep it alive

At design, before the expensive decisions are made — the whole economic argument is that changing a design costs less than changing an implementation.

Then again when something significant changes: a new trust boundary, a new integration, a change in data sensitivity, a new deployment model. A model for a monolith does not describe the same system after it becomes microservices, because every internal call has become a boundary crossing.

The failure modes are consistent. Doing it once and never revisiting produces a document describing a system that no longer exists. Making it a gate rather than a conversation makes teams route around it. And requiring a security specialist for every session limits it to whatever that person has time for — teaching teams to run their own, with review, is what makes it scale.

Validating the model afterwards is the step people skip: the mitigations you believed were in place should be tested, which is the control validation argued for under adversary emulation.

Exam angles

Know threat modeling as a design-time activity structured around what are we building, what can go wrong, what will we do, and did we do it well. Know the data flow diagram elements — external entities, processes, data stores, data flows and trust boundaries — and that threats concentrate where flows cross boundaries. Know mitigate, eliminate, transfer and accept as the responses, and that the model must be revisited when the design changes.