Ensuring Compliance and Robust Security in the Healthcare Industry

Securing medical device approvals requires a thorough understanding of the regulatory requirements that apply to your device or system of health software. Different markets have varied standards:

• ·  FDA Guidance: The U.S. Food and Drug Administration requires device manufacturers to address cybersecurity risks, including vulnerability management and post-market monitoring.
• ·  EU MDR: The European Union’s Medical Device Regulation (MDR) emphasizes cybersecurity as part of the general safety and performance requirements.
• ·  ISO 13485: This international standard specifies requirements for a quality management system for medical devices, including considerations for cybersecurity.

Conducting a gap analysis to identify compliance gaps early in the development cycle is crucial.

Medical Device Risk Management and Cybersecurity Threats

Managing cybersecurity risks and threats in medical device software is unfortunately a moving target. Moreover, incorporating security by design depends on the safety risk assessment and a security risk assessment may include mitigations that impact the secure design or, at least, requires additional features, such as protecting trust zones, using strong cryptography or upgrading procedures and protocols.

🚦Business Impact: Mastering the risk assessment and security architecture relation early on in a project may save millions in project cost. Proven strategy: By knowing the intended purpose and claims, assessing the risks for the intended environment correctly, adjustments to the overall architecture can be done with a sound design of end-to-end procedures and protocols. Mitigations become part of standard features and are not added later on.  

In general patients have to be safe from harm coming from security issues. The following Venn-diagram highlights this relevant subset.

Source: https://www.canada.ca/en/health-canada/services/drugs-health-products/medical-devices/application-information/guidance-documents/cybersecurity/document.html

As outlined in AAMI TIR 57 and ISO 14971 controls from safety and security considerations influence the respective safety and cybersecurity risk analysis.

Source AAMI TIR57

Threat models for medical device systems

At a project specific level the risk can only be assessed with the complete threat landscape in view. This in turn requires a global system view (see architecture below) that includes the working system beyond the approval scope.

🚦Business impact and strategies: as scope is approved by regulators it pays off to discuss systems being not considered a medical device or medical software. As they store and process non-patient data but provide functions important to cybersecurity (think of single-sign-on functions and interoperability of data and operators), the regulatory requirements are strict that you prove security of interface functions and describe in detail what is sent to and received from such systems.

Picking a standard methodology for threat modeling, such as STRIDE or STRIDE-EL, is a must. Modeling the system and identifying threats can be automated using tools such as the threat modeling tool (TMT) shown here.

Source: Microsoft

Developing a detailed threat model is only possible with a solid security design and security architecture. Otherwise too many possibilities are left open. Generic connectivity, open interfaces, plug-in architectures and more may lead to guesswork in threat modeling. 

🚦Strategies: If an iterative approach to system design and security architecture is already in place, threat modeling should be included. The drawback seems to be a multiple effort of threat modeling but in practice, the iterative design process can help to get there faster and certainly more consistently, because every security design includes threat assumptions and their justifications. Furthermore, mitigations and security controls being developed and asserted can be sent to risk assessment and verification early on (see also design verification and validation section).

Security by design documented: The 4 Architecture Views in Medical Device Security

The FDA specifically requires submissions to include a set of diagrams.

Global System View

The guidance leaves much of the details open but has many requirements on formal submission regarding assets, such as:

• Device hardware itself (including assessments for any commercial platforms) 
• Applications for service, configuration, installation/upgrade, and data transfer 
• Healthcare facility-operated assets in the devices network environment 
• Manufacturer-controlled assets interacting with external entities (e.g., a service that collects and redistributes device data, or a firmware update server).
• Access control models and user roles for every asset (such as privileges, user groups, passwords)
• Details of cryptographic protection for firmware and software updates

Furthermore, communication interfaces and end-to-end communication paths supported by all protocols, need to be documented in great detail:

• Type of communication path (data, code, commands)
• Protocol name(s), version number(s), and ports/channels/frequencies
• Detailed descriptions of the primary functionality (and relationship to involved assets) 
• “handoff” sequences from one communication path to another, e.g. when data is forwarded 
• Description of handling unusual/erroneous/unexpected circumstances in communication
• Authentication mechanism, including the algorithm name/version, key distribution and verification 
• Descriptions of the cryptographic methods used throughout the medical device system 
• If a cryptography algorithm is proprietary, a detailed analysis and expert opinion must be provided 
• A detailed list of how each type of credential (e.g., password, key) is generated, stored, configured, transferred, and maintained, including both manufacturer- and healthcare facility-controlled assets (e.g., key management and public key infrastructure (PKI)) 
• Identity management, including how identities are managed/transferred and configured   
• If communication sessions are used or supported, a description of how sessions are established, maintained, broken down, and how they time out
• Precise links and texts between diagram elements 
• Links to the evidence that may be used to justify security claims   
• Traceability of the assets to the SBOM components, for proprietary and third-party code 

Business impact: in a complex system with many assets and communication paths or layers this 

list of the communication interfaces and paths, including communication paths (e.g., between two assets through an intermediary), and any unused interfaces, can quickly get huge. 

🚦Strategies: The right design choices and reduction of options in communication helps to control the design, documentation and also implementation. Delegating security functions such as authentication to underlying standard mechanisms (e.g. TLS, OAuth2) allows to focus on application layer security, data privacy and data protection. (see also appendix 2.B of premarket guidance). 

