What underlying records should support an alert?¶
You should be able to trace an important alert back to the events that caused it to fire.
The alert is the signpost. The source records are what let you test what actually happened.
Ask for records that fit the alert¶
Different alert types need different source material.
| Alert type | Useful underlying records |
|---|---|
| Authentication | Account, result, factor, source, device, session |
| Endpoint/process | Process, parent, command line, path, hash, user |
| Network | Source, destination, ports, protocol, time, volume, DNS |
| Native message, headers, delivery, URL/attachment, mailbox events | |
| Cloud | Tenant, account, API/action, object, session and audit records |
A generic screenshot of the alert is rarely enough for a material conclusion.
Keep the detection context too¶
An alert record itself may contain:
Those links help another investigator reproduce why the alert existed.
One alert can represent many events¶
A security product may group dozens of related events into one alert.
The reverse can also happen: several alerts may all derive from the same underlying event.
That matters when you are assessing how much independent evidence really exists.
Prefer structured source data where possible¶
If the source system can export the events, that is usually more useful than relying on:
- screenshots;
- dashboard summaries;
- pasted snippets.
If export is not possible, record the limitation and how the source was viewed.
Keep event time and alert time separate¶
The underlying event may happen at 05:21.
The alert may be generated at 05:38.
An analyst may review it at 06:10.
Those are three different moments.
The practical point is: for every important alert, preserve the rule context and the source events beneath it so the activity can be independently assessed.
