Security Risks in Healthcare Ivo Miguel Lopes Pinto

Security Risks in Healthcare

Ivo Miguel Lopes Pinto

Thesis to obtain the Master of Science Degree in

Computer Engineering

Supervisor(s): Prof. Miguel Nuno Dias Alves Pupo CorreiaDoutor Paulo Jorge Paiva de Sousa

Examination Committee

Chairperson: Prof. Luís Manuel Antunes VeigaSupervisor: Prof. Miguel Nuno Dias Alves Pupo Correia

Member of the Committee: Miguel Leitão Bignolas Mira da Silva

February 2017

Dedicated to someone special...

iii

Acknowledgments

Firstly, I would like to express my gratitude to my Professor Miguel Pupo Correia for his guidance in my

journey, as well as for Doctor Paulo Sousa. Without them this would not have been achievable.

I warmly thank to the professionals of the Portuguese healthcare sector and the Portuguese ministry

of health that kindly accepted to be interviewed and answer the questionnaires that played a key role in

this thesis.

I am also grateful to my mother, for the support both financially and emotionally.

To my friends, thank you for the advices, and support throughout all this time.

v

Resumo

O sector da saude desempenha um papel fundamental na sociedade actual, por isso tambem os seus

sistemas informaticos sao crıticos. Estes sistemas lidam com informacoes muito sensıveis, mas nem

sempre estao protegidos como seria de esperar de um sistema desta natureza. Este problema pode

facilmente ser reconhecido devido aos eventos recentes que se tem feito sentir, por exemplo, o acesso

ilegal a milhoes de registos de saude eletronicos causando milhoes de dolares em danos. Portugal

pode ainda nao ter sido alvo de um ciberataque em grande escala, mas este projeto tenta contribuir

para evitar tal catastrofe. O objetivo generico deste projeto e sensibilizar as pessoas para os ciber

riscos presentes no sistema de saude Portugues. Para cumprir este objetivo, compilamos um top 10

baseado numa analise de risco ao sector de saude Portugues, e tambem demonstracoes em vıdeo de

possıveis ataques. Este documento providencia uma visao geral sobre o estado da tecnologia no sector

da saude sob uma perspetiva de ciberseguranca. Tambem apresentamos uma descricao de tecnicas de

modelacao de ameacas e analises de risco. Para terminar o trabalho relacionado, apresentamos alguns

tops de risco de IT. Segue-se a seccao principal deste documento, contendo a analise de risco ao sector

da saude Portugues, com enfase nos passos tomados para a conseguir e como esta contribui para o

sector. Ha tambem uma seccao sobre as demonstracoes de ciberataques que desenvolvemos, onde

personificamos um atacante e explicamos em detalhe os passos que um tomaria. Por fim, avaliamos o

nosso trabalho com tres metodos diferentes que se complementam.

Palavras-chave: Sistemas de Informacao, Ciberseguranca, Analise de Risco, Cibercrime,

Saude

vii

Abstract

Healthcare systems are essential to society. They handle very sensitive information, but they are often

not as protected as one expects of a system of this nature to be. This problem can easily be noticed

at the light of recent global events in which, for example, attackers gained access to millions of private

health records causing millions of dollars in damages. Portugal may not have yet been victim of such a

large scale attack, but this project aims to contribute to avoid it. The generic objective of the project is to

contribute to create awareness of cybersecurity risks in the Portuguese healthcare sector. To address

our objective, a top 10 of risks was compiled based on a risk analysis of the Portuguese healthcare

sector along with two attack demonstrations. This document will provide an overview on the state of

healthcare technologies with a cybersecurity perspective. Also, a description of threat modeling and risk

assessment methodologies, and some IT-related tops of risk. Next, we present our risk analysis of the

Portuguese healthcare sector, including the steps we took to achieve it and how it contributes to the

sector. There is a section for our cyber-attacks video demonstrations in which we go in depth into the

steps required to achieve them. Lastly, we evaluate our work with three methods that complement each

other.

Keywords: Healthcare, Information Systems, Security, Risk Analysis, Cybercrime

ix

Contents

List of Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii

List of Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiv

1 Introduction 1

1.1 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.3 Thesis Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Related Work 5

2.1 Privacy and Confidentiality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.1 Electronic health records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.2 Medical devices and the Internet of Things . . . . . . . . . . . . . . . . . . . . . . 7

2.2 Security Risk Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2.1 Threat analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.2.2 Risk analysis methodologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.2.3 Risk rating methodologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.3 Tops of Risks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.3.1 Cybersecurity and privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.3.2 Healthcare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.4 Portuguese Healthcare Sector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.4.1 Current structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.4.2 Evolution of this status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3 Project Development 25

3.1 Top 10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.1.1 Preliminary interviews . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.1.2 Scope definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.1.3 Risk analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.1.4 Top 10 document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

3.1.5 Feedback questionnaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

3.1.6 Evaluation based on the questionnaires . . . . . . . . . . . . . . . . . . . . . . . . 55

3.2 Attack demonstrations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

xi

3.2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

3.2.2 Social engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

3.2.3 Software vulnerabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

4 Evaluation 63

4.1 Qualitative Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

4.1.1 Method overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

4.1.2 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

4.2 Quantitative Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

4.2.1 Method overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

4.2.2 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

4.3 Attack Demonstrations Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

4.4 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

5 Conclusions 73

5.1 Summary and Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

5.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

Bibliography 75

A Top 10 79

xii

List of Tables

1.1 Example attacks to healthcare systems and data . . . . . . . . . . . . . . . . . . . . . . . 1

2.1 Summary of sources for search in study . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2 Overall risk severity table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.3 Summary of the risk methodologies presented . . . . . . . . . . . . . . . . . . . . . . . . 16

2.4 Summary of the presented tops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.1 A summary of the threat agents profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.2 Example of an impact table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.3 Physical access to servers likelihood table . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.4 Physical access to servers impact table . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.5 Social engineering likelihood table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.6 Social engineering impact table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.7 Mobile devices likelihood table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3.8 Mobile devices impact table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3.9 Software vulnerabilities likelihood table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

3.10 Software vulnerabilities impact table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

3.11 Network vulnerabilities likelihood table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

3.12 Network vulnerabilities impact table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

3.13 DoS and business continuity likelihood table . . . . . . . . . . . . . . . . . . . . . . . . . . 41

3.14 DoS and business continuity impact table . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

3.15 Compromising medical devices likelihood table . . . . . . . . . . . . . . . . . . . . . . . . 42

3.16 Compromising medical devices impact table . . . . . . . . . . . . . . . . . . . . . . . . . . 42

3.17 Unauthorized systems access likelihood table . . . . . . . . . . . . . . . . . . . . . . . . . 43

3.18 Unauthorized systems access impact table . . . . . . . . . . . . . . . . . . . . . . . . . . 44

3.19 Lack of active protection measures likelihood table . . . . . . . . . . . . . . . . . . . . . . 45

3.20 Lack of active protection measures impact table . . . . . . . . . . . . . . . . . . . . . . . . 45

3.21 Lack of adequate security personnel likelihood table . . . . . . . . . . . . . . . . . . . . . 46

3.22 Lack of adequate security personnel impact table . . . . . . . . . . . . . . . . . . . . . . . 46

4.1 Breach data from one year period . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

4.2 Categorized incidents table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

xiii

List of Figures

2.1 Access to a EHR on a centralized system architecture . . . . . . . . . . . . . . . . . . . . 6

3.1 Validation questionnaire question 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48









3.10 Validation questionnaire question 10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51










3.20 E-mail for recruitment services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

3.21 E-mail from recruitment services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

3.22 Fake e-mail from information systems director . . . . . . . . . . . . . . . . . . . . . . . . . 58

3.23 Cyber attack scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

3.24 Attack scheme considering network topology . . . . . . . . . . . . . . . . . . . . . . . . . 59

3.25 SQLmap GUI after vulnerability search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

3.26 SQLmap target table information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

3.27 Dump file of the selected table entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

4.1 Evaluation questionnaire question 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

xiv









4.10 Attack demonstrations questionnaire question 1 . . . . . . . . . . . . . . . . . . . . . . . . 69





xv

Chapter 1

Introduction

Healthcare has been around for many years and its importance is indisputable. The goal of healthcare is

to maintain or improve the health of a group of human beings. Information Technology (IT) has become

crucial for the support, sustainability and growth of most businesses [1]. Healthcare has been increas-

ingly adopting IT, making funding channeled to healthcare organizations be used in the development

of new technologies, acquisition of new equipment or hiring of extra personnel. These are adequate

investment options considering the proven IT value for a business, and the healthcare goal. However,

the security of some healthcare assets has been partly neglected over the years. At the light of recent

events, exemplified on Table 1.1, we can be sure that security flaws exist in healthcare systems. Flaws

can lead to disastrous consequences, specially in systems that manage information so sensitive as

patient health information.

From the most simple accident, as losing a laptop computer, to sophisticated malware that ciphers

all data of a system, healthcare organizations have been increasingly targeted as time goes by. Even if

they are not increasingly vulnerable, the knowledge that healthcare systems are potentially vulnerable

to cyber-attacks is out in the open. Media articles such as [2], state that medical record information is

currently more valuable than credit card information on the black market. This was exactly the type of

motivation attackers needed.

Date Target Type of AttackJune 2010 AvMed, Inc. Theft of two laptopsOctober 2011 The Nemours Foundation Loss of propertyAugust 2013 Advocate Health and Hospitals Corporation Theft of four computersMay 2014 Portuguese Integrated Management of Health HackingJuly 2014 Montana Department of Public Health HackingAugust 2014 Community Health Services Corporation HackingMarch 2015 Anthem, Inc. Affiliated Covered Entity HackingMarch 2015 Premera Blue Cross HackingMay 2015 CareFirst BlueCross BlueShield HackingJuly 2015 University of California, Los Angeles Health HackingSeptember 2015 Excellus Health Plan, Inc. HackingFebruary 2016 Hollywood Presbyterian Medical Center Ransomware

Table 1.1: Example attacks to healthcare systems and data

1

The analysis of threats and risks has already proven its value, and is currently used thoroughly by

multiple sectors. Science has been assessing risk probabilities for years, however, its use in other areas

such as business is far more recent. These analysis can in fact save countless of companies resources,

by helping in the prioritization of the most important problems over minor issues. Having that in mind,

the healthcare industry should use the benefit of having at their disposal tested methodologies of risk

and threat analysis to assess its current situation and effectively allocate resources to critical security

measures.

Tops are known for their capacity of presenting information concisely as well as improving under-

standing of a given subject. For those reasons, we will present the results of our research as a top

of risks. Our top has the intent of creating awareness to this security problem by making known the

most important cyber risks in the Portuguese healthcare system. For even greater awareness, attack

demonstrations will be created.

1.1 Objectives

This project aims to address the current state of healthcare systems in Portugal motivated by their

essential role in our society. The goal is to perform a risk analysis on the Portuguese healthcare system,

following a reliable methodology, and use it to compile two concrete resources:

• Top 10 of risks: A top summarizing the risk analysis, with improved readability and exposure

compared to other approaches. The top ranks ten cyber risks due to the fact that ten is a good

threshold for being accurate in the risks affecting the industry but still staying concise, and not

losing the readers attention.

• Attack demonstrations: Video demonstrations of possible attacks aiming to create further aware-

ness to this kind of problems.

The results are unusual deriving from the fact that the area of interest, healthcare, is very far from

cybersecurity and (cyber-)risk analysis. A top 10 plus video demonstrations allow the creation of aware-

ness to the problem in a comprehensible manner to our target audience.

1.2 Contributions

This project aims to contribute to raise awareness of the healthcare sector for cybersecurity risks. For

this, we developed a top 10 of cyber risks. The top does not only describe the ten most severe cyber risks

faced by healthcare, but also the threats behind these risks, previous successful attacks, and potential

impact. It shows how dangerous these risks can be.

Another contribution are cyber attack video demonstrations. Seeing an attack happening is better

motivation for this topic than just the description of it, as agreed by professionals in the healthcare sector.

These demonstrations are publicly available on YouTube.

2

1.3 Thesis Outline

The rest of the report is organized as follows: Section 2 presents methodologies related to security

risk analysis, as well as research on topics related to healthcare security current situation. Section 3

consists of the project overview and detailed description of its implementation steps. Section 4 presents

the methodology to evaluate the project and the results gathered. In Section 5 we conclude and present

directions for future work.

3

Chapter 2

Related Work

Healthcare is a very complex field of study with a large attack surface creating multiple opportunities

for attackers. This section aims to summarize not only the current state of healthcare systems but also

the cyber risks associated with it, and ways to assess them. Section 2.1 presents current problems and

possible solutions related to privacy and confidentiality on healthcare systems. Section 2.2 presents risk

analysis methodologies. Section 2.3 explains existing tops in areas of cybersecurity and healthcare.

2.1 Privacy and Confidentiality

Privacy can be defined as the right to keep information from disclosure to other individuals. By con-

trast confidentiality has been defined as the right to an individual to prevent the re-disclosure of certain

information disclosed originally in the confines of a confidential relationship [3].

Maintaining privacy and confidentiality helps to protect participants from potential harms, may them

be psychological or social. Maintaining privacy and confidentiality should be strictly enforced. Although

general agreements exist about the need to protect privacy and confidentiality [3], protecting them is not

easy and generates controversy.

The following sub-sections cover electronic health records, medical devices, the Internet of Things

with a focus on how it can endanger users privacy and confidentiality.

2.1.1 Electronic health records

Health records also known as medical records are no more than medical data about patients collected

over the course of time. They may include administrative clinical data such as personal statistics like

age and weight, progress notes, problems, medications, vital signs, past medical history, immunizations,

laboratory data, demographics, radiology reports and billing information. The electronic version of these

records – electronic health records – represents the same information but stored and made available

in computer systems. The change from paper-based health records to electronic health records is

motivated by the purpose of improving quality of care. This is provided by error-reducing technologies

that, for instance, avoid errors in handwritten data. Electronic technologies also provide a strong and

5

reliable way of sharing data across institutions solving the problem of having different and incomplete

records at different health institutions.

There are many different approaches to national/regional electronic health records systems. Most

of these approaches share a similar architecture, represented in Figure 2.1. Health records are stored

in clinical servers present at hospitals and clinics. These can be altered by medical doctors of those

institutions. Authorized parties are granted access to health records by the central server, which collects

information from an arbitrary number of clinical servers presenting it in an organized manner.

Figure 2.1: Access to a EHR on a centralized system architecture

The centralized architecture of Figure 2.1 is the most common choice. Record systems can be

divided into two types, which differ on the way they are managed, governmentally or privately. Further

we show examples of both.

US and Australia have record systems managed governmentally, but they function differently. US

is focused on a pull model, meaning the full patient record is made available to authorized parties.

Australia however is more concerned with patient input. In fact, they are working on a push model

version, HealthConnect, where patients and their providers will select which elements of their record are

transmitted to the central server and made available. Their differences and similarities are scrutinized at

[4].

There is also a third type of record system: the personal health record (PHR). Unlike the others

previously mentioned, it is not governmental. It consists in a health record where data is maintained

by the patient. It may contain the same diverse range of data of an EHR. There are multiple vendors

for this software. The most commonly known systems are Microsoft HealthVault and Google Health [5].

Personal health records are not intended to replace health records, but rather to complement them.

As mentioned above records hold very sensitive information. Having that in mind the access should

be restricted to authorized parties only. This feature is provided in every EHR system by access control.

The model of access control differs in each system, but the most adopted is role-based access control

due to its flexibility and ease of use [6]. Authentication is also featured in every EHR system; Public key

6

infrastructure (PKI) or a login/password model are the most commonly chosen among manufacturers

[6].

Current record systems aim to solve privacy and confidentiality problems using access control, but

they make too optimistic assumptions [7]. These systems may provide access control and authorization

mechanisms but some of these record systems, for example Microsoft HealthVault, use outsourced

storage [8]. Can this outsourced resource be trusted? Even if not outsourced, can the storage server be

trusted? Having the push model in mind, the patient does not authorize the server or anyone with access

to it to be able to view or alter his record. Bearing these concerns in mind, encryption based techniques

have been successfully applied to solve this problem [7]. Patient controlled encryption (PCE) focus on

a system using EHR which can be decomposed in a hierarchical structure. It also uses the concept of

hierarchical key structures, which consists in having a secret key with the ability to generate other keys

to decipher only a part of a given ciphered document. PCE starts with the patient generating his own

secret key, used to cipher his health record. In this approach the storage holds a bulk of unreadable data

from its perspective, and the patient has the ability to generate hierarchical keys to distribute accordingly

to whom he wants to share each information with.

Further effort was put into investigating the outsourcing problem i.e., on the problem of the out-

sourced storage potentially having access to confidential data. Data analysis is one of the possible

techniques to gain access to confidential data, unfortunately very effective even if the stored content

is ciphered. Hiding the data content from the storage server cannot stop some of the current attacks.

An attacker could for instance determine a patient disease by analyzing the access pattern to a DNA

sequence. GORAM [8] aims to fix these problems. It offers confidentiality and privacy properties such

as secrecy, no party can deduce information about the content of an entry if it does not have access to

it, accountable integrity, no party can alter contents of entries without being held responsible, and oblivi-

ousness, a server cannot distinguish between different arbitrary queries. These properties are achieved

by applying fairly new security techniques. One technique is based on chameleon signatures which

applies chameleon hash functions, randomized collision-resistant hash function that provide a trapdoor.

