Monitoring, Logs and Threat Detection

Prevention eventually fails: a password gets phished, a laptop misses an update, a vendor is compromised. Detection is how you find out in minutes or hours instead of months, while the damage is still small. It rests on two things: logs, the records systems keep of what happened, and someone or something watching them for signs of trouble. This lesson covers what to log, which signals matter most, how to triage alerts efficiently and how a Milwaukee manufacturer went from ignoring 1,200 alerts a week to acting on the ones that counted.

1. Decide what to log
2. Centralize and keep logs
3. Know the warning signs
4. Triage alerts
5. Measure and tune

Why logs matter

Logs serve three purposes. They detect (an alert fires when something suspicious happens), they investigate (after an incident, logs show how the attacker got in, what they touched and when), and they prove (to an insurer, a regulator or a client, logs show what was and wasn't accessed). Without logs, a breach investigation often can't rule anything out, which can turn a small incident into a large notification.

What to log

You don't need to log everything. Start with the events that matter most for detecting the attacks from earlier lessons:

Two practical rules make logs trustworthy. First, synchronize clocks on every system (NTP, port 123 from lesson 6): if timestamps disagree by minutes, reconstructing an attack becomes guesswork. Second, centralize and protect logs by sending them to a separate system attackers can't easily erase, and keep them long enough to investigate. CISA's #StopRansomware Guide recommends centralizing logs and retaining critical system logs for at least one year where possible. Check your cloud plan: some entry-level plans keep audit logs for a short time unless you upgrade or export them.

Detection tools: from built-in to managed

Detection methods fall into three groups: signatures match known bad files or patterns; behavioral or anomaly detection flags activity that's unusual for a user or system (like a login at 3 a.m. from another continent); and threat intelligence matches indicators such as known malicious domains. Security teams often map their detections to MITRE ATT&CK, a public knowledge base of adversary tactics and techniques that gives defenders a common language for what they can and can't see.

Warning signs worth investigating

These signals catch a large share of real attacks against small and mid-size organizations, and most cloud platforms can alert on them out of the box:

Others worth an alert: repeated MFA prompts (MFA fatigue), security tools being disabled, logins to dormant accounts, large uploads to unfamiliar cloud storage and changes to vendor bank details.

Triage: handling an alert in five steps

1. ReceiveAcknowledge and timestampNote when the alert arrived and who's handling it, so nothing falls through the cracks.
2. ValidateCheck the contextIs the user traveling? Is there a change ticket? Did IT schedule maintenance? Ask the user through a known channel.
3. ScopeLook around itOther alerts for the same user or device? Same activity elsewhere? What data could be involved?
4. DecideClose, monitor or escalateFalse positive: close with a note. Unclear: monitor. Likely malicious: escalate to incident response (lesson 14).
5. ImproveDocument and tuneRecord the outcome and adjust the rule if it fires too often for harmless reasons.

Metrics that keep detection honest

Precision = true positives ÷ total alerts
MTTD (mean time to detect) = average time from start of incident to detection
MTTR (mean time to respond) = average time from detection to containment

Low precision means analysts spend most of their time on noise, which leads to alert fatigue: people start ignoring alerts, including the real ones.

Case: a Milwaukee manufacturer tunes its alerts

The calculation: 36 ÷ 1,200 = 3% before and 36 ÷ 180 = 20% after. Review time went from 1,200 × 3 = 3,600 minutes (60 hours) to 180 × 3 = 540 minutes (9 hours). Tuning didn't hide real threats; it removed predictable noise so people could see them.

Common mistakes

Summary

• Logs let you detect, investigate and prove what happened; start with identity, email, endpoints, firewall, DNS and cloud audit logs.
• Synchronize clocks, centralize logs and keep critical ones for at least a year where possible.
• Built-in alerts are the starting point; EDR, SIEM and MDR add depth as you grow.
• Impossible travel, new inbox rules, new admins and mass file changes are high-value warning signs.
• Triage in five steps and track precision, MTTD and MTTR; tune rules to fight alert fatigue.

Next lesson: Incident Response, Step by Step. You'll learn the incident response lifecycle, what to do in the first hour and which U.S. reporting deadlines may apply.