Security Risk Analysis and Management: An Overview (2013 update)

Editor’s note: This update replaces the January 2011 practice brief “Security Risk Analysis and Management: An Overview.”

Managing risks is an essential step in operating any business. It’s impossible to eliminate all threats; however, healthcare organizations typically conduct a periodic risk analysis to determine their potential exposure. A risk analysis allows organizations to develop strategies to manage those risks appropriately.

The concept of risk management is not new to healthcare, but conducting a risk analysis for information technology can be challenging.

This practice brief reviews the regulatory requirements of an effective security risk analysis and provides an overview of how to conduct a risk analysis.

Clarifying Key Terms

When thinking about risk analysis, it’s helpful to first sort out key terminology. For the purposes of this practice brief, the following terms are clarified below:

• Assessment—A judgment based on an understanding of the situation; a method of evaluating performance
• Analysis—The close examination of something (i.e. an application or information system) to understand it more effectively or to draw conclusions from it; the separation of something (i.e. an application or information system) into its constituents to determine what it contains; to examine individual parts or to study the structure of the whole Source: Encarta Dictionary
• Risk Analysis—A systematic and ongoing process of identifying threats, controls, and vulnerabilities—as well as their likelihood of impact—to arrive at an overall rating of risk

Regulatory Requirements

The HIPAA Security Rule and Meaningful Use require covered entities to perform a risk analysis. An assessment must address the following HIPAA Security Rule standard:

• §164.308(a)(8), Evaluation, which states that organizations must “Perform a periodic technical and nontechnical evaluation, based initially upon the standards and implemented under this rule and subsequently, in response to environmental or operational changes affecting the security of electronic protected health information, that establishes the extent to which an entity’s security policies and procedures meet the requirements of this subpart.”

Refer to the Office of the National Coordinator’s (ONC) Guide to Privacy and Security of Health Information for information about what does and does not qualify as a risk analysis. Specifically, refer to the table entitled Security Risk Analysis Myths and Facts for specific examples. One example is provided below.For example, p. 11 of the guide states the following:

The HIPAA Security Rule requires covered entities and business associates as well as their agents and subcontractors to conduct a risk analysis and implement measures “to sufficiently reduce those risks and vulnerabilities to a reasonable and appropriate level.” Specifically, the rule requires compliance with the following:

• §164.308(a)(1)(ii)(A), Risk analysis, which requires organizations to “…conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information…”
• §164.308(a)(1)(ii)(B), Risk management, which requires organizations to“…implement security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level…”

The security rule applies to a variety of organizations ranging from large healthcare systems to small physician practices as well as their business associates.² Thus, the standards for how an organization must approach a risk analysis are flexible. An organization must base its decision on several factors, including:

• The organization’s size, complexity, and capabilities
• The organization’s technical infrastructure, hardware, and software security capabilities
• The costs of security measures
• The probability and criticality of potential risks to electronic protected health information (ePHI)

The final security rule includes the word ‘reasonable’ 51 times. It includes the word ‘reasonably’ 21 times(including the preamble). What is considered reasonable for one organization may not be for another. Some organizations may be more comfortable accepting certain levels of risk based on their own unique analysis.

A risk analysis determines how to meet the security rule’s implementation specifications and whether an alternative security measure appropriately meets the intent of an implementation specification. However, the HIPAA Security Rule’s preamble states “Cost is not meant to free covered entities from this [adequate security measures] responsibility.” If the cost is reasonable—and a security measure or control would reduce risk significantly—then an organization of any size should consider implementing the control, especially if the risks are high or moderate.

In addition, healthcare organizations striving to meet the Meaningful Use criteria must conduct a risk analysis.³ The Stage 1 criteria include the following measure: “Conduct or review a security risk analysis per 45 CFR 164.308 (a)(1) and implement security updates as necessary and correct identified security deficiencies as part of its risk management process.”

Stage 2 criteria specifies: “Conduct or review a security risk analysis in accordance with the requirements under 45 CFR 164.308(a)(1), including addressing the encryption/security of data at rest in accordance with requirements under 45 CFR 164.312 (a)(2)(iv) and 45 CFR 164.306(d)(3), and implement security updates as necessary and correct identified security deficiencies as part of the EP’s [eligible provider] risk management process.”