Given the trapdoor it is possible to efficiently compute collisions, without it no adversary can find a colli-

sion in a plausible amount of time. This digital signature scheme ensures integrity of data, by essentially

having a tag for each data entry which only clients with access write are able to produce. All clients can

verify the validity of such tags, and eventually with the help of a logging system appoint the misbehaving

party. The other technique used on GORAM is a modified version of a broadcast encryption scheme

which consists in generating and broadcasting the keys to the clients, allowing only a specific subset of

clients to be able to decipher a given cipher text in a scalable manner. Their experiments have proven

the system to have a light overhead comparably to the numerous security properties it provides.

2.1.2 Medical devices and the Internet of Things

The Internet of Things (IoT) embraces a wide range of devices from smart TVs, car systems, networking

devices, smart watches, to a never ending list of devices. The diversity of devices is plentiful but so are

7

Database Content Search StrategyFDA Weekly EnforcementReports

Comprehensive weekly summary ofall safety alerts and recalls issued forFDA-regulated products

Manual review of each weekly report to identify alldevices recalled with adjudication based on deviceuse of computers, software or data storage

FDA Medical and RadiationEmitting device Recalls

Database of recalls providing infor-mation on reason for recall and ac-tions taken

Free text search for inclusion of ”security” and ”pri-vacy” as reason for recall

Manufacturer and UserFacility Device Experience(MAUDE)

Repository of adverse events sentto FDA by users of medical devicesand/or manufacturers

Product problem list hand-searched for connec-tions to security and/or privacy, and all adverseevents linked to these problems reviewed

Table 2.1: Summary of sources for search in study [10]

the threats they face. New attacks are experienced everyday, countermeasures arrive too late.

Medical devices have been gradually improving with time. Technology advances are the main reason

for this improvement. Some patients have their quality of life directly tied with a medical device, others,

life itself depending on a device. With stakes this high, securing devices from induced malfunctions

should be top priority. Although there is nearly universal agreement on the importance of securing these

devices, there is disagreement over the security requirements for them [9]. The American Food and Drug

Administration (FDA) current program requires manufacturers to use design and validation procedures

that address the confidentiality, integrity, and availability of patient data and to limit access to devices to

authorized users only. However, medical devices vary widely in security features because no specific

security guidance or requirements have been promulgated by the FDA. No single security method or

mechanism could provide sufficient security for every medical device under every circumstance [9].

Medical devices are slowly joining the Internet of Things. Older devices are being replaced by newer

ones with innovative capabilities, which could make them susceptible to new threats. Insulin pumps, car-

diac pacemakers, cardiac defibrillators, are some examples of medical devices adhering to the benefits

of wireless connectivity. Patients receive wireless monitors that collect information from their implanted

devices only to relay the stored information to a server, making it available to medical doctors. In theory

it seems very practical and useful, however, it comes with unanticipated risks: attackers could either

steal private information’s or tamper with the devices functionality. Medical devices now inherited the

Internet of Things long lasting problems.

Fortunately, there are no reported incidents related with hacking of medical devices that led to disas-

trous consequences. A study [10] evaluated post-market events in medical devices related to security

and privacy using three databases illustrated in Table 2.1.

A detailed review of these databases, revealed that recalls (market withdrawals) of devices with com-

puters are common, though features such as wireless communication and storage of personal data are

less common. However, this review is not so reassuring. It seems likely that the current classification

scheme does not capture correctly device malfunctions of this type. The scheme needs a better design

to suite the growing complexity of medical devices and their related problems. Jerome Radcliff, a dia-

betes patient, hacked his own insulin pump. He explains how he achieved it in his report [11]. This is the

proof that attacks threatening the life of patients are possible, and should be a real concern even though

as mentioned no major incidents have yet been reported.

The pairing between the Internet of Things and medical devices is already happening, and it wont

8

stop growing. Privacy, confidentiality and integrity should be maintained. The regulations still lack

as mentioned, however, work is already in progress with the intent to counter some of the expected

problems [12, 13]. Some examples of security mechanisms are:

• Very short range communication. By disallowing long-ranged communications to implanted

devices, an attacker would need to be close to perform the attack. The proximity would most likely

disclose his identity.

• Communication protection. Encrypting communications between devices could solve many po-

tential problems, however, the computing power required by this solution may be excessive in

relation to the device’s battery. A potential solution in order to implement encrypted communica-

tions is zero-power defense [12]. This mechanism aims at enhancing security without using energy

from the medical device battery. It consists of an energy-harvesting computer acting as a gateway

device. People trying to communicate with a medical device power the gateway device with their

own radio transmissions. The gateway then runs a challenge-response protocol that makes people

prove they are allowed to contact the device.

• Authentication with passwords. Requiring a password to access a given device might be a good

authentication solution for devices that not only support this method. This would assure privacy

and confidentiality if the password is not incorrectly distributed. The need of accessing devices in

case of emergency also blocks this solution from being standardized.

• Advanced malware detection techniques. Malware detection techniques include control-flow

integrity verification, call stack monitoring, dataflow analysis, and multisource hash-based verifi-

cation. Although the battery drain is still an issue, malware detection is an effective way against

many potential attacks.

A recurring problem tied with medical devices is the persistence of old malware. Not only new medical

devices carry potential attack vectors, old systems used by most hospitals and clinics are also a potential

target. Some medical devices still rely on the original versions of Windows XP and there are plenty of

known vulnerabilities in those versions, for which Microsoft does not provide updates anymore. “Today,

healthcare providers are told to maintain a secure system from insecure devices.” [14] using outdated

versions of systems without security patches is a problem, but the lack of incentive to report such events

is also a concern. Reporting should be incentivized rather than penalized, as it currently is.

2.2 Security Risk Analysis

Risk analysis is the process of identifying, defining and analyzing various dangers to individuals or

organizations by natural or human-caused events. Risk analysis can be either quantitative, where an

attempt is made to numerically determine probabilities of the events, or qualitative, where the likelihood

of potential events is only described.

9

Risk analysis is used to create awareness of hazards and risks, identify who may be at risk, determine

if current measures are adequate for the situation, but also to help prioritize hazards and/or measures.

The prioritization it promotes may be very useful for healthcare. Healthcare budget tends to not be

majorly focused on IT security measures. Risk analysis allows healthcare institutions to improve their

security efficiently.

Risk is the product of the threat level a system is exposed to, the vulnerability level the system has,

and the resulting impact of that adverse event on the organization. It can be represented by an equation:

Risk = Threat level ∗ V ulnerability level ∗ Impact (2.1)

This equation is used to calculate risk in many of the risk analysis methodologies. Threat level

represents the probability of an attack to the system. Vulnerability represents the weakness of the

system, and Impact represents the result if an attack is successful.

Section 2.2.1 discusses threat analysis, a step in risk analysis which analyzes and describes the

attacks that a system can suffer. There are several risk analysis methodologies, some of the most

common will be covered in Section 2.2.2. Section 2.2.3 will cover risk rating methodologies.

2.2.1 Threat analysis

Threat modeling is an approach to analyze the security of a system. Threat modeling can be asset-

centric, attacker-centric or software-centric [15]. Each of these approaches has different strengths and

weaknesses. Threat modeling can also be applied at different stages. The earlier the process is used

in the development life cycle the likelihood of effectiveness increases, and costs decrease. The goals of

threat modeling are the same independently of the approach and can be summarized as [16, 17]:

• Identifying potential threats and vulnerabilities of a system.

• Identifying countermeasures to prevent or mitigate the effect of the threats.

• Creating a set of documents that are used to create security specifications and security testing,

thus preventing duplication of efforts.

• Producing software that is secure by design.

There are several accepted methodologies for threat modeling. We will focus on the Microsoft ap-

proach. The Microsoft security development lyfecycle (SDL) threat modeling process is divided in four

steps: diagramming, threat enumeration, mitigation and verification [15]. This model is aimed at improv-

ing security of designs, documenting security design activities, and teaching security to people working

through the process [15].

A scope assessment is done previously to the threat analysis, in order to gather information about

the application [16]. Diagramming is the first step of the threat analysis. It generally uses Data Flow Dia-

grams (DFD) with the addition of trust boundaries. The elements of a DFD are: process, data flow, data

store, and external entity which are good means of eliciting information. Trust boundaries are no more

10

than frontiers between different sides operating at different privilege levels. Microsoft modified version

of DFDs focus on the flow of data through a system, which is relevant in most software attacks, making

them a great tool of analysis. The reasons behind Microsoft choice of diagram was the ease of under-

standing and data-centric characteristics [15]. The diagramming phase decomposes the application into

a DFD. This decomposition must be done in a hierarchical way, starting from level 0 which decomposes

the application at a high level only showing its main components and user types. The decomposition

can go into detail, however, it is not recommended going beyond level 3 due to the level of complexity.

The diagram is then ready for the second phase, threat enumeration.

Threat enumeration consists in identifying threats for each of the components in the first phase

diagram. Microsoft recommends using a taxonomy, STRIDE, to systematically identify threats, i.e.,

potential attacks to the system and the corresponding vulnerabilities. STRIDE is a mnemonic for security

threats in six categories [18]:

• Spoofing of user identity

• Tampering

• Repudiation

• Information disclose

• Denial of service

• Elevation of privilege

Microsoft also applies a technique, STRIDE per element to provide guidance for non-experts, as well

as repeatability [15]. This technique is based on the observation that some software architecture threats

we are concerned with are more frequent in some DFD elements than others. For instance considers

Spoofing to be frequently present on External entities and Processes. However, Microsoft does not

claim universal applicability of such technique, other organizations might need to extend or replace their

STRIDE threats per DFD element [15].

The third step is mitigation. For each of the identified threats there are four possible actions: redesign

to eliminate, apply standard mitigations, invent new mitigations, or accept vulnerability in design [15, 17].

This third step may be considered a goal of threat modeling, as improving system security is directly tied

with providing a way to address an identified problem.

The fourth and last step is Validation. There are a number of heuristics to validate threat models,

including graph analysis of diagrams, checking that final diagrams reflect the final code, STRIDE threats

per element have been enumerated, that the whole threat model has been reviewed, and each threat is

mitigated [15].

2.2.2 Risk analysis methodologies

There are several risk analysis methodologies available today, which can be divided into two major

categories: quantitative and qualitative. Qualitative methods excel in current complicated structures

11

and widespread information systems. However they vastly depend on the knowledge of the people

who conduct the analysis due to the lack of tools, like mathematics and statistic models, making them

inconsistent [19]. Quantitative methods are considerably more precise but not suitable for complex envi-

ronments [19]. Both quantitative and qualitative methods may be supported by software. The methods

executed without the assistance of software are said paper-based methods. Both approaches have ad-

vantages and disadvantages, for instance [19]: paper-based methods tend to be slower than software

approaches; the use of software assisted methodologies has higher costs.

An overview on some of most currently used risk analysis methodologies follows [20]:

• OCTAVE was developed at the CERT Coordination Center (CERT/CC) [21]. This approach con-

centrates on assets, threats and vulnerabilities. One of the main concepts of OCTAVE is self-

direction. This means that people inside the organization must lead the information security risk

evaluation. An analysis team, consisting of staff from the organization’s business units as well as

the IT department, is responsible for leading the evaluation and recording results. The OCTAVE

approach has three phases, with each broken down into processes. Each process has certain

activities that must be completed, and in each of these activities different steps have to be taken in

order to achieve the desired outputs. The final result is the threat profile of different assets. Each

threat profile contains information on which mitigation decisions can be based.

• ISRAM provides a quantitative approach to risk analysis that allows for the participation of the

manager and staff of the organization. ISRAM is a survey-based model. Two separate and in-

dependent surveys are conducted for the two attributes of risk, namely probability and impact.

ISRAM does not use techniques such as Single Occurrence Losses (SOL) or Annual Loss Ex-

pectancy (ALE); instead, the risk factor is a numerical value between 1 and 25. This numerical

value corresponds to a qualitative, high, medium or low value, and it is this qualitative value on

which risk management decisions are based. The ISRAM methodology has seven steps. Details

on the approach can be found at [19].

• CORA, Cost-Of-Risk Analysis, was developed by the International Security Technology, Inc. The

CORA risk model uses data collected about threats, functions and assets, and the vulnerabilities

of the functions and assets to the threats to calculate the consequences, that is, the losses due

to the occurrences of the threats. It is a methodology where the risk parameters are expressed

quantitatively and where losses are expressed in quantitative monetary terms. CORA uses a

two-step process to support risk management. Parameters for threats, functions and assets are

validated and refined until the best values are determined. CORA then calculates SOL, the loss

expected to result from a single occurrence of a threat, and ALE, the estimated loss expressed in

monetary terms at an annual rate for a given threat, for each of the threats identified. It estimates

a single loss value for a threat to an organization, and then multiplies this value by the frequency

of the threat occurrence. Details on the approach can be found at [20].

• CORAS main objectives are to develop a framework that exploits methods for risk analysis, semi-

formal methods for object-oriented modeling, and computerized tools, for a precise, unambiguous,

12

and efficient risk assessment of security critical systems. The methodology is based on Unified

Modeling Language (UML), a language that uses diagrams to illustrate relationships and depen-

dencies between users and the environment in which they work. During an information security

risk analysis, a great deal of information is brainstormed, and during workshops and discussions,

different people (users, system developers, analysts, system managers), with different expertise in

different fields come together, give their opinions and share information. A way in which all the par-

ticipants can communicate efficiently and understand each other must therefore exist and a UML

profile, proposed by the CORAS project, is used to achieve this. The framework has four main

pillars, of which risk management is one. In CORAS, the final result on which decisions can be

based is the UML class diagrams of each asset. Details on the approach can be found at [22, 23].

• NIST SP 800-30 provides a flexible approach on risk assessment methodologies. This methodol-

ogy can be quantitative, semi-quantitative or qualitative. This iterative methodology can be broken

down into nine different steps, however, some can be conducted in parallel: system characteri-

zation; threat identification; vulnerability identification; control analysis; likelihood determination;

impact analysis; risk determination; control recommendations; results documentation [24]. This

methodology requires commitment from more than the usual IT personnel, for instance from the

senior management. The final result in NIST SP 800-30 is a formal report. This report should

contain information for companies decision makers about risk, so they can allocate resources to

reduce and/or correct potential losses.

A risk analysis process can be quite expensive for a company. However, there are so many options it

is difficult to know which methodology is the best option. Choosing the correct methodology is crucial for

a good analysis, in fact the decision is considered so important that decision frameworks have already

been developed to make it simpler [25]. Frameworks to compare different information risk analysis

methodologies usually rate methodologies using different criteria. Companies assess their needs, and

attribute weight to each criterion. In the end the choice is made using an overall total value derived from

the criterion’s [20].

2.2.3 Risk rating methodologies

Risk rating is the process of estimating and assigning a value/category of severity to a risk. There are

numerous risk rating methodologies currently in use. We will only focus on two in this section. These

methodologies take part in risk analysis enabling to estimate the severity of a risk to the business. Their

importance is supported by the time saved and priorities well defined by having a system able to rate

risks.

Microsoft DREAD

Microsoft uses the DREAD risk rating methodology [17]. The method is applied to each risk identified

by the risk assessment or threat modeling process [18].

13

• Damage potential — The extent of damage that occurs if a vulnerability is exploited.

• Reproducility — How often an attempt at exploiting a vulnerability really works.

• Exploitability — The effort required to exploit the vulnerability.

• Affected Users — Installed instances of the system that would be affected if an exploit became

widely available.

• Discoverability — likelihood that, if unpatched, a vulnerability will be found by external entities.

Using a scale from zero to ten to rate each category (one being the least probability of the occurrence

actually happening along with the least damage potential and ten being the exact opposite), we calculate

the risk to the system using Equation 2.2:

Risk =D + R + E +A+D

5(2.2)

The calculation always produces a number between 0 and 10 with higher numbers representing risks

that are more serious to the total system.

OWASP risk rating methodology

The OWASP risk rating methodology is adaptable and applicable to most organizations and/or systems

[26]. Their approach starts with a risk equation, Equation 3, which is different from the more common

risk equation, Equation 2.1. This difference is due to the fact that OWASP considers likelihood the

combination of threat level and vulnerability level. Its calculation will measure those separately.

Risk = Likelihood ∗ Impact (2.3)

The methodology can be broken down into six different steps [27]:

1. Identify Risk

2. Estimate likelihood factors

3. Estimate impact factors

4. Determine severity of risk

5. Decide what to fix

6. Customize risk rating model

The first step consists in identifying a security risk that needs to be rated. Information must be gathered

about the threat agent involved, the attack that will be used, the vulnerability involved, and the impact of

a successful exploit on the business.

14

Overall Risk Severity

Impact

High Medium High CriticalMedium Low Medium HighLow Low Low Medium

Low Medium HighLikelihood

Table 2.2: Overall risk severity table [27]

Once the risk has been identified the following step is to estimate its likelihood, generally identifying

if whether the likelihood is low, medium or high is sufficient. Although there are a number of factors to

determinate likelihood, they can be separated in two distinct groups: threat agent factors and vulnera-

bility factors. Each of these factors has a rating number associated from zero to nine. The threat agent

factors are: skill level, motive, opportunity, and size. The vulnerability factors are: ease of discovery,

ease of exploit, awareness, intrusion detection. The numbers are used to calculate the overall likelihood

by simply calculating their average.

The third step is estimating the impact of a risk. When considering the impact of a successful attack,

