The past decade has seen a surge in devices connected to the internet, offering numerous benefits but raising concerns about security issues like password vulnerabilities and ransomware incidents. Medical device security is crucial for assuring customers and patients their health and personal information are protected. The FDA provides guidance focusing on cybersecurity, covering device design, labeling, documentation and post-market management. We’ll take a look at software development, maintenance and using off-the-shelf software in medical devices, addressing vulnerabilities, prevention, mitigation and post-release actions. These recommendations are applicable not just to the United States but also to other regulatory bodies worldwide seeking approval for medical devices.
Protecting medical devices from known vulnerabilities
To protect your devices from vulnerabilities, it’s crucial to eliminate known vulnerabilities and anticipate unauthorized access attempts. While flaws in open-source modules are beyond your control, you can mitigate potential issues in your own applications. Hackers often exploit common coding errors like NULL pointer de-references and buffer overflows. Employing static and dynamic analysis techniques, using a coding standard like MISRA or SEI CERT C8, and conducting comprehensive product testing can significantly improve security.
When testing for known issues, both in-house and third-party software should undergo static analysis. Running a Linux vulnerability scanner can check package versions against the National Vulnerability Database, providing insights into open issues and available fixes.
Protecting medical devices from unknown vulnerabilities
Protecting devices from unknown vulnerabilities is also challenging, and employing techniques like structured code analysis and hacker duplication can make devices harder to exploit. Two primary methods to do this are:
Penetration testing: This involves simulating cybersecurity attacks on your devices before release. You can identify vulnerabilities and take preventive measures by allowing engineers or “white hat hacker” consultants to exploit your devices.
Fuzz testing: Hackers often probe devices with a variety of valid and invalid Ethernet packets to observe device behavior. While some packets may duplicate known exploits, many are random or semi-malformed, designed to assess device reactions. Though not as comprehensive as penetration testing, fuzz testing is easier to implement as part of standard product testing. Various market products can be integrated into an automated testing framework to perform fuzz testing. By applying preventative development techniques, following coding standards, conducting product testing, and employing vulnerability scanners, you can strengthen the security of your devices.
Partnering with an operating system provider and what to ask
Using an operating system (OS) provider like Siemens Embedded can significantly benefit your product development. Here are some key items to discuss:
Developing, testing and release: Inquire about how the OS provider tests and releases their products, including board support packages, drivers, and related software. Their expertise and dedicated focus on the OS can offer comprehensive testing beyond what your teams can achieve independently.
Support and services: Explore the OS provider’s experience in assisting customers with product development and device security. Ask about the support they offer in securing devices and their track record in working with customers on such matters.
Product updates: Determine the frequency of product updates provided by the OS provider. Inquire about the nature of these updates and the improvements they bring, focusing on addressing newly discovered issues, including Common Vulnerabilities and Exposures (CVEs).
Security focus: Assess the OS provider’s emphasis on security vulnerabilities, including CVEs. Besides regular updates, they should offer assistance in managing the constant stream of CVEs, which is crucial, especially when seeking regulatory approval for devices in fields like healthcare or automotive.
Industry experience: Find out if the OS provider has experience working with other medical device creators. While they cannot share specific design details, their services, and techniques should be informed by past experiences. You can leverage their expertise to support regulatory approval processes for your device.
Ensuring the security of medical devices
Following this guidance results in more secure products that are difficult to exploit, faster to update to address new vulnerabilities and capable of instilling customer confidence even in the face of issues. While not preventing all future security problems, these methods position manufacturers to promptly resolve any arising issues. Download the white paper to learn more.