security-incident-reporting

Security Incident Reporting

Source: https://github.com/dirnbauer/webconsulting-skills

Comprehensive framework for documenting and analyzing security incidents, drawing from NIST SP 800-61 and SANS methodologies.

When to Use

• After a security incident (DDoS, breach, vulnerability exploitation)
• Creating post-mortem documentation
• Communicating with stakeholders (C-level, legal, security teams)
• Correlating attack patterns with known CVEs
• Establishing incident response metrics (MTTR, dwell time)

Related Skills

• security-audit - Pre-incident vulnerability assessment
• typo3-security - TYPO3 hardening
• SKILL-TYPO3.md - TYPO3-specific incident reporting

---

1. Incident Response Framework

NIST SP 800-61 / SANS Harmonization

Phase	NIST	SANS	Documentation Focus
1	Preparation	Preparation	Runbooks, contacts, tools
2	Detection & Analysis	Identification	Initial detection, triage
3	Containment	Containment	Isolation actions, timeline
4	Eradication	Eradication	Root cause removal
5	Recovery	Recovery	Service restoration
6	Post-Incident	Lessons Learned	Post-mortem, improvements

Documentation Principle

Logbuch-Prinzip: Document in real-time during the incident, then consolidate into the post-mortem report. Never create reports retrospectively from memory.

---

2. Severity Rating Systems

NCISS (National Cyber Incident Scoring System)

Level	Score	Description
Emergency (1)	100	Nation-state attack, critical infrastructure
Severe (2)	80-99	Significant impact, data exfiltration
High (3)	60-79	Service disruption, potential data loss
Medium (4)	40-59	Limited impact, contained breach
Low (5)	20-39	Minor incident, no data loss
Baseline (6)	0-19	Informational, false positive

DDoS Resiliency Score (DRS)

Level	Description	Typical Bandwidth
1-2	Simple Floods	< 1 Gbps
3-4	Sophisticated Multi-Vector	1-5 Gbps
5-6	Advanced (State-Actor Level)	5-100 Gbps
7	Extreme (Hyper-Volumetric)	> 100 Gbps

CVSS Integration

For vulnerability-based incidents, include CVSS 4.0 base score (v3.1 accepted for legacy reports) from the security-audit skill.

---

3. Incident Report Template

Module A: Metadata & Executive Summary

# Security Incident Report

## Metadata
| Field | Value |
|-------|-------|
| Incident ID | SIR-2026-001 |
| Classification | Confidential |
| Status | Closed / Active / Under Investigation |
| Detection Time | 2026-01-21 14:32 UTC |
| Resolution Time | 2026-01-21 15:17 UTC |
| MTTR | 45 minutes |
| Severity | High (NCISS: 65) |
| Lead Analyst | Jane Doe |
| Affected Systems | web-cluster-01, cdn-edge-eu |

## Executive Summary (max 200 words)

On [DATE], our monitoring systems detected [INCIDENT TYPE] targeting [SYSTEMS].
The attack [IMPACT DESCRIPTION]. Through [RESPONSE ACTIONS], normal operations
were restored within [TIMEFRAME]. [DATA IMPACT STATEMENT].

### Business Impact
- Service Availability: [Degraded/Offline for X minutes]
- Data Impact: [None/Potential exposure of X records]
- Financial Impact: [Estimated cost]
- Reputation Impact: [Public/Internal]

Module B: Timeline (Chronological Analysis)

## Incident Timeline

| Time (UTC) | Event | Source | Action Taken |
|------------|-------|--------|--------------|
| 14:32 | Traffic spike detected | Cloudflare Alert | On-call notified |
| 14:35 | 5x baseline traffic confirmed | Grafana | Incident declared |
| 14:38 | Geo-blocking activated | Cloudflare | EU/US traffic filtered |
| 14:42 | Attack vector identified: UDP amplification | DPI Analysis | Null-route for UDP/427 |
| 14:55 | Traffic normalized | Monitoring | Mitigation confirmed |
| 15:17 | All systems stable | Status page | Incident closed |

### Dwell Time Analysis
- Time to Detection (TTD): 0 minutes (automated)
- Time to Containment (TTC): 10 minutes
- Time to Eradication (TTE): 23 minutes
- Time to Recovery (TTR): 45 minutes

Module C: Technical Analysis & IoCs

## Technical Analysis

### Attack Vectors (MITRE ATT&CK)
- T1498: Network Denial of Service
- T1498.001: Direct Network Flood
- T1498.002: Reflection Amplification

### Indicators of Compromise (IoCs)

#### Network Artifacts
| Type | Value | Context |
|------|-------|---------|
| IP Range | 192.0.2.0/24 | Source (spoofed) |
| ASN | AS12345 | Amplification source |
| Port | UDP/427 | SLP Amplification |
| Signature | \x00\x00\x00\x00SLP | Payload pattern |

#### System Artifacts
| Type | Value | Hash (SHA256) |
|------|-------|---------------|
| Modified File | /var/www/shell.php | a1b2c3... |
| New User | backdoor_admin | N/A |
| Cron Job | /tmp/.hidden/beacon | d4e5f6... |

### Root Cause Analysis (5-Whys)
1. Why did the attack succeed? → Amplification ports were exposed
2. Why were ports exposed? → Firewall rules not updated after migration
3. Why weren't rules updated? → No automated validation in deployment
4. Why no automation? → Security review not in CI/CD pipeline
5. Why not in pipeline? → Technical debt, prioritized features

