By Jeff Moore
Both the U.S. FDA and the International Medical Device Regulators Forum (IMDRF) encourage medical device manufacturers to address cybersecurity throughout their product lifecycles, including during the design, development, production, distribution, deployment, and maintenance phases.
In March 2022, the stakes became even higher when the U.S. House of Representatives introduced the “Protecting and Transforming Cyber Health Care Act of 2022” aka “PATCH Act of 2022,” which “…amends Federal Food, Drug, and Cosmetic Act to require, for purposes of ensuring cybersecurity, the inclusion in any premarket submission for a cyber device of information to demonstrate a reasonable assurance of safety and effectiveness throughout the lifecycle of the cyber device, and for other purposes.”
For healthcare providers evaluating the risk of an attack on the devices within their facilities, what exactly does a total product life cycle (TPLC) approach to cybersecurity risk mean? What features or factors should a provider organization consider when evaluating the security of manufacturers’ devices, and what questions should they ask?
Here are the six key components of a TPLC approach to the cybersecurity of medical devices to help guide conversations with manufacturers and assess the risk of their devices.
1. Training
Protecting a medical device against cyberattacks starts with the team designing and developing it. A manufacturer should require its product development staff to be trained on secure design, secure coding, and minimizing the risks and threats to firmware. They must be aware of risks existing in our interconnected world and have the training to minimize these risks and build more robust security into the medical device.
Because malicious actors continuously change their methods of attack to become more effective at infiltrating devices, the manufacturer’s development team must stay up to date regarding current topics and developments in the security world. That way, the company will not be surprised by sudden incidents threatening the security of its customers.
Those responsible for evaluating medical devices for a healthcare organization should ask manufacturers what training and continuing education they provide to their product development teams on cybersecurity, how they keep a pulse on emerging threats, and how these risks are translated into device security features.
2. Medical Device Security by Design
Secure products cannot be developed by bolting on security requirements to the medical devices and firmware post-production. That type of development may produce additional risks and vulnerabilities. Instead, the integration of security requirements to limit risks must be fully integrated into the product design process from the very beginning—not as an afterthought.
In its guidance to manufacturers, the FDA describes the specific design features and cybersecurity design controls that it believes should be included in the design of a “trustworthy” device. It also specifies documentation that manufacturers must include when submitting a device for the agency’s approval based on that device’s level of cybersecurity risk.
With this in mind, look for a manufacturer that designs security into product requirements from the very beginning in accordance with FDA guidelines. A well-designed security architecture is the foundation for the resilience and the secure operation of products. While the complete absence of vulnerabilities is unrealistic, manufacturers should put a tremendous amount of effort into the process of securing devices to make them resilient in a connected environment.
3. Develop
Programming errors are common in software development—with an average of 15 to 50 programming errors per 1,000 lines of source code.[1] While most of these errors have no impact on the security of the product or system, some vulnerabilities are among them. “This range of vulnerabilities from buffer overflows to cross site scripting, from denial-of-service errors to flawed access controls, are still present in many products and systems,” according to software engineering expert Steve McConnell in Code Complete: A Practical Handbook of Software Construction, Second Edition.
Among the medical device manufacturers surveyed by Ponemon Institute for its Medical Device Security Report, half (51%) said they follow specified security requirements during the development phase of a product, but fewer perform thorough practices, such as security testing throughout the software development life cycle (38%), code review and debugging systems (37%), and dynamic application security testing (31%).
The authors of the report state: “As a result, both manufacturers and users concur that medical devices contain vulnerable code, due to a lack of quality assurance and testing procedures and the rush to release pressures on the product development team.”
Therefore, ensure your medical device manufacturer has taken steps to minimize these types of vulnerabilities. Remember: No line of code should be shipped unreviewed. The company should follow the four plus one (stylized as 4+1) principle to bring the number of security vulnerabilities down to a minimal level.
Four is the minimal number of approvers that have seen and reviewed shipped code in peer-to-peer or group code reviews, and plus-one is the static code analysis software, which the device manufacturer uses to check code for automatically detectable defects.
4. Verify/Test
During the code verification phase, the manufacturer should ensure that the product or system, whether newly developed or enhanced, functions as intended—both actual functionality and security capabilities—by running a series of systematic tests (e.g., Fuzz-Testing of Inputs and Interfaces, automated vulnerability scanners, and static code analysis software).
At the final stage of test and verification, the manufacturer should then assign independent external security experts to carry out penetration testing on its medical devices and systems. During these tests, a professional ethical hacker tries to infiltrate the medical device or system without being pre-influenced by the background knowledge the developers have, paired with their high expertise in hardware and software security technology. If vulnerabilities are found, the manufacturer can fix them before bringing the medical device or system to market.
Werner Griesshammer, a certified ethical hacker on the Dräger Cybersecurity team, has experience with the process, commenting: “We decided attacks on our devices could be evaluated by using the same tools and techniques that hackers use.” For this reason, he says, he underwent intensive training and certification to become an ethical hacker. “Ethical hacking is our way to ensure our customers get all of the information to build a safe hospital.”
Griesshammer discloses one approach (among many) he uses for verification and testing: “Metasploit is a tool with a database of all known attacks to popular operating systems Microsoft Windows, Apple OS 10, or Linux. The application will identify possible targets on the network and allow us to run attacks against vulnerabilities on the system. If fixes for the vulnerabilities exist, the system must be updated; otherwise, we will document the issue.”
5. Release
During the release phase, the manufacturer finalizes product and system documentation, and creates a software bill of materials, or SBOM. The SBOM links the software components versions to the company’s specific release and enables it to perform effective vulnerability monitoring. The final software build is frozen and bundled with its documentation, signed to prevent unauthorized changes, and released for distribution.
The PATCH Act requires a device manufacturer to provide a SBOM, including commercial, open-sourced, and off-the-shelf software components that will be provided to users, to both the FDA and users of the device. Forward-thinking medical device manufacturers that have prioritized cybersecurity already do this. Be sure to ask your manufacturer if they currently offer this critically important documentation to help you detect and address vulnerabilities.
6. Medical Device Maintenance and Vulnerability Monitoring
Cybersecurity is an ongoing investment, not a one-time project. Therefore, the manufacturer should have capabilities in place to continuously monitor public information for vulnerabilities. Moreover, the PATCH Act specifies several requirements for manufacturers to monitor medical devices for vulnerabilities and mitigate them. These include:
- Have a plan to appropriately monitor, identify, and address in a reasonable time post-market cybersecurity vulnerabilities and exploits.
- Design, develop, and maintain processes and procedures to make available updates and patches to the cyber device and related systems throughout the lifecycle of the cyber device to address:
- On a reasonably justified regular cycle, known unacceptable vulnerabilities; and
- As soon as possible out of cycle, critical vulnerabilities that could cause uncontrolled risk.
With regards to monitoring vulnerabilities and exploits, a device manufacturer’s security team should review information sources for published security vulnerabilities in third party components and map these vulnerabilities to the possibly affected products. Sources include the National Vulnerability Database; MITRE’s Common Vulnerabilities and Exposures list; VulnDB; and several vendor-specific RSS feeds, mailing lists, and websites.
The manufacturer should also have a way to communicate to its customers procedures for testing device vulnerabilities, reporting vulnerabilities or security issues, and provide information concerning the procedures that follow any incident and public product-related security advisories.
Better Medical Devices
With cyberattacks on medical devices growing, manufacturers should place security front and center throughout their entire product development lifecycles. From requirements to design, from development to testing, a secure development lifecycle strives to build security into medical devices and firmware at every step in the process.
Jeff Moore is chief officer cybersecurity at Dräger Medical Systems, Inc. For in-depth information on how Dräger implements security into the development of its medical devices, read the white paper, Dräger Cybersecurity: Security for medical devices—a shared responsibility.
References:
- Postmarket Management of Cybersecurity in Medical Devices, FDA, December 28, 2016, https://www.fda.gov/media/95862/download
- Principles and Practices for Medical Device Cybersecurity, IMDRF, October 1, 2019, https://www.imdrf.org/sites/default/files/2021-09/imdrf-cons-ppmdc.pdf
- Protecting and Transforming Cyber Health Care Act of 2022, Congress.gov, March 15, 2022, https://www.congress.gov/bill/117th-congress/house-bill/7084/text?r=92&s=1
- Content of Premarket Submissions for Management of Cybersecurity in Medical Devices, FDA, October 18, 2018, https://www.fda.gov/media/119933/download
- McConnell, Steve, Code Complete: A Practical Handbook of Software Construction, Second Edition, July 2004.
- Medical Device Security: An Industry Under Attack and Unprepared to Defend, Ponemon Institute, May 2017.
- Protecting and Transforming Cyber Health Care Act of 2022, Congress.gov, March 15, 2022, https://www.congress.gov/bill/117th-congress/house-bill/7084/text?r=92&s=1
