Security as an Adversarial Game

Security is the one area of systems work where the phrase “it’s a game” is used constantly and meant seriously — and where the analogy is most often invoked without paying its price. A game, in the technical sense, is not “two parties with opposed interests.” It is a tuple: a set of players, an enumerated action set per player, a payoff function over action profiles, an information and timing structure, and a solution concept that says what “playing well” means. Security supplies the first item generously and the rest badly. Where the missing pieces have actually been supplied — a defender who commits publicly to a randomised policy, a set of defenders whose investments create externalities on each other, a resource that is silently captured and silently reclaimed — game theory has produced results that are correct, non-obvious, and in a few cases deployed. Where they have not, “modelling security as a game” produces papers whose conclusions are determined entirely by the payoff numbers the author chose. This note covers both halves, and treats the second as the more important one: the limits are not a closing caveat, they are the subject.

What this note is and is not

This is the general framing note for P8 of Games and Strategic Systems in C MOC. The mechanics of leader–follower commitment, the ARMOR/IRIS/PROTECT deployments, the DOBSS solver, and the SSAS interchangeability theorem live in Stackelberg Games and Commitment and are deliberately not repeated here — this note cites that machinery and asks a different question: when is any of it applicable, and what happens when you apply it anyway? The catalogue of concrete attacks against build and distribution systems is Software Supply Chain Threat Landscape. The minimax machinery is Zero-Sum Games and the Minimax Theorem. Everything numeric below was either read directly from a paper I fetched or computed here in exact rational arithmetic and shown.


Mental Model: the five things a game needs, and which ones security gives you

The useful discipline is not “think like an attacker.” It is to write down, explicitly, the five components a solution concept requires, and to notice which ones you had to invent.

flowchart TB
    Q0["Claim: 'this is an adversarial game'"]
    Q1{"1. Players<br/>Who are the decision-makers?"}
    Q2{"2. Action sets<br/>Can you <b>enumerate</b><br/>every move each can make?"}
    Q3{"3. Payoffs<br/>Do you know u_att and u_def<br/>over every action profile?"}
    Q4{"4. Information &amp; timing<br/>Who observes what, when?"}
    Q5{"5. Solution concept<br/>Nash? Stackelberg?<br/>Maximin? Best response?"}
    OK["A game you can solve.<br/>Rare, and always small."]
    F2["Attack trees, ATT&amp;CK,<br/>STRIDE: <b>partial</b> enumerations<br/>with no completeness claim"]
    F3["Elicited or invented numbers.<br/>Conclusions follow the numbers."]
    F4["The one component security<br/>genuinely supplies: surveillance,<br/>stealth, publication, disclosure"]

    Q0 --> Q1 --> Q2
    Q2 -- "no (usual case)" --> F2
    Q2 -- "yes (bounded domain)" --> Q3
    Q3 -- "no (usual case)" --> F3
    Q3 -- "yes (elicited, bounded)" --> Q4
    Q4 --> F4
    Q4 --> Q5 --> OK

What it shows: the five-part gate that any game-theoretic security claim has to pass, and where real security practice falls out of it. The insight: the analogy fails almost always at step 2, not step 5. Practitioners argue about solution concepts (is the attacker rational? does he play Nash?) when the binding failure is one step earlier — you cannot compute a best response over a strategy space you cannot list. Every deployed success in this space, without exception, is a domain where step 2 was made finite by fiat: these eight terminals, these 400 flights, this one key that is either fresh or stolen.


Zero-sum is a modelling convenience, and it is usually false

The default move when someone says “security is a game” is to reach for the zero-sum machinery: the attacker’s gain is the defender’s loss, so the defender should play a maximin strategy and the minimax theorem guarantees a value. This is attractive for a reason that has nothing to do with security: in a finite two-player zero-sum game, Nash equilibrium, minimax, maximin and the Stackelberg solution all coincide, equilibria are interchangeable so there is no selection problem, and the whole thing is one linear program. You get uniqueness, tractability and a defensible “worst case” story in a single stroke.

It is also, in the deployed applications, not true. The Korzhyk–Yin–Kiekintveld–Conitzer–Tambe JAIR paper states it flatly: “security games are not necessarily zero-sum (and are not zero-sum in deployed applications)” (Korzhyk et al. 2011, §3). The reason is structural rather than accidental. The paper cites Bier (2007) for the point that an attacker’s utility depends on quantities that barely enter the defender’s: the cost of mounting the attack and the propaganda value of the target to the attacker. A defender’s loss when a substation goes down is a repair bill and an outage; the attacker’s gain is a news cycle. These are not the same number with opposite signs, and there is no exchange rate between them.

Worse, security games are not even strategically zero-sum — the strictly larger class (Moulin & Vial 1978) that preserves most of the good properties. The JAIR paper gives a three-line counterexample, and it is worth working through completely because it shows exactly what the zero-sum shortcut costs you.

The game. Three targets t₁, t₂, t₃, one defender resource, so the defender’s mixed strategy is a coverage vector c = (c₁, c₂, c₃) with c₁ + c₂ + c₃ = 1 (cᵢ is the probability target i is covered). Payoffs, from the paper’s Table 2:

t₁ coveredt₁ uncov.t₂ coveredt₂ uncov.t₃ coveredt₃ uncov.
Defender102030
Attacker010101

Read that carefully: the attacker is indifferent between the three targets — each is worth 1 if uncovered and 0 if covered. The defender is not: catching the attacker at t₃ is worth three times catching him at t₁. That asymmetry alone — attacker indifferent, defender not — is enough to break zero-sumness, and it is an entirely realistic asymmetry (a honeypot is worthless to the attacker and valuable to you).

Three quantities, computed here by exact rational brute-force over the simplex at denominators 66 and 132 (both agree, and both reproduce the paper’s two published vectors):

Defender expected payoff if t_i is attacked : c_i · d_i    where d = (1, 2, 3)
Attacker expected payoff if he attacks t_i  : 1 − c_i

MAXIMIN  (maximise the worst case over targets)
    equalise c₁·1 = c₂·2 = c₃·3  →  c = (6/11, 3/11, 2/11),  value 6/11 ≈ 0.545

