Logging That Actually Helps
Detection is impossible without the right data, and the most common reason an investigation stalls is that the one log that mattered was not collected, was not detailed enough, or was sitting on a box the attacker wiped. Good logging is deliberate: decide what security events to capture, centralize them off-host where an attacker cannot erase them, and retain them long enough to investigate a breach discovered months late.
This topic builds Meridian's logging foundation — the raw material for every detection and every investigation that follows. Get it wrong and no amount of clever correlation later can recover the evidence that was never captured.
What to Log
The security-relevant events are authentication (success and failure), authorization changes, process execution, network connections, and administrative actions. Logging everything is as useless as logging nothing — it buries signal in noise and costs a fortune to store — so choose by what your detections and investigations actually need. A failed-login log with no source IP or username is nearly worthless; detail is what makes a log actionable.
Centralize Off-Host
Logs on the compromised host are evidence the attacker controls, and clearing them is a standard step (Chapter 8). Shipping logs to a central store immediately means log-clearing does not erase the record, and it makes correlation across systems possible. Off-host, access-controlled logging is what turns a per-host trickle of events into a searchable, tamper-resistant whole.
Detail, Consistency, and Time
A log that says "login failed" without the user, source IP, and timestamp is nearly useless. Structured, consistently formatted logs with synchronized clocks are what make correlation and timeline reconstruction work — and synchronized time is not optional, because a forensic timeline (Chapter 11) built from hosts whose clocks disagree is unreliable at exactly the moment it matters most.
Retention and the Long Dwell
Breaches are often found months after entry — the dwell time is long — so retention must outlast realistic discovery. Retention shorter than dwell means the logs that would explain a breach are already rotated away before anyone knows to look. Meridian's baseline ships endpoint, authentication, network-flow, and cloud audit logs to a central SIEM, with synchronized time, structured formats, and retention set to the expected dwell — the input to every detection that follows.
- Logging only on the host, so an attacker with access clears the evidence and blinds both detection and forensics.
- Logging too little (missing process execution or authentication detail) or too much (drowning signal in noise), either of which defeats detection.
- Unsynchronized clocks and inconsistent formats, making cross-system correlation and timeline reconstruction unreliable.
- Retention shorter than realistic dwell time, so the logs that would explain a breach are already rotated away.
- Leaving the central log store poorly protected, so it becomes a single juicy target.
- Log security-relevant events deliberately — authentication, process, network, admin, config changes — chosen by detection and investigation needs.
- Ship logs off-host to a central, access-controlled store immediately so they survive host compromise.
- Enforce synchronized time and structured, consistent formats so correlation and timelines are trustworthy.
- Set retention to outlast realistic dwell time, and protect the log store as a high-value asset.
- Capture the fields investigations need — source IP, user, timestamp, process — not just the event type.
Knowledge Check
Why is centralizing logs off-host essential for detection and forensics?
- An off-host copy survives attacker log-clearing
- Off-host logs simply compress better than local host logs do
- Local logs are unable to record failed login attempts
- Centralizing logs encrypts the compromised host's disk
Why does log retention need to outlast realistic dwell time?
- Breaches surface months later, past short retention
- Longer retention windows make forensic queries run faster
- Retention length changes which events actually get logged
- Old logs automatically become more detailed over time
Why is synchronized time across hosts a logging requirement, not a nicety?
- A timeline from hosts with disagreeing clocks is unreliable
- Synchronized clocks meaningfully reduce the total volume of logs
- Without time sync, logs cannot be written to disk at all
- Time synchronization encrypts each of the log entries
You got correct