it is important to realize that there are two kinds of impacts. The first is the technical impact on the

application, the data it uses, and the functions it provides. The other is the business impact on the

business and company operating the application [27]. As in the step two there are multiple factors rated

from zero to nine, which can also be broken down into two separate groups: technical impact factors

(loss of confidentiality, loss of integrity, loss of availability, loss of accountability) and business impact

factors (financial damage, reputation damage, non-compliance, privacy violation). The overall impact is

also calculated using the average of rating in each factor.

In order to determine the severity of a risk, the evaluator utilizes the overall impact and likelihood as

well as the rating system described on Table 2.2. Scores from zero to two are considered low, three to

five are considered medium, and six to nine are considered high.

After the risks have been classified, they must be prioritized. As a general rule, the most severe risks

have higher priority. However, sometimes it can be different for specific situations [26].

The sixth step is the customization of the risk rating model. It is optional, however of great importance.

The customization of the methodology to a business is critical for optimal adoption. A tailored model is

more likely to produce results that match people perceptions about what a serious risk is [27]. An

example of customization could be weighting factors differently, or adding new ones.

Table 2.3 summarizes the risk methodologies we presented.

2.3 Tops of Risks

Tops are a good way to represent a subject in a summarized and concise manner. Today, this is partic-

ularly useful feature due to society’s lack of time. Tops are an ordered list used to represent the most

1Turkey National Research Institute of Electronics and Cryptology2Gebze Institute of Technology

15

Name Type # of steps Organization ReferenceOCTAVE Qualitative 8 CERT [21]ISRAM Quantitative 7 UEKAE1 and GYTE2 [19]CORA Quantitative 2 I.S.T. [20]CORAS Qualitative 8 European research project [22]NIST SP 800-30 undefined 9 NIST [24]DREAD Quantitative 2 Microsoft [18]OWASP risk rating Quantitative 6 OWASP [26]

Table 2.3: Summary of the risk methodologies presented

relevant elements of their subject. The most commonly used are Top 10’s. Tops can be organized by

any criterion, so tops of the same subject can be completely different.

Tops of risk use as criteria the risk obtained from a risk analysis. Due to the sizable number of risk

analysis methodologies, as explained in Section 2.2.2, tops of risk can be subjective. One must be

aware of the methodology taken to compile the top in order to be able to utilize it.

The following section will cover some of the latest cybersecurity and privacy related top’s of risk.

Healthcare tops are also covered in Section 2.3.2. However, more focus is given to IT-related risks.

2.3.1 Cybersecurity and privacy

Cybersecurity addresses many challenges to protect digital information. Tops on cybersecurity are a

powerful awareness document for companies, due to their conciseness on such an extensive topic.

OWASP the ten most critical Web application security risks

Analyzing a large set of recent attacks we may conclude that Web applications are a big contributor to

privacy breaches. This Top follows a series that started in 2003. The current is the 2013 edition, which is

based on eight data sets from seven firms that specialize in application security, including four consulting

companies and three tool/SaaS vendors (1 static, 1 dynamic, and 1 with both). This data spans over

500,000 vulnerabilities across hundreds of organizations and thousands of applications. The risk rating

methodology for this top 10 is based on OWASP risk rating methodology presented in Section 2.2.3. For

each item, they estimated the typical risk that each weakness introduces to a typical web application by

looking at common likelihood factors and impact factors for each common weakness. Considering a top

must be about classes of risk rather than specific vulnerabilities, their considered likelihood factors were

prevalence, detectability, and exploitability. Only one impact factor was considered, technical impact

[28].

The typical risk is calculated using a prevalence value, deduced from supplied statistics from a num-

ber of different organizations, then combined with detectability and exploitability factors. The method for

this combination is not clear neither is how detectability and exploitability factors are estimated. Lastly

this result is multiplied by a estimated average of technical impact for each vulnerability. The rank order-

ing for the top 10 is according to the previously calculated value of risk. The most critical Web application

security risks top compiled by OWASP is the following [28]:

16

1. Injection

2. Broken authentication and session management

3. Cross-site scripting (XSS)

4. Insecure direct object references

5. Security misconfiguration

6. Sensitive data exposure

7. Missing function level access control

8. Cross-site request forgery (CSRF)

9. Using known vulnerable components

10. Unvalidated redirects and forwards

The primary aim of the OWASP Top is to educate developers, designers, architects, managers, and

organizations about the consequences of the most important web application security weaknesses in a

simple way, and how to prevent them [28].

Top ten database security threats

Another asset that constantly compromises privacy are databases. According to Verizon it was the most

compromised asset of 2015 [29]. The reason databases are targeted so often is quite simple: they are

at the heart of any organization, storing customer records and other confidential business data. The top

ten database security threats was compiled by Imperva and is the following:

1. Excessive and unused privileges

2. Privilege abuse

3. Input injection

4. Malware

5. Weak audit trail

6. Storage media exposure

7. Exploitation of vulnerabilities and misconfigured databases

8. Unmanaged sensitive data

9. Denial of service

10. Limited security expertise and education

17

The criteria used to create this rank is not fully clear. As far as it was possible to understand, it was

based on an analysis of the threats faced by companies in previous and current years. The goal of the

top is to aid companies to defend themselves against these kind of problems, using prior knowledge

[30].

Top nine cloud computing threats

At an unprecedented pace, cloud computing has simultaneously transformed business and government,

and created new security challenges. The use of cloud computing technologies has created new secu-

rity vulnerabilities. The shift to cloud technologies can make a business vulnerable to security breaches.

Recognizing both the promise of cloud computing, and the risks associated with it, the Cloud Security

Alliance (CSA) has pioneered the creation of industry-wide standards for effective cloud security, as well

as, a top of cloud computing threats. The goal of this top is to provide organizations with an up-to-date,

expert-informed understanding of cloud security threats in order to make educated risk-management

decisions regarding cloud adoption strategies [31]. The methodology used to compile this top was the

conduction of a survey to industry experts about their professional opinion on the greatest vulnerabili-

ties within cloud computing. The Top Threats working group used these survey results alongside their

expertise to craft the final 2013 report [31]:

1. Data breaches

2. Data loss

3. Account hijacking

4. Insecure APIs


6. Malicious insiders

7. Abuse of cloud services

8. Insufficient due diligence

9. Shared technology issues

OWASP the mobile top ten

In Section 2.1.2 we mentioned the Internet of Things, which similarity to the Cloud is an area in great

expansion. Mobile devices are a critical element of the Internet of Things, and they create opportunity for

numerous security breaches. This top is intended to help developers and non-mobile IT security people

to prevent possible attacks, using experts opinion alongside past events on multiple companies [32, 33]:

1. Weak server side controls

18

2. Insecure data storage

3. Insufficient transport layer protection

4. Unintended data leakage

5. Poor authorization and authentication

6. Broken cryptography

7. Client side injection

8. Security decisions via untrusted inputs

9. Improper session handling

10. Lack of binary protections

OWASP developers use their own risk rating methodology explained in Section 2.2.3 to calculate the

risk. They select and prioritize the items for the top according to: likelihood of an application having that

vulnerability; likelihood of discovery of that vulnerability; likelihood of an attacker successfully exploiting

that vulnerability; typical technical impact if that vulnerability is successfully exploited. The data sources

used to compile the top were provided by multiple companies such as: Aspect Security, HP, Minded

Security.

2.3.2 Healthcare

Lately, the healthcare industry continues to undergo many changes, with the increasing role of technol-

ogy in all aspects of healthcare [34], something that previously happened in other industries such as

the financial [35]. IT-related risks are increasingly ranked higher in the top of concerns from healthcare

industry leaders. These concerns are certainly not misplaced, and should be addressed with a more

comprehensive use of IT, leading to a more mature use of IT governance [35]. Therefore a few tops of

healthcare risks appeared.

Critical risks facing the healthcare industry

This top of risks for the healthcare industry compiled by Diane Doherty and Renee Carino, shows that

two out of the eleven critical issues are IT-related, and they are highly ranked [36].

1. Preparedness for pandemics

2. Violent incidents in hospitals

3. Healthcare reform/physician integration

4. Disruptive staff behavior

5. Telemedicine

19

6. Cyber risk

7. Environmental pollutants

8. Emergency preparedness

9. Alarm fatigue

10. Obesity epidemic

11. Healthcare-associated infections

Ranked fifth, there is telemedicine, which consists in the use of technology such as interactive video

and email to communicate with patients, as well as gathering information remotely through the trans-

mission of diagnostic images and test results. Many of today’s monitoring devices also allow doctors to

remotely collect information about patients who are in the intensive care unit or at home. While this can

provide patients with better access to healthcare and offer physicians more detailed information in less

time than ever, healthcare professionals should keep in mind the risks [36]. These risks include breaches

of patients privacy, negligence in the patients care, and non-compliance with regulatory requirements.

The sixth place is cyber risk. As the healthcare industry increasingly relies on technology new cyber

threats arise. From the adoption of electronic health records, which led to an increase in data breaches,

to specific attacks on medical devices, healthcare is the target of many cyber criminals.

The top was compiled from articles on healthcare, and the authors’ opinion. The opinions expressed

are the authors’ own and not necessarily those of any affiliated company. The same is applied to the

rank ordering.

Top 20 IT risks for the healthcare industry

IT-related threats tend to appear and change very rapidly, making them harder to assess. However,

CHAN healthcare compiled a top of IT-related risks for the healthcare industry. The data used was ob-

tained from an evaluation of risk assessments from 13 health systems in 33 states of the United States.

Based on two primary factors in determining healthcare organizations risk profiles — strategic and busi-

ness impact and business environment complexity — the following risk areas have been identified as

the top 20 [34]:

1. Health information exchange – Patients and health informations are made available across orga-

nizations, privacy and data security concerns arise.

2. Meaningful use (MU) – Minimum U.S. government standards for using EHR, and for exchanging

patient clinical data between healthcare providers, insurers, and patients. The non-compliance

with such standards leads to refunding federal funds received for the EHR program.

3. Data warehousing – Data is often stored and made available in a data warehouse, so both the

warehouse and the transfer interfaces must be equally secure and accurate at minimizing risk.

20

4. ICD-10 transition – ICD-10 is a medical classification list by the World Health Organization. The

implementation of the transition between the current system and ICD-10 must be properly coded

and tested, but the latest extension of the deadline made companies neglect its preparation.

5. Accountable care organizations and Clinically Integrated Networks – Most organizations now are

involved in ACOs or clinically integrated networks (CINs) in some way, and risks continue to multiply

as participating organizations are forced to share data. Consistent security, privacy, and related

practices will be hashed out and agreed upon during due diligence and negotiations.

6. Disaster recovery and business continuity – Two related concepts which can translate to an orga-

nization’s preparation for unforeseen risks to continued operation.

7. Biomedical devices – Unidentified security vulnerabilities in biomedical devices can affect patient

safety as well as the privacy of data on devices and networked systems.

8. System implementation – Many healthcare organizations are susceptible to risks related to the

implementation of electronic health record (EHR), financial, and other business systems.

9. HIPAA security – Organizations must have comprehensive policies and procedures in place to

comply with Health Insurance Portability and Accountability Act3 (HIPAA) requirements.

10. Asset management and software licensing – Many organizations have issues with tracking not only

their physical IT assets but their software licenses as well. Lack of control in these areas can lead

to financial losses for the organization.

11. IT governance – IT leadership must establish adequate policies and procedures and involve stake-

holders from other departments in decision-making. If they do not, problems can arise behind the

scenes that could force the organization into a costly position.

12. Network security – Networks can be vulnerable to external and/or internal attacks if security mea-

sures are not in place. Vulnerable networks do not ensure integrity or confidentiality of the trans-

mitted data. This can carry negative consequences to both patient safety and staff productivity.

13. Data loss prevention – Electronic protected health information4 (ePHI) and similarly sensitive data

can be disclosed to unauthorized personnel either by malicious intent or inadvertent mistake.

14. Third-party vendor oversight – The growing prevalence of third-party vendors in healthcare has

expanded organizations potential liability. Organizations must verify that their vendors comply with

the organizations policies and procedures as well as with the applicable legal requirements.

15. Mobile devices – Security for mobile devices that connect to an organization’s network, system, or

data is critical for protection of ePHI.

3United States legislation that provides data privacy and security provisions for safeguarding medical information.4Personal health information that is covered under HIPAA security regulations and is produced, saved, transferred or received

in an electronic form.

21

Top Numrisks

Target Impactconsid-ered

Risk rank-ing method

Data sources Author Ref

OWASP the ten mostcritical Web applicationsecurity risks

10 Web appli-cations

Technical OWASPrisk ratingmeth.

Several firms spe-cialized in applica-tion security

OWASP [28]

Top ten database secu-rity threats

10 Databasesystems

unknown unknown Imperva ApplicationDefense Center

Imperva [30]

Top nine cloud comput-ing threats

9 Cloud sys-tems

unknown Authors’opinion

Surveys to industryexperts

Cloud Se-curity Al-liance

[31]

OWASP the mobile topten

10 Mobile ap-plications

Technical OWASPrisk ratingmeth.

Polls from severalcompanies in the in-dustry

OWASP [33]

Critical risks facing thehealthcare industry

11 Healthcareindustry

unknown Authors’opinion

Healthcare articles ACEGroup

[36]

Top 20 IT risks for thehealthcare industry

20 Healthcareindustry

Strategicand busi-ness

unknown Risk assessementfrom 13 healthsystems

CHANHealth-care

[34]

Table 2.4: Summary of the presented tops

16. Project management – Numerous competing IT priorities must be effectively managed in order to

avoid cost overruns and late project completion.

17. Interfaces – With numerous system implementations going on, there is increased risk that inter-

faced data flowing between systems is not accurate and complete. Interface issues can adversely

affect patient care and revenue recognition.

18. System access and user provisioning – Healthcare organizations often struggle to maintain con-

sistent core controls around system access. Provisioning is granting the right type of access to the

right user, it also comes up regularly has a problem.

19. Shadow IT – Shadow IT refers to applications that are administered outside of the IT department.

These applications can lack core controls in many areas.

20. Payment card industry data security standard (PCI DSS) – PCI DSS applies to all entities that

store, process, or transmit credit cardholder data. The standard, which outlines technical and

operational system requirements to protect cardholder data, is often overlooked.

Some of these risks might not yet be addressed on some organizations, however, they probably

should [34]. CHAN healthcare top provides a good insight on current threats, mitigating them is made

easier with the clarity and exposure provided by the top.

Table 2.4 summarizes the information about the tops we presented.

2.4 Portuguese Healthcare Sector

This section tries to capture the structure of the Portuguese healthcare sector in terms of cybersecurity,

justify our lack of information about it, and how the sector is moving foward. It is divided into two smaller

sections for increased clarity.

22

2.4.1 Current structure

Portugal has a healthcare sector with a large public participation [37]. The ministry of health has an entity

called Servicos Partilhados do Ministerio da Saude (SPMS) which provides guidelines, best practices,

and identifies challenges and competencies in the sector. The importance of this entity for our context

is high, because it creates the directives about information systems security.

Although Portugal has this transversal entity, SPMS, it does not enforce specific procedures, which

leads us to the lack of available information about the sector state of the art. Each local institution (hospi-

tals, clinics) is responsible for their own security. They interpret these guidelines and best practices, and

deploy solutions they see fit. In this structure, each institution can have different measures and systems

in place, and information about which is being used is not public. Also, materials such as risk analysis

previously conducted, former vulnerabilities lists, or any other report about cybersecurity are private to

the organizations and not available.

There were no regulations in Portugal enforcing the need of publicly communicating breaches or

security incidents, unlike other countries such as the U.S. [38]. This changed with the approval of

the new data protection regulation in 2016, which enforces the need of communicating such incidents.

However, this regulation is only in full effect in 2018.

For the previous reasons information about cybersecurity in the Portuguese healthcare sector are

difficult to find. Nevertheless, one can expect the sector to have cyber hygiene measures in place

[39], such as controlled use of administrative privileges or inventories of authorized and unauthorized

devices. Sectors tend to be somewhat alike, and if considering so, Portugal should also suffer from the

vulnerabilities other countries have.

2.4.2 Evolution of this status

Concerns about cybersecurity are growing all over the world, and Portugal also follows this trend. The

adoption of the new European privacy regulation [40] will benefit the sector in terms of data privacy.

However, there are other concerns such as the lack of adoption of best pratices by local instituions, or

the lack of cooperation between them which could lead to several institutions being affected by the same

problem.

There are solutions being developed by the SPMS, for example, their future dashboard which is

thoroughly explained at [39].

This dashboard tries to provide overall information about the Nation Health System regarding risk

and security, information about the maturity of each local institution in terms of good pratices, and also

tries to promote continous improvement, and to prepare audit/assurance initiatives to institutions.

This initiative generally consists of a risk and security documentation repository. Local institutions

can assess their maturity level in implementing good pratices, and that is shared with SPMS.

SPMS will produce what they call good pratices activation kits, which consists of informations about

the requirements, maturity models, templates/guidelines and metrics that need to be provided by local

institutions to populate risk and security dashboard. Kits about cybersecurity will be a starting point [41].

23

This initiative will allow for both SPMS and the local institutions to understand what good pratices are

they missing and how to implement them, as well as to measure their state.

24

Chapter 3

Project Development

This chapter is divided into two parts. The first is about the top 10, where we present all the steps we

took to achieve it. From the preparation to the result. The second describes the processes behind our

