If you can read the attacker’s mind, you can already build a rule for it. So a detection rule worth keeping is one the attacker cannot read.

The failure mode I see most often is not “we have no detection.” It’s that the detection fires on the exact events the adversary planned for. An attacker who wants to move through your network without being seen is going to look at your monitoring, understand what you watch, and make sure they produce the expected events at the expected volume. If your only rule is “more than 10 failed logins in 5 minutes,” they don’t brute-force. They reuse a credential. Your rule is fine. It just detects what everyone, including the attacker, knows happens first.

This is the problem with most detection catalogs: they encode the first mile of an attack — the noisy, low-risk, easily-suppressed opening moves — and they treat that as coverage.

The first mile is the attacker’s choice

Every intrusion has a shape. I like to break it into three stretches:

First mile. The attacker enters. Initial access is the cheapest, most variable, and most noisy part of any attack. Phishing, credential stuffing, an exposed RDP box, a zero-day, a forgotten API key. The attacker can — and often does — make this stretch as quiet or as loud as they want, because it’s the part they control most.

Middle mile. The attacker operates. Lateral movement, data staging, privilege escalation, persistence. This is where the interesting behavior lives — and where they’re most careful.

Last mile. The attacker exits or acts. Exfiltration, destruction, ransom, or the long quiet of a data-residence campaign. This is where the intrusion is forced to behave differently from normal traffic, because it has to move volume, change state, or cross a boundary it normally doesn’t.

Most rule sets concentrate on the first mile. That’s where the easy signals are. And that’s exactly why it’s the least reliable place to build a detection program — the first mile is where the attacker has the most latitude to be normal.

What “the attacker already knows” actually means

A rule alerts on “the attacker already knows” when the event it matches is a precondition of the attack, not a consequence. Ask the question: would the attacker have to generate this event to succeed, or could they succeed without it?

  • failed_login > 10 — the attacker doesn’t need a burst of failures. Slow it down and they’re invisible. Precondition. Easy to avoid.
  • user.login from new country — the attacker can wait, or burn a cheap throwaway credential. Precondition. Easy to avoid.
  • powershell -enc / base64 blob — the attacker can drop a native binary or use a framework with clean output. Signature. Easy to avoid.
  • data_export rows_affected > 100000 — the attacker can pull in small chunks over hours. Precondition. Easy to avoid by patience.

These rules detect the attempts that are cheap and noisy. They are not worthless — they catch the sloppy attacker. But they are the part of the attack the adversary can afford to be sloppy about, because it’s cheap and it’s first.

The rules that survive an adversary are the ones tied to something the attacker cannot suppress without breaking the objective:

  • Exfiltration has to move bytes across a boundary. Volume is a physical constraint, not a preference.
  • Credential theft has to produce a valid, long-lived identity that works where they want it.
  • Ransomware has to rewrite your files. The filesystem will show it.
  • A persistence mechanism has to survive a restart. That means it has to stay.

The last mile is where physics, state, and boundaries conspire against the attacker. Design there.

Anatomy of a durable rule

A detection that survives contact with a real adversary has four parts. Miss any of them and you either get noise or you get blind.

1. An invariant, not an anomaly.

The strongest detections are built on a property that is always true of normal operation and false of the attack. “This endpoint never returns > 100KB, so > 1MB is not noise, it’s the attack.” “No service account writes to the audit bucket, so a write there is not a spike, it’s the attack.” Invariants beat thresholds. A threshold is a guess at normal. An invariant is a fact about your system that the attack must violate.

2. A scope you can defend.

data_export is not a detection until you know whose exports are normal, where they go, and how much is routine. A rule without scope is a rule about the internet. Scope is what turns “large export” into “large export from a role that never exports to that destination.”

3. A time model that respects the attacker.

Attackers are patient. A single 5-minute window is a first-mile artifact. The last mile often spans hours or days: a small exfil trickle, a persistence that waits for a reboot, a data-residence hold before the theft. Give your rule a horizon long enough that patience becomes the detection instead of the evasion.

4. A negative control that proves you would have caught the your attack.

This is the part most teams skip. A rule you have never fired on a real or staged attack is a hypothesis, not a control. Run the attack yourself — or a faithful subset — and confirm the rule fires at the volume and time the attacker would use, not at the volume you tested. If your staging exfil is 10GB in a minute and your rule catches that, it doesn’t tell you anything about a 10GB-in-three-days exfil.

The anti-noise feedback loop

The real enemy of detection is not the attacker. It’s the alert that gets dismissed. Every false positive you tolerate trains the analyst to ignore the next one — including the true one. So the discipline is a loop, not a rule:

Fire → Triage → Verify → Tune → Repeat.

Concretely:

  • Every rule ships with a “why this is real” one-liner. If you can’t state why this specific pattern is not routine, it’s a noise generator in disguise.
  • Every rule has a kill criterion. “If this fires more than N times a week and fewer than M are real, we retune or retire it.” A rule you keep tuning forever to stay useful is a rule that never was useful.
  • Triage output feeds the rule, not just the ticket. When an alert is dismissed, the dismissal is data. It tells you the invariant was wrong, the scope was too wide, or the time window was too short. Feed that back.
  • Retire rules that stop catching. The detection catalog is not sacred. A rule that catches nothing new for a quarter is a candidate for retirement, not a trophy.

The teams that get detection right treat the rule set the way you’d treat a portfolio: rebalanced, measured, and pruned. Not a museum.

What “good enough” looks like

You do not need a rule for every MITRE ATT&CK technique. You need coverage of the last miles that matter for your business. Map it from the objective backward:

  1. What is the attacker trying to take or break? (the crown jewels, the ability to operate, the data you can’t afford to lose)
  2. What must be true of the system for the attack to succeed? (bytes must move, state must change, an identity must persist, a boundary must be crossed)
  3. What is the last-mile event that is hardest for the attacker to suppress? (that’s your rule)
  4. Can you stage it and confirm the rule fires at the attacker’s pace? (if not, it’s not done)

Four questions. Four answers. That’s the whole program.

The trap: coverage theater

The most dangerous state is having a lot of rules and few durable ones. A detection catalog of 800 rules where 790 are first-mile signatures and thresholds gives the illusion of coverage while the last mile — the part that determines whether you lose the data or the business — is thin.

Count your rules. Then ask how many are built on invariants you could defend, scoped to what actually matters, given a time horizon the attacker would respect, and proven by a staged attack at the right pace. That number — not 800 — is your real coverage.

Trade-offs

Designing for the last mile has costs. Invariant-based rules require you to actually know your system — the “this never happens” claim is only as good as your understanding of normal operation, and that understanding decays as you change things. Time-window rules over hours or days are slower to alert than a 5-minute threshold, so you trade speed for robustness. And staged-attack validation costs time your team may not want to spend on a rule that “should” work.

All three costs are worth paying for the rules that matter and not worth paying for every rule. That’s the whole point: concentrate the rigor on the last mile, and accept that the first mile can stay cheap and noisy.

The takeaway

Build your detection where the attacker has no choice. The first mile is the part they control; the last mile is the part the attack itself forces. Alert on invariants, not guesses. Scope everything. Give it the time the attacker will take. And prove it by running the attack.

Your coverage is not the number of rules you have. It’s the number you could defend under pressure.

Further Reading