What Is Strategic Threat Intelligence?

ICD 203 fixes seven terms for likelihood, running from "almost no chance" at 01-05 percent to "almost certain" at 95-99 percent. A strategic threat intelligence product that uses none of them is not an assessment. It is a newsletter.

Strategic threat intelligence is the level written for people who approve budgets and set direction. The consumer is a CISO, a risk committee, a board. The horizon is quarters to years. Nothing in it should be actionable inside an hour, because that is not the job.

Three levels, one distinction that matters

Tactical intelligence is the technical detail you write a rule from. A command line, a registry path, the artifact an indicator evidences. It expires in days to weeks and it feeds detection content. Operational intelligence is behaviour at campaign scale. A tooling shift, an intrusion chain mapped to ATT&CK. It expires in months and it feeds hunts and roadmaps. Strategic intelligence is neither.

The distinction is not the time horizon. It is the decision on the other end. If the output of a report is a firewall entry, it is tactical no matter how many pages it runs to. If the output is a headcount, a control programme or a capital request, it is strategic even at two pages.

What a strategic product contains

Four ingredients, all of them concrete.

1. Sector targeting trends. Which industries are being hit, by which clusters, and whether the mix is moving. "Regional logistics operators are being targeted through their remote access appliances" is a sector claim. "Ransomware is up" is not.

2. Adversary capability shifts. Access brokerage, edge device exploitation, movement from custom implants to living-off-the-land tooling, help desk social engineering replacing phishing as the identity entry point.

3. Regulatory and geopolitical drivers. Disclosure deadlines, sanctions changing who is targeted, conflict changing who is willing to burn access.

4. Implications for control investment. The paragraph that says what the first three mean for money.

Point four is the one most products skip, and it is the only one the consumer was reading for.

What makes one useless

Four failures, in the order we see them.

No assessment. The document summarises other people's reporting and stops. If you can delete every sentence containing "we assess" and lose nothing, there was no analysis.

No confidence statement. The reader cannot tell whether a judgment rests on three corroborating incident reports or on one vendor blog.

No recommendation tied to a decision. "Organisations should remain vigilant" costs nothing to write and buys nothing.

No falsifiability. The product never says what evidence would overturn it, so it can never be wrong, and therefore never useful.

Estimative language is the tradecraft

Two published scales are in common use and they do not agree. Say which one you are using.

ICD 203, the US Intelligence Community Directive on analytic standards, defines this ladder:

almost no chance      01 - 05 %     remote
very unlikely         05 - 20 %     highly improbable
unlikely              20 - 45 %     improbable
roughly even chance   45 - 55 %     roughly even odds
likely                55 - 80 %     probable
very likely           80 - 95 %     highly probable
almost certain(ly)    95 - 99 %     nearly certain

The FIRST CTI SIG recommends the NATO Words of Estimative Probability instead, which has five terms and different boundaries: highly unlikely under 10 percent, unlikely 10 to 40, even chance 40 to 60, likely 60 to 90, highly likely above 90. "Likely" means 55 percent under one scale and 60 percent under the other. Mixing them silently is how a report gets read as more certain than it was written.

Likelihood is not confidence. Likelihood is about the event. Confidence is about your evidence. FIRST uses the NATO levels: high means good quality information from multiple collection capabilities, moderate means credible and plausible but lacking correlation, low means fragmentary or from sources of dubious reliability.

ICD 203 has a hard rule here that almost everyone breaks. Do not put a confidence level and a likelihood term in the same sentence. Write two sentences.

Bad:  We assess with high confidence that intrusions are highly likely to shift
      toward remote access appliances.
Good: Intrusions against the sector are likely to shift toward remote access
      appliances over the next two quarters. We hold moderate confidence in this
      judgment, based on four public incident reports and no internal telemetry.

State what would change your mind

ICD 203 asks for analysis of alternatives, and specifically for products to identify indicators that, if detected, would alter judgments. This is the part that turns an assessment into something a detection team can work with, because those indicators are collection requirements.

Write them as observables, not as moods.

Assessment: Intrusions against the sector are likely to begin at internet-facing
remote access rather than at the inbox over the next two quarters.
Confidence: moderate.

Would raise the judgment:
  - A second exploited edge appliance CVE with public PoC inside 90 days
  - Access broker listings naming the sector by name rather than by geography

Would lower the judgment:
  - Phishing-delivered loaders reappearing as the dominant first stage
  - Sector-wide MFA enforcement on the VPN estate completing on schedule

Collection gap:
  - We have no visibility into the VPN concentrator logs of three subsidiaries.

That last line is worth more than most of the surrounding prose. An assessment that names its own blind spot lets the reader discount it correctly.

Worked example: a sector trend becomes a build queue

