Analyst Field Guide · Logging & Evidence
Logs are a system's memory — the record of what happened when you weren't watching. Detection rules run on them, incident responders reconstruct from them, and investigations stand or fall on them. But a log is only as useful as it is complete, synchronized, and unaltered. This guide is how to think about what to log, how to make separate logs tell one story, and how to treat that record as evidence rather than trivia.
Logging is a pipeline; evidence is what survives it intact. A log entry is written, forwarded, stored, and eventually read — and at every hop it can be dropped, delayed, truncated, or expired. The detection engineer's rules (see the Detection Engineering guide) and the incident responder's timeline both consume this record, so its gaps become their blind spots. Two skills run through this guide: making the record complete and correlatable in the first place, and handling it so it holds up as evidence later.
Almost everything else in security operations depends on logs. Detections fire on them, alerts are triaged with them, incidents are reconstructed from them, and disputes are settled by them. The blunt operational truth: if an event wasn't logged (or the log didn't survive), then for your purposes it may as well not have happened — you cannot investigate what you cannot see.
This mirrors the packet-capture guide's core caution in a different medium: absence of a log entry is not proof the event didn't occur — it may only mean it wasn't logged, wasn't forwarded, or has aged out. Logs tell you what you did record; be precise about the rest.
Different sources answer different questions, and no single one sees the whole picture. Knowing which source holds which answer is half of investigation speed.
| Source | What it's good for · its blind spot |
|---|---|
| Endpoint (Windows Event Log, Sysmon, EDR) | Process creation, logons, file and registry changes on the host. Blind to what never touched that host, and to activity the attacker cleared (§8). |
| Identity (AD, IdP, auth logs) | Who authenticated, from where, success or failure — the authN/authZ record (see the Identity guide). Blind to what the account did after logging in. |
| Network (firewall, DNS, proxy, NetFlow) | Connections, name lookups, and flows between hosts. Sees metadata even when payloads are encrypted; blind to on-host detail and to intra-segment traffic it never sees. |
| Application / cloud (web, API, CloudTrail-style) | Business actions and control-plane changes — who created a key, changed a policy, exported data. Blind to the OS and network layers beneath. |
Before asking "is this rule noisy?" ask "do I even log the thing it needs?" A detection is only as good as its data source (a point the Detection Engineering guide leans on), and the most common reason an investigation stalls is not a bad query — it's a source that was never collected. Map your sources to the activity you need to see, and treat the gaps as known risks, not surprises.
A usable event answers five questions — who, what, when, where, and with what outcome — and does so in a form a machine can parse. Free text a human can read but a parser can't is only half evidence.
This is why modern logging favors structured formats. Syslog's current form (RFC 5424, which replaced the older BSD syslog of RFC 3164) added precise, timezone-aware timestamps and a structured-data section for exactly this reason; JSON and key=value logs serve the same goal — records a parser can turn into fields, not prose it has to guess at.
Time is what lets separate logs become one story. When you line up an auth log, an endpoint log, and a firewall log to reconstruct an incident, the timestamp is the join key — and if the clocks disagree, the story is wrong even when every individual log is right.
Three rules keep time trustworthy. Log in UTC — timezones and daylight-saving shifts turn correlation into guesswork; store UTC and localize only for display. Synchronize with NTP — hosts drift, and a server minutes off will place its events in the wrong order relative to others, manufacturing false causation or hiding real sequence. Use a precise, unambiguous format — ISO 8601 with sub-second precision and an explicit offset (the profile in RFC 3339), so 2026-07-01T14:23:07.412Z means one exact instant everywhere. This isn't only good practice; PCI DSS v4.0.1 makes time synchronization an explicit requirement (10.6). The residual risk to keep in mind: NTP itself can be wrong or spoofed, and an attacker with host control can alter timestamps — so record your time source, and treat a log whose clock you can't vouch for as a weaker witness.
When you can't fully trust a source's clock, note the skew and correlate on relative order and independent anchors (a shared event seen by two systems) rather than absolute times. A documented "this host ran ~4 minutes fast" is worth far more than silently trusting a wrong timestamp.
No single log shows an attack; the sequence across logs does. Correlation joins events from different sources — by time, user, host, and IP — into a timeline that reveals what a single source can't.
A word of caution that ties to the Critical Thinking guide: correlation shows sequence, not necessarily cause. Two events close in time may be coincidence, and a convincing chain can still be built from misread fields. Treat a correlated timeline as a strong hypothesis to verify against more evidence, not a proven narrative.
The moment a log might support a consequential finding — an incident, a dispute, a legal matter — it stops being operational data and becomes evidence, and how you handle it decides whether it will hold up. Two disciplines apply: preserve the volatile before it vanishes, and protect integrity so you can show it's unaltered.
To show a log is unaltered, record a cryptographic hash (e.g. SHA-256) of the file at collection and work only on copies; anyone can later re-hash to confirm the bytes match. Be precise about the claim: a matching hash proves the file hasn't changed since you hashed it — it says nothing about whether the log was complete, or whether the events were genuine before collection. Append-only or WORM storage and a documented chain of custody (who held it, when, per RFC 3227) raise the bar against tampering; the residual is that a sufficiently privileged attacker, or one who acted before collection, can still have shaped what the log contains. Integrity controls constrain specific tampering threats; they do not make a log true.
Retention is a balance between the cost of storing logs and the cost of not having them when an old breach surfaces — and it's often set by compliance rather than left to preference. Since breaches routinely go undetected for months, "keep it long enough to investigate late" is the governing logic.
| Driver | What it means in practice |
|---|---|
| Compliance minimums | Regulations set floors. As a concrete example, PCI DSS v4.0.1 Requirement 10.5.1 requires retaining audit logs for at least 12 months, with the most recent 3 months immediately available. Other frameworks (HIPAA, SOX, sector rules) differ — cite the specific version that applies to you. |
| Hot vs cold tiers | Recent logs stay "hot" (indexed, query-fast) for active work; older logs move to cheaper "cold" archive. The PCI split (3 months available, 12 months retained) is exactly this pattern. |
| Detection window | Dwell time is often months, so short retention can delete the very logs an investigation needs. Retention shorter than realistic detection time is a self-inflicted blind spot. |
| Legal hold | When litigation or an investigation is anticipated, normal deletion must be suspended for the relevant data. A legal hold overrides the retention schedule. |
| Cost & privacy | Logs cost storage and can contain sensitive data, so retaining everything forever is neither cheap nor safe. Retention is deliberate scoping, not "keep it all." |
For high-level program guidance, NIST's log-management material applies: SP 800-92 (2006) is the published guide, and a Revision 1 ("Cybersecurity Log Management Planning Guide") has been circulating as a draft — check its current status before citing it as final. Framework revisions move, so verify the version and control number in force for your environment rather than trusting a remembered figure.
Logs fail as evidence in predictable ways. Knowing the failure modes lets you design around them and, just as importantly, keeps you from over-trusting a record.
| Failure | What it does |
|---|---|
| Coverage gaps | A source was never collected, so the activity simply isn't in the record. The most common reason an investigation dead-ends (§2). |
| Tampering / log clearing | Attackers delete or wipe logs to hide their tracks (ATT&CK Indicator Removal, T1070; clearing the Windows Security log raises event 1102). A missing log can itself be the signal — if you're watching for the clear. |
| Clock skew | Unsynchronized time misorders events across sources, breaking correlation and fabricating or hiding causation (§4). |
| Volume & noise | Logging everything buries the useful entries and overruns storage and ingest, which in turn causes silent drops. More logging is not more visibility. |
| Log injection | Unsanitized user input written into logs can forge or corrupt entries, or attack whatever parses them later. Treat log content as untrusted data. |
| Missing fields | An event with no user, no source, or no id can't be attributed, joined, or de-duplicated — present but not usable (§3). |
| Retention expiry | The event was logged, but aged out before anyone looked. Silent, and indistinguishable later from never having happened (§7). |
A gap, a cleared log, an unforwarded source, and an expired archive all produce the same thing: nothing to see. That is not evidence the event didn't happen — only that it isn't in your record. State findings in terms of what the logs do show, flag where coverage is missing, and treat a suspicious silence (an unexpectedly empty log, a cleared event trail) as something to investigate, not to wave away.
A logging program turns scattered log files into a dependable record. The goal is not maximum logging — it's the right logs, centralized, correlatable, protected, and watched for their own failures.
None of this makes an environment "well-logged" in the abstract. It reduces specific risks — missed activity, lost correlation, tampered evidence, undetected blind spots — each of which you can name and check. Coverage you haven't verified is coverage you don't have.
| Belief | Reality |
|---|---|
| "If it's not in the logs, it didn't happen" | It may not have been logged, forwarded, or retained — or it was cleared. Absence is not proof (§1, §8). |
| "Log everything, just in case" | Volume buries signal, overruns storage, causes silent drops, and expands the sensitive-data footprint. Log deliberately (§8, §9). |
| "The timestamp is the time it happened" | Only if the clock was synced and trustworthy. Skew and timezone errors misorder events and break correlation (§4). |
| "A hash means the log is trustworthy" | A hash proves the file hasn't changed since hashing — not that it was complete or the events genuine before collection (§6). |
| "Logs on the server are safe evidence" | An attacker who owns the host can alter or clear them. Forward off-host and protect the logging plane (§8, §9). |
| "We're compliant, so our logging is fine" | Compliance sets a floor, not a guarantee. Retention minimums and required fields don't ensure you logged the source your next investigation needs (§7). |
Sources → collect → store → analyze, with a retention branch. Every hop can lose data; a gap is a blind spot. Logging = moving records; evidence = a record preserved intact.
Who · what · when · where · outcome, plus a correlation id — structured (RFC 5424 syslog / JSON / key=value), not free text. Missing a field degrades it: no time = unsequenceable, no user = unattributable.
Log in UTC, sync with NTP, use ISO 8601 / RFC 3339. Time is the join key; join sources on user/host/IP/time to build the timeline. Correlation shows sequence, not proven cause.
Collect most-volatile first (RFC 3227: memory before disk). Hash at collection, work on copies, keep chain of custody. A hash proves "unchanged since hashed," not "complete or genuine." Retention: e.g. PCI DSS v4.0.1 10.5.1 — 12 months, 3 readily available.
Absence is not proof — a gap, a cleared log (T1070 / event 1102), or an expired archive all look like "nothing." State what the logs show, flag missing coverage, forward off-host, and monitor for logging failures (PCI 10.7).
Standards and figures verified this session and flagged to re-check against the primary source before you rely on them. Syslog: RFC 5424 (The Syslog Protocol, 2009, Standards Track) obsoletes RFC 3164 (BSD syslog) and adds structured data and precise, timezone-aware timestamps. Evidence handling: RFC 3227 (Guidelines for Evidence Collection and Archiving, BCP 55, 2002) defines the order of volatility and chain-of-custody guidance. Timestamps: ISO 8601 with the RFC 3339 internet profile (confirm the RFC number if citing it formally). Retention: PCI DSS v4.0.1, Requirement 10.5.1 (retain audit logs at least 12 months, most recent 3 months readily available), with 10.6 (time synchronization) and 10.7 (detect logging/security-control failures) — verify the version and control numbers that apply to you, as PCI DSS revises. NIST SP 800-92 (Guide to Computer Security Log Management, 2006) is the published version; SP 800-92 Revision 1 (Cybersecurity Log Management Planning Guide) has been circulating as a draft (initial public draft 2023, informed by OMB M-21-31) and should be confirmed as draft or final before citing. Windows event references (successful logon 4624, failed logon 4625, process creation 4688, Security log cleared 1102) and ATT&CK technique T1070 (Indicator Removal) reference stable but version-specific identifiers — confirm against Microsoft and the current ATT&CK matrix. No integrity control or retention setting described here makes logs "secure" or "true": each addresses a specific threat (tampering, loss, misordering, blind spots) and leaves specific residuals (privileged or pre-collection manipulation, sources never collected, clocks that can't be vouched for). Companion to Detection Engineering (logs are the data detections run on), Incident Response (reconstructing the timeline), Reading a Packet Capture (another bounded evidence source; absence is not proof), Identity & Authentication (auth logs), and Attack Taxonomy (T1070 and adversary log tampering).