Alan Grau, VP of IoT/Embedded Solutions, Sectigo02.18.20
Every day, medical device manufacturers throughout the world race to develop new, highly sophisticated and increasingly connected products. These products offer a wide range of benefits: improved treatments, more precise diagnostics, better patient monitoring, automated control and central reporting, and monitoring of data. However, with increased functionality and connectivity, comes increased risk – dangers notable enough that the FDA in the U.S. has issued cybersecurity guidelines to help OEMs ensure medical devices are safe from cyberattacks.
Even though medical device manufacturers are heavily investing in the development of new medical device technologies, they often lack the security expertise and the technical resources to ensure that high levels of security are built into these solutions. Many of these devices employ new protocols, platforms and middleware solutions that have not been thoroughly vetted for security issues. The result, not surprisingly, is the continued manufacturing of devices that are easily compromised by hackers. In turn, we continue to see headlines of new security vulnerabilities being discovered in critical medical devices.
In addition, ransomware attacks have targeted hospitals and medical providers with alarming success. In these attacks, hackers compromise a system, encrypt critical data so the systems cannot operate, and then demand a ransom to restore the system to working order. In the past, ransomware attacks have targeted IT and database systems. Future attacks may focus on the medical devices themselves. If a hacker can control systems that impact patient outcomes, they will have tremendous additional leverage for their ransom demands.
FDA Cybersecurity Guidelines
A few of the capabilities recommended in the FDA guidelines include:
What do these guidelines mean for an engineer working on a medical device?
Many medical devices are specialized products—the security solutions used for standard PCs often won’t work for specialized devices. Clearly, meeting the security guidelines is important. Doing so requires an approach that is customized to the needs of the device.
Use of multiple layers of protection, including firewalls, authentication, security protocols, and intrusion detection/intrusion prevention, is a long-established driving principle for enterprise security. In contrast, most medical devices, especially in-home and mobile devices, lack basic firewalls or security protocols, and often rely on little more than simple password authentication. For decades, device manufacturers assumed these devices were not attractive targets to hackers or were not vulnerable to attacks. That is no longer true. Attacks against all types of embedded devices, including medical products, are on the rise and greater security measures are now needed.
For more than 25 years, cybersecurity has been a critical focus for large enterprises. Now medical device design engineers need to take a page from the enterprise security playbook.
Vulnerabilities in Embedded Devices
Before diving into the problem of how to secure connected medical devices, it is important to consider the origin of security vulnerabilities. Broadly speaking, most vulnerabilities in embedded devices can be divided into one of three categories: implementation vulnerabilities, deployment or use vulnerabilities, and design vulnerabilities.
Implementation vulnerabilities occur when coding errors result in a weakness that can be exploited during a cyberattack. The infamous, and seemingly immortal, buffer overflow attacks are the classic example of implementation vulnerabilities. Other examples include improperly seeding random number generators, which can result in the generation of security keys that are easy to guess. Adherence to software development processes such as the OWASP Secure Software Development Lifecycle or Microsoft’s Security Development Lifecycle and thorough testing processes help to address implementation vulnerabilities.
Deployment or use vulnerabilities relate to issues that are introduced by the user during the operation or installation of the device. These include issues such as not changing default passwords, using weak passwords, not enabling security features, etc.
In contrast, design vulnerabilities are weaknesses that result from a failure to include proper security measures when developing the device. Examples of design vulnerabilities that have resulted in security breaches include use of hard-coded passwords, control interfaces with no user authentication, and use of communication protocols that send passwords and other sensitive information in the clear. Other less glaring examples include devices without secure boot or that allow unauthenticated remote firmware updates.
Embedded Security Challenges
Medical devices comprise a wildly diverse range of device types—from small to large, and from simple to complex. These are embedded devices, which differ greatly from standard PCs or other consumer devices. They are fixed-function devices specifically designed to perform a specialized task. Many of them use a specialized operating system such as VxWorks, FreeRTOS or INTEGRITY, or a stripped-down version of Linux. Installing new software on the system in the field either requires a specialized upgrade process or is simply not supported. In most cases, these devices are optimized to minimize processing cycles and memory usage and do not have the extra processing resources required to support traditional security mechanisms.
As a result, standard PC security solutions won’t solve the challenges of embedded devices. In fact, given the specialized nature of embedded systems, Windows-based PC security solutions won’t even run on most embedded devices.
Challenges for medical device security include:
1. Critical functionality: Medical devices control life-enabling systems and manage sensitive data.
2. Replication: Once designed and built, medical devices are mass produced resulting in thousands to millions of identical devices. Once discovered by a bad actor, a successful attack against one of these devices can be replicated across all the devices.
3. Security assumptions: Many medical device engineers have long assumed that their products are not targets for hackers and have not considered security a critical priority.
4. Not easily patched: Most medical devices are not easily upgraded. Once they are deployed, they will only run the software that was originally installed at the factory, including any vulnerabilities.
5. Long lifecycle: The lifecycle for medical devices may be as long as 10, 15, or even 20, years. Building a device that will stand up to the ever-evolving and increasing security requirements of the next two decades is a tremendous challenge.
6. Beyond the perimeter: Medical devices may be deployed outside of the enterprise security perimeter, may be mobile, or may be deployed in homes—environments lacking the protections found in a corporate environment.
7. Obscure to users: There is no way for the end user to easily monitor, change, or update an embedded device’s security health.
Cyberattacks and The Motivated Hacker
The level of security required for a medical device varies depending upon the function of the device. Rather than asking if the device is secure, OEMs should be asking if the device is secure enough. For example, a robotic surgery system clearly needs a very different level of security than connected sensors for remote monitoring of patients.
Hacking is not just the domain of bored teenagers, hacking drones, or even the small groups of motivated hackers. When the stakes are high enough, cyberattacks are multi-phased, multi-year efforts carried out by large, well-funded teams of hackers.
We are no longer talking about protecting a device from just malformed IP packets or DoS packet floods. Hackers know how to research their targets—they often have detailed operating information on the device they are targeting and have sophisticated toolkits and skills that can be used to develop attacks. But how often have OEMs considered how to protect the device from attack from a group with detailed knowledge of the inner workings of their product?
Security Requirements for Medical Devices
A security solution for medical devices must protect firmware from tampering, secure the data stored by the device, secure communication, and protect the device from cyberattacks. This can only be achieved by building in security from the earliest stages of design.
Unfortunately, there is no single one-size-fits-all security solution for medical devices. Engineers must take into consideration the cost of a security failure (economic, environmental, social, etc.), the risk of attack, available attack vectors, and the cost of implementing a security solution.
Features that need to be considered are:
Integrating Security into The Device
Building protection into the device itself provides a critical security layer that ensures devices are no longer depending on the corporate firewall as their sole layer of security and allows security to be customized to the needs of the device.
The engineering team must be as focused on security as they are on the new capabilities of the device. Building these capabilities into a medical device will enable the device to meet the FDA security guidelines.
Supply Chain Considerations
Further adding to the complexity of developing secure medical devices are the challenges with a diverse supply chain. Medical devices include software and firmware from the chip vendors, RTOS vendors, middleware providers, and software vendors. Each of these components can potentially contain software flaws that could lead to security vulnerabilities.
In addition to ensuring proper security measures are built into the device, OEMs must impose secure development processes and monitoring of suppliers to prevent the introduction of vulnerabilities in firmware components.
Summary
Today’s modern medical devices are complex connected computing devices that perform critical functions. Including the latest security protocols and technologies in these devices is an essential design task. Security features must be considered at the very beginning of the design process to ensure the device is protected from the numerous advanced cyber threats they will face.
Alan Grau has 30 years of experience in telecommunications and the embedded software marketplace. Grau joined Sectigo, a leading Certificate Authority and provider of purpose-built PKI management solutions, in May 2019 as part of the company’s acquisition of Icon Labs, where he was CTO and co-founder, as well as the architect of Icon Labs' award-winning Floodgate Firewall. He is a frequent industry speaker and blogger and holds multiple patents related to telecommunication and security. More info about cybersecurity and protecting the cloud can be found at https://www.sectigo.com.
Even though medical device manufacturers are heavily investing in the development of new medical device technologies, they often lack the security expertise and the technical resources to ensure that high levels of security are built into these solutions. Many of these devices employ new protocols, platforms and middleware solutions that have not been thoroughly vetted for security issues. The result, not surprisingly, is the continued manufacturing of devices that are easily compromised by hackers. In turn, we continue to see headlines of new security vulnerabilities being discovered in critical medical devices.
In addition, ransomware attacks have targeted hospitals and medical providers with alarming success. In these attacks, hackers compromise a system, encrypt critical data so the systems cannot operate, and then demand a ransom to restore the system to working order. In the past, ransomware attacks have targeted IT and database systems. Future attacks may focus on the medical devices themselves. If a hacker can control systems that impact patient outcomes, they will have tremendous additional leverage for their ransom demands.
FDA Cybersecurity Guidelines
A few of the capabilities recommended in the FDA guidelines include:
- Restricting unauthorized access to medical devices.
- Making certain that firewalls are up-to-date.
- Monitoring network activity for unauthorized use.
- Disabling all unnecessary ports and services.
What do these guidelines mean for an engineer working on a medical device?
Many medical devices are specialized products—the security solutions used for standard PCs often won’t work for specialized devices. Clearly, meeting the security guidelines is important. Doing so requires an approach that is customized to the needs of the device.
Use of multiple layers of protection, including firewalls, authentication, security protocols, and intrusion detection/intrusion prevention, is a long-established driving principle for enterprise security. In contrast, most medical devices, especially in-home and mobile devices, lack basic firewalls or security protocols, and often rely on little more than simple password authentication. For decades, device manufacturers assumed these devices were not attractive targets to hackers or were not vulnerable to attacks. That is no longer true. Attacks against all types of embedded devices, including medical products, are on the rise and greater security measures are now needed.
For more than 25 years, cybersecurity has been a critical focus for large enterprises. Now medical device design engineers need to take a page from the enterprise security playbook.
Vulnerabilities in Embedded Devices
Before diving into the problem of how to secure connected medical devices, it is important to consider the origin of security vulnerabilities. Broadly speaking, most vulnerabilities in embedded devices can be divided into one of three categories: implementation vulnerabilities, deployment or use vulnerabilities, and design vulnerabilities.
Implementation vulnerabilities occur when coding errors result in a weakness that can be exploited during a cyberattack. The infamous, and seemingly immortal, buffer overflow attacks are the classic example of implementation vulnerabilities. Other examples include improperly seeding random number generators, which can result in the generation of security keys that are easy to guess. Adherence to software development processes such as the OWASP Secure Software Development Lifecycle or Microsoft’s Security Development Lifecycle and thorough testing processes help to address implementation vulnerabilities.
Deployment or use vulnerabilities relate to issues that are introduced by the user during the operation or installation of the device. These include issues such as not changing default passwords, using weak passwords, not enabling security features, etc.
In contrast, design vulnerabilities are weaknesses that result from a failure to include proper security measures when developing the device. Examples of design vulnerabilities that have resulted in security breaches include use of hard-coded passwords, control interfaces with no user authentication, and use of communication protocols that send passwords and other sensitive information in the clear. Other less glaring examples include devices without secure boot or that allow unauthenticated remote firmware updates.
Embedded Security Challenges
Medical devices comprise a wildly diverse range of device types—from small to large, and from simple to complex. These are embedded devices, which differ greatly from standard PCs or other consumer devices. They are fixed-function devices specifically designed to perform a specialized task. Many of them use a specialized operating system such as VxWorks, FreeRTOS or INTEGRITY, or a stripped-down version of Linux. Installing new software on the system in the field either requires a specialized upgrade process or is simply not supported. In most cases, these devices are optimized to minimize processing cycles and memory usage and do not have the extra processing resources required to support traditional security mechanisms.
As a result, standard PC security solutions won’t solve the challenges of embedded devices. In fact, given the specialized nature of embedded systems, Windows-based PC security solutions won’t even run on most embedded devices.
Challenges for medical device security include:
1. Critical functionality: Medical devices control life-enabling systems and manage sensitive data.
2. Replication: Once designed and built, medical devices are mass produced resulting in thousands to millions of identical devices. Once discovered by a bad actor, a successful attack against one of these devices can be replicated across all the devices.
3. Security assumptions: Many medical device engineers have long assumed that their products are not targets for hackers and have not considered security a critical priority.
4. Not easily patched: Most medical devices are not easily upgraded. Once they are deployed, they will only run the software that was originally installed at the factory, including any vulnerabilities.
5. Long lifecycle: The lifecycle for medical devices may be as long as 10, 15, or even 20, years. Building a device that will stand up to the ever-evolving and increasing security requirements of the next two decades is a tremendous challenge.
6. Beyond the perimeter: Medical devices may be deployed outside of the enterprise security perimeter, may be mobile, or may be deployed in homes—environments lacking the protections found in a corporate environment.
7. Obscure to users: There is no way for the end user to easily monitor, change, or update an embedded device’s security health.
Cyberattacks and The Motivated Hacker
The level of security required for a medical device varies depending upon the function of the device. Rather than asking if the device is secure, OEMs should be asking if the device is secure enough. For example, a robotic surgery system clearly needs a very different level of security than connected sensors for remote monitoring of patients.
Hacking is not just the domain of bored teenagers, hacking drones, or even the small groups of motivated hackers. When the stakes are high enough, cyberattacks are multi-phased, multi-year efforts carried out by large, well-funded teams of hackers.
We are no longer talking about protecting a device from just malformed IP packets or DoS packet floods. Hackers know how to research their targets—they often have detailed operating information on the device they are targeting and have sophisticated toolkits and skills that can be used to develop attacks. But how often have OEMs considered how to protect the device from attack from a group with detailed knowledge of the inner workings of their product?
Security Requirements for Medical Devices
A security solution for medical devices must protect firmware from tampering, secure the data stored by the device, secure communication, and protect the device from cyberattacks. This can only be achieved by building in security from the earliest stages of design.
Unfortunately, there is no single one-size-fits-all security solution for medical devices. Engineers must take into consideration the cost of a security failure (economic, environmental, social, etc.), the risk of attack, available attack vectors, and the cost of implementing a security solution.
Features that need to be considered are:
Integrating Security into The Device
Building protection into the device itself provides a critical security layer that ensures devices are no longer depending on the corporate firewall as their sole layer of security and allows security to be customized to the needs of the device.
The engineering team must be as focused on security as they are on the new capabilities of the device. Building these capabilities into a medical device will enable the device to meet the FDA security guidelines.
Supply Chain Considerations
Further adding to the complexity of developing secure medical devices are the challenges with a diverse supply chain. Medical devices include software and firmware from the chip vendors, RTOS vendors, middleware providers, and software vendors. Each of these components can potentially contain software flaws that could lead to security vulnerabilities.
In addition to ensuring proper security measures are built into the device, OEMs must impose secure development processes and monitoring of suppliers to prevent the introduction of vulnerabilities in firmware components.
Summary
Today’s modern medical devices are complex connected computing devices that perform critical functions. Including the latest security protocols and technologies in these devices is an essential design task. Security features must be considered at the very beginning of the design process to ensure the device is protected from the numerous advanced cyber threats they will face.
Alan Grau has 30 years of experience in telecommunications and the embedded software marketplace. Grau joined Sectigo, a leading Certificate Authority and provider of purpose-built PKI management solutions, in May 2019 as part of the company’s acquisition of Icon Labs, where he was CTO and co-founder, as well as the architect of Icon Labs' award-winning Floodgate Firewall. He is a frequent industry speaker and blogger and holds multiple patents related to telecommunication and security. More info about cybersecurity and protecting the cloud can be found at https://www.sectigo.com.
