Applied · Module 6

Logging and detection basics

Prevention is never perfect.

1.5h 3 outcomes Applied Cybersecurity

Previously

Verification and release gates

In practice, you verify three things.

This module

Logging and detection basics

Prevention is never perfect.

Next

Applied capstone

This capstone is a short design review.

Progress

Mark this module complete when you can explain it without rereading every paragraph.

Why this matters

I log what I fear.

What you will be able to do

  • 1 Explain the difference between logs, signals, and alerts
  • 2 Prioritise investigation using impact and likely attack paths
  • 3 Explain residual risk and why controls do not take risk to zero

Before you begin

  • Foundations-level vocabulary and concepts
  • Confidence with basic diagrams and section terminology

Common ways people get this wrong

  • Noisy alerts. Noise teaches people to ignore alarms. Tune until alerts mean something.
  • No evidence captured. If you do not capture evidence before changes, you lose the story of what happened.

I log what I fear. Authentication, authorisation, sensitive access, privilege changes, and unusual network patterns.

In simple terms, logs are the footprints. Monitoring is deciding which footprints matter. Response is what you do when you see them.

A log is only useful when it becomes a signal that can turn into an alert. A log line without context is trivia. A signal has enough context that a human can make a decision.

In the real world, this is triage. You see a burst of failed logins, a login from a new country, an API key used at 3am, or a privilege change followed by data export. You decide what to investigate first, and you decide what evidence to preserve.

How it fails. Alert fatigue, missing context, and no owner. Teams create rules that fire constantly, then everyone ignores the channel. Or they log everything but cannot search it. Or the person who gets paged has no permission to do anything meaningful.

How to do it well. Start with a few high value signals tied to real harm, tune them, and write a short playbook. Decide your trade offs. More alerts can catch more badness but will also burn people out. A smaller set of reliable signals often beats a thousand noisy ones.

Risk thinking joins likelihood and impact. Controls reduce one or both but add cost and friction. This is why a good risk decision is not "maximum security." It is "enough security for what we are protecting, given constraints."

Before you use the log triage tool, do not try to read every line. Try to spot the pattern and the story. Ask what changed, who did it, and what is the plausible next step for an attacker.

After you use it, check your priorities. A common mistake is chasing the weirdest looking event instead of the highest impact path. Another mistake is ignoring baseline behaviour. "Unusual" only makes sense when you know what normal looks like.

Before you use the risk trade off tool, this is about making trade offs explicit. You are practising how to talk about risk without sounding like a robot or a fortune teller.

After you use it, focus on residual risk. The common mistake is assuming one control takes risk to zero. Another mistake is ignoring cost and usability until users bypass the control. Good controls reduce harm without breaking the business.

Mental model

Detection loop

Detection is a loop: collect signals, decide, act, and learn from outcomes.

  1. 1

    Events

  2. 2

    Signals

  3. 3

    Alert

  4. 4

    Action

  5. 5

    Learn

Assumptions to keep in mind

  • Signals map to behaviour. A good alert points to a behaviour you can act on, not a vague fear.
  • A runbook exists. If nobody knows what to do, an alert becomes stress instead of safety.

Failure modes to notice

  • Noisy alerts. Noise teaches people to ignore alarms. Tune until alerts mean something.
  • No evidence captured. If you do not capture evidence before changes, you lose the story of what happened.

Key terms

log
record of what happened
signal
something that indicates risk
alert
actionable notification to a human or system

Check yourself

Quick check. Logging and risk

0 of 7 opened

Scenario. You see 200 failed logins followed by one success, then a password reset and a data export. What should you investigate first

The account takeover path. Confirm the login source, check whether MFA was bypassed, and preserve evidence around the reset and export.

Why log authentication and authorisation events

They reveal misuse of accounts and changes to access.

What makes a good signal

It is reliable, contextual, and actionable without drowning people in noise.

Why do too many alerts hurt

Alert fatigue hides real incidents because people start to ignore them.

How does likelihood differ from impact

Likelihood is how often it may happen. Impact is how bad it is when it does.

What is residual risk

The risk that remains after controls are applied.

Who owns responding to alerts

A named person or team so responsibility is clear.

Artefact and reflection

Artefact

A short list of high value signals for one system

Reflection

Where in your work would explain the difference between logs, signals, and alerts change a decision, and what evidence would make you trust that change?

Optional practice

Scan a realistic log snippet, tag interesting events, and practice deciding what to investigate first.

Also in this module

Play with risk trade offs

Adjust likelihood, impact and control strength to see residual risk change.

Source NIST Cybersecurity Framework (CSF) 2.0 (2024)
Source OWASP Top 10 (2025)
Source OWASP ASVS 5.0.0
Source ISO/IEC 27001:2022 Information security management systems