A Quantitative Study of Vulnerabilities in the Internet of Medical Things
Herv
´
e Debar
1 a
, Razvan Beuran
2
and Yasuo Tan
2
1
SAMOVAR, T
´
el
´
ecom SudParis, Institut Polytechnique de Paris, Palaiseau, France
2
School of Information Science, Japan Advanced Institute of Science and Technology, Nomi, Japan
herve.debar@telecom-sudparis.eu
Keywords:
Cybersecurity, Medical Internet of Things.
Abstract:
Medical objects, small or large, increasingly rely on digital technologies to monitor patients or deliver care.
They form a part of our digital critical infrastructure, that can be significantly impacted by cyberattacks. For
example, the Wannacry ransomware shut down hospitals in Europe for hours, even days. This paper analyzes
recent vulnerabilities that have affected medical objects, and present findings related to the characteristics of
these vulnerabilities. It will then use these findings to propose ideas for improved cybersecurity in the medical
IoT. One of the key findings of the paper is that it demonstrates the effect of regulations enacted worldwide in
early 2017, requiring critical infrastructure operators and providers to proactively publish information about
vulnerabilities.
1 INTRODUCTION
Medical objects, small or large, increasingly rely on
digital technologies to monitor patients or deliver
care. They form a part of our digital critical infras-
tructure, that can be significantly impacted by cyber-
attacks. For example, the Wannacry ransomware shut
down hospitals in the UK for hours, even days (Mar-
tin et al., 2017). Granted, other types of critical in-
frastructures were impacted elsewhere in the world by
this same threat. However, this incident shows that a
significant number of healthcare processes, forming
the Internet of Medical Things, are relying on infor-
mation and communication technologies.
Medical infrastructures form part of our Critical
Infrastructure, or essential services. As such, recent
regulations have introduced an obligation for oper-
ators of critical infrastructures to disclose incidents,
and an obligation for vendors of products used in
these infrastructures to publish vulnerability informa-
tion. An example of sites providing this information is
the US-based ICS CERT advisories (US Department
of Homeland Security, 2019).
Using ICS CERT advisories, this paper focuses
on advisories that apply to the “Healthcare and Pub-
lic Health” critical infrastructure sector, identified by
the “ICSMA identifier in the advisory organization.
Compared with other sources of information (e.g. ar-
ticles in journals), this information is reliably struc-
a
https://orcid.org/0000-0002-1344-4167
tured, up to a point where it is possible to envision
further work to analyze this information.
This paper analyzes recent vulnerabilities that
have affected medical objects, and present findings
related to the characteristics of these vulnerabilities.
It will then use these findings to propose ideas for im-
proved cybersecurity in the medical IoT, leveraging
the conceptual description of the NIST cybersecurity
framework.
2 CONTEXT AND RELATED
WORK
This work should be understood in the context of crit-
ical infrastructure protection, at a time where regula-
tions such as the Network and Information Systems
security (NIS) directive (NIS Directive, 2016) impact
the way industries labelled as critical infrastructures,
and the vendors which serve these industries, must
disclose vulnerability information to the regulators.
Medical environments are critical infrastructures,
and providing good cybersecurity measures may
prove essential to patient health (Martin et al., 2017)
already now. Medical environments have specific re-
quirements, however, which have led to specific so-
lutions being developed in the past such as break the
glass access control (Marinovic et al., 2011). One of
our objectives is to evaluate if medical devices have a
different vulnerability profile than what we are classi-
cally used to in information and communication tech-
nologies, and if we can quantify this difference.
There have been a few studies of cybersecurity
risk in medical environments. Fu and Blum (Fu and
Blum, 2013) analyze cybersecurity reports of medical
device manufacturers to the Food and Drug Admin-
istration (FDA). They provide
`
a qualitative analysis
indicating that there are significant cybersecurity vul-
nerabilities related to integrity and availability, but do
not quantify this information any further.
Kramer and Fu (Kramer and Fu, 2017) study the
specific case of connected pacemakers by analyzing
the advisory provided by the Food and Drug Admin-
istration (US). It concludes that the information pro-
vided in the advisory could be improved. Our root
source is different, as we look at the data from a more
global perspective, and information we process spans
multiple vendors. Also, the FDA is concerned primar-
ily with patient safety and is producing recommenda-
tions to this effect, whereas we are analyzing recom-
mendations that apply to the command and control
ICT infrastructure in the medical sector.
Kruse et al. (Kruse et al., 2017) analyze publica-
tions from the medical databases. They extract 31
documents related to cybersecurity in the medical sec-
tor. It highlights that cybersecurity is a significant is-
sue for the medical sector, and that this is reflected
in regulations such as HIPAA (Annas et al., 2003).
However, it does not provide tools or quantification
of the issues they highlight.
Coventry and Branley (Coventry and Branley,
2018) also analyze the medical scientific literature to
understand why healthcare environments are vulnera-
ble to cybersecurity issues. They elaborate that there
are an increasing number of connected devices per pa-
tient (15 is mentioned in their study) and that health-
care environments host valuable data. However, they
review specific incidents but do not provide a global
view of vulnerabilities.
As a summary, the existing literature focuses on
qualitative analysis, while we attempt to quantify the
issues. Furthermore, many of these studies are driven
by the medical world, while we attempt to bring an
ICT perspective to our analysis.
The analysis heavily relies on structured informa-
tion provided by the Common Weakness Enumeration
(CWE) (Martin, 2007) and the Common Vulnerabil-
ity Scoring System (CVSS) (Mell et al., 2006). As a
by-product of this study, we also expect to show how
effective or useful these widely-used schemes are to
understand vulnerabilities.
3 METHODOLOGY
The objective of the paper is to systematically ana-
lyze advisories of the medical critical infrastructure,
as documented by the ICS CERT advisories. The fol-
lowing methodology was created to support this sys-
tematic analysis.
Collecting and Parsing Advisories. Advisories
have been collected from the ICS-CERT website
and separated into structured information. This is
performed based on the structure of the advisory
as shown on the website.
Enhancing Advisories. Advisories are enhanced in
several specific ways, to get information from
the Common Weakness Enumeration, patch status
and other vendor information.
Queries for Analysis. Once the dataset is structured
and clean, we ran a number of queries to get an-
swers to questions such as complexity of advi-
sories, availability of patches, time between dis-
covery and patch, complexity of the attack vector.
3.1 Collecting and Parsing Advisories
An advisory is a well formatted document, consisting
of four or five sections. For each advisory, we use the
identifier and title provided by CERT, as well as the
date of first publication.
The first section, “executive summary”, is a bul-
let list of summary information providing information
about the CVSS score, the attack vector and skill level
required, the vendors involved, the products involved
and the type of vulnerability. As this is a summary
information, the technical details described hereafter
are more precise, particularly on products and ver-
sions affected.
The second (optional) section “update informa-
tion” contains update information. As advisories are
revised when additional information becomes avail-
able, this section contains time-related information
about the update. The text of the advisory, and in par-
ticular the technical details and the mitigation section
contain revision marks that indicate the update. This
section is not considered in the analysis, as we only
address the most up to date (at the time of collection,
January 2019) version of the advisory.
The third section, “Risk analysis”, is a short sen-
tence about risk related to the advisory as a whole. As
risk is more precisely addressed by the CVSS vector,
this section is not considered in the analysis.
The fourth section, “technical details”, is the most
detailed content of the advisory. It is composed of two
subsections. Subsection “affected products” lists with
significant details the product names and versions that
are affected by the advisory. This section also pro-
vides information about the products that are not af-
fected by the advisory. The second subsection, “vul-
nerability overview”, provides a detailed list of each
of the vulnerabilities that are affecting the products.
Each vulnerability (CVE entry) is reported in an in-
dividual subsection, whose title references the CWE
entry categorizing the CVE information.
Each vulnerability description is thus included in
a third-level subsection. The title of the vulnerabil-
ity subsection references a CWE category of vulner-
ability (text, identifier and link). The content of the
description includes a few lines of text describing in
more details the mechanism of the vulnerability and
its consequences. The last sentence of each section
provides a CVE identifier, a CVSS v3 score and a
CVSS v3 vector.
The final section, “Mitigations”, provides infor-
mation to remediate the vulnerability. It is informally
split in two parts. The first provides information from
the vendor about availability (or not) of patches, and
what they recommend to address with respect to the
vulnerability. This part also provide links to addi-
tional vendor information on their web site. The sec-
ond part is a standard text provided by ICS-CERT on
how to generally mitigate vulnerabilities in critical in-
frastructures.
3.2 Enhancing Advisories
Once the initial information is collected, further pro-
cessing is required to enhance and normalize the in-
formation collected. This enhancement process relies
on third party information that is directly linked to by
the advisories.
Figure 1: Structuration of vulnerability information.
As shown in figure 1, the most basic vulnerabil-
ity directory is CVE, directly associated with a CVSS
vector. However, the technical details section of advi-
sories is sub-structured using the CWE structure, and
the CVE/CVSS information is given only at the end
of each subsection. This means that the number of
CWE in an advisory is lower or equal to the number
of CVE it reports.
The first enhancement relates to the completion
of the CWE information associated with each advi-
sory. CWE contains roughly 1000 entries, classified
as base information, or as class. A class regroups vul-
nerability types that share certain characteristics. For
our purposes, even regrouping CWE provides too seg-
mented information. Therefore, we are using also the
“Software Fault Patterns” (SFP) view of CWE, which
provides a typology of frequent errors made by devel-
opers. This view has two layers, a very compact ag-
gregate of 10 high-level common software mistakes
(referred to as the SFP1 view), and a second layer re-
fining some of these high-level clusters in more pre-
cise sub-clusters.
AS shown in figure 1, there are other substructures
available, such as CAPEC and ATT&CK. This analy-
sis is left for future work.
The second enhancement is the segmentation of
the CVSS vector. We transformed all CVSSv2 in-
formation included in the older advisories in the
CVSSv3 format using a fixed translation scheme. We
then segment the CVSS vector into its eight compo-
nents, to ensure that we are able to analyze in details
the attack vectors and the impact.
Concerning date and time, we take specific care
to extract the year of both the CVE and the advisory
titles. This provides us with a timeline representing
roughly the beginning and the end of the vulnerabil-
ity spectrum. CVE entries are reserved when a re-
searcher suspects a vulnerability and requests an entry
in the CVE repository from MITRE. Thus, the date in
the CVE entry represents roughly the time of discov-
ery. Advisories are generally published when vendors
have had time to confirm the existence of the vulner-
ability and provide a solution.
3.3 Completing Advisories with Device
Type
Certain fields must be manually analyzed in order to
ensure accurate and complete information. We per-
form manual completion of advisories on two counts,
understanding what kind of product is vulnerable, and
what kind of mitigation solution is available.
The first manual analysis performed is linked to
the understanding of what the product is, and more
precisely determining if the advisory describes a de-
vice vulnerability (thus a vulnerability in the embed-
ded software or firmware), or if it is describing an
application vulnerability. ICS-CERT advisories ad-
dress critical infrastructure, but not necessarily de-
vices. Medical software platforms such as imaging
management platforms are purely software, but they
form part of the critical infrastructure and as such are
subject to advisories. So manually reading the vendor
documentation about the product is required to deter-
mine whether the vulnerable product is a medical de-
vice, or pure software.
Traditional industrial control systems differentiate
between sensors (temperature, pressure, etc.), which
provide input data to the control processes, and ac-
tuators (valves, motors, etc.) which apply changes
to the control system. In medical devices, we have a
need for a finer grain classification, as sensors such as
imaging devices need to subject the body to physical
effects, typically radiation, to obtain the desired mea-
surement. We thus will use the following four classes
for devices, extending the transducer capabilities of
the taxonomy proposed in NISTIR 8228 (Boeckl
et al., 2019).
PassiveSensing. The ability to Provide an Observa-
tion of an Aspect of the Physical World in the
Form of Measurement Data (Boeckl et al., 2019).
In the context of this study, we restrict devices in
this category to measurements that cannot have
a negative effect on humans. Examples include
temperature or blood pressure.
Actuating. The Ability to Change Something in the
Physical World (Boeckl et al., 2019). In the
healthcare domain, the environment might be the
patient, but also the operator of the device. De-
vices in this category directly inject treatment to
the patient. This category includes for example
connected syringes, pacemakers or insulin pumps.
ActiveSensing. This extension of NISTIR 8228 cov-
ers the case of a device which requires some actu-
ation to do the sensing. In the healthcare domain,
this might be for example the case of an imaging
device that needs to emit X-rays to capture the im-
age. There might be an adverse effect of X-Rays
to the patient or the operator. The reason for hav-
ing a separate category is that there are recorded
incidents where patients were subjected to inapro-
priate levels of radiations by operators, generally
by accident.
IndirectActuating. This extension of NISTIR 8228
covers the case of a device management platform,
such as an aggregator or a programming tool. It
is not a direct device, but it is so close to the de-
vice that an attack on it might influence the de-
vice itself. An example in the healthcare domain
includes syringe management platforms, drug de-
livery platforms.
3.4 Completing Advisories with Patch
Information
The second aspect of advisories that requires manual
analysis is the understanding of the possible mitiga-
tion solutions associated with the advisory. The “mit-
igation” section of advisories is much less structured
than the other parts. Furthermore, it frequently links
to the security section of the vendor website, where
further interactions are needed to find which piece of
vendor-provided information actually applies. Thus,
there are 3 situations that we are confronted with:
1. Unknown: We have not been able to extract infor-
mation relative to the existence of a patch.
2. No Solution Provided: The text clearly indicates
that the vendor will not fix the vulnerability. The
vendor does not provide a robust solution that en-
able the user to continue using the device with
trust.
3. Solution Provided: The text clearly indicates that
the vendor has fixed or will fix the vulnerability.
To exhaustively describe the different situations
encountered in advisories, we define the following six
patch status:
Unknown. No information could be extracted rela-
tive to the existence of a solution provided by the
vendor.
No The status ‘No’ indicates that no solution will be
provided by the vendor.
Upgrade. The status ‘Upgrade’ indicates that the
vulnerability is patched in newer versions of the
product; the vulnerable version is out of date and
the user should buy a newer version.
Mitigation. The status ‘Mitigation’ indicates that a
workaround is described by the vendor. The vul-
nerability remains in the product, but exploitation
is harder or effects are mitigated.
Announced. The status Announced’ indicates that
the vendor has given a date and methodology for
the release of the patch.
Yes The status ‘Yes’ indicates that the solution has
been published and is available, and can be de-
ployed by the users.
The favorable situation is clearly when a patch is
either announced or available. In the other cases, the
end-user may have to cover significant expenses re-
newing his product or changing its modes of opera-
tion to solve the issue.
3.5 Remaining Issues
The following additional enhancements could be ap-
plied to the dataset, in order to provide increased qual-
ity.
Certain CWE, particularly the ones associated
with older vulnerabilities, are not precise enough.
This is illustrated for example by the fact that cer-
tain CWE are tagged as “used by NVD before 2016”.
They could be replaced by more precise ones (not
done yet), focusing particularly on categories that
provide an aggregated view but not a precise idea of
the problem. The text associated with the description
of the vulnerability could be mined to specify more
precisely the issue. One example of this is CWE-310,
which associated with legacy SSL would be more ac-
curately described by CWE-327, whereas CWE-310
associated with certificate would be more accurately
described by CWE-295.
There is a need to strengthen the process with re-
spect to products and vendors. For example, there is
an issue related to mergers and acquisitions between
Becton and Carefusion, the later bought by the for-
mer. Hence there is a product with the same name,
but different versions, which is attached to two ven-
dors.
There is a need to specialize the confidentiality
impact and to adapt it to the medical domain. For
example, the process needs to determine if Personally
Identifiable Information (PII) and Personal Health In-
formation (PHI) is impacted. We assume that finan-
cial information will never be impacted in the medical
systems, as it resides purely in ICT service platforms.
3.6 Analyzing Advisories
At this stage, we obtain a clean dataset of advisories,
associated with CWE records. In the end, the dataset
consists of 55 fully complete advisories, referencing
as a whole 204 CVE entries. The dataset references
62 products, 48 devices in one of the four categories
listed in section 3.3, and 14 referencing vulnerabili-
ties in software platforms. 40 of the 55 advisories are
related to devices.
Out of the 24 vendors, 20 are device vendors and
6 are software vendors. Therefore, two vendors (Bec-
ton Dickinson and Philips) are present in the data set
with vulnerabilities both on software and on devices.
Out of the 24 vendors, only 6 had reports related to
several years. Philips reported during 4 years, Bec-
ton Dickinson 3. This tends to indicate an increase
in awareness and information sharing. 11 device ven-
dors reported an issue in 2018.
As shown in Figure 2, the importance of reporting
Figure 2: Number of advisories per year per device type.
is improving significantly over the years. All cate-
gories of devices are providing information in 2018.
The category of PassiveSensing is also emerging in
2018. Since the requirements to report cybersecurity
issues in the critical infrastructure sector have been
enacted, there has been a significant number of advi-
sories reported.
4 ANALYSIS RESULTS
4.1 Time Lag between CVE and
Advisory
As is well known in the software world, there might
occur a significant time lapse between the discovery
of a vulnerability and the actual publication of the ad-
visory. So we would like to get a quantitative answer
for the question of How long does it take for a vulner-
ability to be fixed ?
This time lapse in the dataset can be modeled by
the difference between the CVE year and the year of
publication of the advisory. The former represents an
approximation of the time at which the discovery of
the vulnerability is made by a white hat hacker, while
the publication of the advisory indicates that the ven-
dor has been alerted and has handled the problem, of-
ten in recent years by providing a patch.
Table 1 counts the number of vulnerabilities hav-
ing as year of the advisory the line value (from 2013 to
2018) and as year of the CVE the column value (from
1999 to 2018). The expectation is that if vulnerabil-
ities are discovered and handled by vendors rapidly,
we should obtain a diagonal table.
The most reassuring result is that, at the year gran-
ularity (which is quite large), many vulnerabilities are
discovered and disclosed either the same year, or the
year after, and we obtain a diagonal, as expected.
However, there are a few outliers that required further
analysis.
Table 1: Difference in years between the year of the CVE and the year of the advisory.
Year Year as indicated in the CVE label (CVE-YEAR-NNNN)
Adv. 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018
2013 1
2014 4
2015 1 9 17
2016 1 8
2017 1 4 2 16
2018 1 1 2 1 2 1 1 1 5 4 4 4 4 1 59 65
The CVE-1999 entry in fact references the ping-
of-death vulnerability and could be considered an out-
lier. The actual date of the ping-of-death vulnerabil-
ity for windows platforms is 1996, and for BSD-Unix
systems around 1985. Therefore, while it is surprising
that a product analyzed in 2018 should exhibit such
an old vulnerability, the time difference between CVE
and advisory is justified.
Another outlier is the ICSMA-18-037-02 vulner-
ability, also addressed in section 4.2. While the ad-
visory itself is from 2018, the vulnerability affects
many products of the same family, which have been
developed and retired over the years. Hence, the wide
spread in CVE within the same advisory. This ex-
plains most of the time lag (27 out of 30 entries).
As a conclusion, while there is clearly a greater
time lapse than the best practice of 90 days between
private disclosure to vendor and public disclosure,
there is a significant effort to tackle vulnerabilities in
the critical healthcare infrastructure within a reason-
able amount of time.
4.2 Complexity of Advisories
Another question is the complexity of advisories. If
an advisory contains many vulnerabilities, it is likely
to be both more significant and more difficult to pro-
cess for critical infrastructure operators.
Advisories for software report in general only one
CVE per advisory. Our data contains only one out-
lier reporting 35 vulnerabilities (ICSMA-18-058-02),
related to a web portal. This might be considered as
representative of a large software package patching
many vulnerabilities related to the underlying operat-
ing system.
Figure 3 counts the number of CVE entries in ad-
visories for medical devices. It shows that the advi-
sories tend to cover multiple CVE references. 11 ad-
visories cover a single CVE entry (out of 55), while
14 contain 2 CVE references, and another 14 contain
between 3 and 8 CVE references. So while advisories
are more complex for devices than for products, the
complexity remains limited. There are two outliers,
reporting 15 and 27 CVE entries for a single advisory.
Figure 3: Number of CVE entries per advisory for devices.
They cover two different cases.
ICSMA-18-107-02 reports many vulnerabilities
related to the use in the device of the MS operating
system. In the dataset, this is artificial in the sense
that the advisory itself does not list any of the vulner-
abilities, but these can be found in the vendor infor-
mation associated with the advisory. This reflects the
fact that at least this vendor ignored the lifecycle of
the operating system it used in its device.
ICSMA-18-037-02 reports 27 CVE entries for
the same CWE (CWE 287 – Improper authentication,
likely the use of hard coded password) in a family
of products over the years. The CVE entries range
from 2001 to 2017, indicating that the problem has
been known for a significant duration, but was not ad-
dressed by the vendor until very late. The segmenta-
tion of CVE is also very small and might be hard to
address.
Figure 4: Number of CWE entries per advisory for devices.
Figure 4 depicts the same information but for
CWE entries. It shows that for example the two out-
liers presented above have disappeared, because both
of them are related to only a few types of vulnera-
bility. In particular, ICSMA-18-037-02 has com-
pletely disappeared in the figure.
This brings two comments. First, it confirms that
CWE is an effective description of the status of vul-
nerabilities. Second, it indicates that medical devices
may suffer from a single (or two) type of flaws, even if
there are multiple CVE referenced. This may indicate
that there is hope for more efficient mitigation.
Another aspect of advisory complexity is related
to CVSS scores. The profile of severities remains rel-
atively stable over the years. It is impossible to con-
sider that there is an increase in risk related to an in-
crease in severity. However, there is no significant
decrease either, meaning that vulnerabilities continue
to be introduced at a significant rate.
4.3 Analysis of Common Weakness
Enumeration
Common Weakness Enumeration is a taxonomy of
vulnerabilities that is frequently included in the ad-
visories. The following analysis attempts to under-
stand the type of fault that is really occurring, based
on CWE references that are associated with many en-
tries. This part of the analysis uses as pivot the CWE
references. There are 63 different CWE references in
the database. They are present in a large portion of
the dataset. Only one advisory for devices does not
properly reference a CWE entry.
Out of these 63 references, 2 are compounds con-
cerning composites, CWE-352 and CWE-384. They
mean that several basic flaws must be present for the
vulnerability to exist. These are difficult to classify
further, although CSRF is a well-known OWASP is-
sue.
Six other CWE references are categories. These
entries group several CWE entries that share a com-
mon characteristic. It probably means that the identi-
fication of the vulnerability was not precise enough. 1
outlier is specified as graph, which has the same char-
acteristics. In terms of structure, they are classified as
incomplete and are excluded from further analysis.
Table 2 presents the list of simple CWE entries for
devices in the dataset, with their name, the frequency
of apparition overall and in 2018, and the first-level
software fault pattern cluster to which they belong.
The first result from the query is that the most
present issue, by far, is related to authentication.
CWE-287 is essentially a failure to validate fully the
authentication data submitted to the device. A sim-
ilar issue is CWE-345. while CWE-259 and CWE-
798 relate to the fact that authentication information
is hard-coded and cannot be modified. The same is-
sue appears with CWE-321, but the use of cryptogra-
phy indicates an increased awareness of security and
hence is less frequent than password.
The most repeated issue is related to improper au-
thentication (i.e. the absence of a mechanism to con-
trol access to the device), closely followed by default
password. These issues, which have completely dis-
appeared in traditional software development, may in-
dicate that devices are developed by non-security spe-
cialists or do not follow risk assessment procedures.
Several of the Information Leak category entries
also indicate leakage of authentication information.
This situation remains in 2018. The main dif-
ference between the overall data and the 2018 fo-
cus seems to be the removal of cryptographic errors,
which may indicate a better maturity of the develop-
ers in using encryption.
CWE-323 appears only once in the dataset. This
references the infamous Key Reinstallation Attack
(KRACK) vulnerability in WPA2. Since networking
capabilities are clearly part of modern devices, and
one of their attack channels, it is surprising that there
are not more vendors reporting this. This probably
means that there are other advisories to come, or that
this vulnerability is silently patched by vendors.
The same information for software brings up the
traditional issues of tainted input and memory man-
agement, which also exist in devices but less fre-
quently.
4.4 Analysis of the CVSS Vector
This section focuses on analyzing two subparts of the
CVSS vector, the Attack vector and the Attack com-
plexity. The attack vector indicates the capability of
the attacker to carry out its attack remotely (indicated
by adjacent or Network in table 3). The attack com-
plexity indicates the difficulty that the attacker has in
carrying out the attack successfully and is qualified by
either low or high. The table order indicates decreas-
ing number of vulnerabilities.
As unfortunately expected, vulnerabilities are
widely exploitable over the open Internet with a low
attack complexity, as indicated by the last line of ta-
ble 3. In that respect, devices tend to exhibit more
failings than pure software (where physical access is
considered irrelevant). More worrisome, out of the
42 network-accessible, low-complexity vulnerabili-
ties that were reported in 2018, 41 also require no par-
ticular privileges to be exploited. This may indicate
that there has been no significant progress in protect-
ing devices that are in many cases directly connected
Table 2: Count of CWE entries in the dataset and in 2018.
CWE-Ref CWE title Count 2018 SFP Primary
CWE-120 BUFFER COPY WITHOUT CHECKING SIZE OF INPUT 1 1 Memory Access
CWE-125 OUT-OF-BOUNDS READ 1 1 Memory Access
CWE-200 INFORMATION EXPOSURE 1 1 Information Leak
CWE-23 RELATIVE PATH TRAVERSAL 1 1 Path Resolution
CWE-250 EXECUTION WITH UNNECESSARY PRIVILEGES 1 1 Privilege
CWE-254 SECURITY FEATURES 1 0 NA
CWE-256 UNPROTECTED STORAGE OF CREDENTIALS 1 1 Information Leak
CWE-264 PERMISSIONS PRIVILEGES AND ACCESS CONTROLS 1 0 NA
CWE-295 IMPROPER CERTIFICATE VALIDATION 1 1 NA
CWE-323 REUSING A NoNCE KEY PAIR IN ENCRYPTION 1 1 Cryptography
CWE-330 USE OF INSUFFICIENTLY RANDOM VALUES 1 0 Predictability
CWE-377 INSECURE TEMPORARY FILE 1 0 Information Leak
CWE-427 UNCONTROLLED SEARCH PATH ELEMENT 1 1 Tainted Input
CWE-434 UNRESTRICTED UPLOAD OF FILE WITH DANGEROUS TYPE 1 1 NA
CWE-460 IMPROPER CLEANUP ON THROWN EXCEPTION 1 1 Exception Management
CWE-601 URL REDIRECTION TO UNTRUSTED SITE AKA OPEN REDIRECT 1 0 Tainted Input
CWE-668 EXPOSURE OF RESOURCE TO WRONG SPHERE 1 1 Information Leak
CWE-693 PROTECTION MECHANISM FAILURE 1 1 Other
CWE-732 INCORRECT PERMISSION ASSIGNMENT FOR CRITICAL RESOURCE 1 0 Access Control
CWE-755 IMPROPER HANDLING OF EXCEPTIONAL CONDITIONS 1 1 Exception Management
CWE-923 IMPROPER RESTRICTION OF COMMUNICATION CHANNEL TO INTENDED ENDPOINTS 1 1 NA
CWE-119 IMPROPER RESTRICTION OF OPERATIONS WITHIN THE BOUNDS OF A MEMORY BUFFER 2 0 Memory Access
CWE-20 IMPROPER INPUT VALIDATION 2 2 Tainted Input
CWE-257 STORING PASSWORDS IN A RECOVERABLE FORMAT 2 2 Information Leak
CWE-260 PASSWORD IN CONFIGURATION FILE 2 1 Information Leak
CWE-285 IMPROPER AUTHORIZATION 2 0 Access Control
CWE-294 AUTHENTICATION BYPASS BY CAPTURE-REPLAY 2 1 Channel
CWE-300 CHANNEL ACCESSIBLE BY NoNENDPOINT AKA MAN-IN-THE-MIDDLE 2 0 Channel
CWE-319 CLEARTEXT TRANSMISSION OF SENSITIVE INFORMATION 2 1 Information Leak
CWE-320 KEY MANAGEMENT ERRORS 2 0 NA
CWE-321 USE OF HARD-CODED CRYPTOGRAPHIC KEY 2 0 Authentication
CWE-356 PRODUCT UI DOES NoT WARN USER OF UNSAFE ACTIONS 2 2 UI
CWE-400 UNCONTROLLED RESOURCE CONSUMPTION AKA RESOURCE EXHAUSTION 2 0 Resource Management
CWE-749 EXPOSED DANGEROUS METHOD OR FUNCTION 2 1 Other
CWE-78 IMPROPER NEUTRALIZATION AKA OS COMMAND INJECTION 2 2 Tainted Input
CWE-920 IMPROPER RESTRICTION OF POWER CONSUMPTION 2 1 NA
CWE-312 CLEARTEXT STORAGE OF SENSITIVE INFORMATION 3 0 Information Leak
CWE-345 INSUFFICIENT VERIFICATION OF DATA AUTHENTICITY 3 1 Authentication
CWE-522 INSUFFICIENTLY PROTECTED CREDENTIALS 3 1 Information Leak
CWE-121 STACK-BASED BUFFER OVERFLOW 4 1 Memory Access
CWE-284 IMPROPER ACCESS CONTROL 4 4 Access Control
CWE-311 MISSING ENCRYPTION OF SENSITIVE DATA 4 2 Information Leak
CWE-94 IMPROPER CONTROL OF GENERATION OF CODE AKA CODE INJECTION 4 0 Tainted Input
CWE-798 USE OF HARD-CODED CREDENTIALS 6 4 NA
CWE-259 USE OF HARD-CODED PASSWORD 8 2 Authentication
CWE-287 IMPROPER AUTHENTICATION 9 6 Authentication
Table 3: CVSS vector comparison between devices and
software, in the dataset and in 2018.
Attack characteristics Complete dataset Year 2018
Vector Complexity Devices Software Devices Software
Physical High 7 0 5 0
Low 5 0 2 0
Local High 6 0 6 0
Low 13 6 8 5
Adjacent High 20 0 17 0
Low 5 3 4 3
Network High 12 26 7 26
Low 67 30 42 25
to the Internet.
A few attacks do require physical access to the de-
vice, which in healthcare settings is not difficult. This
type of vulnerability might reveal difficulties in se-
Table 4: CVSS impact comparison between devices and
software in the dataset.
Confidentiality Integrity Availability
Devices None 14 (10%) 32 (24%) 35 (26% )
Low 24 (18%) 22 (16%) 19 (14%)
High 97 (72%) 81 (60%) 81 (60%)
Software None 12 (18%) 28 (43%) 27 (42%)
Low 12 (18%) 10 (15%) 6 (4%)
High 41 (63%) 27 (42%) 32 (24%)
curing devices from the persons who have physical
access. In this respect, devices that are not owned by
their main users may require specific security proper-
ties.
Table 4 extracts from the CVSS vector the usual
3 impacts, Confidentiality, Integrity and Availability
(CIA). The major impact of vulnerabilities on devices
is on confidentiality, as only 10% list no impact and
72% list a high impact. Integrity and availability are
slightly less impacted. Also, one has to note that the
impact of vulnerabilities on software is generally less
and less widespread than the impact of vulnerabilities
on devices. Half of the device vulnerabilities list a
high impact in the 3 dimensions, while this is the case
for only 32% of the pure software vulnerabilities.
4.5 Patch Availability
Another interesting question is whether vendors pro-
vide solutions for security vulnerabilities. Table 5 in-
dicates the patch information associated with vulnera-
bilities (CVE entries), according to the nomenclature
presented in section 3.4.
Table 5: Patch information for each CVE, for the whole
dataset and the years 2017-2018.
All years Years 2017-2018
Patch Status Devices Software Device Software
Unknown 28 (20%) 2 (3%) 2 (3%) 2 (3%)
No 8 (6%) 1 (1%) 6 (8%) 0 (0%)
Upgrade 22 (15%) 0 (0%) 3 (4%) 0 (0%)
Mitigation 21 (15%) 1 (1%) 10 (14%) 1 (2%)
Announced 14 (10%) 44 (64%) 10 (14%) 38 (63%)
Yes 50 (35%) 21 (30%) 43 (58%) 19 (32%)
The following table depicts a picture that is sig-
nificantly different between pure software and med-
ical devices. While 94% of the software vulnerabil-
ities are patched, only 45% of them are patched in
devices. Vendors rely more heavily on mitigation and
upgrade (30%). Also interesting is the fact that for
many CVE entries, it is difficult to ascertain the status
of the patch.
Fortunately, the difference is reduced if the data is
focused on the most recent years 2017-2018. Focus-
ing on this most recent part of the dataset, the propor-
tion of devices effectively protected increases to over
70%.
The devices have a different patching profile than
pure software. On one hand this is not surprising
because devices require more effort to patch. On
the other hand, medical devices (contrary to the ones
found in for example smart homes) are managed by
professional, and contrary to other settings (e.g. in-
dustry) it is possible to have shorter usage lifecycle
that could fit a patching model. Furthermore, critical
infrastructure has a requirement to maintain these de-
vices in order to remediate cybersecurity issues. The
gap is closing in recent years, but effort is still re-
quired to continue in this direction.
5 RELATION TO THE NIST
CYBERSECURITY
FRAMEWORK
The NIST Cybersecurity framework (Shen, 2014)
provides a reference for improving critical infrastruc-
ture security. The framework core defines ves areas
(identify, protect, detect, respond and recover) and for
each of these areas defines a number of categories
and sub-categories where action should be taken to
appropriately address the area. Standards cyberse-
curity controls are associated with each of the sub-
categories, to facilitate implementation.
In the context of this work, section 5 attempts to
provide recommendations based on the statistics ex-
tracted from the data, and other considerations from
the literature, for each of the functions.
The recover function covers organizational and
communication actions and is outside the scope of the
work.
5.1 The Identify Function
The activities in the Identify Function are founda-
tional for effective use of the Framework. Under-
standing the business context, the resources that sup-
port critical functions, and the related cybersecurity
risks enables an organization to focus and prioritize
its efforts, consistent with its risk management strat-
egy and business needs. Examples of outcome Cat-
egories within this Function include: Asset Manage-
ment; Business Environment; Governance; Risk As-
sessment; and Risk Management Strategy.
The first category of the identify function is Asset
Management (ID.AM): The data, personnel, devices,
systems, and facilities that enable the organization to
achieve business purposes are identified and managed
consistent with their relative importance to business
objectives and the organization’s risk strategy. In the
context of IoMT, the link in the critical infrastructure
between the objects and the management platforms
(e.g. image management or device programming) is
clearly established through the qualification of advi-
sories. The specificities of the healthcare sector must
be reflected in advisories and in the CVSS vector,
such as the real possibility of physical harm to pa-
tients and operators if the devices are misused, and the
requirements to operate in emergency situations. This
leads to difficulties as communications and data flows
are not necessarily stable, maybe not sufficiently to
enable static definition. In our study, this is qualified
by the type of device, as described in section 3.3.
The second category of the identify function is
Business Environment (ID.BE): The organization’s
mission, objectives, stakeholders, and activities are
understood and prioritized; this information is used to
inform cybersecurity roles, responsibilities, and risk
management decisions.
The advisories studied in this document demon-
strate that some of the devices and software suppli-
ers have complied with regulations, at least in the US.
However, the number of reported issues remains small
overall and further studies should confirm the level of
compliance of the healthcare industry as a whole.
The next three categories cover aspects related to
governance (ID.GV), Risk Assessment (ID.RA) and
Risk Management strategies (ID.RM). They are only
covered through the analysis of the CVSS vector. The
granularity of the CVSS vector is insufficient to en-
sure proper satisfaction of these 3 categories, particu-
larly with respect to privacy risks. Mitigation is also
insufficiently covered in advisories.
5.2 The Protect Function
The Protect Function supports the ability to limit or
contain the impact of a potential cybersecurity event.
Examples of outcome Categories within this Func-
tion include: Identity Management and Access Con-
trol; Awareness and Training; Data Security; Infor-
mation Protection Processes and Procedures; Mainte-
nance; and Protective Technology. In the context of
this work, the analysis of vulnerabilities is the most
appropriate source of information to effectively evalu-
ate the recommendations provided by the framework.
The first category of the Protect function is Iden-
tity Management, Authentication and Access Control
(PR.AC): Access to physical and logical assets and as-
sociated facilities is limited to authorized users, pro-
cesses, and devices, and is managed consistent with
the assessed risk of unauthorized access to authorized
activities and transactions.
This document demonstrates that authentication
issues are by far the most critical vulnerability of
medical devices. While physical access is important
in the protection of devices, the document demon-
strates that devices and software are remotely vulner-
able and that physical access may not necessarily be
the first required ICT protection, not beyond what is
usually carried out in hospital environments. Mitiga-
tion actions proposed by vendors unfortunately do not
rely on permissions management.
The third category of the Protect function is Data
Security (PR.DS): Information and records (data) are
managed consistent with the organization’s risk strat-
egy to protect the confidentiality, integrity, and avail-
ability of information.
Section 4.4 shows that the major impact of vulner-
abilities is on data. However, it does not allow at this
stage a differentiation between data at rest and in tran-
sit. Further work is required to assess exactly what
kind of data is impacted. Overall, the complexity of
exploiting vulnerabilities is rather low, indicating fail-
ure in development processes for devices.
The other categories of the protect function are
less relevant to this work.
Our work demonstrates that the advisories studied
in the document are very relevant to support the Pro-
tect function. Aspects related to network access con-
trol are frequently mentioned in mitigation and in pro-
tection, even though they might be hard to realize in
practice. Aspects related to access control and iden-
tity and access management are frequent causes for
vulnerabilities in devices, much more than software
which suffers from classic input/output sanitization
issues. Data protection aspects, both confidentiality
and integrity, are particularly important in the health-
care domain. The study shows that confidentiality in
particular is a frequent issue in vulnerabilities.
5.3 The Detect Function
The Detect Function enables timely discovery of cy-
bersecurity events. Examples of outcome Categories
within this Function include: Anomalies and Events;
Security Continuous Monitoring; and Detection Pro-
cesses.
The first category of the detect function is Anoma-
lies and Events (DE.AE): Anomalous activity is de-
tected in a timely manner and the potential impact of
events is understood.
In the IoMT, communication and data flows may
not be stable, as medical environments need to react in
emergency situations. The deployment of home care
might also require more study on this, especially since
many vulnerabilities are remotely actionable. Since
many vulnerabilities are related to authentication is-
sues such as default passwords and credentials (sec-
tion 3.3), attacks may be very similar to regular ac-
tivity and it might be extremely difficult to deploy
misuse or anomaly detection methods. The vulner-
abilities studied in this document, either for device or
software, do not require complex event processing or
multi event processing for the most part. The victim is
generally clearly identified and is a single component.
The study provides some worthwhile elements for
the Detect function. The main finding is that the vul-
nerabilities reported for devices touch authentication
issues such as default credentials. Attacks exploit-
ing these vulnerabilities are likely to be extremely
close to normal traffic. Therefore, misuse detection
is not applicable as it will be very difficult to define
a signature. Anomaly detection might detect abnor-
mal activity patterns, but this will be very dependent
on the actual deployment case. In any case, since
most vulnerabilities are remotely accessible, network-
based intrusion detection is the current best tool to
detect attacks exploiting these vulnerabilities. Detec-
tion of malicious code is only feasible in large de-
vices which include a fully functional operating sys-
tem (which on the other hand contradicts the protect
principle of least functionality PR.PT-3).
5.4 The Respond Function
The Respond Function supports the ability to contain
the impact of a potential cybersecurity incident. Ex-
amples of outcome Categories within this Function
include: Response Planning; Communications; Anal-
ysis; Mitigation; and Improvements.
Advisories should provide relevant information
for the respond function, as they include a remedia-
tion (and/or mitigation) section. However, informa-
tion in this section is often of uneven quality. The
general recommendations provided by centers such
as CERT are often too broad to be applicable to a
specific sector such as healthcare in a straightforward
manner. The recommendations provided by vendors
vary greatly. While this function should be present in
advisories, this is clearly an avenue for progress.
5.5 Recommendations
Going further, the first recommendation is to study
and provide solutions for authentication in healthcare.
As the study demonstrates, the main issue is for pa-
tients and care staff to obtain easy access to devices
and software platforms, even across shifts or in un-
usual situations. This requirement is accrued by the
need for emergency access, that should be included
in novel access control frameworks. At the same
time, a subset of the devices will not be able to in-
clude complex authentication procedures, when they
require significant computing, storage, or bandwidth
capabilities. Seamless, transparent authentication that
offers easy access in all situations while ensuring ac-
countability and post-mortem analysis is a mandatory
step forward.
The second recommendation is practical network
access control. Many vulnerabilities are remotely ex-
ploitable. However, legacy equipment will rely on
legacy protocols for many years, and ease of use will
also (as with authentication) require simple proto-
cols. Therefore, solutions based on Software Defined
Networking are likely to offer the required degree of
agility and granularity in network access control that
will be required for healthcare applications. The diffi-
culty is the deployment and management of such tech-
nologies, and their integration in current network ar-
chitectures. In that respect, the work that seems to be
starting at the IETF, leveraging protocol sets for cy-
bersecurity, is an interesting avenue to pursue.
The third recommendation is related to data.
Healthcare is and will continue to be a data-intensive
domain, both for care (e.g. patient monitoring,
surgery, diagnosis) and for research to design and
evaluate new treatments. Therefore, significant care
should be taken that data remains private, accurate
and available when needed. The data aspect of vul-
nerabilities seems undervalued at this stage, and new
methods for generating, storing, transporting and us-
ing data should be developed that enhance confiden-
tiality, integrity and availability of said data.
6 CONCLUSIONS
There exists a significant volume of information re-
lated to cybersecurity in healthcare. Since it is con-
sidered a critical infrastructure, there is a lot of infor-
mation in advisories, in general of better consistence
and quality than is available in journalistic sources.
This information is reliably structured, up to a point
where it is possible to envision further work to an-
alyze this information. The ICS-CERT and NVD
databases have formed the basis for creating a dataset
of information about the Internet of Medical Things,
and medical software, that constitute the healthcare
critical infrastructure. Since the requirements to re-
port cybersecurity issues in the critical infrastructure
sector have been enacted, there has been a signifi-
cant number of advisories reported. There are how-
ever few vendors involved, so there is a need to check
whether this is normal or not. Advisories may regroup
several vulnerabilities on several products of the same
vendor. Many of the vulnerabilities are rated high or
critical, meaning that they have a CVSS score above
7 or above 9.
The analysis demonstrate a take-up of reporting in
2017, associated also with a change of the advisory
format. This is a clear response to the worldwide de-
ployment of cybersecurity reporting regulations such
as the NIS directive(NIS Directive, 2016) in the EU.
Authentication issues represent the main source of
vulnerability present in devices, by far. This seems
rather normal in a healthcare environment where ac-
cess to the device should be given to staff easily,
where there is little culture for protection and ac-
cess control, and where the environment is considered
trustworthy. It would probably be useful to reinforce
good programming practices to avoid common errors,
and also to ensure that software remains sufficiently
simple in devices to be analyzed by existing tools. As
expected, the software fault pattern profile for devices
is different from the one of software products. These
software products generally exhibit data manipulation
issues of various origin, that enable the attacker to
compromise the software through code injection.
Devices seem to be easily exploitable over the
network, with a low complexity. This is coherent
with the observation that authentication issues are the
most prevalent, because we have experience of de-
fault password sharing lists or backdoor information
being widely shared for a long period of time. The
major impact of vulnerabilities on devices is on con-
fidentiality, as only 10% list no impact and 72% list a
high impact. Integrity and availability are slightly less
impacted. Also, one has to note that the impact of
vulnerabilities on software is generally less and less
widespread than the impact of vulnerabilities on de-
vices. Half of the device vulnerabilities list a high
impact in the 3 dimensions, while this is the case for
only 32% of the pure software vulnerabilities.
The devices have a different patching profile than
pure software. On one hand this is not surprising
because devices require more effort to patch. On
the other hand, medical devices (contrary to the ones
found in for example smart homes) are managed by
professional, and contrary to other settings (e.g. in-
dustry) it is possible to have shorter usage lifecycle
that could fit a patching model. Furthermore, critical
infrastructure has a requirement to maintain these de-
vices in order to remediate cybersecurity issues. The
gap is closing in recent years, but effort is still re-
quired to continue in this direction.
The findings were then placed in the context of
the NIST Cybersecurity Framework, which provides
a standard representation for improving the cyberse-
curity of critical infrastructure. Out of the five (Iden-
tify, Protect, Detect, Respond, Recover) functions of
the framework, the first and the last are mostly orga-
nizational. The analysis shed only a limited light on
the recommendations of the framework, demonstrat-
ing mostly that continuous improvement in cyberse-
curity is also shown in advisories.
ACKNOWLEDGEMENTS
This work was performed while Herv
´
e Debar was a
visiting professor with the Center for Trustworthy IoT
Infrastructure at Japan Advanced Institute of Science
and Technology (JAIST) in Ishikawa, Japan.
REFERENCES
Annas, G. J. et al. (2003). Hipaa regulations-a new era
of medical-record privacy? New England Journal of
Medicine, 348(15):1486–1490.
Boeckl, K., Fagan, M., Fisher, W., Lefkovitz, N., Megas,
K., Nadeau, E., Piccarreta, B., O’Rourke, D. G., and
Scarfone, K. (2019). Considerations for managing in-
ternet of things (iot) cybersecurity and privacy risks.
National Institute of Standards and Technology, NIS-
TIR 8228.
Coventry, L. and Branley, D. (2018). Cybersecurity in
healthcare: A narrative review of trends, threats and
ways forward. Maturitas, 113:48–52.
Fu, K. and Blum, J. (2013). Inside risks controlling for
cybersecurity risks of medical device software. Com-
munications of the ACM, 56(10).
Kramer, D. B. and Fu, K. (2017). Cybersecurity concerns
and medical devices: lessons from a pacemaker advi-
sory. Jama, 318(21):2077–2078.
Kruse, C. S., Frederick, B., Jacobson, T., and Monticone,
D. K. (2017). Cybersecurity in healthcare: A system-
atic review of modern threats and trends. Technology
and Health Care, 25(1):1–10.
Marinovic, S., Craven, R., Ma, J., and Dulay, N. (2011).
Rumpole: a flexible break-glass access control model.
In Proceedings of the 16th ACM symposium on Access
control models and technologies, pages 73–82. ACM.
Martin, G., Kinross, J., and Hankin, C. (2017). Effective
cybersecurity is fundamental to patient safety.
Martin, R. A. (2007). Common weakness enumeration.
Mitre Corporation.
Mell, P., Scarfone, K., and Romanosky, S. (2006). Com-
mon vulnerability scoring system. IEEE Security &
Privacy, 4(6):85–89.
NIS Directive (2016). Directive (eu) 2016/1148 of the eu-
ropean parliament and of the council of 6 july 2016
concerning measures for a high common level of se-
curity of network and information systems across the
union. OJ L, 194(19.7):2016.
Shen, L. (2014). The nist cybersecurity framework:
Overview and potential impacts. Scitech Lawyer,
10(4):16.
US Department of Homeland Security (2019). Ics-cert ad-
visories. Online.