What underlying records should support an alert?¶

An alert should be traced back to the records that caused it to be generated.

Avoid the dangerous assumption¶

The dangerous assumption is that the alert contains all the evidence needed to understand the event.

It often does not.

For an authentication alert, request sign-in events, account identifiers, device information, session data, source addresses, authentication method and result.

For an endpoint alert, request process creation, command line, parent process, file path, file hash, user context, network connections and product action.

For a network alert, request source and destination details, ports, protocol, timing, volume, DNS data and the device or process involved where available.

For an email alert, request the original message, headers, delivery records, URL analysis, attachment information and mailbox actions.

For a cloud alert, request audit events, tenant and object identifiers, account actions, application or API use and relevant session information.

Also obtain the alert identifier, rule name and version, time zone, event time and alert-generation time, severity and confidence, analyst notes, resolution or closure reason and details of containment already performed.

Preserve the original export where possible. Screenshots may omit fields or surrounding events.

Check whether the alert grouped several events together. One alert may represent many related records, or several alerts may derive from one underlying event.

The purpose is to understand what actually happened, not merely why the product was concerned.

Where the product cannot export the underlying data, record that limitation and obtain the fullest available technical explanation of how the alert was produced.

Operational takeaway¶

Request the source events, identifiers, rule logic and analyst reasoning beneath each alert so the recorded activity can be independently assessed.