Threat Modeling for SaMD: A Step-by-Step Guide to Compliance with MDR and FDA Regulations

In the rapidly evolving field of Software as a Medical Device (SaMD), ensuring cybersecurity is paramount. For example in 2023 more than 40 million US citizens were affected by data breaches in healthcare. Regulatory bodies like the FDA and Competent Authorities governing the Medical Device Regulation (MDR) in the EU (refer to MDCG2019-16 rev 1) mandate adherence to threat modeling – a pivotal element in the cybersecurity risk management framework.

Within this blogpost we offer a practical walkthrough for organizations looking to develop a threat modeling strategy that aligns with these requirements.

At the heart of our exploration is a fictional device:

'a cloud-based platform designed to segment and analyze DICOM data received from a hospital's PACS system and visualize the results through an interactive web application'

This system, depicted on the right, represents the intricate network of data exchange between hospital networks, cloud services, and end-users.

It provides a snapshot of our device's architecture, serving as the groundwork for the detailed Data Flow Diagram and subsequent threat modeling activities.

Incorporating threat modeling from the initial phases of SaMD development is crucial. It necessitates a deliberate approach to planning, compelling developers to integrate cybersecurity considerations into their software development plans. Creating a dedicated cybersecurity plan, or embedding these considerations within the broader development plan, is not merely advantageous—it's essential. Such proactive planning is the key to preempting costly post-development modifications, ensuring that security is an integral, foundational element of the device's architecture. This foresight facilitates a smoother progression toward developing a secure, compliant SaMD.

As we proceed, this guide will unravel the complexities of threat modeling, ensuring that organizations are equipped to navigate the challenges of securing SaMDs in alignment with MDR and FDA regulations.

Creating a Detailed Data Flow Diagram (DFD)

A Data Flow Diagram (DFD) is the cornerstone of the threat modeling process, offering a visual representation of how data is processed and flows through a Software Medical Device (SaMD). Constructing a DFD provides a foundational understanding of the system's architecture, essential for pinpointing potential security vulnerabilities. The MITRE 'Playbook for Threat Modeling - Medical Devices', developed in cooperation with the FDA, provides a more detailed explanation and is a resource to examine as a manufacturer when starting your threat modeling.

Key Components of a DFD:

External Entities: These represent the actors outside your system's control that interact with it, such as hospital staff using the DICOM uploader and the PACS systems that store patient images. Identifying these entities helps to understand where data originates and where it needs to be securely delivered.

Processes: These are the operations within your system that act upon data, including a pseudonymiser, which removes or pseudonymises patient data, and the segmentation pipeline that processes medical images for analysis. Mapping out these processes reveals the transformation points of data, highlighting areas where security measures are critical.

Data Stores: In Data Stores one catalogs where data resides within a system, whether temporarily or permanently. This could include temporary storage for pseudonymized DICOM files awaiting processing and databases that store user credentials and processed case information.

Data Flows: This aspect tracks the movement of data between entities, processes, and stores, illustrating the path data takes from entry to exit. For example, arrows from the PACS to the pseudonymiser and then to the cloud showcase the DICOM data's journey.

Trust Boundaries: These indicate transitions between different trust levels within your system. Delineating these boundaries, such as those around the DICOM uploader, pseudonymiser, and UI API, is crucial for identifying where to implement security controls to protect against unauthorized access.

Simplifying the DFD Creation Process

Instead of detailing the drafting and refining steps, focus on the iterative nature of constructing a DFD. Begin with an initial layout that captures the main components and their interactions. Collaborate with cross-functional teams—development, operations, and compliance—to ensure a comprehensive representation of the system. As your understanding of the system evolves or as changes are made, revisit and update the DFD to maintain its accuracy and relevance.

This iterative approach not only simplifies the DFD creation process but also ensures that your threat modeling efforts are based on a current and holistic view of your SaMD's architecture.

On the right we have a simplified DFD for our fictional device. This DFD serves as a robust foundation for identifying security threats and implementing the necessary safeguards to protect your medical device throughout its lifecycle.

Data Flow Diagram for the fictional SaMD

Identifying Threats with STRIDE

In the realm of cybersecurity the STRIDE framework offers a structured methodology for uncovering potential threats. STRIDE—an acronym for Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege—categorizes the primary security threats that a system may face. This methodical approach is instrumental in identifying vulnerabilities across the system's architecture, as depicted in the Data Flow Diagram (DFD).

Breaking Down STRIDE

Spoofing: This threat involves an attacker impersonating a user or device, potentially gaining unauthorized access to sensitive data or systems.
Tampering: Refers to the unauthorized modification of data, which could compromise data integrity and lead to incorrect decision-making or actions.
Repudiation: Occurs when users, malicious or otherwise, deny performing actions, often due to the lack of sufficient logging or auditing capabilities.
Information Disclosure: The exposure of confidential information to unauthorized parties, posing significant privacy and compliance risks.
Denial of Service (DoS): An attack that disrupts service availability, affecting user access and system functionality.
Elevation of Privilege: When an attacker gains higher access levels than authorized, potentially leading to full system compromise.

Applying STRIDE involves a thorough examination of each component within the DFD to pinpoint where these threat types could exploit vulnerabilities. This focused analysis aids in determining where to bolster defenses and implement protective measures effectively.

Prioritizing Threats with a Risk-Based Approach:

A critical step in threat modeling is assessing the risk level of identified threats, which involves evaluating both the probability of occurrence and the potential severity of impact. This assessment helps in allocating resources judiciously, prioritizing threats that pose the highest risk to the system.

List of identified Threats
Threat ID	STRIDE Category	Description of the Threat	Probability (1-5)	Severity (1-5)	Threat Level (L, M, H)
T1.1	Spoofing	A threat actor spoofs the hospital network's IP to trick the DICOM uploader into accepting malicious data.	2	5	H
T1.2	Spoofing	The system may have flaws in the implementation of authentication mechanisms, potentially allowing attackers to compromise user sessions or credentials, especially concerning the Web UI.	3	4	H
T2.1	Tampering	DICOM data in transit to the cloud is intercepted and altered, compromising the integrity of patient information.	2	5	H
T2.2	Tampering	An attacker could exploit insufficient input validation to inject malicious code into the system, such as SQL injection or command injection, affecting the DICOM API or other data processing components.	3	5	H
T3.1	Repudiation	Hospital staff deny uploading certain DICOM files, and without proper logging, it cannot be proven.	2	3	L
T4.1	Information Disclosure	A misconfiguration in the cloud storage exposes processed DICOM data to unauthorized parties.	4	5	H
T4.2	Information Disclosure	A lack of proper access controls could allow an attacker to access or manipulate references to internal implementation objects, like files or database keys, through the UI API	2	4	M
T5.1	Denial of Service	The segmentation pipeline is flooded with requests, causing a system crash and data processing halt.	2	4	M
T6.1	Elevation of Privilege	Flaws in the access control logic of the UI API allow users to access data beyond their permission levels.	2	5	H

Efficiently Addressing Identified Threats

After identifying and ranking threats using STRIDE, the journey continues towards developing and implementing specific countermeasures for each identified risk. This stage is crucial as it involves crafting strategies proportional to the risk level of each threat. Immediate and robust actions are necessary for high-risk threats, whereas lower-risk threats may warrant a more measured approach or acceptance based on their impact analysis.

The detailed analysis and prioritization offered by STRIDE empower developers to focus their efforts where they are most needed, ensuring that resources are allocated effectively to enhance the security posture of the SaMD. By methodically addressing the vulnerabilities identified, developers lay the groundwork for a robust defense mechanism that not only secures the device but also complies with regulatory standards.

Developing and Implementing Effective Control Measures

With the STRIDE framework guiding the identification and prioritization of potential threats to our hypothetical SaMD, the focus shifts towards crafting and executing targeted control measures. These measures are meticulously designed to address the specific vulnerabilities uncovered during the threat analysis, ensuring a robust defense mechanism that aligns with the system's unique requirements.

Crafting Tailored Control Measures

Control measures range from sophisticated technical solutions to comprehensive policy and procedural updates, each playing a pivotal role in safeguarding the system. The essence of these measures lies in their ability to not only counteract identified threats but also enhance the overall security architecture of the SaMD. It's imperative that these solutions are integrated thoughtfully to avoid introducing new vulnerabilities or negatively impacting system performance.

