IN THE FIELD OF TECHNOLOGYDEGREE PROJECT ENGINEERING PHYSICSAND THE MAIN FIELD OF STUDYCOMPUTER SCIENCE AND ENGINEERING,SECOND CYCLE, 30 CREDITS

, STOCKHOLM SWEDEN 2016

ICT Security of an Electronic Health Record System: an Empirical Investigation

An in depth investigation of ICT security in a modern healthcare system

JOHAN KVASTAD

KTH ROYAL INSTITUTE OF TECHNOLOGYSCHOOL OF COMPUTER SCIENCE AND COMMUNICATION

ICT Security of an Electronic Health RecordSystem: an Empirical Investigation

An in depth investigation of ICT security in a modern healthcare system

JOHAN KVASTAD

Master’s Thesis in Computer ScienceDegree Program in Engineering Physics

Royal Institute of Technology 2016Supervisor: Linda Kann

Company supervisor: Johan HedinExaminer: Johan Håstad

Principal: CSAM Sweden ABStudent’s email: jkvastad@kth.se

AbstractAn empirical investigation of the security flaws and features of an in-usemodern electronic health record system is performed. The investigationwas carried out using dynamic analysis, manual testing and interviewswith developers. The results indicate that in-use electronic health recordsystems suffer from serious authentication flaws, arising from the inter-action of many different proprietary systems. The authentication prob-lems are so severe that gaining access to any user’s computer on thehospital intranet would compromise a large database of patient medicalrecords, including radiological data regarding the patients. Commonweb vulnerabilities were also present, such as injections and incorrectlyconfigured HTTP security headers. These vulnerabilities were heavilymitigated by the use of libraries for constructing web interfaces.

ReferatICT-säkerhet inom vårdsystem:

en empirisk undersökning

En empirisk undersökning av säkerheten inom ett modern elektronisktpatientjournal-system har utförts. Undersökningen genomfördes medhjälp av dynamisk analys, manuell testning och intervjuer med utveck-larna. Resultatet indikerar att system för elektroniska patientjournalerhar stora brister inom autentisering, vilka uppstår p.g.a. att flera oli-ka kommersiella system måste samarbeta. Problemen är så allvarligaatt med tillgång till en enda dator på intranätet kan en stor databasmed patientdata äventyras, inklusive radiologisk data gällande patien-terna. Vanliga websårbarheter fanns också, så som injektioner av skriptoch inkorrekt konfigurerade HTTP säkerhetsheaders. Dessa sårbarhetermitigerades starkt genom användandet av bibliotek för webinterface.

Contents

1 Introduction 1

2 Background 22.1 History of the Electronic Health Record . . . . . . . . . . . . . . . . 22.2 HIS, RIS and PACS . . . . . . . . . . . . . . . . . . . . . . . . . . . 22.3 IHE, Dicom and HL7 . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.4 XDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.5 Bugs and Flaws . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.6 Vulnerability Assessment . . . . . . . . . . . . . . . . . . . . . . . . . 42.7 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3 Method 63.1 Target Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63.2 Automated Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3.2.1 Dynamic Analysis . . . . . . . . . . . . . . . . . . . . . . . . 73.2.2 Static Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3.3 Manual Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83.4 Test Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

4 Results 114.1 Target Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114.2 Tool Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

4.2.1 Dynamic Analysis Tools . . . . . . . . . . . . . . . . . . . . . 114.2.2 Static Analysis Tools . . . . . . . . . . . . . . . . . . . . . . . 13

4.3 Tool Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134.3.1 OpenVAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134.3.2 Nikto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144.3.3 Vega . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144.3.4 w3af . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154.3.5 OWASP ZAP . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4.4 Manual Testing Results . . . . . . . . . . . . . . . . . . . . . . . . . 154.4.1 Injections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164.4.2 Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . 16

5 Discussion and Conclusion 175.1 Discussion of Tool Results . . . . . . . . . . . . . . . . . . . . . . . . 17

5.1.1 HTTP security headers . . . . . . . . . . . . . . . . . . . . . 185.1.2 False positives . . . . . . . . . . . . . . . . . . . . . . . . . . 20

5.2 Discussion of Manual Assessment . . . . . . . . . . . . . . . . . . . . 205.2.1 Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . 215.2.2 Injections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

5.3 Empirical Results and Previous Research . . . . . . . . . . . . . . . 225.3.1 Standards and Policies . . . . . . . . . . . . . . . . . . . . . . 225.3.2 Pseudo anonymity techniques . . . . . . . . . . . . . . . . . . 235.3.3 Encryption of patient data . . . . . . . . . . . . . . . . . . . 235.3.4 Data access and role based access control . . . . . . . . . . . 235.3.5 Audit trails . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

5.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245.5 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

References 26

Chapter 1

Introduction

In the healthcare sector there is a need to store information about patients. Asthe digitalization of society progresses healthcare practitioners no longer store thisinformation on paper but instead store it electronically. Meanwhile, since the diag-nosis and treatment of a patient is no trivial endeavor, it is natural for a patient’sdata to be accessed by a multitude of professionals in a multitude of ways. Thisgives rise to the need for networked Information and Communication Technology(ICT) solutions to collect and access a patient’s data. This collection of data isreferred to as an Electronic Health Record (EHR) [1].

Along with these ICT solutions comes a host of related security problems. Theseproblems have been studied to some extent [2,3] but little empirical work has beendone on the subject. This degree project is aimed at investigating empirically whatsecurity problems are present in actual implementations, why they are present andwhat can be done to solve or mitigate these problems.

The study comprises an investigation of an EHR subsystem used to access vari-ous data collected from multiple hospitals. This project is carried out in co-operationwith CSAM Sweden AB, the company producing the system, thus granting access tothe software and also access to developer competence regarding the software. Secu-rity flaws uncovered by this investigation which are within the company’s influencehave been addressed as needed.

1

Chapter 2

Background

This chapter provides context for the EHR system under investigation, including abrief history of it’s development, methods for analyzing the security of the imple-mentation and this project’s relation to current research.

2.1 History of the Electronic Health RecordOne can conceive of the EHR in relation to the Electronic Medical Record (EMR) [4].The EMR is the digital version of the classically paper format patient data such asmedical charts and patient journal files. An EHR is a broader term for a digitalpatient record, including data gathered from many different systems and clinics. Forexample the EMR of a patient at one clinic can be included into that patient’s EHR,making it accessible at another clinic as if it was a local EMR. Perhaps because ofthis, EHR and EMR are used interchangeably to some extent [4].

The EHR has evolved from early Multi-Hospital Information Systems (MHIS)which started to appear in the 1960s [5]. As the systems used by various hospitalswere integrated with one another, it was only natural that the patient data thesesystems handled would be integrated as well, resulting in the EHR. In the recentdecade the EHR has seen a large increase in popularity [6], with usage by office-basedphysicians in the U.S. increasing from 18% to 78% through the years 2001–2013.In late 2008 Estonia adopted a nationwide EHR [7]. More advanced than the EHRthere is the concept of the Electronic Personal Health Record (EPHR) [8]. In theEPHR the patients’ data is not only available across hospitals, but is also availableto the patients themselves. EPHR is beyond the scope of this investigation whichwill be limited to the EHR.

2.2 HIS, RIS and PACSAn EHR is ideally the collection of all of a patient’s medical records, made availableto all relevant hospitals and physicians. However, this aggregate nature of the EHRdoes not mean that an EHR is comprised of a single system, developed and operated

2

CHAPTER 2. BACKGROUND

