Mahajan 1

A Risk Based Feasibility Study

Submission by: Consolidated

Instructor: Professor

Course: Information Security

Submission Date: April 14, 2019

Internal
 Mahajan 2

TABLE OF CONTENTS

Section Topic Page

1 Executive Summary 3

2 Background and Scope 4

3 Risk Based Approach 6

4 Recommendations 11

5 Conclusion 16

6 References 18

Internal
 Mahajan 3

1. EXECUTIVE SUMMARY

PPM Healthcare is evaluating a plan to setup an online collaboration website that will

share sensitive patient information with other healthcare providers, insurance

companies and patients. This collaboration is expected to dramatically streamline

communication between different parties involved. As collaboration network partners'

views of patient profiles become well-rounded, the health care experience is also

expected to become more personalized.

Scope of this report

This report evaluates the proposal from a lens of IT and Information Security for the

website and the added risk of collaborating with other partners. This report focuses on

identifying, evaluating and measuring risks related to this collaboration project.

Approach

This study adopts a 2-stage approach. Inherent IT and Information Security risks and

existing control measures are considered in consultation with stakeholders. These risks

are evaluated based on their likelihood and significance.

Conclusion

Based on control measures and other recommendations being made in this study, the

report concludes that residual risks residual risks for this project will be within

acceptable levels and the project can be approved on the condition that the the

additional control measures and recommendations will be adopted and tested prior to

go-live.

Internal
 Mahajan 4

2. BACKGROUND AND SCOPE

PPM Healthcare utilizes digital patient data management system for storage, access

and use of patient data within the organization. Electronic Health Records (EHR) that

have to be made accessible to other medical care practitioners in network hospitals,

insurance providers, physician’s offices, diagnosticians, pharmacists and other medical

specialists are shared via different methods:

• Email

• Upload to partner websites, where available

• File Transfer Protocols (FTP) sharing

There is inconsistency in methods used to share patient EHR and current methods of

sharing sensitive patient information have been deemed to be both, insecure and

unreliable. Inability to quickly access an aggregated view of health care information on a

patient’s previous and current episodes of care has the potential to hinder diagnosis,

prompt unnecessary repeat of tests, jeopardize safety, and generally increase the cost

of health care delivery.

To ensure best care to our patients, PPM is planning to setup an online collaboration

website that will enable sharing of patient EHRs with our partners in the healthcare

industry. Scope of this report is to:

1. identify risks for the planned project,

2. qualify them based on their likelihood & impact; and

3. make recommendations to address identified risks.

Internal
 Mahajan 5

Like any IT project, risk assessment is an essential part of the planning process; with

sensitive patient data being involved however, significance of risk assessment is

magnified manifold. In addition to ensuring Availability and Integrity, Confidentiality of

sensitive patient data is mandated by US, Canadian and European regulations, namely:

- Health Insurance Portability and Accountability Act (HIPAA), a US

federal law that lays out standards and guidelines to guard patient privacy

and ensure sensitive patient information is adequately protected.

- Personal Information Protection and Electronic Documents Act

(PIPEDA) of Canada, which specifies the rules to govern collection, use, or

disclosure of the personal information recognizing the right of privacy of

individuals with respect to their personal information.

- General Data Protection Regulation (GDPR), a legal framework that sets

guidelines for collection and processing of personal information of European

Union citizens.

This report focuses on the importance of implementing safeguards for managing and

protecting sensitive patient information as an added layer of risk management in

addition to other IT risks.

Internal
 Mahajan 6

3. RISK BASED APPROACH

Risk Assessment for this project was conducted based on the approach outlined in

Figure 1 following three-step approach2:

Figure 1: Risk Assessment Stages

3.1 Risk Identification

3.1.1 Stakeholder Identification and Engagement: Stakeholders for this assessment were

identified as:

- IT Operations,

- Security Operations,

- BCM team; and

- Business units based on their role in collection, storage, usage, sharing and

ownership of patient data.

Stakeholder Engagement in planning, implementation and governance of the project is a

critical step as it ensures that their perspective is included, risk & control ownership is

defined and stakeholder buy-in is achieved.

3.1.2 Identification of Risks: A series of group discussions, brainstorming sessions and

interviews were conducted to identify risks related to data collaboration project. These

Internal
 Mahajan 7

risks have been documented in Risk Register to be addressed and governed as part of

the project lifecycle.

3.2 Risk Estimation

3.2.1 The following table provides a summary view of risks that were identified and assessed

based on existing controls in place, residual risk, likelihood of occurrence and criticality

of impact as outlined in the Table 1 below:

Risk ID Inherent Risk Existing Controls Control Gaps Likelihood Significance

