Use this skill when responding to security incidents, conducting forensic analysis, containing breaches, or writing incident reports. Triggers on security incident, breach response, forensics, containment, eradication, recovery, incident report, IOC analysis, and any task requiring security incident management.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Une commande directe contourne le prompt de vérification. Examinez la source avant de l'exécuter.
Use this skill when responding to security incidents, conducting forensic analysis, containing breaches, or writing incident reports. Triggers on security incident, breach response, forensics, containment, eradication, recovery, incident report, IOC analysis, and any task requiring security incident management.
When this skill is activated, always start your first response with the 🧢 emoji.
Security Incident Response
A practitioner's framework for detecting, containing, and recovering from security
incidents. This skill covers the full NIST incident response lifecycle - preparation
through lessons learned - with emphasis on when to act, what to preserve, and
how to communicate under pressure. Designed for engineers and security practitioners
who need to respond with speed and precision when a breach is suspected or confirmed.
When to use this skill
Trigger this skill when the user:
Suspects or confirms a security breach, intrusion, or unauthorized access
Needs to classify incident severity and decide on escalation
Is containing a threat (isolating systems, revoking credentials, blocking IPs)
Needs to preserve forensic evidence or maintain chain of custody
Is communicating an incident to stakeholders, executives, or regulators
Is eradicating malware, backdoors, or persistent access from systems
Is writing a security incident report or post-mortem
Do NOT trigger this skill for:
Proactive security hardening or architectural review (use the backend-engineering
security reference instead)
Vulnerability disclosure or bug bounty triage that has not yet become an active
incident
Key principles
Contain first, investigate second - Stopping the bleeding takes priority over
understanding the wound. Isolate affected systems before collecting forensic
evidence if the attacker still has active access. Evidence is recoverable; damage
from continued access may not be.
Preserve evidence - Everything you do to an affected system changes it. Use
read-only mounts, memory snapshots, and write blockers. Log every command you run.
Courts and regulators require chain of custody.
Communicate early and often - A 30-second "we are investigating" message is
better than silence for three hours. Stakeholders need to plan. Delayed notification
erodes trust far more than the incident itself.
Document everything in real-time - Keep a live incident timeline. Record every
action taken, every finding, every decision, and every person involved. Memory fades
in 24 hours; your logs won't.
Never blame - Incidents are system failures, not individual failures. A
post-mortem that names a person instead of fixing a process produces fear, not
improvement. Apply the same principle as SRE blameless post-mortems.
Core concepts
NIST IR Phases
The NIST SP 800-61 framework defines six phases that form the backbone of any
structured incident response program:
Verified clean systems returned to production, monitoring confirmed
Lessons Learned
Improve defenses and process based on what happened
Post-mortem report, process changes, new detections
Phases are not always strictly sequential. Containment and eradication can overlap.
Detection and analysis continues throughout the entire response.
Severity Classification
Assign severity at detection time. Reassess as facts emerge.
Severity
Definition
Response SLA
Example
P1 - Critical
Active breach with ongoing data exfiltration or system compromise
Immediate, 24/7 response
Attacker has shell on production DB, ransomware spreading
P2 - High
Confirmed compromise but impact is contained or unclear
Response within 1 hour
Stolen API key used, single host compromised, credential stuffing succeeding
P3 - Medium
Suspicious activity with no confirmed compromise
Response within 4 hours
Anomalous login from new country, unusual outbound traffic spike
P4 - Low
Potential indicator, no evidence of compromise
Next business day
Single failed login attempt, phishing email reported but not clicked
When in doubt, escalate to a higher severity. Downgrading is always easier than
explaining why you under-responded.
Chain of Custody
Chain of custody is the documented, unbroken record of who collected, handled, and
transferred evidence. Required for:
Legal proceedings or law enforcement cooperation
Regulatory compliance (HIPAA, PCI-DSS, GDPR)
Insurance claims
Internal disciplinary actions
Every piece of evidence needs: what it is, when it was collected, who collected it,
where it has been stored, and who has accessed it since collection.
IOC Types
Indicators of Compromise (IOCs) are artifacts that indicate a system may have been
compromised. Categories:
Type
Examples
Volatility
Atomic
IP addresses, domain names, email addresses, file hashes
TTP patterns (MITRE ATT&CK techniques), lateral movement indicators
High - most durable signal
Prefer behavioral IOCs for detection rules. Atomic IOCs burn quickly as attackers
rotate infrastructure. Map findings to MITRE ATT&CK techniques when possible - it
enables cross-team communication and threat intelligence sharing.
Common tasks
Detect and classify an incident
When an alert fires or suspicious activity is reported, your first job is triage.
Initial triage checklist:
What triggered the alert or report? (alert, user report, third-party notification)
What systems and data are potentially affected?
Is the attacker likely still active (ongoing) or was this historical activity?
Is PII, PHI, PCI, or other regulated data in scope?
What is the business impact if this is confirmed?
Severity matrix (quick reference):
Is an attacker actively operating in your systems right now?
YES -> P1. Activate incident response team immediately.
NO -> Is a confirmed compromise present (evidence of unauthorized access)?
YES -> P2. Assemble response team within 1 hour.
NO -> Is there suspicious activity with credible threat indicators?
YES -> P3. Assign responder, investigate within 4 hours.
NO -> P4. Log and monitor, review next business day.
Open an incident channel (e.g., Slack #inc-YYYY-MM-DD-shortname) and post the
initial severity assessment within 15 minutes of detection.
Contain a breach
Containment is the most time-critical action. Execute in two stages:
Short-term containment (immediate - do not wait for full investigation):
Isolate affected hosts from the network (network segment or pull the cable) without
powering them off - RAM evidence is lost on shutdown
Revoke or rotate all credentials that may have been exposed
Block attacker-controlled IPs and domains at the firewall and DNS level
Disable any compromised service accounts or API keys
Preserve a snapshot (cloud VM snapshot or disk image) before remediation begins
Long-term containment (within hours):
Move affected systems to an isolated network segment for forensic analysis
Deploy additional monitoring on systems adjacent to the compromise
Validate that backups for affected systems are clean and pre-date the intrusion
Determine if the attacker has established persistence (scheduled tasks, cron jobs,
SSH authorized_keys, new user accounts, implants)
Coordinate with legal before communicating externally about the breach
Never reimage or restore a system before taking a forensic image. A clean system
is useless evidence.
Preserve forensic evidence
Forensic integrity requires that you capture volatile data before it disappears and
that all evidence collection is documented.
Order of volatility (capture in this order):
CPU registers and cache (already lost if you can't attach a debugger live)
RAM / memory dump - use tools like avml, WinPmem, or cloud provider memory
capture APIs
Network connections - ss -tnp, netstat -ano, ARP cache
Running processes - ps auxf, lsof, process tree with hashes
File system - timestamps (MAC times), recently modified files, new files
Disk image - bit-for-bit copy using dd with write blocker or cloud snapshot
Chain of custody log template:
Evidence ID: [unique ID, e.g., INC-2024-001-E01]
Description: [e.g., Memory dump from prod-web-01]
Collected by: [name + role]
Collection time: [ISO 8601 timestamp with timezone]
Collection tool: [tool name + version + command run]
Hash (SHA-256): [hash of the evidence file]
Storage location:[path or bucket with access controls]
Chain of access: [who accessed it and when after collection]
Every command run on a live affected system must be logged with timestamp and
operator name - these commands themselves modify the system and must be part of
the record.
Communicate during an incident
Timely, accurate communication prevents panic and enables stakeholders to take
protective action. Follow a tiered communication model:
Internal responders (Slack incident channel, every 30-60 minutes):
Current status, what we know, what we're doing, next update in X minutes.
Executive / management stakeholder template:
Subject: [P1 ACTIVE / P2 CONTAINED] Security Incident - [date]
What happened: [1-2 sentences, plain language]
Current status: [Investigating / Contained / Eradicating / Recovering]
Business impact: [Systems affected, services degraded, data at risk]
What we are doing: [Top 3 actions in progress]
Next update: [Time]
Contact: [IR lead name + contact]
Customer / external notification (when required by law or policy):
Consult legal before sending any external notification
GDPR requires notification to supervisory authority within 72 hours of becoming
aware of a breach
State breach notification laws vary; legal must determine which apply
Be factual and specific about what data was affected; avoid speculation
Include what affected users should do to protect themselves
Never speculate in stakeholder communications. State only what is confirmed. Use
"we are investigating" until you have facts.
Eradicate the threat and recover
Eradication removes every trace of the attacker. Recovery restores normal operations.
Eradication checklist:
All identified malware, webshells, backdoors, and implants removed
All compromised credentials rotated (service accounts, API keys, user passwords,
certificates)
Vulnerability that enabled the initial access is patched or mitigated
Affected systems reimaged or verified clean from a known-good state
New IOC-based detection rules deployed to SIEM/EDR
Recovery checklist:
Restored systems are patched and hardened before returning to production
Enhanced monitoring is in place for all recovered systems (minimum 30 days)
Backups validated as clean before restoring data
Access controls reviewed and reduced to least privilege
Stakeholders notified that service has been restored
Do not rush recovery. A compromised system returned to production prematurely is
a worse outcome than extended downtime.
Write an incident report
Every P1 and P2 incident requires a written report. P3 incidents warrant a brief
write-up. Reports serve three purposes: accountability, improvement, and compliance.
Incident report template:
# Incident Report: [Short title]**Incident ID:** INC-YYYY-MM-DD-NNN
**Severity:** P1 / P2 / P3
**Status:** Closed
**Date/Time Detected:** [ISO 8601]
**Date/Time Resolved:** [ISO 8601]
**Total Duration:** [HH:MM]
**Report Author:** [Name]
**Reviewed By:** [Names]
## Executive Summary
[2-3 sentences: what happened, what was affected, what was done]
## Timeline
| Time (UTC) | Event |
|---|---|
| HH:MM | [First indicator observed] |
| HH:MM | [Incident declared, responders engaged] |
| HH:MM | [Containment action taken] |
| HH:MM | [Root cause identified] |
| HH:MM | [Eradication complete] |
| HH:MM | [Systems restored to production] |
## Root Cause
[What vulnerability, misconfiguration, or human factor enabled this incident?]
## Impact- Systems affected: [list]
- Data affected: [type, volume, sensitivity]
- Users affected: [count / segments]
- Business impact: [downtime, revenue, SLA breach]
## What Went Well- [list]
## What Could Be Improved- [list]
## Action Items
| Action | Owner | Due Date | Status |
|---|---|---|---|
| [Patch CVE-XXXX-XXXX] | [Name] | [Date] | Open |
## Evidence References
| Evidence ID | Description | Location |
|---|---|---|
Distribute the report within 5 business days of incident closure. For P1 incidents,
hold a live lessons-learned meeting before the written report is finalized.
Conduct lessons learned and improve
The lessons learned phase is where incidents pay dividends. Skip it and you will
respond to the same incident again.
Meeting structure (60-90 minutes for P1, 30 minutes for P2):
Timeline review (15 min) - walk through the incident timeline factually
What went well (10 min) - reinforce what worked
What can improve (20 min) - identify gaps in detection, response, tools, or process
Detection gap analysis (10 min) - what new detections would have caught this earlier?
Improvement categories to consider:
Detection: new SIEM rules, EDR signatures, alerting thresholds
Prevention: patches, hardening, access control changes
Process: runbook updates, communication templates, escalation paths
Training: tabletop exercises, awareness training for the attack vector used
Track action items in your ticketing system. Review completion at the next security
review cycle. An unactioned post-mortem is a missed opportunity and a future liability.
Gotchas
Rotating credentials before isolating the system - If you rotate credentials while the attacker still has an active session, they may have already cached the token or established a persistent back-channel (e.g., reverse shell). Isolate the system from the network first, then rotate credentials.
GDPR 72-hour clock starts at awareness, not confirmation - The 72-hour notification requirement to the supervisory authority begins when you have reasonable belief a breach occurred - not when you have confirmed every detail. Filing "we are investigating" within 72 hours is required; waiting until the investigation is complete is not compliant.
"Contained" does not mean "eradicated" - Isolating a system stops active damage but the threat is still present. Attackers frequently pre-plant persistence (cron jobs, scheduled tasks, additional user accounts) before containment. Never return a system to production after containment alone - eradication must follow.
Slack incident channel membership leaks intel - Adding non-essential stakeholders to the incident Slack channel before legal review can expose information subject to privilege or create a discoverable record. Keep the responder channel tight until legal has been consulted on external communication scope.
Post-mortem action items without due dates are permanent backlogs - An action item with no owner and no deadline will be in the "backlog" forever. Every action item from a post-mortem needs a named owner, a specific due date, and a check-in at the next security review.
Anti-patterns / common mistakes
Mistake
Why it's wrong
What to do instead
Rebooting or wiping a system immediately
Destroys volatile evidence (RAM, network state, running processes) that is critical for forensics
Isolate from network, take memory dump and disk image first, then remediate
Investigating without containment
Attacker retains access while you analyze, exfiltrating more data
Contain first (isolate, revoke creds), then investigate in parallel
Communicating speculation as fact
Creates false expectations, erodes trust when facts change
State only confirmed findings; use "we are investigating" for unknown scope
Skipping chain of custody documentation
Evidence becomes inadmissible in legal proceedings or insurance claims
Document every piece of evidence with collector, time, tool, and hash from collection
Declaring an incident closed too quickly
Attacker may have established persistence that survives remediation
Monitor recovered systems for 30+ days before considering the incident fully closed
Blaming individuals in post-mortems
Creates fear culture, people hide future incidents, root causes go unfixed
Focus on system and process failures; use blameless post-mortem framework
References
For detailed playbooks on specific incident types, read:
references/incident-playbooks.md - step-by-step playbooks for ransomware,
credential theft, data exfiltration, insider threat, and supply chain attacks
Only load the references file when the current incident type matches a playbook -
it is detailed and will consume context.
Companion check
On first activation of this skill in a conversation: check which companion skills are installed by running ls ~/.claude/skills/ ~/.agent/skills/ ~/.agents/skills/ .claude/skills/ .agent/skills/ .agents/skills/ 2>/dev/null. Compare the results against the recommended_skills field in this file's frontmatter. For any that are missing, mention them once and offer to install:
