incident-timeline

Incident Timeline

A timeline turns a pile of alerts into a story a responder or executive can act on. NIST SP 800-61r3 expects incident documentation of what happened, when, and how it was detected; the timeline is the backbone of that record.

Procedure

1. get_case — gather attached alerts, entities, findings, actions.
2. Pull supporting events for the key entities over the incident window (search_security_events, get_wazuh_alerts filtered by agent/user/ip).
3. Normalize every timestamp to UTC ISO 8601. A Wazuh alert's timestamp is when the manager processed the event. The original event time is in the log itself (predecoder.timestamp, or the time at the start of full_log, or data.win.system.systemTime for Windows). Use the event time when they differ by more than a few seconds, and note clock skew or delayed delivery (e.g. an agent reconnecting and flushing its buffer).
4. Order events; collapse repetitive ones ("38 sshd failures 09:02–09:12"). Wazuh composite rules summarize bursts: one rule 5763 or rule 5712 alert stands for several single failures (rules 5716, 5760, 5710), so count the underlying failures, not the composites.
5. Label each event with an ATT&CK tactic where possible.
6. Identify the key milestones and gaps.

Milestones to identify

Derived metrics:

• Dwell time = first detection − first malicious activity.
• Time to contain = containment − first detection.
• Active duration = last activity − first malicious activity.

Pivot points