Data-Flow Diagrams and Trust Boundaries

A process is running code that transforms data, a data store is passive data at rest, an external entity is a person or system you do not control, and a flow is data in motion between them.

An entry point is anywhere data or a request crosses into the system from outside its trust boundary. Not just HTTP endpoints: queue consumers, file drops, inbound email, webhooks, scheduled jobs that fetch remote data, and admin or support consoles all count.

A trust boundary marks a data flow where the two sides do not trust each other equally. Draw it wherever the principal, privilege, tenant, code owner or execution context changes - not wherever the network or a firewall changes.

A data-flow diagram shows what data moves where, not when or in what order. It omits control flow, sequencing, retries and error paths, so replay, race, double-processing and failure-path leak threats stay invisible on it.

Conclude that threat enumeration has not started. A trust boundary marks where the privilege of whoever handles the data changes; with none drawn, every flow on the page looks equally trusted and there is nothing to analyse.

Rebuild the diagram from artifacts that describe the running system: infrastructure-as-code and its state, route and proxy configuration, outbound calls grepped from the repository, identity bindings and database grants, and request telemetry. Confirm each edge with an operator.

Writing the principal an element acts as, and the privilege it actually holds, makes every privilege change visible on a data-flow diagram. Without those labels, boundary placement is guesswork and high privilege hides in plain sight.

A trust boundary marks where trust or privilege changes, not where the network changes. Two tenants sharing one subnet still have different owners and different rights, so anything crossing from one to the other crosses a boundary.

The boxes are organisational units, not system elements. A data-flow diagram is decomposed by where data moves — external entities, processes, stores, flows — so an org chart leaves an adversary nowhere to stand and no boundary to draw.

An unlabelled arrow hides the three things the analysis needs: what channel protects the data, which way the data actually moves, and how valuable it is. Without those, every flow looks identical and threats collapse into guesswork.

Exit points are where data leaves the trust boundary: logs, exports, backups, restore copies, crash dumps and telemetry. They carry the asset outward without anyone breaking in, and they usually skip the authorization the primary request path enforces.

The boundary belongs at the server API, not inside the browser. Everything you ship - route guards, hidden buttons, role flags - runs on a machine the user controls, so both roles sit in one untrusted zone.

A component diagram shows logical separation; a deployment diagram shows where code actually runs. Co-location threats, such as two supposedly separate services sharing one process, one host and one credentials file, appear only in the deployment view.

Decompose only where more detail would change a decision. Stop when the next level would produce elements you would mitigate identically, when no boundary hides inside the box, or when its owners will model it themselves.

Both defeat the walk. The 200-element page spreads a reviewer's attention evenly so boundary crossings vanish into noise; the two-box page hides every privilege change inside a box, so each threat comes out as an unactionable 'tamper with the monolith'.

Exposure is only one axis. The others are privilege — what the path can do once used — and attribution: whether a use binds to a person and would be noticed. A rarely used break-glass admin route can outrank a public form.

An observed flow is real evidence, so the configuration set is what is incomplete. Characterise the edge from telemetry — endpoints, identity, protocol, volume, schedule — then walk it with the on-call operator, keeping it drawn until someone accounts for it.

The agent's identity dies at that boundary. Downstream sees one caller holding the union of every agent's access, cannot make any per-agent decision, and records one name for every read, so attribution is lost.

Draw the boundary around granted access, not around the company. Bureau operators who can read every payroll record sit inside the zone that handles employee data, so operator misuse is an in-scope threat your model has to name.

The provider owns the host, the patching, the storage and the backup machinery; you own the schema, the credentials and every access rule. A cross-tenant read caused by a missing tenant filter is your threat, not theirs.

The child diagram must show the same flows in and out as the parent process it expands — same sources, same sinks, none added or dropped. Only internals are new, and numbering carries down: process 3 expands into 3.1, 3.2.

Whenever the box covers code running at different privileges, reached by different callers, or handling different data classes. One process shape asserts one identity and one set of controls, so anything inside it that differs disappears.

Trust changes at the code-ownership seam: foreign code inside your process shares your address space, secrets and privileges. A boundary belongs there, but nothing enforces it in-process - so mark it unenforced, or move the plugin into a separately privileged process.

Standardising on one diagram makes reviews comparable and the practice teachable, but it silently caps what teams can find. Protocol, retry, error-path and co-location threats do not fit the notation, so nobody raises them and the gap reads as safety.

Very little about security, and nothing by omission. The data classes and business flows probably still hold; every claim the page makes about boundaries, surface and the adversary set has expired, and absence from it proves nothing.

A recovered diagram is ready when it answers the decision at hand: every trust-boundary crossing drawn, every data store's class named, every identity reaching a sensitive store enumerated, and every unverified edge labelled. Time-box the rest.

A uniform principal is a finding, not a tidy diagram. With one credential everywhere, no edge can show a privilege change, so the boundaries the system needs have been erased by its identity design rather than proven absent.

Neither model covers the seam, because each stops at its own edge and draws the missing control on the far side. Close it by modeling the shared boundary jointly and naming exactly one owner for every control on it.