Risk Analysis: Framework

The HIPAA Security Rule does not require a specific methodology or process for conducting a risk analysis. However, it does reference the National Institute of Standards and Technology (NIST) Special Publication (SP) 800-30, Risk Management Guide for Information Technology Systems. This publication provides a comprehensive framework that both the Department of Health and Human Services (HHS) and CMS reference in the following publications:

• The HIPAA Security Rule⁴
• 6 Basics of Risk Analysis and Risk Management⁵
• HIPAA Compliance Review Analysis and Summary of Results⁶
• Guidance on Risk Analysis Requirements under the HIPAA Security Rule⁷

The original NIST SP 800-30 was retired and replaced with the following publications:

• 800-30 Guide for Conducting Risk Assessments, Revision 1 (September 2012)
• 800-39 Managing Information Security Risk: Organization, Mission, and Information System View (March 2011)

Note: Because this practice brief is intended to provide a high-level overview, AHIMA recommends that the reader download NIST SPs 800-30 and 800-39 for a more detailed explanation of risk analysis.9

Figure 1 illustrates the nine risk analysis process steps as detailed in this practice brief.

Figure 1 - Risk Analysis Methodology Flowchart

Step 1. System Characterization

System characterization is the process of identifying the information assets that require a risk analysis. The information assets require protection either because of their criticality to the business and/or because the systems process and store ePHI. System characterization requires an inventory of major applications and general support systems—that is, any systems that process or store PHI. A major application is one that is critical to an organization or that stores PHI. Generally, the ‘owner’ of a major application is the director of the department that primarily uses that application. Following are some examples of major applications and their probable owners:

• Electronic health record (EHR) [chief operating officer and/or chief information officer]
• Laboratory information system [director of laboratory]
• Pharmacy system—medication dispensing carts [director of pharmacy]

General support systems are the systems used throughout the organization to support one or more applications. They are usually ‘owned’ by the information technology (IT) department. Following are some examples of general support systems:

• Computer workstations
• Laptops and tablets
• Smartphones and other mobile devices
• Network (wired and wireless)
• E-mail system

An organization’s risk analysis should initially focus on systems that have the greatest effect on healthcare operations as well as systems that pose the greatest risk for the organization. A business impact analysis, often conducted before creating a disaster recovery plan, is one method used to determine information system criticality.10

Another method for identifying the systems on which the healthcare organization should focus is to rank applications systems based on risk factors, such as:

• Number of users (i.e., the greater the number of users, the higher the risk)
• Type of information (i.e., the more sensitive the information, the higher the risk – Social Security Numbers, HIV data, bank account numbers, credit card data, etc.),
• Use of the information (i.e., patient care, research, business intelligence, patient accounting, etc.)
• Availability of the information (e.g., hosted in the cloud via the Internet, standalone system, virtualized servers, mirrored SAN, etc. )
• Mobility of the information (i.e., the more mobile, the greater the risk – portable media, smartphone, tablet, laptop, etc.)
• Effects on the organization and patients if the system is not available
• Other factors that might indicate that a system has a higher relative risk for the organization (i.e., system frequently goes down, system provide interconnectivity to other applications and system such as an interface engine, etc.

A risk analysis can be time-consuming. Therefore, healthcare organizations should initially focus should be on the ‘critical few’ versus the ‘trivial many.’ However, all applications and systems (including biomedical devices) containing ePHI must eventually be assessed.

Step 2. Threat Identification

Once major applications and general support systems have been categorized, the next step is to identify threats. From an information security perspective, a threat is anything that could affect the confidentiality, integrity, or availability of information or an information system.

There are three types of threats:

• Acts of nature (e.g., lightning, earthquakes, hurricanes, and tornadoes)
• Acts of humans (e.g., carelessness, human errors, unauthorized access, identity theft; tampering; hacking into data; and theft of equipment by internal workforce members, external hackers, and visitors)
• Environmental (e.g., hardware failure, power outage, inoperable air conditioning that leads to overheating, break in the network cable, and water leaking from the ceiling)

Conducting a thorough risk analysis does not imply that organizations must identify every possible threat. The term “reasonably anticipated” is used three times within the HIPAA security rule (twice in the preamble and once in the actual rule) as it pertains to threats or hazards. Instead, they should consider these factors:

• Statistics (i.e. HHS website for reported breaches affecting over 500 patients)
• Geographical location (i.e. hurricane for coastal areas, tornado for the Midwest, volcano for Hawaii)
• Past experiences (i.e. incident reports indicate areas of vulnerability that have been exploited before – theft of equipment in public areas)
• Industry trends (i.e. surveys, reports, security alerts, patches or system updates)

Once identified, the reasonably anticipated threats are matched to a particular application or general support system. For example, the probability of theft is more likely for a laptop or a smartphone that is transported daily in and out of an organization. Alternatively, theft may not be a reasonably anticipated threat for a large rack-mounted server in a data center.

System characterization divides information assets into manageable pieces and helps healthcare organizations identify the unique threats that may exist at each layer of an information system, including the application, the operating system, any software, the server, the network, and desktop and laptop levels of use.

Steps 3 and 4. Control Assessment and Vulnerability Identification

Vulnerabilities and controls should go hand in hand, and it’s often easier to combine the identification of both into one step. If a major application or general support system is already in use, then a healthcare organization should first conduct a control analysis. If an application or system is new and not currently active, then the healthcare organization should perform a vulnerability identification first because some of the security controls may not have been implemented fully yet.

A vulnerability is as an inherent weakness or absence of a safeguard that a threat could exploit. Vulnerabilities may be attributed to people, processes, or technologies. The absence of a functioning control often represents vulnerability in an application or system. For example, antivirus software is used to prevent or detect malicious code. If this control is missing, it represents vulnerability. Sometimes a control may be present but inadequate. Using the same example, if the antivirus software is present but does not get updated regularly, this is also a vulnerability.

Typically, threats are correlated with vulnerabilities, although it is not necessarily a one-to-one relationship. Many threats may exploit a single vulnerability. One threat source may exploit more than one vulnerability. Conversely, a single control may be used to address multiple threats. Figure 2, offers samples of controls and vulnerabilities based on a specific threat for laptops.

Figure 2 - Sample of Threats, Controls, and Vulnerabilities

In general, controls may be categorized as:

• Preventive—Inhibiting a threat, such as access controls, encryption, and authentication requirements
• Deterrent—Keeping the casual threat away, such as strong passwords, two-tiered authentication, and Internet use policies
• Detective—Identifying and proving when a threat has occurred or is about to occur, such as audit trails, intrusion detection, and checksums
• Reactive—Providing a means to respond to a threat that has occurred, such as an alarm or penetration test
• Recovery—A control that helps retrieve or recreate data or applications, such as backup systems and contingency plans

In addition to control analysis, other sources for determining vulnerabilities include reports or results from:

• Past incidents or data breaches, including news stories about reported data breaches at other organizations
• Audits or evaluations conducted by external or internal auditors
• A compliance gap analysis or privacy and security assessment
• Patient complaints to determine whether a breakdown or flaw in a security control exists
• A walk-through inspection (e.g., workstations being left unattended while logged on to an information system containing confidential information)
• A network vulnerability scanning or penetration test
• Web sites, such as the HHS Web site, that post breaches⁸ affecting more than 500 individuals

Step 5. Likelihood Determination

The next step in the risk analysis process is to determine the probability or likelihood that a potential threat will successfully exploit vulnerabilities. The likelihood determination must be made with consideration of the existing security safeguards and controls. Example definitions of likelihood ratings are described in Figure 3.

Figure 3 – Likelihood Definition

Step 6. Impact Analysis

The next step in the process is to determine the potential impact resulting from threats that successfully exploit vulnerabilities. Figure 4 includes example definitions of different types of threats. Figure 5 includes impact ratings of those threats.

Figure 4 - Impact Definition

Healthcare organizations are encouraged to edit these definitions or create their own definitions for likelihood and impact. An accurate description of what constitutes a rating of high, medium, or low is important for maintaining consistency when evaluating risk scores. A consistent standard for scoring risks ensures a better prioritization of risk.

Figure 5-Possible Impacts

Step 7. Risk Determination

The purpose of this step is to assign a risk score that is based on likelihood of the threat being realized, considering the current controls in place and impact to the organization if the threat was successful in exploiting a vulnerability. The scoring of risks allows healthcare organizations to prioritize resources and focus on the areas of greatest risk.

Regardless of the method used, the primary goal for conducting a risk analysis is to prioritize risks. This prioritization ensures that limited resources (i.e., money, people, and time) may be applied to the areas of greatest risk so vulnerabilities can be addressed and reduced.

Healthcare organizations use two approaches to determine risk: qualitative and quantitative. See Figure 6 below.

Figure 6 - Risk Determination: Two Common Approaches

Step 8. Control Recommendations

A control recommendation is plan to address a vulnerability. Figure 7 includes samples of how a stated vulnerability can be translated into a control recommendation.

Figure 7 - Creating Control Recommendations

Note that there may not always be a specific control recommendation for a given vulnerability. For example, when employees have remote access or work from home, there is a threat that someone else (i.e., family member, friend, neighbor) may have access to confidential information. There is no way for an organization to technically secure an employee’s home environment. The recommendation to stop allowing remote access from home may not be a viable option for most organizations. The risk remains without a direct technical control recommendation. Other administrative safeguards might be recommended, such as enhanced awareness for remote access.

Step 9. Results Documentation

The final step in the risk analysis process is the results documentation. The HIPAA Security Rule does not specify the format for documentation of a risk analysis. Many organizations use some type of spreadsheet or a summary report.

Figure 8 is a sample of a risk profile for a risk analysis conducted on laptops. A risk profile is one way to generalize and document risks efficiently. A risk profile can be stored in a Word document, an Excel spreadsheet, or a database. The risk profile below covers most laptops routinely carried in and out of the organization by its workforce. Although there may be some variations in individual configurations, management by exception is a far simpler approach than trying to conduct and document a risk analysis for every laptop used within the organization.

Figure 8 - Sample Risk Profile

A risk analysis report includes the key findings or vulnerabilities as well as the control recommendations for reducing risks. The application or system owners should sign off on this report so that they are aware of the residual risks (i.e., the risks that remain even with the current safeguards and controls applied). Application or system owners typically address risks in one of the three following ways:

1. Mitigate—reduce risks by implementing the recommended controls
2. Transfer—outsource or insure against loss (not always a viable option)
3. Accept—recognize the residual risk but hold off on implementing any controls

Healthcare organizations should address risks in a cost-effective manner relative to the value of the asset and the criticality and sensitivity of the data. Of course, if the risk could be avoided altogether (which is seldom the case), it is also an option. For example, a risk analysis conducted prior to the purchase of an application or system may result in the organization deciding to avoid the risks inherent in the application or system altogether by not purchasing it.

This final step of the risk analysis process is often incomplete because some of the information technology (IT) staff might find it difficult to complete the necessary paperwork and reports. It can also be challenging to obtain a decision from the application or system owner regarding how residual risks will be managed.

HIPAA requires healthcare organizations to retain documentation of the risk analysis for six years. Documentation is critical in proving that the analysis was performed.

Risk Management

Risk management is the act of implementing security safeguards and controls. It also entails monitoring for changes and responding with enhanced strategies. The HIPAA Security Rule addresses the ongoing management of risks in several areas:

• §164.306(e)€, which requires organizations to ensure the following: “Security measures implemented to comply with standards and implementation specifications adopted...must be reviewed and modified as needed to continue provision of reasonable and appropriate protection of electronic protected health information.”
• §164.308(a)(1)(ii)(D), Information system activity review, which requires organizations to “implement procedures to regularly review records of information system activity, such as audit logs, access reports, and security incident tracking reports.”
• §164.308(a)(8), Evaluation, which requires organizations to “perform a periodic technical and nontechnical evaluation, based initially upon the standards and implemented under this rule and subsequently, in response to environmental or operational changes affecting the security of electronic protected health information that establishes the extent to which an entity’s security policies and procedures meet the requirements of this subpart.”

The success of a risk management process depends heavily on the commitment of those involved with safeguarding an application or system. These individuals must implement the approved control recommendations. Therefore, it is strongly suggested that some type of follow-up be scheduled approximately two to three months after the final risk analysis report is delivered and signed. The purpose of the follow-up is to verify progress on risk reduction and to maintain open communications when obstacles are encountered.

Risk analysis and risk management are ongoing processes. Federal government agencies are required by law to reassess risk to information systems every three years. This reassessment is a good benchmark from which healthcare organizations can determine an appropriate time frame. Figure 9 illustrates the ongoing risk management process as described in NIST SP 800-37, Guide for Applying the Risk Management Framework to Federal Information Systems: A Security Life Cycle Approach (Revision 1 February 2010).

Figure 9 - A Security Life-Cycle Approach

Notes

1. The Office of the National Coordinator for Health Information Technology. Guide to Privacy and Security of Health Information. Available online at http://www.healthit.gov/sites/default/files/pdf/privacy/privacy-and-security-guide.pdf
2. Business associates are now required to comply with the Health Insurance Portability and Accountability Act of 1996 (HIPAA) Security Rule because of the passage of the Health Information Technology for Economic and Clinical Health Act of 2009 (HITECH) and as amended by the Omnibus Rule (released January 25, 2013) [Modifications to the HIPAA Privacy, Security, Enforcement, and Breach Notification Rules under the Health Information Technology for Economic and Clinical Health Act and the Genetic Information Nondiscrimination Act; and Other Modifications to the HIPAA Rules]
3. The Office of the National Coordinator for Health Information Technology, “Electronic Health Records and Meaningful Use.” Available online at http://healthit.hhs.gov/portal/server.pt?open=512&objID=2996&mode=2.
4. U.S. Department of Health and Human Services. “The Security Rule.” Available online at www.hhs.gov/ocr/privacy/hipaa/administrative/securityrule/index.html.
5. U.S. Department of HHS. “Security Rule Guidance Material.” Available online at www.hhs.gov/ocr/privacy/hipaa/administrative/securityrule/securityruleguidance.html.
6. Centers for Medicare and Medicaid Services, Office of E-Health Standards and Services . “HIPAA Compliance Review Analysis and Summary of Results.” 2008. Available online at www.hhs.gov/ocr/privacy/hipaa/enforcement/cmscompliancerev08.pdf.
7. U.S. Department of HHS. Guidance on Risk Analysis Requirements under the HIPAA Security Rule. July 14, 2010. Available online at www.hhs.gov/ocr/privacy/hipaa/administrative/securityrule/rafinalguidancepdf.pdf.
8. Office for Civil Rights. Breaches Impacting More than 500 Individuals available online at: http://www.hhs.gov/ocr/privacy/hipaa/administrative/breachnotificationrule/breachtool.html
9. NIST SPs in the 800 series are available online at: http://csrc.nist.gov/publications/PubsSPs.html.
10. Under the HIPAA Security Rule provision for the addressable implementation specification, “Applications and data criticality analysis” §164.308(a)(7)(ii)(E) is essentially a Business Impact Analysis (BIA).”
11. Alberts, Christopher, and Audrey Dorofee. Managing Information Security Risks– The OCTAVESM Approach. Boston, MA: Addison-Weley, 2002.

Reference

Herzig, Terrell. Information Security in Healthcare: Managing Risk. Chicago: HIMSS, 2010. 

Prepared by (2013)

Tom Walsh, CISSP

Assisted by (2013)

William Miaoulis, CISA, CISM

Acknowledgments (2013)

Becky Buegel, RHIA, CHP, CHC
Marlisa Coloso, RHIA, CCS
Julie A. Dooling, RHIA
Katherine Downing, MA, RHIA, CHPS, PMP
Sharon Easterling, MHA, RHIA, CCS, CDIP, CPHM
Lesley Kadlec, MA, RHIA
Michele Kruse, MBA, RHIA, CHPS
Kelly McLendon, RHIA CHPS
Angela Dinh Rose, MHA, RHIA, CHPS, FAHIMA
Jane DeSpiegelaere, MBA, RHIA, CCS, FAHIMA

Prepared by (2011)

Tom Walsh, CISSP

Acknowledgments (2011)

Angela K. Dinh, MHA, RHIA, CHPS
Margaret M. Foley, PhD, RHIA, CCS
Judi G. Hofman, CAP, CHSS
John T. Jensen, CHPS, CIPP
William Miaoulis, CISA, CISM
Margaret Schmidt, RHIA
Mary C. Thomason, II, RHIA, CHPS, CISSP
LaVonne Wieland, RHIA, CHP

Prepared by (original)

Margret Amatayakul, RHIA, CHPS, FHIMSS