# DDoS Incident Response Plan

**Organization:** ___________________________

**Version:** 1.0 | **Effective Date:** ____________ | **Review Date:** ____________

**Classification:** Internal / Confidential

**Document Owner:** ___________________________ | **Approved By:** ___________________________

---

## 1. Purpose and Scope

### 1.1 Purpose

This document defines the procedures for detecting, classifying, responding to, and recovering from Distributed Denial of Service (DDoS) attacks against [ORGANIZATION NAME]'s infrastructure. It ensures that all personnel involved in incident response follow a consistent, repeatable process that minimizes service disruption and preserves forensic evidence.

### 1.2 Scope

This plan covers all network-facing infrastructure managed by [ORGANIZATION NAME], including:

- [ ] Public-facing web servers and APIs
- [ ] DNS infrastructure
- [ ] Mail servers
- [ ] Game servers / voice servers
- [ ] Customer-facing services (list: ___________________________)
- [ ] Internal infrastructure exposed to the internet

### 1.3 Compliance References

This plan supports compliance with the following frameworks:

| Framework | Relevant Controls |
|---|---|
| NIST CSF 2.0 | DE.AE, DE.CM, RS.AN, RS.MI, RS.CO, RC.RP |
| ISO 27001:2022 | A.5.24, A.5.25, A.5.26, A.5.28, A.8.16, A.8.20 |
| SOC 2 TSC | CC6.6, CC7.1, CC7.2, CC7.3, CC7.4, A1.2 |
| CCCS Baseline | SC-1, SC-2, IR-1, IR-2, SR-1, AU-1 |
| NIST SP 800-61r3 | All phases: Preparation, Detection, Containment, Post-Incident |
| Cyber Insurance | Satisfies typical "documented incident response plan" requirements |

---

## 2. Roles and Responsibilities

### 2.1 Incident Response Team

| Role | Name | Contact | Backup |
|---|---|---|---|
| Incident Commander | _____________ | _____________ | _____________ |
| Network Engineer (L1) | _____________ | _____________ | _____________ |
| Network Engineer (L2) | _____________ | _____________ | _____________ |
| NOC / On-Call | _____________ | _____________ | _____________ |
| Communications Lead | _____________ | _____________ | _____________ |
| Management / Exec Sponsor | _____________ | _____________ | _____________ |

### 2.2 External Contacts

| Entity | Contact | SLA / Response Time |
|---|---|---|
| ISP / Transit Provider #1 | _____________ | _____________ |
| ISP / Transit Provider #2 | _____________ | _____________ |
| DDoS Mitigation Vendor | _____________ | _____________ |
| Cloud Provider (AWS/GCP/Azure) | _____________ | _____________ |
| CDN Provider | _____________ | _____________ |
| Law Enforcement (if applicable) | _____________ | _____________ |

### 2.3 RACI Matrix

| Activity | Incident Commander | Network Engineer | NOC | Comms Lead | Management |
|---|---|---|---|---|---|
| Declare incident | A | R | I | I | I |
| Classify severity | A | R | C | I | I |
| Execute mitigation | A | R | I | I | I |
| Customer communication | A | C | I | R | I |
| Escalate to upstream | A | R | I | I | I |
| Post-incident review | R | R | C | C | A |

*R = Responsible, A = Accountable, C = Consulted, I = Informed*

---

## 3. Detection and Monitoring

### 3.1 Monitoring Requirements

Effective DDoS detection requires continuous, per-second monitoring of network traffic at the packet level. The following monitoring capabilities must be in place:

**Traffic Monitoring:**

- [ ] Per-second packets-per-second (PPS) monitoring on all protected hosts
- [ ] Per-second bits-per-second (BPS / bandwidth) monitoring
- [ ] Adaptive baseline calculation with rolling statistical analysis
- [ ] Anomaly detection using baseline multiplier thresholds (recommended: 3x baseline)

**Application-Layer Monitoring:**

- [ ] HTTP/HTTPS requests-per-second (RPS) monitoring
- [ ] Error rate monitoring (4xx/5xx response codes)
- [ ] Web server access log analysis for L7 flood patterns