cyber attack demonstrations, which represent identified risks by our analysis.

3.1 Top 10

The following section is divided according to the major steps that we took to achieve our top 10 of

cyber risks. The first section covers the preliminary interviews, followed by the scope definition. The

third section is the most extensive with the in-depth description of our risk analysis. The fourth is the

description of another interview round, in which we gathered feedback for the last step, the compilation

of the final top 10 of cyber risks.

3.1.1 Preliminary interviews

The preliminary interviews were a way to validate our methodology and future plans.

We prepared an overview of our thesis, which consisted of a brief explanation of the following topics:

• What the thesis consisted of, and why we are doing it;

• OWASP risk rating methodology;

• Top 10 of risks: benefits and constraints;

• Video demonstration: structure, goal, benefits and constraints.

Following the overview of our thesis, we had some open answer questions:

1. Do you consider the presentation of the cyber risk analysis in a top 10 format adequate?

2. Do you think the top 10 of cyber risks is usable in the future by this sector?

3. Do you think the video demonstrations are useful as a extra awareness raising tool?

25

4. Considering the structure for the video demonstration I presented, any criticism or suggestion?

5. Are there any resources that you could recommend me about the current sector state? e.g. previ-

ous cyber risk analysis, previous cyber attack data...

6. Do you recommend me having this conversation with someone else, in order to gather more infor-

mation before starting the development?

We interviewed three people. Without the permission to reveal names, two of them are part of SPMS,

and the other an IT director of a major Lisbon hospital group.

The first question answers were not all identical. Two of the three interviewees agreed to the top 10

format, the other argued that there were still some considerable downsides, such as only referencing

ten cyber risks.

In the second question all three interviewees considered the top 10 usable in the future, although

one showed some concerns about the methodology used being OWASP.

The third question had unanimous feedback. Every interviewee considered the attack demonstra-

tions a very good way to raise awareness to this matter.

The fourth question also had unanimous feedback, with every interviewee agreeing to the proposed

demonstration structure. The only suggestion made, the same by two of the three interviewees, was to

make this cyber attack on a real target e.g. a Portuguese hospital, instead of a sandbox environment to

motivate the nonbelievers that the threat is real.

In the fifth question no resources were recommended by any of the interviewees. The reason for

this is that due to regulations these resources are confidential, and not made available outside these

organizations.

For the last question, the interviewees recommended other individuals that were already in our list,

so it did not expand our candidate pool.

From these initial interviews we concluded that our plan made sense, and validated our top 10 idea.

Also we tried taking in consideration real targets for our attack demonstration.

3.1.2 Scope definition

The project started with a scope definition, a very important step as it serves as a base for the risk

analysis. In this step we established which assets exist in the industry, which of those assets depend

on IT to function properly, possible threats, attacks types, and vulnerabilities. To aid us in the scope

definition we used the work surveyed in Chapter 2, but also extra resources such as [42, 43]

3.1.2.1 Assets

Bellow we enumerate the primary assets found within the healthcare sector. Some are patient specific

which we consider the highest priority asset to protect, others indirectly affect patients, and there is also

assets that do not affect patients in any way but affect the organization. Attacks against these assets can

26

disrupt patient care, affect the organization in financial, reputation or other ways, or even have effects on

patients safety.

• Electronic medical devices, both active and passive devices;

• Electronic business devices e.g. servers, computers, power equipment;

• Healthcare personnel, both involved in patient care or in other activities;

• Software applications;

• Service availability;

• Patient health;

• Patient information e.g. electronic health records;

• Intellectual property and proprietary information.

3.1.2.2 Threats

In addition to the identification of assets, it is crucial to identify the adversaries. Although not every

healthcare facility may face the same adversaries, bellow we enumerate all the threats we consider to

be relevant in this sector, along with a brief summary of each threat.

• Nation states;

• Terrorists;

• Organized crime;

• Internal personnel;

• Individual/groups of hackers;

• Business rivals e.g. other hospitals, clinics;

• Companies e.g. insurers, banks, pharmaceuticals;

• External suppliers.

Nation states

This threat is very powerful, because of their high technical skills and resources. They can be mo-

tivated by many factors, and may target either organizations information, patients’ health, patients’ in-

formation, or all the above. Although not every healthcare facility is relevant enough for a nation state

interest, a visit of a high profile individual can motivate it.

Attack example: A nation state may utilize some software vulnerability to harm a important represen-

tative of another nation state, in order to cause mayhem.

Terrorists

27

This threat is usually motivated to cause harm. Their attacks are usually untargeted, but can be

targeted in specific situations. They tend to target assets such as patients’ health, or service availability.

Terrorists are highly skilled due to the resources to hire such skill.

Attack example: Terrorists may target a hospital, denying service availability in order to harm people.

Organized crime

Motivated by financial gains, organized crime can either target information or patient safety. Skilled

and resourceful funded by the black market, are a considerable threat to most healthcare assets if hired

to attack them.

Attack example: Someone may hire an attacker to harm a patient staying in a hospital.

Internal personnel

Normally less skilled, although this is compensated by their ease of access. Internal personnel

poses a threat to several healthcare assets, such as patients’ information or intellectual property. In

some special cases they can even pose a threat to patients’ safety. They can be motivated by either

financial gains or personal vendettas.

Attack example: An unhappy IT department member can insert a malware to steal, and later sell

patient confidential information in the black market.

Individual/groups of hackers

This is a very generalized threat, however hackers have high technical skills. They are motivated by

financial gains or just reputation. They are likely to target information of any kind but not cause warm to

patient safety.

Attack example: A hacker may find a vulnerability in a healthcare network, and exploit it to steal

confidential information.

Business rivals

Business rivals have considerable resources, and may hire the technical talent. They are motivated

by the competitive advantage they can get, and are likely to target service availability or other asset

which causes loss of reputation. Portugal has a large public healthcare sector so it is more unlikely to

happen.

Attack example: A hospital may hire individuals to attack a competitor with the intent of disrupting

service availability, in order to damage their reputation and gain a competitive advantage over them.

Companies

Companies associated with the healthcare can gain financial advantages. They lack technical skills,

but they make up for it in resources. They are likely to target information.

Attack example: A insurer may hire an attacker to steal confidential patient information in order to

accept or deny to insure an individual.

External suppliers

Depending on the supplier, they can have ease of access and technical skills. They are motivated by

financial gains, and likely to target information. Although they can also target patients’ safety.

Attack example: An external software supplier may insert a backdoor or a vulnerability, that he can

later explore to gain access to confidential information or harm a patient.

28

Bellow we present a summary table of all threats.

Threat attributes Nation states Terrorists Organized crime Internal personnel Hackers Business rivals Companies External suppliers

Skill level

Security penetration skills X X XNetwork and programming skills X XSome technical skills XNo technical skills X X

MotiveLow or no reward X XPossible reward X X X X X XHigh reward

SizeSmall X X X X XMedium X XBig X

Objective

Steal X X XDestroy XDeny X XDamageAll of the above/ Don’t care X X X X

Resources

Individual X XTeam X XOrganization X X X XGovernment X

Table 3.1: A summary of the threat agents profile

3.1.2.3 Vulnerabilities

We used data from our related work, and former attacks on other countries to gather a list of possible

vulnerabilities that exist on the healthcare sector:

• Physical access to critical hospital assets lack proper control;

• Insufficient/ineffective access controls;

• Use of improper/lack of authentication methods - e.g. shared credentials, default configurations;

• Use of many different personal devices by healthcare personnel on professional activities;

• Lack of well-defined IT security policies for the treatment of patient data;

• Lack of well-defined IT security policies for healthcare devices;

• Lack of proper password management;

• Absence/lack of regular periodic risk analysis;

• Absence/lack of regular auditing procedures;

• Absence/lack of logging and monitoring;

• Absence/lack of penetration tests;

• Absence of a responsible for IT security - e.g. CSO;

• Absence of an individual/team responsible for cybersecurity full time;

• Absence of measures against theft/loss of devices with private data;

• Absence/shortage of metrics and indicators for periodic evaluations;

• Lack of training about good security practices;

• Storage and communication of unencrypted private data;

29

• Absence of mechanisms to support high availability - e.g. replication;

• Absence/shortage of backup mechanisms;

• Absence of an inventory of every software, hardware, company and individual with access to

healthcare devices and/or private information;

• Absence of regulations and certified processes ensuring security and data protection for soft-

ware/hardware manufacturers;

• Use of legacy/unpatched systems;

• Software vulnerabilities;

• Absence of coordination between entities to share common problems or past incident’s informa-

tion;

• Network vulnerabilities.

From this quite extensive list, we shortened it to ten items by clustering some specific vulnerabilities

into bigger categories, and also by abandoning some that we did not consider relevant enough. Follow-

ing we explain this clustering, by showing the name of the new vulnerability followed by a item list of the

vulnerabilities contained on it.

Lack of active protection measures

• Absence/lack of regular periodic risk analysis;

• Absence/lack of regular auditing procedures;

• Absence/lack of logging and monitoring;

• Absence/lack of penetration tests;

• Absence/shortage of metrics and indicators for periodic evaluations.

Lack of adequate security personnel

• Absence of a responsible for IT security - e.g. CSO;

• Absence of an individual/team responsible for cybersecurity full time.

Mobile devices

• Use of many different personal devices by healthcare personnel on professional activities;

• Absence of measures against theft/loss of devices with private data.

Compromising medical devices

• Lack of well-defined IT security policies for healthcare devices;

30

• Absence of regulations and certified processes ensuring security and data protection for soft-

ware/hardware manufacturers.

Unauthorized system access

• Insufficient/ineffective access controls;

• Use of improper/lack of authentication methods - e.g. shared credentials, default configurations;

• Lack of proper password management.

Denial of service and business continuity

• Absence of mechanisms to support high availability - e.g. replication;

• Absence/shortage of backup mechanisms.

3.1.2.4 Attack types

Attacks can be targeted or untargeted, unsophisticated or advanced. But they can be divided into four

different categories:

• Denial of service;

• Confidential data theft;

• Data tampering;

• Hardware/software integrity violation.

3.1.3 Risk analysis

The methodology we followed to perform this risk analysis was the OWASP risk rating methodology,

which we already covered in Section 2.2.3. In summary this methodology attempts to rate the severity of

risks after they have been identified, based on different factors such as threat, vulnerability and impact

factors. We estimate these factor values based on categories, and calculate the result.

However, this methodology is customizable and we took advantage of it. We made some changes

to best suite our sector. We removed a factor, loss of accountability, from the technical impact factors

since we do not think it adds any value to our analysis. We also added one impact factor, patient health,

in a new category which we created called patient safety. These changes in factors altered the way we

calculate the overall impact: it is still the average of the technical and business factors but it also uses the

patient health factor with a multiplier of 2. The reasons behind this multiplier of 2 are our intent of making

our analysis more focused on patient impact than business or technical impact, and the importance of

the safety of patients. Bellow we provide an example.

For this table the overall impact calculation is represented by Equation 3.1.

Overall impact = (4.6 + 4.5 + 2 ∗ 6)/4 (3.1)

31

Technical impact Business impact Patient safetyLoss of confidentiality Loss of integrity Loss of availability Financial damage Reputation damage Non-compliance Privacy violation Patient health

6 3 5 3 5 5 5 6Overall technical impact: 4.6 Overall business impact: 4.5

Overall impact: 5.3

Table 3.2: Example of an impact table

Before going in depth into the analysis steps, we describe the categories we used to assign the

numbers for each of these factors: skill level, motive, opportunity, size, ease of discovery, ease of

exploit, awareness, intrusion detection, loss of confidentiality, loss of integrity, loss of availability, financial

damage, reputation damage, non-compliance, privacy violation, and patient health.

Most of them are the default categories from OWASP risk rating methodology [26], however some

we tailored to best suite our analysis. We make this description with the intent of making the analysis

easier to understand.

Threat agent factors

• Skill level: How technically skilled is this group of threat agents? Security penetration skills (9),

network and programming skills (6), advanced computer user (5), some technical skills (3), no

technical skills (1);

• Motive: How motivated is this group of threat agents to find and exploit this vulnerability? Low or

no reward (1), possible reward (4), high reward (9);

• Opportunity: What resources and opportunities are required for this group of threat agents to find

and exploit this vulnerability? Full access or expensive resources required (0), special access or

resources required (4), some access or resources required (7), no access or resources required

(9);

• Size: How large is this group of threat agents? Any hacker in the Internet (9), Someone with

physical access (4).

Vulnerability factors

• Ease of discovery: How easy is it for this group of threat agents to discover this vulnerability?

Practically impossible (1), difficult (3), easy (7), automated tools available (9);

• Ease of exploit: How easy is it for this group of threat agents to actually exploit this vulnerability?

Theoretical (1), difficult (3), easy (5), automated tools available (9);

• Awareness: How well known is this vulnerability to this group of threat agents? Unknown (1),

hidden (4), obvious (6), public knowledge (9);

• Intrusion detection: How likely is an exploit to be detected? Active detection in application (1),

logged and reviewed (3), logged without review (8), not logged (9).

Technical impact factors

32

• Loss of confidentiality: How much data could be disclosed and how sensitive is it? Minimal

non-sensitive data disclosed (2), minimal critical data disclosed (6), extensive non-sensitive data

disclosed (6), extensive critical data disclosed (7), all data disclosed (9);

• Loss of integrity: How much data could be corrupted and how damaged is it? Minimal slightly

corrupt data (1), minimal seriously corrupt data (3), extensive slightly corrupt data (5), extensive

seriously corrupt data (7), all data totally corrupt (9);

• Loss of availability: How much service could be lost and how vital is it? Minimal secondary

services interrupted (1), minimal primary services interrupted (5), extensive secondary services

interrupted (5), extensive primary services interrupted (7), all services completely lost (9).

Business impact factors

• Financial damage: How much financial damage will result from an exploit? Less than the cost

to fix the vulnerability (1), minor effect on annual profit (3), significant effect on annual profit (7),

bankruptcy (9);

• Reputation damage: Would an exploit result in reputation damage that would harm the business?

Minimal damage (1), Loss of major accounts (4), loss of goodwill (5), brand damage (9);

• Non-compliance: How much exposure does non-compliance introduce? Minor violation (2), clear

violation (5), high profile violation (7);

• Privacy violation: How much personally identifiable information could be disclosed? One individ-

ual (3), hundreds of people (5), thousands of people (7), millions of people (9).

Patient safety factors

• Patient health What would be the damage to patients health incase of an exploit? Minimal dam-

ages (3), intermediate damages (5), serious damages (7), death (9).

The first step to perform our analysis was to cross-reference our vulnerabilities with our threats.

However, in this step we encountered our first problem. This cross-referencing was going to produce a

massive number of tables. In order to solve this problem we analyzed our threats and decided to use a

single threat that we called skilled and motivated attacker. Nevertheless, we still reference which specific

threats are relevant for each risk, and if the calculations of the severity categories change based on a

specific threat we make reference to it.

Another fact worth mentioning in our analysis is that we already took in consideration the new Euro-

pean data protection regulation approved in 2016, and to be in full effect in 2018 [40]. We are assuming

that all mandatory security mechanisms are deployed in the organizations when this regulation is in full

effect, even if that is not true today. This new regulation adds security measures in the storage and

communications of data, demands the existence of a data protection officer, makes data breaches com-

munication mandatory, among others. Although these security measures must be justified by scope,

33

data nature, financial indicators, and other factors, in the healthcare sector most of them will be manda-

tory. In our risk analysis these measures are most noticeable by the low loss of integrity values attributed,

because of the backup measures for important data in the regulation. They do not influence other factors

as much, such as loss of confidentiality or loss of availability, because the confidential data can be ac-

cessed by other means such as unauthorized systems access. And availability can be affected without

the influencing data.

Based on our previously presented scope, we compiled a list of 10 risks. These risks resulted from

the cross-referencing of our identified vulnerabilities with healthcare assets. When we recognize that a

vulnerability could have an impact in one or more assets, we identify it as a risk. The lists of vulnerabilities

and assets are defined in Section 3.2.2. The 10 risks are the following:

• Physical access to servers;

• Social engineering;

• Mobile devices;

• Software vulnerabilities;

• Network vulnerabilities;

• Denial of service and business continuity;

• Compromising medical devices;

• Unauthorized systems access;

• Lack of active protection measures;

• Lack of adequate security personnel.

Bellow we are going to present each risk followed by relevant threats, attack types, environments, and

calculations. We present the risks in the order we did the analysis, not in the order they eventually

become listed in the top.

3.1.3.1 Physical access to servers

The calculations for each level (threat level, vulnerability level, and impact level) are based on the factors

value on the two tables presented for each risk (Table 3.3 and Table 3.4 for this risk). Threat level is the

overall threat, vulnerability level is the overall vulnerability, and impact level is the overall impact. Risk

severity is the average of these levels. For every risk, we provide a justification of the values after the

tables. For this first risk, we do an exception and present a more detailed explanation before the tables.

A generalized threat, skilled and motivated attacker, was used for the calculations. Aside from inter-

nal personnel, all threats would produce equivalent overall threat levels and consequently risk severity.

Internal personnel have better opportunity. This leads to an increase in threat level to high, however

maintaining the same overall risk severity.

34

Value attribution justification: Regarding threat agent factors, the skill level is very high for our

generic attacker (Skill level: 9). The value for motive is justified by the possible good reward of a

successful attack (Motive: 7), opportunity is low because gaining physical access to specific parts of a

