and SP2 ended on October 10, 2006
and July 13, 2010; security support
for SP3 will end on April 14, 2014. In
many cases, a medical device manufacturer does not provide an effective
way for hospitals to upgrade to supported versions of operating systems.
Today, healthcare providers are told
to maintain a secure system from insecure devices.
Integrity: High-risk pregnancy monitor infected with malware. A medical device infected with malware can
stray from its expected behavior. For
instance, malware can cause a device
to slow down and miss critical interrupts. When this happened on a high-risk pregnancy monitor, healthcare
professionals could no longer trust the
integrity of the sensor readings, and
depended on backup methods.
Availability: Anti-virus mishap disables hospital workflow. Anti-virus
software can help mitigate certain
cybersecurity risks, but can also introduce its own risks. On April 21, 2010,
one-third of the hospitals in Rhode
Island were forced to “postpone elective surgeries and stop treating patients without traumas in emergency
rooms” because an automated anti-virus software update had accidentally
misclassified a critical Windows DLL
as malicious. The problem with anti-virus software is that by definition,
anti-virus software is a post-market
afterthought to make up for design
flaws in the device. Anti-virus software
does not remove the need to incorporate security into the early design of
Regulation: u.s. food and
Drug Administration Actions
According to the FDA mission statement, the agency holds responsibility
for protecting the public health by assuring the safety, efficacy, and
security of medical devices. In June of this
year, the FDA issued draft guidance
5 and gave examples
of what FDA reviewers would expect
to see during pre-market review. The
draft guidance intentionally does not
prescribe any particular approach or
technology, but instead recommends
that manufacturers consider cybersecurity starting at the concept phase of
the medical device.
quence? Patients do not receive the
safe and effective care they deserve
when malware causes unavailability
of care. The VA has experienced hundreds of malware infections in medical devices such as X-ray machines
and lab equipment made by well-known, reputable companies.
Old software, old malware.
Conficker was detected on 104 devices at the
James A. Haley Veterans’ Hospital in
6 The affected devices included
an X-ray machine, mammography, and
a gamma camera for nuclear medicine
studies. Conficker is a relatively old
piece of malware with well-known mitigation strategies. Why does old malware persist on medical devices?
We observe that one of the cultural
challenges to improved cybersecurity
and therefore safety and effectiveness is
a lifecycle mismatch. For instance, operating system software with production
lifecycles measured in months does not
match well with a medical device having
production lifecycles measured in years
or decades. The equivalent of a transformer for impedance matching does
not yet exist for safely connecting these
different production cultures.
Risks of depending on unsupported software has parallels to depending on a device where parts are
no longer manufactured or repaired.
Medical devices still rely on the original versions of Windows XP (circa
2001). In October 2012, the Beth Israel Deaconess Medical Center in Boston reported to the NIST Information
Security and Privacy Advisory Board
that the hospital depends on 664
Windows-based medical devices primarily because of supply chain issues.
Of the 664 computers, 600 devices run
the original version of Windows XP.
There are no Service Pack 1 (SP1) machines, 15 SP2 machines, and one SP3
machine. One MRI machine still runs
Windows 95. Security support for SP1
atic national reporting system exists.
Yet, individual hospitals know of hundreds of security incidents on medical devices.
For instance, the FDA MAUDE does
not capture adverse events such as lack
of or impaired availability of function
when malware infects a medical device’s operating system. The FDA’s own
disclaimer explains that the MAUDE database is qualitative rather than quantitative. MAUDE is incomplete with un-derreporting and reporting bias.
Imagine the reaction of a clinician
using a high-risk pregnancy monitor
that begins to perform more slowly
because of a Conficker infection.
Would the clinician report a malware
infection? Likely not. Admitting to
playing a role in accidentally infecting a medical device would likely lead
to consequences ranging from disciplinary action to loss of reputation.
Thus, the actual incidence of security
failures leading to healthcare delivery
failures may be significantly greater
than the available statistics suggest.
To have better understanding of medical device security, the bad-news diode must be shorted. Reporting must
be incentivized rather than penalized.
Consequences of Cybersecurity
unpreparedness for medical
Devices: integrity and Availability
If you watch television crime dramas, you may be duped into thinking
that hacking of medical devices is the
number-one risk for public health today. You would be wrong. The most
pressing risks are much less sexy: the
unavailability of patient care and the
lack of health data integrity. Here, we
highlight a few examples that illustrate
the consequences of unavailability and
lack of integrity.
Availability of software to deliver
safe and effective patient care.
Interventional radiology suites and cardiac
catheterization labs contain a number
of computer systems to perform time-sensitive cardiac procedures, such as
angioplasty, to open blocked arteries
for improved outcomes in patients suffering acute heart attacks or strokes.
According to the Wall Street Journal,
6 a VA catheterization laboratory
in New Jersey was temporarily closed
in January 2010. Malware had infected
the computer systems. The conse-
Why does old
malware persist on