by a single provider. Rather, there have been multiple EMR systems which over theyears required integrating with each other to produce an EHR. Two classes of suchEMR systems are the Radiology Information System (RIS) and the Picture ArchiveCommunication System (PACS) [9]. These can be considered subsystems of theHospital Information System (HIS) [10], a more general system including functionssuch as patient admission, inventory control and personnel data.

The first RISs and HISs were developed in the 1960s, bringing digitalization tothe hospital workflow. For radiology this included scheduling examinations, man-aging images and (physical) folders, and preparing work lists. Notably the RIS didnot handle actual storage of the image files. In fact there were no image files atthis time but instead physical films. Digital images in radiology started to appearin the 1970s along with computerized tomography. These were then handled bythe PACSs which began developing in the 1980s. At this time computer storagewas very limited with hard drive capacity in the range of a few dozen megabytes,making it possible only to store a handful (if any!) pictures per drive. In these earlyyears special hardware was needed to handle the then relatively large image files.Notably magnetic tape was used which is still a relevant technology, e.g. CERN’sdata storage system CASTOR [11]. While these storage limitations are no longerrelevant for healthcare the overall system architecture of having RIS and PACS sys-tems is still with us. These systems now face the challenge of integrating betweenhospitals to contribute to a patient’s EHR.

2.3 IHE, Dicom and HL7As many different actors developed different HIS, RIS and PACS solutions therearose a need for these systems to communicate not only with each other, but alsowith different proprietary protocols within a subsystem. That is, the CT scan-ner from vendor A might come with a certain protocol and the MRI scanner fromvendor B has another, yet they must communicate with some archive from vendorC which could use a third protocol! Thus standards for information storage andcommunication developed alongside these systems [9,12]. Today the standard usedby PACS is Digital Imaging and Communication in Medicine (DICOM) and thestandard used by RIS and HIS is Health Level 7 (HL7). There is also an organiza-tion which promotes the effective use of these standards called the Integrating theHealthcare Enterprise (IHE) initiative. This initiative provides IHE Profiles, whichspecify what parts of a standard (such as DICOM) a system is in compliance with.In addition some profiles function more like regular standards.

2.4 XDSAmong its many profiles, IHE publishes the Cross-Enterprise Document Sharing(XDS.b) IHE Integration Profile [13]. This will be referred to as XDS for simplicityin this document. XDS is a standard for sharing documents between healthcare

3

CHAPTER 2. BACKGROUND

enterprises, including both images and text (XDS is in fact document content neu-tral). This purpose is shared with the EHR concept, making XDS a natural objectof study in this work. The XDS does not itself include a security model, this mustbe implemented separately.

2.5 Bugs and FlawsWhen looking at security problems in a system we can distinguish between twogeneral types of problems [14]. Design Flaws pertain to architectural problems ofthe software. Implementation Bugs on the other hand are faulty implementations ofthe design. For example, neglecting to include an authentication mechanism whereone is needed would be deemed a design flaw. On the other hand, implementing anauthentication mechanism which can be bypassed using some technique would bedeemed an implementation bug.

The bugs and flaws of a system are also known as the vulnerabilities or theweaknesses of the system. These weaknesses can be categorized in a multitudeof ways, of notable interest is the Common Weakness Enumeration (CWE) [15]and Common Vulnerability Enumeration (CVE) [16] maintained by the MITREcorporation. At the time of writing the CWE contains classifications for roughly athousand different categories, with the CVE containing over 70,000 explicit cases.In addition to the CWE and CVE there exist other resources on bugs and flaws.One such is provided by the Open Web Application Security Project (OWASP) [17]which maintains a top 10 list of web application security issues. Another is theCritical Security Controls (CIS) [18] maintained by the SANS institute, which is amore wide-spanning approach to computer security.

2.6 Vulnerability AssessmentThe process of searching for vulnerabilities in a system is called Vulnerability De-tection or Vulnerability Discovery. This is usually part of a Vulnerability Assess-ment, which also includes learning about the system (called Target Discovery) andanalyzing the results (Result Analysis). There are multiple ways of performingvulnerability detection [19]:

• Exploratory manual testing

• Systematic manual testing

• Dynamic analysis

• Static analysis

• Mutation based fuzzing

• Generation based fuzzing

4

CHAPTER 2. BACKGROUND

In exploratory manual testing the tester explores the system, looking for vulner-abilities based on the testers experience but without any systematic approach. Incontrast the systematic manual testing may contain checklists or some sort of explo-ration plan. Dynamic and static analysis seek to automate the manual procedures,allowing much larger sets of tests to be run. Dynamic analysis tests the system atrun time, similar to a tester exploring system functionality. Static analysis insteadtests the systems source code without executing it, similar to a tester conductingsource code review. The fuzzing techniques are based on providing a system with in-put deviating from normal input, thus “fuzzing” the input. Mutation based fuzzingalters pre-defined input through some process such as bit-flipping or exchanging keywords. Generation based fuzzing instead creates original input based on a model ofthe system.

The efficiency of some of these methods have been compared [20, 21]. Basedon this aptly named work “One Technique is Not Enough. . . ”, one technique doesnot seem to be able to find a superset of the vulnerabilities discovered by anothertechnique. Thus many techniques will likely be needed.

2.7 Related WorkThere has been previous work on EHR security, notably summarized in [2] and [3].These are literature surveys which both point out the limited empirical basis of EHRsecurity. While limited, some work exists, including [20, 21]. These works focus oncomparing different techniques of vulnerability discovery — but in so doing use opensource EHR systems as their object of study. Thus the result of these works includevarious implementation bugs found in the EHR systems. Their focus, however, liesin comparing the different discovery techniques to each other and not analyzinghealth care security. That is instead the purpose of this project.

5

Chapter 3

Method

This chapter covers the methods of interest for analyzing the XDS EHR system.The methods comprise dynamic analysis, static analysis and manual testing. Targetdiscovery, the act of finding general information about the system, is also detailedas well as the test environment used for conducting the project.

3.1 Target DiscoveryThe first part of a vulnerability assessment is the target discovery [19]. The goalis to chart the technical aspects of the system being assessed, in this case theXDS implementation which constitutes part of the EHR. Target discovery usuallyincludes charting relevant network topology and identifying the systems applicationsand protocols. This information is primarily needed to select tools and strategiese.g. static analysis tools are usually language specific and require access to sourcecode, while penetration testing requires no access to source code but knowledge ofnetwork topology is helpful. In the case of the XDS implementation the discovery isstraightforward - the company already has source code and system documentationavailable. Along with this, a virtual network set up to mimic the target site is alsoavailable for testing purposes.

3.2 Automated ToolsWhen looking for vulnerabilities in software we can do so manually or enlist theaid of tools which perform tasks automatically. Such tools may inspect a systembased on either its run time properties, called dynamic analysis, or its source codeproperties, called static analysis. As is noted in [20,21], static and dynamic analysistools find different individual security errors even within the same error category.Thus there is merit to using both methods. In addition, for a given type of toolthere are usually a few different tools to choose from. These in turn also producedifferent results, usually the result of one tool does not contain the entire resultof another tool [22]. This situation creates incentives to use many different tools.

6

CHAPTER 3. METHOD

However, tools come at a cost. Sometimes financially - but always in time spentlearning and configuring the tool. This degree project is done without a budget andthus must use free alternatives exclusively. While some tools are free and even opensource, some cost hundreds of thousands of dollars. Expensive tools may sometimeshave free community editions, but these are seldom allowed in a corporate setting.Sine the project is carried out with a private business as principal, such communityeditions are ruled out.

