Network Security Incident Response
Incident response (IR) is the organized approach an organization takes when a security breach or cyberattack occurs. No security posture is perfect — at some point, an incident will happen. Organizations that have a documented, practiced incident response plan contain breaches faster, minimize damage, preserve evidence, meet legal obligations, and recover more quickly than those who improvise in the chaos of an active attack.
What Constitutes a Security Incident
Events That Are NOT Incidents (just events): • Blocked phishing email (security tool worked correctly) • Failed brute force attempt blocked by account lockout • Port scan blocked by firewall • User forgot password → reset via normal process Events That ARE Security Incidents: • Confirmed malware infection on one or more devices • Unauthorized access to a system or data • Data breach or confirmed exfiltration • Ransomware deployment • Insider theft of sensitive data • DDoS causing service disruption • Successful phishing leading to credential compromise
The NIST Incident Response Lifecycle
The National Institute of Standards and Technology defines a four-phase incident response lifecycle. This cycle repeats continuously — lessons from each incident improve the next response.
┌───────────────────────────────────────────────────────┐
│ │
▼ │
[PREPARATION] ──► [DETECTION & ANALYSIS] ──► [CONTAINMENT, │
ERADICATION & │
RECOVERY] │
│ │
▼ │
[POST-INCIDENT │
ACTIVITY]────────┘
Phase 1: Preparation
Preparation happens before any incident. Organizations build their response capability during this phase so they are not scrambling to figure out the basics during an active attack.
Preparation Checklist: ✓ Written incident response plan (who does what, when) ✓ Incident Response Team (IRT) identified and trained ✓ Contact list: legal, PR, law enforcement, cyber insurance, regulators ✓ Playbooks for common incident types (ransomware, data breach, DDoS) ✓ Communication templates ready (internal, regulatory, customer notification) ✓ Forensic tools pre-installed and licensed ✓ Logging and monitoring in place (you can't respond to what you can't see) ✓ Backups tested (offline copies, restoration tested quarterly) ✓ IR exercises run at least annually (tabletop or live drill) ✓ Legal hold procedure defined (preserve evidence properly)
Phase 2: Detection and Analysis
An incident must be identified and its scope understood before a response can begin. This phase determines what happened, which systems are affected, how the attacker got in, and what data may be compromised.
Detection Sources: • SIEM alert fires for unusual behavior • IDS/IPS generates high-priority alert • User reports something suspicious • Antivirus flags a malware detection • External party notifies (FBI, security researcher, customer) • Ransom note appears on systems Initial Analysis Questions: 1. What systems are involved? 2. When did this start? (look for earliest indicator) 3. Is the attacker still active or is this a past event? 4. What data may have been accessed or exfiltrated? 5. Is this isolated or does it span multiple systems? 6. What was the initial entry point? Documentation Starts Immediately: • All findings logged with timestamps • Every action taken recorded • Evidence preserved before remediation (forensic images)
Phase 3: Containment, Eradication, and Recovery
Containment
Stop the bleeding. Prevent the attacker from spreading further or exfiltrating more data. Containment actions depend on the type of incident.
Containment Actions by Incident Type: Ransomware: → Immediately isolate infected systems from network (unplug or VLAN quarantine) → Disable compromised accounts → Block identified attacker IPs and domains at firewall → Preserve disk images for forensics BEFORE removing malware Data Breach (active exfiltration): → Block the outbound connection being used for exfiltration → Isolate source system → Preserve network logs showing what was sent → Do NOT wipe systems yet (destroys evidence) Compromised Account: → Disable the account immediately → Revoke all active sessions (force re-authentication everywhere) → Reset password and require MFA re-enrollment → Review all activity from that account in logs
Eradication
Remove the attacker's presence entirely. Identify and close the initial entry point. Remove all malware, backdoors, unauthorized accounts, and persistence mechanisms the attacker installed.
Eradication Steps: 1. Identify all compromised systems (attackers move laterally — check everything) 2. Remove malware from all affected systems 3. Delete unauthorized accounts or SSH keys added by attacker 4. Remove backdoors (scheduled tasks, startup scripts, web shells) 5. Identify and patch the vulnerability used for initial access 6. Reset all credentials that may have been exposed 7. Verify eradication by scanning with multiple tools
Recovery
Restore systems to normal operation with confidence that the attacker is gone and the entry point is closed.
Recovery Steps: 1. Restore affected systems from clean backups (verified pre-infection) 2. Rebuild systems from scratch if backup integrity is uncertain 3. Apply all patches before reconnecting to network 4. Monitor restored systems intensively for recurrence 5. Gradually restore normal operations 6. Confirm business functionality before declaring incident closed
Phase 4: Post-Incident Activity
Every incident is a learning opportunity. The post-incident review (also called a "lessons learned" meeting) examines what happened, how it was handled, and what needs to change to prevent recurrence or improve the next response.
Post-Incident Review Questions: • What was the initial attack vector? Is it fully closed? • How long did the attacker have access before detection? • What controls failed? What controls worked? • Did the IR plan work as expected? What needed improvisation? • Was communication effective (internal, legal, regulatory, public)? • What evidence was gathered? Was it sufficient for forensics? • What would have detected this earlier? • What new controls would prevent this class of attack? • What training gaps were exposed?
Incident Severity Classification
Severity | Description | Response Time -----------|-------------------------------------|------------------ SEV 1 | Active breach with data exfiltration| Immediate (minutes) SEV 2 | Confirmed compromise, no exfil yet | Within 1 hour SEV 3 | Malware isolated to one system | Within 4 hours SEV 4 | Suspicious activity under analysis | Within 24 hours SEV 5 | Policy violation, no active threat | Within 1 week
Legal and Regulatory Considerations
Obligation | Trigger --------------------------------------|-------------------------------------- Law enforcement notification | Criminal attack, nation-state, ransomware Regulatory notification (GDPR) | Personal data of EU residents involved Customer breach notification | Customer PII or financial data exposed Cyber insurance notification | Policy coverage requires prompt reporting Board notification | Material financial or reputational impact Evidence preservation (legal hold) | Any time litigation may result
Organizations that practice incident response before an incident occurs consistently outperform those who plan their response in the middle of an attack. Running annual tabletop exercises — where the IR team walks through hypothetical attack scenarios — identifies gaps, trains staff, and ensures the plan reflects current systems and personnel. The goal is not to eliminate incidents entirely (impossible) but to detect them quickly, contain damage swiftly, and recover fully — emerging stronger from each one.