For the diagrams, analyzing a system scope in detail may reveal additional views that will be asked for later as additional information. For example, physical or deployment views may need to be added as they are rarely congruent to the global diagram which is a logical view in security architecture.

Security Use Case Views

Security use case views include both your regular application use cases involving patients and HCP as well as security use case views for service personnel, manufacturing, support and incident handling.

Technically, these views build on your asset list of the global system view, references the usage protocols and points out security controls used to support the use case. 

Updatability/Patchability View

A special use case is firmware or software update. It involves ideally the reuse of initial use cases (e.g. device roll-out, provisioning or patient onboarding) and takes into account previously established contexts (known passwords, backups of configurations etc.).

🚦Business impact: Software updates, including all dependencies, can quickly get complex and expensive, not only for the documentation effort. Depending on the lifecycle properties of a medical device, its network environment, and the actors handling or even owning devices and platforms, various approaches, including replacing or refurbishing devices, must be considered. 

Multi-Patient Harm View

It is recommended to work from the global system view and the threat model towards a list or view of security issues that affect multiple devices or multiple patients. A quantification of “multiple” or scope may help in setting priorities. Finally, security issues intersecting with patient harm shall be focused on, avoided, or mitigated.

Stakeholder Collaboration

Medical device approvals often involve multiple stakeholders, including healthcare providers, regulatory bodies, and cybersecurity experts. Building collaborative relationships helps streamline the approval process.
Strategies include:

• Early Engagement with Regulators: Consult regulatory agencies during early development stages to clarify expectations.
• User Feedback: Engage healthcare professionals and patients to understand usability concerns related to security features.
• Third-Party Testing: Utilize independent cybersecurity assessments to validate device security measures.

Documentation and Transparency

Detailed documentation is key to demonstrating compliance and gaining approval. Essential components of documentation include:

• Security Risk Management File: Comprehensive records of identified risks, mitigations, and testing outcomes.
• Software Bill of Materials (SBOM): A complete inventory of software components used in the device, including third-party libraries. 
• Post-Market Surveillance Plans: Outline strategies for monitoring and addressing vulnerabilities after the device is deployed.
• Ongoing Vulnerability Assessments: over time, your SBOMs will show signs of degradation (at least for the third-party components). 🚦Strategy: keeping SBOMS, assessments and vulnerability tracing in the same database can help (e.g. using open source systems such as dependency track).

Conducting Robust Testing

Rigorous testing validates the security measures implemented in the medical device. Proven testing strategies include:

• Penetration Testing: Simulate attacks to identify vulnerabilities and weaknesses. 🚦Strategy: Clearly communicate assessment needs, scope and report format (you need a penetration test plan anyway). As the FDA wants to see the original wording of the penetration test report, never allow the pentester to use technical risk scoring without further application consideration. For example, high CVSS 3.1 for openssl, which are quite common, affect the security of a medical device in different ways. Using the FDA-sponsored scoring methodology with a CIA-assessment (confidentiality, integrity and availability) of the diagnostic device or medical device in its environment and application context yield often a very different result score.   
• Functional Testing: Ensure security features operate as intended without compromising device functionality. In addition, abuse, misuse and fuzz-testing may reveal both function and security issues.
• Interoperability Testing: Verify that the device securely interfaces with other healthcare systems and devices.

Leveraging Standards and Frameworks

Adherence to established standards and frameworks provides credibility and compliance assurance. Recommended frameworks include:

• ·  NIST Cybersecurity Framework (CSF 2.0): Guidelines for identifying, protecting, detecting, responding to, and recovering from cybersecurity events.
  🚦Strategy: use this framework if your environment is not ISO 27001 certified.
• ·  IEC 62304, IEC 81001-5-1, IEC 81001-5-2: Standards for medical device software lifecycle processes, emphasizing security controls and risk management.
• ·  IEC 60601-4-5: Standards for electrical equipment safety, including cybersecurity considerations for individual devices. Avoid it for system applications.

Post-Market Considerations

Security approvals do not end with product launch. Post-market activities are vital for maintaining device security and compliance:

• ·  Monitoring: Continuously track device performance and emerging threats using automated tools.
• ·  Vulnerability Reporting: Establish a clear process for users to report security issues and for manufacturers to address them promptly. 
• 🚦Strategy: Strictly apply ISO 29147, ISO 30111 and keep all interactions with external parties as simple as possible.
• ·  Education and Training: Provide healthcare providers and users with guidance on operating devices securely.

The Cybersecurity Management Plan

A cybersecurity management plan basically defined roles and responsibilities, procedures while developing, during and after launch in security concerning a medical device. Its content could be included as a chapter in a software development plan (SDP), however the FDA pre-market guidance defines the content of a cybersecurity management plan (CSMP) as a document which needs to be submitted through the eSTAR form. Therefore, that content should be kept separate or generated from your requirements management system. Specific and more detailed procedures relating to operations management (IT, solution engineering etc.) can be referenced. In practice such content is living in a content management system (versioned wiki, eQMS or similar).

Key Takeaways

Securing medical device approvals is a complex but achievable process. By integrating security by design, engaging with stakeholders, leveraging standards, and maintaining post-market vigilance, manufacturers can ensure their devices meet stringent regulatory requirements and deliver safe, reliable performance. In an era of connected healthcare, robust cybersecurity measures are not just a regulatory mandate but a critical commitment to patient welfare and trust.