Guide · Detection engineering

Writing detection coverage evidence packs

Last reviewed:

An evidence pack turns a coverage claim into something another engineer can check. It should show the technique, the log source, the detection logic and the known limits.

Start with the claim

A coverage claim should be narrow enough to test. 'We cover credential abuse' is too broad. 'We alert when an Entra service principal adds a new credential outside approved deployment paths' is reviewable.

Write the claim in plain language first, then attach the ATT&CK technique, the cloud service, the event source and the rule or query that backs it. If any part is missing, call it a gap rather than stretching the claim.

Show the evidence chain

The evidence chain is the path from attacker behaviour to an alert a human can act on. For cloud detections that usually means an audit event, a parser, a field mapping, a rule and a triage note.

Do not bury the weak link. If the parser only covers one region or the managed finding is delayed, say so. Evidence packs are useful because they expose limits before an incident does.

  • Behaviour: what the attacker does.
  • Telemetry: where that behaviour appears.
  • Logic: how the rule catches it.
  • Triage: what the analyst should check next.

Include negative space

Good evidence packs say what they do not cover. A Sentinel rule over Entra sign-ins does not prove coverage for Azure Resource Manager changes. A GuardDuty finding does not prove every CloudTrail management event is parsed in the SIEM.

That negative space stops coverage reviews becoming sales theatre. It also gives the next engineer a clear place to improve the map.

A small template

Keep the pack short enough to maintain. A reviewer should be able to read one technique in a few minutes and decide whether the claim still holds.

Evidence pack fields text
coverage_claim: Alert on service-principal credential addition
technique: T1098.003
platform: Azure
telemetry: Entra audit logs
logic: Sentinel analytics rule
known_limits: approved CI/CD paths require suppression
review_owner: SOC content lead
Sources
  • MITRE ATT&CK data sources, https://attack.mitre.org/datasources/
  • Sigma specification, https://sigmahq.io/docs/basics/rules.html
  • Microsoft Sentinel analytics rule documentation, https://learn.microsoft.com/azure/sentinel/detect-threats-built-in
  • Splunk detection engineering guidance, https://research.splunk.com/
Last verified: 2026-05-20