Log Correlation and SIEM in Forensic Investigations

A SIEM ingests data through agents installed on endpoints and servers, through syslog receivers that collect network device logs, through API connectors that pull from cloud services, and through direct database queries against application logs. Each source sends a stream of events in its own format. The SIEM's parsing layer converts each event into a normalised record using a data model that assigns vendor-specific fields to standard field names: a Windows Security Event Log field called SubjectUserName and a Linux PAM log field called USER are both mapped to a single user field in the SIEM schema.

After normalisation, correlation rules execute continuously against the incoming event stream. A rule specifies a pattern: for example, five or more failed authentication events on the same account within sixty seconds, followed by a successful authentication from a different IP address. When the pattern matches, the rule fires an alert. The alert groups the contributing events so that an analyst can review the raw underlying log lines rather than only the summary.

Timestamp accuracy is a recurring problem. Network devices, servers, and endpoints may have clock drift or use different time zones. Most SIEMs record both the original log timestamp and the time the event was received by the SIEM collector. Investigators must understand which timestamp appears in a query result and whether the SIEM has performed any time normalisation. A one-hour difference caused by a misconfigured time zone can place an event on the wrong side of a critical threshold in an incident timeline.

During an active incident, the SIEM serves as the first triage surface. The responder searches for indicators of compromise (IoCs) from threat intelligence feeds or initial findings, and the SIEM returns events matching those indicators across all ingested sources. This allows rapid scoping: which systems communicated with a known malicious IP, which accounts were active during a suspicious window, which files were accessed by a compromised user account.

Common queries during active response include: authentication events for a compromised account across all systems; outbound connections to external IPs in a specific CIDR block; process creation events containing a known malicious command string; and data volume anomalies on file servers or email gateways that may indicate exfiltration. The SIEM's ability to search across sources simultaneously reduces the time this scoping takes from days to minutes in a well-configured deployment.

The SIEM alert history is itself an evidence source. If the SIEM fired an alert related to the incident two weeks before the incident was formally declared, that alert record shows when the pattern was detectable. If the alert was dismissed or suppressed, the dismissal log shows who made that decision and when. This information is relevant both to incident attribution and to organisational accountability.

Post-event review differs from active response in its objective. Active response seeks to stop the attack and limit damage. Post-event forensic review seeks to establish exactly what happened: the initial access vector, the sequence of lateral movement, the data accessed or exfiltrated, and the timeline from first compromise to containment. The SIEM is the primary data source for building this timeline when raw logs have already been aggregated into it.

The investigator typically begins with the known compromise endpoint and works backward and outward. Starting from the account or host confirmed as compromised, the analyst searches for all activity associated with that entity in the SIEM, then identifies other entities that entity contacted, and repeats the process until the blast radius is fully mapped. This pivot-and-expand technique is more systematic than hunting through individual log files on each system separately.

Post-event review also examines what the SIEM did not detect. If the attacker used a technique that does not match any correlation rule, the events will appear in the raw log data but will not have generated an alert. Identifying these detection gaps informs both the investigation (the events are still present and searchable) and the organisation's security posture improvement (the correlation rules need updating). This gap analysis requires access to raw log data, not only to SIEM alerts.

Preserving SIEM evidence for legal proceedings requires more care than copying a result set from the SIEM's user interface. The first principle is that a SIEM export is a derivative of the original log data; the original log files on the source systems are the primary evidence. Wherever possible, collect raw logs from original sources alongside the SIEM export. If the SIEM is the only surviving copy because the source system has been rebuilt, document that fact explicitly.

The export process should produce a file in a documented, non-proprietary format where possible, commonly CSV, JSON, or a standard log format. Hash the export (SHA-256 is the current standard in most jurisdictions) immediately after collection and record the hash. Store the export on write-protected media or in a locked cloud storage location with access logging. Document who performed the collection, when, what query was used, what time range was covered, and what version of the SIEM software was running.

Admissibility rules vary by jurisdiction. Under India's Bharatiya Sakshya Adhiniyam 2023, electronic records must be accompanied by a certificate from a responsible official attesting to the system's operation, the manner of production, and the absence of tampering. US federal rules of evidence treat computer-generated records as business records subject to foundation requirements about the reliability of the system that produced them. UK PACE codes require that electronic evidence be handled in a manner that does not alter the data. EU GDPR adds a complication: personal data in logs may need to be pseudonymised before disclosure to third parties, which must be done without altering the evidential core of the record.

Log retention is governed by a combination of compliance requirements, storage economics, and operational policy. Common frameworks specify minimum retention periods: the US HIPAA Security Rule requires audit logs be retained for six years; PCI DSS requires one year with three months immediately available; the EU's NIS2 Directive requires records sufficient to support incident investigation without specifying an explicit duration; India's CERT-In directions (April 2022) require ICT infrastructure logs to be retained for 180 days within India. These are minimums, and many organisations do not exceed them.

The forensic problem is that sophisticated attackers often maintain persistence for months before being detected. A 90-day retention window means that the initial access, which may have occurred 120 days before discovery, is no longer in the SIEM. In these cases, investigators must look for secondary indicators: configuration changes that persist in system state, attacker-created accounts still present in Active Directory, malware artefacts on endpoints, or outbound connections recorded in firewall flow data which may have its own separate retention.

Investigators should map retention windows at the start of every investigation and prioritise collection of the shortest-retention sources first. DNS logs and endpoint process logs are frequently the first to age out. Waiting until forensic imaging is complete before asking about log retention has caused critical evidence to be lost in multiple documented incidents.

A SIEM is only as good as its data sources. Coverage gaps are the most significant limitation. A SIEM that does not ingest endpoint detection and response (EDR) telemetry will not show process creation, file access, or registry changes. One that does not ingest cloud access logs will miss lateral movement through SaaS platforms. Investigators must audit SIEM coverage at the start of an investigation and document which sources are not represented.

Normalisation artefacts are a second limitation. When the SIEM parser maps a vendor-specific field to its schema, it may truncate long strings, drop fields that do not fit the schema, or misparse structured data embedded in log messages. The normalised event may omit the exact command-line argument or URL path that is evidentially significant. When a specific log line is important, retrieve the raw original from the source system rather than relying on the SIEM's normalised version.

Alert fatigue affects the evidential value of the alert history. In large environments, SIEM platforms may generate thousands of alerts per day. Security operations teams apply suppression rules to reduce noise, and individual analysts dismiss alerts they assess as false positives. If the attacker's activity matched a real correlation rule but the alert was suppressed or dismissed, the alert record shows the detection happened but was not acted on. This information is forensically significant but also operationally sensitive.