Secure database Collaboration partners

Hacking of
R001 protocols, 2-factor security could be Frequent Catastrophic
customer PI
authentication at PPM compromised

IP Blacklist service, New collaboration website

R002 DDoS attack High bandwidth could be targeted by DDoS Frequent Catastrophic
provision attack

Weak patching & version

Ransomware Antivirus services upgrade process, Access Reasonably
R003 Catastrophic
attack subscription via public WIFI could Frequent
endanger login credentials

Privacy information Partners can monetize data

Unauthorized Very
R004 trainings, Strong data shared with them without Catastrophic
usage of PI Frequent
handling processes patient consent

API API with existing EHR

Low residual risk as no
R005 vulnerabilities management system Rare Catastrophic
partner APIs involved
exploit verified for protection

Criminal background Partners with weak

Malicious checks, Efficient background checks and
R006 Occasional Major
insiders employee termination employee termination and
process access removal process
Partner devices with no
2-factor MFA pose a risk if
Stolen or lost Reasonably
R007 authentication, No credentials are Moderate
devices Frequent
single sign-on compromised and SSO is
enabled

Table 1: Inherent Risks Assessment

3.3 Risk Evaluation

As noted earlier in the report, there are various regulatory requirements that need to be met

when handling patient personal information in the form of EHRs, most notably HIPAA, PIPEDA

and GDPR. In addition to the regulatory requirements, "Availability" of data is also of critical

Internal
 Mahajan 8

importance to this project, as a delay in access or unavailability of patient health records can

have serious consequences and endanger safety of our patients. Risks identified in Table 1

have a Catastrophic, High or Moderate impact as each of those risks is tied to either regulatory

compliance or availability of patient PI.

In healthcare, security can be a patient safety issue and should be treated as an enterprise-wide

risk management issue, rather than just an IT issue. Health care data is one of the rare types of

personal data that one cannot change and has value that may increase over time. This

difference in value is reflected in the price for medical records (vs. credit card or other financial

data) available for sale on the dark web. As such, there are serious consequences and

significant penalties imposed by regulators for noncompliance or exposure of patient PI. Some

instances of data exposure/breach and regulator response are noted here to emphasize this

point:

3.3.1 Case Study 1: Cyber Attack by nation state3

In March 2017, Health Insurance Company Anthem Inc. agreed to a proposed $115 million deal

to settle a class action lawsuit over a 2015 cyberattack that resulted in a breach affecting nearly

78.9 million individuals. In February 2015, Anthem had announced that it had been the target of

a cyberattack suspected to be orchestrated by an un-named nation state in which personal

information of 78.8 million individuals was stolen, including, for many of those individuals:

names, dates of birth, Social Security numbers and healthcare identity numbers. In addition to

the settlement, Anthem Inc. has spent over $260 million in hiring security consultants and

implementing security related improvements after the breach. Total cost of breach to Anthem

Inc- approximately $375 million.

Internal
 Mahajan 9

3.3.2 Case Study 2: Data leak due to weak access controls4

In March 2017, the Department of Health and Human Services’ (HHS) Office of Civil Rights

(OCR) announced a settlement with St. Elizabeth's Medical Center in Boston, with the hospital

agreeing to pay penalties totaling $218,000 stemming from a November 2012 complaint.

According to a settlement statement released by HHS, OCR received a complaint alleging

noncompliance with the HIPAA Rules by Saint Elizabeth’s staff, who were using what was

described as an “Internet-based document sharing application” to store documents containing

electronic protected health information (“ePHI”) corresponding to 498 individuals. Subsequently,

Saint Elizabeth’s notified HHS of a leak of unsecured ePHI affecting an additional 595

individuals. That data was stored on a former Saint Elizabeth’s employee’s personal laptop and

USB flash drive.

In its ruling, HHS’s Office of Civil Rights found that Saint Elizabeth’s failed to “implement

sufficient security measures regarding the transmission of and storage of ePHI to reduce risks

and vulnerabilities to a reasonable and appropriate level.” Just as important, the medical center

didn’t “identify and respond to a known security incident” or take steps to mitigate the harmful

effects of the security incident and document the security incident and its outcome.

3.3.3 Case Study 3: Accidental exposure of PHI5

In 2017, New York-Presbyterian Hospital (NYP) paid penalties and fines totaling $4.8M after

Health and Human Services’ (HHS) Office investigation concluded:

- NYP impermissibly disclosed the ePHI of 6,800 patients to Google and other Internet

search engines in 2010 when a computer server that had access to NYP ePHI

information systems was errantly reconfigured.

- NYP failed to conduct an accurate and thorough risk analysis that incorporates all IT

