Threat Modeling Risk

# Threat Modeling & Risk Assessment ## Threat Modeling Methodologies ### STRIDE Threat Model STRIDE is a threat modeling framework developed by Microsoft that categorizes threats into six types. **STRIDE Acronym**: ``` S - Spoofing Identity • Impersonating a user or system • Examples: Stolen credentials, session hijacking, phishing • Mitigation: Strong authentication (MFA), certificate validation T - Tampering with Data • Unauthorized modification of data • Examples: SQL injection, man-in-the-middle attacks, config manipulation • Mitigation: Input validation, encryption, digital signatures, integrity checks R - Repudiation • Denying an action was performed • Examples: User denies making a purchase, admin denies configuration change • Mitigation: Audit logging, digital signatures, non-repudiation mechanisms I - Information Disclosure • Exposing confidential information • Examples: Data breaches, information leakage, insufficient encryption • Mitigation: Encryption, access controls, data classification, DLP D - Denial of Service • Making a system unavailable • Examples: DDoS attacks, resource exhaustion, infinite loops • Mitigation: Rate limiting, load balancing, DDoS protection, capacity planning E - Elevation of Privilege • Gaining unauthorized capabilities • Examples: Privilege escalation, exploiting vulnerabilities, bypassing access controls • Mitigation: Least privilege, input validation, security updates, RBAC ``` **STRIDE Threat Modeling Process**: ``` Step 1: Create Data Flow Diagram (DFD) ┌──────────┐ HTTPS ┌──────────┐ SQL ┌──────────┐ │ User │ ──────────────────>│ Web │ ────────────> │ Database │ │ (Browser)│ │ Server │ │ Server │ └──────────┘ └──────────┘ └──────────┘ │ │ HTTPS ▼ ┌──────────┐ │ Auth │ │ Service │ └──────────┘ Step 2: Identify Trust Boundaries - Between User and Web Server (internet) - Between Web Server and Database (internal network) - Between Web Server and Auth Service Step 3: Apply STRIDE to Each Element Web Server: ├─ Spoofing: Attacker impersonates web server │ └─ Mitigation: TLS certificate, HSTS ├─ Tampering: Attacker modifies web server code │ └─ Mitigation: File integrity monitoring, immutable infrastructure ├─ Repudiation: Admin denies making config change │ └─ Mitigation: Audit logging of all admin actions ├─ Information Disclosure: Web server exposes sensitive data in errors │ └─ Mitigation: Custom error pages, no stack traces in production ├─ Denial of Service: Attacker overwhelms web server │ └─ Mitigation: Rate limiting, WAF, DDoS protection └─ Elevation of Privilege: Attacker gains admin access to web server └─ Mitigation: Least privilege, patch management, hardening Step 4: Apply STRIDE to Each Data Flow User → Web Server (HTTPS): ├─ Spoofing: Man-in-the-middle attack │ └─ Mitigation: TLS 1.3, certificate pinning ├─ Tampering: Attacker modifies data in transit │ └─ Mitigation: TLS encryption ├─ Repudiation: User denies sending request │ └─ Mitigation: Session logging with IP address ├─ Information Disclosure: Credentials leaked in transit │ └─ Mitigation: TLS encryption, no credentials in URLs ├─ Denial of Service: Request flooding │ └─ Mitigation: Rate limiting per IP, CAPTCHA └─ Elevation of Privilege: Session hijacking └─ Mitigation: HTTPOnly/Secure cookies, session timeout Step 5: Document Threats and Mitigations | Threat ID | STRIDE Category | Threat Description | Risk Level | Mitigation | Status | |-----------|----------------|-------------------|-----------|-----------|--------| | T-001 | Spoofing | Attacker intercepts login and reuses credentials | High | Implement MFA | Implemented | | T-002 | Tampering | SQL injection in search field | Critical | Parameterized queries, WAF | Implemented | | T-003 | Information Disclosure | Database credentials in config file | High | Use secrets manager | Pending | ``` ### PASTA Threat Model **PASTA** (Process for Attack Simulation and Threat Analysis) is a risk-centric threat modeling framework. **7 Stages**: ``` Stage 1: Define Business Objectives - Identify business goals and security objectives - Example: "Maintain customer trust by protecting payment information" Stage 2: Define Technical Scope - Identify software components, infrastructure, actors - Create architecture diagrams - Example: Web app, database, payment processor integration Stage 3: Application Decomposition - Create detailed data flow diagrams - Identify trust boundaries - Document APIs, protocols, data formats Stage 4: Threat Analysis - Identify threat actors (who might attack?) - Analyze attack vectors (how might they attack?) - Use threat intelligence feeds - Example threat actors: Cybercriminals seeking payment data, competitors, malicious insiders Stage 5: Vulnerability and Weakness Analysis - Review known vulnerabilities (CVEs) - Code review findings - Penetration test results - Example: OWASP Top 10 vulnerabilities Stage 6: Attack Modeling - Create attack trees showing how attacks could succeed - Simulate attack paths - Assess likelihood and impact Example Attack Tree: Compromise Payment Data ├─ AND: Exploit SQL Injection │ ├─ Find vulnerable input field │ └─ Bypass WAF └─ OR: Social Engineering ├─ Phish developer for credentials └─ Insider threat Stage 7: Risk and Impact Analysis - Calculate risk scores - Prioritize threats - Recommend countermeasures - Create remediation roadmap ``` ### Attack Trees Attack trees visually represent the ways a security goal can be compromised. **Example: Steal Customer Data** ``` [Steal Customer Data] │ ┌───────────────────┼───────────────────┐ │ │ │ [Network Attack] [Application] [Physical Access] │ Vulnerability │ │ │ │ ┌───┴───┐ ┌───┴───┐ ┌───┴───┐ │ │ │ │ │ │ [MITM] [Sniff] [SQLi] [XSS] [Steal] [Dumpster] [Laptop] [Diving] AND node: Both children must succeed OR node: Any child can succeed (default) Leaf nodes: - MITM (Man-in-the-Middle): Likelihood: Low, Cost: Medium - SQLi (SQL Injection): Likelihood: Medium, Cost: Low - XSS (Cross-Site Scripting): Likelihood: High, Cost: Low - Steal Laptop: Likelihood: Medium, Cost: Low - Dumpster Diving: Likelihood: Low, Cost: Very Low ``` **Attack Tree Analysis**: ```python class AttackTreeNode: def __init__(self, name, likelihood=0, cost=0, impact=0, node_type="OR"): self.name = name self.likelihood = likelihood # 0-1 scale self.cost = cost # Attacker cost (low, medium, high) self.impact = impact # Defender impact if successful (1-10 scale) self.node_type = node_type # AND or OR self.children = [] def add_child(self, child): self.children.append(child) def calculate_likelihood(self): """Calculate likelihood of attack path success""" if not self.children: return self.likelihood if self.node_type == "OR": # OR node: Probability that at least one child succeeds # P(A OR B) = P(A) + P(B) - P(A)*P(B) combined = 0 for child in self.children: child_likelihood = child.calculate_likelihood() combined = combined + child_likelihood - (combined * child_likelihood) return combined elif self.node_type == "AND": # AND node: Probability that all children succeed # P(A AND B) = P(A) * P(B) combined = 1.0 for child in self.children: combined *= child.calculate_likelihood() return combined # Example attack tree root = AttackTreeNode("Steal Customer Data", node_type="OR") # Network attacks network = AttackTreeNode("Network Attack", node_type="OR") network.add_child(AttackTreeNode("MITM", likelihood=0.1, cost="medium", impact=9)) network.add_child(AttackTreeNode("Packet Sniffing", likelihood=0.05, cost="low", impact=9)) # Application vulnerabilities app = AttackTreeNode("Exploit Application", node_type="OR") app.add_child(AttackTreeNode("SQL Injection", likelihood=0.3, cost="low", impact=10)) app.add_child(AttackTreeNode("XSS", likelihood=0.4, cost="low", impact=6)) # Physical access physical = AttackTreeNode("Physical Access", node_type="AND") physical.add_child(AttackTreeNode("Bypass Physical Security", likelihood=0.2, cost="medium", impact=10)) physical.add_child(AttackTreeNode("Access Database Server", likelihood=0.5, cost="low", impact=10)) root.add_child(network) root.add_child(app) root.add_child(physical) overall_likelihood = root.calculate_likelihood() print(f"Overall likelihood of successful attack: {overall_likelihood:.2%}") # Output: Overall likelihood of successful attack: 60.94% ``` --- ## Risk Assessment Frameworks ### Quantitative Risk Assessment **Single Loss Expectancy (SLE)**: ``` SLE = Asset Value × Exposure Factor Example: - Asset: Customer database - Asset Value: $5,000,000 - Exposure Factor: 0.8 (80% of value lost in a breach) - SLE = $5,000,000 × 0.8 = $4,000,000 ``` **Annualized Rate of Occurrence (ARO)**: ``` ARO = Expected number of times threat will occur per year Example: - Threat: Data breach - Historical data: 1 breach every 5 years - ARO = 1/5 = 0.2 ``` **Annualized Loss Expectancy (ALE)**: ``` ALE = SLE × ARO Example: - SLE = $4,000,000 - ARO = 0.2 - ALE = $4,000,000 × 0.2 = $800,000 Interpretation: Expected to lose $800,000 per year from this risk ``` **Cost-Benefit Analysis**: ``` Cost-Benefit = ALE (before) - ALE (after) - Cost of Control Example: - ALE before control: $800,000 - ALE after implementing DLP and encryption: $100,000 (reduced likelihood to 0.025) - Annual cost of controls: $150,000 Cost-Benefit = $800,000 - $100,000 - $150,000 = $550,000 Positive value → Control is cost-effective Negative value → Control costs more than risk reduction ``` **Quantitative Risk Assessment Example**: ```python class QuantitativeRiskAssessment: def __init__(self, asset_value, exposure_factor, aro): self.asset_value = asset_value self.exposure_factor = exposure_factor # 0-1 self.aro = aro # Annual Rate of Occurrence def calculate_sle(self): """Single Loss Expectancy""" return self.asset_value * self.exposure_factor def calculate_ale(self): """Annualized Loss Expectancy""" return self.calculate_sle() * self.aro def cost_benefit_analysis(self, control_cost, new_aro): """Determine if control is cost-effective""" ale_before = self.calculate_ale() ale_after = self.calculate_sle() * new_aro annual_savings = ale_before - ale_after net_benefit = annual_savings - control_cost return { "ale_before": ale_before, "ale_after": ale_after, "annual_savings": annual_savings, "control_cost": control_cost, "net_benefit": net_benefit, "roi_percent": (net_benefit / control_cost * 100) if control_cost > 0 else 0, "recommendation": "Implement" if net_benefit > 0 else "Do not implement" } # Example: Assess risk of ransomware attack ra = QuantitativeRiskAssessment( asset_value=10_000_000, # Value of systems + downtime cost exposure_factor=0.6, # 60% impact (some data recoverable from backups) aro=0.15 # 15% chance per year (once every 6-7 years) ) print(f"SLE: ${ra.calculate_sle():,.0f}") print(f"ALE: ${ra.calculate_ale():,.0f}") # Evaluate EDR solution that reduces ARO from 0.15 to 0.02 result = ra.cost_benefit_analysis( control_cost=200_000, # Annual cost of EDR new_aro=0.02 # Reduced to 2% chance per year ) print(f"nControl Cost-Benefit Analysis:") print(f"ALE Before: ${result['ale_before']:,.0f}") print(f"ALE After: ${result['ale_after']:,.0f}") print(f"Annual Savings: ${result['annual_savings']:,.0f}") print(f"Net Benefit: ${result['net_benefit']:,.0f}") print(f"ROI: {result['roi_percent']:.1f}%") print(f"Recommendation: {result['recommendation']}") # Output: # SLE: $6,000,000 # ALE: $900,000 # # Control Cost-Benefit Analysis: # ALE Before: $900,000 # ALE After: $120,000 # Annual Savings: $780,000 # Net Benefit: $580,000 # ROI: 290.0% # Recommendation: Implement ``` ### Qualitative Risk Assessment **Risk Matrix (Likelihood × Impact)**: ``` Impact → │ 1-Minimal │ 2-Minor │ 3-Moderate│ 4-Major │5-Catastrophic│ L │ │ │ │ │ │ i 1 │ Low │ Low │ Low │ Medium │ Medium │ k │ │ │ │ │ │ e 2 │ Low │ Low │ Medium │ High │ High │ l │ │ │ │ │ │ i 3 │ Low │ Medium │ Medium │ High │ Critical │ h │ │ │ │ │ │ o 4 │ Medium │ High │ High │ Critical │ Critical │ o │ │ │ │ │ │ d 5 │ Medium │ High │ Critical │ Critical │ Critical │ ↓ │ │ │ │ │ │ Risk Levels: - Low: Accept risk, monitor - Medium: Mitigate within 90 days - High: Mitigate within 30 days - Critical: Immediate mitigation required ``` **Likelihood Scale**: ``` 5 - Almost Certain (>75% probability in next 12 months) • Known active exploits • High attacker motivation • Easy to exploit 4 - Likely (50-75% probability) • Exploits available • Moderate attacker motivation • Moderate exploit difficulty 3 - Possible (25-50% probability) • Some exploits available • Some attacker motivation • Some technical barriers 2 - Unlikely (5-25% probability) • No known exploits • Low attacker motivation • Significant technical barriers 1 - Rare ($10M financial loss • Complete business disruption >1 week • Massive data breach (>1M records) • Permanent reputation damage • Regulatory penalties >$1M • Potential legal/criminal liability 4 - Major • $1M-$10M financial loss • Significant business disruption (3-7 days) • Large data breach (100K-1M records) • Severe reputation damage • Regulatory penalties $100K-$1M 3 - Moderate • $100K-$1M financial loss • Moderate business disruption (1-3 days) • Medium data breach (1K-100K records) • Moderate reputation damage • Regulatory penalties $10K-$100K 2 - Minor • $10K-$100K financial loss • Minor business disruption (<1 day) • Small data breach (<1K records) • Limited reputation damage • Regulatory penalties <$10K 1 - Minimal • = 14: priority = "P0" sla_days = 1 elif priority_score >= 10: priority = "P1" sla_days = 7 elif priority_score >= 6: priority = "P2" sla_days = 30 else: priority = "P3" sla_days = 90 return { "priority_score": round(priority_score, 2), "priority_level": priority, "sla_days": sla_days, "rationale": self._generate_rationale(vuln, priority_score) } def _generate_rationale(self, vuln, priority_score): factors = [] if vuln.get("cvss_score", 0) >= 9.0: factors.append("Critical CVSS score") if vuln.get("exploit_in_wild"): factors.append("Active exploitation in wild") if vuln.get("exploit_available"): factors.append("Public exploit available") if vuln.get("exposure") == "internet_facing": factors.append("Internet-facing system") if vuln.get("asset_criticality", 0) >= 4: factors.append("Critical business system") if vuln.get("data_sensitivity") == "highly_confidential": factors.append("Contains sensitive data") return "; ".join(factors) if factors else "Standard risk assessment" # Example vulnerability assessments vp = VulnerabilityPrioritization() # Scenario 1: Log4Shell on internet-facing application server vuln1 = { "cve": "CVE-2021-44228", "cvss_score": 10.0, "exploit_available": True, "exploit_in_wild": True, "asset_criticality": 5, "exposure": "internet_facing", "data_sensitivity": "highly_confidential", "compensating_controls": False } result1 = vp.calculate_priority_score(vuln1) print("Vulnerability 1: Log4Shell on production web server") print(f" Priority Score: {result1['priority_score']}") print(f" Priority Level: {result1['priority_level']}") print(f" SLA: Patch within {result1['sla_days']} day(s)") print(f" Rationale: {result1['rationale']}n") # Scenario 2: Medium severity vuln on internal dev server with WAF protection vuln2 = { "cve": "CVE-2023-12345", "cvss_score": 6.5, "exploit_available": False, "exploit_in_wild": False, "asset_criticality": 2, "exposure": "internal", "data_sensitivity": "confidential", "compensating_controls": True # WAF blocking exploit } result2 = vp.calculate_priority_score(vuln2) print("Vulnerability 2: Medium CVSS on internal dev server") print(f" Priority Score: {result2['priority_score']}") print(f" Priority Level: {result2['priority_level']}") print(f" SLA: Patch within {result2['sla_days']} days") print(f" Rationale: {result2['rationale']}") ``` --- ## Penetration Testing ### Penetration Test Types ``` 1. Black Box Testing - No prior knowledge of system - Simulates external attacker - Tests external defenses - Longest time required 2. Gray Box Testing - Partial knowledge (e.g., user account) - Simulates malicious insider or compromised account - Most common type - Balanced approach 3. White Box Testing (Clear Box) - Full knowledge (code, architecture, credentials) - Most comprehensive testing - Shortest time required - Identifies maximum vulnerabilities 4. Red Team Exercise - Realistic attack simulation - Multi-vector attacks - Tests detection and response - Blue team (defenders) may or may not be aware 5. Purple Team Exercise - Red team + Blue team collaboration - Improve detection and response - Knowledge sharing - Continuous improvement focus ``` ### Penetration Testing Methodology ``` Phase 1: Planning and Reconnaissance ├─ Define scope (IP ranges, domains, out-of-scope systems) ├─ Rules of engagement (testing windows, contacts, escalation) ├─ Passive reconnaissance (OSINT, DNS, WHOIS) └─ Active reconnaissance (port scanning, service enumeration) Phase 2: Scanning and Enumeration ├─ Port scanning (nmap, masscan) ├─ Service version detection ├─ Vulnerability scanning (Nessus, OpenVAS) ├─ Web application scanning (Burp Suite, OWASP ZAP) └─ Enumerate users, shares, services Phase 3: Gaining Access (Exploitation) ├─ Exploit vulnerabilities (Metasploit, custom exploits) ├─ Password attacks (brute force, dictionary, password spraying) ├─ Social engineering (phishing, pretexting) ├─ Web application attacks (SQLi, XSS, CSRF) └─ Wireless attacks (WPA2 cracking, rogue AP) Phase 4: Maintaining Access ├─ Install backdoors ├─ Create persistent access mechanisms ├─ Establish command and control (C2) └─ Privilege escalation Phase 5: Lateral Movement ├─ Network enumeration ├─ Credential harvesting (Mimikatz, password reuse) ├─ Pivot to other systems └─ Escalate to domain admin or crown jewels Phase 6: Covering Tracks (Clean Up) ├─ Remove tools and artifacts ├─ Clear logs (for red team exercises only) └─ Document all actions for client Phase 7: Reporting ├─ Executive summary ├─ Technical findings with CVSS scores ├─ Evidence (screenshots, logs) ├─ Remediation recommendations ├─ Risk ratings └─ Retest scope ``` ### Common Penetration Testing Tools ``` Reconnaissance: ├─ nmap - Network scanner ├─ masscan - Fast port scanner ├─ theHarvester - Email/subdomain discovery ├─ Shodan - Internet-connected device search ├─ Recon-ng - Web reconnaissance framework └─ OSINT Framework - OSINT collection Vulnerability Scanning: ├─ Nessus - Commercial vulnerability scanner ├─ OpenVAS - Open source vulnerability scanner ├─ Nikto - Web server scanner └─ SQLmap - SQL injection scanner Exploitation: ├─ Metasploit Framework - Exploitation framework ├─ Exploit-DB - Exploit database ├─ Social Engineer Toolkit (SET) - Social engineering └─ Cobalt Strike - Commercial red team platform Web Application Testing: ├─ Burp Suite Pro - Web security testing ├─ OWASP ZAP - Web app scanner ├─ Acunetix - Web vulnerability scanner └─ Nikto - Web server scanner Password Attacks: ├─ John the Ripper - Password cracker ├─ Hashcat - Advanced password recovery ├─ Hydra - Network login cracker ├─ CrackMapExec - Post-exploitation tool └─ Mimikatz - Credential extraction Post-Exploitation: ├─ PowerShell Empire - Post-exploitation framework ├─ BloodHound - AD attack path analysis ├─ Responder - LLMNR/NBT-NS poisoning └─ Impacket - Network protocol toolkit Wireless: ├─ Aircrack-ng - WiFi security auditing ├─ Kismet - Wireless network detector └─ Wifite - Automated wireless attack tool ``` --- ## Security Assessment Deliverables ### Penetration Test Report Template ```markdown # Penetration Test Report ## Executive Summary **Client**: Acme Corporation **Test Date**: January 15-19, 2025 **Test Type**: External and Internal Penetration Test (Gray Box) **Scope**: Production web applications and internal network (10.0.0.0/16) **Tester**: [Red Team Company] ### Key Findings **Critical Risk**: 2 findings **High Risk**: 5 findings **Medium Risk**: 12 findings **Low Risk**: 8 findings **Informational**: 6 findings ### Summary The penetration test identified several critical vulnerabilities that could allow an attacker to gain unauthorized access to sensitive customer data. The most critical finding is an SQL injection vulnerability in the customer portal that allows full database access without authentication. **Recommendations (Priority)**: 1. CRITICAL: Patch SQL injection vulnerability within 24 hours 2. CRITICAL: Disable TLS 1.0/1.1 on all systems within 7 days 3. HIGH: Implement MFA for all user accounts within 30 days 4. HIGH: Patch Log4Shell vulnerability on application servers within 7 days ## Technical Findings ### Critical Finding 1: SQL Injection in Customer Portal **Severity**: Critical (CVSS 9.8) **Category**: Web Application Security **Affected System**: https://portal.acme.com/search **CVE**: N/A (Custom application) #### Description The customer portal's search functionality is vulnerable to SQL injection due to insufficient input validation. An attacker can inject arbitrary SQL commands to extract sensitive data from the database, including customer PII and credit card information. #### Proof of Concept ``` Request: GET /search?query=' UNION SELECT username,password FROM users-- HTTP/1.1 Host: portal.acme.com Response: [List of all usernames and hashed passwords] ``` #### Impact - Complete database compromise - Exfiltration of 500,000+ customer records containing PII - Compliance violations (GDPR, PCI-DSS) - Potential regulatory fines #### Remediation 1. **Immediate** (within 24 hours): - Take search feature offline OR - Implement input validation to reject SQL metacharacters - Deploy WAF rule to block SQL injection attempts 2. **Short-term** (within 7 days): - Rewrite queries using parameterized statements (prepared statements) - Implement least privilege database accounts for application - Enable database query logging 3. **Long-term**: - Conduct secure code review of entire application - Implement SAST scanning in CI/CD pipeline - Security awareness training for developers #### References - OWASP SQL Injection: https://owasp.org/www-community/attacks/SQL_Injection - CWE-89: Improper Neutralization of Special Elements used in an SQL Command --- ### High Finding 1: Outdated TLS Configuration **Severity**: High (CVSS 7.5) **Category**: Cryptography **Affected Systems**: All web servers (15 systems) #### Description Web servers support deprecated TLS 1.0 and TLS 1.1 protocols, which have known cryptographic weaknesses. These protocols are vulnerable to BEAST and POODLE attacks. #### Proof of Concept ```bash $ nmap --script ssl-enum-ciphers -p 443 portal.acme.com PORT STATE SERVICE 443/tcp open https | ssl-enum-ciphers: | TLSv1.0: | ciphers: | TLS_RSA_WITH_3DES_EDE_CBC_SHA (weak) ``` #### Impact - Man-in-the-middle attacks possible - Decryption of encrypted traffic - Compliance violations (PCI-DSS requires TLS 1.2+) #### Remediation 1. Disable TLS 1.0 and TLS 1.1 on all web servers 2. Enable TLS 1.2 and TLS 1.3 only 3. Configure strong cipher suites (ECDHE, AES-GCM) 4. Enable HSTS header (Strict-Transport-Security) Example nginx configuration: ```nginx ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384'; ssl_prefer_server_ciphers on; add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always; ``` --- [Additional findings...] ## Appendix A: Scope and Methodology ### Scope **In Scope**: - External web applications (*.acme.com) - Internal network (10.0.0.0/16) - Wireless networks (guest and corporate) **Out of Scope**: - Production database servers (testing allowed, disruption prohibited) - Third-party SaaS applications - Physical security testing - Social engineering attacks ### Methodology Testing followed the OWASP Testing Guide v4 and PTES (Penetration Testing Execution Standard). ### Testing Windows - External testing: 24/7 - Internal testing: Monday-Friday, 9 AM - 5 PM EST - No testing on holidays ## Appendix B: Tools Used - Nmap 7.94 - Network scanning - Burp Suite Pro 2023.12 - Web application testing - Metasploit Framework 6.3 - Exploitation - SQLmap 1.8 - SQL injection testing - Nessus 10.6 - Vulnerability scanning ## Appendix C: Risk Rating Methodology Risk ratings use CVSS v3.1 base scores with environmental adjustments: - Critical: 9.0-10.0 - High: 7.0-8.9 - Medium: 4.0-6.9 - Low: 0.1-3.9 ``` --- ## Continuous Risk Management ### Risk Register Maintenance ```yaml risk_id: R-042 title: "Ransomware Attack on Production Infrastructure" category: "Cybersecurity" owner: "CISO" status: "Open" threat: actor: "Organized cybercriminal group" motivation: "Financial gain" capability: "High (commodity ransomware widely available)" vulnerability: description: "Unpatched servers, no EDR, limited backup testing" cvss_score: 8.5 likelihood: qualitative: "Likely (4/5)" quantitative_aro: 0.3 justification: "Healthcare sector heavily targeted, recent incidents at peers" impact: qualitative: "Catastrophic (5/5)" quantitative_sle: "$8,000,000" justification: "3-5 day downtime, patient care disruption, ransom demand, recovery costs" risk_score: qualitative: 20 # 4 × 5 = Critical quantitative_ale: "$2,400,000" # $8M × 0.3 risk_response: "Mitigate" controls: existing: - "Daily backups to cloud storage" - "Antivirus on all endpoints" - "Firewall segmentation" planned: - control: "Deploy EDR solution (CrowdStrike)" cost: "$150,000/year" completion_date: "2025-03-01" risk_reduction: "ARO from 0.3 to 0.05" - control: "Implement offline, immutable backups" cost: "$75,000 setup + $30,000/year" completion_date: "2025-02-15" risk_reduction: "SLE from $8M to $2M" - control: "Patch management automation" cost: "$50,000 setup + $20,000/year" completion_date: "2025-02-01" risk_reduction: "ARO from 0.3 to 0.1" residual_risk: qualitative: "Medium (2 × 3 = 6)" quantitative_ale: "$100,000" # $2M × 0.05 acceptable: true justification: "ALE reduced by 95%, within risk appetite" next_review_date: "2025-07-01" last_updated: "2025-01-15" ``` ### Risk Appetite Statement ``` Board-Approved Risk Appetite (Annual): Financial Loss: ├─ Per incident: Maximum $1M ├─ Annual aggregate: Maximum $5M └─ Unacceptable: >$10M single event Data Breach: ├─ Acceptable: 10,000 records OR any PHI/PII Downtime: ├─ Acceptable: 24 hours of critical systems Compliance: ├─ Acceptable: Minor findings that don't impact certification ├─ Tolerable: Moderate findings with 90-day remediation └─ Unacceptable: Major findings, loss of certification, regulatory fines Reputation: ├─ Acceptable: Local media coverage, contained impact ├─ Tolerable: National media coverage, customer churn 20% customer churn ``` This risk appetite guides all risk acceptance decisions. Any risk exceeding "tolerable" thresholds must be escalated to the Board for explicit acceptance.