A key aspect on any risk assessment process is the identification and analysis of vulnerabilities associated to the target organization, its assets, services and devices. Considering that not all vulnerabilities are equally dangerous, and organizations cannot aford to blindly define strategies against the hundreds of newly discovered vulnerabilities, they must define priorities during the vulnerability management process. In addition, while many organizations base their prioritization of vulnerability management on scores such as the Common Vulnerability Scoring System (CVSS), a high portion of vulnerabilities associated to malware are scored with low or medium severity on the CVSS scale, which suggest that focusing only on CVEs which score high or critical would be a mistake. We propose in this paper a multifactor assessment mechanism to define priorities of vulnerabilities afecting Healthcare Organizations. The mechanism helps classifying vulnerabilities based on their score and assigning priorities for their treatment.
With the discovery of new types of cyber-attacks and digital healthcare platforms being universally recognized as Critical Infrastructures, healthcare organizations realize the need to be technologically prepared against such challenges. Hospitals and healthcare centers have started taking actions to protect themselves inside the current landscape of attacks but most importantly to be able to react and mitigate new and unknown threats.
The health sector is exposed to a great number of threats that exploit vulnerabilities that
in some cases are unknown by the target infrastructures. According to a recent report [
One of the key phases in a vulnerability management process is the vulnerability analysis
that aims to prioritize the risks to which organizations are exposed if a given vulnerability
is successfully exploited. Considering that not all vulnerabilities are equally dangerous, and
organizations cannot aford to blindly define strategies against the hundreds of newly discovered
vulnerabilities, they must define priorities during the vulnerability management process.
Prioritization is therefore, the key to a successful implementation of new vulnerability management
programs [
While many organizations base their prioritization of vulnerability management on scores
such as the Common Vulnerability Scoring System (CVSS) [
We propose a multi-factor assessment mechanism to define priorities of vulnerabilities affecting Healthcare Organizations. The mechanism is performed by a Vulnerability Discovery Manager (VDM) tool and will cover both cybersecurity and privacy vulnerabilities with a particular focus on health data, healthcare information systems and medical devices. The proposed approach is expected to help in the classification and prioritization of security vulnerabilities.
The remainder of this paper is organized as follows: Section 2 provides an overview of the vulnerability challenges identified in healthcare environments. Section 3 presents the Vulnerability Discovery Manager reference architecture by detailing its main components. Section 4 introduces the proposed multi-factor vulnerability assessment mechanism. Section 5 provides a use case example to show the applicability of the proposed mechanism. Section 6 provides related works. Finally, conclusions and perspectives for future work are provided in Section 7.
Much like any other domain where new technologies have emerged, healthcare faces
increasingly more and more challenges to its cybersecurity. According to a recent study by Bugcrowd
[
With no standards, guidelines and good practices communicated to all parties involved, and no known published examples of incidents in the industry until recently, as well as undisclosed details of such incidents where other vulnerabilities do not become known to the public or the industry, there is no standard way of making and using medical equipment handling data that will ensure security throughout its lifecycle. This leads to existing yet unknown vulnerabilities being either exposed, posing a threat to the reputation of the manufacturer and the provider, or worse, exploited, in which case personal and sensitive data can be compromised along with the smooth continuity of healthcare services provided. This can have critical consequences, such as major financial loss or even the loss of human life.
Additionally, until recently, a possibly false sense of safety was the norm in the healthcare industry, because it did not seem as a possible target for cyber-attacks. However, this changed ever since the medical records became electronic and are now stored and distributed online. The introduction of Electronic Medical Records (EMR) and Personal Medical Records (PMR), as well as the utilization of cloud services and storage, created a new attack surface for malicious parties. The value of such sensitive data, particularly on platforms where they would be exploited for identity theft or ransom, in combination with the lack of robustness of the security mechanisms of the healthcare infrastructures, pose an attractive target for attackers.
As no standard procedures have been established yet, the measures taken proactively by
providers in order to protect their assets, may not be as efective. It has been observed that there
are still healthcare organizations that have not created a cyber insurance policy taking into
account security controls, nor have put their staf through cyber hygiene training, in fear that
adding more security mechanisms to the system would interfere with their work. To overcome
this, clear and strict procedures need to be established for all stakeholders who are part of the
healthcare domain [
Vulnerabilities in the Healthcare domain, originate due to a multiple number of causes [13]: (i) Most healthcare services and devices require single-factor authentication, making them a potential target to many threats (e.g., brute-force attacks); (ii) Some healthcare devices and apps share patient data with no data protection mechanisms, making them more vulnerable to attacks like Man-in-the-Middle (MITM); (iii) Errors and/or intentional incidents caused by insiders constitute one of the most common threat vectors in Healthcare organizations; (iv) Medical device security practices in place (e.g., code review, debugging systems and dynamic application security testing) lack of quality assurance and testing procedures [14]; (v) Disconnection between the perceptions of medical device manufacturers and healthcare practitioners about security implications of the medical equipment used; (vi) An important number of vendors and users do not disclose cybersecurity and privacy issues afecting their IoT medical devices, which block communications of vulnerabilities and threats in due time among healthcare organizations; (vii) Some medical devices run with outdated software and operating system.
The Vulnerability Discovery Manager (VDM) is a domain-specific tool that identifies, analyses and manages vulnerabilities in the target infrastructure. VDM has been designed to support the key needs of the e-health sector (e.g., criticality and availability) aiming to: (i) identify vulnerabilities to system resources (discovery); (ii) classify and assign priorities to detected vulnerabilities (assessment); (iii) define remediation solutions to mitigate detected vulnerabilities (treatment); and (iv) provide intelligence sharing functionality in order to share the information with other hospitals and healthcare providers (sharing). In this paper we will focus on the assessment capabilities of the tool.
The VDM needs as input data the identification of the assets composing the target infrastructure. The discovery of the assets can be performed using any network scanner such as Nmap or a similar tool. The idea is to obtain information about the network and system devices (e.g., workstations, servers, printers, smartphones, etc.) to start the process of discovering vulnerabilities. Each device is identified by a unique IP address in the system, therefore having a list of IP addresses for all the elements (e.g., nodes, assets) composing the monitored system will trigger the analysis performed by the VDM.
As depicted in Figure 1 VDM has four main components: (i) vulnerability scanner, (ii) vulnerability storage, (iii) vulnerability assessment, and (iv) vulnerability reporting and sharing. The remainder of this section details each VDM component.
This module is in charge of discovering and associating vulnerabilities to the list of nodes present in the input file. It is composed of two main processes: (i) vulnerability identification; and (ii) asset tagging and management. After the identification of vulnerabilities, the tool will associate each node/asset with its corresponding vulnerabilities. This process allows to verify that vulnerabilities match the assets (e.g., devices, equipment, software) in the target network. The objective of this process is to reduce the number of false positives or negatives and to concentrate on the system’s exploitable weaknesses. The outcome of this process is a list of assets and associated vulnerabilities that will be stored in the VDM database and assessed in the next modules.
The VDM DB is a central component that stores the JSON files generated by the vulnerability scanner module. Examples of this information include CVEs, CWEs, CVSS, vulnerability descriptions, attack patterns, related assets, and relevant information associated to the detected vulnerabilities from all assets composing the target system. The VDM DB is the connection entity among all VDM components (i.e., Vulnerability scanner, assessment, reporting & sharing). The VDM DB allows the retrieval of vulnerabilities and risk information related to assets composing the target infrastructure.
This module analyzes the list of detected vulnerabilities, classifies them according to their category, assigns them priorities based on their risk levels and provides treatment to avoid/mitigate them. Details on the Vulnerability Assessment process is provided in Section 4. Based on the obtained score, the risk associated to a given vulnerability can be classified as: (i) Critical, >= 4.1 1.1 >= <= 2.0 ; (ii) High, 3.1 >= <= 4.0 ; (iii) Medium, 2.1 >= <= 3.0 ; (iv) Low, and (v) Negligible, 0.0 >= <= 1.0 .
The VDM tool produces a vulnerability report with valuable information about the target network/hosts and their associated vulnerabilities. The report is stored in the VDM DB and can be displayed in a dashboard or exported in PDF, or STIX1 format. This latter uses STIX objects (e.g., event objects) that can also be integrated in the VDM DB. An Event object describes a dynamic observable cyber event (e.g., the occurrence of an attack). Healthcare organizations have the possibility to share their vulnerability results and new discoveries with other organizations, communities and research groups using the Malware Information Sharing Platform (MISP2) as the reporting and intelligence sharing platform.
The Vulnerability Assessment ( ) value is a metric that comprises three main parameters: (i) Root cause, (ii) Impact, and (iii) Remediation, as shown in Equation 1.
= _ + + (1)
Please note that “n” corresponds to the number of parameters composing the equation from which the value is diferent from null. If information is not available in any of the parameter, it will be discarded from the analysis. The remainder of this section details the identification of each of the parameters composing Equation 1 .
It identifies the main root causes of security vulnerabilities. The cause can be known or unknown. Known causes can be further classified as complexity, open connections, weak passwords, design lfaws, and human factor (as shown in Table 1) [15, 16].
Root Cause Description Human Vulnerabilities caused due to insuficient training, unawareness, and lack Factor of experience, causing coding errors and improper management of assets and data.
Design Flaws Design flaws and bugs in software and hardware. Example: Bugs in widely used operating systems and browsers can expose millions of businesses to significant risks.
Failures Ordinary malfunctions and hardware/software failures due to technical issues that could lead to a denial of service of the system.
Complexity Security vulnerabilities rise proportionally with complexity. Complex software, hardware, information, businesses and processes can all introduce security vulnerabilities.
Weak Pass- Passwords are used to secure virtually everything: mobile devices, software, words websites, company VPNs and enterprise software. Despite education about the dangers — many people still write passwords down, share them or give them out to websites.
Open Connec- Each open connection is a potential avenue for exploitation. Examples: tions wired internet, mobile devices, WiFi, open ports, etc.
Unknown No information is available to assess this parameter.
It assesses the potential impact of a given vulnerability if successfully exploited on the target system/network. It considers three main aspects: (i) data at risk, (ii) severity, and (iii) damage. 4.2.1. Data at risk: 4.2.2. Severity: It identifies and assesses the type of information that needs protection in the organization e.g., Personally Identifiable Information (PII), Intellectual Property Data (IPD), Financial Data, Social Media, etc. (as shown in Table 2) [17, 18].
It considers the CVSS base metric group that represents intrinsic characteristics and severity of a vulnerability that are constant over time and across user environments. It is composed of exploitability metrics (e.g., attack vector, attack complexity, privileges required, user interaction); and impact metrics (i.e., confidentiality, integrity, availability).
Based on the CVSS results, vulnerabilities are assigned a severity score as follows: None: no severity with CVSS = 0.0 (severity = 1), Low: 0.1 >= <= 3.9 (Severity =2), Medium: 4.2.3. Damage: (Severity=3), High: 7.0 >= <= 8.9 (Severity = 4), and Critical: Data at Risk PII Financial Data IPD Social media accounts Third-party data Social work data Data that could potentially identify a specific individual, e.g., medical information, birth date, social security numbers, citizen ID, etc.
Related to the ofering or delivery of a financial product/service or processing of a purchase (e.g., credit card, bank account, loan, etc.).
It refers to sales and marketing plans, new product plans, patents, customer It refers to information often used for authenticating to various applications
It refers to any kind of data accessed, handled and/or supplied by third net- It refers to data about the vulnerable organization/product that is publicly available in social networks, blogs and public websites.
No information is available to assess this parameter.
Score 5 5 5 4 3 2 It considers the potential damage that could be caused by a breach of the afected system if the vulnerability is successfully exploited (as seen in Table 3).
Damage Total Damage Partial Damage
The system is expected to be partially damaged due to the NO/Low Damage
The system is not expected to be damaged due to the successful Description The system is expected to be highly damaged due to the successful exploitation of the vulnerability.
successful exploitation of the vulnerability.
The vulnerability impact is a metric composed of three parameters: (i) the data at risk, (ii) the severity, and (iii) the damage (as shown in Equation 2).
= _ _ + + (2)
Please note that “n” corresponds to the number of parameters composing the equation from which the values are diferent from null. If information is not available in any of the parameter
It assesses the potential capabilities for an organization to implement and recover for a successful exploitation of a given vulnerability in its system. It considers the recovery time, requirements, resilience, costs and recovery level.
It identifies and assesses the time needed for an infrastructure to recover from a given attack, assuming the vulnerability is successfully exploited by a malicious entity (as seen in Table 4).
Recovery Time Long It identifies and assesses the type of security measures (e.g., protective, reactive) the target system needs to implement in order to recover from a given attack (as seen in Table 5).
Requirements New measures Existing measures No measure Unknown
Description The system requires implementing new reactive or protective measures).
The system requires implementing existing measures.
The system does not require to implement any measure.
No information is available to assess this parameter. It identifies and assesses the actions needed by the target system to keep running after a vulnerability has been detected and/or exploited (as seen in Table 7). The system requires to remove the vulnerability to keep running.
The system does not require to remove the vulnerability, but its removal is highly recommended to keep running.
No need to remove the vulnerability to keep running.
No information is available to assess this parameter.
It identifies and assesses level of recovery expected for the target system after the implementation of security measures (as seen in Table 8).
Score Score 5 3 Score 5 3 1
resilience, cost and recovery level parameters, as shown in Equation 3.
= _ + + + + _ (3)
Please note that “n” corresponds to the number of parameters composing the equation from which the value is diferent from null. If information is not available in any of the parameter
Considering a vulnerability of a remote code execution detected in a server from a healthcare organization (as shown in Annex A), the first step on the vulnerability assessment process is to identify the root cause. Although this is not clearly specified in the provided information, a remote code execution can be associated to multiple causes (e.g., open connections, weak passwords, complexity, design flaws, human factors, or a combination of some of them), therefore, the _ score is set to five (5).
The second step is to compute the vulnerability impact. Considering that the vulnerability is associated to a hospital server, the remote code execution could lead to the identification of personal data (e.g., medical information), therefore the _ _ score is set to five (5). In addition, the CVSS value for this vulnerability is equivalent to ten (10), therefore, the score is set to five (5), and since the system is expected to be partially damaged due to the successful exploitation of the vulnerability, its score is set to three (3). As a result, the value for this vulnerability is 4.33.
The third step is to compute the vulnerability remediation value. For that, the following assumptions have been made: • The system can be easily recovered in a short period of time ( _ = 1) • The system requires implementing new security measures ( = 5) • The system does not need to remove the vulnerability to keep running ( = 1) • No information is available to assess the cost parameter ( = 0). This parameter is therefore not considered in the score calculation. • After the implementation of a mitigation measure, the system is expected to be fully operative ( _ =1) Therefore, the score is equivalent to 2.
The final step consists on calculating the Vulnerability Assessment (VA) and classification. As a result, = 3.78 , which corresponds to a HIGH priority.
Novel approaches and tools based on old and recent technologies aim to filling possible security gaps underlying in modern healthcare cyber solutions. However, while it is important to safeguard the digital infrastructures from those who threaten them, it is also important to do so without disrupting the continuous healthcare procedures, or making them too complex to use for people with no technical background, such as the patients and the medical staf. To protect healthcare organizations, a cybersecurity solution needs to be in position to monitor and control all the security-critical aspects. Several solutions to identify and detect vulnerabilities in healthcare infrastructures have been proposed so far, nonetheless, few of them perform a thorough approach to assess and classify their severity.
The Cybersecurity and Infrastructure Security Agency (CISA3) has initiated an efort to enhance security, resiliency and reliability of the Nation’s cybersecurity and communication infrastructure. The Industrial Control Systems Cyber Emergency Response Team (ICS-CERT4) is a CISA initiative that provides a control system security focus in collaboration with US-CERT to conduct vulnerability and malware analysis, share and coordinate vulnerability information and threat analysis through information products and alerts, among other services.
Commercial solutions (e.g., Bugcrowd’s crowdsourced security [19]) are available in the market to help healthcare organizations to discover and manage critical vulnerabilities in the health sector. The solution enables healthcare professionals to assess the risk associated with disparate data sources and infrastructure and ensures compliance with the General Data Protection Regulation (GDPR) and the Health Insurance Portability and Accountability Act (HIPAA). Other well-known commercial and open-source solutions (e.g., Nessus5, OpenVAS6) provide vulnerability assessment capabilities that strongly depend on the CVSS results.
A vulnerability database containing timely information about current security issues, weaknesses, vulnerabilities and exploits on industrial control systems is publicly available as part of the CISA services and frequently updated by ICS-CERT advisories. Similar to the CVE database, the ICS-CERT Advisories database provides a list of industrial control system vulnerabilities. However, several issues have been recently identified [ 20]: (i) The provided recommendations are generic and, in some cases, meaningless; (ii) Industrial impact is ignored; (iii) Likelihood of exposure is missing; (iv) Some advisories contain errors in the CVE and CVSS score; (v) It may take months or years to get to a resolution; and (vi) Some vulnerabilities may not be mitigable besides patching, and some of them provide no advice at all.
In order to cope with the aforementioned shortcomings, we propose a vulnerability discovery manager that uses a multi-factor assessment mechanism to define priorities on vulnerabilities afecting critical infrastructures with a particular focus on healthcare organizations.
This paper presents a multi-factor assessment mechanism to classify define priorities of vulnerabilities afecting Healthcare infrastructures. It details a tool named Vulnerability Discovery Manager (VDM) which is composed of four main modules: (i) a vulnerability scanner, to check for vulnerabilities of the target nodes; (ii) a vulnerability storage, to save discovered vulnerabilities in a local database; (iii) a vulnerability assessment, to prioritize vulnerabilities and provide mitigation guidance; and (iv) a report and intelligence sharing, to communicate and share VDM output with other healthcare institutions.
The proposed assessment mechanism considers not only the vulnerability root causes, but also its impact and potential remediation actions to be implemented. As a result, a score ranging form zero to five is assigned to a particular vulnerability and shared in a platform where other healthcare centers and research organizations can benefit.
An example of usage is provided in Section 5 to show the applicability of our proposed mechanism over a vulnerability report generated by the VDM in a JSON format. Future work will focus on evaluating other factors and refining current values used to compute the vulnerability 4https://us-cert.cisa.gov/ics 5https://www.tenable.com/products/nessus 6https://www.openvas.org/ assessment score.
The research work presented in this article has been supported by the European Commission under the H2020 Programme, through funding of the “CUREX: seCUre and pRivate hEalth data eXchange” project (G.A. id: 826404). [13] Health Tech Staf, Ho healthcare can pinpoint common vulnerabilities – and build defenses, [online], 2018. https://healthtechmagazine.net/article/2018/07/ how-healthcare-can-pinpoint-common-vulnerabilities-and-build-defenses. [14] Ponemon Institute, Medical device security: An industry under attack and unprepared to defend, [online], 2017. https://www.synopsys.com/content/dam/synopsys/sig-assets/ reports/medical-device-security-ponemon-synopsys.pdf. [15] John Spacey, The 10 root causes of security vulnerabilities, [online], 2013. https://arch.
simplicable.com/arch/new/10-root-causes-of-security-vulnerabilites. [16] A. V. Revnivykh, A. Fedotov, Root causes of information systems vulnerabilities 8 (2015). [17] European for Information Technology, 3 types of data that need protection, [online], last visited February 2021. https://europeanitc.com/the-quick-brown-fox/. [18] Joseph Streinberg, 12 types of data that businesses need to protect but often do not, [online], 2018. https://josephsteinberg.com/ 12-types-of-data-that-businesses-need-to-protect-but-often-do-not/. [19] Bugcrowd, Why healthcare it should include crowdsourced security, [online], 2019. https: //www.bugcrowd.com/blog/why-healthcare-it-should-include-crowdsourced-security/. [20] Dragos, Industrial controls system vulnerabilities, [online], 2018. https://dragos.com/ wp-content/uploads/yir-ics-vulnerabilities-2018.pdf.
A. Extract from a VDM report in JSON format {