Logs

Introduction

A user says "I cannot log in." A server admin says "the application stopped responding." A security analyst says "we got an alert showing suspicious authentication activity." A network engineer says "the firewall allowed the traffic, but the application says it never received the request." Every one of these investigations eventually comes down to logs — records created by operating systems, applications, network devices, cloud platforms, security products, databases, authentication systems, APIs, and nearly every other enterprise technology.

A good IT professional learns to move beyond opening a log file and searching for the word ERROR. You need to understand what generated the log, when the event occurred, which system recorded it, which user or service was involved, which session or transaction it belonged to, what happened immediately before and after it, whether other systems recorded the same event, and whether the timestamp can actually be trusted. Log analysis is therefore partly technical knowledge and partly investigative reasoning — and this module is built to teach both.

Learning Objectives

By the end of this module (all 6 lessons), you should be able to explain why logs matter across IT support, sysadmin, networking, IAM, SOC and incident response; read logs methodically instead of scanning line by line; correlate related events across multiple systems using correlation/request/session IDs; handle timestamps correctly, including UTC, ISO 8601, clock drift and Unix epoch time; investigate authentication logs and recognise password spraying vs brute force; navigate Windows Event Viewer/Sysmon and Linux syslog/journalctl; read application, network, cloud and database logs; explain what a SIEM does and why log retention and integrity matter; and apply a professional, repeatable investigation method to build an incident timeline from raw evidence.

1📋 Why Logs Matter

Logs are used across almost every IT discipline. IT Support uses them to investigate application crashes, failed installs, authentication problems, connectivity failures, and configuration issues. Systems Administration investigates Windows service failures, Linux daemon errors, scheduled task failures, resource exhaustion, and account activity. Network Engineering investigates firewall traffic, VPN connections, routing problems, DNS queries, DHCP assignments, and proxy activity. IAM investigates login attempts, MFA challenges, SSO/federation failures, token issuance, and provisioning. Security Operations uses logs to detect compromised accounts, malware, lateral movement, privilege escalation and data exfiltration (Module 11 covers this in depth). Incident Response uses logs to reconstruct a timeline (Module 12):

09:01 User received phishing email
09:04 User clicked malicious URL
09:06 Browser downloaded payload
09:07 PowerShell executed
09:08 Endpoint security generated alert
09:09 Attacker authenticated to another server
09:13 New administrator account created
09:20 Large file transfer started

No single log source usually contains the complete story — the investigator builds the story by correlating multiple logs, which is the single skill this whole module is really about.

2📜 What Is a Log?

A log is simply a recorded event. A very simple one: 2026-08-30 09:14:21 INFO User login successful. A better one carries more context:

2026-08-30T09:14:21.432Z
INFO
user=john.smith
source_ip=192.168.10.24
session_id=7f3a81c2
event=LOGIN_SUCCESS

Modern applications increasingly use structured logging like JSON:

{
  "timestamp": "2026-08-30T09:14:21.432Z",
  "level": "INFO",
  "event": "LOGIN_SUCCESS",
  "username": "john.smith",
  "source_ip": "192.168.10.24",
  "session_id": "7f3a81c2"
}

Structured logs are especially useful because SIEM and monitoring platforms can extract individual fields cleanly, rather than having to parse loose text.

3🏷️ Log Levels

Most useful logs share common fields — a timestamp, and a log level indicating severity: TRACE (extremely detailed, usually only enabled during active troubleshooting), DEBUG (technical diagnostic detail, e.g. DEBUG OAuth token validation started), INFO (normal activity, e.g. INFO User john.smith logged in successfully), WARN (something unexpected happened but the application continued, e.g. WARN Authentication server response exceeded 3000ms), ERROR (an operation failed, e.g. ERROR Database connection failed), and FATAL/CRITICAL (a serious failure that may stop the system entirely).

A common mistake is assuming every incident must contain an ERROR. Many important security events show up as perfectly valid INFO entries — INFO Administrator account created successfully has nothing technically wrong with it, but if an attacker created that account, it's one of the most important lines in the entire log.

📚 Lessons in This Module

Work through these in order — each builds on ideas from the last. Every lesson has its own "Mark lesson complete" button; your progress across all six is tracked below.