facility is hard (Opportunity: 2). The size factor represents how large is the threat agent group, in this

case as large as users with physical access (Size: 4).

This vulnerability is easily discovered by observation (Ease of discovery: 7), also easily exploited due

to the lack of technical skills and resources required by this threat agent group (Ease of exploit: 5). We

believe the vulnerability is currently hidden, as there is no public discussion of it (Awareness: 4). The

intrusion detection is there, in the form of video surveillance or other mechanisms, although it may not

be reviewed if there is no sign of alarm (Intrusion detection: 7).

The impact of a successful attempt can lead to confidential data disclosure, although the size may

vary (Loss of confidentiality: 6). Loss of integrity can happen, but only on data without a backup, which

is less relevant (Loss of integrity: 3). Availability of services can also be affected (Loss of availability: 5).

Patients’ health can be affected by the loss of availability of services (Patients’ health: 6).

Business impact will also occur. Financial damages to fix the effects of the exploited vulnerability

(Financial damage: 3). Reputation damages are a product of both patient safety impact and technical

impact, and can lead to a loss of faith in the affected organization (Reputation damage: 5). Privacy vio-

lations and non-compliance come from the loss of confidentiality (Non-Compliance: 5 / Privacy violation:

5).

Threat level: Medium (5.5)

Threats: Terrorists, Business rivals, Nation states, Companies, Internal personnel, Organized crime,

Hackers.

Vulnerability level: Medium (5.75)

Vulnerability: Physical access to critical hospital assets lack proper control.

Attack types:


• Hardware/software integrity violation

• Confidential data theft

• Data tampering

Environments:

• Hospitals

• Clinics

• Health centers

• Laboratories

Impact level: Medium (5.3)

Risk Severity: Medium (5.45)

35

LikelihoodThreat Size factors Vulnerability factors

Skill level Motive Opportunity Size Ease of discovery Ease of exploit Awareness Intrusion detection9 7 2 4 7 5 4 7Overall threat: 5.5 Overall vulnerability: 5.75

Overall likelihood: 5.6

Table 3.3: Physical access to servers likelihood table



Overall impact: 5.3

Table 3.4: Physical access to servers impact table

3.1.3.2 Social engineering

Threat level: High (8.25)


Hackers.

A generalized threat, skilled and motivated attacker, was used for the calculations. All threats would

produce equivalent overall threat levels and consequently risk severity.


Vulnerability: Lack of training about good security practices.

Attack types:




• Data tampering

Environments:

• Hospitals

• Clinics

• Health centers

• Laboratories

LikelihoodThreat agent factors Vulnerability factors


Overall likelihood: 7

Table 3.5: Social engineering likelihood table


36


7 3 5 3 3 5 5 4Overall technical impact: 5 Overall business impact: 4

Overall impact: 4.25

Table 3.6: Social engineering impact table


generic attacker, and motive is justified by the possible good reward from a successful attack. Size

is anyone with internet access, and opportunity is high due to the lack of resources/access needed to

exploit this vulnerability.

This vulnerability is hard to discover, because the attacker needs to find the right target with specific

access. The exploitation is easy if the chosen target has some specific characteristics. This kind of

vulnerability is known and currently popular. There are most likely no intrusion detection mechanisms

deployed to prevent it.

The impact of a successful attack depends greatly on the target access, although it can leak many

critical data, affect some data or systems integrity, and deny temporarily the availability of some services.

The denial of service can have patient safety impact, and from this impact reputation damages arise.

Non-compliance and privacy violations come directly from the loss of confidentiality. Financial damages

are a result of any needed fix, non-compliance violations, loss of reputation, or any of the other impacts.


3.1.3.3 Mobile devices

Threat level: Medium (5.75)


Hackers.



Vulnerability level: High (6.5)

Vulnerability: Mobile devices.

Attack types:


Environments:

• Hospitals

• Clinics

• Health centers

Impact level: Low(1.7)


generic attacker, and motive is justified by the possible reward from a successful attack, which are not

37




Table 3.7: Mobile devices likelihood table



Overall impact: 1.7

Table 3.8: Mobile devices impact table

very promissing. The size is users with physical access, and the opportunity factor is medium because

it is still required some special setup in order to make a successful attack.

The vulnerability is pretty easy to discover, either by observation or research. For this threat agent

group it is also easy to exploit, and as been lately. This vulnerability is pretty popular in many industry

sectors, and is likely not to be logged.

The impact from mobile devices is mostly in the loss of confidential data, although normally neither

very senstive nor large amounts.

The business impact is low, with small privacy violation. Because large ammounts of data are not

stored in mobile devices. Although it still represents a minor violation, and so non-compliance. Privacy

breaches always impact institutions reputation’s, and cause financial damages. In very rare cases pa-

tient health can be affected, for instance inducing a doctor in error which gathered patient information

through his mobile device.


3.1.3.4 Software vulnerabilities

Threat level: High (8)


Hackers, External suppliers.




Vulnerability: Software vulnerabilities.

Attack types:




• Data tampering

38

Environments:

• Hospitals

• Clinics

• Health centers

• Laboratories


Skill level Motive Opportunity Size Ease of discovery Ease of exploit Awareness Intrusion detection9 7 7 9 9 5 4 9Overall threat: 8 Overall vulnerability: 6.75


Table 3.9: Software vulnerabilities likelihood table

Impact level: High(6.0)


8 3 7 3 5 5 6 7Overall technical impact: 6 Overall business impact: 4.75

Overall impact: 6.2

Table 3.10: Software vulnerabilities impact table


generic attacker, and motive is justified by the large possible reward from a successful attack. The size

is users with Internet access, and the opportunity factor is high because some resources/access are

needed but not many depending on the vulnerability.

These kinds of vulnerabilities are usually easy to discover due to the existence of many automated

tools. The exploitation difficulty depends vastly on the type of software vulnerability, however for this

threat agent group with high technical skills should be easy. Most of these vulnerabilities are kept

hidden, but there is no intrusion detection system in most cases if one is exploited.

The impact differs from the type of vulnerability, in general it can affect everything: confidentiality,

integrity, and availability. Important data is normally backed up which decreases the integrity impact.

Although software vulnerabilities can greatly affect systems availability and consequently impact both

the business and patient safety. Critical data can be disclosed by a software vulnerability exploitation.

Financial and reputation damages are a consequence of the other impacts. Privacy violation and

non-compliance are a result of the loss of confidentiality.

Risk Severity: High (6.8)

3.1.3.5 Network vulnerabilities

Threat level: High (8)

Threats: Business rivals, Nation states, Companies, Internal personnel, Organized crime, Hackers.



39


Vulnerability: Network vulnerabilities.

Attack types:


• Data tampering

Environments:

• Hospitals

• Clinics

• Health centers




Table 3.11: Network vulnerabilities likelihood table

Impact level: Medium(4.1)



Overall impact: 4.1

Table 3.12: Network vulnerabilities impact table


generic attacker, and motive is justified by the possible reward from a successful attack. The size

is users with Internet access, and the opportunity factor is high because some resources/access are

needed but not many depending on the vulnerability.

These kinds of vulnerabilities are usually easy to discover due to the existence of many automated

tools. The exploitation difficulty depends vastly on the type of software vulnerability, however for this

threat agent group with high technical skills should be easy. Most of these vulnerabilities are kept

hidden, but there is no intrusion detection system in most cases if one is exploited.

The impact differs from the type of vulnerability, in general it can affect everything: confidentiality,

integrity, and availability. Important data is normally backed up which decreases the integrity impact. The

biggest impact of network vulnerabilities is in confidentiality, because data can be transmitted without

the use of proper encryption techniques.

Business impact in non-compliance and privacy is a result of the technical impact in loss of confiden-

tiality. Financial and reputation damages are low because of the volume of the information affected. In

very rare cases network tampering can have an effect on patient health.


40

3.1.3.6 Denial of service and business continuity


Threats: Terrorists, Business rivals, Nation states, Internal personnel, Organized crime, Hackers.




Vulnerability: Denial of service and business continuity.

Attack types:


• Data tampering


Environments:

• Hospitals

• Clinics

• Health centers


Skill level Motive Opportunity Size Ease of discovery Ease of exploit Awareness Intrusion detection9 9 7 9 3 6 6 9Overall threat: 8.5 Overall vulnerability: 6


Table 3.13: DoS and business continuity likelihood table

Impact level: Medium(4.8)



Overall impact: 4.8

Table 3.14: DoS and business continuity impact table


generic attacker, and motive is justified by the large reward from a successful attack. The size is users

with Internet access, and the opportunity factor is high because some resources/access are needed but

not many.

The ease of discovery for this vulnerability is low because this kind of data is not made available to

the public. The exploitation of it, on the contrary is pretty easy. Denial of service attacks are very popular

and most likely obvious for this threat agent group. These events are not logged or reviewed.

The impact of an attack contributes only to loss of availability. But this loss can cause damages on

patient health because of the lack of available services, reputation of the institution, and have a very

negative financial effect.

41


3.1.3.7 Compromising medical devices


Threats: Nation states, Internal personnel, Organized crime, Hackers, Terrorists, Business rivals,

External suppliers.




Vulnerability: Compromising medical devices.

Attack types:


• Data tampering


Environments:

• Hospitals

• Clinics

• Health centers




Table 3.15: Compromising medical devices likelihood table




Overall impact: 6.7

Table 3.16: Compromising medical devices impact table



with physical access, and the opportunity factor is medium because some special resources/access are

needed.

Discovering these vulnerabilities is typically hard, and so is exploiting them. Due to requiring a very

specific skill set. The medical devices vulnerabilities are hidden, and even getting manufacturer manuals

for these devices is hard. Intrusion detection systems are not present in these devices.

42

The impact of this vulnerability is broad. It can affect confidentiality, integrity and availability. However,

typically these medical devices do not store many confidential information and so the loss of confidential-

ity is minimal. Integrity is minimally affected too, because of the lack of important data in these devices

or data not backed up. Availability is the most affected, especially because it directly affects patient

health. And this is most likely the goal for such attack.

Reputation damages can come directly from having damages to patients’ health. There can be

privacy violations if confidentiality is affected. Financial damages are a consequence of most impacts.


3.1.3.8 Unauthorized systems access



Companies.




Vulnerability: Unauthorized systems access.

Attack types:


• Data tampering



Environments:

• Hospitals

• Clinics

• Health centers

• Laboratories




Table 3.17: Unauthorized systems access likelihood table


43



Overall impact: 6.2

Table 3.18: Unauthorized systems access impact table



with Internet access due to the number of connected devices, and the opportunity factor is also high

because no special resources/access are needed.

The ease of discovery really depends on the type of unauthorized access, it ranges between easy

and difficult, So we attribute it a medium value on our scale. After discovered, the exploitation difficulty

still depends on the type of access. Although we consider it to be easy, and attribute it a medium value.

There may be intrusion detection systems deployed, however not reviewed.

There are different impacts based on the type of system granted unauthorized access. Confiden-

tiality can be greatly affected allowing attackers full access to all data. Availability can also be a target,

interrupting many services. Integrity impact is lower due to the measures in place from the European

data privacy regulation, backing up relevant data.

Loss of availability can have an impact on patients’ safety. The size of privacy violation depends on

the institution size, and there will be non-compliance violations with loss of confidentiality. Financial and

reputation damages are a consequence of all the other impacts.


3.1.3.9 Lack of active protection measures



Companies, External suppliers.




Vulnerability: Lack of active protection measures.

Attack types:


• Data tampering



Environments:

• Hospitals

44

• Clinics

• Health centers

• Laboratories


Skill level Motive Opportunity Size Ease of discovery Ease of exploit Awareness Intrusion detection9 7 7 9 6 5 4 9Overall threat: 8 Overall vulnerability: 6

Overall likelihood: 7

Table 3.19: Lack of active protection measures likelihood table

Impact level: High (6.2)



Overall impact: 6.2

Table 3.20: Lack of active protection measures impact table


generic attacker, and motive is justified by reward from a successful attack. The size is users with

Internet access due to the number of connected devices, and the opportunity factor is also high because

low special resources/access are needed.

The lack of these processes usually are easy to discover, however some specific ones are harder.

The exploitation difficulty is indirect in this case, because this risk is not directly exploitable but induces

or allows to exist other vulnerabilities, such as software vulnerabilities. This attributed value is the as in

same as software vulnerabilites for the same reasoning. Most of these vulnerabilities are kept hidden,

but there is no intrusion detection system in most cases if one is exploited.

The impact is also indirect. We attribute it values for the exploitation of a software vulnerability,

because this risk allows these vulnerabilities to exist.


3.1.3.10 Lack of adequate security personnel



Companies, External suppliers.




Vulnerability: Lack of adequate security personnel.

Attack types:


45

• Data tampering



Environments:

• Hospitals

• Clinics

• Health centers

• Laboratories




Table 3.21: Lack of adequate security personnel likelihood table




Overall impact: 5.9

Table 3.22: Lack of adequate security personnel impact table


generic attacker, and motive is justified by the reward from a successful attack. The size is users with

Internet access due to the number of connected devices, and the opportunity factor is also high because

low special resources/access are needed.

The lack of security personnel is hard to discover. The exploitation difficulty is indirect in this case,

because this risk is not directly exploitable. It induces or allows to exist other vulnerabilities, and can

enhance the impact of other risks. For example, when a cyber attack happens to a target protected

by a security system that no one can operate. The attributed value is the as in same as software

vulnerabilities for the same reasoning. Most of these vulnerabilities are kept hidden, but there is no

intrusion detection system in most cases if one is exploited.

The impact is also indirect. We attribute it values for the exploitation of a software vulnerability with

smaller confidentiality and privacy violation values. This risk allows in a way these vulnerabilities to exist,

although we consider the lack of these individuals less impactful than not having the systems in place.


46

3.1.4 Top 10 document

After our analysis, we ordered the ten cyber risks according to their severity and we got this top 10 as a

result:

1. Software vulnerabilities

2. Unauthorized systems access

3. Lack of active protection measures

4. Lack of adequate security personnel

5. Compromising medical devices

6. DoS and business continuity

7. Network vulnerabilities

8. Social engineering

9. Physical access to servers

10. Mobile devices

We used this top 10 to write the top 10 document itself, provided in Appendix A, where we explain

briefly what is each risk, threat agents involved, possible attack vectors, assets affected, expected impact

in case of successful attack, and provide a real past case.

3.1.5 Feedback questionnaires

The goal of these questionnaires was to validate our top 10, by asking risk related questions. We de-

veloped questions for each of our identified risks, with the intent of verifying if these risks are present

in the Portuguese healthcare sector. The questionnaire was closed response, although there was an

open field for observations in the end. These questionnaires gave us a more in-depth perspective of

the Portuguese healthcare sector and its current state. The target audience was only IT healthcare pro-

fessionals due to the technical nature of the questions. The number of professionals that answered our

questionnaire was 23. All these professionals were chosen because they work in IT areas of Portuguese

healthcare institutions.

In this section, we go in depth about the questions and answers in these questionnaires.

We begin with a question about the size of the local institution the user is inserted into. This helps us

correlating which types of institutions are vulnerable each risk.

As we can see in Figure 3.1, most of the respondents are inserted into very large organizations, and

the others in large organizations.

Almost all the following questions are directly related to one or more risks of the top 10. Their goal is

to validate the presence of these vulnerabilities in the Portuguese healthcare sector.

47

Figure 3.1: Validation questionnaire question 1


2. Physical access to servers with confidential data, for example clinical patient data, is

controlled by access control and authentication mechanisms? (answers in Figure 3.2)

This question relates to the risk, physical access to servers. We can see in the Figure 3.2 that a

majority of organizations has access control and authentication mechanisms limiting the access to their

physical servers.

3. The access to all applications and devices that utilize confidential data is controlled by

access control and authentication mechanisms? (answers in Figure 3.3)


48

This question relates to the risk, unauthorized systems access. A majority claims to have controlled

access to all applications and devices, although this control can exist and still be weak. For example

with default credentials.

4. Are there event detection mechanisms for theft of confidential data, integrity violation or

loss of availability? (answers in Figure 3.4)


This question does not relate to a single risk, but to the parameter of intrusion detection of our

analysis present in all risks. Most organizations cannot detect an attack, which means it can already

have happened and went undetected.

5. Operating systems and applications are regularly updated? (for example, automatic up-

dates like the Microsoft Windows ones) (answers in Figure 3.5)


This question relates to the risk, software vulnerabilities. Many of these updates remove known

security vulnerabilities. There are still many who do not update their applications, making them an easy

target for known attacks.

6. Personnel (doctors, nurses, etc) connect personal mobile devices (smartphones, tablets)

to the healthcare network? (answers in Figure 3.6)

This question relates to the risk, mobile devices. Half of these organizations let their personnel

connect personal devices to their network. Personal devices which could have been affected previously.

49


7. Is there security training for the personnel about good cybersecurity pratices? (answers in

Figure 3.7)


This question relates to the risk, social engineering. A big majority of organizations do not offer

cybersecurity training to their employees. Their employees are unaware of current threats, and can

easily be targeted.

8. Are there mechanisms against theft/loss of mobile devices with confidential information,

such as clinical data? (answers in Figure 3.8)


50

This question also relates to mobile devices. A big majority of organizations do not protect mobile

devices with confidential data. These devices can easily be stolen by attackers with no technical skills.

9. Is there a well defined security policy for medical devices? (answers in Figure 3.9)


This question relates to the risk, compromising medical devices. Policies for medical devices are