equipment, applications, and data systems utilizing ePHI.

Internal
 Mahajan 10

- NYP failed to implement processes for assessing and monitoring all IT equipment,

applications, and data systems that were linked to NYP patient data bases prior to

the breach incident and failed to implement security measures sufficient to reduce

the risks and vulnerabilities to its ePHI to a reasonable and appropriate level.

- NYP failed to implement appropriate policies and procedures for authorizing access

to its NYP patient data bases, and it failed to comply with its own policies on

information access management.

Nearly 90% of healthcare organizations have suffered from a breach6. Given the

interconnectedness of our healthcare organizations, small entities pose a significant security

risk for larger organizations. As small organizations are compromised by malware, ransomware,

or other digital threats, larger organizations can be laterally compromised. The above examples

highlight the high cost of non-compliance and exposure of sensitive patient health information.

These financial losses are in addition to other damaging impacts to the organization, like:

- Loss of reputation and patient trust

- Negative impact to stock value

- Increased regulatory scrutiny

- Threat to patient health

- Impact to employee morale; amongst others.

PPM executives need to be aware of the likelihood and significance of these risks materializing

as the organization ventures into a collaboration model for sharing sensitive patient information

with our health care provider partners.

Internal
 Mahajan 11

4. RECOMMENDATIONS

This section provides recommendations to mitigate risks outlined in Section 3.2 and documents

residual risks, executives and risk owners need to be aware of to manage them effectively.

4.1 Recommended Controls

4.1.1

Risk ID Inherent Risk Existing Controls Control Gaps Likelihood Significance

Secure database Collaboration partners

Hacking of
R001 protocols, 2-factor security could be Frequent Catastrophic
customer PI
authentication at PPM compromised

Control Measures to mitigate R001

- CR001C1: Require 2-factor authentication for website access for partner website

access. 2-factor authentication adds another security layer to the login process,

reducing the chances of account hacking.

- CR001C2: Implement "Pull" mechanism of data sharing instead of "Push"

mechanism, where only the data requested by the partner using unique customer

identification is transferred. The external-facing web servers, resources and services

should be in the DMZ, so they are accessible via the internet, but the rest of the

internal LAN remains unreachable.

Internal
 Mahajan 12

4.1.2

Risk ID Inherent Risk Existing Controls Control Gaps Likelihood Significance

IP Blacklist service, New collaboration website

R002 DDoS attack High bandwidth could be targeted by DDoS Frequent Catastrophic
provision attack

Control Measures to mitigate R002

- CR002C1: Subscribe to DDoS mitigation services like Akamai, that works by

deflecting DDoS traffic in one of the outer layers – the network layer and helps

absorb any potential application layer DDoS traffic at the network edge.

4.1.3

Risk ID Inherent Risk Existing Controls Control Gaps Likelihood Significance

Weak patching & version
Ransomware Antivirus services upgrade process, Access Reasonably
R003 Catastrophic
attack subscription via public WIFI could Frequent
endanger login credentials

Control Measures to mitigate R003

- CR003C1: Implement robust patch management processes based on a patch

management policy that is integrated with IT security policy. Patch management

should be automated as far as possible and there should be a demarcated team

responsible for patch and vulnerability management.

- CR003C2: Encrypting PII at rest and in transit needs to be non-negotiable

component of PII protection for this project. Implement strong encryption and key

management protocols.

Internal
 Mahajan 13

4.1.4

Risk ID Inherent Risk Existing Controls Control Gaps Likelihood Significance

Privacy information Partners can monetize data

Unauthorized Very
R004 trainings, Strong data shared with them without Catastrophic
usage of PI Frequent
handling processes patient consent

Control Measures to mitigate R004

- CR004C1: Develop and agree framework with all partners involved in data

collaboration that clearly outlines "Acceptable Use" of PII in accordance with HIPAA,

PIPEDA and GDPR guidelines. Ensure that all partners have signed off on and are

committed to Acceptable Use policy. The policy should outline legal liability in case of

partner misuse of patient PII.

4.1.5

Risk ID Inherent Risk Existing Controls Control Gaps Likelihood Significance

API API with existing EHR

Low residual risk as no
R005 vulnerabilities management system Rare Catastrophic
partner APIs involved
exploit verified for protection

Control Measures to mitigate R005

- CR005C1: Control access to API via the least privilege principle. Implement

authentication and authorization mechanisms such as OAuth/OpenID Connect, in

conjunction with Transport Layer Security (TLS).

Internal
 Mahajan 14

4.1.6

Risk ID Inherent Risk Existing Controls Control Gaps Likelihood Significance

