17.1 What Logs, Events, and Alerts Tell Defenders
Three Different Objects, Often Confused
A log is a continuous stream written by a system: the Linux syslog daemon appends facility-and-severity lines such as auth, cron, or kern at levels from emerg down to debug. An event is one timestamped row extracted from that stream: Windows writes structured records keyed by event ID, where 4624 means a successful logon, 4625 a failed logon, 4688 a process creation, 7045 a new service install, and 1102 the audit log was cleared. An alert is not data at all -- it is a decision. Something compared events against a rule or model and decided a human should look now. Mixing these up is the most common beginner mistake: more logging never produces better security unless something turns rows into decisions.
What a Row Actually Carries
Every useful row has five anchors: a timestamp, a source identity (host, user, process, or interface), an object acted on (file, account, port, registry key), an action verb, and an outcome. Missing any one of them makes the row nearly uninvestigatable, which is why defenders care about configuration as much as coverage. An 4688 event that records only the process ID but not the command line cannot tell you whether powershell.exe ran a benign inventory script or a base64-encoded downloader. Clock skew is the quiet killer of this model: if hosts drift by minutes, the ordering of "failed logon then success then new service" collapses, and correlation engines produce nonsense.
From Rows to Signals
Raw sources -- operating system, network gear, applications -- are noisy on their own. A single workstation can emit tens of thousands of rows a day, of which an adversary-relevant handful exist. Correlation is what compresses that funnel: patterns across time (five 4625 events then a 4624 in sixty seconds), across hosts (one account authenticating in two countries ten minutes apart), or against a baseline (a server that never writes to /tmp suddenly doing so). Because correlation is probabilistic, alerts arrive with a false-positive tail; a defender's real inventory is the ratio of confirmed incidents to tickets, not ticket volume.
Retention Decides What You Can Ever Know
Intrusions are routinely discovered weeks after the first event, so retention window is a detection capability. Keep the fields you will pivot on longest -- auth, process, network flow metadata -- and shrink verbose payload logs faster. Preserve a tamper-evident copy before acting, because attackers with privilege routinely clear event logs (that 1102 event) or delete the very syslog file you are reading.
Architecture Diagram
Key Takeaways
- Logs are streams, events are single timestamped rows, and alerts are decisions made about rows.
- Know your platform's high-value event IDs: 4624, 4625, 4688, 7045, and 1102 on Windows; auth, cron, and kern facilities in syslog.
- A row needs timestamp, source, object, action, and outcome plus synchronized clocks to be usable.
- Correlation across time, hosts, and baselines is what converts thousands of rows into a few real alerts.
- Judge monitoring by confirmed-incident yield and retention depth, not by alert count or log volume.