Another step in the long road to better cybersecurity for medical devices
--
When it comes to evaluating risk, context may not be everything, but it’s a very big thing. That has been apparent for months now regarding the coronavirus pandemic. The same virus is not the same threat to everybody. While COVID-19 can kill anybody, the risk to an 80-year-old with asthma is vastly greater than it is to a healthy high-schooler.
Context applies to risks caused by vulnerabilities in connected medical devices as well. The Common Vulnerability Scoring System (CVSS) for ranking the severity of a software vulnerability, on a scale of 0 to10, is based on the likelihood of it being exploited plus the impact it would have if it were exploited.
But to be useful, those scores need context. As should be obvious, impact can vary wildly depending on what kind of damage could result and who or what would be affected.
If a given vulnerability in financial software led to an exploit that caused $1 million in damage to Saudi Aramco — the biggest energy company in the world — and to a company with a single oil well in Kentucky, you don’t need a calculator to figure out which victim would suffer more.
A $1 million hit might put the Kentucky company out of business. For Saudi Aramco, with $295 billion in annual revenue, $1 million isn’t even a rounding error in its bottom line.
Another example: If a given software vulnerability led to the compromise of your credit card, that would be a financial headache. But if that same vulnerability could be exploited by a hacker to get control of a connected, implanted medical device that is helping to keep you alive, that would be an existential threat.
So context is the rationale behind the U.S. Food and Drug Administration’s (FDA) recent approval of a rubric created by the MITRE Corporation designed to rank the severity of vulnerabilities found in medical devices. MITRE issued a version of the rubric more than a year ago, in September 2019, but it was just a couple of weeks ago that the FDA announced that it has approved it as a Medical Device Development Tool (MDDT).
The need is obvious. Cyber vulnerabilities in medical devices or in the systems and networks that support them could allow malicious hackers to turn healing tools into lethal weapons, or into leverage for ransom or blackmail.
Basic CVSS scores are assigned by the National Vulnerability Database (NVD) within the National Institute of Standards and Technology (NIST).
Same vulnerability, different risk
But clearly, a single scoring system for vulnerabilities that could affect things ranging from smart watches to medical devices to critical infrastructure to military missiles can be worse than just misleading or confusing — it could be dangerous.
Jonathan Knudsen, senior security strategist at Synopsys, cited Heartbleed, a major security vulnerability in the popular OpenSSL (secure socket layer) cryptographic software library, as an example of how different vulnerabilities are perceived.
He noted that some security experts said Heartbleed should have been given an off-the-chart 14 severity rating. But its official CVSS score? Just 7.5. It had only a 5.0 rating when it was first discovered in 2014.
Heartbleed allowed attackers to trick servers into leaking information stored in their memory and also to access a server’s private encryption key. It was discovered and a fix came quickly, but even now, six years later, there are unpatched systems that are vulnerable to it.
“The cold hard truth is that measuring or even estimating risk is difficult to impossible,” Knudsen said, “roughly as effective as reading the patterns of tea leaves in the bottom of your cup.”
In a class he taught last fall, Knudsen described a vulnerability to his students and asked them to fill out the CVSS calculator online. “Everyone came up with a different number,” he said.
There are three ways to rank vulnerabilities — base, temporal and environmental — and NIST acknowledges that the CVSS provides only a base score, calculated by the unchanging, static components of a vulnerability.
A temporal score can change, based on things like a patch being available (which would lower it) or hackers actively exploiting it (which would make it higher).
An environmental score would reflect the impact on a specific company or use cases, such as medical devices.
Setting priorities
Hence the new rubric, designed to rank vulnerabilities based on a medical environment.
As the new MITRE rubric’s authors, Penny Chase, senior principal scientist, and Steve Christey Coley, principal information security engineer, put it, “there are challenges in using CVSS to assess the severity of vulnerabilities in medical devices. CVSS and its associated rubric and examples were developed for enterprise information technology systems and do not adequately reflect the clinical environment and potential patient safety impacts.”
Or as Michael Fabian, principal consultant at Synopsys, put it somewhat more bluntly, “the point of the score should not be to tell us what to fix, but to set priorities. You need context to tell you what the most severe threats are. And severity and impact need to be addressed based on the environment where that product lives.”
Will the new rubric do that? Will it be a game changer for medical device security? Apparently we’re about to find out, given that it will be used by vendors working on premarket security and risk assessments, to gain FDA approval for devices.
Knudsen is a bit dubious, given that there are already multiple versions of the CVSS. The new rubric “dilutes an already confused landscape — we have CVSS 2, CVSS 3.0 and CVSS 3.1,” he said. “Now we’ll also have some healthcare-specific version of CVSS? It sounds like a bit of a mess.”
But according to MITRE (and the FDA), the goal is to maintain the “common language” of the CVSS while adapting it to healthcare risks.
“The rubric is structured as a series of questions at various decision points,” the authors said, adding that the questions are “organized in a way that prioritizes answers with the most significant contribution to the CVSS score.”
Chase and Coley said one of the challenges in assigning scores based on “real-world” conditions is to maintain the delicate balance among privacy, safety and security. Obviously, security should not undermine safety, as in, “you don’t want antivirus to fire during surgery,” they wrote.
So to get the best and most relevant scores, they recommend using “a group of subject matter experts (SMEs), not just a single analyst. From the perspective of patient safety, at a minimum, the following knowledge areas should be shared across the entire group:”
- Cybersecurity and privacy
- Device engineering, design, and architecture
- Patient health impact from resulting hazards
- Information technology integration and interoperability
Stephanie Domas, executive vice president of research at MedSec, which provides cybersecurity software and services to hospitals and medical device manufacturers, sees the new rubric as promising. While its approval by the FDA came just last month, it has already been used by a number of vendors since it has been available for more than a year.
She said one of the best things about it is that the questions are “very concrete” and focus on what a device does, such as diagnose and/or treat a patient, and where it is used.
“They made it so you don’t have to be security expert to come up with a security risk score,” she said.
The downside is that it is so complex and detailed that it has been difficult for vendors to use it effectively on their own. But that has changed, she said, now that MedSec, has “built an Excel-based tool to walk you through it.”
Game changer? Maybe
Domas, who led the development of the tool, said it “does all the calculations for you.” And with that, she said the new rubric does have a chance to be a game changer.
One of the problems with adapting CVSS scores to different industries is that there is so much room for interpretation. As was the case with Knudsen’s students, who came up with different scores for the same vulnerability when using the CVSS calculator, Domas said scoring of medical device vulnerabilities wasn’t “repeatable” because different experts came to different conclusions.
“But this is repeatable, because of the rubric,” she said, “and being repeatable is the game changer.”
That doesn’t mean it will overhaul medical device security overnight. If it were a matter of setting standards or priorities, that overhaul would have already happened. It’s been six years, after all, since the FDA issued guidance on “premarket submissions for management of cybersecurity in medical devices.”
And it was more than two years ago, in June 2018, that the FDA adopted the ANSI (American National Standards Institute) UL 2900–2–1 as a “consensus standard” for the premarket certification process of connected medical devices. That standard, developed over a number of years with input from multiple stakeholders including Synopsys, called for, among other things, “structured penetration testing, evaluation of product source code, and analysis of software bill of materials.”
But Domas believes the overall trend is promising, even though progress is uneven. She said a “very large segment” of the industry is taking security more seriously, but that there is also a significant number of vendors that are still “on their maturity journey.”
That’s because, in spite of constant exhortations from security experts to “build security in” to the software that runs the devices throughout its development, some are still waiting until the end of development to address security.
“Where security becomes a big barrier is after the fact,” Domas said, when penetration testing finds vulnerabilities that could have been fixed more quickly and cheaply during earlier stages of development but going back to fix them will delay a product’s submission.
“There does need to be a culture change,” she said. It’s a struggle to move the needle.”
Knudsen said the realities of software security apply to every industry. “Everybody likes to think that their industry has special software problems, but they’re wrong. The inconvenient truth is that building software right is hard. You have to put in the work, you have to make security part of the process, and you have to fix as many bugs as you can.”