**Root Cause**: Missing security validation in deployment pipeline

---

4. DDoS Post-Mortem Analysis

Metrics Table

Metric	Value	Threshold	Status
Peak Bandwidth	45 Gbps	10 Gbps	Exceeded
Peak Packets/sec	12M PPS	5M PPS	Exceeded
Peak Requests/sec	850K RPS	100K RPS	Exceeded
Unique Source IPs	145,000	N/A	Amplification
Attack Duration	45 min	N/A	-
Geographic Spread	89 countries	N/A	Global botnet

Attack Vector Classification

Vector	% of Traffic	Type	Mitigation
UDP Flood	60%	Volumetric	Null-route
SYN Flood	25%	Protocol	SYN cookies
HTTP Flood	15%	Application	Rate limiting

Multi-Vector Detection

Was this a smoke-screen attack?
├── Volumetric attack started: 14:32
├── Application-layer probing detected: 14:38
├── Login brute-force attempts: 14:40-14:45
└── Conclusion: Coordinated multi-vector attack

---

5. CVE Correlation for DDoS

Map attack signatures to known vulnerabilities for threat intelligence.

Amplification Vector CVE Table

Attack Type	Port	Amplification Factor	CVE	Description
NTP Monlist	UDP/123	556x	CVE-2013-5211	NTP mode 7 monlist
Memcached	UDP/11211	51,000x	CVE-2018-1000115	UDP reflection
CLDAP	UDP/389	70x	Various	LDAP reflection
SLP	UDP/427	2,200x	CVE-2023-29552	Service Location Protocol
DNS	UDP/53	54x	Various	Open resolver abuse
SSDP	UDP/1900	30x	Various	UPnP reflection
Chargen	UDP/19	358x	CVE-1999-0103	Character generator

Analysis Example

## CVE Correlation Analysis

Traffic analysis shows 40% of UDP flood originated from port 427.
Deep Packet Inspection confirmed payloads typical for CVE-2023-29552.

**Conclusion**: Botnet leveraging unpatched VMware ESXi instances as
SLP reflectors. Recommend:
1. Verify our infrastructure is not acting as reflector
2. Block UDP/427 at edge
3. Report to upstream provider

---

6. Impact Assessment Matrix

Operational Impact

Category	Level	Description
Availability	Critical	Complete outage for 15 minutes
Performance	High	50% degradation for 30 minutes
Collateral	Medium	API gateway affected

Financial Impact

Category	Estimated Cost
Lost Revenue	$15,000
Scrubbing Overage	$2,500
Incident Response	$5,000 (8 person-hours)
Total	$22,500

Reputation Impact

Channel	Severity	Action Required
Social Media	Medium	Prepared statement
B2B Partners	Low	Direct notification
Press	None	No external coverage

---

7. Blameless Post-Mortem

Principles

1. Focus on systems, not individuals: "Why did the process allow X?" not "Who did X?"
2. Assume good intentions: Everyone acted with the best information available
3. Learn, don't punish: Goal is improvement, not blame
4. Share openly: Publish internally for organizational learning

Post-Mortem Template

## Post-Mortem: [Incident Title]

### What Happened
[Factual description of the incident]

### What Went Well
- Detection was automated (0 min TTD)
- On-call responded within SLA
- Communication was clear

### What Went Wrong
- Firewall rules were outdated
- No alerting for UDP traffic spikes
- Runbook was incomplete

### Action Items
| ID | Action | Owner | Due Date | Status |
|----|--------|-------|----------|--------|
| 1 | Add security validation to CI/CD | @devops | 2026-02-01 | Open |
| 2 | Update runbook with DDoS procedures | @security | 2026-01-28 | Open |
| 3 | Implement UDP traffic alerting | @sre | 2026-02-05 | Open |

### Lessons Learned
- Automated security gates prevent configuration drift
- Regular runbook reviews are essential
- Multi-vector attacks require layered defense

---

8. Report Distribution

Classification Levels

Level	Audience	Content
Executive	C-Level, Board	Summary, business impact, remediation status
Technical	Security Team, SOC	Full IoCs, TTPs, forensic details
Legal	Legal, Compliance	Data impact, regulatory implications
Public	Customers, Press	Sanitized summary, no technical details

Retention Requirements

Document Type	Retention	Storage
Full Incident Report	7 years	Encrypted archive
IoC Data	2 years	Threat Intelligence Platform
Logs & Evidence	1 year	Immutable storage

---

9. Checklists

Pre-Incident Preparation

• Incident response runbooks documented
• On-call rotation established
• Communication templates prepared
• Evidence collection tools ready
• Stakeholder contact list updated

During Incident

• Incident declared and logged
• Timeline documentation started
• Evidence preserved (logs, packets)
• Stakeholders notified
• Status page updated

Post-Incident

• Full incident report completed
• Post-mortem meeting scheduled
• Action items assigned and tracked
• Lessons learned documented
• Controls validated/improved

---

References

• NIST SP 800-61 Rev. 3 (April 2025, CSF 2.0-aligned; Rev. 2 withdrawn 2025-04-03)
• SANS Incident Response
• MITRE ATT&CK
• DDoS Resiliency Score
• CISA NCISS

---

Credits & Attribution

This skill draws from the "Handbuch für Advanced Security Incident Reporting" methodology, incorporating elements of NIST SP 800-61, SANS frameworks, and industry best practices.

Developed by webconsulting.at for the Claude skill collection.

Source: https://github.com/dirnbauer/webconsulting-skills