**Protocol-Aware Detection:**

- [ ] Attack family classification (UDP flood, SYN flood, DNS amplification, NTP reflection, HTTP flood, GRE flood, ICMP flood, fragmentation)
- [ ] Confidence scoring for each detected attack
- [ ] Service port awareness (distinguish attack traffic from legitimate service traffic)

### 3.2 Monitoring Tool Configuration

| Parameter | Value |
|---|---|
| Monitoring tool | ________________________________ |
| Detection latency target | < _______ seconds |
| Baseline calculation window | _______ minutes |
| Threshold multiplier | _______ x baseline |
| L7 detection | Enabled / Disabled |
| PCAP capture | Enabled / Disabled |
| PCAP retention period | _______ days |

### 3.3 Alert Channels

All alert channels must be tested quarterly.

| Channel | Configuration | Responsible |
|---|---|---|
| Primary (e.g., Slack/PagerDuty) | _____________ | _____________ |
| Secondary (e.g., email) | _____________ | _____________ |
| Escalation (e.g., SMS/phone) | _____________ | _____________ |
| Customer status page | _____________ | _____________ |

---

## 4. Classification and Severity Levels

### 4.1 Severity Matrix

| Severity | Name | Criteria | Response Time | Escalation |
|---|---|---|---|---|
| S1 | Critical | Service down or degraded for customers; attack exceeds mitigation capacity | Immediate | Incident Commander + Management + ISP |
| S2 | High | Attack detected and actively mitigated; risk of service impact | < 15 minutes | Incident Commander + Network Engineer |
| S3 | Medium | Attack detected; automated mitigation handling successfully | < 30 minutes | Network Engineer (on-call) |
| S4 | Low | Anomalous traffic detected; no service impact; monitoring | < 2 hours | NOC / automated logging |

### 4.2 Attack Classification

| Attack Category | Examples | Typical Indicators |
|---|---|---|
| Volumetric (L3) | UDP flood, DNS amplification, NTP reflection, SSDP, memcached | PPS/BPS spike, single protocol dominance |
| Protocol (L4) | SYN flood, ACK flood, TCP fragmentation, GRE flood | Connection state exhaustion, unusual flag patterns |
| Application (L7) | HTTP flood, slowloris, RUDY, API abuse | RPS spike, elevated error rates, unusual User-Agent distribution |

---

## 5. Escalation Procedures

### 5.1 Automated First Response

The following actions should trigger automatically upon attack detection (no human intervention required):

**Layer 3/4 Mitigation:**

- [ ] Firewall rules (iptables/nftables) to drop source IPs exceeding thresholds
- [ ] XDP/eBPF filters for line-rate kernel-level packet dropping
- [ ] Rate limiting on non-service ports

**BGP Mitigation (if attack exceeds local capacity):**

- [ ] BGP FlowSpec rules to surgically filter attack traffic at the router level
- [ ] RTBH (Remote Triggered Black Hole) for destination-based blackholing as last resort

**Service Protection:**

- [ ] Service port awareness rules to block attack traffic while keeping legitimate ports open
- [ ] Automatic cooldown and unblock when attack subsides

### 5.2 Manual Escalation Ladder

| Step | Trigger | Action | Who |
|---|---|---|---|
| 1 | Automated mitigation active > 10 min | Review attack details, verify automated response is effective | On-call engineer |
| 2 | Service impact despite mitigation | Engage Incident Commander, apply manual rules, consider FlowSpec | Incident Commander |
| 3 | Attack exceeds local capacity | Contact upstream ISP for upstream filtering or activate cloud scrubbing | Incident Commander + ISP |
| 4 | Attack sustained > 1 hour at S1 | Engage management, prepare customer communication | Incident Commander + Comms |
| 5 | Sustained multi-vector or targeted | Contact DDoS mitigation vendor, consider law enforcement | Management |

### 5.3 ISP Escalation

**Primary Transit Provider:**