3.2.1 Dynamic AnalysisAutomated tools that analyze a program’s behavior during run time are calleddynamic analysis tools [22,23]. Such tools which look for vulnerabilities in softwareare called Vulnerability Assessment tools. These can be further divided into SystemAssessment Tools and Application Assessment Tools [24], but for the purposes ofthis work no such distinction is required.

For dynamic analysis the Open Web Application Security Project (OWASP) hasa list of known tools specialized for vulnerabilities in web applications [25]. Suchspecialized tools are also known as scanners as they scan an application for vulnera-bilities. Since the user interface of the XDS is a web application these vulnerabilityscanners will be of great interest. Other more general vulnerability assessment toolscan be found by searching the internet. These tools include Nessus, OpenVAS, CoreImpact, Nexpose and Qualys Guard. While some of these were once open source,most are currently proprietary with the exception of OpenVAS. Some of the pro-prietary software solutions offer free versions, however, these are typically heavilyrestricted or for non-corporate use. Since the project is carried out at a companythe latter is a concern. A short description of the non-commercial vulnerabilityscanners listed by OWASP [25] and otherwise notable tools are provided in table3.1.

3.2.2 Static AnalysisAutomated tools that analyze a programs source code are called static analysistools. Some static analysis tools used for security purposes are listed by the Na-tional Institute of Standards and Technology’s (NIST’s) Software Assurance MetricsAnd Tools Evaluation (SAMATE) project [26]. These along with other well knownjavascript source code analyzers are listed in table 3.2.

Unfortunately there is a sparsity of javascript static analyzers for applicationswith heavy use of libraries as this is still a challenging problem for static analysistools [27, 28]. Depending on the results of the target discovery, static analysis maynot be possible.

7

CHAPTER 3. METHOD

Table 3.1. Non-commercial dynamic analysis tools.

Name Last activity DescriptionGrabber 2006 “Minimum bar” scanner for the SAMATE

Tool Evaluation Program at NIST.Grendel-Scan 2013 Web application scanner.GoLismero 2016 Vulnerability testing framework, all scan-

ning functionality through plugins.Nikto 2016 Web application scanner.OpenVAS 2016 Vulnerability testing framework, contains

own scanner.OWASP ZAP 2016 Intercepting proxy with scanning capabil-

ities.Vega 2015 Intercepting proxy with scanning capabil-

ities.Wapiti 2014 Web application scanner.w3af 2016 Web application scanner.Xenotix 2016 Emulates a Firefox, Internet Explorer and

Chrome browser and allows the user tocraft HTTP GET and POST queries usingfuzzing techniques.

3.3 Manual TestingIn addition to testing the XDS system using automated tools, manual testing is ofinterest. The manual testing was based on the OWASP top ten [29] and discussionswith the developers. The OWASP top ten is a listing that aims to represent themost critical common web application security flaws. The list is currently basedon “over 500,000 vulnerabilities across hundreds of organizations and thousands ofapplications.”. The developers’ opinion was that the web interface was the mostinteresting part to study since most other functionality is behind firewalls and isreachable only via the XDS Document Consumer server (see figure 4.1). Codeinjection and authentication were then selected as the primary concern of the manualtesting. It was further decided that if a security feature hinged on the correctimplementation of a library function then it would be assumed that the functionwas indeed correctly implemented, as recursively testing all libraries used would bean infeasible scope of the manual testing. The testing was carried out by first findingall possible input fields and their corresponding outputs in the client [30]. This wasachieved by reviewing the source code (e.g. look for .innerHTML assignments) andsystematically going through the functionality of the application. Furthermore theserver code relevant for communicating with the other servers behind the firewallswas reviewed.

8

CHAPTER 3. METHOD

Table 3.2. Javascript static analysis tools.

Name Last activity DescriptionCheckmarx CxSAST 2016 Commercial.Closure Compiler 2016 Javascript minifier for optimizing down-

load performance. Also warns about com-mon mistakes such as index out of boundsor trailing commas.

ESLint 2016 Similar to JSHint and JSLint, but rulesare plugins.

Fortify SCA 2016 Commercial.HP QAInspect 2011 Commercial.JSHint 2016 Javascript style checker. Fork of JSlint

which allows configuration of rules.JSlint 2016 Javascript style checker. Not primarily a

security checker, but common program-ming anti-patterns can sometimes resultin security problems.

JSprime 2014 Security focused tool. Some support forJQuery library.

TAJS 2015 Tool for analyzing type related errors injavascript, e.g. reading properties of nulltype objects.

Yasca 2015 Inactive project on OWASP, most files onGithub have not been updated for 4 years,but a few were updated 2015.

3.4 Test EnvironmentAutomated tools and manual testing need to be carried out on an actual imple-mentation and for this a testing environment was set up. The testing environmentconsisted of running the target software in a Docker [31] container on a Linux Mint17.3 [32]. The testing tools were run on a Kali Linux 2016 and a Kali Linux 2.0 [33]virtualization using Virtual Box [34]. To ensure the tools were set up correctly theywere tested against Metasploitable 2 [35], which was also virtualized using VirtualBox, as well as Mutillidae 2 [36], which was run on the Linux Mint. Metasploitable2 is a purposefully insecure Linux virtual machine and Mutillidae 2 is a deliberatelyinsecure web application. This allows the tester to verify that the scanners arecorrectly installed and configured by scanning these insecure systems. If no errorsare found, then the scanner is most likely incorrectly installed or configured. Forexample, when scanning Metasploitable 2 using OpenVAS some 60 security flawswere found, including a backdoor allowing remote root access, keylogging exploits,

9

CHAPTER 3. METHOD

bad SSH usernames and passwords (user:user) and SQL injections. Similarly whenthe intercepting proxy OWASP ZAP was used on Mutillidae 2 there were hundredsof flaws detected, including path traversal (illegally accessing files on the server sys-tem), remote file inclusion (uploading any file to the server, possibly executing codeon the server), cross site scripting (illegally running arbitrary code in the user’sbrowser), SQL injection and remote OS command injection.

10

Chapter 4

Results

This chapter presents the results of the automated and manual testing, along withthe target discovery and selection of tools. The main findings were serious authen-tication problems and injections found via manual testing, multiple dangerouslyconfigured HTTP headers found via automated testing and the fact that currentstatic analysis tools were insufficient for carrying out static analysis on the XDSimplementation.

4.1 Target DiscoveryThe system under investigation is an XDS.b version 12 compliant registry, repositoryand consumer [13]. The XDS system implementation receives patient informationfrom various systems, including RIS and PACS, see figure 4.1. These are then servedto the XDS Document Consumer server. The XDS Document Consumer server thenstores a local cache in the Elasticsearch database [37]. The end-user accesses thedata via the javascript client in their browser, and the server stores preferences suchas filters in the Cassandra database [38].

4.2 Tool SelectionThe selection results from both the dynamic analysis tools and the static analysistools are presented below. For dynamic analysis, criteria were needed to narrow thenumber of candidates down. For static analysis, there were no scanners appropriatefor the task.

4.2.1 Dynamic Analysis ToolsFor dynamic analysis tools there were many tools to choose from (see table 3.1).Thus some criteria were set to narrow the selection to a manageable size. Sincetools need to be up-to-date with current security threats, tools with inactive devel-opment were excluded. In this project a tool is deemed inactive if there has been no

11

CHAPTER 4. RESULTS

Figure 4.1. XDS implementation overview

development in the last two years, as was done in a similar project on the topic ofsecurity in agile development [39]. A summary of the fitness of the tools presentedin table 3.1 is found in table 4.1.

Table 4.1. Vulnerability assessment tools’ fitness for study.