MINIMAX  (minimise the attacker's best payoff)
    minimise 1 − min_i c_i       →  c = (1/3, 1/3, 1/3),     attacker gets 2/3

STRONG STACKELBERG (commit; attacker best-responds, ties broken for defender)
                                 →  c = (1/3, 1/3, 1/3),     defender gets 1

The maximin strategy and the minimax strategy are different vectors. In a zero-sum game that is impossible — they are the same object viewed from two sides, which is precisely what von Neumann’s theorem asserts. Here they diverge, and the divergence is not decorative: a defender who reaches for the zero-sum reflex and computes maximin plays (6/11, 3/11, 2/11), and against a best-responding attacker earns 3 × 2/11 = 6/11 ≈ 0.545. A defender who computes the actual Stackelberg answer plays the uniform vector and earns 183% more from the same resource, purely by not assuming zero-sumness.

The intuition is worth stating because it is counterintuitive: the maximin defender pours coverage onto t₁, the target where being attacked hurts most in the uncovered case… except that in this game the uncovered payoff is 0 everywhere, so “hurt” is identical across targets and the only thing that varies is the upside of catching him. Maximin, which reasons about a malevolent opponent rather than a self-interested one, misreads that asymmetry entirely. The right answer is to spread coverage evenly, making the attacker indifferent, and then let the strong tie-break hand you the target where a capture is worth 3.

When the zero-sum assumption is safe

It is safe exactly when it is true, and one important family makes it true by construction: cryptographic and protocol security definitions. “The adversary wins if he distinguishes the two worlds” is a genuinely two-outcome, genuinely opposed game with a fully specified action set (any probabilistic polynomial-time algorithm) and no payoff numbers to invent. That is why provable security works and game-theoretic risk modelling does not: the crypto game is a real game. Note also that where the game is zero-sum, commitment is worth exactly nothing — Stackelberg and maximin coincide — so the entire randomised-patrol argument collapses to “play maximin”. See Zero-Sum Games and the Minimax Theorem and Stackelberg Games and Commitment.


The game that is actually well-posed: defenders against each other

The strongest, best-validated strategic result in security is not about attackers at all. It is that the defenders are playing a game among themselves, and that they lose it.

Ross Anderson opened this line with an observation from automated-teller-machine fraud (Anderson, ACSAC 2001). In the United States, a customer disputing a transaction put the burden of proof on the bank; in Britain, Norway and the Netherlands, the burden lay on the customer. American banks therefore had a motive to protect their systems and — the part that matters — although they “actually spent less money on security than their European counterparts, they spent it more effectively.” European banks, insulated from the loss, “became careless. Eventually, epidemics of fraud demolished their complacency.” Anderson’s generalisation is the single most quotable sentence in the field: “where the party who is in a position to protect a system is not the party who would suffer the results of security failure, then problems may be expected.”

This is a game with all five components present and no invented numbers. The players are real institutions, the actions are budget allocations, the payoffs are recoverable from liability law and fraud statistics, the information structure is public, and the solution concept is ordinary Nash. Nothing about it requires modelling an attacker’s mind.

Varian’s three reliability technologies

The formalisation is Hal Varian’s (System Reliability and Free Riding, Feb 2001, revised 30 Nov 2004). Let agent i exert effort xᵢ at cost cᵢxᵢ, and let the system succeed with probability P(F(x₁, x₂)); agent i values success at vᵢ, so its expected payoff is P(F(x₁,x₂))·vᵢ − cᵢxᵢ. Everything turns on the shape of F — how individual efforts aggregate into system reliability. Varian, building on Hirshleifer’s story of an island whose flood defences depend on the laziest family, identifies three:

TechnologyF(x₁, x₂)Real security instanceEquilibrium result
Total effortx₁ + x₂vulnerability testing; fuzzing hours; log reviewUnique NE. Reliability set by the agent with the highest benefit/cost ratio vᵢ/cᵢ; everyone else free-rides (Fact 1)
Weakest linkmin(x₁, x₂)program correctness — the most careless committer introduces the vulnerabilityA continuum of NE. Reliability set by the agent with the lowest benefit/cost ratio (Fact 2)
Best shotmax(x₁, x₂)the one security architect or internal auditor who champions the fixPossibly two discrete NE — including a “slacker equilibrium” where the high-value agent contributes zero, knowing the other will be forced to

Walk the symbols once, because this is the whole argument. vᵢ/cᵢ is agent i’s benefit-to-cost ratio: how much reliability is worth to it, per unit of effort it costs. In the total-effort case each agent’s first-order condition is vᵢP′(x₁+x₂) = cᵢ, so agent i wants the total to reach a level x̄ᵢ = G(cᵢ/vᵢ) that depends only on its own ratio; whoever wants the highest total supplies all of it and the other free-rides. In the weakest-link case each agent’s best response is min(x_other, x̄ᵢ) — matching the other until it hits its own ceiling — which produces a whole range of equilibria, the Pareto-best being min(x̄₁, x̄₂), i.e. the least motivated agent’s ceiling.

The scaling result is the one with teeth. Drawing agents from a cost distribution, what matters is the order statistics — the highest and lowest costs of effort — so: “Systems will become increasingly reliable as the number of agents increases in the total efforts case, but increasingly unreliable as the number of agents increases in the weakest link case” (Fact 5). Every large codebase with many committers is a weakest-link system with a growing n.

Uncertain — the scaling claim has two versions and they are not the same

Verify: “adding agents makes weakest-link systems less reliable.” Reason: Varian’s Fact 5 derives this from order statistics over a distribution of costs — more agents means a worse worst agent. His Facts 6 and 7, for identical agents, say something different: in the weakest-link case “the socially optimal reliability and the Nash reliability are identical, regardless of the number of agents,” and in the total-effort case the Nash outcome is constant in n while the social optimum rises. The popular one-line summary in Anderson & Moore’s survey collapses these into a single claim. Both papers were read in full here; the discrepancy is one of scope (heterogeneous vs identical agents), not an error, but the claim should always be stated with the heterogeneity assumption attached. To resolve: state which of Facts 5/6/7 you mean when citing it.

Varian’s policy conclusions are unusually concrete for a theory paper — “software companies should hire more software testers and fewer but more competent programmers” (testing is total-effort, so you want volume; correctness is weakest-link, so you want to raise the floor), and Fact 8: the optimal fine “equal to the costs imposed on the other agents should be imposed on the agent who has the lowest cost of reducing the probability of failure.” That is a mechanism-design prescription derived from a security model, and it is the intellectual ancestor of every software-liability proposal since.

Hidden action, hidden information, and the lemons market

Anderson and Moore extend this into a taxonomy: security failures are largely hidden-information or hidden-action problems. Hidden action is the insurance case — one party’s unobservable behaviour changes the outcome — and it maps directly onto systems: “Routers can quietly drop selected packets or falsify responses to routing requests; nodes can redirect network traffic to eavesdrop on conversations; and players in file-sharing systems can hide whether they have chosen to share.” Their design prescription is to “structure interactions to minimise the capacity for hidden action, or to make it easy to enforce suitable contracts” — which is exactly what Rate Limiting as a Mechanism and reputation systems do.

Hidden information gives you Akerlof’s market for lemons, and Anderson’s application is savage. If buyers cannot distinguish secure products from insecure ones, price converges to the value of the insecure ones and the secure ones leave the market. Worse, the obvious fix — third-party evaluation — has its own incentive failure. Anderson’s complaint about the Common Criteria is that, unlike the Orange Book, evaluations are “not made by the relying party … but by a commercial facility paid by the vendor”, which “motivated the vendor to shop around for the evaluation contractor who would give his product the easiest ride.” He goes further: from the user’s point of view “an evaluation may actually subtract from the value of a product”, because a certificate may make a court less willing to order disclosure of documentation you would need to challenge a forged signature. Whatever you think of the conclusion, the structure of the argument is game-theoretic and requires no attacker model at all.

flowchart LR
    subgraph MKT["The market game (no attacker required)"]
        V["Vendor<br/>chooses security effort"]
        E["Evaluator<br/>paid by vendor"]
        B["Buyer<br/>cannot observe quality"]
        V -- "pays for evaluation" --> E
        E -- "certificate" --> B
        B -- "price = expected quality" --> V
    end
    subgraph OUT["Equilibrium"]
        L["Lemons: price falls to<br/>insecure-product value;<br/>secure products exit"]
        S["Evaluator shopping:<br/>cheapest/easiest ride wins"]
    end
    B --> L
    E --> S
    L -.->|"reduces return on<br/>security effort"| V
    S -.->|"decouples certificate<br/>from quality"| B

What it shows: the information-asymmetry loop between vendor, vendor-paid evaluator and buyer that Anderson identifies. The insight: the security failure here is an equilibrium, not a bug. No party behaves irrationally, no attacker appears anywhere in the diagram, and no amount of better cryptography changes the outcome. The fix has to be a change in who pays whom — a mechanism change, not a technical one.

This is also why the third of the US federal government’s three named “game-change” research themes, alongside Moving Target and Tailored Trustworthy Spaces, is Cyber Economic Incentives — justified in exactly these terms: “information security problems are substantially issues of misaligned incentives and misallocated resources - and are therefore economic problems that require economic and not merely technical solutions” (NITRD CSIA IWG, 13 May 2010).


FlipIt: the cleanest game security has produced

If the economics results are the most validated strategic work in security, FlipIt is the most elegant — and it is the best worked example available because its mathematical content is real, its assumptions are stated honestly, and its motivating scenario (an attacker who steals your key and you never find out) is one that ordinary threat modelling handles badly.

FlipIt was introduced by Marten van Dijk, Ari Juels and Alina Oprea (RSA Laboratories) with Ronald Rivest (MIT) in FLIPIT: The Game of “Stealthy Takeover” (this note reads the full IACR ePrint 2012/103, dated 26 February 2012; the journal version is Journal of Cryptology 26(4):655–713, October 2013, DOI 10.1007/s00145-012-9134-5, confirmed via the Crossref API). Its motivation is the assumption failure that Advanced Persistent Threats (APTs) create: “attackers launching an APT can steal full cryptographic keys, crossing the line of inviolate key secrecy that cryptographers assume in designing primitives. Assumptions may also fail repeatedly.” Leakage-resilient cryptography assumes continuous partial compromise; FlipIt assumes repeated total compromise.

The game

Two players, a defender (player 0) and an attacker (player 1), contest one shared resource — a key, a password, a virtual machine, an entire infrastructure. Time is continuous. Either player may move at any instant, paying a move cost; moving gives that player control of the resource. The defining twist, which the authors note has no precedent they could find in the game theory literature:

A player does not immediately know when the other player moves. A player only finds out about the state of the system when she moves herself.

So a defender who rotates a key does not learn whether the key was already stolen except by rotating it. An attacker who re-steals a key does not know whether the defender rotated in the meantime except by stealing it again. There are no observable “turns,” no alternation, no notification. The payoff, called benefit βᵢ, is the fraction of time player i controls the resource (its gain γᵢ) minus its average move cost per unit time:

β_i  =  γ_i  −  k_i · α_i

  γ_i  = fraction of elapsed time player i controlled the resource   (0 ≤ γ_i ≤ 1, γ_0 + γ_1 = 1)
  k_i  = cost of one move for player i
  α_i  = player i's rate of play (moves per unit time) = 1/δ_i for period δ_i
sequenceDiagram
    autonumber
    participant D as Defender — key rotation
    participant R as Resource — the key
    participant A as Attacker — key theft
    Note over R: control = D
    A->>R: move (steal) — cost k₁
    Note over R: control = A<br/>D does not know
    Note over D,A: attacker holds; defender still<br/>believes the key is safe
    D->>R: move (rotate) — cost k₀
    Note over R: control = D<br/>D learns nothing about<br/>whether it had been stolen
    A->>R: move (steal again) — cost k₁
    Note over R: control = A
    Note over D,A: neither player is ever told<br/>when the other moved

What it shows: one trajectory of FlipIt, with the crucial fact drawn as an absence — no arrow ever runs from a move to the opponent. The insight: this stealth is why FlipIt is not a standard repeated game. In an iterated game you condition on the opponent’s observed history; here the history is invisible, so a strategy is essentially a schedule, and the interesting question becomes how to randomise a schedule, not how to react.

Solving the periodic case, by hand

Take both players playing periodically with a random phase: fixed period δᵢ, with only the first move’s offset chosen uniformly at random. Suppose the defender moves at least as fast (α₀ ≥ α₁) and let r = δ₀/δ₁ = α₁/α₀. Within any one defender interval of length δ₀, the probability that the attacker’s single move falls inside it is r, and given that it does, it lands uniformly at random, so the expected attacker-controlled fraction of that interval is r/2. Hence:

β₀(α₀, α₁) = 1 − α₁/(2α₀) − k₀α₀        (defender)
β₁(α₀, α₁) =     α₁/(2α₀) − k₁α₁        (attacker)

Theorem 1 of the paper gives the Nash equilibrium of this game in closed form. For k₀ < k₁ (the defender’s move is cheaper):

α₀* = 1/(2k₁)          α₁* = k₀/(2k₁²)

Note what α₀* depends on: the defender’s optimal rate of play is a function of the attacker’s move cost, not her own. That is the sort of result that only falls out of writing the game down.

The paper’s illustrated case is k₀ = 1, k₁ = 1.5. Recomputed here in exact rational arithmetic — including a brute-force sweep over 900 unilateral deviations for each player, confirming neither can improve:

α₀* = 1/(2·1.5)       = 1/3
α₁* = 1/(2·1.5²)      = 2/9
gains    (γ₀, γ₁)     = (2/3, 1/3)
benefits (β₀, β₁)     = (1/3, 0)
best unilateral deviation, defender : 1/3   (no improvement)
best unilateral deviation, attacker : 0     (no improvement)

This exactly reproduces the values printed in the paper’s Figure 4, and it exhibits the headline result: the benefit of the player with the higher move cost is always 0 in the Nash equilibrium. The attacker still controls the resource a third of the time — he is not excluded — but every unit of value he extracts is exactly consumed by what it cost him to extract it. And when move costs are equal (verified here for k₀ = k₁ = 1 and = 2), both players get benefit 0: the whole surplus is burned in the contest.

What FlipIt actually tells a defender

Three lessons, all stated by the authors and all operational:

  1. Design for repeated total compromise. The paper quotes the then-head of the NSA’s Information Assurance Directorate: “No computer network can be considered completely and utterly impenetrable — not even that of the NSA. NSA works under the assumption that various parts of their systems have already been compromised.”
  2. Move cost is the lever, not move rate. “By lowering the move cost a player can obtain higher benefit, no matter how the opponent plays.” Playing fast is only a good defence if moving is cheap — and if it is cheap enough relative to the attacker’s cost, aggressive play “can motivate the opponent to drop out of the game (essentially not to play at all).” The authors’ engineering conclusion is that virtualisation “has a huge potential in this respect”: if refreshing a machine costs nothing, you can refresh constantly. This is the argument for immutable infrastructure and short-lived credentials, derived rather than asserted.
  3. Randomise, and randomise the right way. Against a naive attacker, periodic play is fine — Theorem 4 shows the periodic strategy with random phase strongly dominates all renewal strategies of the same rate. But against a last-move (LM) attacker, who learns on moving exactly when the defender last moved, “periodic play for the defender is not very effective, as the attacker learning the defender’s period and last move time can move right after the defender.” Theorem 6 shows that an exponentially distributed defender forces even a fully adaptive LM attacker into playing periodically — the memorylessness of the exponential makes the attacker’s feedback worthless. As the authors put it: “Paradoxically, therefore, the attacker’s strongly dominant strategy does not make use of the full knowledge the attacker gains from the feedback received during the game.”

That third point is the one worth carrying into practice. A 90-day key rotation on the first of the quarter is a periodic strategy: an adversary who has seen one rotation knows when the next is. Rotating on an exponential schedule with the same mean is strictly better against an adversary who can observe your rotations, and is not more expensive.

Uncertain — FlipIt's scope is narrower than its reputation

Verify: any claim that “FlipIt tells you your optimal key rotation period.” Reason: the 2012 article restricts itself to games where the defender plays a renewal strategy (“In this article, we restrict ourselves to games in which one of the players (the defender) plays with a renewal strategy”), and the authors explicitly leave open “Is there a strongly dominant strategy for the defender in the class of all renewal strategies against an LM attacker?” — they show experimentally that a delayed exponential beats the plain exponential, which is direct evidence that exponential is not optimal. It also assumes the resource is binary (controlled or not), that control has constant value per unit time, and that move costs are known constants. Real key rotation has none of those properties. To resolve: read the follow-up work the authors defer to, and any empirical validation of move-cost estimates — I found none in this paper.


Threat modelling: strategic reasoning that is not quite game theory

Practitioners already do something that looks like game analysis. It has three canonical forms, and each supplies a different subset of the five components — which is exactly why none of them is a game, and why they are nonetheless useful.

Attack trees are one-sided optimisation

Bruce Schneier’s attack trees (Dr. Dobb’s Journal, December 1999) put the attacker’s goal at the root and refine it downward through OR nodes (alternative means) and AND nodes (conjunctive prerequisites). Leaves carry values — Boolean (possible/impossible) or continuous (a dollar cost) — and the values propagate: “OR nodes have the value of their cheapest child; AND nodes have the value of the sum of their children.”

flowchart TB
    G["<b>Open the safe</b><br/>OR"]
    P["Pick lock"]
    L["Learn combination<br/>OR"]
    C["Cut open safe<br/><i>needs special equipment</i>"]
    I["Install improperly"]
    F["Find combination<br/>written down"]
    T["Get combination<br/>from owner — OR"]
    B["<b>Bribe — $20,000</b><br/>cheapest attack needing<br/>no special equipment"]
    Th["<b>Threaten — $60,000</b><br/>becomes cheapest once<br/>bribery is hardened to $80,000"]
    Bl["Blackmail"]
    E["Eavesdrop — AND"]
    E1["Listen to the<br/>conversation"]
    E2["Get owner to say<br/>the combination"]
    G --> P & L & C & I
    L --> F & T
    T --> B & Th & Bl & E
    E --> E1 & E2

What it shows: the structure of Schneier’s safe example — OR nodes are alternative means, the one AND node (eavesdropping) requires both children. Only the two dollar values stated in the article’s prose are shown; the remaining leaf costs live in the article’s figure images, which are not machine-readable, so they are deliberately left blank rather than guessed. The insight: an attack tree computes min over the attacker’s action set (OR nodes take the cheapest child, AND nodes take the sum) — it is a shortest-path problem, not a game. The defender never moves in it. That is also its strength: it needs no payoff function for the defender, no equilibrium concept and no rationality assumption beyond “the attacker prefers cheaper attacks.”

The countermeasure trace is the part worth copying into practice. Querying the tree for the cheapest attack requiring no special equipment returns a root cost of **80,000 — and the root falls to **60,000 − 80,000 − $20,000`, and it is realised by a different attack path. This is the only reliable way to measure “we raised the cost of attack,” and it requires re-running the whole min.

Uncertain — the safe tree's other leaf values were not read

Verify: the numeric leaf costs for picking the lock, cutting the safe open, improper installation, finding the combination written down, and the eavesdropping subtree. Reason: Schneier’s article carries them only inside Figures 1–6, which are images; the HTML text I extracted states just the 60,000 / $80,000 figures used above. An earlier draft of this diagram carried plausible-looking numbers for the other leaves — they were invented and have been removed. To resolve: read the printed Dr. Dobb’s Journal (December 1999) figures, or the corresponding figures in Secrets and Lies.

Schneier’s own worked PGP tree makes the argument that justifies the whole exercise: “breaking the RSA or IDEA encryption algorithms are not the most profitable attacks against PGP,” because keyboard sniffers, screen capture and passphrase brute-force are all far cheaper. “Increasing the key length from 1024 bits to 2048 bits is like putting an enormous stake into the ground and hoping the enemy runs right into it.” This is the single most valuable output of adversarial thinking in practice and it required no equilibrium at all — only the observation that a defender optimises the max over defences while the attacker optimises the min over attacks, and these two optimisations pick different coordinates.

Note also the honesty in Schneier’s own instructions: “there’s always the chance that you forgot about an attack, but you’ll get better with time,” and “to make this work, you must marry attack trees with knowledge about attackers. Different attackers have different levels of skill, access, risk aversion, money.” He is describing, without the vocabulary, a Bayesian game with unobservable types and an admittedly incomplete strategy space.

The kill chain is a repeated-game argument

Lockheed Martin’s intrusion kill chain (Hutchins, Cloppert & Amin; the Lockheed Martin whitepaper PDF read here carries no publication date in its text and a PDF creation timestamp of 24 October 2010 — it is conventionally cited as 2011) decomposes an intrusion into seven phases — reconnaissance, weaponization, delivery, exploitation, installation, command and control, actions on objectives — and its central claim is structural: “the adversary must progress successfully through each stage of the chain before it can achieve its desired objective; just one mitigation disrupts the chain.”

The strategically interesting part is not the seven boxes; it is the argument about repetition. The paper’s thesis is that APT actors, by definition, “attempt intrusion after intrusion, adjusting their operations based on the success or failure of each attempt,” and therefore “any repetition by the adversary is a liability that defenders must recognize and leverage.” It concludes, in direct opposition to Anderson: “This model shows, contrary to conventional wisdom, such aggressors have no inherent advantage over defenders.

flowchart LR
    subgraph ONE["One-shot view — Anderson, ACSAC 2001"]
        A1["Attacker needs<br/>ONE working bug"]
        A2["Defender must find<br/>ALL of them"]
        A3["⇒ attack is cheaper<br/>'Paddy has thermodynamics<br/>on his side'"]
        A1 --> A3
        A2 --> A3
    end
    subgraph REP["Repeated view — Hutchins, Cloppert &amp; Amin"]
        B1["Attacker must complete<br/>ALL SEVEN phases"]
        B2["Defender needs to break<br/>ANY ONE phase"]
        B3["Attacker must re-use tools<br/>and infrastructure to be economical"]
        B4["⇒ persistence is a liability;<br/>defender adapts per campaign"]
        B1 --> B4
        B2 --> B4
        B3 --> B4
    end

What it shows: two arguments about the attack/defence asymmetry that reach opposite conclusions from the same kind of reasoning. The insight: they are not actually contradictory — they are arguments about different games. Anderson quantifies the one-shot vulnerability-discovery race (the attacker needs one of a million bugs; the defender needs all of them). Hutchins et al. reason about a repeated campaign in which the attacker’s move must be a full seven-stage sequence and reuse is economically forced. The asymmetry flips because the unit of analysis changed from “a bug” to “a campaign.” Anyone who cites either as the structure of security is citing half of it. This is exactly the lesson of Iterated Games and the Shadow of the Future: repetition changes the equilibrium, and it changes it here too.

ATT&CK is an empirical strategy space, and it says so

MITRE ATT&CK is the closest thing security has to an enumerated attacker action set: tactics (short-term adversary goals), techniques and sub-techniques (means of achieving them), plus documented in-the-wild procedures. First model created September 2013, publicly released May 2015 with 96 techniques, per the design document.

What makes it a good primary source for this note is that it disclaims precisely the property a game-theoretic model would need. Three statements from the design and philosophy document:

  • “ATT&CK is not an exhaustive enumeration of attack vectors against software.”
  • “coverage of every ATT&CK technique is unrealistic … ATT&CK documents known adversary behavior and is not intended to provide a checklist of things that need to all be addressed.”
  • The content “is largely drawn from publicly reported incidents on suspected advanced persistent threat group behavior,” supplemented by offensive research — and its construction “is as much of an art as it is a science.”

That third point deserves an explicit inference: a knowledge base built from publicly reported incidents is a sample of attacks that succeeded far enough to be noticed and were then published. It is systematically missing the attacks that failed silently, the ones that succeeded and were never detected, and the ones whose victims did not disclose. As an empirical description of “what adversaries do” that is enormously valuable. As the strategy space S_attacker in a solution concept, it is a biased, non-exhaustive sample — and treating a min or an equilibrium over it as the answer imports the bias wholesale.

STRIDE and the elicitation problem

The remaining family — STRIDE (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege) and its relatives — supplies a taxonomy of threat categories per data-flow element rather than an action set or payoffs. It is a checklist that improves recall during design review. It is not, and does not claim to be, a model with a solution.

Uncertain — STRIDE's provenance and current status not verified from a primary source here

Verify: the origin, authorship and current Microsoft guidance for STRIDE (commonly attributed to Loren Kohnfelder and Praerit Garg, 1999) and the status of the Microsoft Threat Modeling Tool. Reason: I did not fetch a Microsoft primary document during this note; the acronym expansion above is standard and uncontroversial, but the historical and status claims are not sourced here. To resolve: fetch Microsoft’s current Security Development Lifecycle threat-modelling documentation and the original 1999 memo. uncertain


The limits of the analogy, taken seriously

This is the part of the note that matters. The game framing is invoked in security more than anywhere else in systems work, and it survives contact with reality less often. Seven specific failures, in rough order of how badly they break things.

flowchart TB
    subgraph REQ["What a solution concept needs"]
        R1["Enumerated S_att"]
        R2["Known u_att over S_def × S_att"]
        R3["Known attacker type"]
        R4["Payoff-maximising attacker"]
        R5["A single defender"]
    end
    subgraph REAL["What security has"]
        L1["Open-ended, growing,<br/>partly unknown action set"]
        L2["Elicited or invented numbers;<br/>no exchange rate between<br/>attacker gain and defender loss"]
        L3["Unobservable types;<br/>Bayesian version is NP-hard"]
        L4["Opportunists, automation,<br/>ideologues, bored teenagers,<br/>and states with unlimited budget"]
        L5["Principals with divergent<br/>interests; the party who can<br/>protect ≠ the party who loses"]
    end
    R1 -.->|"fails"| L1
    R2 -.->|"fails"| L2
    R3 -.->|"fails"| L3
    R4 -.->|"fails"| L4
    R5 -.->|"fails"| L5

What it shows: a component-by-component audit of the game framing against operational security. The insight: these are not five independent difficulties to be chipped away at. L1 alone is fatal to every solution concept, because min, max, argmax and “equilibrium” are all operations over a set — and if the set is wrong the operation is meaningless regardless of how carefully the rest is done. The correct response is not to abandon the framing but to demote it: use it where the domain makes the set finite, and use the vocabulary (commitment, externality, best response, dominance) as a thinking tool everywhere else.

1. You cannot enumerate the attacker’s strategy space

Every solution concept — Nash, Stackelberg, maximin, dominance, best response — is defined as an optimisation over S_attacker. Security has no such set. New techniques are invented continuously, the same technique appears at new abstraction layers (a cache side channel is not in any 2005 attack tree), and the boundary of the system itself moves (your build pipeline became part of your attack surface, which is what Software Supply Chain Threat Landscape catalogues). The most careful curated enumeration in existence, MITRE ATT&CK, says of itself that it “is not an exhaustive enumeration.”

The consequence is precise and often glossed over: an equilibrium computed over a subset of the attacker’s strategies is not an approximation of the equilibrium over the full set. Adding one attacker strategy can change the defender’s optimal mixture completely, because the defender’s best response is a max over a set that just grew. There is no continuity result to lean on. Compare Support Enumeration, where enumerating the wrong supports gives you a wrong answer, not a nearly-right one.

2. The payoffs are invented, and the conclusions follow them

Given a defender’s coverage vector and an attacker’s target, what number goes in the matrix? Someone has to choose it. In the deployed Stackelberg systems this is done by structured preference elicitation with domain experts, which is defensible and expensive. In the bulk of the literature it is done by the author. Because the solution is a max over a small set, the ranking of the payoff entries determines the answer entirely; the mathematics contributes nothing beyond making the ranking explicit.

This is not an abstract worry. The Korzhyk et al. counterexample above turned on one asymmetry — the attacker indifferent, the defender not — and flipped the optimal strategy from (6/11, 3/11, 2/11) to uniform. Change three numbers in a security game and you change the recommendation.

3. “The attacker takes the cheapest path” is an assumption, not a theorem

This is the load-bearing premise of attack trees, of threat modelling in general, and of every claim of the form “we’ve raised the cost of attack.” It is an empirical hypothesis about attacker behaviour, and it is one that Schneier himself immediately qualifies: attackers differ in “skill, access, risk aversion, money,” and “if you are worried about terrorists, you also have to worry about attackers who are willing to die to achieve their goal.”

Several concrete ways it fails:

  • Opportunistic and automated attackers do not choose a path at all. A mass scanner attacks whatever answers on port 22. It is not solving your attack tree; it is enumerating the internet. The “cheapest path” for such an attacker is a property of its target list, not of your system.
  • Cost is not the attacker’s only argument. Detection risk, attribution risk, and the propaganda value the JAIR paper cites all enter. An attacker may take an expensive path because it is quiet.
  • Attackers have sunk capability. An actor with an existing implant for platform X will use it against a target where a cheaper generic attack exists, because the marginal cost of the tool it already owns is near zero. Cost is relative to a toolkit, not to the abstract world.
  • “Raising the cost” may not reduce the attack rate at all unless the cost crosses the attacker’s threshold. A defence that takes an attack from 30k has accomplished nothing against an adversary with a 20k budget — and you generally do not know which you have.

4. Attacker types are unobservable, and modelling that properly is intractable

The honest formulation of “I don’t know who is attacking me” is a Bayesian game: a probability distribution over adversary types with different payoffs. This is what ARMOR actually does (see Stackelberg Games and Commitment). Two problems arrive together.

First, the prior is a guess. There is no frequency data that tells you the probability that your next intrusion is a criminal, a competitor, or a state.

Second, the computation goes off a cliff. Conitzer and Sandholm prove that in the Bayesian setting, computing the optimal strategy to commit to is NP-hard — Theorem 5 for pure commitment (“even when the follower has only a single type”) and Theorem 7 for mixed commitment, “even when the leader has only a single type and the follower has only two actions” (Conitzer & Sandholm, EC 2006). The non-Bayesian two-player mixed case, by contrast, is a single linear program per follower action (their Theorem 2). So the exact step you must take to be honest about uncertainty is the step that destroys tractability. Everything deployed uses a mixed-integer solver on a small instance.

5. Most of the literature is unvalidated, and this is documented

This deserves to be said plainly, with a source. Vilhelm Verendel surveyed 90 papers on quantified security published between 1981 and 2008, classifying each by security perspective, target, underlying assumptions and type of validation (Verendel, NSPW 2009). His conclusion:

The result shows how the validity of most methods is still strikingly unclear. … Quantified security is thus a weak hypothesis because a lack of validation and comparison between such methods against empirical data. Furthermore, many assumptions in formal treatments are not empirically well-supported in operational security and have been adopted from other fields.

His Table 4 is the specific indictment for our purposes. For the economic perspective — the bucket containing essentially all the game-theoretic work, and whose entries in his tables are keyword-tagged “game theory,” “zero-sum game theory,” “stochastic game theory,” “multi-parameter attack trees” — validation breaks down as empirical 16, hypothetical 31, simulation 8, theoretical 13, none 11. Hypothetical examples outnumber empirical validation roughly two to one. He tags the assumption class explicitly: RAT (rationality) appears on nearly every game-theoretic entry, and he notes that “in technical security, the degree of agent rationality has been little evaluated and remains unclear,” while evidence from other fields “suggests that this is far from obvious for decision-making in operational security.” His closing verdict: “valid quantification of security is not close but far away on the horizon.”

This survey stops at 2008 and the field has grown enormously since; the deployed Stackelberg systems post-date it. But nothing I found supersedes it as a systematic audit of validation, and the pattern it identifies — theory imported wholesale from other fields, validated against hypothetical examples — is still recognisable in the literature.

Uncertain — no post-2008 systematic validation audit was located

Verify: whether the validation picture has materially improved since Verendel’s 2009 survey. Reason: I fetched and read Verendel in full, and Herley & van Oorschot’s 2017 SoK quotes it approvingly as still-current, but I did not find a comparable systematic survey covering 2008–2026. To resolve: locate a post-2015 systematic review of empirical validation in game-theoretic security (ACM CSUR is the likely venue), and check whether the deployed-systems literature has published outcome measurements rather than deployment announcements. uncertain

6. Unfalsifiability makes the whole apparatus ratchet in one direction

Cormac Herley’s Unfalsifiability of security claims (PNAS 113(23):6415–6420, 7 June 2016) supplies the epistemological reason this field does not self-correct. The argument, in one line: things can be declared insecure by observation, but never secure, therefore any claim of the form “X is necessary for security” is empirically unfalsifiable.

Formally, define Y = {x : bad outcomes will be avoided}. Unless you commit to a time interval, a claim that an event will occur is verifiable but not falsifiable — no amount of incident-free operation proves the 6-character password safe. So Y is an untestable set: you can never observe that something is a member of it. Claims of sufficiency (X ⊂ Y) remain falsifiable — one breach refutes them. Claims of necessity (Y ⊂ X) are not, because refuting one would require exhibiting something secure that lacks X, and you cannot exhibit anything secure.

The consequence for adversarial modelling is direct: “assumptions that attackers cannot do something can never be verified … assumptions that they can do something can never be falsified” (Herley & van Oorschot, IEEE S&P 2017). Every threat model is built out of exactly such assumptions. So a threat model can accumulate adversary capabilities forever and never shed one: “newly observed or speculated attack capabilities can argue a countermeasure in, but no possible observation argues one out.” Herley’s conclusion is that “waste is inevitable, and cumulative,” and that “when justifications are unfalsifiable, deciding the relative importance of defensive measures reduces to a subjective comparison of assumptions.”

He also gives the reductio: unique 40-bit passwords across 100 accounts is a sufficient condition for breach isolation, but treating it as necessary requires a user to memorise 4,525 random bits — “equivalent to memorizing the first 1,362 places of π.” Something clearly impossible has been promoted to necessary by confusing X ⇒ Y with X ⇐ Y ninety-nine times.

Note that this cuts for the game framing as well as against it. A game model with explicit payoffs and an explicit action set at least makes its assumptions falsifiable-in-principle and comparable — which is more than “best practice” offers. The failure mode is a model whose parameters are unfalsifiable and whose conclusions are presented as derived.

7. Nobody checks the arithmetic, including in the famous papers

A small but pointed illustration, found while reading a source for this note. Anderson’s classic attack/defence asymmetry argument posits a product with 10⁶ bugs, each with mean time between failure 10⁹ hours; Paddy the attacker tests 10³ hours a year, Brian the defender benefits from “10,000,000 hours a year worth of testing.” Anderson then states: “After a year, Paddy finds a bug, while Brian has found 100,000. But the probability that Brian has found Paddy’s bug is only 10%.”

Computed here:

expected distinct bugs found in T hours ≈ 10⁶ · (1 − e^(−T/10⁹))
   Paddy,  T = 10³ :        1 bug          P(finds a given bug) = 0.0001%   ✓ matches paper
   Brian,  T = 10⁷ :    9,950 bugs         P(finds a given bug) = 0.995%    ✗ paper says 100,000 and 10%
   Brian,  T = 10⁸ :   95,163 bugs         P(finds a given bug) = 9.52%     ✓ matches paper's numbers

Brian’s two stated figures are both off by exactly 10× against the stated 10⁷ hours, and both are consistent with 10⁸ hours — an apparent typo in one of the three numbers. The qualitative conclusion is untouched: at 10⁷ hours Brian still finds only 1% of Paddy’s bugs, which is worse than the paper claims, so “Paddy has thermodynamics on his side” holds a fortiori. But the field’s most-cited quantitative asymmetry argument has an internal inconsistency that has survived twenty-five years of citation, which is itself evidence about how these numbers are used.

Uncertain — the arithmetic discrepancy is my computation, not a published erratum

Verify: the 100,000-bugs / 10% figures in Anderson 2001 §4. Reason: the inconsistency is internal to the PDF I fetched and read; I have not checked later printings, the Security Engineering book version, or the Brady–Anderson–Ball reliability paper the note defers to for “the actual statistics [which] are somewhat more complicated, involving lots of exponential sums.” It is possible the intended model is not the simple exponential one I assumed. To resolve: read Brady, Anderson & Ball, and compare against the version of this argument in Security Engineering. uncertain


Failure Modes and Gotchas

1. Assuming zero-sum because it makes the maths nice. Worked above: in the JAIR counterexample the maximin and minimax coverage vectors differ, and the zero-sum reflex costs the defender 45% of the achievable payoff. Symptom: you computed a “worst-case optimal” defence and it concentrates resource on the target that is most valuable to you, ignoring that the attacker may not care. Diagnosis: check whether u_att = −u_def entry by entry. It almost never does once attack cost enters.

2. Solving a game over a strategy space you invented, then presenting the solution as a finding. Symptom: a paper or an internal document whose conclusion (“we should invest in X”) is stated with more confidence than the payoff table it rests on. Diagnosis: perturb the payoffs by ±30% and re-solve. If the recommendation flips, the model contributed nothing the ranking of your guesses did not.

3. Confusing a threat model with a game. A threat model is a list of assumed adversary capabilities. It has no defender action set, no payoffs and no solution concept. It is a scoping artefact — genuinely valuable — and it produces no optimal anything. Calling it game-theoretic overclaims.

4. Treating “we raised the attacker’s cost” as a result. Without an estimate of the attacker’s budget and of the next-cheapest path, a cost increase on one branch is unmeasurable. Attack trees make this checkable: recompute the root after the countermeasure. Schneier’s own worked example does exactly this — bribery hardening moves the root from 60,000 because he re-ran the min over the whole tree, and the new cheapest attack is a different one (hiring thugs).

5. Deterministic “randomisation.” A patrol schedule, a key rotation, a scan window or a canary deployment that is nominally random but actually periodic is fully predictable to anyone who observes two instances. FlipIt’s Theorem 6 is the precise statement of the fix: against an adversary who learns your last move time, an exponential inter-move distribution makes his feedback worthless, whereas a periodic schedule hands him the ability to move immediately after you. Symptom: “we rotate quarterly.” Diagnosis: ask whether an observer of two rotations can predict the third.

6. Commitment you cannot actually make. The entire Stackelberg security-game apparatus assumes the defender commits to a published policy and the attacker best-responds after surveillance. If your policy is secret, the game is simultaneous and the analysis does not apply; if your operators override the schedule, the committed mixed strategy is not the one being played. See Stackelberg Games and Commitment for the failure modes of commitment itself.

7. Modelling a single defender when there are many. The Varian result is that heterogeneous defenders in a weakest-link system converge to the least motivated one’s effort level, and the situation degrades as n grows. A model with one defender and one attacker will never find this, and it is the failure mode that actually causes breaches in large organisations and open ecosystems.

8. Importing rationality assumptions without flagging them. Verendel’s survey tags them RAT precisely because they are usually implicit. Every equilibrium claim in security carries “the attacker is a payoff-maximising agent with these payoffs” as a premise; if that premise is not written next to the conclusion, the conclusion is being oversold.

9. Ratchet accumulation. Herley’s mechanism: a new speculated capability argues a control in, and nothing ever argues one out, because you cannot observe security. Symptom: a control catalogue that only grows, and prioritisation debates that reduce to whose assumptions sound more plausible. Diagnosis: for each control, ask what observation would justify removing it. If there is none, it entered on an unfalsifiable claim.


Alternatives and When to Choose Them

ApproachSuppliesMissingSolution conceptChoose it when
Attack trees (Schneier 1999)Attacker action structure, leaf costsDefender actions, payoffs, equilibriummin over AND/OR treeYou want to find where the cheap attack actually is, and to compare countermeasures by re-running the min
STRIDE / data-flow threat modellingA recall checklist per componentEverything quantitativenoneDesign review; the goal is not forgetting a category, not optimising
MITRE ATT&CKEmpirically observed technique catalogue, adversary perspectiveCompleteness, costs, payoffsnone (coverage mapping)Measuring detection coverage against observed behaviour; explicitly not a checklist to complete
Kill chainPhase structure, repetition argumentPayoffs, action setsinformal repeated-game reasoningCampaign-level defence against a persistent adversary who must re-use infrastructure
Security games / SSE (Korzhyk et al. 2011)Everything, if the domain is finiteApplicability outside bounded physical domainsStrong Stackelberg equilibrium (one LP per attacker action)Fixed target list, fixed resource count, adversary conducts surveillance. Airports, ports, flights, patrols
FlipItTiming, stealth, move costsMulti-resource, non-binary controldominance / Nash within strategy classesReasoning about rate of a repeated defensive action (rotation, refresh, re-imaging) under stealthy compromise
Security economicsReal payoffs, real players, public informationAn attacker model (deliberately)ordinary Nash / mechanism designDiagnosing why a system of organisations is insecure; designing liability, disclosure and incentive rules
Provable securityFully specified adversary class, genuinely zero-sumReal-world relevance of the modelasymptotic indistinguishabilityCryptographic primitives and protocols, where the game is real
Quantitative risk analysisA number for the boardValidation (Verendel 2009)expected lossPrioritising within a portfolio when you accept the numbers are estimates and say so

The honest ranking for most engineering work: attack trees and ATT&CK for scoping, security economics for diagnosing organisational failure, FlipIt-style reasoning for anything you do on a schedule, and full security games only if you happen to be guarding a finite list of physical things.


Production Notes

The applied successes share one property, and it is not sophistication. Every system in the Tambe-group line — ARMOR at Los Angeles International Airport (checkpoints and canine patrols), IRIS for the Federal Air Marshals Service (flights on a schedule), and the port-patrol and anti-poaching systems that followed — guards a finite, enumerable, physically bounded set of targets. That is what makes step 2 of the mental model survivable. No comparable deployment exists for “defend an enterprise network,” and the reason is not that nobody tried.

Uncertain — deployment claims for these systems are widely exaggerated and I did not re-verify them here

Verify: which of ARMOR, IRIS, PROTECT, GUARDS and PAWS were deployed versus trialled versus under development, and on what dates. Reason: this note did not fetch the deployment papers; Stackelberg Games and Commitment did, and records that ARMOR (LAX, trial from August 2007) and IRIS (FAMS) are attested in sources it read, while PROTECT and GUARDS were not deployed as of the 2011 JAIR paper — GUARDS was “being tested and evaluated” and the Coast Guard work was “under development.” Secondary retellings routinely upgrade all of these to “deployed.” To resolve: read the AAMAS deployment papers directly. uncertain

Moving target defence is the game framing applied at national scale, and it was justified in exactly these terms. The NITRD Cyber Security and Information Assurance Interagency Working Group named “Moving Target” one of three federal cybersecurity “game-change” R&D themes on 13 May 2010: mechanisms “that continually shift and change over time to increase complexity and cost for attackers,” where “the characteristics of an MT system are dynamically altered in ways that are manageable by the defender yet make the attack space appear unpredictable to the attacker,” and — the strategic claim — “MT technology changes the game by wresting the advantage from the attacker because it eliminates the availability of constant or slowly-changing vulnerability windows that allow attackers to lie in wait and conduct useful experiments on persistent vulnerabilities.” That is a description of denying the attacker the observation half of the Stackelberg structure, and FlipIt is the cleanest formal model of it. The same document is candid that the research question is unresolved: “The challenge is to demonstrate that complexity is indeed a benefit and not a liability.” As of this note (2026-08-29) I found no systematic outcome evaluation answering it.

What the framing changes in day-to-day engineering, concretely:

  • Randomise on an exponential, not a period. Key rotation, credential expiry, secret re-issue, canary scan windows and re-imaging schedules are all FlipIt moves. If an adversary can observe one, make the next one memoryless.
  • Optimise move cost, not move rate. FlipIt’s strongest result is that lowering k₀ helps “no matter how the opponent plays.” Short-lived credentials, immutable infrastructure and one-command re-imaging are the operational form of this — they are valuable because they make defensive moves cheap, which is a different argument from “they reduce the blast radius.”
  • Publish the policy, not the schedule. Commitment requires observability, so the randomisation policy should be public and the realisation secret. This is also the standard argument against security-by-obscurity, arrived at from a different direction.
  • Fix the incentive before the mechanism. If the team that would bear the cost of a control is not the team that bears the loss, no control survives contact with the budget cycle. This is Anderson’s finding and it is the best-supported result in the field.
  • Re-run the min after every countermeasure. A control that hardens one attack tree branch has accomplished nothing until you check what the new cheapest path is.

Where this connects in the vault. Consensus as a Coordination Game and The Byzantine Generals Problem are the case where the adversary model is fully specified — up to f of 3f+1 nodes, arbitrary behaviour — which is why those results are theorems and security-game results are models. Congestion Control as a Game and Rate Limiting as a Mechanism are the systems that already commit to a published policy and let users best-respond. The Price of Anarchy measures the same defender-coordination gap that Varian’s free-riding results describe. And Software Supply Chain Threat Landscape is what happens to the attacker’s action set when the system boundary moves — the concrete demonstration that S_attacker is not a fixed set.


Source hygiene for this note

Every PDF cited was checked by extracting its text and confirming the title and abstract match the filename. Routes that failed, recorded so they are not re-tried blindly: microsoft.com/en-us/research/... returned HTTP 403 for two Herley papers; pnas.org/doi/pdf/10.1073/pnas.1517797113 returned HTTP 403 (the paper was obtained from Europe PMC at europepmc.org/articles/PMC4988610?pdf=render, located via the Europe PMC REST search API); mitre.org/sites/default/files/... returned HTTP 403 while attack.mitre.org/docs/... served the same document at 200; ieee.org staging returned HTTP 418. One near-miss worth recording: guessing a PMC identifier served a completely unrelated paperPMC4988612 returns “Ecological consequences of human niche construction,” not Herley’s PNAS article, which is PMC4988610. Adjacent identifiers in the same journal issue are not adjacent papers; resolve identifiers through a search API rather than incrementing them.


See Also