- Contact: _________________________
- Procedure: _________________________
- Expected response time: _____________
- Capabilities: [ ] RTBH  [ ] FlowSpec  [ ] Upstream scrubbing

**Secondary Transit Provider:**

- Contact: _________________________
- Procedure: _________________________

---

## 6. Mitigation Playbooks

### 6.1 Volumetric Attack (UDP Flood / Amplification)

**Detection indicators:**
- PPS or BPS exceeds baseline by 3x or more
- Single protocol (UDP) dominates inbound traffic
- Source IPs are spoofed or from known amplification reflectors

**Response steps:**
1. [ ] Verify attack classification and target IP
2. [ ] Confirm automated firewall rules are active
3. [ ] If XDP/eBPF available, deploy kernel-level drop filter for attack protocol
4. [ ] If attack exceeds server capacity, deploy BGP FlowSpec rule: `protocol UDP, destination [TARGET_IP], action drop`
5. [ ] If attack exceeds link capacity, activate RTBH or contact ISP for upstream filtering
6. [ ] Monitor mitigation effectiveness via real-time dashboard
7. [ ] Preserve PCAP evidence for post-incident analysis

### 6.2 Protocol Attack (SYN Flood)

**Detection indicators:**
- Elevated TCP SYN packets without corresponding SYN-ACK completion
- Connection table exhaustion on target server
- Potential source IP spoofing

**Response steps:**
1. [ ] Verify SYN cookies are enabled (`net.ipv4.tcp_syncookies = 1`)
2. [ ] Deploy rate limiting on SYN packets to target IP
3. [ ] If server connection table is saturating, increase `net.ipv4.tcp_max_syn_backlog`
4. [ ] Deploy XDP filter for SYN rate limiting
5. [ ] If spoofed sources, deploy uRPF (unicast Reverse Path Forwarding) at router
6. [ ] Preserve PCAP evidence

### 6.3 Application-Layer Attack (HTTP Flood)

**Detection indicators:**
- HTTP requests-per-second exceeds baseline
- Elevated 5xx error rates
- Unusual User-Agent strings or request patterns
- Single URI or endpoint targeted

**Response steps:**
1. [ ] Verify L7 detection has classified the attack
2. [ ] Review top attacking IPs and request patterns in PCAP/logs
3. [ ] Deploy rate limiting per source IP at the web server or WAF level
4. [ ] If pattern identified, deploy targeted blocking rule (URI, User-Agent, country)
5. [ ] Consider enabling CAPTCHA challenge on targeted endpoints
6. [ ] If attack bypasses application-layer rules, escalate to CDN/WAF provider
7. [ ] Preserve access logs and PCAP evidence

---

## 7. Communication Plan

### 7.1 Internal Notification Matrix

| Severity | Notify Immediately | Notify Within 15 Min | Notify Within 1 Hour |
|---|---|---|---|
| S1 | Incident Commander, Management | All engineering, Support team | All staff |
| S2 | Incident Commander | Network team | Support team |
| S3 | On-call engineer | Network team (FYI) | -- |
| S4 | -- | -- | -- (logged) |

### 7.2 Customer Communication Templates

**Initial Notification (S1/S2):**

> We are currently investigating elevated network traffic affecting [SERVICE]. Our monitoring systems detected the issue at [TIME] and automated mitigation is active. We will provide an update within [30 minutes / 1 hour].

**Update:**

> Our team has identified the traffic as a DDoS attack targeting [TARGET]. Mitigation measures are in place and service is [restoring / stable]. We continue to monitor the situation.

**Resolution:**

> The DDoS attack that began at [START_TIME] has been fully mitigated as of [END_TIME]. All services are operating normally. Total duration: [DURATION]. A detailed post-incident report will be available within [48 hours].

### 7.3 Status Page Updates

| Platform | URL | Update Responsibility |
|---|---|---|
| Primary status page | _________________________ | _____________ |
| Social media | _________________________ | _____________ |
| Support ticket system | _________________________ | _____________ |

---

## 8. Evidence Preservation

### 8.1 During an Incident

The following evidence must be preserved automatically or manually during every DDoS incident:

