The Drawing Is Where the Findings Are
Last timeWhat You Are Actually Protecting
Draw what the system actually is, including the parts nobody puts on architecture diagrams, then mark every line where data crosses between differently trusted things.
What gets left off
Ask a team for their architecture diagram and you will get a drawing of
the system serving a request. Browser, load balancer, two services, a
database, a cache. It is accurate and it is not the drawing you need.
The drawing you need includes everything that touches the data, whether or
not it is involved in serving anybody. That turns out to be a much larger
picture, and the parts that are missing are missing for a consistent
reason: they are not on the request path, so they were never drawn.
| usually on the diagram | touches the data | can read every record at | belongs on the threat dr | |
|---|---|---|---|---|
| the nightly backup and w | 0 | 1 | 1 | 1 |
| the administrative inter | 0 | 1 | 1 | 1 |
| the analytics pipeline | 0 | 1 | 0 | 1 |
| the support tool that ca | 0 | 1 | 1 | 1 |
| the scheduled export job | 0 | 1 | 1 | 1 |
| a developer laptop with | 0 | 1 | 0 | 1 |
| the primary database | 1 | 1 | 0 | 0 |
| the error reporting serv | 0 | 1 | 1 | 1 |
The pattern is worth stating because it generalises. The parts left off
tend to be the parts with the broadest access, precisely because broad
access is what makes something useful for backups, support and analytics.
The request path is narrow by design; everything around it is wide.
Three entries deserve naming. The support tool, which exists so that a
person can see somebody elses account, and which is therefore a legitimate
mechanism for exactly the thing you are trying to prevent. The analytics
pipeline, which usually copies production data somewhere with different
controls and a different owner. And the error reporting service, which
receives whatever happened to be in a variable when something failed,
which is routinely more than anybody intended.
What a boundary is
With the drawing populated, mark the boundaries. This is the step that
produces the findings.
A trust boundary is a line where data passes between two parts that trust
each other differently. It is not a network edge, not a firewall, and not
the outline of your cloud account, though it sometimes coincides with
those. The test is whether the two sides have different reasons to be
trusted.
The lesson stops here
3 more paragraphs to go
You have read the opening. The rest of the argument, the problems that check whether it landed, and the lines worth keeping at the end all come with a plan.
The first lesson of every course in the library reads the whole way through, free, so you can see exactly what the rest of them are.
See the planThe contentsThis is the reading half
Starting the course gives you your own copy of it. Every idea on every page has problems standing under it, marked with a reason rather than a tick, and any sentence you do not believe can be opened and argued with. None of that can happen on a page nobody owns.
The contents