How does attacker-defender cost asymmetry shape defending 400 legacy sites with one engineer?

## The shape of the asymmetry Attacker economics is usually taught as a single comparison — cost of one attempt against gain from one success. Across an estate it becomes a comparison of *cost curves*, and the two curves have different shapes. An attacker pays a substantial one-off cost to develop a technique: find the weakness in a common platform, write the exploit, learn how the responses look. After that, applying it to the next target costs a request. Their total cost scales roughly with the *number of techniques* they use. A defender pays per site: discover it exists, determine its stack, apply a fix, verify the fix, and keep it applied through a maintenance lifetime nobody funded. Their total cost scales with *sites times techniques*. With four hundred departmental sites accreted over fifteen years and one security engineer, that multiplication is the whole problem. Any plan whose first step is "go through the sites and fix them" loses arithmetic before it loses to any attacker: each new technique the attacker learns re-multiplies your work, and the estate keeps drifting behind you while you sweep. Adding a second engineer changes a constant on the losing side of a multiplication. ## The move: change the curve, not the effort The strategic question is not "how do we fix more sites faster" but "where can one unit of defender work cover N sites" — that is, how do we buy the *attacker's* cost shape for ourselves. Four levers do that, roughly in order of value per unit of political capital spent. **Shrink N.** Decommissioning is the cheapest security work available on an estate like this. A site nobody has updated since a graduate left is not a site to harden, it is a site to archive to flat files or delete. Every removal permanently subtracts from every future multiplication, and unlike a patch it does not need reapplying next quarter. **Put controls where they are shared.** Routing the whole estate through one ingress layer lets a single change enforce transport security, authentication for anything non-public, response headers, request limits and a virtual patch for a newly published technique — once, for everything behind it. That is the attacker's economics running in your favour: pay once, apply to N. **Standardise what remains.** Migrating surviving sites onto one hosted platform or one template converts four hundred stacks into one stack with four hundred instances. Central identity does the same for credentials: one place to enforce and revoke rather than four hundred local login forms. **Make detection carry the tail.** A detection rule also has the pay-once-apply-to-N shape, so centralised logging and a small number of rules cover the estate far more cheaply than per-site remediation. And because compromise of a forgotten site is a question of when, network isolation between the estate and anything that matters — research data, staff systems, the identity infrastructure — bounds the consequence rather than the likelihood. Inventory precedes all of it. You cannot decommission, route, migrate or monitor a site you do not know exists, and on an estate like this discovery normally finds more sites than the official list. ## What you accept, and how you say it Everything above still leaves a tail: sites that must stay, cannot be migrated in this budget year, and will not be patched promptly. The senior move is to say so explicitly and to bound the damage rather than pretend the tail is covered — isolate it, keep nothing sensitive on it, monitor it, and put a decommissioning date on the calendar. That is an honest position; "we scan and patch everything" on an estate of this size is not. ## Where the argument gets pushed back Two objections are worth having ready. The first is that consolidating four hundred sites behind one ingress creates a single point of failure — true, and it is the trade you are choosing: you concentrate both risk and control. It is usually right when N is large and per-site quality is outside your influence, and it obliges you to invest in that layer's own resilience and to keep isolation behind it so a bypass does not hand over the estate. The second is departmental ownership: a team wants its site kept. Answer in the same currency. A live legacy site draws on the security budget every technique cycle, forever; a static archive keeps the content at almost no recurring cost; migration to the shared platform keeps the site and moves it into the pay-once column. Make the default a deadline rather than an open debate, because the asymmetry compounds while the discussion runs.