critical, although half of the organizations questioned still do not enforce it. This can have effects on

patients’ safety.

10. Is there a well-defined security policy for devices with confidential data, such as clinical

data? (answers in Figure 3.10)


This question is related to several risks, such as mobile devices, medical devices, software vulnera-

bilities... Just like policies about medical devices, half of the inquired organizations do not enforce well

defined security policies for devices that hold confidential data.

11. Are there mechanisms in place to assure the continuity, for example backups, in case of

adversity for clinical data? (answers in Figure 3.11)

This question relates to the risk, denial of service and business continuity. A majority of organizations

has mechanisms to ensure continuity of their services.

12. Are there mechanisms in place to assure the continuity of the electronic healthcare ser-

vices, for example backups? (answers in Figure 3.12)

51



This question relates to the risk, denial of service and business continuity. A majority of organizations

has mechanisms to ensure continuity of their services.

13. Are there mechanisms in place to ensure confidentiality of the data in its storage and

communication, for example ciphering mechanisms? (answers in Figure 3.13)


This question relates to several risks, such as network vulnerabilities, and physical access to servers.

A large majority of the healthcare organizations does not utilize mechanisms to ensure confidentiality.

Confidential data, for example clinical data, is stored and communicated in plain text.

52

14. Are risk analysis performed periodically? (answers in Figure 3.14)


This question relates to the risk, lack of active protection measures. Risk analysis are a important

mechanisms to identify which risks are critical and possibly use measures to either mitigate or eliminate

them. However, most healthcare organizations still do not utilize them.

15. Are penetration tests performed periodically? (answers in Figure 3.15)


This question also relates to lack of active protection measures. Penetration tests are a good way to

verify if an organization is safe from an attack. Unfortunately, most Portuguese healthcare organizations

still do not utilize them.

16. Are auditing procedures used periodically in networks and software? (answers in Figure

3.16)

This question also relates to lack of active protection measures. Just like penetration testing, or risk

analysis most healthcare organizations do not use auditing procedures.

17. Are hardware/software manufacturers obligated to utilize certified processes that ensure

the systems protection, and the data utilized by these systems? (answers in Figure 3.17)

This question relates to several risks, such as software vulnerabilities, compromising medical de-

vices, unauthorized systems access, and network vulnerabilities. More than half of the inquired orga-

nizations do not obligate manufacturers to use certified processes. This can lead to vulnerabilities in

53



critical applications and systems.

18. Are there mechanisms to share information with other institutions, in order to identify

common problems? (answers in Figure 3.18)


This question does not relate to any specfic risk. The lack of a sharing knowledge mechanism can

lead to several organizations being targeted by the same attack with success. Although there is work in

progress in this direction, it is mentioned in Section 2.4.2.

19. Is there a cybersecurity team responsable for data and electronic healthcare services?

54

(answers in Figure 3.19)


This question relates to the risk, lack of adequate security personnel. Healthcare organizations do

not have dedicated personnel for cybersecurity.

In the open field for observations, 13% of the professionals claim being aware to the existing risks,

and best practices missing. But lack either funding or manpower to address them.

3.1.6 Evaluation based on the questionnaires

After the feedback questionnaires, we analyzed the ordering of our top 10. This ordering had just been

based of our risk analysis. We consider that the feedback questionnaires supported that the analysis

was accurate, because they showed that these risks exist in the Portuguese healthcare sector. The

questionnaires also gave us an estimate idea of number of vulnerable institutions, existence or not of

security mechanisms in these institutions, and eased the impact estimation of a successful attack.

We did not change the ordering of the top. Portuguese healthcare organizations are vulnerable to

the risks indicated on the top, some more than others. Although to best utilize the top, each organization

must conduct their own risk analysis.

The final top 10 document is the one in Appendix A, as mentioned in Section 3.2.4.

3.2 Attack demonstrations

This section will cover all the steps taken to develop the attack demonstrations. The purpose of such

demonstrations is to raise awareness to the cybersecurity problems we identified, in a more graphical

manner. It is divided in three sections: a first section where we present an overview of the attack

demonstrations, a second section where we go in depth into each step we took to develop an attack with

social engineering, and a third where we explain how we achieved our software attack.

55

3.2.1 Overview

Initially we planned to develop several attack demonstrations, four from our related work research: insulin

pump tampering, pacemaker disabling, USB stick manipulation, EHR web application tampering. And

some others from the most severe risks from our top 10. However, further research proven that some of

these were very complicated, and others required special resources and permits to compile.

We changed our plan to only do two attack demonstrations, from risks in our top 10. The first chosen

risk was social engineering. The reason behind this choice was mainly the ease of representation in

video format for a target audience unfamiliar with most IT concepts, in a comprehensible manner. The

second risk chosen was software vulnerabilities, because we rated them as the most severe risk faced

by healthcare organizations.

The video demonstrations have the planned structure: visual scheme of the attack for easier under-

standing, reproduction of the major steps needed to exploit the vulnerability, and a representation of the

consequences of such attack.

In order to make these demonstrations we created fictional scenarios. We pretend to follow every

attack step like a real attacker would. We record the important steps, and compile them into video.

Lastly, we add a voice-over.

We uploaded our work into YouTube, for ease of distribution. In order to raise awareness to the

matter we need to distribute it to many healthcare professionals.

3.2.2 Social engineering

We started by researching how a social engineering attack is orchestrated, without any special resource

worth mentioning, this research provided us with a good general idea.

We decided to use e-mail as the attack vector, and distribute a simple malware. The reason behind

the e-mail choice was simply the ease of representation in the video versus, for example, physical social

engineering.

The first step was to find a target, we chose Servicos Partilhados do Ministerio da Saude (SPMS).

They are the higher entity in Portugal in terms of IT in healthcare. The second step was to create a plan,

and we did:

1. Get information about the targeted company

2. Create a malware

3. Create a cover story

4. Find potential vulnerable individuals

5. Distribute the malware

Bellow we go in depth into each step of the plan.

56

Get information about the targeted company

We researched their company, for instance using their website. Using a tool like Google makes easy the

task of finding information about a specific target.

In order to get their e-mail footer, and domain name the attacker would e-mail them pretending to be

interested in their recruitment services like in Figure 3.20.

Figure 3.20: E-mail for recruitment services

He would get a reply like the one in Figure 3.21. Now he would have their footer, and information

about their domain, spms.min-saude.pt.

Figure 3.21: E-mail from recruitment services

Create a malware

We did not really create any malware, because we have no intent of actually running the attack, only

emulating it on a video. Although, in this step an attacker would develop a fully undetectable malware

with features of his choosing, for instance data theft, data tampering, damages to availability, among

57

many other possibilities. Other possibility would be to simply download a malware, or even order one on

the dark web.

To attach this malware to an e-mail there are multiple possibilities. The attacker could use Microsoft

Office macros, use a special software called binder that merges multiples files into one, or even upload

it to a vulnerable website that would inject the malware in its visitors.

Create a cover story

This step is the tricky one. An attacker needs a believable story for people to open his attachments.

Our story consisted of the information systems director distributing a document of new best practices,

because of the incoming legislation about privacy already approved. The e-mail sent is seen in Figure

3.22.

Figure 3.22: Fake e-mail from information systems director

Find potential vulnerable individuals

In this step, an attacker just had to use Google or another crawler. After having their domain, spms.min-

saude.pt, he can search for personal e-mails with that extension. The more targets the email is sent to,

the higher the success rate.

Distribute the malware

The final step is to send these e-mails. However, to make it believable the attacker need to send them

from either the victim’s or one very alike. For this task, he can simply use a e-mail spoofer, or create a

domain alike theirs, for example, with a letter change.

Video

Developing the video consisted simply in compiling all the major steps in the Windows movie maker. We

also added an attack scheme on the beginning like the one in Figure 3.23. And explained the possible

impacts of such attack.

The video is available on YouTube at https://www.youtube.com/watch?v=lU5aDFYk008.

58

https://www.youtube.com/watch?v=lU5aDFYk008

Figure 3.23: Cyber attack scheme

3.2.3 Software vulnerabilities

We started by compiling a network environment with a database, and a web application. The purpose

was to simulate a real life network in a small scale. We configured each device with standard specifica-

tions.

Figure 3.24: Attack scheme considering network topology

First the attacker must choose a target. Following this first step, the attacker will want to access

confidential data stored in the hospital database server. To achieve that he must find a vulnerability in

one of their web applications. For this task he can use one of several automated tools available online,

depending on the type of vulnerability he is searching for.

As we can see by Figure 3.25, the attacker uses SQLmap. This tool automatically searches a web

application for vulnerable injection points, and presents the results as indicated by the yellow arrow. We

discover three potential entry points. The next step for the attacker is to exploit one of these injection

points, and try to extract database information.

He does that, as we can see by Figure 3.26. Having this information, the attacker can simply dump

the contents of the desired tables into a file. The file would have a similar aspect as the one shown in

Figure 3.27.

After all these steps the attacker would now have access to confidential healthcare information.

59

Figure 3.25: SQLmap GUI after vulnerability search

Video

Developing the video was simply compiling all the major steps in the Windows movie maker. Besides

the attack steps and the network topology, we explain the impact such attack would have in a healthcare

environment.

The video is available on YouTube at https://www.youtube.com/watch?v=BdFNcWeW38k.

60

https://www.youtube.com/watch?v=BdFNcWeW38k

Figure 3.26: SQLmap target table information

Figure 3.27: Dump file of the selected table entries

61

Chapter 4

Evaluation

This chapter describes the methods used to evaluate our solution. The first two sections evaluate the

top 10 following a quantitative and a qualitative approach. The purpose of the quantitative approach is to

provide an argument that the top 10 produced is up to date and can be used by the industry to appoint

priority to cyber risks. The qualitative approach evaluates what end users think about our work, to make

sure we appeal to our target audience. It also evaluates their understanding on the subjects covered,

to prove the materials produced are comprehensible by the healthcare sector. A third section evaluates

our video demonstrations, to make sure we can raise awareness with them. Lastly, in a fourth section

we draw our conclusions from our evaluation.

4.1 Qualitative Evaluation

This evaluation method consisted of a questionnaire to healthcare professionals. The goal of this eval-

uation was to prove our top was comprehensible to healthcare professionals, applicable to the current

healthcare industry state, and up to date.

The target audience was very general, including healthcare administration, clinical personnel (doc-

tors, nurses), and also IT. The questionnaire is closed response.

4.1.1 Method overview

We prepared a questionnaire in Google forms, with nine questions and a open field for observations.

To validate the document itself, four questions were prepared about its appearance and content. We

also prepared a question about the comprehension difficulty of the document, and a question about the

applicability of the top to the current healthcare state. To measure if our target audience was educated

to the topic we developed a question about the usage of learned topics in future decision making. As a

bonus, we also tried to understand if we motivated these users to further research cybersecurity topics.

We sent the questionnaire along with the top 10 document to many professionals working in Por-

tuguese institutions, and we got fifteen answers. The target audience for this questionnaire was more

63

general than the first questionnaire we conducted. Medical care, IT, and management are examples of

areas of the professionals questioned.

There is a first section has a question about the type of user, followed by a question about his

institution. This section helps us understand the profile of the user.

1. What is the area in the healthcare that you work? (answers in Figure 4.1)

Figure 4.1: Evaluation questionnaire question 1

As we can see by the Figure 4.1, we managed to get a very nice distribution of healthcare profes-

sionals.

2. What is the size of your local institution, in number of employees? (answers in Figure 4.2)


In terms of organization size, a majority was from big organizations. However, the others were evenly

distributed.

The following section has four questions about the top 10 document itself.

3. Rate the appearance of the document. (answers in Figure 4.3)

A majority rates the document appearance high, however there are still votes on an average appear-

ance.

4. Rate the content of the document. (answers in Figure 4.4)

Most people consider the document content of good quality.

5. Rate the difficulty of comprehension of the topics addressed for you. (answers in Figure

4.5)

64




The comprehension of the topics has a very disperse distribution. However, most votes are positive

as we can see in Figure 4.5. This dispersion is because of the several different roles in healthcare that

were questioned.

6. Rate utility of the real past cases in the document, as extra means of sensibilization.


Most votes are positive feedback. The real past cases raise awareness to the cybersecurity threat.

The last section has 3 questions. It focusses on applicability of the top, and sensibilization of the

user

7. Did you research more about cybersecurity, for instance the bibliography, after having

65


contact with our document? (answers in Figure 4.7)


We managed to get over 50

8. Do you consider our top applicable to the Portuguese healthcare sector, having in account

the used methodology? (answers in Figure 4.8)


All votes consider the top applicable to some degree. Most consider it fully applicable as seen by

Figure 4.8.

9. Will you take into account information in our document in future professional decisions?


66


Many of the questioned people claim they will utilize information from our document in future work

decisions. We consider it another victory.

4.1.2 Results

Fifteen people answered our questionnaire. From the ones that answered we got a good distribution of

roles in the healthcare sector. The feedback was good, in terms of appearance, content, and compre-

hension of the document.

The real cases were considered a good tool for extra awareness.

The top was considered applicable by everyone to the Portuguese healthcare sector, and most say

they will utilize the information in future professional decisions.

We also managed to get the attention of a few people to further investigate these topics.

Overall, we managed to get the results we wanted. The document is comprehensible by healthcare

professionals, and raises awareness to the cybersecurity problem. On top of that we managed to make

some healthcare professionals more informed for future decisions.

4.2 Quantitative Evaluation

This evaluation method consisted in gathering information about past events in the healthcare industry,

categorizing them, and lastly comparing these to our top. The goal of this evaluation was to prove our

top was up to date on cybersecurity risks.

Due to the nature of the healthcare industry in Portugal, data about cybersecurity events is private.

This is not the case in other countries, for instance, in the United States of America. We took advantage

of this, and used their U.S. Department of Health and Human Services Office for Civil Rights breach

portal [38] to gather intel. However, this portal only shows breaches that affect privacy, and more than

500 affected users. Any attack that targets integrity, or availability is not shown. Neither are attacks with

less than 500 affected users. Without any other reputable resource to use, this evaluation method will

only validate the ordering in risks that affect privacy.

67

4.2.1 Method overview

We used data from a one year period, from October 2015 to October 2016. In this time there were over

14,5 million affected users and 291 incidents.

The portal uses two properties to classify the breaches, type of breach and location of breach. For

type of breach there are seven options: hacking/IT incident, improper disposal, loss, theft, unauthorized

access/disclosure, other, and unknown. For the property location of breach there are eight options:

desktop computer, electronic medical record, e-mail, laptop, network server, other portable electronic

device, paper/films, and other. Associated with each incident there is also number of affected users,

data, covered entity, state in which it occurred, and a description. However, the description is optional.

Table 4.1 presents the results from the time period we used:

Type of breach Location of breach # users # incidentsUnauthorized Access/Disclosure Email 157360 30Unauthorized Access/Disclosure Network Server 743394 12Unauthorized Access/Disclosure Paper/Films 137634 48Unauthorized Access/Disclosure Other Portable Electronic Device 1540 2Unauthorized Access/Disclosure Electronic Medical Record 259989 14Unauthorized Access/Disclosure Other 165865 11Unauthorized Access/Disclosure Desktop Computer 16707 4Unauthorized Access/Disclosure Laptop 3118 1Hacking/IT Incident Network Server 11183370 49Hacking/IT Incident Email 76890 13Hacking/IT Incident Desktop Computer 137578 13Hacking/IT Incident Electronic Medical Record 110717 11Hacking/IT Incident Other 9436 4Loss Paper/Films 494894 6Loss Other Portable Electronic Device 7283 4Loss Other 10558 6Theft Desktop Computer 44900 8Theft Laptop 768947 26Theft Other 20347 5Theft Paper/Films 30294 16Theft Email 553 1Theft Electronic Medical Record 44761 2Improper Disposal Other Portable Electronic Device 2000 1Improper Disposal Paper/Films 122789 4

Table 4.1: Breach data from one year period

The categories provided are not very good to pinpoint the vulnerability behind it. Descriptions are

very vague, and in many cases nonexistent. Although we made an effort to categorize these breaches

according to the risks in our top, the result are in the Table 4.2.

Risk # users # incidentsSoftware vulnerabilities 11517991 90Unauthorized system access 1189073 42Mobile devices 822670 40Social engineering 234250 43

Table 4.2: Categorized incidents table

68

In our categorization, some software vulnerabilities incidents can be network vulnerability related.

However, we have no way of knowing which. The same happens with unauthorized systems access,

some can be related to physical server access.

4.2.2 Results

Comparing the data to our top 10 of cyber risks, excluding the cyber risks not related to privacy, we see

that software vulnerabilities are clearly the biggest risk. Followed by unauthorized system access. Both

lack of active protection measures, and lack of adequate security personnel are not directly exploitable

and for that reason not validated in this method.

Compromising medical devices does not target confidentiality, but patient safety. Denial of service

and business continuity targets availability. Both are excluded from this evaluation.

Network vulnerabilities are included in our software vulnerabilities data, due to the lack of descrip-

tions. Their impact is inferior to software vulnerabilities, and that is the main reason they are ranked

lower.

Social engineering has many attacks but few affected users.

Physical server access is within unauthorized systems access, as previously mentioned, due to the

lack of information. The low position of this risk is due to the access required for a successful attack.

Mobile devices have a very big number of affected users, and number of incidents. The position in

the top is justified by the low impact an attack of this nature has.

4.3 Attack Demonstrations Evaluation

