Three nouns that students confuse, and that you cannot afford to confuse in a write-up:

• An event is anything observable on a system — a login, a packet, an antivirus scan. Server logs are full of them, easily millions per day on a medium-sized network.
• An alert is an event that some detection tool has decided is worth a human's attention. Alerts are rarer than events, but plenty of them are still false positives.
• An incident is an alert that has been confirmed — by a human or a well-trained automation — to represent an actual violation of security policy or an imminent threat of one. The moment the word "incident" gets used in writing, the stopwatch starts: lawyers care, regulators care, and the bill begins to climb.

Incident handling, sometimes called incident response (IR), is the disciplined process of detecting, analysing, containing, eradicating, recovering from, and learning about those incidents. The authoritative reference is NIST Special Publication 800-61 (NIST = National Institute of Standards and Technology) — the Computer Security Incident Handling Guide — which defines the classic six-phase lifecycle. NIST is a US federal agency that publishes technical standards used worldwide.

Why does anybody pay for this work? Three reasons in roughly descending order of how much they should be reversed: money (the IBM Cost of a Data Breach Report consistently shows organisations with mature IR programmes save one to two million US dollars per incident compared to those without), regulation (under GDPR (General Data Protection Regulation) the breach-notification clock is 72 hours from awareness — not from confirmation), and trust (a transparent, fast response often preserves a company's reputation; a hidden one ends in a courtroom).

The CIA triad — Confidentiality, Integrity, Availability — is the trio of properties every security control ultimately defends:

• Confidentiality — information is disclosed only to those authorised to see it. Mechanisms: encryption (in transit and at rest), access control lists, multifactor authentication (MFA), the boring physical lock on the server-room door.
• Integrity — information is accurate, complete, and unaltered by unauthorised parties. Mechanisms: cryptographic hashes, digital signatures, transaction logs, version control. The Stuxnet worm famously attacked integrity by reporting correct values to operators while centrifuges destroyed themselves.
• Availability — authorised users can access information and systems when needed. Mechanisms: redundant hardware, load balancers, backup power, anti-DDoS (Distributed Denial-of-Service) services. Every DDoS attack is a direct assault on this pillar.

Three vocabulary terms revolve around the triangle:

• A threat is anything that could cause harm — an organised crime group, a disgruntled employee, a tropical storm. Threats are potential, not actual.
• A vulnerability is a weakness a threat can exploit — an unpatched server, a shared admin password, a missing background check.
• An exploit is the specific method or tool that uses the vulnerability — a Metasploit module, a phishing email with a poisoned spreadsheet, a brick through the window.

Risk = Likelihood × Impact. That is the qualitative formula every CISO (Chief Information Security Officer) you ever meet will recite. Risk is never purely technical; the same vulnerability in a public-facing production database is a much bigger risk than in a test system holding fake data, because impact differs by orders of magnitude. The companion methodology is NIST SP 800-30 — Guide for Conducting Risk Assessments.

A control is a safeguard that reduces risk. Three families: preventive (stop the thing happening), detective (notice it when it does), corrective (clean up afterwards). A mature programme uses all three. An asset is anything the organisation values enough to protect — data, systems, people, reputation, intellectual property.

The seven incident families you will see in the wild, in roughly decreasing order of frequency:

1. Malicious code (malware) — viruses, worms, trojans, rootkits, ransomware. The 2017 WannaCry outbreak hit ~200,000 systems across 150 countries in roughly a day.
2. Social engineering — phishing (email), vishing (voice), smishing (SMS — Short Message Service), pretexting, Business Email Compromise (BEC). The FBI Internet Crime Complaint Center reports BEC alone causes billions of dollars of losses annually.
3. Denial of Service (DoS) and DDoS — flooding a target to take it offline. The 2016 Dyn cyberattack took a chunk of the US internet down using compromised home routers and cameras.
4. Unauthorised access — stolen passwords, credential stuffing, exploitation of exposed services. The 2021 Colonial Pipeline ransomware case began with a single leaked VPN (Virtual Private Network) credential reused across systems.
5. Data exposure and leakage — deliberate exfiltration, accidental public buckets, mis-addressed spreadsheets. The 2017 Equifax breach exposed records of 147 million people.
6. Insider threats — malicious (a departing engineer with source code on a USB stick) and accidental (an executive uploading sensitive data to personal cloud storage by mistake).
7. Supply-chain compromise — an attacker compromises a trusted vendor and the malicious update ships to thousands of customers. The 2020 SolarWinds Sunburst campaign is the canonical case.

Every incident gets classified along four axes: severity (how loud should the alarm ring — typically Low/Medium/High/Critical), scope (how far does it reach — narrow or broad), category (which of the seven families above, since category drives runbook selection), and sensitivity (was regulated data — personal data, protected health information, cardholder data — touched).

The SOC (Security Operations Center) is the front line. SOC analysts monitor the SIEM (Security Information and Event Management) platform, triage alerts, and resolve or escalate. SOCs run in tiers: Tier 1 does first-pass triage, Tier 2 does deeper analysis and minor incident response, Tier 3 does forensic investigation and malware reverse engineering. Most enterprise SOCs run 24×7 with follow-the-sun shifts because attackers do not respect office hours.

The CSIRT (Computer Security Incident Response Team) owns the incident from confirmation through lessons learned. In small organisations, the CSIRT is a subset of the SOC; in large ones, a separate unit reporting to the CISO. Two cousin acronyms: CERT (Computer Emergency Response Team) is older and still used for many national teams like CERT-EU; the CERT trademark belongs to Carnegie Mellon University, which is why most corporate teams now prefer CSIRT. PSIRT (Product Security Incident Response Team) is the team inside a software vendor that handles vulnerabilities in their own products.

Around the SOC and CSIRT sit the supporting cast: the CISO owns the executive-level security programme, Legal counsel decides what can be said publicly and asserts privilege over forensic reports, Communications/PR (Public Relations) writes the breach-notification letter and the press release, Human Resources handles insider cases and out-of-hours staff matters, IT operations know the infrastructure and must be befriended long before the breach, and External partners (a digital-forensics retainer with firms like Mandiant, CrowdStrike, or Unit 42, a breach-notification law firm, a PR agency) get called when the incident exceeds in-house capacity. Law enforcement (the FBI and its Internet Crime Complaint Center (IC3), the U.S. Cybersecurity and Infrastructure Security Agency (CISA), and Canada's Royal Canadian Mounted Police National Cybercrime Coordination Unit (RCMP NC3)) gets engaged when the incident is serious enough that the intelligence outweighs the headache.

If you remember one non-technical word from Lesson 4, make it tabletop exercise — a two-hour meeting where the IR team walks through a simulated incident with no keyboards and no real systems. Tabletops surface the playbook gaps that no documentation review will reveal. Every organisation that runs them quarterly handles real incidents dramatically better than those that do not.

Modern incident handling has a stopwatch attached. The four frameworks you must know on day one of the job:

• GDPR (General Data Protection Regulation) — the EU regulation in force since May 2018. Article 33 requires notification of the lead supervisory authority within 72 hours of awareness of a personal-data breach, unless the breach is unlikely to result in a risk to individuals. Article 34 requires notification of the affected individuals themselves when the risk is high. Penalties reach EUR 20 million or 4% of global annual turnover, whichever is higher. The Irish Data Protection Commission has been the lead regulator for many of the largest fines.
• HIPAA (Health Insurance Portability and Accountability Act) — the US law governing protected health information (PHI). The Breach Notification Rule, enforced by the US Department of Health and Human Services Office for Civil Rights, requires individuals to be notified within 60 days, the Secretary of HHS within 60 days for breaches of 500 or more individuals, and prominent media outlets in the affected state if 500 or more residents are involved.
• NIST guidance — not a law, but the global de-facto baseline. The two publications you must know are NIST SP 800-61 Rev. 2 (the six-phase incident-handling lifecycle) and the NIST Cybersecurity Framework version 2.0 (organised into six functions: Govern, Identify, Protect, Detect, Respond, Recover).
• Others worth knowing — PCI DSS (Payment Card Industry Data Security Standard, contractual rather than legal but card-brands can revoke processing rights for non-compliance), NIS2 (the EU Network and Information Security Directive 2 with a 24-hour early-warning clock for essential and important entities), the SEC cyber-incident disclosure rule (US-listed companies must file Form 8-K Item 1.05 within four business days of materiality determination), CCPA/CPRA (California's privacy laws), and ISO/IEC 27035 (the international standard for information-security incident management).

The practical consequence: every incident has a clock. The instant an incident is confirmed, two questions must be asked — "is personal or regulated data implicated?" and "when does the clock start?". Write those two questions on a sticky note on your monitor.

The classic six-phase IH&R lifecycle is the model you will see on every certification exam — CEH (Certified Ethical Hacker), GCIH (GIAC Certified Incident Handler), ECIH (EC-Council Certified Incident Handler) — and on most job descriptions:

• Preparation — before the fire starts, you check the extinguishers. Build the IRP (Incident Response Plan), stand up the CSIRT, stock the jump bag, run tabletops, harden logging on the SIEM, EDR (Endpoint Detection and Response), and NDR (Network Detection and Response) — and get legal, HR, PR (Public Relations), and the insurance carrier on the same page before the 3 a.m. call.
• Identification — somebody yells "fire!" and you confirm it is actually fire and not burnt toast. Sources: SIEM correlation rules, EDR telemetry from products like CrowdStrike Falcon or Microsoft Defender for Endpoint, help-desk calls, external notification (your bank, a customer, CISA — the Cybersecurity and Infrastructure Security Agency — or, awkwardly, a journalist).
• Containment — close the door so the fire does not spread. Short-term: stop the bleeding (network isolation, account disable, DNS blackholing of attacker infrastructure). Long-term: keep the attacker busy while you plan a clean eradication. Snapshot affected VMs (Virtual Machines) before reboot — never the other way around, or you lose volatile evidence in RAM (Random Access Memory).
• Eradication — remove the malware, delete attacker accounts, patch the exploited CVE (Common Vulnerabilities and Exposures), kill every persistence mechanism (scheduled tasks, registry run keys, cron jobs, WMI subscriptions, systemd timers). If you eradicate before you fully understand root cause, the attacker comes back through the same door.
• Recovery — bring systems back online under careful monitoring. Restore from known-good backups, re-image rather than "clean" where possible, stage the bring-up so you catch surprises before they hit the crown jewels, and validate that business functions actually work — finance does not care that the domain controller is clean if they cannot run payroll.
• Lessons Learned — within two weeks of recovery, run a blameless post-incident review (PIR), produce metrics, update the IRP and playbooks, and feed the lessons back into Preparation.

The classic three nouns that students confuse: Event (anything observable), Incident (event(s) that violate or threaten security policy), Breach (an incident where confidentiality of data is proven lost). Mixing these up in a boardroom is how careers end.

A real IRP (Incident Response Plan) is a living document, not a PDF gathering dust on a SharePoint. Seven sections at minimum: purpose/scope/authority, roles and responsibilities (in the form of a RACI matrix — Responsible / Accountable / Consulted / Informed — by title, not by name), incident classification and severity matrix (typically SEV-1 through SEV-4 with crystal-clear definitions and time-to-notify SLAs — Service Level Agreements), six-phase playbook references, communication and escalation protocol, legal and regulatory reporting obligations (Canada's Personal Information Protection and Electronic Documents Act (PIPEDA) reported to the Office of the Privacy Commissioner of Canada (OPC), Quebec's Law 25 where Quebec residents are affected, U.S. state breach-notification laws reported to the relevant state Attorney General — for example California, New York, Illinois — plus the U.S. Federal Trade Commission (FTC) and sector-specific bodies), and plan maintenance with an owner and review schedule.

When you build an IRP from scratch, do it in this order: map crown-jewel assets, define the severity matrix in terms of business impact (a SEV-1 means "this is costing money or reputation right now", not "this is a cool zero-day"), draft roles with named deputies, write one playbook per top-five incident type (the SANS Reading Room and the CISA playbooks are excellent starting templates), get legal and HR to review the relevant sections in writing, then tabletop-test, break, and rewrite annually.

The IRP decays. Every new SaaS (Software as a Service) tool, every reorganisation, every new regulation (the EU's NIS2 and DORA — Digital Operational Resilience Act — are two recent examples) rots a piece of it. Schedule a minor review every quarter, a major review annually, and an unscheduled review after any SEV-1 or SEV-2.

Activation is a formal act, not a mood. Triggers: any confirmed SEV-1 or SEV-2, credible external notification, detection of high-impact TTPs (Tactics, Techniques, and Procedures) such as domain-wide Kerberoasting or a ransomware note on any host, or executive decision by the CISO. First moves: declare, assemble, stabilise, communicate.

Most of the damage in a major breach comes from communication failures, not technical failures. The attacker exfiltrated in six minutes; the legal team learned about it from Twitter; the PR team contradicted the CEO's TV statement; customer service was telling people "everything is fine" while the website was publicly defaced. Look at the post-mortems of Equifax or Target and you will see exactly this pattern.

Three communication axes run in parallel during a live incident, each with different rules:

• Internal-technical — the IRT (Incident Response Team), SOC, IT operations, network team, application owners. High bandwidth, high detail, minimal filter. Use secure, out-of-band channels because your main channels may be compromised.
• Internal-executive/legal/HR/PR — leadership, legal counsel, HR, PR, insurance broker. Lower bandwidth, structured, often via SITREPs (Situation Reports) every 60 or 120 minutes during an active SEV-1.
• External — customers, regulators, law enforcement, media, vendors, partners. Lowest bandwidth, maximum filtering, often through a single spokesperson. Every word is potentially a legal exhibit.

Escalation — moving the incident up the severity ladder or up the seniority ladder — has two rules every junior responder should memorise. First: when in doubt, escalate. The cost of escalating a false positive is a slightly grumpy manager; the cost of not escalating a real one ends careers. Second: escalation is not a blame transfer — you still own the technical response after escalating. You are asking for authority, resources, and visibility, not for someone to take the pain away.

A sane escalation matrix maps severity to "time to notify", "who must be told", and "who decides". Each row maps to a pre-written, pre-approved message template so the on-call analyst at 02:14 on a Saturday is not composing prose with shaking hands.

The single rule that has bitten me once and that I will never break again: never assume your primary communication channel is safe during an active incident. If an attacker has email access, they are reading your incident email thread. Always have an out-of-band fallback — a private Signal or WhatsApp group set up in peacetime, a conference-bridge number printed on a laminated card in the jump bag, an alternate ticketing system. This is not paranoia. The Lapsus$, Colonial Pipeline, and Uber 2022 breach playbooks all confirm attackers eavesdrop on the response when they can.

Lawyers have a phrase incident responders should tattoo on their forearms: if it is not documented, it did not happen. Documentation has four distinct purposes — operational (telling the next analyst what has been done), forensic (building an admissible chain-of-custody trail), regulatory (satisfying GDPR Article 33, the SEC cyber-incident rule, HIPAA, NIS2, PCI-DSS), and strategic (feeding lessons-learned and metrics back into the programme). Mixing them — for example, putting forensic hypotheses in the regulator notification — creates legal exposure.

A minimum documentation set, phase by phase:

• Preparation: the current version of the IRP and every playbook with version number and approval date, asset inventory, contact lists, tabletop after-action reports, training records.
• Identification: the alert that triggered detection with raw log excerpts and timestamps in UTC (Coordinated Universal Time), initial analyst triage notes and the reasoning for the severity call, the exact list of IoCs (Indicators of Compromise) observed, time of declaration, identity of declaring authority.
• Containment: every action taken, the system it was taken on, the authorised person, the timestamp, any chain-of-custody forms (NIST SP 800-86 — Guide to Integrating Forensic Techniques into Incident Response — is the reference), hash values of all evidence collected (typically SHA-256).
• Eradication: root-cause hypothesis → validation → confirmed root cause, with evidence for each step; list of patches, configuration changes, account deletions, and rule additions made, with change-management ticket numbers.
• Recovery: restore sources (which backup, what point-in-time, validated how), service-by-service bring-up order, sign-off from business owners.
• Lessons Learned: reconstructed UTC minute-granular timeline, root-cause analysis report, cost of the incident (direct, indirect, regulatory, reputational), specific action items with owners and deadlines.

The reporting clock you must internalise: GDPR Article 33 — 72 hours from awareness to the lead supervisory authority; SEC 8-K Item 1.05 — four business days from materiality determination; PCI-DSS — "immediately" to your acquiring bank; HIPAA — 60 days for breaches affecting 500 or more individuals; NIS2 — 24-hour early warning to the national CSIRT. These deadlines start from the moment you become aware, not from the moment it is convenient.

Most organisations do the first five phases. Many quietly skip Lesson Six. The lessons-learned meeting gets scheduled, then cancelled, then forgotten. Skipping it is the single most expensive mistake in security: every incident is a free, fully-funded research project into how your defences fail, and throwing that research in the bin is indefensible.

A proper PIR (Post-Incident Review) is blameless (about systems, not individuals), timed (within two weeks of recovery, before memory decays), multi-disciplinary (IR, IT Ops, SOC, application owners, business owners, legal, HR — the gaps live at the seams between disciplines), data-driven (real metrics from the SIEM and ticketing system, not war stories), and action-oriented (every PIR produces a written list of items with owners and deadlines).

Two root-cause-analysis techniques worth knowing. The 5 Whys — ask "why did this happen?" five times in a row, and the fifth answer is what you actually fix. Why did the attacker get in? Because a contractor's VPN account had MFA disabled. Why? Because IT turned it off six months ago "temporarily". Why was the temporary change not reverted? Because there was no expiry on the exception ticket. Why? Because the exception-ticket template has no expiry field. Why? Because nobody has reviewed the template in three years. The fix is the template, not the contractor. The second technique is the Fishbone (Ishikawa) diagram, which splits causes into categories — People, Process, Technology, Environment — and forces the team to populate each branch (ASQ has a good primer).

Metrics that actually matter (and a couple that do not):

• MTTD (Mean Time to Detect) — first attacker action to first confirmed alert.
• MTTA (Mean Time to Acknowledge) — alert firing to analyst pickup.
• MTTR (Mean Time to Respond / Recover) — declaration to full recovery.
• Incidents per 1,000 employees — normalised so the CFO does not panic at headcount growth.
• % of alerts that were false positives — anything above 40% means your detection content needs tuning, not your staffing.
• % of PIR action items closed within 90 days — the single best signal of whether your lessons-learned process actually learns.

Vanity metrics that look impressive but are worthless: number of alerts generated (volume is not quality) and number of blocked connections at the firewall (that is internet noise, not defensive value).

Every PIR action item belongs to one of four buckets — Detection (a new SIEM rule, a new EDR signature), Prevention (a patch, a config change, a new control), Process (an updated playbook, a new training module, a new checklist), and People (a hire, a re-org, a new external retainer). Tag every action item; at the next quarterly review, count the closures per bucket. If your programme is leaning entirely on Detection (the sexy bucket), you have a maturity problem.

And finally — publish a sanitised internal PIR report to your whole IT organisation. Engineers reading "here is how we got beaten last month and here is what we are doing about it" build security instincts faster than any classroom training. Secrecy breeds repetition.

A useful rule veteran responders pass to juniors: the alert is not the incident; the alert is a hypothesis. Modern SIEM platforms throw off thousands of correlations a day — most are noise, a few are real. Your job in the first ninety seconds is to decide which.

Five steps in a specific order, drilled into every reputable playbook from NIST SP 800-61, ENISA, and SANS:

• Verify the signal. Cross-reference. If a detection rule fired because a host queried a domain on a threat-intelligence feed, do not just trust the rule — open the VirusTotal entry, check the AlienVault OTX (Open Threat eXchange) reputation, look at the WHOIS via ICANN Lookup. Two confirming sources turn an alert into a finding. Zero turn it into a tuned-rule false positive.
• Scope and severity. Three sub-questions. Which hosts? (one workstation or a whole VLAN — Virtual Local Area Network). What data? (developer laptop or a database with regulated financial records — GDPR and HIPAA timers attach). What business impact? (a tax-closing run that ships tomorrow morning is a different beast from a marketing landing page). Severity is typically a P1-to-P4 scale: P1 means active loss or material business impact, P4 means informational.
• Contain (without erasing). This is where the WannaCry first responder went wrong. The default first-response containment is network isolation, not power-off. On a managed endpoint, the EDR agent's "contain device" button is one click — the host is cut off from everything except its EDR controller while memory, processes, and disk stay intact for forensic capture. Pulling the plug destroys evidence in RAM that the eradication phase may need.
• Notify. Page the on-call analyst, log the incident in the ticketing system with a unique ID, alert the IR lead per the IRP, start the legal clock if regulated data may be in scope.
• Capture. Run the volatile-evidence collection script before anything else changes. Memory image, network connections, process tree, logged-in users — in that order, because that is the order they decay.

A 1995 California criminal trial — famously — turned on a forensic detective who could not, in the end, account for who had been holding a piece of physical evidence during a few hours between collection and lab analysis. The defence pounced. The judge sustained an objection. The evidence was excluded.

Now imagine your turn on the stand. The case is corporate; your company is suing a former employee for stealing source code on his last day. The crucial evidence is a forensic image of his laptop drive, made by you during off-boarding eighteen months earlier. Opposing counsel leans forward and asks if you can account for who had physical custody, when, and what they did with the drive. If you can — every transfer, every signature, every hash — your evidence stays in. If you cannot — even one unsigned form, one missing hash — the judge may exclude it, and with it the case.

This is not theoretical. The bodies that write cybercrime evidence rules — the International Organization on Computer Evidence (IOCE), the Council of Europe Budapest Convention on Cybercrime, the US Department of Justice CCIPS (Computer Crime and Intellectual Property Section), ENISA — converge on the same principle: evidence is admissible if and only if its integrity, authenticity, and continuity can be demonstrated.

The five non-negotiable principles:

• Integrity — the evidence must not be altered by collection or analysis. Operationalised through write blockers on physical media, working only on copies, hashing before and after every operation, and using forensically-validated tools (the NIST CFTT (Computer Forensics Tool Testing) program maintains a database).
• Authenticity — the evidence is provably what it claims to be. Hashing is the technical part; documenting origin (which host, which user, which storage) is the procedural part.
• Continuity — every transfer of custody is recorded with no gaps. If evidence sits in a locked cabinet for three weeks, the access log of the cabinet must show that nothing happened.
• Reproducibility — analysis must be reproducible by an independent party using the same tools and inputs. This is why we record tool versions to the patch level (Volatility 3.4.0 and 3.4.1 may produce different output on the same memory image).
• Minimality — collect what you need; do not over-collect. Sweeping up an entire department's email when you needed three messages creates privacy exposure and may conflict with GDPR's data minimisation principle.

A defensible chain-of-custody form contains, at minimum: a unique case identifier, a precise description ("SRV-FIN-03 RAM dump, 32 GiB, file SRV-FIN-03_mem.raw" — not "a memory dump"), a hash record with algorithm and digest, a custody log with one row per transfer including UTC timestamps and signatures from both parties, a storage record describing the bag, seal number, safe location, and access control, and a disposition record.

Two practical points students under-appreciate. First: timestamps must be in UTC. CET vs PST timestamps in a single case file at 03:00 cause confusion attackers exploit. Second: handwriting must be legible and in permanent ink. Pencil entries and erasable-ink (frixion) pens are inadmissible.

The senior responder's heuristic: at the moment of seizure, make at least two complete forensic images, hash both, lock the original copy in the safe with no further work done — it becomes the master. Keep one working copy in the analyst's hands; keep a second working copy as a recovery copy. The master is touched once, twelve months later in court, and at that point the only operation is a hash check that proves the working copy is identical.

A working day's worth of evidence is layered like a pyramid by half-life. CPU registers and cache decay in nanoseconds. ARP (Address Resolution Protocol) tables persist for seconds. Running-process and network-connection state persists for minutes to hours on a live system. RAM contents disappear at power-off (and sometimes faster, due to memory wear-leveling). Disk contents persist for days to years. Archival media persists for as long as the medium lasts.

The reference document is RFC 3227, the Internet Engineering Task Force guide on evidence collection priority. Its prescription, simplified: collect from the top of the pyramid down. Memory before disk, live network state before logs, kernel structures before user-space artefacts.

The lesson NotPetya 2017 hammered home: many administrators watching their fleets get destroyed shut machines down to "save" them. This was wrong. The malware had already encrypted the boot sector by the time the ransom note appeared, so shutdown saved nothing — but it destroyed the most valuable evidence: the contents of memory, which held the malware's running threads, decrypted strings, the hash-dump it had performed on lsass.exe (Local Security Authority Subsystem Service), the credentials it had stolen, and the list of remote hosts it was about to attack via PsExec and Windows Management Instrumentation (WMI). Almost none of that was recoverable from a powered-off disk.

Memory forensics with Volatility and similar tools lets you, hours or days later, list every process running at the moment of capture, find parent-child relationships that look wrong (cmd.exe spawned by winword.exe is rarely good news), pull command-line arguments, extract injected shellcode, recover loaded DLLs (Dynamic Link Libraries), and sometimes reconstruct browser tabs and chat windows that the user had open. None of that is on the disk.

The notebook is the responder's alibi. When a regulator asks the data controller, under GDPR Article 33, to demonstrate that the 72-hour breach-notification clock was respected, the proof is the notebook. When a HIPAA auditor asks why the affected database was kept online for ninety extra minutes, the answer is in the notebook. When the chief executive asks, six months later, why the e-commerce site was not pulled during Black Friday, the answer is in the notebook.

Five practical disciplines beginners must internalise:

• The 5W+H rule. Every entry answers, at minimum, Who (which person or tool acted), What (the action or observation), Where (which host, network segment, file path), When (full UTC timestamp to the second), Why (the reason — even one phrase is better than nothing), and How (the command, query, or procedure used).
• Time in UTC, always. A Toronto analyst sits in Eastern Time and will instinctively log "13:42 ET"; a Vancouver colleague at the same wall-clock instant writes "10:42 PT"; on the same incident, an attacker connecting from Singapore appears in the firewall log at "17:42 UTC" and nothing will line up. Convert to local time only for human-facing communication; everything in the timeline notebook is UTC.
• Quote, do not paraphrase. When a tool produces output, paste the literal output. Do not write "the scan found three suspicious files." Write the three filenames with full paths and hashes. Paraphrase looks like a tidy reconstruction afterwards; literal output stands up in court.
• Mark assumptions visibly. "Assuming the user did not knowingly execute the macro." "Assuming the workstation clock was correct at the time of capture." Visible assumptions allow the future reader to know which load-bearing facts were verified and which were taken on faith.
• Never delete; correct by appending. A responder writes the wrong IP, notices five minutes later, and reaches for the eraser. Don't. Leave the wrong line and add a new line: 13:47:12Z — CORRECTION: the IP recorded at 13:42:08Z was 10.0.0.42, not 10.0.0.24. Source: arp -a re-checked. The corrected notebook is unforgeable in a way the silently-fixed one is not.

The mechanical implementation can be a paper composition book with consecutive page numbers, or a private Git repository with signed commits, or an append-only file with hash-chained entries (each entry includes the SHA-256 of the previous one, blockchain-style). All are valid. What matters is that entries cannot be plausibly altered after the fact.

The 2019 Capital One breach is the published case study where documentation quality won the day. The bank produced for the US Office of the Comptroller of the Currency a precise UTC timeline of when the suspicious access pattern was first noticed (an external researcher's email, archived with full headers), when the affected bucket was first restricted, when each cloud key was rotated, when each affected customer cohort was identified, and when each external notification was sent. The regulator still fined the bank — eighty million US dollars — but the documentation itself was treated as evidence of a mature response, and that mattered for the size of the fine.

The single most common cause of evidence contamination during the first hour is not malice and not incompetence — it is enthusiasm. Three people who all want to help reach for the same machine. The desktop technician opens the user's mailbox to "see what came in" and overwrites the access timestamp on the malicious attachment. The system administrator restarts the suspect server and destroys running malware in memory. The security analyst browses to the attacker's command-and-control domain from the corporate network and tips off the adversary. None did anything wrong by their own job description. They simply did not coordinate.

The classic six-role structure derived from NIST SP 800-61 Rev. 2 and the SANS Incident Handler's Handbook:

• Incident Commander (IC). The single decision-maker. Authorises actions, manages timelines, protects the team's focus. The IC decides when to pull the network cable and when to escalate to law enforcement. Without an IC, the response degenerates into a committee — the worst kind of response.
• First Responder / Forensic Analyst. The hands at the keyboard. Runs the volatile capture script, takes the memory image, seals the evidence bag. Their discipline is to follow the playbook exactly and resist the urge to investigate before they have collected.
• Communications Lead. The single voice to the rest of the organisation, customers, and (if applicable) press. Stops technicians from giving inadvertently misleading updates while the investigation is incomplete.
• Legal & Compliance Liaison. The bridge to the lawyers and external regulators. Watches the GDPR Article 33 / HIPAA Breach Notification Rule / PCI-DSS requirement 12.10 clocks so the technical team does not have to.
• Subject-Matter Expert (SME). A floating role filled by whoever knows the affected system best — DBA (Database Administrator) for a database breach, network engineer for a routing anomaly, developer for an application-layer compromise. SMEs advise; they do not act independently.
• Scribe / Documentation Officer. The keeper of the contemporaneous notebook from Lesson 4. In small teams this merges with the first responder; in larger ones a dedicated scribe is invaluable.

The tool that codifies the boundaries is the RACI matrix — every action down one axis, every role across the other, each cell filled with one of four letters (Responsible, Accountable, Consulted, Informed). Print it on A3, laminate it, and stick it to the wall of the war room. When the question "who restarts the server?" is asked at 03:14, the answer is not a debate; it is in the matrix.

The 2017 Equifax breach is the textbook role-confusion case. The published US House of Representatives report reads, in places, like a checklist of role failures: no clearly-named Incident Commander when the breach was first detected internally, decisions taken by committee, the website set up for affected consumers was hosted on a domain not owned by Equifax (making it indistinguishable from a phishing site — a Communications Lead with authority would have rejected that), and the Scribe role was effectively absent so the Congressional report had to assemble the timeline from email archives instead of a contemporaneous notebook. Equifax ultimately settled with the US Federal Trade Commission and a coalition of state attorneys general for approximately seven hundred million US dollars.

Malware research has many sub-categories, but for incident handling six core families cover almost everything. Memorise them — they appear on every certification exam and every job interview:

• Virus. Needs a host file to live; attaches to an executable, document, or script and runs when the user opens the host. A virus on a USB stick that nobody plugs in is harmless.
• Worm. Self-propagating; finds vulnerable services on the network and copies itself across with no user interaction. WannaCry crossed continents in hours because it was a worm.
• Ransomware. Encrypts files (or whole drives) and demands payment for the decryption key. Modern ransomware is usually a double-extortion game — pay or we publish your data. LockBit, BlackCat (ALPHV), Royal — same technical mechanism (encryption), same business model (extortion).
• Trojan. Pretends to be useful software. The user installs it on purpose because it looks like a free Photoshop, a "system optimiser", or a game crack. Once running, the trojan opens a backdoor.
• Rootkit. Designed to hide. Modifies the operating system — sometimes the kernel itself — so infected processes, files, and network connections become invisible to standard tools like ps, Task Manager, or netstat. Rarely comes alone; usually brings spyware or backdoors with it.
• Spyware. Silently collects information — keystrokes, screenshots, browser history, saved passwords — and ships it to the attacker. The most famous modern example is Pegasus, the NSO Group commercial surveillance product that targeted journalists and activists.

The lines blur in real malware: WannaCry was a worm that delivered ransomware. Emotet started as a banking trojan and finished its life as a malware-loader-as-a-service. NotPetya looked like ransomware but was a wiper — destruction was the goal and the ransom note was theatre. When you classify, classify the primary behaviour right now.

An IoC (Indicator of Compromise) is any forensic artefact observed on a network or in an operating system that, with high confidence, indicates an intrusion has occurred. The phrase was popularised around 2010 by Mandiant (now part of Google Cloud) when they published their work on the APT1 (Advanced Persistent Threat) group. Before that, intrusion detection was mostly signature-based and event-by-event; IoC thinking turned it into pattern-of-life thinking.

Five categories of IoC:

• File-based. Cryptographic hashes (MD5 — Message Digest 5 — has known collisions since 2008; SHA-1 — Secure Hash Algorithm 1 — was broken in 2017 by the SHAttered attack from Google and CWI Amsterdam; SHA-256 is the modern standard), file names and paths (svchost.exe in C:\Users\Public\ is suspicious because the real one lives in C:\Windows\System32\), file size and timestamps.
• Network-based. IP addresses (run them through AbuseIPDB and VirusTotal), domain names (random-looking domains like xkrjvbsiq.duckdns.org are often DGA — Domain Generation Algorithm — C2/Command-and-Control), URLs, TLS (Transport Layer Security) fingerprints (JA3 and JA3S hash the way a client/server negotiates TLS).
• Host-based. Registry keys (HKCU\Software\Microsoft\Windows\CurrentVersion\Run is the classic Windows persistence spot), scheduled tasks, services, mutexes (the WannaCry mutex Global\WannaCryptor is a famous example).
• Behavioural (TTPs) — Tactics, Techniques, and Procedures, described in the MITRE ATT&CK framework. Examples: T1059.001 (PowerShell execution), T1486 (data encrypted for impact, i.e. ransomware), T1543.003 (Windows service persistence).
• IoA (Indicator of Attack). A more modern term popularised by CrowdStrike. IoCs say what attacked you (static fingerprint); IoAs say how (intent and behaviour). You want both.

The single most quoted concept in IoC work is David Bianco's Pyramid of Pain (2013), which ranks IoCs by how much pain it costs the attacker to change them. From easiest (and most worthless from a defender's standpoint) to hardest:

• Hash values — trivial to change (recompile).
• IP addresses — trivial (VPN, Tor).
• Domain names — easy (register a new one).
• Network/host artefacts — annoying.
• Tools — hard (development cost).
• TTPs — very hard.

Implication for your career: signature-based blocking on hashes and IPs is necessary but cheap to defeat. Behavioural detection lasts months instead of hours. The senior SOC analyst is the one who writes the behavioural rule.

In practical sweep work, three independent IoCs from different categories pointing at the same target equals rope — escalate. One IoC in isolation might be a false positive. Three is not.

The golden rule, written in capitals because it is the rule everything else builds on:

CONTAIN, DO NOT POWER OFF.

Pulling the plug on an infected host feels right, is fast, is decisive — and is one of the worst things you can do. You destroy RAM (which holds running processes, network connections, decryption keys, injected code, cached SSO — Single Sign-On — credentials). You break the timeline. You teach the malware (modern malware detects shutdown signals and triggers anti-analysis or wiper code paths). You cannot easily un-power-off — once it is off, the only way back is a reboot, and reboot is exactly when persistence mechanisms re-engage.

Instead, isolate the host while keeping it running. Network segmentation, EDR "contain device" buttons, firewall rules on pfSense or OPNsense — all of them keep memory and processes alive while cutting off the attacker.

NIST splits containment into three time horizons:

• Short-term containment (minutes). The fire is burning. Stop the spread NOW. Disconnect the host from the network at the NIC (Network Interface Controller) level rather than power, kill the malicious process, block the C2 domain at the DNS resolver, isolate at the EDR.
• Long-term containment (hours to days). Keep the attacker busy while planning a clean eradication. Allow-list legitimate processes only, redirect attacker traffic to a sinkhole, deploy honeytokens to detect lateral movement.
• Sustained containment (days to weeks). Maintain a quarantine zone for forensic analysis while business operations continue elsewhere.

Crown-jewel protection matters: when a malware outbreak begins, you protect the high-value assets first — domain controllers, finance systems, anything with regulated data — even if the active fire is somewhere else. Attackers do not stay where they landed; they move toward value.

Containment buys time. Communication wins or loses the rest of the game. The most technically perfect response can still cost the company executives, market cap, and regulatory penalties if the comms are clumsy.

The picture: 02:14, ransomware on a payments server. Wrong answer — post in the corporate Slack #incidents channel, because if the attacker has been inside for a week (and average dwell time is roughly two to three weeks depending on the report), they may be reading that channel and will accelerate before you finish typing. Right answer — pick up your work phone, call the IR lead's mobile (a number saved before this happened), and read the situation aloud in plain language. Out-of-band communication.

Communication has four axes — WHO (audience: internal-technical, internal-leadership, internal-support, external), WHAT (message structure), WHEN (cadence by severity), HOW (channel ranked by integrity), and WHY (regulatory clock).

The SBAR pattern, borrowed from emergency medicine, works perfectly for an incident message:

• S — Situation (one sentence): "At 02:14 we detected ransomware on a payments server."
• B — Background (two sentences): "The server processes 8% of transaction volume. Initial vector appears to be a compromised VPN credential."
• A — Assessment (two sentences): "We have isolated the host. We do not yet know whether other hosts are affected. Forensic image in progress."
• R — Recommendation/Request (one sentence): "I need you on a call in five minutes; I am calling Legal next."

That format works for a pager, an email, a phone call, and a board update.

Channels ranked by integrity (highest first): face-to-face → personal mobile voice call → encrypted out-of-band messenger (a dedicated Signal group set up in peacetime) → personal email → corporate phone (VoIP) → corporate Slack/Teams → corporate email. Once an incident is confirmed, assume corporate channels are compromised and discuss IoCs only in a separate private war-room channel with restricted membership.

The regulatory clock summary, by region: GDPR — 72 hours from awareness; UK GDPR + Data Protection Act 2018 (enforced by ICO — Information Commissioner's Office) — 72 hours; HIPAA Breach Notification Rule — 60 days to individuals, "without unreasonable delay"; PCI-DSS — typically 24 hours to your acquirer; PIPEDA (Canada — Personal Information Protection and Electronic Documents Act) — "as soon as feasible" after determining real risk of significant harm; NIS2 — 24-hour early warning, 72-hour full notification. The key skill is not memorising the laws; it is knowing that legal counsel is one of your first calls, not your last.

• WannaCry (May 2017). A worm + ransomware combination linked by the US Treasury and UK NCSC (National Cyber Security Centre) to North Korean actor Lazarus Group. Vector: SMBv1 (Server Message Block v1) RCE (Remote Code Execution) via the EternalBlue exploit, originally NSA (US National Security Agency) code leaked by the Shadow Brokers in April 2017. Microsoft had patched it (MS17-010) two months before the outbreak. Within 24 hours WannaCry infected over 200,000 systems in 150 countries; the UK NHS (National Health Service) was hit hardest in the public eye. The famous kill switch — researcher Marcus Hutchins registered the long random domain the malware checked — stopped the spread within hours. Lesson: patch management cadence is not optional; segment networks; offline backups beat ransom payments.
• NotPetya (June 2017). A wiper disguised as ransomware, attributed by US and UK statements to Russian military intelligence (GRU). Vector: a compromised software update for M.E.Doc, a Ukrainian tax-accounting application; from there the malware spread via EternalBlue and stolen credentials. Total damage estimated at roughly $10 billion — the most costly cyberattack in history. The "ransom note" demanded $300 in Bitcoin to a single address, but the encryption was non-recoverable — paying changed nothing. Maersk's domain controllers were all wiped; the company was saved by a single domain controller in Ghana that had been offline due to a power outage during the attack, flown back to the UK to rebuild identity infrastructure (Andy Greenberg's WIRED article tells the story). Lesson: validate vendor update integrity not just origin; treat ransomware alerts as possibly destructive; geographic and offline backup diversity matters; read your cyber-insurance war-exclusion clause.
• Colonial Pipeline (May 2021). Ransomware (DarkSide). Vector: a compromised VPN account — single password, no MFA, password had appeared in a credential dump. The pipeline operator shut down a 5,500-mile fuel pipeline as a precaution even though OT (Operational Technology) was not directly affected; six days of outage and fuel panic across the US East Coast. Colonial paid roughly $4.4 million in ransom; the FBI later recovered approximately $2.3 million by tracing the cryptocurrency wallet. Lesson: MFA on every remote-access point, no exceptions; decommission unused VPN accounts immediately; OT/IT segmentation; engage law enforcement early.
• SolarWinds Sunburst (December 2020). Trojanised software supply chain attributed to Russian SVR (foreign intelligence) per a US joint statement. Vector: malicious code inserted into the SolarWinds Orion build pipeline; approximately 18,000 organisations downloaded the trojanised version, with a much smaller targeted subset including FireEye (now Trellix/Mandiant) and parts of the US federal government. FireEye discovered the campaign while investigating their own intrusion. Lesson: detect anomalous behaviour, not just bad signatures (the trojanised binary was perfectly signed); secure the build pipeline like production; egress monitoring catches the C2 traffic eventually; frameworks like SLSA (Supply-chain Levels for Software Artefacts) address the structural issue.

In casual conversation people use "phishing" for everything. In an incident report you cannot — the four terms describe genuinely different attacks with different victim profiles, detection signatures, and financial impacts.

• Phishing (broad-net). Industrial-scale; the same email or small set of templates sent to thousands or millions of recipients hoping for a 0.1% click-through. Generic greeting ("Dear customer"), urgency language, mismatched display name and underlying address. The Anti-Phishing Working Group (APWG) tracks volumes quarterly. Detection is usually loud — bad grammar, suspicious sender domain — and modern email gateways catch the obvious ones.
• Spear-phishing (personalised). Phishing with reconnaissance. The attacker has spent time on you specifically — your LinkedIn profile, your company's website, maybe a conference where you spoke. The email is addressed to you by name, references a project you actually work on, and might come from what looks like a colleague's or supplier's address. Volume is low (sometimes a handful in one company), success rate is an order of magnitude higher than untargeted phishing. CISA publishes alerts on advanced campaigns; many state-aligned actors run these almost exclusively.
• Whaling (executive-targeted). Spear-phishing aimed at "big fish" — CEO, CFO, board members, Domain Administrators, cloud-account owners. Lures look like board communications, legal notices, or merger paperwork. The attacker has often profiled the target for weeks. The payoff: large wire transfer, crown-jewel data, or a foothold for trivial lateral movement. Whaling is a subset of spear-phishing distinguished by victim seniority.
• Business Email Compromise (BEC). The category that confuses students most. Often no malicious attachment and no malicious link at all. The attacker either compromises a legitimate corporate mailbox (via earlier phishing or credential-stuffing) or carefully spoofs one, then sends a perfectly-worded, perfectly-timed email asking finance to change a supplier's bank account, a junior employee to buy gift cards, or IT to reset a password. The FBI Internet Crime Complaint Center (IC3) consistently ranks BEC as the single most financially damaging cybercrime category — typically billions of dollars in reported losses each year, far more than ransomware in raw money terms. There is no malware for an EDR tool to catch.

Every phishing attack — laziest mass-mail to elegant BEC — decomposes into three sequential stages. Memorising them pays back in incident triage because they map cleanly onto which artefact you collect, which control failed, and which mitigation you apply.

• Lure construction (the artistry phase). The content the victim sees: subject line, sender name, body text, visual design, call-to-action. The attacker is doing creative writing. Good lures hit one or more of the six classic levers of social engineering documented systematically in Robert Cialdini's research (cialdini.com): authority ("from the IT department"), urgency ("expires in 24 hours"), scarcity ("only three slots remain"), familiarity/liking (copying a colleague's tone, name-dropping a real project), social proof ("your colleague Juan already approved this"), reciprocity ("we helped you last quarter"). Sophisticated lures stack multiple levers — almost no legitimate corporate email applies three at once.
• Hook delivery (the logistics phase). How the lure reaches the victim's screen. Channels: standard email over SMTP (Simple Mail Transfer Protocol), spoofed sender domain (which SPF/DKIM/DMARC are designed to stop — Lesson 3), look-alike domain (typosquatting like paypa1.com with a numeric "1", homograph attacks using Cyrillic characters that look Latin, sub-domain trickery like paypal.com.attacker.io), compromised legitimate mailbox, and adjacent channels (smishing — SMS phishing; vishing — voice; quishing — QR-code; chat-platform phishing on Slack, Teams, WhatsApp). The defender's job during this phase is to make hook delivery fail before it reaches the user.
• Payload execution (the conversion phase). Whatever the attacker actually wanted. Most common payloads: credential harvesting (user clicks a link, lands on a fake login page, types username and password into the attacker's form); malware execution (user opens an attachment — maliciously-crafted Office document, ISO file, password-protected ZIP, executable disguised as a PDF); drive-by browser exploit (rare today but still seen); direct human action (the BEC payload — the user just does what the email asked; wires money, changes a password, forwards a confidential document); token/session theft (increasingly important — the attacker harvests not just the password but the post-authentication session cookie or an OAuth token, bypassing MFA).

The three-stage model maps roughly onto the Lockheed Martin Cyber Kill Chain (Reconnaissance → Delivery → Exploitation/Installation/Actions on Objectives) and the MITRE ATT&CK framework. When you write up a phishing incident, you fill in details for those three stages — a clean report structure.

When email was designed in the 1970s, nobody verified the sender. SMTP (defined in RFC 5321) trusts the sender to tell the truth about who they are. The "From:" line is structurally just text the sender wrote. The internet has been retroactively bolting on authentication ever since.

• SPF (Sender Policy Framework, RFC 7208). Answers: is the server that just connected allowed to send mail for the domain it claims to be from? The owner of cyber.soho.example publishes a DNS (Domain Name System) TXT record listing every IP authorised to send for that domain — for example v=spf1 ip4:203.0.113.0/24 include:_spf.google.com -all (the -all is a "hard fail" — anything not on the list is asserted not to be us). What SPF does not protect against: an attacker who has compromised your real mail server, or one using a look-alike domain (a different domain entirely, so SPF does not even apply). Subtle gotcha: SPF breaks on email forwarding — the forwarding server appears as the sender to the final destination.
• DKIM (DomainKeys Identified Mail, RFC 6376). Answers: has this message been tampered with in transit, and was it signed by a server holding the domain's private key? The domain owner publishes a public cryptographic key in DNS under a "selector" name like default._domainkey.cyber.soho.example. The corresponding private key sits on the sending mail server. When the sending server emits an email, it signs selected headers and the body and attaches a DKIM-Signature: header. The receiver fetches the public key and verifies. DKIM survives forwarding (the signature stays attached) but breaks if a mailing list modifies the email by adding a footer or rewriting the subject.
• DMARC (Domain-based Message Authentication, Reporting & Conformance, RFC 7489; consortium home at dmarc.org). The policy layer on top. Answers: what should the receiver do when SPF and DKIM both fail, and what should they tell us about it after the fact? The owner publishes _dmarc.cyber.soho.example TXT v=DMARC1; p=reject; rua=mailto:dmarc@cyber.soho.example; pct=100. The p= tag is the policy — none (monitor only), quarantine (deliver to spam), or reject (refuse outright). The rua= tag points to where aggregate reports go — daily summaries of every IP claiming to be your domain. DMARC also enforces alignment — the SPF or DKIM domain must match the visible "From:" domain, closing the loophole where an attacker passes SPF/DKIM for some other domain they control while showing your domain in the From line.

A small consultancy with no SPF, no DKIM, no DMARC is structurally spoofable — an attacker on a $5-a-month VPS (Virtual Private Server) can send a perfect-looking invoice email purporting to be from accounts@mapleleafcode.example and the receiver has nothing to evaluate against. After publishing the three records with p=reject, the same attack returns 550 5.7.1 DMARC policy violation at the SMTP layer and never reaches the inbox. Cost to the company: roughly an hour of DNS configuration. Value: every spoof attempt against the domain now bounces at the receiver's edge.

A magic email gateway that blocked 99.9% of phishing emails sounds amazing, until you do the maths: a 5,000-employee company processing 91 million emails a year still sees 91,000 phishing emails reach inboxes annually. The only way to bring residual risk down is to train the humans. The cybersecurity industry's saying — "the user is the last line of defence — and also the first" — captures it: the user is first because they receive the lure, last because if every technical control has failed, only the user clicking or not clicking remains.

A bad awareness program is the one most companies still run: a 25-minute mandatory video once a year, multiple-choice quiz, certificate emailed to HR (Human Resources), checkbox ticked. Compliance achieved, behaviour unchanged.

A good awareness program (aligned with CISA's awareness materials and NIST SP 800-50 on building information-technology security awareness and training programmes) has these characteristics:

• Continuous, not annual. Drip-feed — short 2-4 minute micro-lessons monthly, not 25-minute marathons.
• Role-tailored. Finance lessons focus on BEC and invoice fraud. Engineer lessons focus on credential phishing and source-code-repository tokens. Generic training trains nobody well.
• Includes simulation. Periodic simulated phishing campaigns; clickers receive an immediate "this was a simulation" landing page; reporters get a quick thank-you. The point is never to punish the click — it is to find the awareness gap.
• Measurable. Track the report rate (how many people report a real or simulated phishing email) at least as carefully as the click rate. Many programs obsess over click rate and miss that report rate is more actionable — clicks happen anyway, but a high report rate gives early warning of campaigns in flight.
• Blameless. Public shaming for clicks produces a culture where users hide mistakes, which is catastrophic. Foster the opposite culture: "if you click and tell us within five minutes, you're a hero."
• Updated to current threats. A 2026 program that still uses 2019 lures (Nigerian princes, lottery winnings) is a museum exhibit.

What good training is not: not punishment, not a substitute for technical controls (SPF/DKIM/DMARC, MFA, email gateways, EDR all stay in place — awareness is a layer, not a replacement), not a one-time fix, and not just for non-technical staff (engineers and IT staff fall for phishing too, and their access tends to be more dangerous).

Generic IH&R applies, but email incidents have specific quirks: the artefact lives in cloud mailboxes (Microsoft 365, Google Workspace, Exchange Online) and is collected via API; the blast radius is everyone (a campaign rarely targets just one person — by the time one user reports, the same email is in 50 other inboxes); the attacker may already have the credentials and may notice when you start pulling logs; MFA bypass is now common (Adversary-in-the-Middle / AITM kits harvest the post-authentication session cookie, so password reset alone is insufficient — you must revoke active sessions); and the supply-chain effect is real (a compromise of a finance mailbox can pivot into BEC against the company's customers within hours).

The email-specific 6-phase playbook:

• Phase 1 — Preparation. Provision audit access (a "break-glass" role with read access to the email tenant's audit logs — Microsoft 365 Unified Audit Log, Google Workspace Audit Logs — message-trace tools, in-place eDiscovery). Know your retention windows (M365 default unified audit log is 180 days, longer with E5 licensing; Google Workspace audit logs typically 6 months). Pre-write one-page playbooks for "user reports phishing", "credentials confirmed phished", "BEC suspected". Set up the report channel (a "Report Phishing" button in the email client). Run quarterly tabletops.
• Phase 2 — Detection & Analysis. Trigger is usually one of three: a user reports through the dedicated channel (60-80% of email incidents in mature programmes — which is why Lesson 4 awareness directly enables Lesson 5), the email gateway flags something post-delivery (e.g. a URL that became malicious after delivery), or a downstream alert (anomalous sign-in, EDR detection, suspicious finance request). The analyst's first job is scoping — original sender, subject, content; how many internal recipients; how many opened, clicked, or executed; were any credentials submitted, tokens issued, or wires processed.
• Phase 3 — Containment. Purge the email from every recipient mailbox using the provider's purge tools (M365 Content Search + Purge, or Google Workspace Investigation Tool). Block the sender at the gateway including originating IPs and look-alike domains. Block malicious URLs at the web proxy and DNS filter. Reset credentials and revoke all active sessions — an attacker with a valid session token does not need the password. Disable any new mailbox rules the attacker created (a common attacker move is an inbox rule that auto-forwards or auto-deletes specific keywords like "invoice"). For BEC, contact the impacted external party on a known channel to halt in-flight wire transfers.
• Phase 4 — Eradication. Re-image any endpoint where malware execution was confirmed. Audit and remove all OAuth (Open Authorization) consents the user (or the attacker) granted to third-party applications — AITM kits often plant a malicious OAuth app for persistence even after passwords change. Force MFA re-enrollment; if a factor was compromised (e.g. SIM-swap), enrol a stronger factor. Hunt for lateral movement — sign-in logs from the compromised account during the attacker window, what other resources did it touch, were emails sent, did the account access SharePoint, Drive, or source-code repositories.
• Phase 5 — Recovery. Restore mailbox state after purging — verify legitimate emails were not accidentally caught. Re-enable accounts with fresh MFA. Verify monitoring is in place for the IoCs identified. Re-issue communication if external parties were affected.
• Phase 6 — Lessons Learned. Within two weeks, blameless retrospective. What was the gap (a missing DMARC policy, a user who had not taken recent training, a finance process that allowed IBAN — International Bank Account Number — changes without verification)? Which detection fired first? What playbook step took longest? What from this incident should be added to the next round of awareness training?

The first 30 minutes cheat-sheet when a user clicks "Report" on something real:

OWASP (the Open Worldwide Application Security Project) is a non-profit foundation, federated through hundreds of local chapters worldwide including OWASP Toronto and OWASP Boston. Its mission is the boring, important kind: gather what application-security practitioners actually see, distil it into checklists, training, free tools and standards, and give all of it away. The most-cited piece of work they publish is the OWASP Top 10, a ranked list of the ten most critical web-application security risks. The current edition is the OWASP Top 10 — 2021, and the next refresh is in active drafting.

The Top 10 is ten categories of risk, not "the ten worst vulnerabilities" — buckets, not bugs. Each bucket holds many specific CWE (Common Weakness Enumeration) entries maintained by MITRE. It is a floor, not a ceiling — necessary but not sufficient. Treating it as a compliance checklist ("we ticked all ten, we are safe") is a common, expensive mistake.

The 2021 list:

Three buckets dominate breach reports year after year: A01 Broken Access Control (the boring, devastating one — change ?invoice_id=42 to ?invoice_id=43 and read someone else's invoice; OWASP's own statistics across half a million applications found access-control failures in roughly 55% of tested apps); A03 Injection (SQL injection is genuinely declining as frameworks default to parameterised queries, but XSS — Cross-Site Scripting — is everywhere and command injection is having a renaissance through insecure server-side template engines); A06 Vulnerable & Outdated Components (the Equifax category — running a web framework with a public CVE for which a patch exists).

A nuance to internalise: most common ≠ most damaging. SSRF (A10) is rare in absolute terms — maybe one in ten apps — but in a cloud environment it can pivot into stolen cloud credentials in minutes, as it did in the Capital One breach in 2019.

• SQL injection (SQLi). Untrusted text is concatenated into a database query and the database treats part of it as code. The textbook payload ' OR '1'='1' -- turns SELECT * FROM users WHERE name='[input]' into a query that matches every user. Detection signatures include unusual single-quote density in URL parameters, UNION SELECT in request bodies, error responses leaking SQL syntax, and User-Agent strings like sqlmap/1.7. Response: identify whether any requests returned a 200 OK with payload content (those are confirmed reads), block the source IP at the WAF (Web Application Firewall), check the database query log for the rows the attacker actually saw, and escalate. Long-term remediation: parameterised queries (the default API of every database driver — the vulnerable form exists only because programmers reach for string concatenation out of habit).
• XSS (Cross-Site Scripting). Untrusted text is reflected into a page and the browser executes it as JavaScript. Three flavours: reflected (the malicious script is in the URL and runs only when a victim clicks the crafted link), stored (the script is saved in the application's data store — a comment field, a user profile — and runs for every visitor who views it), and DOM-based (the script runs through client-side JavaScript without ever touching the server). Detection: <script> tags in URL parameters, javascript: schemes, encoded variants like %3Cscript%3E. Response: invalidate active sessions, force password resets if cookies were exfiltrated, and remediate by output-encoding all user-supplied content.
• CSRF (Cross-Site Request Forgery). A victim who is already authenticated to your site visits an attacker-controlled page that triggers a state-changing request (transfer money, change email) using the victim's cookies. Defences: CSRF tokens (a unique unpredictable value tied to the session and submitted with every state-changing request), the SameSite cookie attribute, and re-authentication for sensitive actions.

A WAF (Web Application Firewall) like ModSecurity sits in front of the application and applies rule sets such as the OWASP Core Rule Set (CRS), scoring every request and blocking or alerting when the score crosses a threshold. The five-step detection-and-response loop on a WAF alert: triage (is fourteen hits in five minutes a typo or a campaign?), pivot to the source (reverse DNS, threat-intel reputation), pivot to the target (which endpoint, what payload), confirm whether anything got through (status=200 and payload content is the rope), escalate.

A line worth writing on the inside of your forehead: "the logs are not the truth; the logs are evidence; the analyst builds the truth from them." Logs are written by the very systems an attacker is trying to fool. A skilled attacker tries to delete, rotate, or poison the log. A novice leaves a confession. Most attackers fall in the middle.

Six layers of logs an incident responder pivots between:

• WAF / CDN log — every request that hit the perimeter, including blocks. (CDN = Content Delivery Network, e.g. Cloudflare, Akamai, Fastly.)
• Web server log — Apache access.log, Nginx access.log, IIS (Internet Information Services) *.log. HTTP method, URL, status code, response size, User-Agent.
• Application log — stack traces, authentication events, business actions like "user X exported the customer list".
• Database query log — slow queries, query errors, full-query auditing on sensitive tables.
• Operating-system log — new files, sudo invocations, new cron entries, new users.
• SIEM correlation layer — pulls from all of the above and lets you pivot across them in seconds.

The NCSA Combined Log Format is the default for most web servers:

203.0.113.42 - - [04/May/2026:23:11:02 +0200] "GET /api/v1/login?u=admin'+OR+1=1-- HTTP/1.1" 200 412 "-" "sqlmap/1.7"

Read left to right: source IP, identity (almost always -), authenticated user (almost always -), timestamp with timezone offset, request method, request line including the suspicious payload, HTTP status code (200 here means the SQLi worked), response size in bytes, referer, User-Agent (the attacker did not even bother to hide they were using sqlmap).

Status-code patterns worth watching: a sudden burst of 404s from one IP is reconnaissance (the attacker is probing for paths). A string of 500s is the application crashing on malformed input — possibly an exploit attempt. A 200 after a long string of 401s and 403s is a successful brute-force or authentication bypass.

Containment is not a single action; it is a sequence. The seven-rung containment ladder, aligned with NIST SP 800-61 Rev. 2:

• Confirm. Validate the alert is real. False positives waste resources and erode trust.
• Isolate. Pull the host from the network or move it to a quarantine VLAN. Cut the network before you cut the malware — if the attacker cannot see your cleanup, they cannot adapt.
• Preserve. Snapshot disk and memory before changing anything else. Evidence first. The ten minutes a snapshot takes saves you weeks later when forensics needs the disk image to identify exactly what was stolen, when the legal team needs the memory image because the running process held an unencrypted key, when communications needs to tell customers exactly what data was accessed (without evidence, you say "we cannot rule out").
• Eradicate. Identify and remove all webshells (a webshell is a small server-side script the attacker uploaded to give themselves remote command execution — common forms in PHP are c99.php, r57.php, <?php system($_GET['c']); ?>); inventory and remove attacker-created accounts (operating-system and application); remove persistence (cron, systemd timers, scheduled tasks, .bashrc injections, modified startup scripts); rotate every credential the host had access to (database passwords, API keys, SSH keys, OAuth tokens).
• Patch & Harden. Fix the underlying vulnerability (parameterise the SQL query for A03; update the library for A06; add the missing authorisation check for A01); harden the surrounding configuration (remove verbose error pages, disable directory listing, drop unused services); add the monitoring you wish you had had (if the breach was invisible for a week, you have an A09 gap — close it).
• Restore. Rebuild from a known-good image. Redeploy clean code. Bring traffic back gradually — 10%, 50%, 100% — watching the WAF logs at each step.
• Lessons Learned. A blameless post-mortem 2-5 days later. Three concrete runbook updates. Owners and deadlines.

Under Canada's Personal Information Protection and Electronic Documents Act (PIPEDA), Quebec's Law 25, and U.S. state breach-notification regimes (Colorado's 30-day rule, Illinois' PIPA, Massachusetts' 201 CMR 17.00, California's CCPA, and HIPAA's Breach Notification Rule for healthcare data), failure to demonstrate due diligence in the response phase can multiply the regulatory and civil exposure. Preservation is not optional bureaucracy; it is your defence. Whichever clock applies to your jurisdiction, it starts at "becoming aware" — or, in the Canadian phrasing, at "determining real risk of significant harm" — not at "fully understanding". As an incident responder you do not own the legal notification, but you do own the clock — and your manager will need an honest, documented "we became aware at this timestamp" entry in your timeline.

• Equifax, 2017 — 147 million records. A clean A06 — Vulnerable & Outdated Components case. On 7 March 2017 the Apache Software Foundation published CVE-2017-5638, an RCE flaw in Apache Struts; a patch shipped the same day. Equifax's internal email instructed teams to patch within 48 hours. One critical web application was missed. On 13 May, attackers exploited the unpatched Struts on Equifax's online-disputes portal. They moved laterally for 76 days before an internal SOC analyst noticed unusual traffic on 29 July. Public disclosure on 7 September. The single most important number: 67 days from public CVE to attacker exploit. The attacker's reconnaissance window — from "patch is publicly known" to "this victim has not patched yet" — is now measured in weeks. The fix was a one-line dependency update; the failure was process, not code. Recommended further reading: the US Government Accountability Office's 2018 report, 38 pages, reads like a thriller.
• British Airways, 2018 — 380,000 cards. An A08 — Software & Data Integrity Failures case, specifically a client-side supply-chain attack known as Magecart. Attackers compromised a third-party JavaScript file that BA's website loaded on the payment page. The injected script intercepted form submissions and sent card data to an attacker-controlled domain that mimicked a legitimate BA subdomain. No SQLi, no traditional vulnerability, no zero-day — there was a checkbox in the supply chain that was not ticked. The UK ICO initially proposed a £183 million fine, later reduced to £20 million on appeal — one of the first major GDPR enforcement actions in Europe. Modern web pages are not just your code; they are your code plus 40 third-party scripts. Each is a vulnerability you do not control. Subresource Integrity (SRI) — a browser feature that binds a script to a hash so a tampered version refuses to run — is the simplest defence (Mozilla Developer Network's SRI documentation is a 10-minute read).
• Capital One, 2019 — 106 million records. An A10 — Server-Side Request Forgery case, with cloud privilege as the amplifier. A web application accepted a user-supplied URL parameter and fetched it server-side. The attacker (a former AWS — Amazon Web Services — employee) pointed it at the cloud-instance metadata endpoint http://169.254.169.254/, the special address from which a virtual machine reads its own IAM (Identity and Access Management) credentials. The application politely fetched and returned the credentials. The attacker used them to read S3 (Simple Storage Service) buckets full of personal data. SSRF in 2010 was a curiosity; SSRF in a cloud environment in 2026 is a credential-theft tool. Block outbound requests to link-local and private ranges from your web tier, full stop, by default, before you even think about CVEs.

The pattern across all three: none were prevented by perimeter security (all got through the firewall the legitimate way); all were detected by humans, not tools (tooling buys you the data; humans buy you the conclusion); all could have been contained faster; all triggered regulatory action.

The post-mortem on a small web-app incident has a specific shape — the IR lead opens with three sentences that are not decoration but the technical specification of a blameless review: "we are not here to assign blame; we are here to find what made this possible", "every name in this room is here because they have something to teach us, not because they did something wrong", "the output of this meeting is three runbook changes, not three resignations". Without those sentences, the meeting becomes a witch hunt and the organisation learns nothing.

The numbers you extract from the timeline, every time: TTD (Time to Detect), TTC (Time to Contain), total attacker dwell time. The IBM Cost of a Data Breach Report puts the industry mean time to identify a web-app breach above 200 days for several years running. Single-digit hours is world class; months is normal — and a clear improvement target.