Criminal background Partners with weak
Malicious checks, Efficient background checks and
R006 Occasional Major
insiders employee termination employee termination and
process access removal process

Control Measures to mitigate R006

- CR006C1: Require background check verification by partners before granting

credentials to partner employees.

- CR006C2: Require partners to have a documented employee termination process

where access credentials to website is revoked as soon as an employee termination

is processed.

- CR006C3: Implement automatic revocation of access for any credentials not used for

more than 15 days. This control should be accompanied by an automated process

which an employee can use to re-enable access by answering security questions.

4.1.7

Risk ID Inherent Risk Existing Controls Control Gaps Likelihood Significance

Partner devices with no
2-factor MFA pose a risk if
Stolen or lost Reasonably
R007 authentication, No credentials are Moderate
devices Frequent
single sign-on compromised and SSO is
enabled

Control Measures to mitigate R007

- CR007C1: Require 2-factor authentication per CR001C1. No Single Sign-On (SSO)

support for PPM or partner employees. This will reduce the risk of hackers using a

stolen device to access collaboration website.

Internal
 Mahajan 15

4.2 Other Recommendations

4.2.1 Security Awareness and Training

PPM needs to adopt specific security policies to identify core activities such as security

reminders, protection, login monitoring, and password management. It is important to

note that “people” and "ignorance", not necessarily technology, are often the largest

threat to security and sensitive information and every effort needs to be made to ensure

all staff, management and partners are aware and adhere to the Information Security

policy.

4.2.2 Business Continuity Management

PPM's Business Continuity Management (BCM) plan needs to be updated and tested to

include scenarios of collaboration website being made unavailable or breached. A

defined framework to address issues related to Unavailability of sensitive patient data

that can impact healthcare delivery or invite regulatory action needs to be implemented.

Clear understanding of Recovery Time Objectives (RTO) and Recovery Point Objectives

(RPO) for each set of patient data and IT systems involved need to be set out and BCM

plans geared to achieve those.

Internal
 Mahajan 16

5. CONCLUSION

A risk heat map is a tool used to present the results of a risk assessment process visually and in

a meaningful and concise way. Narrowly focusing on inherent risks and existing controls in

place and outlined in Section 3, the below Figure 2, risk heat map was developed BEFORE

additional controls and recommendations outlined in Section 4 have been implemented.

Figure 2: Risk heat map for inherent risks and existing controls

As depicted in the heat map, several risks in the "Red" zone indicate high likelihood of them

materializing with potentially catastrophic impact to the organization. Additional control

measures and recommendations highlighted in Section 4 are expected to lower the likelihood

and severity of these risk impacts such that it brings the overall residual risk to an acceptable

level. These expected residual risks AFTER these recommendations are implemented depicted

in Figure 3 below.

Internal
 Mahajan 17

Figure 3: Residual risk heat map with additional controls

It is important to note that the above risk heat map in Figure 3 provides a "potential" view once

additional control measures and recommendations highlighted in Section 4 have been adopted.

Risk likelihood and impact are expected to fall in the "yellow" and "green" zone and would need

to be monitored and managed continuously. Residual risk likelihood and impact are

expected to be at an "Acceptable" level and the project can be approved with the

condition that as a minimum, control measures and recommendations identified in this

report will implemented.

Internal
 Mahajan 18

6. REFERENCES

1. Picture on Title Slide: O'Dowd, Elizabeth. "Open Source Collaboration Key to Healthcare

Blockchain Adoption", August 24, 2017, www.HITinfrastructure.com

2. Ali, Sheraz. "6 Steps Risk Management Approach", September 03, 2016,

https://www.ecrrn.com/blog/files/6b05d547c39af8ce6babd9e94b71fab0-4.html

3. McGee, Marianne Kolbasuk. "A New In-Depth Analysis of Anthem Breach", January 10,

2017, https://www.bankinfosecurity.com/new-in-depth-analysis-anthem-breach-a-9627

4. Roberts, Paul. "CLOUD FILE SHARING LEADS TO $250K HIPAA FINE", March 20,

2017, https://digitalguardian.com/blog/cloud-file-sharing-leads-250k-hipaa-fine

5. McGee, Marianne Kolbasuk, " NY Presbyterian Hospital Slapped With Second HIPAA

Fine", April 21, 2016,

https://www.hhs.gov/sites/default/files/ocr/privacy/hipaa/enforcement/examples/ny-and-

presbyterian-hospital-settlement-agreement.pdf

6. Sublett, Christine. " Health Data Security and Risk: An Overview of What Lies Ahead",

October 18, 2017, https://www.academyhealth.org/blog/2017-10/health-data-security-

and-risk-overview-what-lies-ahead

Internal