Run day-to-day defense like a SOC analyst: logging and SIEM hunting, IDS alerts, incident response, triage, forensics, vulnerability management, hardening, cloud posture and MITRE ATT&CK.

Security Operations & Defense

## Why it matters

Every organisation will have security incidents. What separates a bad day from a disaster is whether people know what to do: who leads, what to preserve, when to cut off a machine, who must be told, and how to stop it happening again. An **incident response (IR)** lifecycle gives that structure. It is also a staple of job interviews and of the CySA+ exam.

## Event, alert, incident

- An **event** is anything observable: a login, a file write, a blocked connection.
- An **alert** is an event (or pattern) that a tool flagged for attention.
- An **incident** is a confirmed or likely violation of security policy: an attacker in an account, malware running, data exposed.

Most alerts are not incidents. Triage (the next lesson) decides which ones are.

## The NIST lifecycle

The US National Institute of Standards and Technology publishes incident response guidance in **Special Publication 800-61**. The widely taught lifecycle from revision 2 has four phases:

1. **Preparation**: plans, contacts, tools, logging, training and practice before anything happens.
2. **Detection and Analysis**: noticing something is wrong, confirming it, working out scope and severity, and documenting.
3. **Containment, Eradication and Recovery**: stopping the spread, removing the attacker and their tools, and restoring normal operations safely.
4. **Post-Incident Activity**: lessons learned, improving controls and detections, and keeping evidence.

The phases loop: lessons learned feed back into preparation, and during an incident you often go back and forth between analysis and containment as you find more.