For control measures addressing web application security, the OWASP Top 10 provides an essential checklist of vulnerabilities and recommended practices. To illustrate, the following table outlines specific control measures for each identified threat, demonstrating how we plan to mitigate risks to an acceptable level.

List of control measures
Threat ID	Control Measure(s)	Residual Probability (1-5)	Residual Severity (1-5)	Residual Threat Level (1-5)
T1.1	Implement network-level authentication IP filtering Secure VPN channels for data transmission	1	4	L
T1.2	Strengthen authentication processes with multi-factor authentication Session management best practices	1	4	L
T2.1	Employ end-to-end encryption, such as TLS Integrity checks like cryptographic hashing to secure data in transit	1	5	M
T2.2	Validate all inputs Utilize parameterized queries Employ proper error handling to prevent injection attacks	1	5	M
T3.1	Implement comprehensive logging Auditing mechanisms to track and verify all data uploads and transactions	1	3	L
T4.1	Conduct regular configuration and access control audits Ensure that cloud storage permissions are correctly set	1	5	M
T4.2	Implement role-based access control (RBAC) Ensure secure direct object references to prevent unauthorized access	1	4	L
T5.1	Apply rate limiting, request throttling Utilize load balancers to manage traffic and prevent system overload	1	4	L
T6.1	Regularly review and update access control policies Enforce least privilege principles Perform periodic access reviews	1	5	M

Technical Solutions

Incorporating technical solutions such as encryption, sophisticated access controls, and secure configurations forms the backbone of our mitigation strategy. These solutions undergo rigorous planning, exhaustive testing, and meticulous deployment phases to confirm their efficacy in neutralizing threats. The objective is to fortify the SaMD against attacks without compromising on usability or functionality.

Manufacturers should take note that whilst implementing security controls, they do not adversely affect controls associated with 'Safety Risk' management, e.g. per ISO 14971. As an example, protecting a medical device from unauthorized access may compromise the ability of a user to alter the medical device operations quickly in case of a critical situation. Manufacturers should carefully weigh the risk controls and evaluate their effect on the safety of the product overall. It is recommended to include the results from the threat modeling exercise as an integral part of the overall Risk Management File, to fully understand the interactions between the two.

Policy and Procedure Updates

Equally important are the policy(s) and procedural updates that establish a governance framework for ongoing security management. This includes the formulation of regular security assessments, revision of permission protocols, and the instigation of staff training programs. Such procedural measures ensure that the organization's security posture evolves in tandem with the changing threat landscape.

Continuous Monitoring and Iterative Improvement

The implementation of control measures marks the beginning, not the end, of an ongoing security journey. Continuous monitoring through system audits, real-time threat detection systems, and regular penetration testing is vital. This proactive surveillance allows for the early identification of new vulnerabilities, ensuring that the SaMD's defenses remain impervious over time.

By adopting a holistic approach that combines technical implementations with strategic policy updates, organizations can establish a dynamic security framework. This not only addresses the immediate threats identified through STRIDE but also lays down a solid foundation for anticipating and mitigating future security challenges. Through this continuous cycle of improvement, SaMD developers can assure stakeholders of their commitment to maintaining the highest standards of security and compliance.

Conclusion: A Path Forward with SaMD Security

Navigating the complexities of SaMD security is an ongoing challenge that demands vigilance, innovation, and a deep understanding of both technological and regulatory landscapes. By adopting a structured approach to threat modeling, employing rigorous control measures, and committing to continuous evaluation, developers can significantly enhance the security posture of their medical devices.

Take the Next Step with QAIR

If you're looking to strengthen your SaMD's security and compliance but are unsure where to start, QAIR is here to guide you. Our expertise in cybersecurity and regulatory affairs positions us uniquely to support your journey towards creating safer, more reliable medical devices. Contact us to explore how we can collaborate to address your security needs and navigate the complexities of regulatory compliance together.

Let's work together to advance the security and efficacy of healthcare technology, ensuring it serves the best interest of patients and providers alike.