Incident Response (IR)
Incident response is the fire department for cybersecurity. When a breach, malware infection, or unauthorized access is detected, incident response is the organized plan for handling it: stop the damage, figure out what happened, fix the problem, and make sure it does not happen again. Without a plan, organizations panic and make mistakes that make things worse (like wiping evidence or paying ransoms immediately).
Incident Response (IR) is a structured methodology for handling cybersecurity events. The NIST SP 800-61 framework defines four phases:
1. Preparation:
- Establish IR team roles and contact information
- Deploy detection tools (SIEM, EDR, IDS)
- Create playbooks for common incident types
- Conduct tabletop exercises
2. Detection and Analysis:
- Identify indicators of compromise (IOCs): suspicious IPs, file hashes, registry keys, unusual process behavior
- Triage: determine severity, scope, and affected systems
- Collect volatile evidence (memory dumps, running processes, network connections) before it is lost
- Document timeline of events
3. Containment, Eradication, and Recovery:
- Short-term containment: isolate affected systems (network quarantine, disable accounts)
- Long-term containment: apply patches, reset credentials, block C2 domains
- Eradication: remove malware, close attack vector, eliminate persistence mechanisms
- Recovery: restore from clean backups, rebuild compromised systems, verify integrity, monitor for re-compromise
4. Post-Incident Activity:
- Root cause analysis
- Lessons learned documentation
- Update detection rules and playbooks
- Report to stakeholders, regulators (breach notification laws), and potentially law enforcement
Incident classification (example):
| Severity | Description | Response Time |
|---|---|---|
| P1 Critical | Active data exfiltration, ransomware, widespread outage | Immediate (all-hands) |
| P2 High | Compromised credentials, malware on production | Within 1 hour |
| P3 Medium | Phishing success (no lateral movement), policy violation | Within 4 hours |
| P4 Low | Failed attack, reconnaissance, minor policy violation | Next business day |
Incident response triage commands
# Volatile evidence collection (run BEFORE rebooting)
# 1. Who is logged in right now?
$ w
$ last -20
# 2. What processes are running?
$ ps auxf > /tmp/ir/processes.txt
# 3. What network connections exist?
$ ss -tnp > /tmp/ir/connections.txt
$ ss -tnp | grep -v "127.0.0.1" # Focus on external
# 4. What is in memory? (capture before shutdown)
$ sudo dd if=/dev/mem of=/tmp/ir/memory.dump bs=1M count=4096
# 5. Check for persistence mechanisms
$ crontab -l > /tmp/ir/crontab.txt
$ systemctl list-unit-files --state=enabled > /tmp/ir/services.txt
$ ls -la /etc/cron.d/ >> /tmp/ir/crontab.txt
# 6. Check for recently modified files
$ find / -mtime -1 -type f 2>/dev/null > /tmp/ir/modified_files.txt
# 7. Isolate the host (last step, after evidence collection)
$ sudo iptables -P INPUT DROP
$ sudo iptables -P OUTPUT DROP
$ sudo iptables -P FORWARD DROPEvery organization experiences security incidents; the difference is how well they respond. Companies with tested IR plans contain breaches in hours; those without take months (IBM Cost of a Data Breach Report: average 277 days to identify and contain). Regulatory requirements (GDPR 72-hour notification, HIPAA breach notification, SEC 4-day disclosure) make IR planning a legal obligation, not just a best practice. Common IR mistakes include: rebooting compromised systems (destroys volatile evidence), immediately changing all passwords (tips off the attacker), and not preserving chain of custody for forensic evidence. Managed Detection and Response (MDR) providers like CrowdStrike and Arctic Wolf offer outsourced IR capabilities for organizations without dedicated security teams.