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:

1. EPHI boundary definition
2. Threat identification
3. Vulnerability identification
4. Security control analysis
5. Risk likelihood determination
6. Impact analysis
7. Risk determination
8. 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 www.securityfocus.com and www.searchsecurity.com

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 (http://icat.nist.gov) 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:

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:

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.

Go to TOP