Name FitnessGrabber Inactive.Grendel-Scan Inactive.GoLismero Platform, overlaps with other tools.Nikto Ok.OpenVAS Ok.OWASP ZAP Ok.Vega Ok.Wapiti Inactive.w3af Ok.Xenotix Ok, manual aid.

A note on GoLismero, OpenVAS and Xenotix: The tool GoLismero is a platformrather than a scanner and for this project the interest would then lie in the plugins.The default plugins are Nikto, Nmap and SSLScan. Nikto is already included in the

12

CHAPTER 4. RESULTS

analysis and is thus not unique for GoLismero. Nmap [40] is used to characterizenetworks (e.g. find what services are running) and SSLScan [41] characterizes whichciphers are supported by SSL services. Default installed GoLismero is then verysimilar to Nikto. GoLismero will therefore be excluded as it overlaps with Nikto.

OpenVAS is also a platform but comes with its own scanning functionality,consisting of some 47,000+ tests, which compared to the 76,600 CVE codes inexistence as of June 2016 is of some significance [16].

Xenotix has some automatic capabilities but these are fuzzing methods for man-ually selected URL or HTML DOM parts [42]. Thus it is more of a manual aid ratherthan an automatic scanner.

4.2.2 Static Analysis ToolsThe situation for static analysis of javascript for security seems to be that thereexist few free or open source tools designed for security, and no tools at all whichhandle applications relying heavily on javascript libraries well [27, 28]. The systemunder investigation relies heavily on the Dojo toolkit [43], a development library forbuilding web applications, and so a static tool fit for the analysis must handle thislibrary well. This means that there is currently no open source static analysis toolrelevant for the investigation, and static analysis cannot be carried out for the XDSConsumer.

4.3 Tool ResultsThe tool results are summarized in table 4.2. Of note is that there is little overlapin the results found by the different tools, only three of ten topics overlap. Addingto this, in the internal address case the addresses found were not the same. It isalso of note that six of the ten problems found were related to incorrectly config-ured HTTP headers, something which is straightforwardly tested for. The lack ofoverlap between the tools in such a situation is unfortunate, as a tool user mightmiss seemingly standard security checks by using only one tool. The specifics andconsequences of the results are discussed in the discussion section on HTTP securityheaders 5.1.1.

4.3.1 OpenVASOpenVAS flagged for eight warnings. However, these were all false-positives pertain-ing to Cross Site Scripting (XSS) vulnerabilities in software which was not presentin the testing environment. Cross site scripting occurs when malign script is in-jected into the user’s browser, allowing the attacker to e.g. steal session cookies orkeylogg the user on that page. Six of the eight false-positives regarded CommonGateway Interface (CGI) scripts [44]. These are scripts used to present dynamicweb content, but can sometimes be exploited to execute arbitrary code on the servere.g. via the Shellshock bug.

13

CHAPTER 4. RESULTS

Table 4.2. Tool result summary.

Topic Reported by Problem descriptionX-XSS-Protection Nikto, OWASP ZAP Missing header.X-Frame-Options Nikto, Vega, OWASP ZAP Missing header.Strict-Transport-Security Nikto Missing header.X-Content-Type-Options Nikto Missing header, header

not set to “nosniff”.Content-Type Vega Character set not speci-

fied.Cache-Control OWASP ZAP Missing header.E-mail addresses Vega E-Mail address found.Internal address Vega, OWASP ZAP Internal address found.Internal server error OWASP ZAP Internal server error

found.Cross Site Request Forgery w3af Dangerous parameters

found.

4.3.2 NiktoWhen running Nikto against the target system the error codes produced refer to theOpen Source Vulnerability Database (OSVDB), a project which shut down on 5thApril 2016. Thus the results produced by Nikto could have been difficult to study asonly short descriptions were then available. Fortunately the OSVDB codes can beconverted to CVE codes [45]. Nevertheless Nikto flagged for 84 warnings, but 80 ofthese were false positives. These false positives were all related to Nikto incorrectlyclassifying a HTTP 200 OK, blank page return or javascript heavy page as a positiveresult for the test in question. For example a test might try to access a CGI script ina CGI folder, but no such folder exists on the server. Instead the server would servea blank page rather than a HTTP 404 and Nikto would incorrectly classify thisas a positive identification of a vulnerability. It might also try to access a “.exe”file on the Linux file system and claim it could execute it, but no such file evenexisted. The four warnings which were not false positives all pertained to HTTPheader configurations. These were namely the headers X-XSS-Protection, X-Frame-Options, Strict-Transport-Security and X-Content-Type-Options which were eithermissing or set to allow anything. These headers are discussed in discussion section5.1.1.

4.3.3 VegaVega reported six types of warnings: HTTP X-Frame-Options header missing, Char-acter set not specified, email-address found, internal address found and HTTP

14

CHAPTER 4. RESULTS

Access-Control-Allow-Origin allows everything. The character set not specifiedrefers to the server not specifying character set for the served document, whichallows the browser to guess a character set. The email address found was an oldsupport email for the company. The internal addresses found were non-XDS relatedservices running on the test machine i.e. noise.

4.3.4 w3afW3af experienced some technical problems, such as fatal crashes on the test en-vironment. Some scanning profiles also would not complete as the crawler wouldget stuck on various URLs, such as a picture or an empty folder. Aggregatingwhat progress the scanner did make from the various profiles produced some re-sults nonetheless. Most results from w3af were flagged as informational, such as OSdiscovery, empty response bodies on HTTP 200 OK, which HTTP methods wereallowed etc.

W3af flagged for two security warnings: directory path disclosure and Cross SiteRequest Forgery (CSRF). The directory path disclosure did not actually disclosedirectories in the test environment, but were rather what seemed like path macrosused in compressed Dojo toolkit code. Since these macros refer to the Dojo toolkitdirectory structure and not system specific directories the warning was deemed afalse positive. The CSRF regarded the use of URL query string parameters whichaffect the site functionality. The parameters in question controlled which viewerthe browser should load and which user is using the application. Normally CSRFis about tricking a user’s browser to perform malicious activity as the user, butin this case the problem is deeper and lets the attacker authenticate as the user.The serious issue of authentication using plain text URL query string parameters isdiscussed further under the dedicated discussion on authentication in section 5.2.1.

4.3.5 OWASP ZAPOWASP ZAP gave the following warnings: the HTTP X-Frame-Options header wasnot set, an internal server error was found, Cache-Control HTTP header missing, X-XSS-Protection missing, Anti-MIME-Sniffing header X-Content-Type-Options wasnot set to “nosniff”, Content-type header was missing and some internal addresseswere found.

4.4 Manual Testing ResultsThe manual testing discovered a total of seven script injections and serious problemswith authentication. The source code was available and there arose no need forfuzzing with Xenotix as the required payload could in each case be inferred fromcode review. Thus Xenotix was not used.

15

CHAPTER 4. RESULTS

4.4.1 InjectionsFilter names

The first four injections found were related to the name of filters for queryingpatient data. The user could name a filter e.g. “</span><IMG SRC="/" on-error="alert(’Script injected’)"><span>” and this would then execute the script infour different locations. This implementation bug was rooted in the fact that thesystem needs to store arbitrary names in its database, but depending on the HTMLcontext of where it was displayed the name could allow executable code. While theDOJO toolkit used does offer functionality to HTML encode the output, which isused at several other places in the system, this had simply been missed at the fourinjection locations. It is noteworthy that the possibility of sharing filters betweenphysicians has been discussed. Such sharing would have made an excellent attackvector, as then an insider physician only needs to share a filter with a colleague torun arbitrary malicious browser scripts.

