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](../security-audit/SKILL.md) - Pre-incident vulnerability assessment - [typo3-security](../typo3-security/SKILL.md) - TYPO3 hardening - [SKILL-TYPO3.md](./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](../security-audit/SKILL.md) skill. --- ## 3. Incident Report Template ### Module A: Metadata & Executive Summary ```markdown # 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) ```markdown ## 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 ```markdown ## 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 ```markdown ## 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 ```markdown ## 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