For the first time, on July 9, 2019, ICS-CERT disclosed a vulnerability specifically impacting anesthesia machines. If exploited, the vulnerability would allow an attacker to silence alarms, alter date and time settings, adjust gas composition inputs, change barometric pressure, and switch between anesthetic agents — all without authentication.
Affecting GE Aestiva and GE Aespire (models 7100 and 7900) machines that are ported to the network via terminal servers, the exploitation chain for this vulnerability is actually quite simple — provided you know your way around the communication protocol that these machines use.
For reasons of convenience and interoperability, these devices are designed to allow for backward compatibility of their network communication protocol. What that means in effect is that despite running an updated protocol version, if needed, you can force the machines to revert to earlier protocol versions. The problem is that those older versions are often less secure and, having been built on a common technological framework, might support network commands that have since been disabled on account of their having no legitimate clinical purpose. It’s precisely such commands that lay at the heart of this vulnerability.
Of course, security and backward compatibility are not mutually exclusive. If you have proper authentication and authorization controls in place, both can be accommodated. If the devices were configured to only allow protocol reversion after a request is authenticated and authorized, it would not be a real problem. The attack surface would be rendered so small that it would be altogether negligible. Unfortunately, as was the case with this vulnerability and is the case with many medical devices, authentication and authorization are often overlooked.
When it comes to these GE devices, that means that anyone familiar with the communication protocol can force a revert and send a variety of problematic commands to the machine.
If reading this has you worried, it should. More worrying still, this vulnerability was given a CVSS grade of just 5.3 — reflecting only moderate severity. So how is it that a vulnerability allowing malicious actors to manipulate key anesthesia machine settings can be scored so lightly?
What Exactly Does a "Moderate" CVSS Severity Denote?
To understand the problem, you need to understand the context. The CVSS is a standardized scale for measuring the severity of computer system security vulnerabilities and was first introduced in 2005. Back then, cyber threats were entering a new era of proliferation and a universal standard for their assessment was needed.
Since then, three additional versions of the scoring system were introduced in 2007, 2015, and 2019 respectively. Each version was meant to incrementally improve on the shortcomings or limitations of its predecessors. The CVSS assesses a vulnerability according to Base metrics (including User Interaction, Privileges Required, Scope, Attack Complexity, and Authentication), Impact metrics (including Confidentiality, Integrity, and Availability), Temporal metrics (including Exploitability, Remediation Level, and Report Confidence), and the Modified Base (meant to de-genericize the score and account for differences in how a vulnerability might a given organization compared to the world as a whole).
The problem is that the fundamental approach to severity assessment has remained the same for the last 15 years. When the Common Vulnerability Scoring System was conceived, it looked to quantify the impact potential of security flaws in technology ecosystems. As such, it approached the question on a purely technological basis. No one was thinking about things like medical device vulnerabilities back then. Today, however, we need a common system for quantifying the impact potential of cybersecurity vulnerabilities in human ecosystems. We need a scale that could measure “risk” more holistically — in terms of both technology and human costs.
While new recommendations have been made, we’re still waiting for a new rubrik. In the meantime, the healthcare industry applies, or rather misapplies, a measurement system that is entirely blind to a huge component of its vulnerabilities’ risks. When it comes to the potential for harm from a vulnerability in a device connected to human beings, the CVSS score really does NOT give an accurate picture of the risk. Indeed, the CVSS score is not meant to capture “risk” per se, but the accessibility and system severity of a potential exploit. As such, the score expresses the potential for system compromise, not the potential for human impact.
The reality however is that a vulnerability opening the door to the same level of system compromise, with the same CVSS score, could pose vastly different potentials for harm depending on whether or not the machine is connected to a person.
Going back to our original question then, how CVE-2019-10966 could appear so serious and be afforded such a modest severity score, the answer is because the potential for system compromise is somewhat limited — lacking, for example, the ability to load any malicious content onto the machine; significantly though, the potential for human impact is considerable — for example, with the ability to silence alarms that might require immediate intervention.
In this sense, the discrepancy between the details of the vulnerability and the CVSS score here touches on a larger industry issue in that there is currently no scoring system designed to express the potential for total risk — including human impact.
So How Severe Is This Vulnerability Really?
It’s important to not sensationalize this disclosure or overstate the risks presented by the vulnerability. GE has said that under normal circumstances, an exploit is not expected to present a direct risk to the safety of a reasonably healthy patient.
That said, any unintended manipulation of a highly complex and sensitive medical device is not a good thing and should obviously be defended against. Here, it’s not even just of matter of sensitive technology, but sensitive science. Every patient responds differently to anesthetics and close, precise supervision is therefore required. I’ve been told by anesthesiologists that certain procedures and certain patients — particularly the elderly — can, for example, be extremely sensitivity to oxygen and nitrous oxide levels.
Having your gas compositions inputs properly calibrated is important and even if there’s no direct danger to the patient, it does not mean that the machine or the chemicals it dispenses will work as intended. As such, the severity of the impact would likely vary with the patient and procedure in question as well as the extent of composition alteration.
Of course, this vulnerability could also be exploited to enable an attacker to silence alarms on targeted devices, the implications of which you don’t need a medical license to appreciate. Bottom line: if this vulnerability were to be scored on a more holistic scale for risk, it would be considered critical.
De-Network the Device, Solve the Problem?
When you think about anesthesia machines, it might not immediately be clear to you why they’re networked in the first place, and you might think that the best solution is simply to de-network them. This would be a mistake.
Because of the highly individual reactions and sensitivities to anesthetics, strict protocols and rules have been established to precisely document what occurs over the course of a procedure. It’s largely for this reason that these machines are networked to begin with: so that every interaction can be automatically and accurately captured for the record. And it is in this regard that alterations to date and time settings can prove consequential — jumbling log chronology and undermining the efficacy of medical records and audit trails.
As CyberMDX Head of Research Elad Luz remarked, “The potential for manipulating alarms and gas compositions is obviously troubling. More subtle but just as problematic is the ability to alter timestamps that reflect and document what happened in a surgery...Once the integrity of time and date settings has been compromised, you no longer have reliable audit trails. That's a very serious problem for any medical center.”
In other words, if you’re hoping to avoid the headache that this vulnerability might cause by de-networking your Aestiva and Aespire devices, you’ll just be guaranteeing yourself much of that self-same headache.
The disclosure of CVE-2019-10966 made the news as the first CVE released specifically affecting anesthesia machines. The real story here though is a lot less about a novel discovery and a lot more about fundamental and persistent industry shortcomings.
There’s the story of the authentication and authorization controls that manufacturers are still overlooking and neglecting to bake into their device designs. There’s the story of the industry standard severity scoring system that not only fails to capture key risk factors but can dangerously mislead stakeholders to delay action. And there’s the story — that I didn’t even address here — of how this vulnerability took more than eight months to be released.
Yes, the fact that this is the first ICS-CERT confirmed remote vulnerability in an anesthesia machine is interesting, but that's really just the tip of the iceberg. As an industry, we have a great deal of work ahead of us, and if we want to avoid being shipwrecked, we’d be wise to take note of what lies below the surface.