What are the signs that an automatically generated detector is too narrow?

What makes an automatically generated detector too narrow?

A detector is too narrow when it only recognises the exact pattern it was trained or tuned on, then fails as soon as the adversary changes harmless-looking details. In practice, that means it is overfit to surface features rather than the behaviour that defines the campaign, so it gives a false sense of coverage.

Which visible signs usually expose the problem?

The clearest sign is brittle matching. If detections depend on one sender domain, one subject line template, one file name, or one exact sequence of indicator values, attackers can evade them by swapping those features cheaply. Another warning is uneven recall across variants: the detector catches a sample, then misses the same activity when the wording, infrastructure, or packaging changes.

A second sign is that the alert logic looks impressive in testing but collapses outside the seed examples. If the detector fires on lab samples, reproductions, or a short list of known indicators, but produces little signal against new instances of the same technique, it is probably recognising examples rather than the underlying malicious pattern.

Why narrow detectors fail in real campaigns

The underlying issue is generalisation. Attackers routinely vary campaign details to defeat exact matches, while preserving intent and workflow. When a detector is built around brittle clues, its precision may look acceptable on a controlled set, but its resilience is poor because the same behaviour reappears under a different wrapper.

That matters because the defender is usually trying to detect a tactic, workflow, or abuse pattern, not a single artifact. If the logic cannot survive small changes in presentation, it is not anchored to the actual security behaviour that matters. Good detectors should tolerate rotation in low-value features while still flagging the same abuse path.

How practitioners should judge and fix it

What to verify: Test the detector against rewritten subjects, alternate domains, renamed files, reordered fields, and other low-cost variations. If performance drops sharply, the rule is too dependent on presentation, not behaviour.

Common mistake: Treating high hit rates on a frozen training set as proof of quality. That often rewards memorisation of examples, especially when the detector is built from a small set of incidents or indicators.

What good looks like: The detector still fires when visible indicators change, but the attack method stays the same. It should key off stable behavioural cues, such as suspicious sequencing, abnormal access patterns, or repeated abuse steps, rather than one-off labels.

Practitioner takeaway: Narrow detectors are usually exposed by cheap attacker rotation. If a minor content rewrite breaks detection, widen the logic toward the abuse pattern and validate it against unseen variants before trusting the result.

Related resources from NHI Mgmt Group

• What are the signs that authorization testing is too narrow for real-world web applications?
• What are the signs that ATT&CK coverage is too narrow for real incidents?
• What are the signs that an LLM benchmark programme is too narrow to support enterprise decisions?
• What are the signs that ransomware detection rules are too narrow to catch simple endpoint behavior?