CSA study materials
CSA study resources

CSA (EC-Council Certifications): Log Retention Gap After a Breach Discovery

CSA · Put your knowledge to work in context.

All case studies

Log Retention Gap After a Breach Discovery

During an investigation, the team learns a web server was compromised 47 days ago. Its OS audit logs are retained for 30 days locally, then shipped to a SIEM where the index retention is 90 days. However, the SIEM ingestion pipeline dropped events from that host for an 11-day window three weeks ago due to a parsing error (the error was fixed but the raw events were not re-ingested). The web server's application logs are retained for 14 days on disk. Firewall logs are retained for 90 days. The incident commander needs a timeline of attacker activity from day 0 to discovery.

1. Map what timeline coverage the team can actually achieve and where the gaps are.

Read the worked answer

Coverage is a patchwork, not a continuous record:

  • OS audit logs, days 0–30: present locally (before local rotation). Days 31–47 exist only in the SIEM if ingested.
  • SIEM index, days 0–90: the intended long record, but the 11-day parsing gap three weeks ago (~days 26–37) means those events are missing from the index unless the raw source still has them.
  • Application logs, days 33–47: only the last 14 days survive on disk; days 0–32 are gone.
  • Firewall logs, days 0–90: full coverage of network connections, which can partially reconstruct activity the host logs lost.

The honest timeline is: strong host detail for the last ~2 weeks (app logs), strong host detail for the first 30 days (local OS logs, if not yet rotated past), a hole in the SIEM for the 11-day parsing window, and firewall-level network evidence throughout.

2. What should the analyst do first to recover the 11-day gap, and what is the fallback?

Read the worked answer

First, check whether the raw events still exist anywhere upstream of the parser - the original log shipper buffer, a raw/landing index, or the web server's own local files if that window falls within the 30-day local retention. If raw events exist, re-ingest them into a separate index and re-parse, then document the recovery. If they are gone, the fallback is reconstruction from firewall logs (connection records to and from the host), proxy logs, authentication logs from other systems the attacker touched, and any EDR telemetry that is retained longer than the SIEM. The timeline should explicitly mark the 11-day window as "no direct host evidence - reconstructed from network data," so downstream readers know the confidence level. Do not silently interpolate.

3. What process failure does this expose, and what control would prevent recurrence?

Read the worked answer

The parsing error was fixed but the dropped events were never backfilled - a silent data-loss path with no detection. The control is ingestion health monitoring: alert when a known-active source stops producing events or when parse-failure rate exceeds a threshold, plus a documented backfill procedure that runs whenever a parser is corrected. Retention policy should also be revisited: a 30-day local / 90-day SIEM split is fine only if the pipeline is reliable, and the investigation just proved it was not for 11 days. A retention decision without an integrity check on the pipeline is a false sense of coverage.