URL query string parameters

Three more injections were found which depended on query string parameters. Thefirst two were in addition dependent on certain administrator settings. The admincould set various parameters such as the patient ID and the referring unit as beingnon-editable from the user interface. However, these parameters could still be setusing a URL query string. Similar to the previous injections, in the non-editablemode the query string parameters would not be properly escaped and thus allowedinjection. Lastly an injection was possible by changing the user name, which wasalso supplied via a URL query string. The user name is displayed in the userinterface and was not properly escaped.

Database injections

The consumer server connects to three databases as discussed in the target dis-covery section 4.1. In neither of these three cases does the server create a querystring as in the common SQL injection scenarios, but instead uses parameteriza-tion. Thus database injections through the XDS consumer server are unlikely, e.g.implementation flaws in the database versions or similar need to be found.

4.4.2 AuthenticationAuthentication for users is barely existent as it is handled via a plain text parameterin the URL query string. In effect, anyone on the internal network can authenticateas any user (in the XDS system) as long as they know that user’s user name. Foradmins there is a better solution in place where a user name and password is sentover HTTPS and the client receives a session cookie. The disparity between adminand user authentication is explained in discussion section 5.2.1.

16

Chapter 5

Discussion and Conclusion

This chapter discusses the results from the automatic tools and manual testing.In addition, the results are compared to previous related work and future work issuggested.

The poor state of authentication is likely the most serious problem as anyone whogains access to any user account on the intranet can access the entire XDS database,in addition the problem cannot be easily fixed as it is dependent on multiple EHRvendors cooperating. There are other security flaws of similar severity such as theAccess-Control-Allow-Origin HTTP header allowing any site visited by a user tomake requests to the XDS database, meaning a user who visits a malicious sitewhile logged onto the intranet could leak the entire XDS database. This flaw ismore easily fixed as only a single header field needs to be changed in the XDSsystem.

In relation to previous work many features which are discussed as important inthe literature such as encryption of stored data and certain standards were absentfrom the XDS system. Notably a feature which was present in the XDS was audittrails.

5.1 Discussion of Tool ResultsIt is of interest to note that none of the scanners found any of the injections.In related work hundreds of SQL injections were found [20, 21] and several XSSattacks were found. This implementation did not use SQL databases, which explainsthe lack of SQL injections, but there were several XSS vulnerabilities - which thescanners did not find. A possible explanation could be that the scanners used donot work well with javascript. Almost the entire XDS web interface is written injavascript and so handling it poorly would hinder the success of the scanners. Ofnote is the Asynchronous Javascript and Xml (AJAX) spider featured in OWASPZAP. AJAX is a set of techniques for building dynamic web applications, such asthe XDS. The AJAX spider made some progress toward finding the injections, as itentered input into some relevant fields, but ultimately did not succeed in injecting

17

CHAPTER 5. DISCUSSION AND CONCLUSION

any scripts. This is perhaps because it did not try any multi-step maneuvers suchas pressing a button to open a menu, entering data into that menu, then pressing abutton so save changes. While the open source vulnerability tools were not so goodwith javascript, they did find problems with HTTP headers.

The injections found using manual testing were all due to unescaped HTMLoutput. The DOJO toolkit used for the web application has functionality for es-caping HTML, which was also used in many places of the web app, but its usagewas missed in the injection locations. Thus it might be a good idea to regularlyperform manual penetration testing as these injections were straightforward to find.The consequences of an XSS attack for the XDS system would be data theft of ev-erything the victim can access via the XDS, which currently is everything availablein the repository. At the moment the repository contains data from radiology, gen-eral pictures and associated data taken by physicians and endoscopy data. Whilethis is sufficiently interesting for an attacker as is, since the repository is documentneutral, it may expand its data range in the future which would only increase theseverity of a successful XSS attack.

5.1.1 HTTP security headersThe following HTTP security headers were related to problems flagged by the scan-ners. As many of these relate to browser behavior it is important to note that thehospitals using the XDS system are using Internet Explorer 8 (IE8).

X-XSS-ProtectionThe X-XSS-Protection header is originally an IE8 feature which decides whetherthe XSS filter for the Microsoft browser is activated. The purpose of this filteris to mitigate XSS attacks. The filter tries to detect an XSS attack and modifiesthe response from the server, but the filter can be exploited to create XSS flawswhich are not present without the filter [46]. This is noted in Microsoft securitybulletin MS10-002 [47] where it is given CVE code CVE-2009-4074 [48] and anoption to completely block the server response rather than modifying it was addedin bulletin MS10-018 [49]. The default browser behavior is to let the filter modifyserver responses. Due to the above vulnerabilities the header should therefore beset explicitly to either “X-XSS-Protection: 1; mode=block” for using the filter butcompletely blocking suspicious responses or “X-XSS-Protection: 0” for disablingthe filter entirely. The former is likely preferred as it provides additional securityagainst XSS attacks without introducing new vulnerabilities.

X-Frame-OptionsThe X-Frame-Options header is described in RFC 7034 [50]. The purpose of theheader is to avoid clickjacking [51]. In clickjacking the attacker sets up a malicioussite A which renders a legitimate site B in e.g. a carefully crafted HTML <iframe>,usually transparent. When the user thinks they are clicking in site A, they areactually clicking on specific parts of site B such as account deletion or sending

18

CHAPTER 5. DISCUSSION AND CONCLUSION

unintended Twitter messages. Site B can tell the user’s browser not to renderin a frame by using X-Frame-Options, thus preventing such clickjacking. In thissetting clickjacking could be used to e.g. have a physician sign a referral responseas completed without the physicians knowledge.

In the application under study the X-Frame-Options header is related to theauthentication as the implemented solution for hiding the URL in the browser isbased on rendering the client application in an iframe. Thus enabling this clickjack-ing defense could potentially break application functionality. Nevertheless, there isa configuration which only allows the issuing site to render the content in frames.Using the “SAMEORIGIN” value for the header field should allow both clickjackingdefenses and normal application execution.

Strict-Transport-SecurityThe Strict-Transport-Security header, known also as the HTTP Strict TransportSecurity (HSTS) policy is described in RFC 6797 [52]. The purpose of the headeris to enforce the usage of HTTPS for a site in order to avoid attacks based onHTTP. Even if the site uses HTTPS it is possible to accidentally have non-HTTPSfunctionality, or for the user to override warnings of bad certificates. HSTS preventsboth of these. As the application in question already uses HTTPS there should befew problems complying with the HSTS policy.

X-Content-Type-OptionsThe X-Content-Type-Options header is originally an IE8 feature which tells thebrowser how to do content-sniffing, also known as MIME-sniffing. If it is not prop-erly configured a HTTP response marked as containing one type of data might beinstead interpreted as containing another, allowing an attacker some possibility tochoose how data is interpreted. This can be exploited, e.g. an image is crafted sothat it is interpreted as code and executed in the browser when loaded [53]. In theXDS system a user could upload a tampered medical image (or other file type) tothe repository, and then when it is viewed a payload is executed. Setting the headerto “X-Content-Type-Options: nosniff” will disable content sniffing.

Content-TypeThe Content-Type header is described in RFC2045 [54]. The warning raised byVega pertained to not specifying the character set, e.g. UTF-8. This has beenexploited in the past, for instance one could make the browser Internet Explorer 7interpret a response as UTF-7. One could then perform XSS exploits by encodingthe payload in UTF-7 which would pass through filters such as PHP’s htmlentitiesfunction, and then the browser would decode the payload and execute it. Thus caremust be taken so that the charset used when filtering is the same as that used whenparsing the web site.

