Recovering an Undocumented System

## The situation A twelve-year-old freight-forwarding customs-declaration broker still runs in production. It submits declarations to a government gateway and pulls tariff and consignee data from a third-party customs-data vendor. The last engineer who wrote it left years ago; there is no diagram, no design document, and two operators who know how to restart it. You have been asked to threat-model it. The asset that matters most here is not customer records, it is **audit truth and non-repudiation**: a declaration that was altered, replayed, or attributed to the wrong filer is a legal problem, not just a data problem. A plausible adversary is the vendor at the far end of one of those flows being compromised. You cannot threat-model a system you cannot describe. Recovery comes first, and recovery is an evidence exercise. ## The five evidence sources, and what each one lies about **1. Declarative infrastructure config and its state.** The repository that provisions the estate, plus the state it records, tells you which networks, subnets, load balancers, queues, object stores and managed databases exist and how they are wired. It is the best single source for *topology*. What it misses: everything created by hand outside it, everything that drifted after the last apply, and everything provisioned before the team adopted the tooling — for a twelve-year-old system, that is often the older and more interesting half. **2. Route and reverse-proxy configuration.** The route file, the ingress rules, the API route table: these enumerate the inbound paths that reach the application and which upstream serves each one. This is where the entry side of the picture comes from. What it misses: everything that is not an HTTP request — a queue consumer, a scheduled job, a file drop, an operator with a shell. **3. The repository itself, read for egress.** Grep for hostnames, base URLs, SDK client construction, connection strings, webhook targets, SMTP and SFTP endpoints. This is usually the only way outbound third-party edges surface at all, because nothing in the infrastructure config has to mention a host you merely call over the internet. What it misses: whether the code path is live, which environment the endpoint belongs to, and any destination that arrives at runtime from configuration or a database row. **4. Identity bindings and grants.** Service-account role bindings, cross-account trust policies, database `GRANT`s and key policies tell you *who is permitted to reach what*. A grant is not proof that a flow happens — but it is proof that a flow **could** happen, which for threat modeling is nearly as important. Draw it as a candidate edge and label it: the permission is itself attack surface. **5. Request telemetry.** Access logs, flow logs, request traces and metrics tell you what genuinely moved, when, how often, and to where. This is the only source that reflects behaviour rather than intent. What it misses: anything outside the retention or observation window. A quarterly reconciliation run leaves nothing in a 30-day log, and its absence is not evidence it does not exist. ## Cross-checking, not merging The useful discipline is to keep the two directions of error apart: | Source type | Systematic error | |---|---| | Config, code, grants | **Over-states**: dead rules, orphaned grants, unreachable code | | Telemetry | **Under-states**: only the window, only what fired | So: the union of both is your candidate edge set; the intersection is the set you can call confirmed without asking anyone. Everything in the difference is a question for a human. Config with no traffic may be dead — or may be the quarterly job. Traffic with no config is the more alarming direction and deserves its own investigation. ## Then talk to the operators The draft is a hypothesis. Walking it edge by edge with the two people who still run the broker converts guesses into facts faster than any amount of further reading, and it surfaces the flows that leave no artifact at all: the analyst who pulls a monthly extract by hand, the vendor who mails a certificate once a year, the emergency path someone uses when the gateway rejects a batch. Record who confirmed each edge and when — provenance on the diagram is what lets the next reader judge it. ## What goes on the paper Annotate each edge with the evidence that produced it — config, telemetry, code, operator statement, or inference — and mark unverified edges visibly rather than omitting them. An edge you silently drop becomes a threat nobody ever considers; an edge drawn with a question mark on it becomes a task. For the customs broker, the vendor flow drawn as a real, confirmed edge with its protocol and data class is what lets you ask the question that matters: if that vendor is compromised, what can it do to the truth of a declaration?