# Root Cause Analysis Security

> Conduct root-cause analysis (RCA) to identify underlying causes of security incidents and prevent recurrence.

- Skill: `sethdford/root-cause-analysis-security` (Agent Skill)
- Install (CLI): `npx skillmds@latest add sethdford/root-cause-analysis-security`
- Raw SKILL.md: https://api.skillmd.com/api/skills/sethdford/root-cause-analysis-security/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: sethdford (https://skillmd.com/u/sethdford)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/sethdford/root-cause-analysis-security

---


# Root-Cause Analysis (Security)

Conduct root-cause analysis to identify underlying causes and prevent recurrence.

## Context

You are a senior security engineer conducting root-cause analysis (RCA) for $ARGUMENTS. RCA determines why a security incident happened; without understanding root cause, the same vulnerability will be exploited again. RCA is not blame—it's learning. A good RCA identifies systemic issues (missing patches, poor monitoring, inadequate testing) not just the "what" but the "why" of incident.

## Domain Context

- **Root Causes**: Vulnerability (unpatched, misconfiguration), detection gap (no monitoring, alert misconfigured), process failure (access control bypassed)
- **RCA Techniques**: Five Whys, Fishbone Diagram, Event Tree Analysis
- **Blamelessness**: RCA is about systems, not people; aim for learning and prevention
- **Follow-up**: RCA findings drive remediation; prevention controls prevent similar incidents

## Instructions

1. **Understand the Incident Fully**:
   - **Timeline**: Detailed chronology of events (when did each thing happen?)
   - **Attack Vector**: How did attacker get in? (vulnerability, weak password, phishing, misconfig)
   - **Scope**: What systems affected? What data accessed? How long had attacker access?
   - **Detection**: What alerted you to incident? How long between intrusion and detection (MTTD)?
   - **Impact**: Business impact (revenue loss, downtime, customer trust, regulatory action)
   - **Interviews**: Interview people involved (who detected it? who investigated? what was missed?)

2. **Apply Five Whys Technique**:
   - **Observation**: System was compromised due to unpatched vulnerability
   - **Why 1**: Why was the system vulnerable? Because security patch was not applied
   - **Why 2**: Why wasn't patch applied? Because patch testing didn't include this system
   - **Why 3**: Why wasn't this system in patch testing? Because system inventory was incomplete
   - **Why 4**: Why was inventory incomplete? Because on-boarding process didn't document all systems
   - **Why 5**: Why didn't on-boarding process document systems? Because no process owner assigned
   - **Root Cause**: Lack of process ownership; systems weren't being tracked/managed
   - **Remediation**: Assign process owner; establish/improve system inventory process

3. **Identify Systemic Issues**:
   - **Vulnerability Management**: Are vulnerabilities being tracked? Are patches tested before deployment?
   - **Detection**: Are attacks being detected? How quickly (MTTD)? What's the alert threshold?
   - **Monitoring**: Are suspicious activities being monitored? (Failed logins, privilege escalation, data access)
   - **Access Control**: Is access properly restricted? Are credentials strong? Is MFA enabled?
   - **Segmentation**: Are systems isolated? Can attacker move laterally after initial compromise?
   - **Testing**: Are security controls tested? (penetration tests, vulnerability scans)
   - **Awareness**: Do employees know about threats? Can they identify phishing?

4. **Document Findings**:
   - **Executive Summary**: What happened? Root causes identified
   - **Technical Details**: How incident occurred; attack chain; detection/response timeline
   - **Root Cause Analysis**: Five Whys, systemic issues identified
   - **Contributing Factors**: What else made incident possible? (missing monitoring, weak segmentation)
   - **Recommendations**: Preventive controls to prevent similar incidents
   - **Priority**: Which recommendations are critical? (Must fix before similar incident occurs)

5. **Develop Remediation Plan**:
   - **Prevention Controls**: What will prevent this from happening again?
     - Example RCA: Patch wasn't applied → Remediation: Improve patch management process
     - Example RCA: Attack wasn't detected → Remediation: Improve monitoring/alerting
   - **Detective Controls**: What will help us detect earlier if prevention fails?
     - Example: Enhanced monitoring for exploitation attempts
   - **Priority**: Implement critical controls first
   - **Timeline**: When will each control be implemented? (Critical: <30 days)
   - **Verification**: How will you verify control is effective?

6. **Implement Preventive Measures**:
   - **Process Improvements**: Update patch management, on-boarding, access control processes
   - **Technical Controls**: Add/improve detection (monitoring, alerting), prevention (segmentation, hardening)
   - **Awareness**: Train employees on lessons learned
   - **Testing**: Verify controls work (security test, penetration test)
   - **Metrics**: Track if improvements reduce incident risk

## Anti-Patterns

- Focusing on symptom instead of root cause (patch the vulnerability but don't improve process); **identify systemic issues**
- Blaming individuals (person forgot to apply patch); **focus on systems and processes**
- No follow-up on recommendations (analysis without action); **implement preventive measures**
- Assuming one RCA explains everything (complex incidents have multiple causes); **identify all contributors**
- Not learning from similar incidents (same root cause, different trigger); **look for patterns across incidents**

## Further Reading

- NIST SP 800-61 (Post-Incident Activities): https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r2.pdf
- Blameless Post-Mortem Guide: https://www.pagerduty.com/blog/blameless-post-mortems/
- Five Whys Technique: Toyota Production System, continuous improvement methodology
- Fishbone Diagram: Ishikawa Diagram for cause and effect analysis