**Revision 3 (2025)** reorganises the guidance around the six functions of the NIST Cybersecurity Framework 2.0 (Govern, Identify, Protect, Detect, Respond, Recover), so incident response is treated as part of overall risk management rather than a separate process. The four-phase model is still the common vocabulary in SOCs and exams, and it maps neatly onto the CSF functions. Read the current publication at [csrc.nist.gov](https://csrc.nist.gov/pubs/sp/800/61/r3/final). Checked on 2026-10-23.

Other models exist. The SANS model splits the same work into six steps (Preparation, Identification, Containment, Eradication, Recovery, Lessons Learned). The ideas are the same.

## What each phase involves

**Preparation**
- A written IR plan with roles: incident lead, technical responders, communications, legal and management.
- An up-to-date contact list, including outside help (an IR retainer, your cloud provider, law enforcement contacts).
- Logging and a SIEM that cover your key systems (module 1), plus clock synchronisation.
- Tabletop exercises: walking through a scenario on paper to find gaps.

**Detection and Analysis**
- Confirm the alert is real, then **scope** it: which accounts, hosts and data are affected?
- Assign a severity based on impact (business functions, data sensitivity, number of systems).
- Start an **incident log**: every action, finding and decision with a UTC time and the person's name.

**Containment, Eradication and Recovery**
- **Short-term containment** stops the bleeding: isolate a host from the network, disable an account, block an IP or domain.
- **Preserve evidence before you destroy it.** Capture memory and logs before wiping or rebooting where the situation allows (lesson 2.3).
- **Eradication** removes the cause: malware, persistence mechanisms, backdoor accounts, the vulnerability that let them in.
- **Recovery** restores from known-good backups or rebuilds, resets credentials, and watches closely for the attacker returning.

**Post-Incident Activity**
- A **blameless** lessons-learned meeting within a couple of weeks: what happened, what went well, what to change.
- Concrete follow-ups with owners: new detections, patches, training, plan updates.
- Retain evidence and reports according to policy and legal advice.

## Worked example: a phishing compromise

At 09:05 the SIEM alerts on a successful Microsoft 365 sign-in for `j.ruiz` from a country where the company has no staff, ten minutes after the user clicked a link in an email.

- **Detection and Analysis.** The analyst confirms the sign-in is not a VPN and the user did not travel. Mailbox audit logs show a new inbox rule forwarding all mail to an outside address. Severity: high (account takeover with data leaving). Scope check: two other users received the same email; one clicked.
- **Containment.** Revoke sessions and reset passwords for both users, require MFA re-registration, delete the forwarding rule, and block the sender and the phishing domain.
- **Eradication.** Purge the phishing email from all mailboxes, check for other inbox rules, OAuth app grants or MFA methods the attacker added.
- **Recovery.** Return the accounts to the users, monitor sign-ins for two weeks, and notify affected contacts if the forwarded mail contained their data (legal decides on notification duties).
- **Post-incident.** Lessons learned: the phishing email passed filters and users could not easily report it. Actions: add a report-phish button, alert on new external forwarding rules, and move these users to phishing-resistant MFA.

## Common mistakes

- **Wiping first, asking later.** Rebuilding a machine before collecting evidence can destroy the only record of how the attacker got in.
- **Tipping off the attacker.** Visible half-measures (resetting one password while they hold others) can push them to act faster. Plan containment so it happens together.
- **No incident log.** Memory fails under stress; reports, insurance and legal questions need a timeline.
- **Skipping lessons learned.** Without it, the same incident happens again.

## Quick recap

- Events are observations, alerts are flags, incidents are confirmed or likely policy violations.
- NIST SP 800-61 phases: Preparation; Detection and Analysis; Containment, Eradication and Recovery; Post-Incident Activity. Revision 3 aligns them with CSF 2.0.
- Scope, document, preserve evidence, contain together, remove the cause, recover carefully, and learn.


Walk an incident through the NIST phases: preparation, detection and analysis, containment, eradication and recovery, and lessons learned.

The IR lifecycle

Incident Response - CompTIA Security+ SY0-701 - 4.8

Incident Planning - CompTIA Security+ SY0-701 - 4.8

Make a table with columns: alert, what the rule detects, key evidence, classification, priority (P1-P4), next action.

For each alert, write in one line what the rule is designed to detect.

Use the context to classify each alert as true positive, benign true positive, false positive, or needs more information.

Set a priority for each using severity and asset value (the matrix in the reading): pay attention to which assets and accounts are critical.

Write the next action for each: close with a reason, gather specific additional data, escalate to IR, or contain per playbook.

Put the five alerts in the order you would work them, and say why the top one goes first.

Write a full analyst note for the highest-priority alert in the format from the reading (alert, time, findings, classification, priority, actions), defanging any domains.

Pick one alert that should lead to a tuning request or exception and write the request in two sentences.

## Why it matters

A busy SOC can receive hundreds or thousands of alerts a day. Most are harmless. **Triage** is the skill of deciding, quickly and consistently, which alerts need action now, which can wait, and which can be closed. Good triage stops real incidents from hiding in the noise; bad triage either misses them or burns out the team by escalating everything.

## The triage questions

For each alert, a tier 1 analyst works through roughly the same questions, usually in 5 to 15 minutes:

1. **What does the rule detect?** Read the rule logic, not just the title.
2. **Is the data right?** Is the log complete, is the time correct, does the host or user exist?
3. **What is the context?** Who is the user, what is the host (a laptop, a domain controller, a test VM?), is there a change ticket or a known scan?
4. **Is it malicious, suspicious or benign?** Check reputation of IPs, domains and file hashes, and look at activity just before and after.
5. **What is the impact if it is real?** A crown-jewel server or an admin account raises the stakes.
6. **What next?** Close with a reason, escalate to tier 2 or IR, or contain now if the playbook allows.

## Classifying the outcome

| Outcome | Meaning | Action |
|---|---|---|
| **True positive** | Malicious activity confirmed | Escalate or contain per playbook |
| **Benign true positive** | Rule worked, activity is authorised | Close; consider tuning or an exception |
| **False positive** | Rule matched something it should not | Close; send a tuning request |
| **Needs more information** | Cannot decide yet | Gather data, ask the user or owner, escalate if time runs out |

## Prioritising: severity times asset value

Most SOCs set priority from two things: how bad the activity is and how important the target is. A simple matrix:

| | Low-value asset (test VM) | Normal asset (staff laptop) | Critical asset (domain controller, payroll, admin account) |
|---|---|---|---|
| **Low severity** | P4 | P4 | P3 |
| **Medium severity** | P4 | P3 | P2 |
| **High severity** | P3 | P2 | P1 |

P1 means work it now and page the on-call lead; P4 can wait in the queue. Teams write their own version into their playbooks.

## Enrichment: gathering context fast

- **Asset inventory or CMDB**: what the host is and who owns it.
- **Identity directory**: the user's role, manager, usual location and recent password or MFA changes.
- **Threat intelligence**: reputation of IPs, domains and hashes. Free sources include VirusTotal and AbuseIPDB. Never upload a company's confidential files to public services; search by hash instead.
- **SIEM pivots**: everything the same user, host or IP did in the hour around the alert.

Many SOCs automate this with **SOAR** (security orchestration, automation and response) playbooks that attach the context to the alert before a human sees it.

## Worked example: two alerts, two outcomes

**Alert A: "Possible brute force: 120 failed SSH logins on `scan-lab01`."** The host is a lab VM owned by the security team, the source IP is the internal vulnerability scanner, and a change ticket shows a scheduled credentialed scan. Outcome: benign true positive, P4, close with the ticket reference and suggest an exception for the scanner IP on that host.

**Alert B: "PowerShell launched by WINWORD.EXE on `fin-lt-07`."** The laptop belongs to an accounts payable clerk. The command line contains `-EncodedCommand` and a long base64 string. One minute later the laptop made its first-ever connection to a newly registered domain. Outcome: true positive (likely a malicious macro), high severity on a finance user's machine: P2. Following the playbook, the analyst isolates the laptop with the EDR tool, escalates to IR with the evidence, and notes the domain so others can be checked.

## Writing it down

Every triaged alert needs a short note that someone else can follow:

```text
Alert: PowerShell spawned by WINWORD.EXE on fin-lt-07 (user m.okafor)
Time (UTC): 2026-10-23 13:02:41
Findings: encoded PowerShell; outbound connection 13:03 to invoice-docs-check[.]com (registered 3 days ago, no reputation)
Classification: True positive (likely malicious macro)
Priority: P2 (high severity, finance user)
Actions: host isolated via EDR 13:11; escalated to IR (ticket IR-2291); domain added to watchlist
```

Notice the defanged domain (`[.]`): it stops anyone accidentally clicking a malicious link in a ticket.

## Common mistakes

- **Closing because "it is always a false positive".** Attackers rely on alert fatigue. Check each alert, and fix noisy rules instead of ignoring them.
- **Escalating with no context.** "Alert fired, please check" wastes tier 2 time. Pass on what you found and why it matters.
- **Taking actions outside the playbook.** Containment can disrupt the business; know what you are authorised to do.
- **No notes.** Undocumented triage cannot be reviewed or improved.

## Quick recap

- Triage asks what the rule detects, whether the data is right, what the context is, whether it is malicious, what the impact is and what to do next.
- Classify as true positive, benign true positive, false positive or needs more information.
- Prioritise by severity and asset value, enrich with inventory, identity, intelligence and SIEM pivots, and write a short, defanged note.

## Try it

Open the **Do** tab and triage five sample alerts.


Triage alerts like a SOC analyst: check the rule, the data and the context, classify, prioritise and write a clear note.

Alert triage

SOC Alert Triage Explained: What Most Beginners Get Wrong

Take a snapshot of your Ubuntu lab VM named "before-forensics".

Stage the incident and note the UTC time of each action: create a user (`sudo useradd -m support2`), create a file (`echo test | sudo tee /tmp/.cache-update`), and run `sudo -l` as your normal user.

Make an evidence folder (`mkdir -p ~/evidence`; in a real case it would be external media) and record the current UTC time with `date -u > ~/evidence/00-time.txt`.

Collect volatile data first: `ps auxww`, `sudo ss -tunap`, `who -a` and `last -n 20`, each saved to its own file in `~/evidence`.

Collect less volatile data: copy `/var/log/auth.log` into the folder and save `stat /tmp/.cache-update` output.

Hash everything: `sha256sum ~/evidence/* > ~/hashes.sha256` (kept outside the folder), then verify with `sha256sum -c ~/hashes.sha256`.

Write a chain-of-custody line for the folder: item, collected by, UTC time, method, storage location, and SHA-256 of `auth.log`.

Build a timeline in a spreadsheet (columns: time_utc, source, event, notes) using `auth.log` and the `stat` output. Check that the useradd, sudo and file-creation events appear in the right order.

Compare your timeline with your notes from step 2. Note any time zone or clock differences you found.

Clean up: delete the test user (`sudo userdel -r support2`) and the file, or restore your snapshot.

## Why it matters

During an incident, people want answers fast: how did they get in, what did they touch, are they still here? **Digital forensics** answers those questions from evidence, in a way that holds up later in front of management, insurers, regulators or a court. The two skills every responder needs first are **preserving evidence** without changing it and **building a timeline** of what happened.

## Principles

1. **Preserve before you analyse.** Work on copies, never the original.
2. **Collect the most volatile data first.** Some evidence disappears when a machine is rebooted or even when time passes.
3. **Prove integrity.** Record cryptographic hashes (SHA-256) of everything you collect, so you can show it has not changed.
4. **Keep a chain of custody.** Record who collected each item, when, how, where it was stored and every time it changed hands.
5. **Document everything** with UTC timestamps, including commands you ran.

Serious cases (anything that might involve law enforcement, employee discipline or litigation) need trained forensic examiners and legal advice from the start. What you learn here is the first-responder level.

## Order of volatility

RFC 3227, a long-standing guideline for evidence collection, lists data from most to least volatile. A simplified version:

| Order | Evidence | Why it is fragile |
|---|---|---|
| 1 | CPU registers, cache | Changes every instant |
| 2 | Memory (RAM): running processes, network connections, logged-in users | Lost at power-off; malware may live only here |
| 3 | Temporary file systems | Cleared at reboot |
| 4 | Disk | Survives reboot, but changes as the system runs |
| 5 | Remote logs and monitoring data | Rotated or overwritten over time |
| 6 | Physical configuration, network topology | Changes slowly |
| 7 | Archives and backups | Most stable |

This is why "just reboot it" or "pull the plug and reimage" can destroy key evidence. Whether to keep a compromised machine running is a judgement call: isolating it from the network (not powering it off) often preserves memory while stopping the spread.

## Collecting from a live Linux system

A first responder's quick capture might look like this. Output goes to an external drive or a network share, never to the suspect disk, and every command is noted.

```bash
OUT=/mnt/evidence/web02-2026-10-23
date -u                                  > $OUT/00-time.txt
{ uname -a; uptime; }                    > $OUT/01-system.txt
{ who -a; last -n 50; }                  > $OUT/02-users.txt
ps auxww                                 > $OUT/03-processes.txt
ss -tunap                                > $OUT/04-connections.txt
sudo cp /var/log/auth.log* "$OUT"/
sha256sum "$OUT"/*                       > "$OUT"/hashes.sha256
```

Full memory captures and disk images use dedicated tools (for example LiME or AVML for Linux memory, and write blockers plus imaging tools for disks). The open-source **Autopsy** platform and the **Volatility** framework are common for analysis.

## Building a timeline

A timeline puts every relevant event from every source in time order. It turns scattered clues into a story.

**Sources** include authentication logs, web server logs, shell history, file system timestamps, SIEM alerts, EDR events and cloud audit logs. File systems record several times per file, often summarised as **MAC(B)**: Modified (content changed), Accessed, Changed (metadata changed) and Born (created). On Linux, `stat file` shows them.

Tools like **plaso** (`log2timeline`) build "super timelines" from hundreds of artefact types automatically. For small cases a spreadsheet works well, with columns `time_utc`, `source`, `host`, `event` and `notes`.

### Worked example

From a web server, a responder collects auth logs, the web access log, `stat` output for an odd file and the `www-data` user's activity:

| time_utc | source | event |
|---|---|---|
| 2026-10-22 23:58:10 | web access log | `POST /upload.php` from 203.0.113.50 with file `img.php` |
| 2026-10-22 23:58:11 | file system (Born) | `/var/www/html/uploads/img.php` created |
| 2026-10-22 23:59:02 | web access log | `GET /uploads/img.php?cmd=id` from 203.0.113.50 |
| 2026-10-23 00:03:40 | web access log | `GET /uploads/img.php?cmd=wget...` downloading a script |
| 2026-10-23 00:04:05 | auth.log | new user `support2` added |
| 2026-10-23 00:06:31 | auth.log | SSH login as `support2` from 203.0.113.50 |

The story is now clear: an unrestricted file upload let the attacker place a web shell, run commands, create a backdoor account and log in over SSH. The timeline also tells responders what to fix (the upload form), what to remove (the shell and the account) and where to look next (anything `support2` did).

## Common pitfalls

- **Time zones.** Logs from different systems may use local time, UTC or no zone at all. Convert everything to UTC and note the original.
- **Clock drift.** A machine whose clock is five minutes off will scramble the order; check against NTP.
- **Changing the evidence.** Opening files on the suspect system updates access times; installing tools on it overwrites deleted data. Use trusted tools from external media.
- **Forgetting the hashes.** Without them you cannot prove your copy matches what you collected.

## Quick recap

- Preserve first, collect in order of volatility, hash everything and keep a chain of custody.
- Isolating a host often beats powering it off, because memory holds evidence.
- A timeline in UTC, combining logs and file timestamps, turns clues into a story and tells you what to fix.
- Serious cases need trained examiners and legal advice.

## Try it

Open the **Do** tab to collect evidence and build a timeline on your own lab VM.


Preserve evidence in order of volatility, prove integrity with hashes and chain of custody, and build a UTC timeline.

Forensics basics

DFS101: 1.1 Introduction to digital forensics

Timeline Analysis in DFIR, Full Process Explained

Run incidents through the NIST lifecycle, triage alerts quickly and consistently, and preserve evidence with a clear timeline.