The Final HIPAA Security Rule Conducting Effective Risk Analysis

The Final HIPAA Security Rule -- Conducting Effective Risk Analysis

By Steve Weil, CISSP, CISA

Introduction

Risk analysis is a key requirement of the HIPAA final Security Rule. The Security Rule requires covered entities (CEs) to "conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information held by the covered entity." The rule further states that "[t]he required risk analysis is also a tool to allow flexibility for entities in meeting the requirements of this final rule... ." This article presents a high-level overview of the risk analysis process.
"Risk" is the likelihood that a specific threat will exploit a certain vulnerability, and the resulting impact of that event. "Risk analysis," the starting point in an overall risk management process, is a systematic and analytical approach that identifies and assesses risks and provides recommendations to reduce risk to a reasonable and appropriate level. This process will enable senior management to understand their organization's risks to electronic protected health information (EPHI), and to allocate appropriate resources to reduce and correct potential losses.

General Methodology

Risk analysis is an eight-part process that CEs should carry out step-by-step:

EPHI boundary definition
Threat identification
Vulnerability identification
Security control analysis
Risk likelihood determination
Impact analysis
Risk determination
Security control recommendations

Step 1: EPHI Boundary Definition

CEs should begin the risk analysis process by conducting a detailed inventory of their EPHI and information systems that contain EPHI. Using questionnaires, on-site interviews and inspections, document review, and automated scanning tools, the inventory should obtain and document a wide variety of information, including:

Information system hardware and software details
Internal and external interfaces of information systems
Identification of the primary users of the information systems and EPHI
Basic function and purpose of the EPHI and information system
Technical controls (e.g., hardware or software access control mechanisms, encryption) and non technical controls (e.g., security policies, employee training) being used to protect EPHI and information systems

Information systems can be complex, with a wide range of components, interfaces, and processes; the inventory should seek to identify all interdependencies among these items.

Step 2: Threat Identification

The CE should next identify all potential threats to its EPHI and related information systems. A threat is defined as "something or someone that can intentionally or accidentally exploit a vulnerability." In general, there are three types of threats to EPHI:

Natural: Floods, earthquakes, tornados, etc.
Human: Unintentional (incorrect data entry or accidental deletion of data) and intentional (denial of service attack,
installing malicious software)
Environmental: Power failures, hazardous material spill, etc.

Detailed information about threats can be acquired from a wide variety of sources including:

Hazard identification and vulnerability assessment studies conducted by local and state governments
Security organizations such as SANS, CERT, and NIPC
Security web pages such as and

Step 3: Vulnerability Identification

CEs should then identify the vulnerabilities of their EPHI and related information systems. A vulnerability is a flaw or weakness in system security procedures, design, implementation, or internal controls that can be exploited by a threat and result in misuse or abuse of EPHI. CEs can identify these vulnerabilities by (1) reviewing vulnerability sources and (2) performing security assessments.
Vulnerability sources include system and data owner questionnaires, on-site review of information systems, audit reports, and information system test and evaluation reports. Vulnerability lists such as the NIST vulnerability database ( and Bugtraq, as well as advisories from security vendors and security organizations such as CERT are also good tools.
Security assessments use a variety of software tools and auditing techniques to check specific data and information systems for an array of vulnerabilities. They typically define the "footprint" (what systems and services are available to a threat). CEs should be sure to establish clearly defined rules of engagement (what time of day the assessments can occur, what types of attacks are appropriate, what systems will be assessed, etc.) BEFORE the assessment begins.

Step 4: Security Control Analysis

CEs should next analyze the security controls that have been implemented or will be implemented to protect EPHI; this includes both preventive and detective controls.
Preventive security controls are designed to prevent or restrict the exploitation of vulnerabilities (e.g., access control, authentication). Detective controls detect and report when violations occur (e.g., audit trail, alarm). The analysis should clearly define what security controls are being used to protect specific EPHI, how they're being used, and any gaps between how they're being used and how they're supposed to be used.

Step 5: Risk Likelihood Determination

The goal of this step is to assign to specific risks ratings that indicate the probability that a vulnerability will be exploited by a particular threat. Three factors should be considered: 1) threat motivation and capability, 2) type of vulnerability, and 3) existence and effectiveness of security controls. Table 1 below presents three risk likelihood levels that CEs might use:

Table 1

Likelihood / Definition
High / Threat is highly capable, motivated, or likely and current security controls are ineffective
Medium / Threat is capable, motivated or likely, but there are security controls in place that may prevent exploitation of specific vulnerabilities
Low / Threat is not capable, motivated or likely or current security controls will likely prevent exploitation of specific vulnerabilities

Step 6: Impact Analysis

Next, CEs determine the impact that would result if a threat were to successfully exploit a vulnerability. Information system and EPHI owners should be interviewed to determine the impact in the following areas:

Confidentiality: EPHI is disclosed or accessed in an unauthorized manner
Integrity: EPHI is improperly modified
Availability: EPHI is unavailable to authorized users

CEs should define the impacts as high, medium or low.

Step 7: Risk Determination

At this point, CEs use the information obtained in the above steps to identify the level of risk to specific EPHI and related information systems. For each vulnerability and associated possible threat, CEs should make a risk determination based on:

The likelihood a certain threat will attempt to exploit a specific vulnerability
The level of impact should the threat successfully exploit the vulnerability
The adequacy of planned or existing security controls

Table 2 below presents three levels of risk that CEs might use:

Table 2

Risk Level / Required Action
High / Security controls should be implemented or improved as quickly as possible
Medium / Security controls should be implemented or improved in a reasonable amount of time
Low / Existing security controls are likely adequate or the risk is acceptable

Step 8: Security Control Recommendations

Using all of the above information, CEs should conclude the Risk Analysis process by proposing security controls that can mitigate or eliminate the identified unacceptable risks to EPHI. These controls should reduce the level of risk to EPHI and related information systems to an acceptable level. These proposed controls would then be evaluated when the CE moves into risk mitigation.

Conclusion

Thorough and accurate risk analysis is essential for complying with the HIPAA final Security Rule. CEs can use the above risk analysis process to evaluate their risks and determine appropriate and reasonable security controls for protecting their EPHI.
Steven Weil, CISSP, CISA, is senior security consultant with Seitel Leeds & Associates, a full service consulting firm based in Seattle, WA. Mr. Weil specializes in the areas of security policy development, HIPAA compliance, disaster recovery planning and security assessments. He can be reached at .

The Final HIPAA Security Rule Conducting Effective Risk Analysis