Security Incident Reporting

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

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)

DDoS Resiliency Score (DRS)

CVSS Integration

For vulnerability-based incidents, include CVSS v3.1 base score 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

Attack Vector Classification

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

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

Financial Impact

Reputation Impact

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

Retention Requirements

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. 2
• 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.