19

CHAPTER 5. DISCUSSION AND CONCLUSION

Access-Control-Allow-OriginThe Access-Control-Allow-Origin header is described in the W3C Cross-Origin Re-source Sharing (CORS) recommendation [55]. In the current XDS system it is setto the wildcard value * for all resources. This is something which normally is onlyrecommended for a completely public site, which the XDS system is not. The wild-card setting allows scripts originating from any domain to access the responses fromrequests which would normally be blocked by the same origin policy. Thus a user onthe internal network might access a malicious site via e.g. social engineering. Themalicious site could then issue requests for the internal site and steal the responses,possibly requesting and stealing the entire database [56]. This is a serious problemwhich must be addressed. A solution is to white-list only the domains which needCORS, and only allow CORS on the resources which require it rather than everyresource. This also requires some form of authentication, as otherwise the Originheader might just be spoofed.

Cache-ControlThe Cache-Control header is described in RFC 7234 [57]. The header instructs thebrowser whether to cache the HTTP response, and if so how it should be done.Caching sensitive information can be exploited. For instance if a malicious useraccesses a browser which contains cached information the malicious user can stealthe information. If the header is missing then the response might still be cacheddepending on browser. This could be exploited by an attacker who temporarilygains access to a physicians computer via e.g. social engineering. The attackercan then access the cached patient data and download it on a USB or email it,concluding the data theft.

5.1.2 False positivesSeveral false-positives were related to CGI scripts. Nikto and OpenVAS both foundmany false positives for CGI script vulnerabilities. Looking at the evidence forthe false-positive results they seem to interpret any HTTP 200 OK as a success,regardless if the returned page is blank or nonsensical (such as receiving the loginpage instead). The tests for CGI scripts which produced false positives were heavilyreliant on accessing specific URLs, but the server would answer with HTTP 200 OKand blank page even if the URL did not exist. W3af, a program with similar purposeas Nikto and OpenVAS, instead noted that some pages returned blank bodies andflagged these as possible server errors.

5.2 Discussion of Manual AssessmentThe manual assessment was successful in finding injection vulnerabilities by enumer-ating all input-output pairs. From the associated code review it was also apparentthat several problems had been averted through the use of library functionality. In

20

CHAPTER 5. DISCUSSION AND CONCLUSION

addition, discussing security problems with the developers revealed that some prob-lems were already known (such as authentication) but the solutions were outsidethe developers’ influence.

5.2.1 Authentication

The hospitals which use the XDS system combine it with many different softwaresolutions from many different vendors. These together comprise the EHR, alongwith other functionality. In this situation the XDS web application is then a sub-system which is launched to view RIS and PACS information from another EHRsubsystem, perhaps a workflow manager. When these are client/server systems anauthentication problem has arisen at the deployment site due to the servers havingno implemented means of authentication among each other. For each system theuser would then require a manual log in which is something the hospitals want toavoid in order to improve staff efficiency. Thus the users want to manually authen-ticate to only one or a few services and the servers cannot authenticate the usersamong themselves. This forces the servers to blindly trust the clients, leaving suchsystems open to e.g. man-in-the-middle identity spoofing.

As a result the current authentication for users in the XDS system consistssolely of user names as URL parameters to allow vendor interoperability. Thisis recognized to some extent by the client, since the company has been requestedto hide the URL bar in the browser as well as disable key combinations whichaccess it such as CTRL+L. This is no real solution and such a request indicatesa lack of security knowledge at the hospitals. A possible solution to the lack ofauthentication could instead be for hospitals to specify some form of federatedidentity management to the vendors e.g. SAML [58, 59]. This would allow forthe single sign on functionality sought after by the hospitals in a secure manner.However, the relevant hospital staff would first need to know that they ought toask for such functionality. A possible solution to the lack of in-house knowledge forthe hospitals could be to develop some of the EHR systems themselves. Dependingon the size of hospitals this could be done on a regional scale for economic reasons.This would provide the organizations with their own EHR developers whom couldbe counseled when purchasing EHR systems from external vendors.

Finally a note on administrators of the EHR services. For the XDS system thereis cookie based session authentication in place for admins. This could be present inthe other EHR systems as an admin does not require as much interoperability as auser.

5.2.2 InjectionsAll of the injections found were based on incorrectly filtered HTML. The XDSsystem needs to be able to store any data, so it cannot filter input made by the userbefore storing it. Instead, at every point that user input is present on the page, the

21

CHAPTER 5. DISCUSSION AND CONCLUSION

user input must be HTML encoded so as to avoid execution of malicious scripts.This had been done in many places, such as tool-tip boxes, but had been missedin some. There were indeed many places where an injection could easily have beenmissed, but was averted by using Dojo toolkit library functions to build the web-interface rather than writing own javascript. For instance if allowing the user toset the value of a HTML attribute there are subtleties in what needs to be HTMLencoded to avoid injections. Depending on whether the attribute value is enclosedin single quotes, double quotes or no quotes, different HTML characters need tobe encoded. If instead using library functions to create the HTML elements thenthe programmer often need not think about such subtleties or even remember touse a filter, as it is done by the library functions. However, some library functionsstill allowed injections when using innerHTML functionality as this would not becompletely HTML encoded.

5.3 Empirical Results and Previous ResearchIn the reviews [2,3] several security features and potential problems are pointed outbased on mostly theoretical work. Having performed some basic security analysisof an in-use EHR system we can see how those problems relate to the empiricalfindings.

5.3.1 Standards and PoliciesBoth [2,3] note that the literature is extensive regarding HIPAA. This is regulationrelevant in the U.S.A. and not in the Nordic countries relevant for this project.Other important standards mentioned are ISO EN13606 and ISO 27799. The for-mer defines how multiple EHR systems can communicate between themselves andthe latter provides health care specific guidelines for the more general ISO 27002information security standard.

None of these were requested by the hospitals for the XDS EHR system, neitherwere they used by the developers. Instead the important standards were XDS, HL7and DICOM. The latter two standards regard RIS and PACS data format, makingthem important in feeding data to the XDS EHR system. For security to come withstandards compliance the security aspects must then lie in the XDS standard.

The XDS standard states that “The operation of any XDS Affinity Domain willrequire that a proper security model be put in place. It is expected that a rangeof security models should be possible.”. The XDS Affinity Domain is in our casethe hospitals using the XDS system. So the standard states that some securitymodel should exist but that it is outside of the standards scope to specify such amodel. Thus it is fully possible for a hospital to ask for a standards compliant EHRsystem without specifying security concerns, leaving the entire security question inthe hands of the software developers. This is indeed what has happened with theXDS implementation, a somewhat tragic situation where the developers know ofthe serious authentication problems but cannot solve the problem as it requires a

22

CHAPTER 5. DISCUSSION AND CONCLUSION

cooperation of the hospitals different EHR vendors, something the hospitals needto request.

5.3.2 Pseudo anonymity techniquesAnother topic noted as important in [2,3] is pseudonymization [60], a way to enforceprivacy of patient data. Privacy is important for many reasons, both ethical andpractical. In the event of a data leak or misuse of patient information there mightbe severe consequences for an individual. As pointed out by Riedl et.al. [60] “Insur-ance companies or employers could use this information to deny health coverage oremployment. The disclosure of sensitive data, such as the history about substanceabuse or HIV infection, could result in discrimination or harassment.”. At the sametime it is important for a physician to be able to identify a patient for treatment andcounseling reasons, thus ruling out complete anonymization. A solution to this ispseudonymization which only allows health care providers who own a certain secretto identify medical data with a patient, while otherwise keeping the medical datade-identified. Pseudonymization was not present in the XDS EHR.

