Close Menu

    SIEM and Incident Response Practice: 5 Realistic Scenarios

    Learn how a SIEM helps you spot trouble and how the NIST incident response lifecycle guides what you do next. Then practise on five scenarios, each with alerts, an analysis walkthrough and a sample escalation note.

    Independent study aid. Not affiliated with or endorsed by Google or Coursera. All scenarios, names, addresses and notes are invented for practice (IPs use documentation ranges). Follow your own organisation’s playbooks in real work.

    1. The NIST incident response lifecycle

    The widely taught model comes from NIST SP 800-61 and has four phases that loop back on each other. NIST has since published a newer revision that maps response activities to its Cybersecurity Framework; the classic four phases below are still the usual teaching model. Check NIST’s site for current versions.

    1. Preparation

    Playbooks, contact lists, logging, tools, training and practice drills before anything happens.

    2. Detection and analysis

    Spot alerts, decide if they are real, scope the impact, rate severity and document.

    3. Containment, eradication, recovery

    Stop the spread, remove the cause, restore systems safely and watch for return.

    4. Post-incident activity

    Review what happened, fix gaps, update playbooks and share lessons learned.

    2. SIEM basics

    A SIEM (security information and event management) tool gathers logs from many sources into one searchable place and raises alerts when patterns match.

    FunctionMeaningExample
    CollectPull in logs from devices and appsFirewall, email gateway, endpoints, servers, identity system
    NormaliseConvert varied formats to common fields“src_ip”, “user”, “action”
    CorrelateLink events across sourcesPhishing click followed by new process on same laptop
    AlertNotify when a rule matches10 failed logins in 5 minutes
    Search and reportInvestigate and show trendsAll logins by one user this week

    Triage questions for every alert

    • Who / what / where / when? User, host, IP, exact times (note the time zone).
    • Is it expected? Check change tickets, travel, approved scans.
    • True or false positive? Look for a second source that confirms it.
    • How far has it spread? Other hosts or accounts with the same indicator.
    • How severe? Think data sensitivity, system criticality and active vs. attempted.

    3. Five practice scenarios

    Try to write your own answer before opening each walkthrough.

    Scenario 1: Phishing with a clicked link

    Background: A finance employee reports an odd “invoice” email at 09:05.

    TimeSourceAlert / event
    09:02Email gatewayMessage from billing@acme-payments.example delivered to 14 users; display name mismatch
    09:07Web proxyUser m.rivera visited hxxp://acme-pay-login.example/verify (newly registered domain)
    09:08Identity logsm.rivera sign-in from 203.0.113.50 (new country)

    Analysis walkthrough

    1. Confirm the email is malicious: check sender domain age, headers, link target (view safely, never click).
    2. Scope: search the SIEM for all recipients and everyone who visited the domain.
    3. The sign-in from a new country right after the click suggests stolen credentials: treat as likely account compromise.
    4. Contain: reset password, revoke sessions, enable or check MFA, block the domain, pull the email from all mailboxes.
    5. Check the mailbox for new forwarding rules and review actions taken during the foreign session.
    6. Recover and learn: confirm account is clean, notify users, add detection and training.
    Sample escalation note: “Subject: Confirmed phishing, probable account compromise (m.rivera). At 09:02 a phishing email reached 14 users. At 09:07 m.rivera visited a lookalike login page; at 09:08 a sign-in came from 203.0.113.50 (unusual location). I reset the password, revoked sessions and blocked the domain, and I am removing the email from the other 13 mailboxes. Please review the mailbox for forwarding rules and decide on user notification. Next update 10:00.”
    Scenario 2: Ransomware on a file server

    Background: Helpdesk reports files with strange extensions and a note on a shared drive.

    TimeSourceAlert / event
    13:40Endpoint toolUnknown process on WS-221 launched from a temp folder
    13:46File server logsThousands of file renames by one user in 3 minutes
    13:49File serverNew file README_RESTORE.txt in many folders

    Analysis walkthrough

    1. Treat as high severity: mass renames plus a ransom-style note is strong evidence.
    2. Contain fast: isolate WS-221 from the network and disable the user account; consider blocking the share. Do not power machines off unless your playbook says so, since memory can hold evidence.
    3. Scope: find other hosts with the same file hash or process name and other folders touched.
    4. Preserve evidence: logs, the note, sample hashes.
    5. Escalate to the incident lead, management and legal. Decisions about payment, regulators and law enforcement are not the analyst’s alone.
    6. Recover from clean backups after the entry point is understood; check backups were not touched.
    Sample escalation note: “Subject: URGENT, suspected ransomware, file server FS-02. From 13:46 user t.okoye’s account renamed thousands of files, and a ransom note appeared in many folders at 13:49. Source workstation WS-221 ran an unknown process from a temp folder at 13:40. I isolated WS-221 and disabled the account at 13:55. Backup status is unverified. Need incident lead and legal engaged now, plus a decision on taking the share offline. Update every 30 minutes.”
    Scenario 3: Brute-force attack on a remote login

    Background: The SIEM fires a rule for repeated failed sign-ins on the VPN.

    TimeSourceAlert / event
    02:10-02:25VPN logs412 failed logins from 198.51.100.77 across 30 usernames
    02:26VPN logsSuccessful login for svc-backup from the same IP
    02:31Internal firewallsvc-backup account connecting to several servers it never used before

    Analysis walkthrough

    1. Many users, one source and short window: this is password spraying or brute force, not a forgotten password.
    2. The key question is whether any guess succeeded. It did: svc-backup logged in right after.
    3. Unusual lateral connections confirm misuse: this is now an incident, not just an attempt.
    4. Contain: disable or reset the service account, kill active VPN sessions, block the source IP.
    5. Investigate what the account touched; check whether MFA was missing and whether the password was weak or reused.
    6. Improve: add lockout and MFA, restrict service accounts, tune the alert.
    Sample escalation note: “Subject: Successful brute force, svc-backup VPN. 412 failures from 198.51.100.77 between 02:10 and 02:25, then a successful login as svc-backup at 02:26. By 02:31 the account was reaching servers it does not normally use. I disabled the account, ended its sessions and blocked the IP. Please review server access on the affected hosts and confirm credential rotation for related accounts.”
    Scenario 4: Data exfiltration

    Background: A data-loss rule flags large outbound traffic from an engineering laptop.

    TimeSourceAlert / event
    Tue 23:15Endpoint toolArchive tool created a 4 GB file from the source-code folder
    Tue 23:40Proxy3.8 GB uploaded to an unfamiliar file-sharing site
    Tue 23:42DNS logsSame host queried the site’s domain for the first time

    Analysis walkthrough

    1. Compare to the host’s baseline: does this person ever upload at night or use that site?
    2. Establish what was in the archive (file names, sensitivity) from endpoint logs.
    3. Check whether the user was active, or whether malware or a stolen session is the cause.
    4. Contain: block the destination, isolate the laptop if compromise is suspected, preserve disk and proxy evidence.
    5. Escalate early to security leadership, legal and HR as per policy; data exposure may trigger notification duties.
    6. Avoid accusing the user. State facts and let the investigation decide intent.
    Sample escalation note: “Subject: Possible data exfiltration, source code, laptop ENG-118. On Tuesday at 23:15 a 4 GB archive was created from the source folder, and 3.8 GB was uploaded to an unapproved file-sharing site at 23:40. This is out of pattern for the user. I blocked the site and preserved proxy and endpoint logs. Request legal and management review, a decision on isolating the laptop, and confirmation of what the repository contained.”
    Scenario 5: Insider threat

    Background: An employee who resigned last week shows unusual access.

    TimeSourceAlert / event
    MonHR note (via manager)Employee d.nguyen gave notice, leaving Friday
    Wed 19:30Document systemd.nguyen opened 600 customer files outside their own region
    Wed 19:55Email gatewayMultiple attachments sent to a personal webmail address

    Analysis walkthrough

    1. Resignation plus unusual bulk access is a recognised risk pattern, but it is not proof of wrongdoing.
    2. Check whether the access fits the job (handover work?) and whether policy allows personal email forwarding.
    3. Handle quietly and need-to-know: involve your manager, HR and legal before any contact with the employee.
    4. Preserve logs and email copies with proper chain of custody.
    5. Typical controls: limit access, increase monitoring, plan the exit process and device return.
    6. Keep records factual and neutral.
    Sample escalation note: “Subject: Confidential, unusual access by departing employee. After giving notice, d.nguyen opened about 600 customer files outside their region on Wednesday evening and sent several attachments to a personal address at 19:55. I have preserved the relevant logs. I have not contacted the employee. Please involve HR and legal, and advise whether to restrict access before Friday. Please keep this need-to-know.”

    4. Common mistakes

    • Closing alerts without a second source to confirm the verdict.
    • Skipping the scope step, so one infected host becomes ten.
    • Wiping or rebooting systems before evidence is saved.
    • Vague notes. Always include times, hosts, users and actions already taken.
    • Blaming people in reports instead of stating facts.

    5. Practice questions (tap to reveal)

    Q1. Name the four NIST phases.

    Preparation; detection and analysis; containment, eradication and recovery; post-incident activity.

    Q2. What does correlation add over single logs?

    It connects events across sources, such as a link click followed by a foreign sign-in, revealing attacks no single log shows.

    Q3. In the brute-force case, what turned an attempt into an incident?

    A successful login from the attacking IP, followed by unusual internal activity.

    Q4. Why preserve evidence before restoring a system?

    Restoring can overwrite logs and files needed to learn how the attack happened and to support legal action.

    Q5. Why keep insider cases need-to-know?

    Early exposure can tip off the person, damage an innocent employee’s reputation, and weaken the investigation.

    6. YouTube search links

    7. One-screen revision summary

    • Lifecycle: prepare, detect and analyse, contain/eradicate/recover, learn.
    • SIEM: collect, normalise, correlate, alert, search.
    • Triage: who, what, where, when; expected?; confirmed by a second source?; scope; severity.
    • Contain first, preserve evidence, then recover.
    • Escalation note: what, when, affected, evidence, actions, request, next update.
    • Insider cases: neutral facts, HR and legal, need-to-know.

    ← Back to hub

    Related pages

    Educational summary for learners; not affiliated with Google or Coursera. All scenarios are fictional. Verify details against official materials. Last reviewed: October 2026.