From Threat Model to Detection Hypothesis

A threat model gives you possibilities, not a detection

A threat model may tell you that an attacker could abuse OAuth consent to read a user’s mail. That statement is useful because it identifies an asset, a trust relationship, and a potential consequence. It is not yet a detection. Consent can be granted through several paths, mail can be accessed through several interfaces, and ordinary applications may request the same permissions.

Choose one path. An attacker presents a consent request, a user grants delegated mail-reading authority, the identity service records the grant, and the application later uses that authority against the mail service. By describing the path in verbs and relationships, you separate the objective from the actions required to reach it.

The path is still a model. It may omit a provider-specific shortcut or assume logging that does not exist. Treat it as a reasoned representation of how the behavior could occur, not as a transcript of a future incident. Detection design begins when you ask which parts of that path create observable state and which observation point can see them.

Find the behavior the attacker cannot omit

Details such as application name, source address, browser string, and timing are often cheap for an attacker to change. The grant and later use of authority are harder to remove if the chosen path is to succeed through the legitimate service. A property that must remain true under stated conditions is an invariant.

Invariants are conditional. If the attacker chooses stolen credentials instead of malicious consent, the grant disappears from the path. If the provider exposes no resource-access audit, later token use may be unobservable. You should write those conditions beside the invariant so it does not become a universal claim.

Now identify the observation points. The identity provider may record the actor, application, scopes, grant type, tenant, and time. The mail service may record the application, subject, operation, resource, and outcome. The detection depends on relating two producers whose identifiers and clocks may not align. That dependency belongs in the hypothesis rather than being discovered after implementation.

Write a prediction that evidence can challenge

A useful hypothesis might say: “If a previously unapproved application receives delegated mail-reading authority and uses it soon afterward, identity and mail audit records should show the same tenant, application, subject, granted scopes, and subsequent resource access.” The statement predicts a relationship. It also creates ways to be wrong.

The application may have been approved through a process the detection does not know. The mail event may identify a service principal rather than the consented client. Records may arrive outside the selected window. An administrator may grant authority on behalf of a user. Each contradiction tells you whether the hypothesis needs a narrower scope, another source, different entity resolution, or a distinct analytic.

Avoid adding intent to the prediction. Audit records can show authority granted and used. They do not directly show that the user was deceived or that the application operator intended harm. Those are assessments built from additional evidence. Keeping intent out of the observable claim makes the later judgment more defensible.

Competing explanations shape the evidence you need

A hypothesis becomes stronger when you ask what ordinary process could create the same pattern. A newly deployed backup application may receive mail access and begin using it immediately. An administrator may replace an application after an outage. A user may approve a legitimate productivity tool without following the preferred process.

These alternatives do not mean the analytic should ignore the behavior. They tell you which context changes its meaning: application ownership, approval record, publisher verification, grant initiator, prior tenant history, resource sensitivity, and expected deployment time. Context should be as-of the event where possible. Today’s approved owner can misrepresent an application that was unapproved when the grant occurred.

You can now turn the hypothesis into a detection requirement. The requirement names the consumer and response, defines evidence semantics and timing, describes alternative explanations, and sets acceptance criteria. The hypothesis is the reasoning kernel inside that broader operational promise.

Preserve what the result does and does not establish

When the analytic matches, report the observations before the assessment. State that an application received named scopes and accessed a resource under the same subject and tenant within the measured interval. Then state the assessment: the sequence is inconsistent with the known approval path and warrants review. Finally state uncertainty: ownership records may be incomplete, and the audit sources do not establish how the user understood the consent request.

This structure prevents the title from becoming stronger than the evidence. “Malicious OAuth application detected” would collapse fact, assessment, and attribution. “New mail-reading grant followed by use outside the known approval path” tells the consumer what changed and why attention is justified.

A hypothesis should also have review triggers. Provider semantics, identifier formats, audit latency, consent policy, and application inventory can all change. When they do, the prediction may no longer be testable in the same way. A living hypothesis records those dependencies so adaptation changes the reasoning openly instead of silently changing only the query.