typically needs to be approved by the
manufacturer. Thus, deployment of security-relevant upgrades typically gets
36 Manufacturers, importers,
and device user facilities are required
to report specific device-related adverse events and product problems.
Surveillance strategies must be reconsidered in order to effectively and
efficiently collect data on security and
privacy problems in medical devices.
Some regulation aspects as well as the
role of standards bodies, manufacturers, and clinical facilities have been
discussed in Fu and Blum.
12 We see
a demand for action to adjust the increasing need for software updates for
medical devices with the need to redo
clinical trials after major changes.
Vulnerabilities are often unknown until malware
exploiting those vulnerabilities is detected. We need methods to detect
the presence of malware. Malware
detection techniques include control-flow integrity verification, call stack
monitoring, dataflow analysis, and
multisource hash-based verification.
Although software-based malware detection methods are suitable for traditional computing systems, the performance overhead may be prohibitive
for medical devices with strict time
constraints. Hardware-based detection
methods can reduce or eliminate the
performance overhead, but power consumption remains a challenge.
For medical devices, we need malware detection methods that are non-intrusive with very low power consumption, as power is a precious resource,
especially in implantable devices. In
order to provide resilience to zero-day exploits, anomaly-based malware
detection methods will be needed.
These methods rely on accurate models of normal system behavior, which
will require both formal methods for
modeling this behavior and tight integration with system design tasks. The
importance of timing requirements in
medical devices may provide a unique
system feature that can be exploited to
better detect malware.
Malware reaction. Detecting mal-
ware only addresses half of the prob-
lems. Once malware is detected, how
should the medical device respond?
Notification is a straightforward op-
tion, but it allows the malware to re-
makers. Hardware Trojans on medical
devices seem unrealistic today, but
precautions must be taken to reduce
attack vectors wherever possible. Back-
doors in military chips have already
been documented, where attackers
could extract configuration data from
the chip, reprogram crypto and access
keys, modify low-level silicon features,
and also permanently damage the de-
30 An approach for automatic em-
bedding of customizable hardware
Trojan horses into arbitrary finite state
machines has been demonstrated.
These Trojan horses are undetectable
35 Radio pathways
have been embedded into computers,
where computers could be remotely
controlled and provided with malware
even when they were not connected to
We must keep in mind that hardware Trojans can be an attack vector
for medical devices too. It is important
to ensure such malware is not installed
in the manufacturing process. Given
the reliance on computer-aided design
tools, it is further necessary to ensure
hardware Trojans are not inserted in
the design by these tools. Verification
methods utilized in designing hardware should ensure the resulting output designs match the inputs and do
not contain additional circuitry. Outside of using trusted manufactures for
each stage of design, ensuring Trojan-free hardware is not practical. Thus,
detection and mitigation capabilities
will still be needed. Once malicious
hardware is detected and its behavior is understood, research on how to
mitigate the affects of the malicious
hardware to ensure safety of medical
devices will be of critical importance.
Interoperability. Increasingly, medi-
cal devices rely on wireless connectivity,
be it for remote monitoring, or for re-
mote updates of settings or even for an
update of the software itself. Interoper-
ability challenges include secure pro-
tocols, authentication, authorization,
encryption, and key management. In-
teroperability of medical devices is es-
pecially tricky due to medical emergen-
cy situations. In case of an emergency,
health personnel may need to access
not only medical records, but also medi-
cal devices of a person in need, perhaps
in a life-threatening situation. Authenti-
cation and authorization mechanisms
must have a bypass or shortcut for such
circumstances. However, these bypass-
es and shortcuts should not provide a
means that enables attackers to gain
access to the device.
Initiatives to secure the interoper-
ability of medical devices include ex-
ternally worn devices,
3 for example, a
trustworthy wrist-worn amulet,
software radio shields.
have also created a prototype firewall
to block hackers from interfering with
wireless medical devices32 and to au-
thenticate via physical contact and the
comparison of ECG readings.
Organizational. Security is most
effective when designed into the sys-
tem from the very initial development
cycle. It is important to develop and
maintain threat models and to as-
sess risks during device development.
A systematic plan for the provision
of software updates and patches is
needed. Last but not least, a security
response team has to permanently
identify, monitor, and resolve security
incidents and security vulnerabilities.
For that purpose, user facilities such
as hospitals and clinics should be in-
centivized to report security occurrenc-
es. These reports can provide valuable
insights into security problems of med-
ical devices. In addition, we propose
the definition of security and threat
levels for medical devices with defined
rules of action and an audit guideline
for all involved stakeholders. The lev-
els defined in the table here are a small
first step in that direction. We imagine
simple scores for medical devices that
summarize their sensitivity, their im-
pact as well as their exposure and their
current threat level. Rule-based actions
could then trigger needed actions to re-
act to security-related incidents.
Regulations. It is important to know
at any time the level of danger and to
take appropriate countermeasures.
Design and distribution of medical
devices is tightly regulated. In the U.S.,
the FDA has the authority over medical
device distribution. A device manufacturer has the responsibility for the
approved configuration of the device.
Device users, such as hospitals and patients, do not have access to a device’s
software environment and cannot
install additional security measures.
Any upgrade or update—either added
functionality or security measures—