Diagramming Pitfalls

## The fifth mark on the page A data-flow diagram (DFD) uses four element types: **external entities** (people or systems outside your control), **processes** (code that acts on data), **data stores** (databases, object storage, queues, log files) and **data flows** (the arrows between them). The **trust boundary** is a fifth mark, and it is deliberately not an element — it is a line drawn *across* flows at every point where the level of trust or privilege of the party handling the data changes. That definition matters, because it is not the same as a network line. A boundary can sit inside one process (a request arriving from an unauthenticated caller versus one carrying a support agent's session), between two services in the same cluster, or between two readers of the same table. Conversely, a firewall in the deployment may separate two components that share exactly the same privilege — and there is no boundary there worth drawing. ## Why the missing line stops the analysis Threat enumeration works by walking the page and asking, at each element and each crossing, what an adversary standing there could do. Boundary crossings are where an adversary changes what they are able to reach, so they are where the interesting threats live: data arriving from a less-trusted side must be validated, data leaving to a less-trusted side must be filtered or authorised, and identity asserted across the line must be authenticated rather than assumed. Remove the boundaries and that walk has no structure. Every flow looks like every other flow, so the enumeration either produces nothing at all or produces the same generic sentence about each arrow. In the classic STRIDE-per-element mapping a process attracts all six categories while a data flow attracts tampering, information disclosure and denial of service — but which of those is *credible* depends entirely on who sits on the other end of the arrow, and that is exactly the fact the missing line withholds. ## The worked example A hospital scheduling portal is drawn with three reader groups — clinicians, a billing vendor's support staff, and a research team — each with an arrow into a single appointments-and-patients database, plus the portal process in the middle. It is an accurate picture of the deployment. It is not a threat model, because those three readers are three different principals with three different legitimate needs: | Principal | Legitimate need | What the undrawn boundary hides | |---|---|---| | Clinician | Full record for their own patients | Whether scope is enforced per patient or per role | | Billing vendor staff | Amounts, insurer, dates | Whether they can read clinical notes and identifiers too | | Research team | De-identified aggregates | Whether the export path re-identifies | Each arrow crosses a change in trust, and each crossing raises a different question about patient personal data. With the lines drawn, the analysis writes itself: what authenticates the vendor's staff, what limits their query, what is logged so a bulk read is attributable. With no lines, none of those questions has a place to attach. ## The half-drawn version, which is the more common defect More common than *no* boundary is exactly one boundary: a single line labelled "internet", with everything else inside it treated as one undifferentiated trusted zone. That model can only ever produce threats from an anonymous outsider. It structurally cannot represent the vendor's support staff, a misconfigured internal service, or a partner integration, because the diagram asserts that all of them are equally trusted. A reviewer should treat one perimeter line as barely better than none: it answers "where is the front door" and refuses every other question. ## What a reviewer says, and asks for The conclusion to state out loud is narrow and fair: this is a system diagram, and the threat-modeling step has not happened yet. It is not a claim that the design is insecure — it is a claim that the artifact cannot support that claim either way. The request that unblocks it is mechanical. For every flow, name the principal at each end and the credential that principal presents. Wherever those two ends differ, draw the line. Then re-walk the page; the threats that appear at the new crossings are the ones that were invisible five minutes earlier. ## A useful sanity check If the boundaries on a finished diagram trace exactly the network topology, the author probably drew network segments and relabelled them. Real boundaries usually cut across the topology in at least one place — inside a single service, or between two consumers of one store — and a diagram where they never do deserves a second look.