5.3.3 Encryption of patient dataAnother way to protect the privacy of patients data is to encrypt it [61]. Thisway even if the database is compromised the data would still be safe as long asthe decryption keys are safe. There was no encryption of patient data in the XDSsystem. This had not been requested by the hospital and the developers raisedconcerns that key management at the hospital would not be appreciated and couldpotentially cause problems with everyday operations e.g. losing keys. Thus it wasnot implemented in the XDS.

5.3.4 Data access and role based access controlIt is possible to the let patients influence who gets to view specific information ontheir medical record. This can be handled using Role Based Access Control(RBAC)[62, 63] in which hospital staff is assigned different roles with different privileges.There is also benefit to distinguishing permissions within a role, e.g. two physicianstreating two patients with similar or same names are less likely to mix up thepatients if access to patient data is denied for the incorrect patient. There is noRBAC system in the XDS, instead a system by another vendor is supposed torestrict what the XDS can display to users. However, this other system does notwork and the end result is that all users of the XDS have equal privileges (exceptfor admins who have additional administration rights). While the XDS system ismostly used for viewing data, which mitigates unwanted manipulation of patientdata, having equal privileges for all users does not seem like a good idea.

23

CHAPTER 5. DISCUSSION AND CONCLUSION

5.3.5 Audit trailsAn audit trail is a record of activities which can be used to review and find securityissues such as abuse of permissions or improper disclosure of patients’ health data[64]. Audit trails are done by the XDS according to the IHE’s Audit Trail and NodeAuthentication (ATNA) standard [65]. However, the poor state of authenticationhas some negative impact on the audit trail as it is very easy to spoof an identity.Thus the records can reliably say what has transpired but not by whom.

5.4 ConclusionThe XDS.b version 12 compliant registry, repository and consumer studied in thiswork contained security flaws of varying severity. The poor authentication allowinganyone to authenticate as any user by knowing only the username is very seriousand raises questions regarding the state of security in live EHR systems. The flawsin the authentication depended heavily on interoperability problems due to theEHR solution being built by multiple vendors. There are historic reasons for suchmulti-vendor solutions and thus it is likely that these design flaws are present inmany EHR systems [10]. A possible solution would be for hospitals to demandvendors implement a federated identity management protocol such as SAML fortheir services.

The ethical and practical consequences of not having a working authenticationsolution are severe. Ethically a patient may be concerned about privacy as a right.Practically there are issues such as being denied employment or insurance, but thereis also the risk of identity theft. An impostor might use the stolen identity to receivecare [66]. Such fraudulent care will leave an incorrect medical history with possiblyharmful consequences for the patient. In order to do no such harm, a hospital mustfirst review their data security routines.

When assessing EHR security, free and open source tools have some usage butthere are large limitations. Static analysis for security on library heavy javascriptclients is still a research subject. Dynamic analysis of web applications had troublewith javascript heavy clients, finding none of the (for a human) straightforward in-jections. Nevertheless, dynamic analysis was useful in finding non-javascript relatedproblems, specifically HTTP header configurations.

These findings suggest that there may be several implementation bugs in exist-ing EHR systems but that they can be mitigated using a combination of dynamicanalysis and manual testing. In addition several potential problems were avoided bydeveloping web interfaces using libraries, thus standardizing many web constructssuch as form fields. Indeed all of the injections found were based on a few cases ofnot using library functionality or explicitly forcing the library functions to use inse-cure methods such as the HTML DOM “.innerHTML”. Constructing web interfacesusing libraries is thus a practice which should be encouraged.

24

CHAPTER 5. DISCUSSION AND CONCLUSION

5.5 Future WorkPossible future work includes:

• Empirically investigate EHR security in cooperation with a hospital, insteadof a software vendor.

• Compare efficacy of commercial tools versus free open source tools, relate toeconomic efficiency and economic feasibility for hospitals.

• Empirically investigate more systems used in health care. Are the problemssimilar between many different systems?

• Continue the research on static analysis of javascript for application securitywhen libraries are used.

• Investigate the use of, or the possibility of use of, federated identity manage-ment at hospitals. Of special interest is its use as a single sign on mechanism.

25

References

[1] Tracy D Gunter and Nicolas P Terry. The emergence of national electronichealth record architectures in the united states and australia: Models, costs,and questions. Journal of Medical Internet Research, 2005.

[2] Ajit Appari and M. Eric Johnson. Information security and privacy in health-care: current state of research. International Journal of Internet and EnterpriseManagement, 2010.

[3] José Luis Fernández-Alemán, Inmaculada Carrión Señor, Pedro ÁngelOliver Lozoya, and Ambrosio Toval. Security and privacy in electronic healthrecords: A systematic literature review. Journal of Biomedical Informatics,2013.

[4] Lidong Wang and Cheryl Ann Alexander. Applications of automated identifi-cation technology in ehr/emr. International Journal of Public Health Science,2013.

[5] Morris F. Collen and Don Eugene Detmer. Multi-hospital information systems(mhiss). In Morris F. Collen and Marion J. Ball, editors, The History of MedicalInformatics in the United States, chapter 10. Springer, 2015.

[6] Chun-Ju Hsiao and Esther Hing. Use and characteristics of electronic healthrecord systems among office-based physician practices: United states 2001-2013. Technical report, U.S. Department of Health and Human Services, 2014.

[7] Overview of estonian electronic health record (ehr) system.http://www.e-tervis.ee/index.php/en/news-and-arcticles/432-overview-of-estonian-electronic-health-record-ehr-system.

[8] Mohammad Al-Ubaydli. Personal Health Records: A Guide for Clinicians.Blackwell Publishing, 2011.

[9] Bradley James Erickson, Ronald L. Arenson, and Robert A. Greenes. Imaginginformation systems. In Morris F. Collen and Marion J. Ball, editors, TheHistory of Medical Informatics in the United States, chapter 15. Springer, 2015.

26

REFERENCES

[10] Morris F. Collen and Randolph A. Millerr. The early history of hospital in-formation systems for inpatient care in the united states. In Morris F. Collenand Marion J. Ball, editors, The History of Medical Informatics in the UnitedStates, chapter 6. Springer, 2015.

[11] G Lo Presti, X Espinal Curull, E Cano, B Fiorini, A Ieri, S Murray, S Ponce,and E Sindrilaru. Streamlining castor to manage the lhc data torrent. Journalof Physics: Conference Series, 513(4):042031, 2014.

[12] Oleg S. Pianykh. Digital Imaging and Communications in Medicine (DICOM).Springer, 2012.

[13] IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): IntegrationProfiles. Standard, Integrating the Healthcare Enterprise, April 2016.

[14] Gary McGraw. Software security. IEEE Security & Privacy, 2004.

[15] Common Weakness Enumeration, MITRE Corporation. https://cwe.mitre.org/. Accessed: 2016-05-09.

[16] Common Vulnerabilities and Exposures, MITRE Corporation. https://cve.mitre.org/. Accessed: 2016-05-09.

[17] Open Web Application Security Project. https://www.owasp.org/. Accessed:2016-05-09.

[18] SANS institute. https://www.sans.org/. Accessed: 2016-05-09.

[19] Sugandh Shah and B. M. Mehtre. An overview of vulnerability assessment andpenetration testing techniques. Journal of Computer Virology and HackingTechniques, 2015.

