Where Trust Changes

## What a trust boundary actually claims On a data-flow diagram (DFD) you draw external entities, processes, data stores and the flows between them. A **trust boundary** is a line cutting across one or more of those flows, and it is not decoration: it is an assertion that *the element on one side cannot vouch for the element on the other*. Everything you do afterwards hangs off that assertion. Threat enumeration is driven by crossings - at each crossing you ask what a party on the far side could send, forge, replay, read, corrupt or withhold - and the controls you list (authentication of the caller, authorization decisions, input validation, output encoding, rate limits, logging that survives the far side) are the things you place *at* the crossing. A boundary in the wrong place therefore does not just make an ugly picture; it silently deletes a set of threats from the review, or invents a set that never existed. ## The rule: trust, not topology Draw a boundary wherever the **level of trust changes**. In real designs that happens for a small number of recurring reasons: - **Authentication changes.** An anonymous caller becomes an identified one, or an unauthenticated protocol carries a flow that the receiving side then acts on. - **Authorization or privilege changes.** A normal user's request reaches an administrative function; a service that runs unprivileged calls one that runs with elevated rights; a request ends up executing against a datastore account that can read far more than the caller may see. - **Tenancy changes.** A request path from one customer can reach another customer's data or compute. - **Code ownership changes.** Code written by a party you do not control begins executing - another team's plugin, a vendor's library, a callback you accepted. - **Execution context changes.** Work moves to a different OS user, a different container, a different machine, or into a child process that can be constrained differently from its parent. A useful sixth trigger, really a consequence of the first five: **input arrives from a party you cannot constrain**. Anything downstream of that input is handling attacker-influenced data until something validates it. ## Why "the network changed" is the wrong test The network test fails in both directions. *Hops that are not boundaries.* Two internal services owned by one team, deployed together, running as the same service identity, holding the same secrets, are one trust zone even though their traffic crosses a switch. Compromise either and you have the other. Drawing a boundary between them produces a threat table nobody will act on and dilutes the boundaries that matter. *Boundaries with no hop.* A plugin from another team loaded into your process, a child process started under a different OS user, two accounts on one host, an administrative console and a normal console served by the same binary - all are real trust changes with no packet crossing anything. ## The perimeter-only diagram, worked Take a factory manufacturing-execution system on a flat plant network, where the only boundary anyone drew is the corporate firewall at the edge. The adversary that matters is someone already on the plant LAN - a contractor's laptop, a vendor's remote-support session, a compromised operator workstation - and the asset at stake is the safety and continuity of the physical process, not a database of customer records. Deriving the real boundaries from trust changes rather than from wiring gives you several the perimeter model hid: operator workstations authenticate to the MES, so that flow crosses an authentication change; engineering workstations write setpoints to controllers that accept the write unauthenticated, so the controller trusts anything on the wire and the boundary sits right at its input; the historian replicates plant data up to corporate reporting, so a flow crosses an ownership and privilege change in the outbound direction; a vendor's support path enters as a party the plant does not control. None of that is visible while a single line around "the plant" declares everyone inside to be us. (Deciding how to *segment* that network afterwards is a different discipline; the modeling job here is only to make the trust changes that already exist appear on the diagram.) ## Don't over-draw either Boundaries cost analysis. If you draw one at every arrow, every crossing demands a table and the genuine ones stop standing out. The discipline is the same in both directions: for each boundary you drew, name the two parties and say in one sentence what the trust difference is and what enforces it. If you cannot, erase it. ## Checking your work A quick self-review that catches most placement errors: for any two elements you put in the *same* zone, ask whether compromising one gives the attacker the other. If yes, one zone is right. If no - different principal, different owner, different privilege - you are missing a boundary. Then walk each boundary and ask what the far side is allowed to assume; whatever it assumes without checking is your next threat.