Browse CTFs New CTF Sign in

The PICERL Lifecycle: How Incidents Are Managed

incident_response Difficulty 1–2 45 min certifiable

Theory

Prerequisites

  • FND-K001: CIA Triad & the Modern Threat Landscape
  • COA-K001: SOC Architecture & Alert Lifecycle (recommended)

Why This Lesson Matters

Imagine a fire breaking out in a building. The fire department does not arrive and immediately start knocking down walls. They follow a protocol: assess the situation, contain the fire, rescue victims, extinguish, then investigate the cause. Skip any step and people get hurt or the building is destroyed unnecessarily.

Incident response works exactly the same way. A practitioner who jumps straight to "nuke and rebuild" without first containing the threat may destroy forensic evidence, miss persistence mechanisms, and find the attacker back inside a week later. The PICERL framework is the protocol that prevents these mistakes.


1. PICERL at a Glance

PICERL is one of the most widely taught IR lifecycle models. It has six phases:

Preparation → Identification → Containment → Eradication → Recovery → Lessons Learned
     P              I               C               E             R            L

Think of it as a story: you prepare before the attack, you identify that something is wrong, you stop it spreading, you remove it, you rebuild safely, then you learn so it does not happen again.


2. Phase by Phase

Phase 1 — Preparation (P)

Preparation happens before any incident. It is the least exciting phase and the most important.

What you build Why it matters
IR runbooks / playbooks Step-by-step guides so analysts do not improvise under pressure
IR team contacts and escalation tree You cannot google "who to call" during a P1 at 3 AM
Pre-authorised forensic toolkits Tools on every server ready to use without a change request
Communication templates Draft regulatory notification emails before you need them
Tabletop exercises Practice the plan so gaps appear in training, not in production

Analogy: A surgeon does not decide how to perform open-heart surgery in the operating room. They trained for years and have a sterile kit ready before the patient arrives.

Phase 2 — Identification (I)

This is when you answer: Did an incident actually occur?

An alert is not an incident. An anomaly is not an incident. An incident is a confirmed or highly probable violation of your security policy with a real business impact.

Alert fires
    ↓
Triage: Is this a true positive?
    ↓
If TP: What is affected? How many systems? What data?
    ↓
Classify severity (P1–P4) and formally declare the incident

Key question to answer in Identification:

"What is the scope of impact right now, and is it growing?"

If impact is contained to one system → P3/P4. If attacker is actively moving through the network → P1.

Phase 3 — Containment (C)

Containment stops the bleeding. It does not fix the problem — it stops it from getting worse.

Short-term containment (immediate, minutes): - Isolate the affected host from the network (pull cable, disable port, VLAN reassignment) - Block the C2 IP at the firewall - Disable the compromised account

Long-term containment (hours to days): - Rebuild to a clean state only after forensics are complete - Apply patches that close the initial access vector - Change all credentials that may have been exposed

The containment dilemma: Sometimes you want to monitor before isolating — to understand the full scope or let the attacker reveal other compromised hosts. This is a deliberate decision, not neglect. Document the reasoning.

Phase 4 — Eradication (E)

Eradication removes everything the attacker installed or modified: - Malware binaries and dropped files - Persistence mechanisms (services, scheduled tasks, registry run keys, cron jobs) - Backdoor user accounts - Web shells - Modified configuration files

Common eradication mistake: Reimaging a system without first checking whether the attacker has persistence on other systems. The malware comes back because you only cleaned one host out of three.

Phase 5 — Recovery (R)

Recovery is returning systems to normal operation — but only after you are confident the threat is gone.

Recovery checklist: 1. Restore from a known-clean backup (not a backup from after the compromise) 2. Apply all relevant patches 3. Reset all credentials that touched the compromised systems 4. Validate the restore: do integrity checks, confirm services are healthy 5. Monitor intensively for 72 hours after restoration

Analogy: After a flood, you do not move furniture back in until the walls are dry and the structural damage is repaired.

Phase 6 — Lessons Learned (L)

The lessons learned phase closes the loop. Without it, the same incident happens again.

The output is a post-incident report (covered in CIR-K011) plus a set of control improvements with owners and deadlines:

Control gap Improvement Owner Due
No MFA on VPN Deploy MFA for all VPN users IT team 30 days
SSH password auth enabled Disable password auth, key-only SysAdmin 7 days
No EDR on legacy servers Deploy EDR agent Security team 60 days

