Write Requirements and Make Honest Coverage Claims

Write Requirements and Make Honest Coverage Claims

Define the consumer, evidence, timing, tests, and limits before claiming that a behavior is covered.

From a useful hypothesis to an accountable detection promise

Once you have a hypothesis, the temptation is to write a query. Resist it for a little longer. A query is one implementation of a detection requirement, and you do not yet have a complete requirement until you know who will use the result and what decision it must support.

Imagine that the application-consent pattern from the previous lesson reaches an analyst. Should the analyst revoke the grant immediately, contact the user, inspect later access, or merely add risk to the identity? Each decision demands different evidence and allows a different delay. Revocation may require high confidence and proof that the application is unauthorized. Investigation can begin with weaker evidence, provided the alert makes that uncertainty clear. The consumer and decision latency therefore shape what the detection must observe and how quickly it must arrive.

A useful specification connects the behavior claim to its scope, evidence, logic, output, tests, owner, and retirement conditions. The Detection Requirement Specification explains those elements in detail. They are not administrative decoration. If the specification does not name the tenant and identity types in scope, a later dashboard may imply coverage of environments the analytic never sees. If it does not state that token-use evidence may arrive thirty minutes late, a five-minute correlation window may create silent false negatives.

MITRE ATT&CK helps you organize the threat knowledge behind the requirement. In the current defensive model, a technique describes adversary behavior, a Detection Strategy describes a defensive approach, an Analytic describes platform-relevant evidence and logic, and Data Components describe kinds of information. MITRE ATT&CK v19: Detection Strategies and Analytics explains this defensive structure, while Migrating from ATT&CK Data Sources to Data Components explains why older source labels do not map mechanically to the newer evidence model. These objects can sharpen your thinking, but they do not know whether your organization collects the evidence, maps the fields correctly, or can act on the result. An ATT&CK mapping is therefore a statement of relevance, not proof of local capability.

Coverage becomes meaningful only when you bound it. Instead of claiming “Account Manipulation is covered,” you might say that a named version detects newly granted mail-reading authority for production users in the primary tenant when identity and mail audit feeds are healthy, and that tests covered interactive user consent but not administrator bulk grants. That sentence is less impressive on a heat map and much more useful in an incident.

The distinction is developed in Why ATT&CK Technique Coverage Is Not Detection Coverage. A tested state says representative evidence produced the expected result. A partial state names what remains outside scope. An unknown state admits that a mapping or query exists without adequate proof. A degraded state tells consumers that a dependency no longer supports the previous claim.

Good requirements make those states possible because they preserve the reasoning behind the implementation. When the provider changes its audit schema or the organization adopts a new tenant, you can return to the requirement and ask whether the claim still holds. Without it, you are left with a query whose original assumptions have disappeared.

Resources

• MITRE ATT&CK v19.2 — Primary reference for the standards and concepts discussed in this lesson.