// networking basics — module 11

Module 11 — Logging, Telemetry & Evidence

Soren Brumbach · · 7 min read

Thesis: Both tracks revolve around what systems record. Attackers want to avoid or erase it; defenders want to collect and read it. Before the split, understand what gets logged, where it lives, and in what form — the raw material of detection and forensics. Security is often the art of finding the meaningful record in a mountain of noise.

Prerequisite: Module 10 — Scripting & Automation: Bash, Python, and Regex (you'll parse logs with exactly those skills), and Module 8 — Operating Systems Under a Security Lens: Linux & Windows (you know where Linux and Windows keep their logs).

11.1 The core idea

Nearly everything a system does can leave a record: a login, a process starting, a network connection, a file being read, a privilege being used. Collectively these records are telemetry — the observable evidence of activity. The catch is volume: a busy system generates millions of log lines, almost all of them boring. So the real skill is not "collect logs" (that's easy) but finding the one meaningful record in the mountain of noise — which is why the parsing skills from Module 10 are the other half of this module. Detection, investigation, and even measuring the success or failure of an attack all come down to telemetry.

11.2 Where logs live

You met most of these homes in Module 8; here they are as a defender's map:

  • Linux — plaintext files under /var/log, the syslog system that routes them, and the systemd journal read with journalctl (Linux Module 7). Key files: auth.log/secure (authentication), syslog/messages (general).
  • Windows — the Event Logs (Security, System, Application channels) via Event Viewer, addressed by Event ID (4624 successful logon, 4625 failed logon, 4688 process creation…). PowerShell (Get-WinEvent) queries them programmatically.
  • Applications keep their own — web servers and reverse proxies (Module 6) log every request; databases log queries and errors.
  • Network devices and firewalls log connections, allows, and denies — the network-level counterpart to host logs.

The lesson: telemetry is scattered across hosts, applications, and network gear, in different places and formats — which is exactly the problem centralization (§11.5) solves.

11.3 Log formats

Logs come in several shapes, and the shape determines how easily you can parse them (Module 10):

  • Plaintext lines — human-readable, loosely structured (Jul 12 10:33:01 host sshd[123]: Failed password for root from 10.0.0.9). Readable, but you parse it with regex.
  • Key-value — user=alice action=login result=fail; easier to split on =.
  • JSON — fully structured ({"user":"alice","action":"login","result":"fail"}); trivial to parse programmatically (Module 10's json.loads) and query precisely. Modern logging trends toward JSON for exactly this reason.
  • CSV — tabular rows; easy to load into spreadsheets or scripts.

Structured formats (JSON, CSV) are far easier to parse and search than free-form text — which is why mature telemetry pipelines prefer them. When you get to choose, structured wins.

11.4 What's worth logging for security

Not all telemetry is equally useful. The events that matter most for security — the ones a defender ensures are captured and an attacker knows they'll trip:

  • Authentication events — logons, failures, lockouts (Module 9's whole battleground; the single richest source).
  • Process creation — what programs ran, with what command line and parent (catches malware and living-off-the-land abuse of tools like PowerShell).
  • Network connections — what talked to what (ties back to Modules 2–5; catches C2 and exfiltration).
  • Privilege changes — escalations, new admins, group changes (catches an attacker gaining power).
  • File access — reads/writes to sensitive data (catches collection and theft).

If you can log only a few things, log these. They're where attacks show up.

11.5 Centralization — the SIEM concept

One host's logs are useful; but an attack moves across hosts, and no single machine sees the whole story (and a compromised host's local logs can be tampered with). The answer is centralization: ship logs from everywhere into one system so you can search across the entire environment at once. That system is a SIEM (Security Information and Event Management).

   host logs ──┐
   Windows  ──┤
   firewall ──┼──►  [ SIEM ]  ──►  search everything at once,
   web/proxy──┤                    correlate across sources, alert
   network  ──┘

A SIEM does three things: collect (ingest telemetry from many sources), correlate (connect related events — a failed-login burst here followed by a success there), and alert (fire when patterns match detection rules). It's introduced here conceptually; it becomes central on the blue side after the split. The key insight now: centralization is what turns scattered, per-host noise into a searchable whole — and it also puts logs somewhere an attacker on a single host can't easily erase.

11.6 Time matters

Reconstructing an incident means putting events in the right order — and that's impossible if the clocks disagree. Three things:

  • Timestamps — every record is anchored in time; they're how you build a timeline.
  • Time zones — logs from different systems may be in different zones (or UTC); normalize before comparing, or you'll misorder events by hours.
  • Clock synchronization (NTP) — machines sync their clocks over NTP so their timestamps are comparable. If two hosts' clocks drift apart, correlating "the attacker went from A to B" becomes guesswork. Synchronized clocks are a quiet prerequisite for all of incident response.

11.7 Evidence handling at a glance

Sometimes logs and captures aren't just telemetry — they're evidence, potentially for legal proceedings. The idea to carry forward: evidence must be trustworthy and unaltered, which is where Module 7's hashing returns. Hashing a captured file or log and recording the digest proves it hasn't changed since collection (integrity). The formal discipline — chain of custody, who handled evidence and when — belongs to forensics, but know now that "is this record trustworthy and intact?" is a real question, and hashing is the tool that answers it.

11.8 → Red/Blue

Same event streams, opposite goals. Red teams study logging to understand what they'll trip and how loud they'll be — which is why techniques exist to run quietly, clear logs, or blend into normal activity (and why "did the target notice?" is measured in their telemetry). Blue teams collect, centralize, and mine that same telemetry to catch the intrusion — building detections on the security-relevant events of §11.4, correlating across sources in a SIEM, and reconstructing the timeline afterward. Both sides are reading the same records; one tries to stay out of them, the other lives in them. The parsing skills from Module 10 are how either side actually works with the data.

Lab 11

Use your lab (Linux box and Windows VM). Bring your Module 10 skills.

  1. Hunt failed logins on Linux. Use journalctl (or read /var/log/auth.log) with grep to find every failed login in the last day. Then count them by source IP with a Module 10 pipeline (grep ... | grep -oE '<ip regex>' | sort | uniq -c | sort -rn). Which IP tried the most?

  2. Find the Windows equivalent. On the Windows VM, locate a failed logon in the Security log and confirm its Event ID (4625). Then find a successful one (4624). Note how the same concept (§11.4 authentication events) lives in a totally different store than Linux's.

  3. Parse a sample log by type. Take a sample log file and, using Module 10, extract and count events by type (e.g., group by action or status and tally). If you have a JSON-formatted log, parse it in Python; if plaintext, use regex.

  4. Prove why clocks matter. Write a short explanation: given two machines whose clocks differ by five minutes, describe concretely how that corrupts your reconstruction of "the attacker moved from host A to host B." Then check whether your lab machines are NTP-synced.

  5. Integrity with hashing. Take a log file, sha256sum it, then append one line and hash again — watch the digest change completely (Module 7's avalanche effect). Explain how recording the original hash proves later tampering.

✅ Mastery Check — do not proceed until true

Answer out loud, without notes:

  1. Why is "collecting logs" the easy part and "finding the meaningful record" the real skill?
  2. Where do authentication logs live on Linux and on Windows? Name the tool for each.
  3. Why are structured log formats (JSON/CSV) easier to work with than free-form text?
  4. Name the five categories of security-relevant events and why each matters.
  5. What is a SIEM, what three things does it do, and what problem does centralization solve that per-host logging can't?
  6. Why do synchronized clocks matter for incident response? What syncs them?
  7. When logs are evidence, how does hashing (Module 7) help, and what question does it answer?

And perform cold:

  • On Linux, find and count failed logins by source IP in one pipeline.
  • On Windows, find a failed logon by Event ID in the Security log.

When all of that is effortless: Module 12 — Threats, Vulnerabilities & the Frameworks That Organize Them