In order to evaluate our video demonstrations, we developed another questionnaire. It consisted of five

questions, two about the user profile and the other three about the top itself. We tried to evaluate the

appearance, content, and ease of understanding of our cyber attack demonstrations. We made the

questionnaire available to a wide range of individuals, although trying to target mostly healthcare and IT

professionals. This target selection is justified by the target audience of our video demonstrations. We

managed to get 36 answers.

1. In what area are your academic studies? (answers in Figure 4.10)

Figure 4.10: Attack demonstrations questionnaire question 1

69

We got an even distribution between IT and health sciences professionals like we intended.

2. In what range follows your age? (answers in Figure 4.11)


All individuals were in the range from 18 to 25 years old.

3. Rate the videos appearance. (answers in Figure 4.12)


The results show that the inquired users consider our videos average looking. Certainly, a category

we could have improved.

4. Rate the videos content. (answers in Figure 4.13)


Most users consider the videos content good. This is a good indicator, especially because many of

the inquired users are from IT and have technical expertise in this area.

5. Rate the difficulty of understanding the videos content for you. (answers in Figure 4.14)

70


This question provided us with a good result, with most of the inquired users considering the videos

very easy to understand. Even health sciences professionals from an unrelated area understand our

content which was our goal.

Overall, the results were positive. Raising awareness to the cybersecurity problem in the healthcare

sector is our main goal, and these video demonstrations were a visual aid complementary to our top 10

document. The worse feedback we received was related to appearance, but we believe we still pass our

desired message with the demonstrations, and succeed in complementing the top.

4.4 Conclusions

The evaluation of a top 10 is not an easy task. Although we think that the combination of the quantitative

approach with our qualitative approach made a good evaluation method. If there was more information

about cybersecurity incidents publicly available, we could have achieved a slightly better evaluation.

The evaluation of our video demonstrations was simple, but captured what we desired from it.

71

Chapter 5

Conclusions

This chapter describes the main conclusions obtained from our research and the development of the

project. Section 5.1 shows a summary of the conclusions we took from this thesis, along with contribu-

tions brought. Section 5.2 mentions some ideas for future related work.

5.1 Summary and Contributions

The growth of information technology has changed the face of many sectors, including healthcare. IT is

associated with many security problems and lately there has been numerous successful attacks. This

document studied some of the changes IT brought to healthcare along with their possible complications.

The research tries to argue the idea that risk analysis is an important way to minimize risk effectively,

by going in depth into some methodologies and their potential advantages. Tops were also analyzed for

their syntheses capabilities.

We developed a top 10 of cyber risks for the Portuguese healthcare sector, which we believe rep-

resents well the current risks faced by this sector. This format allowed us to present the data in an

organized manner but also improved ease of understanding to the people we presented it to.

The attack demonstrations clearly show cyber attacks can happen, and increase people’s awareness

to the ease of such attacks. They are available for viewing on YouTube.

We sent our document to over 100 people. By doing this we believe we are already contributing for

our goal of raising awareness to the cybersecurity risks.

5.2 Future Work

While developing our project, we identified some aspects which could be target of a future work. In this

section we briefly describe them.

• Our work has limited utility due to the fact of only identifying the risks, and not providing solutions

for them. A suggested future work would be providing solutions for these identified risks.

73

• Cybersecurity and IT itself is ever-changing. Every year there are innovations in IT, some of which

affect security. The top must be updated in order to maintain its relevancy, these updates could be

yearly or every two years. The suggested future work is maintaining up to date this top.

• Another future work suggestion would be for singular healthcare companies to utilize the top pro-

duced in order to make sure they are not vulnerable to these risks.

• Producing attack demonstrations for the other identified risks, could also be a work for the future.

74

Bibliography

[1] C. C. Law and E. W. Ngai. IT business value research: a critical review and research agenda.

International Journal of Enterprise Information Systems (IJEIS), 1(3):35–55, 2005.

[2] C. Humer and J. Finkle. Your medical record is worth more to hackers than your credit card. Reuters

US, 24 September 2014.

[3] M. A. Rothstein. Genetic privacy and confidentiality: why they are so hard to protect. The Journal

of Law, Medicine & Ethics, 26(3):198–204, 1998.

[4] T. D. Gunter and N. P. Terry. The emergence of national electronic health record architectures in the

United States and Australia: models, costs, and questions. Journal of Medical Internet Research,

7(1):e3, 2005.

[5] A. Sunyaev, D. Chornyi, C. Mauro, and H. Krcmar. Evaluation framework for personal health

records: Microsoft HealthVault vs. Google health. In System Sciences (HICSS), 2010 43rd Hawaii

International Conference on, pages 1–10. IEEE, 2010.

[6] J. L. Fernandez-Aleman, I. C. Senor, P. A. O. Lozoya, and A. Toval. Security and privacy in electronic

health records: A systematic literature review. Journal of Biomedical Informatics, 46(3):541–562,

2013.

[7] J. Benaloh, M. Chase, E. Horvitz, and K. Lauter. Patient controlled encryption: ensuring privacy

of electronic medical records. In Proceedings of the 2009 ACM workshop on Cloud computing

security, pages 103–114, 2009.

[8] M. Maffei, G. Malavolta, M. Reinert, and D. Schroder. Privacy and access control for outsourced

personal records. In Security and Privacy (SP), 2015 IEEE Symposium on, pages 341–358. IEEE,

2015.

[9] W. H. Maisel and T. Kohno. Improving the security and privacy of implantable medical devices. New

England Journal of Medicine, 362(13):1164, 2010.

[10] D. B. Kramer, M. Baker, B. Ransford, A. Molina-Markham, Q. Stewart, K. Fu, and M. R. Reynolds.

Security and privacy qualities of medical devices: an analysis of fda postmarket surveillance. PLoS

One, 7(7):e40200, 2012.

75

[11] J. Radcliffe. Hacking medical devices for fun and insulin: Breaking the human scada system. In

Black Hat Conference presentation slides, volume 2011, 2011.

[12] N. Leavitt. Researchers fight to keep implanted medical devices safe from hackers. IEEE Computer,

(8):11–14, 2010.

[13] J. Rozenblit and J. Sametinger. Security challenges for medical devices: Implantable devices,

often dependent on software, save countless lives. but how secure are they? Communications of

the ACM, 58(4):74–82, Mar. 2015. ISSN 0001-0782.

[14] K. Fu and J. Blum. Controlling for cybersecurity risks of medical device software. Biomedical

Instrumentation & Technology, 48(S1):38–41, 2014.

[15] A. Shostack. Experiences threat modeling at microsoft. In Modeling Security Workshop. Dept. of

Computing, Lancaster University, UK, 2008.

[16] OWASP. Application Threat Modeling. owasp.org/Application_Threat_Modeling/, 2015. [On-

line; accessed 7-May-2016].

[17] Microsoft. Introduction to Threat Modeling. Available at http://download.microsoft.

com/download/9/3/5/935520EC-D9E2-413E-BEA7-0B865A79B18C/Introduction_to_Threat_

Modeling.ppsx, 2011. [Online; accessed 25-May-2016].

[18] OWASP. Threat Risk Modeling. https://www.owasp.org/Threat_Risk_Modeling, 2016. [Online;

accessed 7-May-2016].

[19] B. Karabacak and I. Sogukpinar. ISRAM: information security risk analysis method. Computers &

Security, 24(2):147–159, 2005.

[20] A. Vorster and L. Labuschagne. A framework for comparing different information security risk anal-

ysis methodologies. In Proceedings of the 2005 Annual Research Conference of the South African

Institute of Computer Scientists and Information Technologists on IT Research in Developing Coun-

tries, pages 95–103, 2005.

[21] C. J. Alberts and A. Dorofee. Managing information security risks: the OCTAVE approach. Addison-

Wesley Longman Publishing Co., Inc., 2002.

[22] R. Fredriksen, M. Kristiansen, B. A. Gran, K. Stølen, T. A. Opperud, and T. Dimitrakos. The CORAS

framework for a model-based risk management process. In Computer Safety, Reliability and Secu-

rity, pages 94–105. Springer, 2002.

[23] D. Raptis, T. Dimitrakos, B. A. Gran, and K. Stølen. The CORAS approach for model-based risk

management applied to e-commerce domain. In Advanced Communications and Multimedia Se-

curity, pages 169–181. Springer, 2002.

[24] G. Stoneburner, A. Y. Goguen, and A. Feringa. SP 800-30. risk management guide for information

technology systems. 2002.

76

owasp.org/Application_Threat_Modeling/

http://download.microsoft.com/download/9/3/5/935520EC-D9E2-413E-BEA7-0B865A79B18C/Introduction_to_Threat_Modeling.ppsx



https://www.owasp.org/Threat_Risk_Modeling

[25] J. H. Eloff, L. Labuschagne, and K. P. Badenhorst. A comparative framework for risk analysis

methods. Computers & Security, 12(6):597–603, 1993.

[26] OWASP. OWASP Risk Rating Methodology. Available at https://www.owasp.org/index.php/

OWASP_Risk_Rating_Methodology, 2016. [Online; accessed 24-May-2016].

[27] OWASP. Owasp testing guide v4. 2014.

[28] J. Williams and D. Wichers. OWASP Top 10 - 2013 rcl - the ten most critical web application security

risks. Technical report, OWASP Foundation, 2013.

[29] Verizon. Data breach investigations report. 2014.

[30] Imperva. Top ten database security threats. 2015.

[31] Cloud Security Alliance. The notorious ninecloud computing top threats in 2013. 2013.

[32] OWASP. Mobile Security Project - Scratchpad. Available at https://www.owasp.org/index.

php/Projects/OWASP_Mobile_Security_Project_-2015_Scratchpad, 2015. [Online; accessed

25-May-2016].

[33] OWASP Mobile Security Project. Top 10 mobile risks - final list 2014. Available at https://www.

owasp.org/index.php/Projects/OWASP_Mobile_Security_Project_-_Top_Ten_Mobile_Risks,

2014.

[34] R. Chaudhary and R. Malarkey. Top 20 IT risks for the healthcare industry –

and how to mitigate them. Available at https://www.crowehorwath.com/folio-pdf/

Top-20-IT-Risks-for-the-HC-Industry_CHAN15918.pdf, 2014. [Online; accessed 25-May-

2016].

[35] R. Pereira, M. M. da Silva, and L. V. Lapao. Business/IT alignment through IT governance pat-

terns in Portuguese healthcare. International Journal of IT/Business Alignment and Governance

(IJITBAG), 5(1):1–15, 2014.

[36] D. Doherty and R. Carino. Critical risks facing the healthcare industry. Available at http://www.

acegroup.com/us-en/assets/ace_medical_critical_risk_wp.pdf, 2015. [Online; accessed 25-

May-2016].

[37] P. A. F. de Sousa. O sistema de saude em Portugal: realizacoes e desafios. Acta Paulista de

Enfermagem, 22:884–94, 2009.

[38] U. D. of Health and H. Services. U.S. department of health and human services office for civil rights

breach portal. Available at https://ocrportal.hhs.gov/ocr/breach/breach_report.jsf, 2016.

[Online; accessed 9-December-2016].

[39] R. M. M. Gomes and B. H. Soares. Cybersecurity match supply and demand in Portuguese health-

care sector – industry collaboration. 2016.

77

https://www.owasp.org/index.php/OWASP_Risk_Rating_Methodology

https://www.owasp.org/index.php/OWASP_Risk_Rating_Methodology

https://www.owasp.org/index.php/Projects/OWASP_Mobile_Security_Project_-2015_Scratchpad

https://www.owasp.org/index.php/Projects/OWASP_Mobile_Security_Project_-2015_Scratchpad

https://www.owasp.org/index.php/Projects/OWASP_Mobile_Security_Project_-_Top_Ten_Mobile_Risks

https://www.owasp.org/index.php/Projects/OWASP_Mobile_Security_Project_-_Top_Ten_Mobile_Risks

https://www.crowehorwath.com/folio-pdf/Top-20-IT-Risks-for-the-HC-Industry_CHAN15918.pdf

https://www.crowehorwath.com/folio-pdf/Top-20-IT-Risks-for-the-HC-Industry_CHAN15918.pdf

http://www.acegroup.com/us-en/assets/ace_medical_critical_risk_wp.pdf

http://www.acegroup.com/us-en/assets/ace_medical_critical_risk_wp.pdf

https://ocrportal.hhs.gov/ocr/breach/breach_report.jsf

[40] Regulamento (UE) 2016/679 do parlamento Europeu e do conselho. Jornal Oficial da Uniao Eu-

ropeia, 27 de abril de 2016.

[41] Center for Internet Security. The CIS critical security controls for effective cyber defense. Available

at https://www.cisecurity.org/critical-controls.cfm, 2016. [Online; accessed 8-January-

2016].

[42] Deloitte. Networked medical device cybersecurity and patient safety: Perspectives of health care

information cybersecurity executives. 2013.

[43] P. A. Williams and A. J. Woodward. Cybersecurity vulnerabilities in medical devices: a complex

environment and multifaceted problem. Medical devices (Auckland, NZ), 8:305, 2015.

78

https://www.cisecurity.org/critical-controls.cfm

Appendix A

Top 10

79

VERSION 0.1 – DECEMBER 2016

Ivo Lopes

Advisors: Miguel Correia and Paulo Sousa

SECURITY RISKS IN HEALTHCARE

TOP 10 CYBERSECURITY RISKS

1

SECURITY RISKS

IN HEALTHCARE

TOP 10 CYBERSECURITY RISKS

Introduction

Healthcare has been around for countless years and its importance

for our society is indisputable. Information Technology (IT) has

become crucial for the support, sustainability, and growth of most

business sectors. Healthcare has been increasingly adopting IT, from

administrative processes to patient care. However, the security of

healthcare assets is sometimes neglected. At the light of recent

events, we can be sure that security vulnerabilities exist in healthcare

systems. Vulnerabilities can lead to disastrous consequences,

especially in systems that manage patient health data or provide life

support.

We conducted a risk assessment on the Portuguese healthcare

sector following the OWASP Risk Rating Methodology. Our goal is to

raise awareness about cybersecurity risks by disseminating the most

important risks for the Portuguese healthcare sector. To achieve that

goal, we compiled a Top 10 of Security Risks based on the

assessment made. Tops are known for their capacity of presenting

information concisely as well as improving understanding on a given

subject.

This document presents the Top 10 of Healthcare Security Risks,

including description for each of the risks, as well as summary tables

of the assessment, and real past cases.

TOP 10

SECURITY

RISKS

1. Software

vulnerabilities

2. Unauthorized

system access

3. Lack of active

protection measures

4. Lack of adequate

security personnel

5. Compromising

medical devices


and business

continuity

7. Network

vulnerabilities


9. Physical access to

servers

10. Mobile devices

2

1. Software vulnerabilities

A software vulnerability is a weakness which may allow an attacker to break one or more security

properties.

Healthcare uses many different software products, although it lacks regulations and certified

processes ensuring the security of these products. The use of legacy/unpatched systems can also

lead to vulnerabilities.

The ease of discovery of these vulnerabilities is countered by the high skill level required to exploit

them, but the potential reward motivates attackers, producing a high likelihood of successful attacks.

The consequences of a successful attack can be disastrous, such as extensive corrupt data, loss of

availability, leakage of sensitive data, damage to business, and even patient health impacts such as

death.

Real case: In 2013, MUSC Physicians & MUHA, an American clinical enterprise, discovered that the

payment portal of its business associate Blackhawk Statement Group had been hacked via a

vulnerability in the software. The breach exposed the names, addresses, email addresses, and

credit care information of 7120 individuals.

Threat agents Attack vectors Assets Technical

impact

Business

impact

Patient

safety

impact

Threat level

High

Vulnerability

High

Impact

High

Impact

Medium

Impact

High

Nation

states

Internal

personnel

Organized

crime

Hackers

Terrorists

Business

rivals

Companies

External

suppliers

Attackers identify

a weakness

through scanning

or manual

analysis, and

customize an

exploit.

Moreover,

legacy/unpatched

systems often

have known

vulnerabilities

that can be

discovered and

exploited

automatically

even by low

skilled attackers.

Patients

health

Patients

information

Intellectual

property

and

proprietary

information

Service

availability

Electronic

business

devices

Software

applications

Attackers

can exploit a

vulnerability

to steal or

corrupt data,

tamper with

system

integrity, or

deny service

availability.

Depending

on the

institution,

and type of

vulnerability

it can affect

patient

privacy,

institution

reputation,

and cause

financial

losses.

The

tampering

with

systems

integrity

and/or its

data could

lead to

wrong

patient

treatment,

and major

damage.

3

2. Unauthorized system access

Unauthorized access is a situation when someone gains access to data, applications, or devices

illegitimately. This can happen, for example, by bypassing an access control mechanism by

exploiting a vulnerability, or by using someone else’s ID and password to access a restricted service.

Most healthcare systems can be a target, e.g., those in hospitals, clinics, health centers or

laboratories. The vulnerability exists due to the lack of effective access control mechanisms, and

insufficient training of employees on cybersecurity, among other problems.

Due to the number and nature of the assets this risk affects, there are multiple highly motivated and

skilled threats. A successful attack could have both organizational and technical impacts with loss

and/or damage of confidential data, loss of availability, and major patient health impact.

Real case: In 2013 confidential information of 10,000 Presbyterian Anesthesia Associates patients

was compromised when an unauthorized person gained access to the servers of the company

