What is Cybersecurity Risk Management (CRM)?
Robust Cybersecurity Risk Management (CRM) prevents damage to computers and electronic communications systems, to ensure availability, integrity, and confidentiality. Connected medical devices (i.e., devices directly connected to other systems or devices through a computer network) create new sources of risk for medical devices. CRM is a medical device-centric process intended to:
• Identify threats, vulnerabilities, and assets associated with medical devices
• Estimate and evaluate associated security risks
• Control security risks; and
• Monitor the effectiveness of risk controls
Starting with a Threat Model, CRM evaluates possible threats that a security compromise may have on the medical device, people, environment, Medical Device Manufacturer (MDM), as well as the information being processed or stored by the device. CRM is a companion to Safety Risk Management (RM), the traditional ISO14971 Risk Management process for medical devices that focuses on Severity of Harm and Probability of Occurrence of Harm. From a Safety RM perspective, we look to reduce 'clinical' harms, such as Third-Degree Burns, Lacerations, Infections, and Broken Bones. From a CRM perspective, we look to reduce Data Breaches, System Downtime, and Reputational/Business Impacts.
When Cybersecurity threats lead to Safety Harms, Cybersecurity and Safety RM documentation must align, meaning all Safety Harms reside in the Safety Risk Analysis , even if the risk was identified by CRM (e.g., the attacker gains access to a medical device's code, alters the code, and causes the device to malfunction, which may lead to patient/user harm).
Do not confuse the two RM processes: one is focused on device system SAFETY, and the other is focused on device system SECURITY. The two methods do, in fact, overlap (See Figure 1) and certainly must be connected.Â
Not only do the SAFETY and SECURITY RM methods connect, but their recommended process steps are nearly identical, which can confuse Medical Device Manufacturers (MDMs).
Why two different Risk Management methods?Â
AAMI TIR57/SW96 propose TWO Risk Management (RM) methods. But why? Because, even though the two RM methods have similar process steps and use similar language, they ultimately identify and evaluate different hazards and harms.Â
SAFETY RM uses two independent variables, SEVERITY of HARM and Probability of Occurrence of HARM. But what are the independent variables for SECURITY RM? Are they the same? Are they different? How do we know? From FDA Guidance (Postmarket Management of Cybersecurity in Medical Devices, December 2016), the following may be helpful:Â
"One method of assessing the acceptability of risk involves using a matrix with combinations of "exploitability" and "severity of patient harm" to determine whether the risk of patient harm is controlled or uncontrolled. A manufacturer can then conduct assessments of the exploitability and severity of patient harm and then use such a matrix to assess the risk of patient harm for the identified cybersecurity vulnerabilities."
Furthermore, FDA provides an image of what this matrix may look like:
Given this guidance, let's sharpen the differences between SAFETY and SECURITY RM in the following manner:
Safety Risk (i.e., ISO 14971) = Severity of HARM (e.g., Clinical description – broken bone, death, laceration) PLUS Probability of Occurrence of HARM (i.e., How often does the HARM – laceration, broken bone – occur?).Â
Here, the Occurrence of HARM is estimated from actual use, such as Post Market Surveillance (PMS) data of similar devices. This PMS data helps bring 'math' to our occurrence estimates so they are not simply opinions.Â
Security Risk (i.e., AAMI TIR57/SW96) = Severity of HARM (e.g., Clinical description – a broken bone, death, laceration – if the vulnerability were to be exploited) PLUS EXPLOITABILITY of a Cybersecurity VULNERABILITY (i.e., How likely is the VULNERABILITY occur?).Â
A vulnerability is a specific technical weakness or flaw in a system, software, or hardware that attackers can exploit to compromise its security.
MDMs often do not have good PMS data on Vulnerabilities. So where does the 'math' come from to estimate the Exploitability of a Cybersecurity Vulnerability? Fortunately, the 'math' may come from global cybersecurity databases such as the National Vulnerability Database (NVD) [https://nvd.nist.gov/] and CVE [https://cve.mitre.org/]. Consider NVD and CVE a massive PMS database for common cybersecurity software and hardware used by many industries, not just medical devices.Â
How can we estimate vulnerabilities?
Using these powerful, cross-industry, global databases requires one more tool to bring the 'math' to our vulnerability estimates. Fortunately, another globally recognized approach is available: Common Vulnerability Scoring System (CVSS) [https://www.first.org/cvss/]. The purveyors of CVSS, FIRST, defines CVSS as:
"The Common Vulnerability Scoring System (CVSS) provides a way to capture the principal characteristics of a vulnerability and produce a numerical score reflecting its severity. The numerical score can then be translated into a qualitative representation (such as low, medium, high, and critical) to help organizations properly assess and prioritize their vulnerability management processes."
CVSS gives MDMs access to a global, open-source database to estimate the likelihood of a cybersecurity exploit using an FDA and globally recognized, validated, open-source, detailed approach that breaks down specific vulnerabilities to assess exploit likelihood. There are several factors used to frame vulnerability scores. For this Blog Post, let's not get into the details of the factors used by CVSS. For our immediate purposes, the CVSS method helps generate a 'score' for our vulnerability estimates. Using CVSS scoring and considering the image from FDA in 2016, we can come up with a SECURITY Risk Matrix that looks like the following:
Moving from Threats to Security Risk
While monitoring vulnerabilities ensures the ongoing security of a deployed device, addressing threats in the pre-market phase is equally critical. A threat is a potential action or actor that could exploit a vulnerability to cause harm, and in this phase, enumerating and analyzing threats helps shape the design of secure systems by anticipating potential risks before they materialize.
From the premarket guidance:
“FDA recommends that the cybersecurity risk assessment provided in premarket submissions should capture the risks and controls identified from the threat model. The methods used for scoring the risk pre- and post-mitigation and the associated acceptance criteria as well as the method for transferring security risks into the safety risk assessment process should also be provided as part of the premarket submission."
In our previous blog post, you can learn more about Threat Modeling, which is the activity preceding the Risk Assessment.
Leveraging CVSS does have a limitation, in that the specific exploit must be understood in context of the actual system (e.g., Intended Use, Data being shared/stored) and its use environment (e.g., Large Hospitals, Small Clinics, Home use by laypersons). So each threat identified by the Threat Model can be evaluated by CVSS, but each one should also be assigned an Exploitability Level, and ultimately a Severity, then plotted on the Security Risk Matrix shown in Figure 4. Again, Security Risk is the product of Severity of Harm (i.e., S1 through S5) and Exploitability of a Cybersecurity Vulnerability (i.e., E1 through E5), leading to a Risk Rating for each identified Risk as Red (Highest Risk), Yellow (Medium Risk), or Green (Lowest Risk).Â
Once all of the threats from the Threat Model have had the risk estimated, then the unacceptable ones (e.g., Yellow, Red risks) are reviewed for potential Risk Control Measures (RCM). Leveraging AAMI TIR SW96 (2023), not all RCMs are created equal, there is a priority order for risk reduction (i.e., Strongest to weakest):Â
a) inherent security by design
b) inherent security by manufacturing process
c) protective threat mitigation measures added into the medical device
d) protective threat mitigation measures added to the manufacturing process;
e) security risk disclosure (i.e., providing needed security information to users) and/or security risk transfer to users; and
f) where appropriate, security training to users.
So the most robust way to reduce a risk is to design it out of the device or the device system. The least robust way to reduce a risk, is to provide labeling or training for your users, simply relying on them to control the risk. Labelling and training are an acceptable form of risk reduction, just understand that they are weak and should not be expected to reduce a Red risk to Green.Â
What does FDA require?
From FDA guidance (2023):Â
"Performing security risk management is distinct from performing safety risk management as described in ISO 14971. The distinction in the performance of these processes is due to the fact that in the security context versus the safety context, the scope of possible harm and the risk assessment factors may be different. Also, while safety risk management focuses on physical injury, damage to property or the environment, or delay and/or denial of care due to device or system unavailability, security risk management may include risks that can result in indirect or direct patient harm…The scope and objective of a security risk management process, in conjunction with other SPDF processes (e.g., security testing), is to expose how threats, through vulnerabilities, can manifest patient harm and other potential risks."
Furthermore:
"FDA recommends that device manufacturers conduct both a safety risk assessment and a separate, accompanying security risk assessment to ensure a more comprehensive identification and management of patient safety risks."
Here, what FDA requires is strongly influenced by others (e., AAMI TIR 57, AAMI SW 96, IEC 81001). As stated above, the SECURITY Risk Management process is a companion to and is connected to, the SAFETY RM process. Their processes are similar, with similar terminology, but measure very different sets of risks. Building efficient and compliant Risk Management systems takes time and care, but the results pay off quite handsomely.
The FDA guidance also nicely highlights how the risk assessment should be conducted following the threat model:
“FDA recommends that the cybersecurity risk assessment provided in premarket submissions should capture the risks and controls identified from the threat model. The methods used for scoring the risk pre- and post-mitigation and the associated acceptance criteria as well as the method for transferring security risks into the safety risk assessment process should also be provided as part of the premarket submission."
This highlights that the CRM cannot be effectively accomplished without a robust Threat Model. As we have stated, the Threat Model is an input to the Cybersecurity Risk Management (CRM) process. Just as we recommended with the Threat Model, using a known, globally recognized, approach to evaluate and estimate CRM will go a long way to bringing consistency to the RM effort and to support design teams with the clarity required to develop a secure medical device.Â
How Security Pattern can help
We offer various consultancy services and training modules to support your organization with cybersecurity challenges. For the topic covered in this article, we highly recommend:
The Threat Modeling and Risk Assessment consultancy service
The ARIANNA platform: the product security management platform for connected devices and systems.
About the Author
Dr. John Salvato, President, Design Quality Services LLC
Design Quality Services (DQS) was established to support large and small innovators' product development endeavours, resolve quality system challenges, and provide technical training. The pathway to commercialization is complex, regulatory expectations can be ambiguous, and quality management systems (QMS) may become unstable. DQS brings a pragmatic approach to enable these pathways, fostering business growth and market success. We are here to help you solve your toughest challenges. John has an impressive 30-year career spanning quality assurance, manufacturing, and product development in the medical device and automotive industries. As the president of DQS, he brings exceptional engineering abilities and unparalleled global management experience. His leadership has led to successful development projects globally. John leverages his many years of professional experience with his academic work.Â
Comments