Recurring Threats, Platform Controls

## The finding you can only see across models A threat model is normally read alone: one design, one set of trust boundaries, one threat list, one set of tickets. Reading the **portfolio** — every model the organisation holds — surfaces a class of finding no single model can show. When the same statement appears in thirty-eight models across an insurance group's estate — *service-to-service calls inside the private network are unauthenticated, so any workload that gains a foothold can call any other* — the repetition itself is the finding, and it is a finding about the **platform**, not about any of the thirty-eight products. Note the attacker and the asset, because they are what make the threat one threat rather than thirty-eight. The attacker is any compromised low-privilege workload: a container running a vulnerable library, a job that processes attacker-supplied input, a service a contractor can deploy to. The asset is credentials and lateral reach — the ability to call the claims service, the payments service, the identity service as if you were a peer. No product team owns that shape. Every product team inherits it from the network they were handed. ## Why thirty-eight tickets is the wrong shape of answer Filing one ticket per model looks diligent and is expensive in ways that do not show up in the tracker: - **Thirty-eight implementations.** Some teams will ship mutual authentication, some a shared secret in an environment variable, some an allow-list of source addresses. You now own thirty-eight designs to review and thirty-eight ways to be wrong. - **Thirty-eight negotiations.** Each ticket competes with that team's roadmap. Most will slip; a few will never start. - **No coverage for what arrives next.** Service thirty-nine ships next quarter with the same gap, and the practice has no memory. - **The work is misplaced.** You are asking product engineers to solve an infrastructure problem they cannot solve well, because they do not control the identity plane. ## Relocating the control The alternative is to move the control to where the threat actually lives. The platform issues each workload a short-lived, verifiable identity; callers present it, callees verify it, and a service gets this by being deployed rather than by writing code. One control, built once, answers the threat everywhere — including in services that do not exist yet, which is the part thirty-eight tickets can never buy. The same reasoning covers a different attacker and a different asset. A customer-support console whose agents can open any account appears in most product models as *an agent with legitimate access reads records for customers they are not helping* — a malicious insider, personal data at stake. Thirty-eight redaction projects inside thirty-eight products is the tickets answer. The relocated answer is a platform grant service: an agent requests access to a specific account for a stated reason, receives a grant that expires, and every product console reads through it. Same move, different layer. ## What has to be true before you merge threats Recurrence is a hypothesis, not a fact. Two models can use identical words for different threats: | What to compare | Why it decides the merge | | --- | --- | | Attacker position | An anonymous internet caller reaching an internal port is not a compromised peer workload; one control will not answer both | | Asset at stake | Lateral reach differs from bulk data export, and the proportionate control differs with it | | Boundary crossed | The same words can describe a hop the platform mediates and a hop it never sees | | The control that would stop it | If one control stops both, they are one threat; if not, they are two wearing the same label | Normalising threat wording across models is what makes the pattern visible in the first place; confirming the underlying flows is what makes merging safe. Matching strings is how you produce a confident, wrong consolidation. ## What the platform control owes you Moving a threat into the platform concentrates it. Thirty-eight moderate risks become one risk that matters a great deal, so the control must carry the weight: - **A named owner** — a team that is funded to run it, not a project that ended. - **A test** that exercises the property, so a change to the platform that weakens the control fails visibly rather than silently. - **A reference each product model can point at**, so the threat is still recorded in every model, now with a mitigation that lives elsewhere. - **An honest interim answer** for the window before it lands, because the threat is live now. The threat does not disappear from the thirty-eight models. It is still there — what changes is that the mitigation column stops saying *team to implement caller authentication* and starts naming a control with an owner and evidence behind it. ## When the tickets answer is still right Relocation is not free and not always correct. Keep the work distributed when the threats only look identical; when the platform team cannot own the control on any credible timeline and exposure is live; when the right control genuinely differs by service because data sensitivity or caller population differs; or when centralising creates a single component whose failure hands an attacker everything at once. The mature answer is often both: a per-service mitigation now, and a platform control in flight that lets you delete those mitigations later.