3. Incident Severity and SLAs

Every organisation needs a severity classification. This table is a common standard:

Severity Definition Example Contain within
P1 — Critical Active breach, ongoing exfiltration or encryption Live ransomware, active C2 1 hour
P2 — High Confirmed compromise, spread possible LSASS dumped, lateral movement started 4 hours
P3 — Medium Suspected compromise, investigation ongoing Malware found, no confirmed execution 24 hours
P4 — Low Policy violation, low-confidence anomaly USB inserted, failed login 72 hours

Why SLAs matter: Without a P1 = 1-hour containment target, analysts make different decisions about how urgently to act. Explicit SLAs create accountability and help management understand resource needs.


4. The Containment Decision: Isolate or Monitor?

This is the hardest real-time decision in IR. Use this mental model:

Is active exfiltration happening right now?
    YES → Isolate immediately. Data loss beats intelligence gathering.
    NO  ↓
Is this the only compromised host?
    UNSURE → Monitor briefly (15–30 min) to see where the attacker moves.
             Set a hard timer. Monitoring with no timeout is not monitoring, it is inaction.
    YES → Isolate and investigate.

Document every containment decision with a timestamp and rationale. Decisions made at 3 AM will be reviewed in the cold light of day.


5. Common Mistakes

Mistake 1: Skipping straight to rebuilding. Reimaging a system before collecting forensic evidence destroys the investigation. Always image first, remediate second.

Mistake 2: Partial containment. Blocking one malicious IP while the attacker has three backup C2 channels is not containment — it is a false sense of security.

Mistake 3: Treating every alert as an incident. Declaring P1 for every anomaly exhausts the team and creates alert fatigue. The Identification phase exists to filter signal from noise.

Mistake 4: Not updating the scope estimate throughout the incident. The scope at T+2 hours is different from the scope at T+0. Continuously reassess as new evidence arrives.


6. Practice Exercises

  1. A SIEM alert fires at 14:30: "Encoded PowerShell executed on WS-042." You investigate and find the decoded command downloads a second-stage payload. At 14:45, you see a lateral movement event to SRV-001. Classify the severity (P1–P4) at 14:30 and again at 14:45. What changes and why?

  2. You are the IR lead. Legal asks you to keep the compromised system online to gather evidence against the attacker. The attacker has access to a database containing 50,000 customer records. What is your response?

  3. Map each action to a PICERL phase:

  4. Deploying an EDR agent on all servers after a ransomware incident
  5. Disabling a compromised service account
  6. Restoring a file server from last night's backup
  7. Running a tabletop exercise with the executive team
  8. Identifying that the initial access was a phishing email

7. Lab

Assessment mode: quiz

8 scenario questions covering: - Phase identification for described actions - Severity classification for described incidents - Containment decision (isolate vs monitor) for described scenarios

A score of ≥ 75% is required to pass.


8. Framework Alignment

Framework Role Competency Confidence
CCSSF-CIR Cyber Incident Responder IR lifecycle application High
CCSSF-COA Cyber Security Operations Analyst Incident escalation and IR handoff Medium
CCSSF-ISSO ISSO / Generalist IR governance and programme design Medium
NICE 2.2.0 Incident Responder (PR-IRP-001) K0041 — Incident response procedures High

9. Further Reading

  • NIST SP 800-61 Rev.2 — Computer Security Incident Handling Guide (free, 79 pages) — the authoritative US reference
  • SANS Incident Handler's Handbook — Free; practical step-by-step companion to PICERL
  • Google Project Zero Incident Retrospectives — Real post-incident reports from one of the best IR teams in the world
  • "The Practice of Network Security Monitoring" — Richard Bejtlich — Chapter on IR workflow

Learning Objectives

["Name the six PICERL phases in order and describe the primary objective and one concrete output of each", "Classify a described incident at P1 through P4 using the severity table and justify the classification with specific evidence from the scenario", "Apply the containment decision framework to decide whether to isolate or monitor a compromised host, given information about active exfiltration and scope uncertainty"]

Lesson Outline

Prerequisites → Why this matters (fire brigade analogy) → PICERL phases (P through L with analogies and concrete outputs) → Severity classification with SLA table → Containment decision mental model (flowchart) → Common mistakes → Practice exercises → Quiz lab → Framework alignment → Further reading