Articles / A Logging Strategy That Pays Off in an Incident
Detection · Logging Strategy

A Logging Strategy That Pays Off in an Incident

There is a specific, sinking feeling in incident response: you have the attacker in your sights, you know roughly what they did, and the log that would confirm it doesn't exist — never enabled, aged out, or overwritten. A logging strategy is the work you do before that moment so it never arrives. It is not "log more"; it is deciding, in advance, which questions an investigation will need to answer and making sure the data to answer them survives until you ask.

Most logging is designed for operations — debugging a service, tracing a slow request — and then pressed into security duty during an incident, where it turns out to be missing the fields, the sources, or the retention that an investigation needs. A security logging strategy inverts the design: it starts from the investigative questions ("who authenticated as this account and from where?", "what did this process do after it launched?", "what left the network, to where?") and works backward to the sources and fields that answer them.

Retention is a security control

query during IRprotectsLog sourceshosts · apps · cloud ·identityForward off-hostas events occurCentral storeretained past dwell timeAppend-only / RBACintegrity controlsInvestigationweeks or months laterLocal log theattacker can edit ordeleteRetention shorterthan dwell time →evidence aged out
Log strategy is written for the investigation you haven't had yet.

Dwell time — how long an attacker is present before discovery — is frequently measured in weeks or months. If your high-value logs roll off after seven days, then by the time most breaches are detected, the evidence of how they began is already gone. Retention is not a storage-cost line item; it is the boundary of how far back an investigation can see. The sources that reconstruct an intrusion — authentication, process execution, network flow, cloud control-plane — need retention measured against realistic dwell time, not against last month's bill.

Why it matters: An attacker who has been in your environment for six weeks is invisible to logs that only go back one. Retention shorter than your dwell time means the beginning of every serious incident is, by design, unrecoverable.

Log integrity, or the attacker edits the record

Logs that a compromised host can alter or delete are logs an attacker will alter or delete — clearing traces is a standard step in a competent intrusion. This is why logs must be shipped off the source system, quickly, to storage the source cannot reach back into. Centralised, tamper-resistant, append-only logging is what ensures the record you investigate is the record of what happened, not the version the attacker chose to leave you.

  • Design logging around investigative questions. For each source ask: ‘what incident does this help me reconstruct?’ If there’s no answer, it’s ops logging, not security logging.
  • Ship logs off-host immediately. Anything that lives only on the machine that generated it is one attacker command away from deletion. Centralise fast.
  • Set retention against dwell time. Keep the sources that reconstruct an intrusion long enough to cover how long attackers actually stay — and tier cheaper storage so cost isn’t the reason you can’t look back.
  • Capture the fields investigations need, not just the event. A login event without the source IP, or a process event without the command line, is a headline with the story torn out.
  • Verify the pipeline end to end. Logs silently stop flowing all the time. A source everyone assumes is covered but hasn’t reported in weeks is the gap you find at the worst moment.
Test for it — in practice
  • Pick a plausible incident — a compromised admin account — and ask whether you could reconstruct the last 60 days of that account’s activity from logs you actually retain. If not, you’ve found a gap while it’s still cheap to fix.
  • Check one critical log source and confirm it’s still flowing and still complete. Silent pipeline failures are common, and ‘we thought that was logged’ is a sentence nobody wants to say mid-investigation.

Auditing whether your logging can actually answer the questions a real investigation asks — coverage, fields, retention, integrity — is the groundwork our assessment lays, so the evidence is there before you need it.

Logging is one of those investments whose value is invisible right up until the moment it is the only thing that matters. Nobody thanks you for retention policy on a quiet Tuesday; everybody needs it during the breach. Design your logging for the investigation you hope never to run, and if that day comes, the difference between a scoped, provable response and a shrug is the strategy you set months earlier. You can only investigate what you had the foresight to record.

Keep reading
SIEM and the Art of Useful Logging