Justin Carroll, Software Engineering Director, Full Spectrum06.27.23
When it comes to cybersecurity and liability in medical device development, manufacturers need to treat 99% mitigation as a 100% chance of an incident. It takes only one cybersecurity incident to undo years of work building a reputation, or worse, cause harm to a patient.
There are nearly as many cybersecurity concerns around infiltration (bad actors gaining access to a system) as there are with exfiltration (bad actors exporting data from a system). It’s unfortunate that this is the world we live in, and even sadder to realize that it’s likely always been that way: thieves and spies are not a modern invention.
Building medical equipment and Software as a Medical Device (SaMD) is no exception. The FDA reminds us all frequently of our collective responsibilities to guard against attacks that compromise medical device safety and risk patient harm. The most impactful measures a manufacturer can take to guard hardware devices and software from malicious actors are to assess their attack surfaces, be proactive in monitoring and guarding, and be responsible in evolving cybersecurity mitigations. This applies not only to in-house engineering and product development teams, but to every hardware and software development partner and consultant that contributes to a product.
There are several techniques for minimizing attack surfaces and reducing the blast radius of an incident should one occur. These techniques include implementing a cybersecurity architecture in the device that guard against unauthorized access, establishing quality checkpoints throughout the product development lifecycle, and evaluating development partners for Software Development Lifecycle (SDLC) practices and their own outsourcing policies.
Regardless of what form outsourcing takes, it’s important to evaluate the entire attack surface of the medical device as well as the entire product development team and supply chain.
When selecting a development partner, thoroughly evaluate their ISO 9001 implementation, QMS processes, and any other relevant documentation and standards (e.g., IEC 62304/82304/60601-1, ISO 13485 and 14971:2019, etc.). Simply asking the right questions is the first step in the necessary process to fully audit and evaluate development partners. In addition to probing a prospective partner’s knowledge about cybersecurity, ask to see their documented SOPs to determine if their knowledge is being applied to their own policies and standards. And don’t be afraid to ask for references that can attest to their engineering history.
To help with future evaluations, here is a summarized checklist:
Thankfully, development teams are not on the hook for code reviewing every public repository used or evaluating every fuse and transistor in an IC or silicon wafer. But that doesn’t absolve the ethical and legal responsibilities to ensure patients are kept safe and data is secure. Assess the standards, guards, and training of potential development partners by asking the right questions and checking references.
Implementing a Zero Trust Architecture
A Zero Trust Architecture (ZTA) is based on the concept that it doesn’t matter who, what, where, when, or why a user or computer is in a networked system; they are assumed to be an unauthenticated and unauthorized actor in the system until proven otherwise (guilty until proven innocent). Understanding and applying ZTA can guide architects, engineers, and service teams to implement and coordinate the entire solution to confirm users, services, and requests are authenticated (AuthN) and authorized (AuthZ).
A common, older architecture is the concept of a “walled garden”. In a walled garden architecture, there is a single AuthN entry point that, once cleared, provides access to the authorized resources “behind the garden wall” without re-attesting AuthN beyond the initial AuthN entry point. An example of a walled garden architecture is likely sitting on your smartphone right now. Once you are authenticated into your phone (using passcode or biometric), you have access to your contacts, photos, and web browser.
In a ZTA, access to resources is not presumed by previous authentication. Instead of having a single AuthN checkpoint, resources in a ZTA system are guarded on each request. Using the smartphone example again, while providing your biometrics or passcode to unlock your smartphone, it likely isn’t enough to get you into your banking app. If your bank is practicing ZTA they will ask for your authentication every time you open the app; they make no presumption that the person who unlocked the phone is authenticated or authorized to access your account. In this model, every request and requester must provide evidence to the service that they are both AuthN’ed and AuthZ’ed for the resources. Failure to provide that evidence means a failure to retrieve that resource.
Put differently, the ZTA is distinct from the traditional architecture of a “walled garden” where there is only a single AuthN guard to the entire system. Instead, a ZTA enforces the behavior of attesting an actor’s AuthN and AuthZ on a regular basis. Furthermore, each service provider within the device’s ecosystem is responsible for providing this check, making no assumptions for AuthN and AuthZ, in effect participating in the enforcement of the overall cybersecurity of the medical device. This shared responsibility and permeating model creates an intricate and hardened barrier that helps to prevent unwanted access and exfiltration of data (accidental or intended).
Building a Network of Trust
A Network of Trust is a web of relationships established within a system. This can be applied to opensource software (e.g., jQuery, BlueZ, Django, AOSP, etc.) and all the dependencies it trusts and relies on to build itself, as well as to the relationships built with the development partner (after all, they depend on upstream resources and vendors themselves).
A Network of Trust provides a framework of establishing trust through transitive relationships. Meaning, in a model where actors A, B, and C talk with each other, if A trusts B, and B trusts C, then A can trust C (relying on a trust model where trust may be inherited through transitive relationships; see Figure 1 below).
Implementing a true Network of Trust may create some serious gaps in the overall cybersecurity of a medical device if implemented incorrectly but accepting that transitive relationships will organically evolve in almost all architectures allows for it to be evaluated and controlled. Ask development partners about the thoroughness of their tool evaluations and cybersecurity audits they’ve performed (i.e., are they internal or external audits; how frequent; when was the last audit performed), and how they enforce AuthN and AuthZ within their own network. Simply asking probative questions to development partners, early and frequently throughout the engagement, will be the starting point in helping to select, secure, and sustain a development partnership. This is also the beginning of a comprehensive audit that helps to map the trust boundaries that have been built by the development partner’s own Network of Trust and what risk they might be introducing into the medical device. If a partner is not in compliance with a device manufacturer’s standards, and their trust relationships are lacking proper guards, that partner could lead to additional attack surfaces in a medical device.
Securing the Supply Chain
A supply chain is the intricate web of interconnected providers needed to deliver the core components to build the medical device. This can be hardware, software, or services.
In hardware, this could be a chip manufacturer. In software, this could be a public code repository. And in services, this could be a logging service for an IoMT device. In all these examples, two main concepts are critical to understand:
To help guard against cybersecurity threats to a supply chain, consider adopting tools that help to freeze the software artifacts that includes a cryptographic signature to attest the immutability of the medical device’s origin (tamper evidence).
Also consider tooling that helps evaluate the software dependency trees for the correct licenses, versions, and known CVE’s; this is especially relevant in front-end development projects where opensource components are commonly pulled into the medical device. With opensource libraries and packages it’s very common to see developers use one popular package that can pull other lesser-known support packages (e.g., React, D3, Twisted, etc.).
Establishing a Chain of Trust
In a Chain of Trust architecture AuthN and AuthZ can be established by a chain of authority. This is considered a hierarchical transitive trust-building model. In this hierarchical model, there is a chain of trust that is built from the top down. A central authority authorizes delegates below it, in effect creating a chain of command or authority. The top of this dependency graph need not be responsible for authorizing or authenticating all agents below it, but only its immediate child agent. It’s up to the next immediate child to AuthN and AuthZ its children, and so on until all participants in the graph are attested (see Figure 2 below).
In practice one example of this is HTTPS (HTTP Secure), the pervasive and preferred way to connect to everyday internet sites. HTTPS includes a Certificate Authority (CA) at the top of the Chain of Trust and is the backbone of TLS/SSL communication.
It’s for this very reason that it requires the entire product team, including those members coming from development partners, understand cybersecurity risk mitigations and ways of establishing and maintaining trust relationships with every supplier in the chain. Failing to do so creates blind-spots throughout the product development cycle, allowing hackers to infiltrate and exfiltrate.
Don’t be a victim of an avoidable cybersecurity attack because a development partner created an open invitation to hackers to compromise a medical device or service. Be thoughtful in the selection of a qualified and well-trained development partner and challenge them to rise to the occasion to be a shining example in enforcing cybersecurity standards. Patients will appreciate it.
Justin Carroll is a Software Engineering Director at Full Spectrum. When not designing Class-1 through Class-3 medical devices, or large distributed systems connecting cloud with IoT, Justin spends his time with his family camping in and around the Rocky Mountains. In addition to a long career in software engineering, Justin has his roots in data science. The combination of medical, cloud, embedded, and data science allows Justin to help clients around the world to develop secure and data-driven products that meet FDA, FIPS, and other regulatory needs. You can contact Justin at jcarroll@fullspectrumsoftware.com.
There are nearly as many cybersecurity concerns around infiltration (bad actors gaining access to a system) as there are with exfiltration (bad actors exporting data from a system). It’s unfortunate that this is the world we live in, and even sadder to realize that it’s likely always been that way: thieves and spies are not a modern invention.
Building medical equipment and Software as a Medical Device (SaMD) is no exception. The FDA reminds us all frequently of our collective responsibilities to guard against attacks that compromise medical device safety and risk patient harm. The most impactful measures a manufacturer can take to guard hardware devices and software from malicious actors are to assess their attack surfaces, be proactive in monitoring and guarding, and be responsible in evolving cybersecurity mitigations. This applies not only to in-house engineering and product development teams, but to every hardware and software development partner and consultant that contributes to a product.
There are several techniques for minimizing attack surfaces and reducing the blast radius of an incident should one occur. These techniques include implementing a cybersecurity architecture in the device that guard against unauthorized access, establishing quality checkpoints throughout the product development lifecycle, and evaluating development partners for Software Development Lifecycle (SDLC) practices and their own outsourcing policies.
Securing Medical Device by Properly Evaluating Development Partners
Cyberattacks come in many different forms. Common examples include using the device as a penetration point into the devices larger network, embedding malicious code into the product, exfiltrating PII, and overloading the device or supporting ecosystems to prevent its intended use (e.g., Denial of Service and Distributed Denial of Service). All these attacks can come from within as readily as outside the organization. Fortunately, these potential attacks are partially or fully mitigated through hardware and software architectures and design patterns that promote security as a first-class citizen. Unfortunately, cybersecurity concepts can be difficult to understand and can be even harder to implement. It’s this very reason that medical device manufacturers must thoroughly evaluate the cybersecurity strategy and concrete mitigations both in-house and with development partners. Keep in mind that outsourcing can come in many forms, such as:- Hiring a development partner to build an entire medical device, or just a portion of the ecosystem such as a SaMD or Cloud IoMT solution.
- Sourcing parts such as Board Support Packages, integrated circuits (IC), or electrical components needed to build a printed circuit board.
- Pulling from public code repositories that are community built and shared. These libraries can potentially pull 10’s-100’s of additional support packages that introduce new attack surfaces.
- Hiring a development partner to perform a cybersecurity audit.
Regardless of what form outsourcing takes, it’s important to evaluate the entire attack surface of the medical device as well as the entire product development team and supply chain.
When selecting a development partner, thoroughly evaluate their ISO 9001 implementation, QMS processes, and any other relevant documentation and standards (e.g., IEC 62304/82304/60601-1, ISO 13485 and 14971:2019, etc.). Simply asking the right questions is the first step in the necessary process to fully audit and evaluate development partners. In addition to probing a prospective partner’s knowledge about cybersecurity, ask to see their documented SOPs to determine if their knowledge is being applied to their own policies and standards. And don’t be afraid to ask for references that can attest to their engineering history.
To help with future evaluations, here is a summarized checklist:
- Review vendor policies for compliance with standards relevant to the medical device.
- Conduct site visits to ensure access is limited to authorized and qualified personnel.
- Validate any certification claims as valid and current.
- Request that any deliverables come with a Bill of Materials (BoM) and/or Software BoM (SBoM) that shows compliance (e.g., RoHS, CVE, IEC/ISO, appropriate licenses, etc.) for the medical devices’ regulatory needs.
- Identify any offshore and onshore resources that will have access to the product to ensure only qualified and trusted engineers have access.
- Ask them to share their CAPA history and evaluate any issues the vendor has with their engineering processes and deliverables.
- Ask for (and contact) references of past products built by the development partner.
Thankfully, development teams are not on the hook for code reviewing every public repository used or evaluating every fuse and transistor in an IC or silicon wafer. But that doesn’t absolve the ethical and legal responsibilities to ensure patients are kept safe and data is secure. Assess the standards, guards, and training of potential development partners by asking the right questions and checking references.
Common Patterns to Discuss
There are common patterns used throughout the industry to address cybersecurity concerns. Discussing these with a prospective development partner will not only qualify them but will start a conversation that leads to the optimal solution for a particular device.Implementing a Zero Trust Architecture
A Zero Trust Architecture (ZTA) is based on the concept that it doesn’t matter who, what, where, when, or why a user or computer is in a networked system; they are assumed to be an unauthenticated and unauthorized actor in the system until proven otherwise (guilty until proven innocent). Understanding and applying ZTA can guide architects, engineers, and service teams to implement and coordinate the entire solution to confirm users, services, and requests are authenticated (AuthN) and authorized (AuthZ).
A common, older architecture is the concept of a “walled garden”. In a walled garden architecture, there is a single AuthN entry point that, once cleared, provides access to the authorized resources “behind the garden wall” without re-attesting AuthN beyond the initial AuthN entry point. An example of a walled garden architecture is likely sitting on your smartphone right now. Once you are authenticated into your phone (using passcode or biometric), you have access to your contacts, photos, and web browser.
In a ZTA, access to resources is not presumed by previous authentication. Instead of having a single AuthN checkpoint, resources in a ZTA system are guarded on each request. Using the smartphone example again, while providing your biometrics or passcode to unlock your smartphone, it likely isn’t enough to get you into your banking app. If your bank is practicing ZTA they will ask for your authentication every time you open the app; they make no presumption that the person who unlocked the phone is authenticated or authorized to access your account. In this model, every request and requester must provide evidence to the service that they are both AuthN’ed and AuthZ’ed for the resources. Failure to provide that evidence means a failure to retrieve that resource.
Put differently, the ZTA is distinct from the traditional architecture of a “walled garden” where there is only a single AuthN guard to the entire system. Instead, a ZTA enforces the behavior of attesting an actor’s AuthN and AuthZ on a regular basis. Furthermore, each service provider within the device’s ecosystem is responsible for providing this check, making no assumptions for AuthN and AuthZ, in effect participating in the enforcement of the overall cybersecurity of the medical device. This shared responsibility and permeating model creates an intricate and hardened barrier that helps to prevent unwanted access and exfiltration of data (accidental or intended).
Building a Network of Trust
A Network of Trust is a web of relationships established within a system. This can be applied to opensource software (e.g., jQuery, BlueZ, Django, AOSP, etc.) and all the dependencies it trusts and relies on to build itself, as well as to the relationships built with the development partner (after all, they depend on upstream resources and vendors themselves).
A Network of Trust provides a framework of establishing trust through transitive relationships. Meaning, in a model where actors A, B, and C talk with each other, if A trusts B, and B trusts C, then A can trust C (relying on a trust model where trust may be inherited through transitive relationships; see Figure 1 below).
Implementing a true Network of Trust may create some serious gaps in the overall cybersecurity of a medical device if implemented incorrectly but accepting that transitive relationships will organically evolve in almost all architectures allows for it to be evaluated and controlled. Ask development partners about the thoroughness of their tool evaluations and cybersecurity audits they’ve performed (i.e., are they internal or external audits; how frequent; when was the last audit performed), and how they enforce AuthN and AuthZ within their own network. Simply asking probative questions to development partners, early and frequently throughout the engagement, will be the starting point in helping to select, secure, and sustain a development partnership. This is also the beginning of a comprehensive audit that helps to map the trust boundaries that have been built by the development partner’s own Network of Trust and what risk they might be introducing into the medical device. If a partner is not in compliance with a device manufacturer’s standards, and their trust relationships are lacking proper guards, that partner could lead to additional attack surfaces in a medical device.
Securing the Supply Chain
A supply chain is the intricate web of interconnected providers needed to deliver the core components to build the medical device. This can be hardware, software, or services.
In hardware, this could be a chip manufacturer. In software, this could be a public code repository. And in services, this could be a logging service for an IoMT device. In all these examples, two main concepts are critical to understand:
- All actors in the supply chain must be trusted to establish and manage cybersecurity risks.
- The security of a medical device is only as strong as its weakest link.
To help guard against cybersecurity threats to a supply chain, consider adopting tools that help to freeze the software artifacts that includes a cryptographic signature to attest the immutability of the medical device’s origin (tamper evidence).
Also consider tooling that helps evaluate the software dependency trees for the correct licenses, versions, and known CVE’s; this is especially relevant in front-end development projects where opensource components are commonly pulled into the medical device. With opensource libraries and packages it’s very common to see developers use one popular package that can pull other lesser-known support packages (e.g., React, D3, Twisted, etc.).
Establishing a Chain of Trust
In a Chain of Trust architecture AuthN and AuthZ can be established by a chain of authority. This is considered a hierarchical transitive trust-building model. In this hierarchical model, there is a chain of trust that is built from the top down. A central authority authorizes delegates below it, in effect creating a chain of command or authority. The top of this dependency graph need not be responsible for authorizing or authenticating all agents below it, but only its immediate child agent. It’s up to the next immediate child to AuthN and AuthZ its children, and so on until all participants in the graph are attested (see Figure 2 below).
In practice one example of this is HTTPS (HTTP Secure), the pervasive and preferred way to connect to everyday internet sites. HTTPS includes a Certificate Authority (CA) at the top of the Chain of Trust and is the backbone of TLS/SSL communication.
Tying it All Together: Holding Development Partners Accountable & Establishing Trust
All these concepts are critical to understanding how to build a comprehensive “Network of Trust,” especially when mitigating cybersecurity risk in a medical device. All medical devices are built on more fundamental components. Hardware relies on a Bill of Materials including silicon chips and printed circuit boards. Software relies on code built upon code (think compilers or upstream support packages). It’s easy to think of potential bad actors as intruders directly modifying company source code. But it’s harder to imagine that bad actors often don’t need to access proprietary source code to compromise a medical device when they can, with less effort, move up the supply chain and inject their hacks upstream. The Log4J vulnerability exploited in 2022 is a perfect example of how even a widely used and well-respected software component can impact a wide range of systems.It’s for this very reason that it requires the entire product team, including those members coming from development partners, understand cybersecurity risk mitigations and ways of establishing and maintaining trust relationships with every supplier in the chain. Failing to do so creates blind-spots throughout the product development cycle, allowing hackers to infiltrate and exfiltrate.
Don’t be a victim of an avoidable cybersecurity attack because a development partner created an open invitation to hackers to compromise a medical device or service. Be thoughtful in the selection of a qualified and well-trained development partner and challenge them to rise to the occasion to be a shining example in enforcing cybersecurity standards. Patients will appreciate it.
Justin Carroll is a Software Engineering Director at Full Spectrum. When not designing Class-1 through Class-3 medical devices, or large distributed systems connecting cloud with IoT, Justin spends his time with his family camping in and around the Rocky Mountains. In addition to a long career in software engineering, Justin has his roots in data science. The combination of medical, cloud, embedded, and data science allows Justin to help clients around the world to develop secure and data-driven products that meet FDA, FIPS, and other regulatory needs. You can contact Justin at jcarroll@fullspectrumsoftware.com.