Threat Model Documentation for eSTAR Submission

6.4.1 Evolving Your Threat Model for FDA Review

Your threat modeling effort (detailed in Chapter 3.6) serves as the foundation for understanding your device's attack surface. As you prepare for submission, your existing threat model needs enhancement to meet FDA's specific documentation requirements and review expectations.

The Evolution Approach: Build on Your Foundation

During development (Chapter 3.6), you created:

• Data flow diagrams showing system components
• STRIDE analysis identifying potential threats
• Attack trees mapping threat scenarios
• Initial threat prioritization

For FDA submission, enhance this same work by:

• Adding explicit traceability to architecture views and risk assessments
• Expanding threat descriptions with clinical impact analysis
• Including comprehensive mitigation mapping
• Demonstrating systematic coverage of attack surface

What Changes Between Development and Submission:

Development Focus	Submission Enhancement
"What could go wrong?"	"How does this threaten patient safety?"
Technical threat identification	Clinical impact assessment
Basic threat prioritization	Risk-based threat ranking with rationale
Internal team understanding	FDA reviewer comprehension
Implementation planning	Mitigation demonstration

6.4.2 Pre-Submission Threat Model Review

Conduct a "submission readiness assessment" of your threat model 8-10 weeks before submission.

Submission Readiness Checklist

Completeness Verification:

• All system components from architecture views are threat modeled
• External interfaces comprehensively analyzed
• Trust boundaries systematically examined
• STRIDE applied to all relevant elements
• Clinical use scenarios covered

FDA-Specific Enhancements Needed:

• Threats linked to potential patient harm
• Mitigation strategies clearly mapped
• Residual risks explicitly identified
• Emergency scenarios addressed
• Multi-patient harm scenarios included

Common Enhancement Needs

Insufficient Clinical Context Example:

❌ Development-Level Threat:
"T-001: Attacker could spoof authentication messages"

✅ Submission-Ready Threat:
"T-001: Authentication Spoofing Leading to Unauthorized Therapy Changes
Description: An attacker could craft fake authentication messages to bypass 
user verification, potentially gaining access to therapy configuration functions.
Clinical Impact: Could result in incorrect insulin dosing, leading to 
hypoglycemia or diabetic ketoacidosis.
Likelihood: Medium (requires network access and protocol knowledge)
Mitigation: Implemented mutual certificate authentication (CTL-AUTH-002) and 
message integrity validation (CTL-INT-001)
Residual Risk: Low after controls"

Missing Traceability Example:

❌ Development-Level Analysis:
"DoS attack could crash the device"

✅ Submission-Ready Analysis:
"T-045: Network Denial of Service Attack
Threat Source: External attacker on hospital network
Attack Vector: Flood network interface with malformed packets
Referenced Architecture: Global System View, Figure 2 (Network Interface)
Affected Components: Network communication module, patient monitoring display
Clinical Impact: Loss of real-time patient monitoring during attack
Controls: Rate limiting (CTL-NET-003), network segmentation (CTL-NET-001)
Testing: Validated in security test report Section 4.3
Risk Assessment: Documented as RSK-023 with Medium residual risk"

6.4.3 Enhanced Documentation Structure

Transform your development threat model into a submission-ready document.

Recommended Enhancement Structure

Executive Summary (New for Submission):

• Threat modeling methodology used
• Key findings and risk areas
• Mitigation approach overview
• Integration with other security activities

System Model Enhancement:

Original: Basic DFD with component relationships
Enhanced: DFD with explicit security annotations:
- Trust boundaries clearly marked and explained
- Security controls annotated on diagram
- Attack surface highlighted
- External dependencies identified with risk ratings

Threat Analysis Enhancement:

• Convert STRIDE tables to threat descriptions with clinical context
• Add threat actor analysis (who would attack and why)
• Include attack feasibility assessment
• Map threats to architecture components

Risk Integration (New Section):

• Clear mapping from threats to risk assessment
• Explanation of how threats become risks
• Documentation of threat-to-control relationships

6.4.4 eSTAR Integration and Organization

File Placement Strategy

Primary Threat Model Document:

18-Threat-Model-[DeviceName]-v2.1.pdf
├── Executive Summary
├── Methodology and Scope  
├── System Models (Enhanced DFDs)
├── Threat Analysis by Component
├── Multi-Patient Threat Scenarios
├── Mitigation Mapping
└── Appendices (Detailed STRIDE tables, etc.)

Cross-Document Integration:

• Architecture Views (Section 6.3): Reference specific threats addressed by architectural decisions
• Risk Assessment (Section 6.5): Use threat IDs consistently across documents
• Security Controls: Map each control to specific threats
• Test Documentation: Reference threats validated through testing

Traceability Table Example

Threat ID	Architecture Element	Risk ID	Control ID	Test Case
T-001	Authentication Module	RSK-003	CTL-AUTH-002	TC-SEC-15
T-002	Network Interface	RSK-007	CTL-NET-001	TC-SEC-23
T-003	Update System	RSK-012	CTL-UPD-001	TC-SEC-31

6.4.5 Addressing FDA's Specific Concerns

