Fluent Essays

A new medium-sized health care facility just opened, and you are hired as the CIO, the CEO is somewhat technical and has tasked you with creating a threat model. The CEO needs to decide from 3 selected models but needs your recommendation as well to make sound decisions. The concern is user authentication and credentials with third-party applications which is common in the health care industry. You will research several threat models as it applies to the health care industry, summarize three models and choose one as a recommendation to the CEO in a summary with a model using UML Diagrams (Do not copy and paste images from the Internet). In your document be sure to discuss the security risks and assign a label of low, medium or high risks and the CEO will make the determination to accept the risks or mitigate them).The CEO has provided the attached article as a reference.Task:Explain why the other threat models are not ideal (compare and contrast)Provide one recommendation with summary and UML diagramMust be in full APA3-page minimum not including the title page, abstract and references. threat_modeling_mobile6.pdf Unformatted Attachment Preview See discussions, stats, and author profiles for this publication at: https://www.researchgate.net/publication/323167742 Threat Modeling for Mobile Health Systems Conference Paper · April 2018 DOI: 10.1109/WCNCW.2018.8369033 CITATIONS READS 3 477 4 authors: Matteo Große-Kampmann geb. Cagnazzo Norbert Pohlmann Westfälische Hochschule Westphalia University of Applied Sciences, Gelsenkirchen 16 PUBLICATIONS 14 CITATIONS 113 PUBLICATIONS 386 CITATIONS SEE PROFILE SEE PROFILE Markus Hertlein Thorsten Holz XignSys GmbH Ruhr-Universität Bochum 7 PUBLICATIONS 15 CITATIONS 198 PUBLICATIONS 7,399 CITATIONS SEE PROFILE Some of the authors of this publication are also working on these related projects: Botnet Detection View project Medical Security View project All content following this page was uploaded by Matteo Große-Kampmann geb. Cagnazzo on 03 July 2018. The user has requested enhancement of the downloaded file. SEE PROFILE Threat Modeling for Mobile Health Systems Matteo Cagnazzo1 and Markus Hertlein3 and Thorsten Holz2 and Norbert Pohlmann1 Abstract— Mobile Health (mHealth) is on the rise and it is likely to reduce costs and improve the quality of healthcare. It tightly intersects with the Internet of Things (IoT) and comes with special challenges in terms of interoperability and security. This paper focuses on security challenges and offers a mitigation solution especially with a focus on authentication and encryption for resource constrained devices. It identifies assets in a prototyped mHealth ecosystem and classifies threats with the STRIDE methodology. Furthermore the paper identifies associated risk levels using DREAD and outlines possible mitigation strategies to provide a reasonable trustworthy environment. I. INTRODUCTION Advances in mobile health (mHealth), respectively IoTHealth, are likely to reduce costs and improve the quality of healthcare. Especially with the paradigm shift from inpatient care towards ambulant and home care, mobile and ubiquitous technologies are an inevitable step. The shift is due to increasing cost pressure, ageing society and shortage of skilled professionals[24]. Mobile health applications can increase access to healthcare, encourage self-management and maintain treatment. Internet of Things (IoT) devices are used within healthcare systems and form mHealth environments. Wearables with various sensors, for example gyroscopic-, heart rate- or bioimpedance sensors are often deployed in the Body Area Network (BAN) of the patient. These devices come with a lot of challenges in terms of interoperability and security which need to be considered and treated seriously [23]. ENISA identifies ”asset and configuration management as a relevant technical measure” to prevent attacks [7]. Furthermore, this paper addresses a key recommendation from [7] because it conducts risk and vulnerability assessment for a mHealth architecture which is deployed in a clinical context. This paper discusses most recent related work in chapter II. Afterwards it introduces current developments and background knowledge for mHealth in chapter III-A and threat modeling in chapter III-B. After this we model the threats and define assets in chapter IV. We use a STRIDEbased approach to model threats[22]. To assess the associated risks for specific threats we use the DREAD model [25]. At the end of the paper possible mitigation strategies are discussed in chapter V and conclusions are drawn in chapter VI. *This work is partly funded by the Federal Ministry of Education and Research in Germany (Grant.Nr: 16SV7775) 1 M. Cagnazzo and N. Pohlmann are with the Institute for InternetSecurity, Westphalian University of Applied Sciences, 45876 Gelsenkirchen, Germany {lastname} at internet-sicherheit.net 2 T. Holz is with the Horst Gortz Institute for IT-Security (HGI), RuhrUniversity Bochum, Germany thorsten.holz at rub.de 3 M. Hertlein is with XignSys GmbH, Gelsenkirchen, Germany hertlein at xignsys.de II. RELATED WORK Several papers on future research direction indicate that privacy and security are key issues to the successful deployment of mHealth[16][3]. [16] defines one research challenge as: ”clarify threats and develop security and privacy protections for smartphone apps that handle medical and health data”. This paper aims to give an overview of threats and mitigation strategies for current and future mHealth applications. Current work on threat modeling in healthcare is focusing on telehealth and is not paying attention to mHealth specific threats, especially if data is stored in a cloud environment[1]. Works like [19] are defining and mitigating threats for smart home systems and consider parenthetically how mHealth systems and threats interact with it. [5],[21] and others try to solve the authentication, usability and confidentiality problem within the IoT in general. They do not use standardized approaches to identify threats and mitigate them as well. Stationary care telehealth service terminals, as described in [8] and [20] are likely reduce mobile application scenarios for doctors and medical personnel. This stationary approach is something a mHealth ecosystem is aiming to overcome in the future, to empower mobility to doctors and other caregivers. Common legacy protocols used in medical environments often lack security and privacy aspects. [11] shows that the often used ”HL7” protocol has no security or privacy mechanisms specified especially in version two, which is the most deployed solution in production systems. Figure 1 shows a prototypical mHealth system. It is derived from an architecture which is used in the MITASSIST project. The project is funded by the German Federal Ministry of Education and Research. Figure 2 shows a more detailed view of the components, which data has to pass in the architecture. The wearable on which the sensors are deployed will produce huge amounts of data. Analyzing big amounts of data quickly becomes impracticable for humans, therefore an artificial intelligence(AI) is trained during the research project. Current research shows, that the used models can be exploited by an attacker as well, therefore we include the artificial intelligence into our threat model[9][17]. III. BACKGROUND This section will give a brief definition and introduction of mHealth as well as an architectural overview of an mHealth system. Furthermore threat modeling and the used methodology is introduced. B. Threat Modeling A. mHealth mHealth is the combination of computing and internet technologies, with information and communication systems. In addition with sensors it can form a wearable body area network (BAN) with the patients smartphone[15]. Patients as well as health- and careproviders can benefit from mHealth solutions. mHealth applications that run on information systems like smartphones are used by patients and doctors to access data within the health platform as shown in figure 1. Doctors, caretakers and patients access the platform via an application which can either be deployed to a mobile or stationary device. The patient environment consists of devices and applications in personal patient environment, like wearables and smartphones. These are needed to collect measurements of sensor data, support self reporting as well as feedback or intervention from the caretaker. Most sensors that are deployed are also modules in the IoT, therefore mHealth and IoT components intersect each other. The patients send data via mobile or WLAN networks to the health service cloud. The data is stored in an electronic or personal health record systems(EHR/PHR) which is integrated in the hospital cloud service. The most used protocol is HL7[11]. The data can be crawled by monitoring services or an artificial intelligence, which support the doctor in his decision making, offer more granular insights for patient and doctor, as well as providing suggestions how the patient can improve his health. Other health and care providers could get access to the data as well. This yields privacy concerns which are out of scope of our paper, therefore we neglect third party scenarios. Patients benefit from mHealth applications around the world, since the deployment of mHealth applications can be done in a cost effective way. Especially developing countries can benefit from the widespread deployment of mHealth solutions[10]. ”Respectively, 50 \% and 70 \% of the interventions were effective in promoting physical activity and healthy diets” says[18]. Threat modeling is an important aspect of the security development lifecycle, which is a process aiming to build better and more secure software[13]. It is a technique, which aims to find assets, analyze potential threats and mitigate them. This provides defenders with important insights: • The most likely attack vectors • Assets an attacker is attracted to. • Attack vectors that otherwise would have gone unnoticed The threats which are found during the threat modeling phase will be associated with a security risk to rank them and prioritize certain assets. An asset is defined by ENISA as ”anything that has value to the organization, its business operations and their continuity, including information resources that support the organization’s mission”. TABLE I C ONNECTION BETWEEN STRIDE AND M H EALTH ENVIRONMENT Threat Categories mHealth Security Perspective Spoofing: attacker poses as an authorized user or entity Attacker using user authentication information to access sensitive medical data Tampering: Modifying data maliciously Attacker modifying data in transit (e.g. from BAN to LAN) or at rest Repudiation: Filtering malicious actions if proof is missing Authorized user performs illegal operations and system cannot trace it, other parties cannot prove this Information disclosure: Exposing information to any unauthorized entity Leaking raw data or medical records Denial of Service: Denying service to valid users Attacker jamming BAN or DoS’ing hospital environment Elevation of Privilege: User gains privilege rights and manipulates the system Attacker gains access to security systems as a trusted entity The threat modeling technique used in this paper is STRIDE by Microsoft which is an abbreviation for Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service and Elevation of Privilege [22]. There are more threat modeling frameworks, for example PASTA or OCTAVE [2][25]. To rank threats we use the DREAD model, which is described in the next section. Fig. 1. mHealth Prototype Architecture Table I defines each threat category and relates it to a specific mHealth attack scenario. After the STRIDE threats are addressed, a metric for the risk of an actual attack needs to be calculated. We will use the DREAD model to evaluate the likelihood of an attack by exploiting a particular threat[14]. The DREAD model consists of Damage potential, TABLE II A SSETS AND I MPACT Reproducibility, Exploitability, Affected Users and Discoverability. The DREAD risk can be calculated as follows: RiskD = (DAM AGE + REP RODU CIBILIT Y + EXP LOIT ABILIT Y + AF F ECT EDU SERS + DISCOV ERABILIT Y ) (1) Values from 1 (low) to 3 (high) are assigned to each addend of equation 1. The sum is calculated and the result can fall in the range of 5-15. Afterwards one can rank threats with overall ratings of 12-15 as high risk, 8-11 as medium risk, and 5-7 as low risk. IV. STRIDE THREATS The process of threat modeling according to STRIDE can be broken down into three blocks: • Identifying assets • Listing potential threats • Mitigating threats To define threats and get a more detailed overview of our architecture, a graphical representation of the data flows and critical points are illustrated with Microsofts Threat Modeling Tool 2017 in figure 2. Data is acquired Asset Impact Network components connecting the user to the service No Availability Loss of information Network components connecting the sensor to the Application No Availability Loss of information Identity management for access control and authentication User specific information cannot be stored or retrieved Database and Storage Components Loss of Availability Loss of Data Integrity Loss of feedback Eavesdropping on Communication Confidentiality Violation Table II shows identified assets and the impact, which a failure of the respective asset would have. Loss of Availability is the most common impact the alteration of an asset could have. Since the mHealth solution should provide close to realtime feedback or intervention to the patient, a loss of availability could be harmful for patient safety not just for security reasons. Depending on the health or monitoring scenario in which the solution is used, close to realtime can range from a few seconds (cardiac monitoring) to 15 minutes (depression monitoring). Other important impacts are confidentiality violation and loss of information. Since the data is considered medical it is highly personal and must be protected carefully. The mHealth platform should be trustworthy, therefore it should provide and maintain confidentiality wherever possible. Fig. 2. Data Flow and critical points from one or more sensors on a wearable and pushed to a central sensor controller. The data is collected and persisted. After a configurable time-interval the data is pushed to the application over a Bluetooth LE connection. The application can send configuration data to the sensor controller and acknowledges received and stored sensor data. Configuration data could be, for example the sampling rate of a specific sensor. The patient authenticates himself and gets access to the application. Sensor data is transmitted from the device to the service platform over a https connection. This data gets acknowledged, after it is stored successfully. If medical personnel wants to check on a patients condition it authenticates itself on its application and sees selected vital data of the patient. If the medical supervisor wants to send interventions to the patients, these are sent to the patient over the cloud infrastructure and gets an acknowledgement after the patient read the intervention. From the flow of data over the respective components a threat model is generated. Table III shows threats towards patient or personnel authentication. It focuses on the loss and misuse of credentials, as well as spoofing of sensors. Generally threats are more severe, if an admin or health personnel is compromised because this would alter the whole integrity of the platform whilst an attack against a single user would only put that specific user at risk. If an attacker or user gains unauthorized access to the platform the threats are elevation of privilege, data tampering and disclosure. Table IV shows this in the STRIDE column. A user could try to elevate his privileges and gain admin access to the service component or the PHR. This elevation could lead to disclosure of private data from other users. The associated risks by an authorization threat are at least medium but most of the times high, because gaining administrator or system privileges, even if they are only local, can cause damage to patients as well as healthcare providers. Furthermore spoofed sensors or smartphones can be used to flood the architecture with requests, forcing a denial of service TABLE III AUTHENTICATION T HREATS information from a PHR is exposed. Description STRIDE DREAD Patient identity sharing or loss S Medium TABLE V P RIVACY T HREATS Description STRIDE DREAD Patient Data Disclosure I High Low Administration Data Disclosure I High E Medium Lost Smartphone I Medium Lost Wearable I Low Sysadmin Identity Theft S High Stolen Smartphone I Medium Sensor Spoofing S,D Medium Stolen Sensor I Low Smartphone Spoofing S,D Medium EHR/PHR Spoofing S High Weak access control smartphone I Medium Weak access control wearable I Low Personnel identity sharing or loss S High Identity spoofing S Patient and Personnel Identity Theft because the service or smartphone cannot respond. Privacy is of huge importance for patients, especially if TABLE IV AUTHORIZATION AND ACCESS T HREATS Description STRIDE DREAD Unauthorized Access to system data E High Unauthorized Access beyond authorized privileges E Medium Tampering to modify access control T Medium Impersonation of a Patient E,D Medium Impersonation of Personnel E,D High Unauthorized access to admin functionality E,T High they suffer from a mental disease. A disclosure of their illness can either be beneficial or hinder the healing process but for most patients it is a dilemma whether they should disclose or conceal it[4]. Nonetheless individuals suffering from any illness should choose for themselves, if they want to disclose their illness, therefore patient data disclosure by an adversary should be prevented at all costs. Lost or stolen devices, especially lost wearables only pose a low risk to private data disclosure, because an attacker cannot read sensitive data from it. Only the last few sensor measurements are stored on the wearable, therefore the information gain is minor. If the smartphone is lost or stolen the information leakage is bigger, but no The last threat category are threats that target artificial intelligences. Table VI shows that these threats are at least of medium importance since an altering of the AI would alter the integrity of the whole platform. Someone could try to change the training data which would mean that every decision the AI does is made from false assumptions, therefore this is the main threat and has a high risk, for now. A non targeted adversarial attack has the goal of forcing the classifier to return an incorrect result. If for example heart rate is monitored an attacker could try to make the classifier return the result cardiac disease, even though the patient is healthy. A targeted attack would try to yield a whole class of the AI and make it return this class regardless of the input. A targeted attack could be that every patient where the data looks like a cardiac arrhythmia will be diagnosed with an infarction. Both attacks imply, that an attacker has successfully gained access to the smartphone or is an active adversary in the same network, because he needs to manipulate the data sent to the mHealth service. TABLE VI A DVERSARY T HREATS Description STRIDE DREAD Potential altering of training data T High Non-targeted adversarial attack T Medium Targeted adversarial attack T Medium V. POSSIBLE MITIGATION STRATEGIES The assets can be grouped by the different kinds of the underlying technologies and processes. This leads to different mitigation strategies for each scenario. Even though security and privacy are the main factors in the healthcare environment to focus on, the interoperability between systems and devices is gaining more and more importance, since sensors and smart devices are spreading faster. Therefore, this paper presents a holistic approach as the mitigation strategy covering all parts of the mHealth system. A distributed system like the presented prototypical mHealth system (Fig. 1) can be harmed by two independent classes of attacks. The first class is physical attacks, for example the physical destruction of a sensor or the disturbing of the interconnection of the sensors, smart devices and cloud services. That kind of attacks cannot be prevented with IT-Security mechanisms. The second threat class is virtual attacks, like data manipulation. We are only focusing on attacks of the second class. In reverse that means, that Denial of Services through connection jamming or physical destruction is not part of this research. A Denial of Service could also be achieved if an attacker is able to conquer a connection, for example through connection hijacking. That kind of DoS is p ... Purchase answer to see full attachment