Turn a Threat Concern into a Detection Hypothesis

Turn a Threat Concern into a Detection Hypothesis

Decompose behavior, identify invariants, and write a hypothesis that evidence can support or contradict.

How you reason from behavior to observable evidence

A request such as “detect credential theft” sounds clear until you try to implement it. Credential theft is an objective, not one observable action. An attacker might capture a password, steal a browser cookie, persuade a user to approve an OAuth application, or copy a workload token. These paths share a purpose but create different evidence. If you skip that distinction, you will either write logic so broad that it says little or so narrow that its title promises more than it detects.

Begin by choosing one behavior path. Suppose you are concerned about a malicious application receiving permission to read a user’s mail. The attacker must first present a consent request, the user or administrator must grant authority, the identity provider must record the grant, and the application must later use a token to access mail. This description separates the attacker’s objective from the actions required to reach it.

Some details are easy for the attacker to change. The application name, publisher text, source address, and timing can all vary. Other properties are harder to avoid. If the application is to read mail through the legitimate service, some identity must receive authority and that authority must be used against the mail resource. A property that must remain true for the behavior to succeed, under the conditions you have stated, is an invariant. Invariants are valuable because they direct you toward behavior rather than decoration. They are never universal; an attacker may choose a different path, so you record the conditions that make the invariant hold.

You can now write a detection hypothesis. A hypothesis is a falsifiable prediction about evidence: if an application receives a new mail-reading grant and uses that delegated authority soon afterward, the identity and application audit records should reveal the grant, the client, the subject, the scopes, and the later resource access. The hypothesis is stronger than “look for suspicious consent” because it says what relationship should exist and which observation could show that it does not.

The reasoning is explored further in From Threat Model to Detection Hypothesis and Detection Invariants and Adversary-Controlled Features. Notice that neither reference gives you a magic list of fields. Field names depend on the provider and pipeline. The durable work is deciding which facts the behavior requires, which source could observe them, and which ordinary workflow could produce a similar pattern.

A benign application may receive the same scopes through an approved process. That alternative does not invalidate the hypothesis. It tells you which context the analytic or analyst will need: application ownership, approval path, tenant, requester, prior grants, and the sensitivity of the resource. Threat-informed design does not remove ambiguity. It makes ambiguity visible early enough to engineer around it.

Resources

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