hosting their website. The protected health information (PHI) involved in the breach included

patients’ names, addresses, phone numbers, email addresses, and credit card information.

Threat agents Attack

vectors

Assets Technical

impact

Business

impact

Patient

safety

impact

Threat level

High

Vulnerability

Medium

Impact

High

Impact

Medium

Impact

High

Nation

states

Internal

personnel

Organized

crime

Hackers

Terrorists

Business

rivals

Companies

Several

different

attacks are

possible, for

instance taking

advantage of

default

configurations,

or shared

passwords.

These could

grant access to

the controls of

a device such

as MRI.

Patients

health

Patients

information

Intellectual

property

and

proprietary

information

Service

availability

Electronic

devices

(medical

and

business)

Attackers can

access

confidential

data, in some

cases tamper

with system

integrity, or

temporarily

deny service

availability.

Depending

on the

institution and

type of

access

granted it

could violate

patient

privacy,

cause

reputation

damage, or

financial

losses.

The

tampering

with systems’

integrity

and/or their

data could

lead to wrong

patient

treatment,

and major

damages.

4

3. Lack of active protection measures

Active protection measures can take many forms such as periodic risk analysis, auditing procedures,

logging and monitoring of events, and penetration testing. The lack of use of these mechanisms can

lead to unawareness of the existence of vulnerabilities in the company resources. These

vulnerabilities can be exploited to achieve several ends and, depending on their type, the impact can

be disastrous: from technical impact, such as loss of confidentiality or availability, to effects on

patients’ health. Business would also be affected depending on the consequences of a successful

attack.

Real case: An employee of the Indian Health Services (IHS) network penetration testing team

discovered protected health information (PHI) on open shares in a network attached storage device

that could have affected 5,000 individuals if the problem had been not caught on time.


vectors

Assets Technical

impact

Business

impact

Patient

safety

impact

Threat level

High

Vulnerability

High

Impact

High

Impact

Medium

Impact

High

Nation

states

Internal

personnel

Organized

crime

Hackers

Business

rivals

Companies

Terrorists

For example,

the lack of

penetration

testing can

leave

unnoticed

resources

openly

accessible on

the company

network,

which might

lead to

confidential

data leakage.

Patients

information

Intellectual

property

and

proprietary

information

Electronic

devices

(business)

Software

applications

Patients

health

Attackers can

exploit a

vulnerability

to steal or

corrupt data,

tamper with

systems

integrity, or

deny service

availability.

Because the

vulnerability

was not

detected from

the lack of

protections.

Depending on

the institution,

and type of

vulnerability it

can affect

patient

privacy,

institution

reputation,

and cause

financial

losses.

The

tampering

with systems

integrity

and/or its

data could

lead to

wrong

patient

treatment,

and major

damages.

5

4. Lack of adequate security personnel

Cyber security personnel are required for multiple operations, for instance, to operate the security

systems in place. Without security personnel with proper knowledge and training most protective

measures lose their effectiveness, leaving the system open to several types of attacks.

The impact these attacks cause depends greatly on their type. They can have technical impact such

as loss of availability and/or confidentiality, but also affect the heal of patients. The business is

affected as a result of the previous impacts, resulting in both financial and reputation damages.

Real case: In 2014, an attacker threatened the Boston Children’s Hospital. In the following weeks,

the hospital CIO, incident response team, and IT team were able to repel multiple attacks and

prevent the compromise of patient data.


vectors

Assets Technical

impact

Business

impact

Patient

safety

impact

Threat level

High

Vulnerability

Medium

Impact

Medium

Impact

Medium

Impact

High

Nation

states

Internal

personnel

Organized

crime

Hackers

Terrorists

Business

rivals

Companies

Attackers can

send multiple

requests to

the company

network, trying

to cause a

loss of

availability.

Without

security

personnel to

analyze the

data and block

the requests

from the

attackers, it

would work.

Patients

health

Patients

information

Intellectual

property

and

proprietary

information

Service

availability

Electronic

business

devices

Software

applications

Attackers can

exploit a

vulnerability

to steal or

corrupt data,

tamper with

systems

integrity, or

deny service

availability.

Without

personnel to

actively

counter the

attack it

would

succeed.

Depending on

the institution,

and type of

vulnerability it

can affect

patient

privacy,

institution

reputation,

and cause

financial

losses.

The

tampering

with systems

integrity

and/or their

data could

lead to

wrong

patient

treatment,

and major

damages.

6

5. Compromising medical devices

Medical devices such as MRI scanners, PET scanners, pacemakers, defibrillators, insulin pumps,

etc., often have unidentified security vulnerabilities. These vulnerabilities are left undisclosed due to

the lack of well-defined IT security policies for healthcare devices and third-party vendor oversight.

The rather specific nature of these devices, the difficulty of accessing them and the high skill level

required to attack them, reduces the number of possible threats. However, a successful attack can

have major impact on both the business and the patients health, with denial of service availability,

hardware/software integrity violation, and possible data exposure.

Real case: In 2016 a security researcher was able to connect to a MRI device inside a hospital

network with the assistance of Shodan, a search engine for the Internet of Things. The hospital

name was not disclosed. Another security researcher was able to tamper with his own insulin pump

and change the automatic dosage, proving that other insulins pumps are not secure.


vectors

Assets Technical

impact

Business

impact

Patient

safety

impact

Threat level

High

Vulnerability

Medium

Impact

Medium

Impact

Medium

Impact

High

Nation

states

Internal

personnel

Organized

crime

Hackers

Terrorists

Business

rivals

External

suppliers

Attackers

identify a

security

vulnerability on

a device, and

explore it. For

instance,

sending forged

requests to an

insulin pump,

or pacemaker.

Patients

health

Patients

information

Service

availability

Electronic

medical

devices

Depending on

the device,

sensitive data

can be

disclosed.

Systems

integrity is

affected. Both

primary and

secondary

services can

be

interrupted.

Depending on

the device,

confidential

information

may be

stolen.

Reputation

and financial

damages are

caused

mainly from

the patient

safety impact.

The exploit of

a medical

device has

major patient

safety impact.

In the worst

case, it can

cause patient

death or

severe health

issues like

cancer (due

to radiation

exposure).

7

6. Denial of service and business continuity

Revenue, and even patient safety can be affected if systems and data are not available when

required. The lack of mechanisms to support high availability can lead to unavailability in case of an

attack. Business continuity is also a concern due to the lack of backup mechanisms.

The impact of a successful attack could cause medium technical impact, but serious patient health

damage. Business would also be affected by both financial and brand damages.

An attacker has difficulties discovering these vulnerabilities, however the possible high rewards from

a successful attack, and ease of opportunity still produce a high likelihood for an attack.

Real case: In 2016 the Hollywood Presbyterian Medical Center was infected by a ransomware, that

encrypted all their files, and demanded a ransom for the decryption key. The medical center was

forced to pay to restore their operations and maintain business continuity.


vectors

Assets Technical

impact

Business

impact

Patient

safety

impact

Threat level

High

Vulnerability

High

Impact

Low

Impact

Low

Impact

High

Nation

states

Internal

personnel

Organized

crime

Hackers

Terrorists

Business

rivals

Companies

Attackers can

for instance fill

the network

with fake

requests,

making it

impossible to

differentiate

from real

request. Also

they can deny

the

information

required for

the services to

run e.g.

scramble all

patient

information.

Patients

health

Service

availability

Electronic

devices

(business

and

medical)

Software

applications

All services

can be

completely

unusable for

a period of

time.

Systems

integrity can

also be

affected

when data is

the attack

vector.

Service

unavailability

has financial,

and reputation

damages. If

the

unavailability

affects patient

safety it

enhances the

damage.

The

tampering

with systems

integrity, and

the possible

non-

availability of

a needed

treatment,

greatly affect

patient

safety.

8

7. Network vulnerabilities

A network vulnerability is a weakness in the network that can be exploited for unauthorized

purposes. Network systems may be vulnerable to both external or internal attacks. A successful

attack can lead to loss of confidential data, unauthorized access to specific resources, and in some

cases, even data tampering.

The impact of a successful attack is mostly technical with loss and/or tampering of confidential data.

However, in some special cases it can affect patients’ health.

The threat agent required for a successful attack has to be in most cases highly skilled, but the ease

of discovery of network vulnerabilities makes this risk relevant.

Real case: In 2010 at the University of Texas a file server in the network was compromised and

accessed. The compromise exposed the records of 27000 individuals to an unauthorized entity. The

protected health information involved in the breach included names, addresses, diagnostic codes,

name of medication prescribed, medication costs and some social security numbers.


vectors

Assets Technical

impact

Business

impact

Patient

safety

impact

Threat level

High

Vulnerability

High

Impact

Medium

Impact

Medium

Impact

Medium

Nation

states

Internal

personnel

Organized

crime

Hackers

Terrorists

Business

rivals

Companies

Attackers

scan the

network for

vulnerabilities.

If any is found,

an exploit is

developed,

and used.

Patients

health

Patients

information

Intellectual

property

and

proprietary

information

Service

availability

Electronic

devices

(business

and

medical)

Software

applications

A network

vulnerability

can lead to

unauthorized

access to

privileged

information, or

systems

control. The

range of

consequences

can be

delimited to

breaches of

privacy and

systems

integrity

violation.

Depending

on the

institution,

the number

of affected

users by a

privacy

breach

changes.

However, it

is expected

minimal

reputation,

and

financial

damages.

Unauthorized

access to

systems

controls can

affect patient

safety. The

effect could

be from minor

to

intermediate

damage to

patients’

health.

9


Social engineering in this context refers to manipulation of one or more employees – medical

doctors, nurses, assistants, technical staff, etc. – instead of IT systems and computer devices. Most

healthcare environments have this risk. The risk comes from the lack of training about cybersecurity.

Social engineering has many potential threats due to lack of technical knowledge necessary for a

successful attack, and the rewards it can provide. A successful attack could bring both technical, and

business impact with confidential data leakage and/or tampering, loss of availability, systems

integrity violation, but typically minor patient health impacts.

Real case: In 2013 at the University of Washington Medicine an employee downloaded an email

attachment that contained malicious malware. The malware compromised the organization’s IT

system, affecting the data of 90,000 patients. The data included patient names, medical record

numbers, dates of service, billing data, other demographics such as address and phone numbers,

dates of birth, social security numbers, and insurance identification.


vectors

Assets Technical

impact

Business

impact

Patient

safety

impact

Threat level

High

Vulnerability

Medium

Impact

Medium

Impact

Medium

Impact

Medium

Nation

states

Internal

personnel

Organized

crime

Hackers

Terrorists

Business

rivals

Companies

Attackers take

advantage of

poor

personnel

training, and

trick them into

performing an

unsafe action.

Examples:

Malicious

email with

malware;

Politely ask to

check a pen

drive content

which the

attacker

claims he

found.

Patients

health

Patients

information

Intellectual

property

and

proprietary

information

Service

availability

Electronic

business

devices

Software

applications

After being

tricked by an

attacker there

is no way to

predict what

is going to

happen. The

range can

vary from

confidential

data theft,

data

tampering or

temporary

denial of

availability.

The effects

are

proportional

to the access

that was

granted by

the tricked

employee,

Depending on

the institution

and the

access

gained, the

impact can

vary from

privacy

violation of a

couple users

to hundreds.

The same

can be

applied to

financial

damages.

The institution

reputation

may be

affected.

The

tampering

with systems

integrity

and/or its

data could

lead to

wrong

patient

treatment,

however that

kind of

access is

unlikely.

Patient

safety

impact is

ranked

medium.

10

9. Physical access to servers

Unauthorized physical access to healthcare servers happens when some individual accesses

illegally the server room. It can cause multiple problems such as confidential data leakage, integrity

violations, or denial of service.

The lack of proper access control contributes to the ease of access to these physical resources by

unauthorized individuals. The technical skills required for a successful attack are low, although

discovering these vulnerabilities is not hard, exploiting them can be. Overall the likelihood of an

attack is medium.

A successful attack carries both high technical, and business impact. Patients’ safety can also be

greatly affect.

Real case: In 2010 a computer network server and a television were physically stolen from Silicon

Valley Eyecare Optometry and Contact Lenses. The network server contained the electronic

protected health information (ePHI) of 40,000 individuals and included demographic information,

social security numbers, diagnoses, and insurance information.


vectors

Assets Technical

impact

Business

impact

Patient

safety

impact

Threat level

Medium

Vulnerability

Medium

Impact

Medium

Impact

Medium

Impact

High

Nation

states

Internal

personnel

Organized

crime

Hackers

Terrorists

Business

rivals

Companies

Note: Calculations

with internal

personnel as

specific threat,

produce a higher

threat level, high.

The lack of

effective

physical

access control

mechanisms

opens the

possibility of

direct physical

access to

hospital

assets, in

which an

attacker can

alter, insert, or

delete

contents.

Patients

health

Patients

information

Intellectual

property

and

proprietary

information

Service

availability

Electronic

devices

(medical

and

business)

Attackers with

access to

servers can

steal or

corrupt data,

tamper with

systems

integrity, or

deny service

availability.

Depending on

the institution,

it could carry

financial

damages,

patient

privacy

violation, and

possible

reputation

damages

depending on

the type of

attack.

The

tampering

with systems

integrity

and/or its

data could

lead to wrong

patient

treatment,

and major

patient health

damages.

11

10. Mobile devices

Mobile devices – smartphones, tablets, laptops – that connect to the organization’s networks and

systems, or store sensitive data, are a potential target in any healthcare environment. The increase

in use of different personal devices by healthcare personnel on professional activities, lack of

measures against theft/loss of devices, e.g., remote wiping, aggravate this risk.

The impact is mostly technical. A successful attack could leak confidential data, and in some special

cases affect systems integrity.

Threats are vast due to the average technical skills required for an attack and ample opportunity.

Real case: In 2010, AvMed suffered the theft of two laptops on one of their facilities. These devices included information on more than 1.2 million patients. The types of information involved included names, addresses, dates of birth, social security numbers and healthcare details.


vectors

Assets Technical

impact

Business

impact

Patient

safety

impact

Threat level

Medium

Vulnerability

High

Impact

Low

Impact

Low

Impact

Low

Nation

states

Internal

personnel

Organized

crime

Hackers

Business

rivals

Companies

Attackers

steal a mobile

device with

confidential

information, or

they can infect

a device with

software in

order to affect

the systems

that device will

connect to.

Patients

information

Intellectual

property

and

proprietary

information

Electronic

devices

(business

and

medical)

Software

applications

The theft/loss

of devices has

a medium

impact on

confidentiality.

Some mobile

devices have

sensitive data,

however not

big amounts.

In some

cases, it can

have minimal

impact in

systems

integrity.

Depending

on the

institution,

and the

mobile

device the

number of

affected

users differ.

A privacy

violation is

expected in

the range

from a single

to hundreds

of users.

The

occasional

system

integrity

tampering

can have a

minimal

effect on

patient

safety.

12

Methodology

This top followed a risk rating methodology based on the OWASP Risk Rating Methodology. For

each of the top 10 items, we estimated the vulnerability, threat, and impact levels. We did this using

knowledge from past events, and our technical expertise. The rank is ordered according to the

severity calculation of each risk.

The OWASP Risk Rating Methodology defines several factors to help calculate the risk. We did not

use all their factors. We tailored it to best suite our industry, healthcare. Our tailored methodology

includes eight likelihood factors. Four of them classify the threat level (skill level, motive,

opportunity, and size), and the other four the vulnerability level (ease of discovery, ease of exploit,

awareness, and intrusion detection). To calculate impact, we consider technical impact, business

impact, and patient safety impact. For technical impact, we have three factors (loss of confidentiality,

loss of integrity, and loss of availability), whereas for business we have four (financial damage,

reputation damage, non-compliance, and privacy violation). Patient safety has only one factor

(patient health). The overall impact is determined by the average of technical, business and patient

safety impacts, except for patient safety that has a multiplier (x2) due to its critical nature. The risk is

calculated using the average of the likelihood and the overall impact.

Note that, as for each risk there are several possible threats, to do the calculations we use a

generalized threat, a skilled and motivated attacker. The reason is that using different threats would

produce the same levels of severity. In special cases where the values produced differ we specify

them.

Lastly, our calculations take into consideration the new and approved data protection regulation by

the European Commission, which enters in application fully by May 2018.

Attack demonstrations

We also developed video attack demonstrations of two risks in our top 10. The reason for this was to

further increase the exposure to the topic, and provide a visual aid.

The risks we chose for these demonstrations were: Software vulnerabilities, and social engineering.

The reason for these choices were the ease of demonstration in video format, and ease of

comprehension for a target audience unrelated with most IT terms.

These demonstrations are available on YouTube at:

Software vulnerabilities – https://www.youtube.com/watch?v=BdFNcWeW38k

Social engineering – https://www.youtube.com/watch?v=lU5aDFYk008

13

Bibliography

Chaudhary, R., & Malarkey, R. (2016, Dec 12). Top 20 IT Risks for the Healthcare Industry.

Humer, C., & Finkle, J. (2014, Sep. 24). Your medical record is worth more to hackers than your

credit card. Reuters.

Independent security evaluators. (2016, Feb). Securing hospitals - a research study and blueprint.

OWASP. (2016). OWASP Risk Rating Methodology (in OWASP Testing Guide v4).

Security Risks in Healthcare Ivo Miguel Lopes Pinto

Documents

Transcript of Security Risks in Healthcare Ivo Miguel Lopes Pinto