You inherit a service whose four threat-modeling questions were answered in a wiki page two years ago - how do you restart the loop?

## The situation An inherited FX-rate publishing service: the rate it publishes is what downstream systems settle money against. Somebody ran the four questions at kickoff two years ago and wrote the answers on a wiki page. Questions one to three were answered there; question four - *did we do a good enough job?* - has never been asked at all. There is no ceremony that re-opens the page, and nobody currently on the team was in that session. This is the most common real-world state of threat modeling, and interviews use it because the naive answers are both wrong in opposite directions: trusting the page wholesale, or deleting it and starting from nothing. ## Why question one has to go first Everything in the old page hangs off the model. Threats were enumerated against a set of components and flows that existed two years ago, so: - threats against components that no longer exist are noise, and clearing them is cheap; - components that appeared since were never enumerated at all, and nothing in the page will tell you they are missing; - and a trust boundary that moved - a function that used to run in-house and is now operated by a managed service - silently changes who the relevant attacker is. That last point matters here. If part of the publishing chain is now run by a vendor, a compromised managed-service operator is a legitimate attacker position with privileged, legitimate access to the pipeline, and the asset at risk is the integrity of a published rate rather than a stolen dataset. That threat cannot be in a two-year-old list because the boundary did not exist when the list was written. So the first move is to rebuild the model of what actually runs today. It does not have to be beautiful; it has to be current and agreed by the people operating the service. ## What to salvage and what to redo The cheap parts to redo are the diagram and the threat list - both fall out of a fresh pass in a session or two. The expensive part, and the part worth reading carefully, is question three's output: the decisions and their reasons. A line saying *we accepted the risk of unsigned rate updates on the internal hop because the network was considered isolated* is genuinely valuable. It tells you what the team believed, what condition the acceptance rested on, and therefore what to check now. If the condition has changed - the hop is no longer isolated, or a vendor now sits on it - the acceptance has silently expired. **An accepted risk is a decision made under stated conditions, not a permanent property of the system.** Re-consent it explicitly, with a current owner, or reverse it. Discarding the page to start clean throws all of that away and guarantees the new team re-litigates decisions someone already thought about. Accepting the page as current is worse: it gives false confidence that a model exists. ## Running question four for the first time On an inherited system this is the fastest source of real findings, because it needs no new enumeration. Take each mitigation the old page claims and ask what evidence exists that it is in the running system. Two years is long enough for a control to have been refactored away, moved behind a flag, or simply never built - and nothing in the wiki distinguishes *we agreed to do this* from *this is deployed*. Verified controls stay; unverified ones become open items again. ## The judgment call, which is what is really being tested There is no fixed right answer to *how much do you rebuild*. The tradeoff to state out loud: - **Proportionality.** A service that settles money justifies a full pass; a low-value internal tool justifies re-answering question one and verifying the top few controls. - **Sequencing.** Model first, verify old decisions second, re-enumerate third. Verification produces concrete findings early and buys you the credibility to spend more time. - **Ownership.** The exercise ends with a named owner for the model itself, otherwise you are creating the same stale page for the next person who inherits the service. - **Cadence.** State what will re-open the model next time - the change that triggers it - so the loop does not close permanently again. ## Answers that go wrong Re-answering question two off the old diagram is the most seductive mistake: it feels like real work, produces a longer threat list, and is built on a picture nobody has checked. Equally weak is treating the exercise as an archaeology project - reconstructing what the original authors meant instead of looking at what is deployed. The page is a source, the running system is the truth.