Medical Device Cyber Risk Management

Armin Torres, Principal, Qualified Data Systems, a BioTeknica sister company.

Medical Device Cyber Risk Management is the marriage between Safety and Security. It may seem an afterthought that we should be innately capable of living on a safe and secure planet as humans, but what about the connected devices that surround us more and more each day?  How are these made safe and secure? And how can the lack of device security affect us as humans? These are difficult questions to answer in today’s hyper-driven technology marketplace.

It seems that the only thing that ever mattered when it came to medical device design was proving Safety and Performance. Safety was the sacrificial offering made to the regulators, while performance was the thing that sold product and made the quality of our lives better.

Who can blame design engineers when all the regulatory focus has been on producing safe and effective devices? After all, proving safety and effectiveness is a prerequisite to market entry, but security is something intangible, an elusive characteristic, difficult to demonstrate.

Today, Safety shares the spotlight with Product Security. There is no alternative in light of the continued security breaches, hacks, and malware proliferating in our progress towards a more autonomous society. So how do we manage these new risks?

Effective Cyber Risk Management begins with a deep understanding of how device designs may affect trust boundaries between Man/Machine and Machine2Machine interactions.  In light of this, Product Security Risk Management has to be contextualized by both the user and device environments. The user environment is typically defined by the intended use or essential clinical performance of the device design.  The device environment is typically defined by the operating modes of the medical device itself. A good example of these concepts is a diagnostic monitoring device.

A diagnostic monitoring device may have numerous users such as the patient, the clinician, the biomedical engineer, and the medical device manufacturer. Each of these users may interact with the device differently for various reasons in the care continuum. Therefore, each defined user type interaction with the device represents a possible threat actor in the product’s security profile. Additionally, these threat actors must be reviewed within the context of the device’s operating environment. A diagnostic monitor could be used in an ambulatory mode, in a critical care setting, or limited for a defined in-patient diagnostic procedure. Each of these environmental modes of operation may help contribute to or degrade the security profile of the device. Obviously, using the device in a home healthcare setting is very different from a hospital ICU. Luckily, many medical devices are simple in nature and offer a single device use profile within a set clinical environment. These devices tend to be the easiest to secure, but others that offer multiple components, such as an advanced insulin pump system, are more challenging.

A simple workflow that highlights this Cyber Risk Management Process is illustrated below.

Step 1: Asset Inventory

List all assets and/or security signals related to the medical device’s intended use and essential clinical performance in the device’s operating environment (Use Case) that require protection. These assets may vary based on the device’s user profile and/or operating environment profile (i.e., mode of operation or state). An asset may be tangible (e.g., a physical item such as hardware, firmware, computing platform, network device, or other technology component) or intangible (e.g., humans, data, information, software, capability, function, service, trademark, copyright, patent, intellectual property, image, or reputation). Together, these profiles are often considered the device’s Protection Profile.  From these characteristics, the appropriate protections are engineered to provide the requisite system security performance and effectiveness and to control, to the extent reasonable and practical, asset loss and the associated consequences.

Step 2: Identify Threat Sources

Identify and evaluate all potential threat sources and their potential targets. These must be evaluated against the user and device profiles. Cyber threat sources refer to persons who attempt unauthorized access to a medical device, system, and/or network using a data communications pathway. This access can be directed from within a user facility by trusted users or from remote locations by unknown persons using the internet. If a threat source were to exploit a device vulnerability, then the threat could potentially adversely impact the essential clinical performance of the device.

Step 3: Identify Device Functions

Identify and evaluate all of the device functions that may be vulnerable to an attack. These must be evaluated against Essential Clinical Performance. Effective cybersecurity risk management is intended to reduce the risk to patients by decreasing the likelihood that device functionality is intentionally or unintentionally compromised by inadequate security.

Step 4: Identify Vulnerabilities

Identify and characterize device vulnerabilities based upon an evaluation of Threat Sources and the Device Functions. Select the assets and/or signals that have a potential vulnerability and describe the vulnerability in detail. Vulnerabilities should be identified within the context of a device’s user profile and/or operating environment profile. The presence of a vulnerability does not necessarily trigger patient safety concerns. Rather, it is the impact of the vulnerability on the essential clinical performance of the device that may trigger patient safety concerns. Regardless of whether the vulnerability impacts essential clinical performance or not, all vulnerabilities should be characterized for future impact.

Step 5: Assess Vulnerabilities

Assess the likelihood of vulnerabilities being exploited and the vulnerability risk level using the industry standard Common Vulnerability Scoring System (CVSS). If the vulnerability is already scored by a third-party source or the manufacturer of the component, then complete the scoring using the vendor-provided CVSS v3.0 vector string. For those who are not familiar with this scoring system, you can get more information here:  First.org.

An example of device vulnerability assessment is illustrated below.

Once you have scored the device’s vulnerabilities using the CVSS as shown above, you can then integrate this into your Device Hazard Analysis to marry your product’s security with its Safety Risk Assessment. An example of this marriage is illustrated below.

Once all this is done, don’t forget to incorporate your Product Security Risk Management into your overall Risk Management Strategy and Plans.

A final note of caution is in order here. Performing this marriage between Safety and Product Security may require the skills of an interdisciplinary team consisting of information technology professionals, product development engineers, software engineers, quality engineers, technical support personnel, clinicians, and others.

In the end, connected medical devices that operate in our environment should be designed and implemented to be as secure as they are safe for the sake of all humanity. No pressure designers, the world is depending on you!