Security Architecture Views: Showing Your Design

3.5.1 Why Architecture Views Matter

Architecture views are like blueprints that show how security is built into your device. They help:

• FDA reviewers understand your security design
• Development teams implement consistently
• Security assessments identify gaps
• Future maintainers understand the system

The FDA specifically requires four types of architecture views, each serving a different purpose.

3.5.2 Global System View

Purpose

According to FDA guidance: "A global system view should describe the overall medical device system, including the device itself and all internal and external connections."

System Components:

• The medical device itself
• Connected medical devices
• IT infrastructure (servers, databases)
• Network components
• External services (cloud, update servers)
• User interfaces (apps, workstations)

Communication Paths:

• Wired connections (USB, Ethernet)
• Wireless connections (Wi-Fi, Bluetooth)
• Remote connections (VPN, internet)
• Service connections (JTAG, serial)

Trust Boundaries:

• Between device and external world
• Between different privilege levels
• Between different networks
• Between different user types

Example Global System View Elements

Key Considerations

Completeness: Include ALL connections, even those used rarely (like service ports)

Clarity: Use standard notation and clear labels

Updates: Keep current as system evolves

3.5.3 Multi-Patient Harm View

Purpose

Per FDA guidance, this view "addresses how the device and system defend against and/or respond to attacks with the potential to harm multiple patients."

Understanding Multi-Patient Harm

Multi-patient harm can occur when:

• Multiple devices are compromised simultaneously
• A central system affecting multiple devices fails
• Malware spreads between devices
• Common vulnerabilities affect device fleets

What to Include

Attack Scenarios:

• Ransomware affecting all devices on network
• Compromised update pushing malware
• Central monitoring system failure
• Coordinated device manipulation

Defensive Measures:

• Network segmentation
• Device isolation capabilities
• Anomaly detection
• Incident response procedures

Impact Analysis:

• How many devices could be affected?
• What's the patient impact?
• How quickly could it spread?
• What's the recovery time?

Example Scenarios to Address

1. Network-Based Attack

   • Attacker gains network access
   • Scans for vulnerable devices
   • Exploits common vulnerability
   • Compromises multiple devices

2. Supply Chain Attack

   • Malicious update created
   • Distributed to all devices
   • Activates simultaneously
   • Affects entire fleet

3. Central System Compromise

   • EMR system breached
   • Sends malicious commands
   • Multiple devices respond
   • Patient care disrupted

Example Multi-Patient Harm View

3.5.4 Updateability and Patchability View

Purpose

This view "describes the end-to-end process that permits software updates and patches to be deployed to the device."

Critical Update Path Elements

Update Creation:

• Development environment security
• Code signing process
• Update packaging
• Version control

Update Distribution:

• Update server security
• Distribution channels
• Network paths
• Authentication methods

Update Installation:

• Device authentication of updates
• Integrity verification
• Installation process
• Rollback capability

Update Verification:

• Success confirmation
• Functionality testing
• Error handling
• Status reporting

Security Controls Throughout

Each step needs specific security controls:

1. Authentication: Verify update source
2. Integrity: Ensure update unchanged
3. Confidentiality: Protect update contents
4. Availability: Maintain device function
5. Authorization: Control who can update

Common Pitfalls to Avoid

• Unsigned updates
• Unencrypted distribution
• No rollback mechanism
• Weak authentication
• Missing integrity checks

Example Updateability and Patchability View

3.5.5 Security Use Case Views

Purpose

These views "cover all medical device system functionality through which a security compromise could impact the safety or effectiveness of the device."

Identifying Critical Use Cases

Ask yourself:

• What functions could harm patients if compromised?
• Which features have the highest privilege?
• What operations handle sensitive data?
• Which interfaces are most exposed?

Common Security-Critical Use Cases

1. Clinical Parameter Changes

   • Therapy settings
   • Alarm limits
   • Dosage calculations
   • Treatment protocols

2. Emergency Access

   • Override procedures
   • Rapid access needs
   • Audit requirements
   • Recovery methods

3. Remote Access

   • Service connections
   • Telemedicine interfaces
   • Remote monitoring
   • Cloud connectivity

4. Data Management

   • Patient data access
   • Export functions
   • Backup procedures
   • Data deletion

Documenting Each Use Case

For each security use case, document:

Scenario Description:

• What happens normally
• User types involved
• Data flows
• Success criteria

Security Requirements:

• Authentication needs
• Authorization levels
• Audit requirements
• Data protection

Threat Scenarios:

• How could this be attacked?
• What's the impact?
• How is it detected?
• How is it prevented?

Security Controls:

• Specific measures implemented
• Defense in depth approach
• Monitoring capabilities
• Response procedures

Example Use Case View