- [ ] **PCAP files** -- Packet captures from before and during the attack, including pre-attack baseline traffic for comparison
- [ ] **Attack metadata** -- Start time, end time, peak PPS/BPS, attack type classification, confidence score, source IP distribution
- [ ] **Firewall logs** -- All rules triggered, IPs blocked, packets dropped
- [ ] **System logs** -- Server performance metrics, connection table state, service health
- [ ] **Communication logs** -- All internal and external communications related to the incident

### 8.2 Retention Policy

| Evidence Type | Retention Period | Storage Location |
|---|---|---|
| PCAP files | _______ days | _________________________ |
| Attack logs | _______ days | _________________________ |
| Firewall logs | _______ days | _________________________ |
| Post-incident reports | _______ years | _________________________ |
| Communication logs | _______ years | _________________________ |

---

## 9. Post-Incident Review

### 9.1 Timeline

| Activity | Deadline |
|---|---|
| Incident log finalized | + 24 hours |
| PCAP forensics analysis completed | + 48 hours |
| Post-incident review meeting | + 72 hours |
| Written post-incident report | + 5 business days |
| Action items assigned | + 5 business days |
| Action items completed | + 30 days |

### 9.2 Post-Incident Report Template

**Incident Reference:** _______________

**Date/Time:** Start: _______________ End: _______________ Duration: _______________

**Severity:** S1 / S2 / S3 / S4

**Attack Summary:**
- Attack type: _______________
- Peak PPS: _______________ | Peak BPS: _______________
- Target IP(s): _______________
- Source IP count: _______________
- Attack confidence score: _______________%

**Detection:**
- Detection method: Automated / Manual
- Time to detect: _______________ seconds
- Alert channel that fired: _______________

**Response:**
- Time to first mitigation action: _______________
- Mitigation method(s) used: _______________
- Was escalation required? Yes / No
- If yes, escalation path: _______________

**Impact:**
- Service disruption: Yes / No
- Duration of customer impact: _______________
- Estimated revenue impact: $_______________
- Customer complaints received: _______________

**PCAP Forensics:**
- Attack signature / fingerprint: _______________
- Source IP analysis (spoofed / real / botnet): _______________
- Protocol breakdown: _______________
- Notable payload patterns: _______________

**Lessons Learned:**
1. What went well: _______________
2. What could be improved: _______________
3. Detection gaps identified: _______________
4. Threshold adjustment needed: Yes / No

**Action Items:**

| # | Action | Owner | Due Date | Status |
|---|---|---|---|---|
| 1 | _____________ | _____________ | _____________ | _____________ |
| 2 | _____________ | _____________ | _____________ | _____________ |
| 3 | _____________ | _____________ | _____________ | _____________ |

---

## 10. Plan Maintenance

### 10.1 Review Schedule

This plan must be reviewed and updated:

- [ ] **Quarterly** -- Review contact lists, escalation procedures, and threshold values
- [ ] **After every S1/S2 incident** -- Incorporate lessons learned
- [ ] **Annually** -- Full plan review including tabletop exercise
- [ ] **On infrastructure changes** -- New servers, new transit providers, architecture changes

### 10.2 Testing Schedule

| Test Type | Frequency | Last Completed | Next Scheduled |
|---|---|---|---|
| Alert channel test | Quarterly | _____________ | _____________ |
| Tabletop exercise | Annually | _____________ | _____________ |
| Simulated attack drill | Annually | _____________ | _____________ |
| BGP failover test | Semi-annually | _____________ | _____________ |
| Escalation contact verification | Quarterly | _____________ | _____________ |

### 10.3 Version History

| Version | Date | Author | Changes |
|---|---|---|---|
| 1.0 | _____________ | _____________ | Initial version |
| | | | |
| | | | |

---

*This template is provided free of charge by [Flowtriq](https://flowtriq.com). It is designed to be used with any DDoS detection and mitigation tooling. For a monitoring solution that covers every checkbox in this document out of the box, visit [flowtriq.com](https://flowtriq.com).*