How should linked events across several systems be correlated?¶
The practical answer¶
Events across several systems should be correlated using shared identifiers, timestamps, accounts, devices and the logical sequence of activity.
The key evidential caution¶
The dangerous assumption is that events close together in time must belong to the same action.
They may not.
Evidence to preserve¶
Investigators should preserve the original timestamps, time zones and clock information for every source.
Useful linking features may include:
Key points¶
- session IDs
- correlation IDs
- account identifiers
- hostnames
- IP addresses
- process IDs
- file hashes
- command text
- remote-service identifiers
- management-job IDs
Build the sequence from the evidence rather than from the expected attack story.
One system may record the request.
Another may record authentication.
A third may record process execution or file access.
Check whether clocks differ and whether events were delayed in collection or reporting.
Where a gateway, proxy or management platform sits between systems, identify the intermediary rather than treating the apparent source as the final controller.
Evidential limits¶
Do not merge separate sessions solely because they use the same account.
Shared, automated or service accounts may generate overlapping activity.
Record gaps and conflicts.
A defensible timeline may contain uncertainty rather than one continuous narrative.
Practical interpretation¶
Where several tools collect the same event, avoid counting it several times. An endpoint alert, identity alert and incident ticket may all derive from one authentication or process event.
Preserve the shared event identifiers and record which systems produced derived interpretations.
This prevents one event being overstated as several independent corroborating facts.
Operational takeaway¶
Link cross-system events through multiple identifiers and a supported sequence, and record clock differences, intermediaries and unresolved gaps.