Why is the protocol an attacker used usually a convenience rather than a precondition?
answer
- ask what the swap costs
- several routes, one target
- settings on their side
- cost column says cannot
- technique outlives the route
basics
~20 sA precondition is something the technique cannot run without. A protocol is normally one of several interchangeable routes to the same thing, so blocking it moves the operator to another route instead of ending the technique.
solid answer
~50 sThe test is simple: for every detail an attack used, ask what it costs the operator to use a different one. The client application, the user agent string it sends, the region the traffic comes from and the protocol it speaks are all settings on the attacker's side — minutes of work, no new capability, no new money. Those are conveniences. A precondition is a property of the thing being attacked: that a secret is accepted from whoever presents it, that an account holds a right, that a service takes input without proof. Only those are candidates for removal. So if a stolen long-lived token replays into a SaaS tenant, blocking the older access protocol it happened to arrive over removes nothing — the same token replays over the current protocol. Name what the technique consumes, not what it happened to touch.
go deeper
Be ready to define a precondition in one sentence — something the technique cannot run without — then give one example of a detail an attacker swaps for free and one they cannot swap at all.
Expect to price the swap for each thing an attack used: client, agent string, source region, protocol. Explain why the cost column turning into 'cannot' is what marks a real precondition.
Show that you apply the test before accepting any control, and that you state plainly which paths a cheap block genuinely closes and which it only delays by the time it takes to change a setting.
Own the habit across an estate: a portfolio of controls all aimed at swappable details reads as layered defence and buys very little, so require every proposed control to name the precondition it removes.
## The question behind the question When an interviewer describes an intrusion and then asks "so what control answers this?", they are testing whether you can separate two things that look identical in a write-up: **what the technique used** and **what the technique needed**. Everything the operator touched shows up the same way after the fact, so the untrained answer is to block whatever was named. That produces controls that are true, cheap, easy to approve — and worth almost nothing. ## Definitions A **precondition** is a fact that must hold or the technique cannot execute at all. Remove it and there is no degraded version of the attack; the attack is simply gone for every operator, not just the one you watched. A **convenience** is any interchangeable way of satisfying a precondition. It is on the attacker's side of the exchange, and its cost of substitution is what makes it a convenience. The **substitution test** is the one-line procedure: for each thing the technique used, ask *what does it cost this operator to use a different one?* Zero-cost swaps are conveniences. Things that cannot be swapped at any price, because they are properties of your system rather than choices of theirs, are preconditions. ## The swap ladder, priced Take a concrete case: a long-lived bearer token for a SaaS tenant, stolen and replayed by someone who never runs code on any machine of yours. | What the attack used | Cost to swap | Verdict | | --- | --- | --- | | A particular client application | a different library or a different published client | convenience | | A particular user agent string | one line of configuration | convenience | | A source region or address | the price of a proxy or a rented host | convenience | | A particular access protocol | whichever surface the tenant still exposes | convenience | | The token being accepted from whoever presents it | not the attacker's to change at all | **precondition** | The last row is qualitatively different. It is not expensive for the operator — it is *unavailable* to the operator. Only the issuer can change it. That is the signature of a real precondition: the cost column stops being a number and becomes "cannot". ## Why protocols are the classic false precondition Protocols get mistaken for preconditions more than anything else, for three reasons. First, they are the most visible thing in any account of an intrusion, because the intrusion has to travel over something. Second, blocking one is genuinely easy and produces a clean before-and-after story. Third, a real class of techniques *does* depend on a protocol's own weaknesses — an attack on how a protocol authenticates or how it negotiates really does die when the protocol is withdrawn. Because that class exists, the reasoning generalises when it should not. The discriminator is what the technique consumes. If the technique consumes a weakness *in the protocol*, the protocol is a precondition. If the technique consumes a credential, a right, or an unauthenticated entry point and the protocol was merely the pipe it came down, the protocol is a convenience — and the same technique arrives tomorrow down the pipe you kept. ## Applying it out loud A usable habit is to write one line for every control you propose: *this control removes <precondition>*. If you cannot fill the blank with something the attacker cannot substitute, you have not written a mitigation — you have written an inconvenience, and you should say so when you propose it. Inconveniences still have uses; they close the specific paths that genuinely required the thing, and they cost the operator the minutes it takes to change a setting. What they must not do is close the question. The honest form is: "withdrawing the older protocol closes the paths that can only run over it; the token replay is not one of them, and that still needs an answer." ## The failure mode this prevents A portfolio of controls each aimed at a swappable detail reads, on paper, like layered defence. In practice all of those layers share one property: the operator satisfies them from a configuration file. That is why a technique keeps recurring against an estate that has "already mitigated" it several times. Every mitigation was aimed at a convenience.
- Give me one thing an attacker genuinely cannot substitute.That a secret is accepted from whoever presents it. If a copied credential works purely because it was presented, no change of client, region or protocol matters, and nothing on the operator's side can change that property. Only the issuer can, by binding the credential to a key the thief did not get, or by making it expire quickly.
- So is withdrawing a legacy protocol worthless?No — it is worth exactly the paths that require it, and nothing beyond them. Techniques that consume a weakness in the protocol itself really do die with it. The mistake is claiming the withdrawal answers a technique whose only relationship to the protocol was that it travelled over it.
- How do you decide which side of the line something falls on?Ask who owns it. Anything named on the attacker's side of the exchange — client, agent string, source address, channel — is theirs to change for the price of a setting. Anything that is a property of your system — a right an account holds, a secret that replays, an endpoint that accepts input without proof — is yours, and only those can actually be removed.
Boarding up one door of a shop that has four unlocked ones. The burglar never needed that door; he needed the shop to be unlocked.
saying these in an interview costs you the question
- Treats every detail the attack touched as a requirement
- Says withdrawing the protocol stopped the technique
- Cannot name one thing an operator cannot swap
- Counts attacker-side settings as things you control
- Proposes a control without naming what it removes