[20] Andrew Austin and Laurie Williams. One technique is not enough: an empiricalcomparison of vulnerability discovery techniques. In International Symposiumon Empirical Software Engineering and Measurement.

[21] Andrew Austin, Casper Holmgreen, and Laurie Williams. A comparison of theefficiency and effectiveness of vulnerability discovery techniques. Informationand Software Technology, 2013.

[22] Pär Emanuelsson and Ulf Nilsson. A comparative study of industrial staticanalysis tools. Electronic Notes in Theoretical Computer Science, 2008.

[23] Chandrapal Chahar, Vishal Singh Chauhan, and Manik Lal Das. Code analysisfor software and system security using open source tools. Information SecurityJournal: A Global Perspective, 2012.

[24] Michael Gregg. The Network Security Test Lab: A Step-by-Step Guide. JohnWiley & Sons, Inc., 2015.

27

REFERENCES

[25] OWASP vulnerability scanning tools. https://www.owasp.org/index.php/Category:Vulnerability_Scanning_Tools. Accessed: 2016-06-22.

[26] NIST SAMATE list of Source Code Security Analyzers. https://samate.nist.gov/index.php/Source_Code_Security_Analyzers.html. Accessed:2016-05-10.

[27] Magnus Madsen, Benjamin Livshits, and Michael Fanning. Practical staticanalysis of javascript applications in the presence of frameworks and libraries.In Proceedings of the 2013 9th Joint Meeting on Foundations of Software En-gineering.

[28] Esben Andreasen and Anders Møller. Determinacy in static analysis for jquery.In Proceedings of the 2014 ACM International Conference on Object OrientedProgramming Systems Languages & Applications.

[29] OWASP Top 10. https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project. Accessed: 2016-07-13.

[30] Meucci et al. Owasp testing guide v4. Technical report, OWASP, 2014.

[31] Docker. https://www.docker.com/. Accessed: 2016-08-15.

[32] Linux Mint. https://www.linuxmint.com/. Accessed: 2016-08-15.

[33] Kali Linux. https://www.kali.org/. Accessed: 2016-08-15.

[34] VirtualBox. https://www.virtualbox.org/. Accessed: 2016-08-15.

[35] Metasploitable 2. https://sourceforge.net/projects/metasploitable/files/Metasploitable2/. Accessed: 2016-08-15.

[36] OWASP Mutillidae 2 Project. https://www.owasp.org/index.php/OWASP_Mutillidae_2_Project. Accessed: 2016-08-15.

[37] Elasticsearch. https://www.elastic.co/products/elasticsearch. Ac-cessed: 2016-08-16.

[38] Apache Cassandra. http://cassandra.apache.org/. Accessed: 2016-08-16.

[39] Andreas Broström. Integrating Automated Security Testing in the Agile De-velopment Process. Master’s thesis, KTH Royal Institute of Technology, Stock-holm, Sweden, 2015.

[40] Nmap. https://nmap.org/. Accessed: 2016-08-15.

[41] SSLScan. https://sourceforge.net/projects/sslscan/. Accessed: 2016-08-15.

28

REFERENCES

[42] OWASP Xenotix XSS Exploit Framework. https://www.owasp.org/index.php/OWASP_Xenotix_XSS_Exploit_Framework. Accessed: 2016-08-15.

[43] Dojo Toolkit. https://dojotoolkit.org/. Accessed: 2016-07-11.

[44] RFC 3875 - The Common Gateway Interface (CGI) Version 1.1. https://tools.ietf.org/html/rfc3875. Accessed: 2016-08-15.

[45] CVE Reference Map for Source OSVDB. http://cve.mitre.org/data/refs/refmap/source-OSVDB.html. Accessed: 2016-08-15.

[46] Eduardo Vela Nava and David Lindsay. Abusing Internet Explorer 8’s XSSFilters. http://p42.us/ie8xss/Abusing_IE8s_XSS_Filters.pdf. Accessed:2016-08-16.

[47] Microsoft Security Bulletin MS10-002. https://technet.microsoft.com/library/security/ms10-002. Accessed: 2016-08-16.

[48] CVE-2009-4074 IE8 XSS Filter vulnerability. http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-4074. Accessed: 2016-08-16.

[49] Microsoft Security Bulletin MS10-018. https://technet.microsoft.com/library/security/ms10-018.aspx. Accessed: 2016-08-16.

[50] RFC 7034 - HTTP Header Field X-Frame-Options. https://tools.ietf.org/html/rfc7034. Accessed: 2016-07-18.

[51] Gustav Rydstedt, Elie Bursztein, Dan Boneh, and Collin Jackson. Bustingframe busting: a study of clickjacking vulnerabilities at popular sites. In inIEEE Oakland Web 2.0 Security and Privacy (W2SP 2010), 2010.

[52] RFC 6797 - HTTP Strict Transport Security (HSTS). https://tools.ietf.org/html/rfc6797. Accessed: 2016-07-18.

[53] Adam Barth, Juan Caballero, and Dawn Song. Secure content sniffing for webbrowsers, or how to stop papers from reviewing themselves. In Proceedingsof the 2009 30th IEEE Symposium on Security and Privacy, pages 360–371,Washington, DC, USA, 2009. IEEE Computer Society.

[54] RFC 2045 - Multipurpose Internet Mail Extensions (MIME) Part One: For-mat of Internet Message Bodies. https://www.ietf.org/rfc/rfc2045.txt.Accessed: 2016-07-19.

[55] Cross-Origin Resource Sharing. https://www.w3.org/TR/cors/. Accessed:2016-07-19.

[56] Shreeraj Shah. Html5 top 10 threats stealth attacks and silent exploits. Black-Hat Europe, 2012.

29

REFERENCES

[57] RFC 7234 - Hypertext Transfer Protocol (HTTP/1.1): Caching. https://tools.ietf.org/html/rfc7234. Accessed: 2016-07-19.

[58] OASIS Security Services Technical Committee. Saml 2.0 technical overview.Technical report, OASIS, 2008.

[59] A. A. Malik, H. Anwar, and M. A. Shibli. Federated identity management(FIM): Challenges and opportunities. In 2015 Conference on Information As-surance and Cyber Security (CIACS), pages 75–82, Dec 2015.

[60] Thomas Neubauer and Johannes Heurix. A methodology for the pseudonymiza-tion of medical data. International Journal of Medical Informatics, 80(3):190– 204, 2011.

[61] D. Daglish and N. Archer. Electronic personal health record systems: A briefreview of privacy, security, and architectural issues. In Privacy, Security, Trustand the Management of e-Business, 2009. CONGRESS ’09. World Congresson, pages 110–120, Aug 2009.

[62] Longhua Zhang, Gail-Joon Ahn, and Bei-Tseng Chu. A role-based delegationframework for healthcare information systems. In Proceedings of the SeventhACM Symposium on Access Control Models and Technologies, SACMAT ’02,pages 125–134, New York, NY, USA, 2002. ACM.

[63] Bernd Blobel. Authorisation and access control for electronic health recordsystems. International Journal of Medical Informatics, 73(3):251 – 257, 2004.Realizing Security into the Electronic Health Record.

[64] J. Sun and Y. Fang. Cross-domain data sharing in distributed electronichealth record systems. IEEE Transactions on Parallel and Distributed Sys-tems, 21(6):754–764, June 2010.

[65] IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): IntegrationProfiles. Standard, Integrating the Healthcare Enterprise, April 2016.

[66] J. Kwon and M. E. Johnson. Protecting patient data-the economic perspectiveof healthcare security. IEEE Security Privacy, 13(5):90–95, Sept 2015.

30

www.kth.se