Events, alerts, incidents and the lifecycle

Why this matters

SOC Analyst Foundations stopped where an incident starts: an alert fired, you worked it, and you found a successful login from a brute-force source with quiet changes left behind. The next question is not "what does this mean" — it is "what do we do now, in what order, without making it worse." That is incident response, and the first hours decide whether the case can be explained and cleaned up, or whether evidence is destroyed and the intruder simply comes back.

This course walks the whole lifecycle on one synthetic host, soc01. A brute force has already succeeded on it and the intruder left persistence behind — a scheduled job, a systemd timer, an extra SSH key, a tampered script. Everything on the machine is synthetic and inert: the payload never connects, the keys are not usable, the "web shell" cannot run. You will declare, scope, preserve, contain, eradicate, recover, report and review — the same loop you would run in a real company, on data that is safe by construction.

Concepts

Event, adverse event, incident — three different words. NIST defines an *event* as any observable occurrence involving computing assets — a login attempt, a software update, a request. An *adverse event* is one with a negative consequence. A *cybersecurity incident* is a determination: an occurrence that actually or imminently jeopardises the confidentiality, integrity or availability of information or a system, or violates security policy. Most adverse events never become incidents. Declaring one is a judgement made from evidence, and it usually starts obligations — notification, containment authority, sometimes a legal clock.

The lifecycle, as NIST describes it today. The current revision, NIST SP 800-61 Rev. 3 (April 2025), replaces the older four-phase circle (preparation; detection and analysis; containment, eradication and recovery; post-incident activity) with a model built on the six Cybersecurity Framework (CSF) 2.0 Functions:

        Govern (GV) · Identify (ID) · Protect (PR)     <- preparation: broader risk management
        --------------------------------------------
        Detect (DE) · Respond (RS) · Recover (RC)       <- the incident response itself
        --------------------------------------------
        Improvement (ID.IM)  <- lessons learned feed back into every function, continuously

Read it as: *Govern, Identify and Protect* prepare the ground (they are not the response itself); *Detect, Respond and Recover* are the response; and *Improvement* runs continuously, feeding lessons back the moment they are learned, not only at the end. The older four phases still map cleanly onto it — "detection & analysis" is Detect plus the improvement category, "containment, eradication & recovery" is Respond plus Recover — so if your organisation uses the four-phase language, you are describing the same work. This course uses the practised order: declare, scope, reconstruct, preserve, contain, eradicate, recover, report, review.

Severity and confidence are two different numbers. *Severity* is how much it would matter if the worst supported reading is true. *Confidence* is how strongly the evidence supports that reading. They move independently — evidence changes confidence, not severity. "A password authentication succeeded from the brute-force source" is high severity and, before you look at what the session did, moderate confidence. Merge them into one field and you either cry wolf or sit on something serious. Record both, with a reason for each.

Declaration is a commitment. When you declare an incident you are telling the organisation to spend people and, sometimes, to start notification clocks. Under-declaring hides a real incident; over-declaring burns trust. The declaration memo is the record: the decision, the severity, the confidence, the authority behind it, and the evidence it rests on — written before the investigation runs away with you.

Guided exercise

You are the on-call responder. soc01 is your lab machine; you sign in as analyst and you have sudo. Three services matter as *context*: nginx serves a small site (a legitimate service you must not break), and the intruder's traces live in scheduled jobs, a systemd timer and SSH keys.

1. Confirm the workstation is up. The one service you must keep alive all incident is nginx.

1. Create your workspace and note the time. Every observation needs a defensible UTC time.

mkdir -p ~/ir/case
date -u +"%Y-%m-%dT%H:%M:%SZ"

1. Read a normal day first. Generate a known-good baseline bundle with the course generator (the same one from ULC-006, staged at ~/ir/generate_events.py). Reading normal is what makes abnormal visible.

cd ~/ir
python3 generate_events.py --scenario baseline --seed 4213 --out baseline --quiet

1. Generate the case bundle. The alert that reached you: *"ssh-auth-failure-burst on soc01."* The collected evidence for the case is the persistence scenario at the same seed.

python3 generate_events.py --scenario persistence --seed 4213 --out bundle --quiet
cd bundle && jq -r '.files[] | "\(.sha256)  \(.path)"' manifest.json | sha256sum -c --quiet && echo BUNDLE_OK

BUNDLE_OK

1. Diff the day. One command shows what the suspect day added over a quiet one:

diff -rq ~/ir/baseline/collected ~/ir/bundle/collected

Only in /home/analyst/ir/bundle/collected/etc/cron.d: ubuntu-motd-refresh
Only in /home/analyst/ir/bundle/collected/etc: systemd
Files .../root/.ssh/authorized_keys differ
Files .../home/deploy/.ssh/authorized_keys differ

A cron entry, a systemd directory and two changed key files appear on the suspect day. That is enough to decide this is an incident.

1. Write the declaration memo. Open ~/ir/templates/declaration-and-severity.md for the field list, then write ~/ir/case/declaration.md with the labelled lines: Decision:, Severity:, Confidence:, Authority:, Summary: and Basis:. Declare it an incident, choose a severity from the matrix (a real account authenticated, so this is at least SEV-2), and state a confidence with a reason. Keep the basis to observations, not conclusions.

Troubleshooting

Symptom → python3: can't open file '.../generate_events.py'. The generator lives at ~/ir/generate_events.py. If you are in a sudo -i root shell, ~ is /root. Exit to your own shell.

Symptom → sha256sum -c reports FAILED. Something changed the bundle after generation. Do not regenerate over the top and continue; record the failure, regenerate into a clean directory, and note it.

Symptom → your date differs from any time in this course. It should — that is your clock. The *bundle* timestamps are deterministic for a given seed and are the ones you build the timeline from.

Symptom → you want to skip the memo because "obviously it's an incident." Write it anyway. The memo is what makes the declaration auditable and fixes the severity and confidence before the case moves.

Check your understanding

Summary and next step

• An incident is a determination made from evidence; declaring it commits the organisation and starts clocks.
• The current NIST lifecycle (SP 800-61 Rev. 3) is built on the CSF 2.0 functions, with improvement running

continuously; the older four phases map onto it.

• Record severity and confidence separately, each with a reason, in a declaration memo.

Next, lesson 2 turns the declaration into preparation: the playbook and the readiness that make the rest of the response fast.

References

• NIST SP 800-61 Rev. 3, Incident Response Recommendations and Considerations (CSF 2.0 Community Profile) — https://csrc.nist.gov/pubs/sp/800/61/r3/final (accessed 2026-09-19)
• NIST Cybersecurity Framework (CSF) 2.0 — https://www.nist.gov/cyberframework (accessed 2026-09-19)
• RFC 5737, IPv4 address blocks reserved for documentation — https://www.rfc-editor.org/rfc/rfc5737 (accessed 2026-09-19)