FDA reviewers evaluate threat models for comprehensiveness and clinical relevance.

Key FDA Review Questions

"Did you consider all ways the device could be attacked?"

• Demonstrate systematic coverage using recognized methodology
• Show consideration of all interfaces, even rarely used ones
• Address both technical and non-technical attack vectors

"How do these threats relate to patient safety?"

• Explicit clinical impact analysis for each significant threat
• Clear connection between technical compromise and patient harm
• Consideration of emergency scenarios and device availability

"What did you do about the threats you found?"

• Clear mitigation strategy for each threat
• Explanation of risk acceptance decisions
• Demonstration of defense-in-depth approach

Enhancement Examples by Category

Network-Based Threats:

Enhanced Documentation Should Include:
- Specific attack vectors (MITM, eavesdropping, injection)
- Network topology assumptions and limitations
- Hospital network integration risks
- Wireless communication vulnerabilities
- Remote access attack scenarios

Physical Access Threats:

Enhanced Documentation Should Include:
- Service port access scenarios
- Device tampering possibilities
- Physical environment assumptions
- Maintenance access security
- USB/removable media risks

Software/Firmware Threats:

Enhanced Documentation Should Include:
- Malicious update scenarios
- Memory corruption vulnerabilities
- Privilege escalation paths
- Third-party component risks
- Configuration tampering

6.4.6 Multi-Patient Harm Threat Analysis

FDA specifically wants to see how threats could affect multiple patients simultaneously.

Enhanced Multi-Patient Scenarios

Network Propagation Threats:

T-101: Ransomware Propagation via Hospital Network
Attack Scenario: Attacker gains access to one device, deploys ransomware 
that spreads to other devices on same network segment
Affected Systems: Up to 15 devices on medical device VLAN
Clinical Impact: Simultaneous loss of monitoring for ICU patients
Mitigation: Network segmentation (CTL-NET-001), endpoint detection 
(CTL-MON-002), isolation capability (CTL-RES-001)
Detection Time: <5 minutes via anomaly detection
Recovery Time: 30 minutes via automated isolation and clean backup restore

Update System Compromise:

T-102: Malicious Update Distribution
Attack Scenario: Compromise of update server leading to distribution of 
malicious firmware to entire device fleet
Affected Systems: All devices configured for automatic updates (est. 1,200 units)
Clinical Impact: Potential therapy disruption at multiple facilities
Mitigation: Code signing (CTL-INT-002), staged rollout (CTL-UPD-003), 
rollback capability (CTL-RES-003)
Detection: Digital signature validation, behavioral monitoring
Recovery: Automated rollback within 15 minutes

6.4.7 Quality Standards for Submission

Professional Documentation Requirements

Diagram Quality:

• Use standard threat modeling notation (DFD3, UML)
• Consistent symbols and color coding throughout
• Clear, readable fonts and labels
• Professional layout and formatting

Threat Descriptions:

• Structured format with consistent elements
• Clear, technical language appropriate for FDA reviewers
• Avoid jargon without explanation
• Include quantitative risk assessments where possible

Completeness Validation:

• Every component in architecture views has threat analysis
• All external interfaces examined for threats
• Emergency and maintenance scenarios considered
• Third-party component risks addressed

6.4.8 Common Submission Deficiencies

Learn from frequent FDA feedback to avoid common mistakes.

Incomplete Threat Coverage

FDA Feedback:

"The threat model does not appear to consider USB port attacks mentioned in your device description. Please provide analysis of threats via physical interfaces."

Prevention:

• Cross-reference all interfaces mentioned in device description
• Include rarely used or maintenance-only interfaces
• Address physical access scenarios explicitly

Insufficient Clinical Context

FDA Feedback:

"The threat analysis focuses on technical impacts but doesn't adequately address how these threats could affect patient care. Please clarify clinical risks."

Prevention:

• Include clinical impact for every medium/high severity threat
• Consider emergency scenarios where device unavailable
• Address both immediate and delayed patient harm

Poor Integration with Risk Assessment

FDA Feedback:

"Threats identified in threat model don't align with risks in your risk assessment. Please ensure consistency."

Prevention:

• Use consistent threat/risk identification numbers
• Ensure every significant threat becomes a risk
• Verify mitigation strategies match between documents

6.4.9 Final Submission Preparation

4-Week Pre-Submission Checklist

Document Quality:

• Professional formatting and presentation
• Consistent terminology across all documents
• Clear traceability to other submission elements
• Executive summary provides clear overview

Technical Completeness:

• All architecture components threat modeled
• Multi-patient scenarios adequately addressed
• Clinical impacts clearly articulated
• Mitigation strategies comprehensively documented

FDA Reviewer Perspective:

• Document tells complete security story
• Threats clearly linked to patient safety
• Systematic methodology evident
• Professional presentation throughout

Remember: Your threat model should demonstrate to FDA that you've systematically thought through how your device could be attacked and what that means for patient safety. The goal is showing comprehensive analysis, not perfection.

---

Key Insight: The most effective threat model submissions build naturally from development work, enhanced with FDA-specific context and traceability. This approach ensures accuracy while meeting regulatory expectations for comprehensive security analysis.