Full Spectrum is often engaged to assess software cybersecurity for our clients.  So, when the FDA issued its new draft guidance to the MedDevice industry (Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions | FDA – April 8. 2022) we expected the FDA to reinforce its stated policy to be ‘vigilant and responsive’ to the cyber-security issues related to medical devices. 

 

However, after review, the draft guidance represents a significant ramping of the expectations of FDA for the OEM to take a more formal approach to cyber-design and to adopt variations of these new formalities throughout the post-market phases of all products containing software – especially those that support communication within the device and between the device and any hospital networks.

 

This article will focus on four takeaways from the draft guidance that we think are of particular importance: Software Architecture Implications of Cyber Security, Threat Modeling (ongoing), Treatment of Off-The-Shelf (OTS) Software, and Transparency Requirements. 

 

Software Architecture Implications of Cybersecurity

 

It has long been recognized that proper cyber design commences with the development of the product software architecture. This cyber-design concept, referred to as the Secure Product Development Framework (SPDF), requires that the OEM develop a software architecture that demonstrably meets both the existing safety and efficacy requirements, as well as newer cyber safety requirements. 

 

It is important to note that the cybersecurity risk of a medical device is separate from the current safety risk assessment, which is based primarily on patient safety. For example, it is expected that existing connected devices of minor concern to patient safety could end up with a cybersecurity risk of high concern. Therefore, a thorough and well-documented assessment of cyber risks along with software architectural and design mitigations will be required.

 

The security objectives of authenticity, authorization, availability, confidentiality, and secure timely updatability will require a structured analysis that evaluates the software architecture from multiple ‘architectural views’.  To meet the objectives will mean adding global system view, multi-patient harm view, updatability view, and various security use case views to the patient and operator safety views currently recommended in the software architecture review processes.

 

Threat Modeling

 

To fully comply with the new guidance, the OEM is responsible for the development of a comprehensive threat model, which will identify system risks, both pre- and post-mitigation, fully illuminate all deployment environment assumptions, and fully explore cybersecurity risks introduced through the supply chain, manufacturing, product updating, and interoperation with other devices. These threat models must be used in the software architecture and design review process to ensure that sufficient software protections have been introduced.

 

Treatment of Off-The-Shelf (OTS) Software

 

The new guidance pays special attention to the now common practice of either including ‘off-the-shelf’ (OTS) software or deploying the medical device software on shared platforms. Both these practices had enormous benefits to the OEM – improving the speed of product development and dramatically changing the deployment options. However, OTS software also dramatically increases the cyber vulnerabilities of medical devices. Sophisticated attacks on Windows, Linux and IOS have been around for years. Recent news about the global impact of exploited vulnerabilities in SolarWinds’ network management software underscores the risks of OTS software within the medical industry.

 

Any OEM that includes OTS software is responsible for putting into place processes and controls to ensure that the OTS software manufacturer fully abides with the OEM’s cybersecurity policies – all of which will now be required as part of the design history file (DHF).  Related to this, as part of configuration management, FDA is recommending that OEMs have custodial control of source code through a source code escrow process. While this will not always be practical (it seems unlikely   that Microsoft might submit all 50 million lines of Windows to each OEM’s escrow), it is recommended that OEMs consider adding these controls to their internal processes.

 

Transparency Requirements

 

All aspects of the new draft guidance are coupled with a stated transparency policy that the OEM provide any information necessary to integrate their devices into the end-user environment, as well as any information required to maintain the “device’s cybersecurity over the device lifecycle or that has the potential to affect the safety and effectiveness of the device.” This, clearly, will have a significant impact on the amount and type of information that is provided about the control software of any medical device.

 

Conclusion

 

These changes in FDA guidance are currently only in a draft form and are non-binding. While it is anticipated that there will be changes to the specifics, it is also clear that FDA will take a more engaged role in overseeing the cybersecurity related elements of medical device software.

 

It would be well advised for any OEM to take more aggressive steps to ensure that they are ready for the impact this may have on medical device development. A strong set of formal software architectural design and review processes will soon be required across a new set of device types.  The requirements will not stop with the product release, as the OEM will be responsible for ongoing requirements to ensure persistent cyber risk mitigations over the product’s life.  

 

Though the implications of this new guidance are not surprising, they are significant in their impact on the processes and responsibilities of the OEM.  We have daily interactions with OEM clients of all sizes, and many are struggling to understand exactly how to apply these changes to their product development processes.  If you have similar concerns and challenges, Full Spectrum can help.  Reach out to us for a free consultative meeting.