Recommendations for safety and IT security in medical devices
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
DSI Industrial & Policy Recommendations (IPR) Series
Recommendations for safety and IT security
in medical devices
Isabel Skierka (Digital Society Institute, ESM T Berlin)
Issue 6, 2017
The healthcare industry is undergoing great technolog- are systemic . Cyber attacks’ impact on the privacy of
ical transformations. Hospitals are going digital and patient data has already been established. M ore re-
medical devices – whether implanted in patients’ bod- cently, their potential impact on patient health and
ies or stationed in hospitals – are equipped with increas- safety has been raising concerns for healthcare organi-
ing computing power and wireless connectivity. Con- zations, regulators, and medical device manufacturers
nected healthcare can offer safer, more efficient, and alike. The management and governance of related risks
timely medical service delivery. It also presents great requires comprehensive standardization, regulation,
economic opportunities – according to a Roland Berger and best practices to encompass both IT security and
consultancy firm study, the digital healthcare market is safety.
set to grow at average annual growth rates of 21 per- The below analysis of the convergence of safety and
cent until 2020 (Roland Berger 2016). security risks in connected healthcare and recommen-
Yet, the integration of computing and communica- dations for policy and industry are based on a review of
tion technologies in safety-critical medical systems will the relevant literature, expert interviews, and a DSI
expose them to the same network and information se- workshop with representatives from health organiza-
curity (cybersecurity) threats as other information tions, medical device manufacturers, IT security ex-
technology (IT) systems. Research and real-world inci- perts, safety engineers, regulators, and certification
dents have shown that IT security risks in healthcare bodies.
1. Status
1.1 Cybersecurity incidents in
medical devices
For over a decade, researchers have been warning that Regular patching of cybersecurity vulnerabilities, a
the level of cybersecurity in safety-critical medical de- practice most people know only from their desktop IT
vices is alarmingly low. On August 29, the US Food and systems, is on the way to becoming a common proce-
Drug Administration (FDA) issued a recall for nearly half dure in health care.
a million pacemakers made by Abbott Laboratories (US The Abbott pacemaker recall is just the latest in a
Food & Drug Administration 2017). The agency found series of incidents. While no single incident to date has
that the devices could be hacked to control pacing or been known to cause deaths by hacking into a pace-
deplete the devices’ batteries, with potentially fatal maker or insulin pump, several researchers have
consequences. As a result, all patients whose lives de- demonstrated that it is possible. In 2008, a team of re-
pend on one of the affected pacemaker models, ap- searchers first demonstrated attacks against implanta-
proximately 745,000 persons worldwide, had to visit ble cardiac defibrillators. With the help of a commer-
their doctors to receive a firmware update that patches cially available device programmer, the team was able
the security flaws. to extract a patient’s private data and reprogram the
pacemaker to deny service (Halperin et al., 2008).
Page 1 of 15DSI Industrial & Policy Recommendations (IPR) Series
Recommendations for safety and IT security in medical devices
Since then, several have demonstrated different Tradeoffs bet ween security, safety, and ot her
possibilities for hacking pacemakers and insulin pumps essent ial sy stem requirements
(Burleson et al., 2012; M arin et al., 2016; Li, Achieving a balance between medical systems’ security
Raghunathan, and Jha 2011; Radcliffe 2011). In M ay of goals and health care utility and safety is challenging.
this year, researchers from the security firm M ost medical devices rely on embedded computer sys-
WhiteScope discovered a total of 8,665 open and known tems, which are constrained in their computation
vulnerabilities in third-party software libraries imple- power, memory, and energy consumption. Security
mented across four different pacemaker programmers mechanisms can slow down their operation, reduce us-
from four different manufacturers (Rios and Butts able battery life and make devices less accessible in
2017). This is a failure of enormous proportions. emergency situations. M oreover, generic security con-
Not only implantable but also stationary hospital trols such as password access controls can hamper usa-
devices are vulnerable to hacking. A 2014 report by the bility in fast paced clinical environments. Hence, secu-
SANS Institute concluded that 94 percent of healthcare rity mechanisms need not only be secure, but also
organizations have been the victim of a cyber attack, usable, efficient and compatible with the unique cir-
including attacks against medical devices and infra- cumstances of these systems.
structure (Filkins 2014). Other reports have shown how Related dilemmas have been subject to a growing
vulnerable medical devices served as conduits for hack- corpus of research and suggestions for innovative en-
ers to attack hospital networks (Independent Security cryption and authentication solutions. Yet, to date
Evaluators 2016). The “WannaCry” ransomware worm, none of these have been found to be secure enough for
which compromised the networks of many global cor- implementation attacks (for an overview, see M arin et
porations earlier this year, also affected medical de- al., 2016).
vices in hospitals and prompted the US Industrial Con-
trol System Computer Emergency Response Team (ICS- Lifecy cle conflicts
CERT) and several medical device vendors to issue se- The life time of medical devices is much longer than
curity alerts about vulnerable devices (ICS-CERT 2017). the life time of software. A medical device’s life time
These examples and others show that cybersecurity is between 10 and 30 years, which is much longer than
risks in health care are systemic. M any medical devices the supported life time of most operating systems. As
lack even basic security features, and the resulting a result, software usually becomes outdated and un-
risks are externalized. Unfortunately, the parties most supported over the course of a device’s lifetime. As re-
affected by the risk – the patients themselves – can do use of hardware and software systems in medical de-
little to improve the security of the devices on which vices is common, a medical device is generally a mix of
their own health depends. new and old legacy systems. M oreover, legacy systems
may no longer be interoperable with newer systems.
This leaves vulnerabilities such as misconfiguration and
1.2 Structural obstacles security holes. M edical devices running on the M i-
crosoft Windows XP operating system, for example, no
A number of structural factors amplify cybersecurity longer receive vital software updates (unless hospitals
threats to medical devices and complicate their pro- or manufacturers pay a high fee to Microsoft) – an issue
tection. As medical devices are increasingly complex which became dramatically visible during the spread of
and interconnected, they need to be considered as the WannaCry ransomware worm.
larger systems, composed by different software and
hardware components. Hence, security mechanisms Lack of (t imely) security patches
need to be implemented across the system with its dif- Once a vulnerability is known, devices need to receive
ferent layers. For example, some of the functionality timely software security updates. Yet, patching medi-
of a medical device might lie outside the device, on a cal devices is much more complicated than patching IT
server. M oreover, security is contextual. A mobile de- desktop systems (see Bellovin 2017; Brook 2017; Nun-
vice like a smart phone can perform critical functions nikoven 2017). Patches bear security risks if they inter-
if it is used in a medical context, for example for mon- act with the use environment in an unforeseen way or
itoring or diagnosis purposes. Therefore, securing med- render systems unavailable. Not only must software up-
ical systems requires coordination of responsibilities dates fix security flaws in a particular software system,
among manufacturers and operators of different sys- they must also ensure that they do not cause any unin-
tem components. tended effects and incompatibilities concerning other
soft- and hardware in the system, including aforemen-
tioned legacy systems. M oreover, if software updates
are not securely deployed, they can also be manipu-
Page 2 of 15DSI Industrial & Policy Recommendations (IPR) Series
Recommendations for safety and IT security in medical devices
lated to channel malicious software into systems. Fi- 1.3 Standards lag behind
nally, responsibilities for update deployment and in-
stallation are not always clear. Hospitals and other M edical device safety is strictly regulated in Europe and
medical device users are often dependent on vendors in other countries. Yet, regulation and standards are
to deploy patches and lose liability claims in case they catching up with digital innovation and have so far in-
upgrade or change devices’ software independently. sufficiently addressed cybersecurity. Hence, regulators
Device original equipment manufacturers (OEM s) in and standardization bodies need to update and extend
turn do not always have access to the software imple- existing frameworks beyond safety requirements to se-
mented in their devices and are dependent on software curity.
suppliers or integrators themselves. Political bodies in the US and more recently in Eu-
rope have started to take action. So far, the FDA has
Propriet ary and opaque soft ware assumed a leading role in this field. It has issued two
M ost medical devices rely on proprietary software. sets of guidelines for cybersecurity in medical devices,
Original equipment manufacturers (OEMs) do not have a pre-market guidance in October 2014 (US Food & Drug
full access to it. M oreover, manufacturers and Administration 2014), and a post-market guidance in
suppliers are rarely transparent regarding third party December 2016 (US Food & Drug Administration 2016).
software components in their products. Hence, They are intended to support manufacturers in ful-
validating the software becomes a difficult task. In filling the requirements of the pre-market approval and
testing terms, OEM s must treat software as a ‘black post-market monitoring processes with respect to
box’. Where software vendors make the software cybersecurity risks throughout a product’s entire
accessible to OEMs or to testing and certification labs, lifecycle.
some security risks, such as known vulnerabilities or However, implementation remains poor. A study by
code errors, can be mitigated. the Ponemon Institute found that only 51 percent of
surveyed device makers follow the FDA’s guidance to
mitigate or reduce inherent security risks in medical
Divergence of safet y and security risk
devices, and only 44 percent of health organizations
assessment s
follow the guidance (Ponemon Institute 2017). The
Risk assessment and testing methods for safety and se-
FDA’s enforcement mechanisms, such as the issuance
curity of control systems have evolved separately over
of recalls and safety notices, as well as liability for de-
time. Safety mechanisms are mainly concerned with
vice failure and reputational damage will raise the cost
unintentional/non-malicious threats caused by natural
of bad security for manufacturers.
disasters, technical failures or human failure. Security
The European Union (EU) and national oversight
mechanisms additionally address intentional/malicious
bodies in Europe have offered little guidance as to how
threats caused by intentional human behavior, for ex-
medical IT security practices and mechanisms should
ample by hackers. When it comes to attacks, security
look like, raising the specter of an uneven regulatory
is a function of a threat agent and its capabilities, in-
patchwork across the continent. Currently, moderate
tent, and motivation. These are dynamic and con-
to high-risk medical devices’ conformity with safety
stantly evolving. Therefore, security risks cannot be
and performance regulatory requirements are evalu-
addressed by static risk assessment and management
ated by certification bodies (so-called ‘notified bod-
methods, such as functional testing for the presence or
ies’, which are accredited private companies) and
absence of specified behavior as well as static risk and
overseen by national authorities. If they conform with
failure rate calculation methods. Attacks on security
the requirements, they obtain a CE (Communauté Eu-
often exploit the existence of unspecified behavior and
ropéenne) label and can be marketed in the entire EU.
are found after the software has been released and is
In M ay 2017, the EU adopted a new M edical Device Reg-
in use in larger systems (Bryans 2017). As a result, the
ulation (M DR), which for the first time specifically re-
security risks need to be managed by the manufacturer
quires manufacturers to develop devices in accordance
after a device has already been marketed. This in-
with “state of the art” IT security requirements. But
cludes the continuous testing of software for vulnera-
the regulation offers little guidance as to how the prac-
bilities and the provision of software updates. As con-
tices and mechanisms to be followed by manufacturers
trol systems in medical devices can be affected by
should look like. This is a problem because standards
cyber attacks, it is increasingly important to address
that combine or complement established criteria for
the combination of safety and security in such modern
the functional safety of medical devices with appropri-
control systems.
ate IT security requirements do not yet exist—so there
is no established definition of what “state of the art”
means for the IT security of medical devices.
Page 3 of 15DSI Industrial & Policy Recommendations (IPR) Series
Recommendations for safety and IT security in medical devices
Therefore, manufacturers and certification bodies in European member states by M ay 2018, requires op-
that evaluate devices for their safety are left to define erators of essential services, including hospitals, to im-
their own medical IT security certification and evalua- plement minimum IT security standards and to notify
tion frameworks. This creates a risk that cybersecurity of security breaches. The EU General Data Protection
standards in health care are fragmenting across Europe Regulation, which EU member states also have to im-
and even within EU member states. plement by M ay 2018, will also apply to software and
Apart from medical device regulation, regulatory medical device vendors, as well as to health organiza-
frameworks for critical infrastructure security and data tions and makes security and privacy by design and de-
protection play important roles for cybersecurity in fault mandatory.
health care. The European Network and Information
Security (NIS) Directive, which has to be implemented
2. Recommendations
2.1 Policy recommendations
Common medical IT security certification Promot ing t ransparency of IT security risks
st andards and incidents
Public authorities, in cooperation with manufacturers European and national medical oversight agencies
and certification bodies, should develop concrete com- should make information about IT security risks and in-
mon European IT security criteria as a component of cidents in medical devices publicly available. At pre-
the medical device certification process. The European sent, national authorities need to submit information
Commission has recently proposed an EU-wide about safety incidents to the European Database on
cybersecurity certification framework that could serve M edical Devices (EUDAM ED), which is only accessible by
as a basis for the certification of security properties of EU institutions and national authorities. Per the M DR,
medical products and processes (European Commission most information submitted to EUDAM ED will be public
2017). Within the framework, medical-device-specific in the future.
schemes and security requirements could serve as a ba- Information about software vulnerabilities concern-
sis for evaluation, testing, and certification of ing medical devices should also be made accessible to
cybersecurity along with other medical system require- all stakeholders. The Common Vulnerability Scoring
ments. Such schemes should be harmonized with other System (CVSS) is useful in assessing the information se-
international standards as much as possible with the curity risk of a vulnerability (in terms of impact on con-
goal of creating internationally applicable schemes fidentiality, integrity, availability). In order to capture
that also lower device vendors’ transaction costs. vulnerabilities’ impacts on systems’ safety and not only
Other guidance can be deduced from international on their security, the CVSS or other vulnerability as-
standards for the secure design and development of sessment systems should be adapted to the safety con-
software components, FDA guidelines, and existing text. The M ITRE Corporation and the FDA have formed
guidelines on Industrial Control Systems (ICS) security. a working group, including medical device manufactur-
ICS properties are in fact similar to those of me dical ers, healthcare providers, and cybersecurity experts,
devices since both are systems in which embedded to develop an approach for using CVSS to score medical
computers control physical devices’ interactions with device vulnerabilities (Carmody and Zuk 2017).
their environments. Hence, the measures used to se-
cure embedded computer systems in ICS are equally Information sharing
applicable in the healthcare context. Examples for European and national decision-makers should incen-
guidance documents include the international draft IEC tivize information sharing about security threats in the
62443 standard series on industrial network and system health care sector. Currently, information sharing is
security, the US National Institute of Standards and fragmented. Safety incidents are reported to national
Technology’s (NIST) ICS Security Guide (NIST 2015), and authorities and collected in the Eudamed database.
the proposed European cybersecurity certification Healthcare organizations classified as “operators of es-
framework for industrial automated control system sential services” under the EU NIS Directive will need
components (European Commission 2016).
Page 4 of 15DSI Industrial & Policy Recommendations (IPR) Series
Recommendations for safety and IT security in medical devices
to report major security incidents to national infor- formation sharing networks can be overseen by an In-
mation security authorities which differ from the med- formation Sharing and Analysis Center (ISAC), a sec-
ical CAs. EU institutions and national authorities as well toral coordinating Computer Emergency Response
as industry should set up an information sharing system Team (CERT), or national CERTs. In the US, for exam-
that supersedes these fragmentations and ensures a ple, a National Health Information Sharing & Analysis
better sharing of threat information within the Center (NH-ISAC) provides threat information and ex-
healthcare sector. It should additionally promote the change services.
exchange of threat information with other sectors. In-
2.2 Recommendations for
manufacturers and suppliers
Health care is a critical infrastructure. Hospitals, as minimum, and isolate safety critical system compo-
critical infrastructure operators, and other medical de- nents from other potentially vulnerable components
vice users are responsible for securely operating medi- within the devices.
cal devices within their networks. As mentioned pre-
viously, they are regulated under the EU NIS Directive Int egrated safety and security risk assessment
and the GDPR. The standard IEC 80001 offers guidance M anufacturers as well as notified certification bodies
on the applic ation of risk management for IT networks should apply integrated safety and security risk assess-
incorporating medical devices for health organizations. ment and management methods to medical devices.
Within their organizations, hospitals should integrate Research in this field has presented a number of inte-
the management of medical devices, which has tradi- grated risk assessment methods for (industrial) control
tionally been the task of biomedical technicians, and systems that can complement established medical de-
networks, which has traditionally been under the aus- vice risk management standards, for example the
pices of the IT department. SAHARA or Unified Security and Safety Risk Assessment
The ultimate responsibility for medical device M ethods (Chockalignam et al., 2016). The aforemen-
safety lies with their manufacturers. Per EU liability tioned FDA pre-market cybersecurity guidelines as well
law, original equipment manufacturers (OEM s) are held as the IEC 62433 standard offer additional guidance in
liable for harm caused by a defective product. In order this field.
to mitigate cybersecurity risks as far as possible, man-
ufacturers should implement a number of security re- Transparency about device security and risks
lated pre-market practices (before the device is mar- Device manufacturers and vendors should transpar-
keted) and post-market management mechanisms for ently declare how their devices fulfill medical IT secu-
monitoring, vulnerability handling, and information rity requirements. The manual for devices should not
sharing. only include directions for their use, but also a threat
Several medical device makers have adopted effec- model of the device in use contexts to clearly demon-
tive processes to implement cybersecurity in devices strate the risks of the device’s use. This would give de-
throughout their life cycle, including responsible patch vice operators and users the necessary information
management and disclosure programs (Draeger 2017; about security trade-offs and the ability to decide
Siemens Healthineers 2017). These can serve as exam- about related risks.
ples in the industry. Software and hardware suppliers should be equally
transparent and explain the security mechanisms and
Security by design threat models of their software and the effects of its
IT security should not be an afterthought, rather it use in a device.
should be designed into the devices from the start. The
design of medical devices should follow proven secure Pat ch management
lifecycle standards and secure supply chain manage- M anufacturers should operate an effective and usable
ment practices. All off-the-shelf hard- and software in- patch management system. Once a vulnerability is
tegrated into devices should be trustworthy and pro- known, devices need to receive timely software secu-
vide high technological assurance. M anufacturers rity updates. Since software updates themselves bear
should reduce devices’ connectivity to the necessary security risks, they should be tested in use environ-
ments before being deployed. M oreover, device makers
Page 5 of 15DSI Industrial & Policy Recommendations (IPR) Series
Recommendations for safety and IT security in medical devices
need to implement secure channels for the deployment encouraging. Standards ISO/IEC 29147: Information
of updates in order to prevent their manipulation. Technology – Security Techniques – Vulnerability disclo-
sure and ISO/IEC 30111:2013 Information Technology –
Vulnerability reporting Security Techniques – Vulnerability handling processes
M anufacturers should operate a vulnerability reporting provide guidelines for manufacturers and their adop-
program through which they collaborate with third par- tion should be promoted by public institutions.
ties who discover software security flaws. M any medi-
cal device manufacturers, including Siemens, Draeger,
M edtronic, and Philips, have implemented coordinated
vulnerability disclosure programs throughout the past
years (I am the Cavalry 2017). These developments are
3. References
Bellovin, S.M . (2017). Patching is hard. SM Blog. and of the Council. https://ec.europa.eu/digital-sin-
https://www.cs.columbia.edu/~smb/blog/2017- gle-market/en/eu-cybersecurity-certification-frame-
05/2017-05-12.html (accessed October 30, 2017). work (accessed October 30, 2017).
Brook, C. (2017). Patches pending for medical devices Filkins, B. (2014). Healthcare c yberthreat report:
Widespread compromises detected, compliance night-
hit by WannaCry. Threatpost, M ay 18. https://threat-
mare on the horizon. SANS Institute InfoSec Reading
post.com/patches-pending-for-medical-devices-hit- Room. https://www.sans.org/reading-room/whitepa-
by-wannacry/125758/ (accessed October 30, 2017). pers/analyst/health-care-cyberthreat-report-wide-
spread-compromises-detected-compliance-nightmare-
Bryans, J. W. (2017). The internet of automotive horizon-34735 (accessed October 30, 2017).
things: Vulnerabilities, risks and policy implications.
Journal of Cyber Policy 2 (2): 185-194. Fox-Brewster, T. (2017). M edical devices hit by ran-
somware for the first time In US hospitals. Forbes,
Burleson, W., S. Clark, B. Ransford, and K. Fu. (2012).
Design challenges for secure implantable medical de- M ay 17. http://www.forbes.com/sites/thomasbrew-
vices. DAC, June 3-7, San Francisco, California, USA. ster/2017/05/17/wannacry-ransomware-hit-real-med-
ical-devices/ (accessed October 30, 2017).
Carmody, S. and M . Zuk. (2017). The evolving state of
medical device cybersecurity. HIMSS Annual Confer- Halperin, D.,Heydt-Benjamin, B. Ransford, S. Clark, B.
ence, Feb 19-23. http://www.himssconfer- Defend, W. M organ, K. Fu, T. Kohno and W. M aisel.
ence.org/sites/himssconfer- (2008). Pacemakers and Implantable Cardiac Defibril-
ence/files/pdf/16FINAL.pdf (accessed October 30,
lators: Software Radio Attacks and Zero Power De-
2017)
fenses. IEEE Symposium on Security and Privacy.
Chockalingam, S., D. Hadžoismanović, W. Pieters, A.
Teixera, and P. van Gelder. (2016). Integrated safety I Am The Cavalry (2017). An overview of vulnerability
and security risk assessment methods: A survey of key disclosure programs. https://www.iamthecav-
characteristics and applications. The 11th Interna- alry.org/resources/disclosure-programs/ (accessed
tional Conference on Critical Infrastructure Security. December 7, 2017).
Draeger (2017). Cybersecurity. https://www.drae- ICS-CERT (2017). Indicators associated with WannaCry
ger.com/en_uk/Hospital/Insights-to-Solutions/Cyber- ransomware (Update I). M ay 15. https://ics-cert.us-
security (accessed December 7, 2017).
cert.gov/alerts/ICS-ALERT-17-135-01I (accessed Octo-
European Commission. (2016). Introduction to the Eu- ber 30, 2017).
ropean IACS components Cybersecurity Certification
Framework (ICCF). https://erncip-project.jrc.ec.eu- Independent Security Evaluators. (2016). Hacking hos-
ropa.eu/documents/introduction-european-iacs-com- pitals. February 23. https://www.securityevalua-
ponents-cybersecurity-certification-framework-iccf tors.com/hospitalhack/securing_hospitals.pdf (ac-
(accessed October 30, 2017). cessed October 30, 2017).
European Commission. (2017). COM (2017) 477 final. Johnson, C. (2012). CyberSafety: O n the interactions
between cybersecurity and the software engineering
The EU cybersecurity certification framework. Pro-
of safety-critical systems. In Achieving system safety,
posal for a Regulation of the European Parliament ed. C. Dale and T. Anderson. London: Springer Verlag.
Page 6 of 15DSI Industrial & Policy Recommendations (IPR) Series
Recommendations for safety and IT security in medical devices
Rios, B. and J. Butts. (2017). Security evaluation of
Leverett, E., R. Clayton, and R. Anderson. (2017). the implantable cardiac device ecosystem and archi-
Standardisation and c ertification in the ‘Internet of tecture and implementation interdependencies.
Things’. 16th Annual Workshop on the Economics of In- WhiteScope Security Report, M ay 17.
formation Security (WEIS). http://weis2017.econin- https://drive.google.com/file/d/0B_GspGER4QQTYkJf
fosec.org/wp-content/up- aVlBeGVCSW8/view (accessed August 31, 2017).
loads/sites/3/2017/05/WEIS_2017_paper_23.pdf Roland Berger Consultants (2016). Digital healthcare
(accessed October 30, 2017). market to average 21 percent growth per year through
2020. September 28. https://www.roland-
Li, C., A. Raghunathan, and N. K. Jha. (2011). Hijack- berger.com/en/press/Digital-health-market-to-aver-
ing an insulin pump: Security attacks and defences for age-21-percent-growth-per-year-through-2020.html
a diabetes therapy system. Proceedings of the 13th (accessed October 30, 2017).
IEEE International Conference on e-Health Network-
ing, Applications, and Services, Healthcom ‘11. Siemens Healthineers (2017). Cybersecurity at Sie-
mens Healthineers. https://www.healthcare.sie-
M arin E., D. Singelée, F. D. Garcia, T. Chothia, R. Wil- mens.com/medical-imaging-it/cybersecurity (ac-
lems, and B. Preneel. (2016). On the (in)security of cessed December 7, 2017).
the latest generation implantable cardiac defibrilla-
tors and how to secure them. ACSAC '16 Proceedings US Food & Drug Administration (2014). Content of pre-
of the 32nd Annual Conference on Computer Security market submissions for management of cybersecurity
Applications: 226-236. https://www.esat.ku- in medical devices. Guidance for industry and Food
leuven.be/cosic/publications/article-2678.pdf (ac- and Drug Administration staff.
cessed 30 September, 2017). https://www.fda.gov/downloads/M edicalDevices/De-
viceRegulationandGuidance/GuidanceDocu-
National Institute for Standards and Technology ments/UCM 356190.pdf (accessed October 30, 2017).
(2015). SP 800-82, Revision 2. Guide to industrial con-
trol systems (ICS) security. US Food & Drug Administration (2016). Postmarket
management of cybersecurity in medical devices.
Nunnikhoven, M . (2017). WannaCry & the reality of Guidance for industry and Food and Drug Administra-
patching, 14 M ay. Retrieved from tion staff. https://www.fda.gov/downloads/M edi-
http://blog.trendmicro.com/wannacry-reality-of- calDevices/DeviceRegulationandGuidance/Guid-
patching/ (accessed October 30, 2017). anceDocuments/UCM482022.pdf (accessed October
30, 2017).
Ponemon Institute. (2017). M edical device security:
An industry under attack and unprepared to defend. US Food & Drug Administration (2017). Firmware up-
https://www.synopsys.com/content/dam/synop- date to address cybersecurity vulnerabilities identi-
sys/sig-assets/reports/medical-device-security- fied in Abbott’s (formerly St. Jude M edical’s) implant-
ponemon-synopsys.pdf (accessed October 30, 2017). able cardiac pacemakers. FDA Safety Communication,
August 29. https://www.fda.gov/M edi-
Radcliffe, J. (2011). Hacking medical devices for fun calDevices/Safety/AlertsandNotices/ucm573669.htm
and insulin: Breaking the human SCADA system. Black (accessed August 31, 2017).
Hat Conference 2011.
The DSI Industrial & Policy Recommendations (IPR) Series is published by the Digital Society Institute of ESMT Berlin,
http://dsi.esmt.org.
© 2017 ESM T European School of M anagement and Technology GmbH.
This paper may be distributed freely according to the CreativeCommons license Attribution-NonCommercial-NoDe-
rivatives 4.0 International. https://creativecommons.org/licenses/by-nc-nd/4.0/
Page 7 of 15DSI Industrial & Policy Recommendations (IPR) Series
Empfehlungen zur Cybersicherheit von
Medizingeräten
Isabel Skierka (Digital Society Institute, ESM T Berlin)
Ausgabe 6, 2017
Die Gesundheitsversorgung durchläuft einen digita- dass Cybersicherheitsrisiken in der Gesundheitsver-
len Wandel. M edizingeräte - ob im Körper der Pati- sorgungen mittlerweile systemisch sind. Nicht nur
enten implantiert oder in Krankenhäusern statio- die Auswirkung von Cyber-Angriffen auf die Pri-
niert – und ganze Krankenhäuser sind immer vatsphäre von Patientendaten, sondern auch auf
‚smarter‘ vernetzt, Arbeitsprozesse laufen fast aus- Leib und Leben der Patienten bereitet Gesundheits-
schließlich sofware-basiert ab. Die vernetzte M edi- organisationen, Regulierungsbehörden und Herstel-
zin kann eine sicherere, effizientere und schnellere lern von M edizinprodukten Kopfzerbrechen. Wie
Versorgung bieten. Auch die wirtschaftlichen dieses Papier zeigt, erfordert der Umgang der damit
Wachstumsc hancen der Gesundheitsbranche stei- verbundenen Risiken umfassende Standardisierung,
gen. Laut einer Studie der Unternehmensberatung Regulierung und Best Practices, die sowohl Safety-
als auch IT-Sicherheitsmechanismen umfassen.
Roland Berger (2016) soll der digitale Gesundheits-
Die nachfolgende Analyse und Empfehlungen
markt bis 2020 durchschnittlich um 21 Prozent pro
basieren auf einer Literaturanalyse,
Jahr wachsen.
Experteninterviews und den Ergebnissen eines DSI
Die Integration von Computer- und Kommunika-
Workshops am 18.10.2017 in Berlin, an dem
tionstechnologien in sicherheitskritische medizini-
Vertreter von Gesundheitsorganisationen,
sche Systeme birgt jedoch auch Cybersicherheitsri-
M edizinprodukteherstellern, IT-Sicherheits-
siken. Die Ergebnisse mehrerer IT-
experten, Konformitätsbewertungsstellen und
Sicherheitsstudien und auch reale Vorfälle haben
Regulierungsbehörden teilnahmen.
über die vergangenen Jahre hinweg verdeutlicht,
1. Ausgangslage
ein Angreifer so die Frequenz der Impulse kontrol-
lieren oder die Batterie des Geräts erschöpfen und
1.1 Cybersicherheits-Vorfälle damit den Stillstand des Schrittmachers einleiten
können. Die potentiellen Folgen wären fatal. Infolge
in Medizingeräten
des Rückrufs mussten alle Patienten, die eines der
Seit etwa einem Jahrzehnt warnen Forscher vor gra- betroffenen Herzschrittmacher-Modelle im Körper
vierenden Cybersicherheits-Mängeln in M edizingerä- tragen, ihre Ärzte aufsuchen um ein Firmware-Up-
ten. Am 29. August 2017 leitete die US- date zur Behebung der Sicherheitsmängel zu erhal-
amerikanische Arzneimittelbehörde Food and Drug ten. Weltweit sind etwa 745.000 M enschen betrof-
Administration (FDA) zuletzt einen Rückruf von fen.
knapp einer halben M illion Herzschrittmacher des Das regelmäßige Patchen von Cybersicherheits-
Herstellers Abbott Laboratories ein (US Food & Drug lücken kennen die meisten M enschen nur von ihren
Administra-tion 2017). Der Behörde lagen Ergeb- Desktop IT-Systemen. Doch in Zukunft wird auch das
nisse vor, nach denen Hacker sich durch Sicherheits- regelmäßige Patching von M edizingeräten, Autos o-
lücken im Schrittmacher lebensbedrohlichen Zugriff der Haushaltsgeräten zur Gewohnheit werden.
auf die Funktionen des Geräts hätten verschaffen Der Abbott-Herzschrittmacher-Rückruf ist nur
können. Unter Ausnutzung der Schwachstelle hätte der jüngste aus einer Reihe von Vorfällen. Obwohl
Page 8 of 15DSI Industrial & Policy Recommendations (IPR) Series
Empfehlungen zur Cybersicherheit von Medizingeräten
bisher kein einziger bekannter Sicherheitsvorfall in
1.2 Strukturelle Hürden
einem Herzschrittmacher oder einer Insulinpumpe
einen Todesfall verursacht hat, haben mehrere For- Eine Reihe von strukturellen Faktoren verstärken
scher gezeigt, dass dies möglich ist. Im Jahr 2008 die Cybersicherheitsgefahren für Medizingeräte und
demonstrierte ein Forscherteam erstmals Angriffe erschweren deren Schutz. Da M edizinprodukte im-
auf implantierbare Herz-Defibrillatoren. M it Hilfe mer komplexer und vernetzter werden, müssen sie
eines kommerziell erhältlichen Geräteprogrammie- als Systeme betrachtet werden, die sich aus ver-
rers war es dem Team möglich, die privaten Daten schiedenen Soft- und Hardwarekomponenten zu-
eines Patienten zu extrahieren und den Herzschritt- sammensetzen. Daher müssen Sicherheitsmechanis-
macher so umzuprogrammieren, dass er den Dienst men systemübergreifend innerhalb der
verweigerte (Halperin et al., 2008). verschiedenen Ebenen implementiert werden. Bei-
Seitdem haben mehrere Forscher und IT- spielsweise könnte ein Teil der Funktionalität eines
Sicherheitsexperten verschiedene Möglichkeiten für M edizinprodukts außerhalb des Geräts auf einem
das Hacken von Herzschrittmachern und Insulinpum- Server liegen. Darüber hinaus ist Sicherheit kontext-
pen aufgezeigt (Burleson et al., 2012; Li, Rag- abhängig. Ein mobiles Endgerät wie ein Smartphone
hunathan und Jha 2011; M arin et al., 2016; Radcliffe kann kritische Funktionen übernehmen, wenn es im
2011). Im M ai 2017 entdeckten Forscher des Sicher- medizinischen Kontext, das heißt zu Überwachungs-
heitsunternehmens WhiteScope insgesamt 8.665 of- oder Diagnosezwecken, eingesetzt wird. Die Absi-
fene und bekannte Schwachstellen in Software-Bib- cherung medizinischer Systeme erfordert daher eine
liotheken von Drittanbietern, die über vier Koordination der Verantwortlichkeiten zwischen
verschiedene Schrittmacher-Programmierer von Herstellern und Betreibern verschiedener System-
vier verschiedenen Herstellern implementiert wur- komponenten.
den (Rios und Butts 2017). Diese Software-Bibliothe-
ken lassen sich meist nicht mehr im implantierten Kompromisse zwischen „Safety“,
Gerät updaten. Das ist ein Designfehler extremen Cy bersicherheit und anderen grundlegenden
Ausmaßes. Sy st emanforderungen
Nicht nur implantierbare sondern auch statio- Die Sicherung von M edizingeräten gegen Cyber-An-
näre Geräte im Krankenhaus sind anfällig für Ha- griffe oder –vorfälle ist nicht trivial. Geräte müssen
cker-Angriffe. Ein Bericht des SANS-Instituts aus mehrere, nicht immer kompatible Systemanforde-
dem Jahr 2014 kommt zu dem Schluss, dass 94 Pro- rungen erfüllen, wobei Cybersicherheit nur eine ist.
zent aller Gesundheitsorganisationen in den USA Op- Vor allem müssen Geräte in ihrer Einsatzumgebung
fer eines Cyber-Angriffs geworden sind, betroffen – dem menschlichen Körper oder auf einer Kranken-
waren auch medizinische Geräte und Infrastruktu- hausstation – uneingeschränkt wie intendiert funkti-
ren (Filkins 2014). Andere Berichte zeigen, wie Ha- onieren um Leib und Leben des Patienten zu schüt-
cker verwundbare M edizingeräte gezielt als Einfalls- zen („Safety“). Die meisten medizinischen Geräte
tore in Krankenhausnetzwerke nutzen um sensible sind auf eingebettete Computersysteme angewie-
Daten zu erbeuten (Independent Security Evaluators sen, die in ihrer Rechenleistung, ihrem Speicher und
2016). Der Ransomware-Wurm „WannaCry“, wel- ihrem Energieverbrauch eingeschränkt sind. Cyber-
cher im M ai 2017 die Netzwerke vieler global agie- sicherheitsmechanismen wie Verschlüsselungs- oder
render Konzerne infizierte, befiel auch zahlreiche Authentifizierungsmaßnahmen können den Betrieb
M edizingeräte in Krankenhäusern. Der Vorfall veran- verlangsamen, die Batterielaufzeit verkürzen oder
lasste das US Industrial Control System Computer Geräte in Notsituationen unzugänglich machen. Dar-
Emergency Response Team (ICS-CERT) und mehrere über hinaus können generische Sicherheitskontrol-
Hersteller medizinischer Geräte, Sicherheitswar- len wie Passwort-Zugriffskontrollen die Benutzer-
nungen über gefährdete Geräte zu veröffentlichen freundlichkeit in schnelllebigen klinischen
(ICS-CERT 2017). Umgebungen beeinträchtigen. Daher müssen Sicher-
Diese und andere Beispiele zeigen, dass Cybersi- heitsmechanismen nicht nur sicher, sondern auch
cherheitsrisiken im Gesundheitswesen systemisch nutzbar, effizient und mit den einzigartigen Gege-
sind. Vielen M edizinprodukten fehlen sogar grundle- benheiten dieser Systeme kompatibel sein.
gende Sicherheitseigenschaften. Die daraus resul- Die damit verbundenen Dilemmata sind Gegen-
tierenden Risiken werden externalisiert. Leider kön- stand einer zunehmenden Anzahl von Forschungsar-
nen die am stärksten betroffenen Parteien - die beiten und Vorschlägen für innovative Verschlüsse-
Patienten selbst - wenig tun, um die Sicherheit der lungs- und Authentifizierungslösungen. Bislang hat
Geräte, von denen ihre eigene Gesundheit abhängt, sich jedoch keines dieser Systeme als sicher genug
zu verbessern. gegen spezialisierte Angriffe erwiesen (für einen
Überblick siehe M arin et al., 2016).
Page 9 of 15DSI Industrial & Policy Recommendations (IPR) Series
Empfehlungen zur Cybersicherheit von Medizingeräten
Lebenszy kluskonflikte implementierte Software und sind von Software-Lie-
Die Lebensdauer von M edizingeräten (etwa 10 bis 30 feranten oder Integratoren abhängig.
Jahre) ist länger als die unterstützte Lebensdauer
der meisten Betriebssysteme und Anwendungssoft- Propriet äre und undurchsichtige Soft ware
ware. Diese Diskrepanz führt dazu, dass Software im Die meisten medizinischen Geräte sind auf proprie-
Laufe der Lebensdauer eines Geräts in der Regel täre Software angewiesen. Auch Gerätehersteller
veraltet und nicht mehr unterstützt wird. Da die haben oft keinen uneingeschränkten Zugriff auf die
Wiederverwendung von Hard- und Softwaresyste- Software. Darüber hinaus sind Hersteller und Zulie-
men in medizinischen Geräten weit verbreitet ist, ferer selten transparent, was Softwarekomponenten
ist ein M edizinprodukt in der Regel eine M ischung von Drittanbietern in ihren Produkten betrifft. Die
aus neuen und alten Systemen („legacy Systeme“). Validierung der Software ist daher eine schwierige
Außerdem ist es möglich, dass „legacy“ Systeme Aufgabe. In Bezug auf das Testen müssen Konformi-
nicht mehr mit neueren Systemen interoperabel tätsstellen und Hersteller Software oft als eine
sind. Dadurch entstehen Schwachstellen wie Fehl- "Black Box" betrachten. Um Sicherheitsrisiken zu mi-
konfigurationen und Sicherheitslücken. M edizini- nimieren, müssen Softwareanbieter die Software
sche Geräte, die auf dem veralteten Betriebssystem Herstellern und Test- und Zertifizierungslaboren
M icrosoft Windows XP laufen, erhalten beispiels- transparent zugänglich machen.
weise keine Software-Updates mehr (es sei denn,
Nutzer zahlen eine hohe Gebühr an den Hersteller Divergenzen bei der Bewert ung von Sicher-
M icrosoft). Während der Verbreitung des WannaCry- heit srisiken
Wurms, der eine Schwachstelle in Windows-Be- Risikobewertungs- und Testmethoden für die „Sa-
triebssystemen ausnutzte, wurden die Konsequen- fety“ (funktionale Sicherheit) und Cybersicherheit
zen fehlender Sicherheits-Updates deutlich. von Kontrollsystemen haben sich im Laufe der Zeit
separat entwickelt. „Safety“-M echanismen befas-
Verzögerte oder fehlende Sicherheits- sen sich hauptsächlich mit unbeabsichtigten/nicht
Updat es schädlichen Bedrohungen, die durch Naturkatastro-
Sobald eine Schwachstelle bekannt ist, muss die phen, technische Ausfälle oder menschliches Versa-
Software in betroffenen Geräten rechtzeitig ein Si- gen verursacht werden.
cherheitsupdate erhalten. Doch das „Patchen“ von IT-Sicherheitsmechanismen adressieren zusätz-
medizinischen Geräten ist viel komplizierter als von lich vorsätzliche Bedrohungshandlungen. Das Aus-
IT-Desktop-Systemen (siehe Bellovin 2017; Brook maß der Bedrohung hängt vom Bedrohungsakteur
2017; Nunnikoven 2017). Patches selbst bergen Si- und seinen Fähigkeiten, Absichten und seiner M oti-
cherheitsrisiken, wenn sie auf unvorhergesehene vation ab. Cyberbedrohungen sind dynamisch und
Weise mit der Nutzungsumgebung interagieren oder entwickeln sich ständig weiter. Daher können IT-
die Verfügbarkeit von Systemen beeinträchtigen. Sicherheitsrisiken nicht durch statische Risikobe-
Software-Updates müssen nicht nur Sicherheitsmän- wertungs- und -management-M ethoden, wie zum
gel in einem bestimmten Softwaresystem beheben, Beispiel Funktionstests auf das Vorhandensein oder
sie müssen auch sicherstellen, dass sie keine unbe- Nichtvorhandensein von spezifiziertem Verhalten
absichtigten Auswirkungen und Inkompatibilitäten sowie statische Risiko- und Ausfallratenberech-
in Bezug auf andere Soft- und Hardware im System, nungsmethoden, bekämpft werden. Angriffe auf die
einschließlich der oben genannten „legacy“ Sys- Sicherheit nutzen oft die Existenz von unspezifizier-
teme, verursachen. Darüber hinaus können Soft- tem Verhalten aus und werden erst gefunden, nach-
ware-Updates, wenn sie nicht auf einem sicheren dem die Software veröffentlicht wurde und in grö-
Weg bereitgestellt werden (auf einem gesicherten ßeren Systemen im Einsatz ist (Bryans 2017). Daher
Server verfügbar, signiert, sicher an das Gerät über- müssen die Sicherheitsrisiken vom Hersteller gema-
tragen), auch manipuliert werden, um schädliche nagt werden, nachdem ein Gerät in Verkehr ge-
Software in Systeme zu leiten. Außerdem sind die bracht wurde. Dazu gehört das kontinuierliche Tes-
Verantwortlichkeiten für die Bereitstellung und In- ten von Software auf Schwachstellen und die
stallation von Updates nicht immer deutlich. Kran- Bereitstellung von Software-Updates. Da Kontroll-
kenhäuser und andere Anwender medizinischer Ge- systeme in M edizinprodukten von Cyber-Attacken
räte sind oft darauf angewiesen, dass die Hersteller betroffen sein können, wird es immer wichtiger, die
Patches bereitstellen und verlieren Haftungsansprü- Kombination von „Safety“ und IT-Sicherheit zu be-
che, falls sie selbstständig Änderungen an der Gerä- rücksichtigen.
tesoftware vornehmen. Gerätehersteller wiederum
haben nicht immer Zugriff auf die in ihren Geräten
Page 10 of 15DSI Industrial & Policy Recommendations (IPR) Series
Empfehlungen zur Cybersicherheit von Medizingeräten
von Konformitätsbewertungsstellen (sogenannte
1.3 Regulierung und Standards
"Benannte Stellen", die akkreditierte Privatunter-
hinken hinterher nehmen sind) bewertet und von nationalen Behör-
den überwacht. Wenn sie den Anforderungen ent-
Die „Safety“ von M edizinprodukten ist in Europa und
sprechen, erhalten sie ein CE-Zeichen (Communauté
in anderen Ländern strikt reguliert. Dennoch sind
Européenne) und können in der gesamten EU ver-
viele gesetzliche Regeln und Standards von der digi-
marktet werden. Im M ai 2017 verabschiedete die EU
talen Innovation überholt. Daher müssen Regulie-
eine neue M edizinprodukteverordnung (M DR), wel-
rungsbehörden und Normungsgremien die bestehen-
che die Hersteller erstmals ausdrücklich dazu ver-
den Rahmenbedingungen über die „Safety“-
pflichtet, Geräte nach dem „Stand der Technik“ der
anforderungen hinaus aktualisieren und auf die IT-
IT-Sicherheitsanforderungen zu entwickeln. Die
Sicherheit ausweiten.
Verordnung bietet jedoch wenig Anhaltspunkte da-
Politische Gremien in den USA und in jüngster
für, wie die von den Herstellern zu befolgenden
Zeit auch in Europa haben begonnen Cybersicher-
Praktiken und M echanismen aussehen sollten. Denn
heit aktiv anzugehen. Die amerikanische FDA hat in
Standards, die etablierte Kriterien für die funktio-
diesem Bereich eine führende Rolle übernommen.
nale Sicherheit (Safety) von M edizinprodukten mit
Sie hat zwei Richtlinien für die Cybersicherheit von
entsprechenden IT-Sicherheitsanforderungen kom-
M edizinprodukten herausgegeben, eine Pre-Market
binieren oder ergänzen, gibt es noch nicht - und so
Guidance im Oktober 2014 (US Food & Drug Admi-
gibt es auch keine etablierte Definition dafür, was
nistration 2014) und eine Post-M arket Guidance im
der „Stand der Technik“ für die IT-Sicherheit von
Dezember 2016 (US Food & Drug Administration
M edizinprodukten bedeutet.
2016). Sie sollen die Hersteller dabei unterstützen,
Hersteller und Konformitätsbewertungsstellen,
die Anforderungen der Zulassungs- und Post-Market-
die Geräte auf ihre Sicherheit überprüfen, müssen
Überwachungs-Prozesse im Hinblick auf Cybersi-
daher ihre eigenen Zertifizierungs- und Bewertungs-
cherheitsrisiken über den gesamten Lebenszyklus
rahmen für die medizinische IT-Sicherheit definie-
eines Produkts zu erfüllen.
ren. Dies birgt die Gefahr, dass die Cybersicher-
Die Umsetzung scheint jedoch mangelhaft. Eine
heitsstandards im Gesundheitswesen in ganz Europa
Studie des Ponemon-Instituts ergab, dass nur 51 Pro-
und sogar innerhalb der EU-M itgliedsstaaten immer
zent der befragten Gerätehersteller den Richtlinien
weiter auseinanderbrechen.
der FDA folgen, um inhärente Cybersicherheitsrisi-
Neben der Regulierung von M edizinprodukten
ken in M edizinprodukten zu mindern oder zu redu-
spielen regulatorische Rahmenbedingungen für die
zieren und nur 44 Prozent der Gesundheitsorganisa-
Sicherheit kritischer Infrastrukturen und den Daten-
tionen den Richtlinien folgen (Ponemon Institute
schutz eine wichtige Rolle für die Cybersicherheit
2017). Die Durchsetzungsmechanismen der FDA, wie
im Gesundheitswesen. Die europäische Richtlinie
zum Beispiel die Einleitung von Rückrufen und Ver-
zur Netzwerk- und Informationssicherheit (NIS-
öffentlichung von Sicherheitshinweisen, sowie die
Richtlinie), die in den europäischen Mitgliedstaaten
Haftung für Geräteausfälle und Reputationsschäden
bis M ai 2018 umgesetzt werden muss, verpflichtet
werden zukünftig die Kosten für mangelnde Cyber-
Betreiber kritischer Infrastrukturen, darunter Kran-
sicherheit für die Hersteller erhöhen.
kenhäuser, zur Umsetzung von IT-M indeststandards
Die Europäische Union (EU) und die nationalen
und zur M eldung von Sicherheitsverletzungen. Die
Aufsichtsbehörden in Europa haben bisher wenige
EU-Datenschutzgrundverordnung, die die EU-
Hinweise für die Implementierung von Cybersicher-
M itgliedsstaaten ebenfalls bis M ai 2018 umsetzen
heitsmechanismen in M edizingeräten gegeben.
müssen, gilt auch für Software- und M edizinpro-
Ohne einheitliche europäische Standards droht ein
duktehersteller sowie für Gesundheitsorganisatio-
Flickenteppich von unterschiedlichen Prüfmaßnah-
nen und schreibt Sicherheit und Privacy „by design
men und Sicherheitsniveaus von Geräten diesem Be-
and default“ gesetzlich vor.
reich. Derzeit wird die Konformität von M edizinpro-
dukten mittlerer bis hoher Risiken mit den
sicherheits- und leistungsrechtlichen Anforderungen
Page 11 of 15DSI Industrial & Policy Recommendations (IPR) Series
Empfehlungen zur Cybersicherheit von Medizingeräten
2. Empfehlungen
Sicherheitsrisiken und Vorfälle in M edizingeräten öf-
fentlich zugänglich machen. Derzeit müssen die na-
tionalen Behörden Informationen über sicherheits-
2.1 Empfehlungen an
relevante Vorkommnisse an die Europäische
politische Entscheidungsträger Datenbank für M edizinprodukte (Eudamed) übermit-
teln, die nur für EU-Institutionen und nationale Be-
Gemeinsame Standards für die hörden zugänglich ist. Laut M DR werden die meisten
Zert ifizierung medizinischer IT -Sicherheit Informationen, die an Eudamed übermittelt wer-
Behörden sollten in Zusammenarbeit mit Herstellern den, in Zukunft öffentlich zugänglich sein.
und Zertifizierungsstellen konkrete gemeinsame eu- Informationen über Software-Schwachstellen in
ropäische IT-Sicherheitskriterien als Bestandteil des Bezug auf M edizinprodukte sollten auch für alle Sta-
Zertifizierungsprozesses für Medizinprodukte entwi- keholder zugänglich gemacht werden. Das Common
ckeln. Die Europäische Kommission hat kürzlich ei- Vulnerability Scoring System (CVSS) ist nützlich bei
nen EU-weiten Zertifizierungsrahmen für die Cyber- der Bewertung des Informationssicherheitsrisikos ei-
sicherheit vorgeschlagen, der als Grundlage für die ner Schwachstelle (in Bezug auf die Auswirkungen
Zertifizierung von Sicherheitseigenschaften von Me- auf Vertraulichkeit, Integrität und Verfügbarkeit).
dizingeräten und -prozessen dienen könnte (Euro- Um die potenziellen Auswirkungen von Schwachstel-
pean Commission 2017). Innerhalb dieses Schemas len auf die Systemsicherheit zusätzlich zur funktio-
könnten medizintechnische Systeme und Sicher- nalen Sicherheit („Safety“) zu erfassen, sollten CVSS
heitsanforderungen als Grundlage für die Bewer- oder andere Schwachstellenbewertungssysteme an
tung, Prüfung und Zertifizierung der Cybersicher- den Cybersicherheitskontext angepasst werden. Die
heit sowie anderer medizinischer M ITRE Corporation und die FDA haben eine Arbeits-
Systemanforderungen dienen. Solche Systeme soll- gruppe gebildet, in der Hersteller von M edizinpro-
ten so weit wie möglich mit internationalen Stan- dukten, Anbieter von Gesundheitsdienstleistungen
dards harmonisiert werden und somit international und Cybersicherheitsexperten gemeinsam einen An-
anwendbare Systeme schaffen, die auch die Trans- satz für die Verwendung von CVSS zur Bewertung
aktionskosten der Gerätehersteller senken. von Schwachstellen bei M edizinprodukten entwi-
Weitere Hinweise lassen sich aus internationalen ckeln (Carmody und Zuk 2017).
Standards für das sichere Design und die Entwick-
lung von Softwarekomponenten, FDA-Richtlinien Informationsaustausch
und bestehenden Richtlinien zur Sicherheit von in- Europäische und nationale Entscheidungsträger soll-
dustriellen Kontrollsystemen (ICS) ableiten. Die Ei- ten sich für einen besseren Informationsaustausch
genschaften von ICS sind in der Tat vergleichbar mit über Cybersicherheitsbedrohungen im Gesundheits-
denen von M edizinprodukten, da es sich bei beiden wesen einsetzen. Derzeit ist die gemeinsame Nut-
um Systeme handelt, in denen eingebettete Compu- zung von Informationen fragmentiert. Sicherheits-
ter die Wechselwirkungen physikalischer Geräte mit zwischenfälle werden den nationalen Behörden
ihrer Umgebung steuern. Die M aßnahmen zur Siche- gemeldet und in der Eudamed-Datenbank gesam-
rung von eingebetteten Computersystemen im in- melt. Gesundheitsorganisationen, die nach der EU-
dustriellen Kontext sind daher auch im Gesundheits- NIS-Richtlinie als „Betreiber kritischer Infrastruktu-
wesen anwendbar. Beispiele für Leitfäden sind der ren“ eingestuft sind, müssen größere Sicherheits-
internationale Entwurf der Normreihe IEC 62443 zur vorfälle an nationale Informationssicherheitsbehör-
industriellen Netzwerk- und Systemsicherheit, der den melden, die sich von den medizinischen CAs
unterscheiden. EU-Institutionen und nationale Be-
ICS Security Guide (NIST 2015) des US National Insti-
hörden sowie die Industrie sollten ein Informations-
tute of Standards and Technology (NIST) und der
austauschsystem einrichten, das einen besseren
vorgeschlagene europäische Zertifizierungsrahmen
Austausch von Informationen über Bedrohungen im
für die Cybersicherheit von Komponenten industri-
Gesundheitssektor gewährleistet. Außerdem sollte
eller automatisierter Steuerungssysteme (Europäi-
sie den Austausch von Informationen über Bedro-
sche Kommission 2016). hungen mit anderen Sektoren fördern. Der Informa-
tionsaustausch könnte über ein neutrales Informa-
Förderung der Transparenz von IT- tion Sharing and Analysis Center (ISAC), ein
Sicherheitsrisiken und -vorfällen sektorales koordinierendes Computer Emergency
Europäische und nationale medizinische Aufsichts- Response Team (CERT) oder nationale CERTs ablau-
behörden sollten Informationen über IT- fen. In den USA beispielsweise stellt ein National
Health Information Sharing & Analysis Center (NH-
Page 12 of 15You can also read
