Pick the logs that matter: authentication, process, network and cloud audit events, and the Windows and Linux entries defenders read most.
Why it matters
A security operations team cannot defend what it cannot see. When something goes wrong, the first questions are always the same: who logged in, from where, what ran, and what changed? Logs are the only reliable answer. Teams that collect the wrong logs (or none) discover breaches months later, usually because someone outside tells them.
Collecting everything is not the answer either. Storage costs money, noisy logs bury the signal, and a SIEM licence is often priced by volume. The skill this lesson teaches is choosing the logs that matter and knowing what a few key events look like.
The core idea: log the security story
A useful security log answers five questions about an event: who (user or service account), what (the action), where (host, source IP), when (an accurate timestamp, ideally in UTC) and outcome (success or failure). If a log source cannot answer most of these, it is less useful for detection.
Start with the sources that cover the most common attacks:
| Priority | Source | Why it matters |
|---|---|---|
| 1 | Authentication (Windows Security log, Linux auth.log/secure, identity provider sign-ins) | Stolen passwords and guessing attacks show up here first |
| 2 | Endpoint process activity (Windows 4688 or Sysmon, Linux auditd, EDR) | Shows what actually ran on a machine |
| 3 | Network boundary (firewall, VPN, DNS, proxy) | Shows who talked to whom, and callbacks to attacker servers |
| 4 | Cloud control plane (AWS CloudTrail, Azure Activity Log, Google Cloud Audit Logs) | Records every API call that changes your cloud |
| 5 | Application and server logs (web server access logs, database audit) | Shows injection attempts and data access |
Windows event IDs worth knowing
Windows writes security events to the Security log, viewable in Event Viewer or with PowerShell. A small set of event IDs covers a lot of ground:
| Event ID | Meaning | What a defender looks for |
|---|---|---|
| 4624 | Successful logon | Logons at odd hours, from new hosts, logon type 10 (RDP) from the internet |
| 4625 | Failed logon | Many failures for one account (guessing) or one failure for many accounts (spraying) |
| 4672 | Special privileges assigned to a new logon | An admin-level logon you did not expect |
| 4688 | New process created | Office apps starting PowerShell, unusual command lines |
| 4720 | User account created | Accounts created outside the normal process |
| 4732 | Member added to a security-enabled local group | Someone quietly added to Administrators |
| 4740 | Account locked out | Password guessing in progress |
| 1102 | The audit log was cleared | Attackers covering tracks; this should almost never happen |
The logon type field in 4624 and 4625 matters: type 2 is at the keyboard, type 3 is over the network (file shares), and type 10 is Remote Desktop.
Process creation (4688) is not fully useful by default: you must turn on the audit policy and the setting that includes the command line. Many teams install Microsoft's free Sysmon tool, which logs process creation (Event ID 1), network connections (Event ID 3) and more, with richer detail.
# Last 20 failed logons on this machine (run as administrator)
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625} -MaxEvents 20 |
Select-Object TimeCreated, Message
Linux authentication logs
On Debian and Ubuntu, SSH and sudo activity goes to /var/log/auth.log; on Red Hat-style systems it is /var/log/secure. On systemd systems you can also query the journal.
# Failed SSH passwords, newest last
sudo grep "Failed password" /var/log/auth.log | tail -n 5
# The same idea through the journal (the unit is "ssh" on Ubuntu, "sshd" on RHEL)
sudo journalctl -u ssh --since "1 hour ago" | grep -i "failed"
A typical line looks like this:
Oct 23 02:14:07 web01 sshd[2210]: Failed password for invalid user admin from 203.0.113.50 port 51122 ssh2
It answers who (admin, which does not exist: "invalid user"), where (203.0.113.50 against web01), when, and the outcome (failed). Thousands of these from one IP is a bot guessing passwords.
Worked example: picking logs for a small company
A 50-person company has Windows laptops, two Linux web servers, Microsoft 365 and one AWS account. The budget allows a free or open-source SIEM and a modest amount of storage. A sensible first set:
- Microsoft 365 / Entra ID sign-in logs (most attacks today start with a stolen cloud password).
- Windows Security events 4624, 4625, 4672, 4720, 4732, 4740 and 1102 from every laptop, plus Sysmon process creation.
auth.logand the web server access logs from both Linux servers.- AWS CloudTrail for the whole account.
- Firewall and DNS logs.
What they leave out at first: verbose debug logs, every successful file read, and performance counters. They can add sources later when a detection needs them.
Retention and integrity
- Keep logs long enough. Attackers often go unnoticed for weeks. Many teams keep 90 days searchable and a year or more in cheaper archive storage; regulations may require longer.
- Synchronise clocks. Use NTP everywhere and record times in UTC, or your timeline will not line up across systems.
- Ship logs off the host. An attacker with admin rights can delete local logs (that is what event 1102 records). Forwarding to a central collector protects the evidence.
- Never log secrets. Passwords, session tokens and full card numbers must not appear in logs.
Common mistakes
- Logging only successes or only failures. A burst of 4625 followed by one 4624 is the story; you need both.
- Leaving process auditing off. Without 4688 or Sysmon, you cannot tell what ran.
- Ignoring the cloud. Many incidents never touch an on-premises server.
- Collecting logs nobody reads. A log source should support a question you actually ask or an alert you actually run.
Quick recap
- Good security logs answer who, what, where, when and outcome.
- Prioritise authentication, endpoint process, network boundary and cloud audit logs.
- Know the key Windows IDs (4624, 4625, 4672, 4688, 4720, 4732, 4740, 1102) and where Linux keeps
auth.log. - Synchronise clocks, ship logs off the host, keep them long enough, and keep secrets out.