What follows is a constructed example, written the way we would write one. It is not a report on a real victim or a real incident.

Take the assessment above. On its own it is a sentence a board can nod at. Decomposed, it is a build queue. The technique is to ask, for each driver in the assessment, which ATT&CK techniques would show up in telemetry if the assessment turned out to be right, and whether we currently collect the data those techniques land in.

Eight rows, and the ordering falls out of the assessment rather than out of whoever shouted loudest. Identity techniques sit at the top because the assessment says the entry point moved there. The impact techniques at the bottom are already covered in most estates, which is exactly why they are last. That prioritisation is the whole product. Everything downstream of it is ordinary detection engineering.

The detection that comes out of it

Row four, help desk social engineering, is the one with the least existing coverage in most tenants. The base signal in Microsoft Entra ID is a security info registration event.

title: Entra ID Security Info Registered
id: 6e2a4c17-9d51-4f0b-a3c8-71b5d0e94f22
status: experimental
description: Registration of a new authentication method in Microsoft Entra ID. Intended as a correlation feed rather than a standalone alert.
references:
    - https://attack.mitre.org/techniques/T1556/006/
    - https://learn.microsoft.com/en-us/entra/architecture/security-operations-privileged-accounts
author: huntrule.com
date: 2026-07-31
tags:
    - attack.persistence
    - attack.t1098
    - attack.credential-access
    - attack.t1556.006
logsource:
    product: azure
    service: auditlogs
detection:
    selection:
        LoggedByService: 'Authentication Methods'
        Category: 'UserManagement'
        OperationName: 'User registered security info'
    condition: selection
falsepositives:
    - New starters enrolling on their first day
    - Users replacing a lost phone
    - Bulk re-enrollment after an authentication method policy change
level: informational

On its own that rule fires constantly and deserves its informational level. The detection is the pairing. An administrative password reset followed within the hour by an enrollment on the same account is the shape of a help desk takeover.

let resets =
    AuditLogs
    | where TimeGenerated > ago(30d)
    | where Category == "UserManagement" and OperationName has "Reset password"
    | extend target = tostring(TargetResources[0].userPrincipalName)
    | extend actor = tostring(InitiatedBy.user.userPrincipalName)
    | where isnotempty(actor) and actor != target
    | project resetTime = TimeGenerated, target, actor;
let enrolments =
    AuditLogs
    | where TimeGenerated > ago(30d)
    | where LoggedByService == "Authentication Methods"
    | where OperationName has "registered security info"
    | extend target = tostring(TargetResources[0].userPrincipalName)
    | project enrolTime = TimeGenerated, target, OperationName;
resets
| join kind=inner enrolments on target
| where enrolTime between (resetTime .. resetTime + 60m)
| project resetTime, enrolTime, target, actor, OperationName
| sort by enrolTime desc

We match OperationName has "Reset password" rather than an exact string because the admin-initiated and self-service activity names differ, and we did not want the query to depend on which one your tenant emits.

What it misses. An attacker who already holds the password enrolls without ever triggering a reset, and the join drops them. Help desks that issue a Temporary Access Pass instead of resetting the password produce a different audit trail, so a separate rule on TAP issuance is needed to cover that path. Resets performed by a ticketing system's service principal leave InitiatedBy.user empty and are filtered out by the isnotempty(actor) clause, which is deliberate and also a gap.

Known false positives. The legitimate version of this sequence is identical: a user loses a phone, calls the desk, gets a reset, enrolls a new authenticator. Nothing in the log separates the two. Route the output to the service desk queue for ticket verification rather than to the SOC as an alert, or you will burn the analyst rota inside a week. If the tenant has fewer than a few hundred users, the volume is low enough to verify every hit by hand.

We tested this logic against the Entra ID audit schema as documented, not against a live tenant with a red team exercise behind it.

Summary

Strategic threat intelligence is the level whose output is a budget line, not an alert. It contains sector targeting trends, adversary capability shifts, regulatory and geopolitical drivers, and an explicit statement of what those mean for control investment. It uses a published estimative scale, names which one, keeps likelihood and confidence in separate sentences, and states the indicators that would overturn it. A strategic product that a detection team cannot decompose into a prioritised technique list has not finished its job, because the prioritisation is the deliverable.

Identity rules covering the techniques above sit under identity rules in the catalog, and the MFA-specific ones under an MFA search.

Collect for the assessment above:
  Entra ID AuditLogs      Category=UserManagement, LoggedByService=Authentication Methods
  Entra ID AuditLogs      device registration and Temporary Access Pass activities
  Entra ID SigninLogs     resultType 500121 (authentication failed during strong
                          authentication request) for push bombing
  VPN concentrator        authentication success and failure, per subsidiary
  Windows Security 4688   with command line auditing enabled, or Sysmon Event ID 1