HIPAA Series – Basics of Risk Analysis and Risk Management

In this post we are going to talk about Basics of Risk Analysis and Risk Management. This post is the sixth post in the HIPAA series. This series of posts is called the HIPAA Series.

The series will contain seven post:

But this series also has two spin offs. We suggest that if you do not have basic information about HIPAA, before starting this series, first read the following two posts:

—————————–

Source:

This article is a summary from of the hhs.gov website. With the following link:

Basics of Risk Analysis and Risk Management

For more info please refer to hhs.gov

Security Rule Requirements for Risk Analysis and Risk Management

The Security Management Process standard has four required implementation specifications. Two of the implementation specifications are Risk Analysis and Risk Management.

Implementation specification for Risk Analysis: 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.
Implementation specification for Risk Management: Implement security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level to comply with [(the General Requirements of the Security Rule)].

Much of the content included in this paper is adapted from government resources such as the National Institute of Standards and Technology (NIST) 800 Series of Special Publications (SP), specifically, SP 800-30 – Risk Management Guide for Information Technology Systems.

The goal of this post is to present the main concepts of the risk analysis and risk management processes in an easy-to-understand manner.

There are numerous methods of performing risk analysis and risk management. There is no single method or “best practice” that guarantees compliance with the Security Rule. However, most risk analysis and risk management processes have common steps.

To better understand risk analysis and risk management processes, covered entities should be familiar with several important terms, including “vulnerability,” “threat,” and “risk,” and the relationship between the three terms. Explanations of the terms are adapted from NIST SP 800-30 and are presented in the context of the Security Rule.

1- Vulnerability: a flaw or weakness in system security procedures, design, implementation, or internal controls that could be exercised (accidentally triggered or intentionally exploited) and result in a security breach or a violation of the system’s security policy.

Vulnerabilities could potentially result in a security incident, such as an inappropriate use or disclosure of EPHI.

There are two types of Vulnerabilities:

Technical: These vulnerabilities may include: holes, flaws or weaknesses in the development of information systems; or incorrectly implemented and/or configured information systems.
Nontechnical: these vulnerabilities may include ineffective or non-existent policies, procedures, standards or guidelines.

2- Threat: The potential for a person or thing to exercise (accidentally trigger or intentionally exploit) a specific vulnerability.”

Threats may be grouped into these general categories:

Natural threats: like floods, earthquakes, tornadoes, and landslides.
Human threats: These threats are enabled or caused by humans and may include intentional (e.g., network and computer based attacks, malicious software upload, and unauthorized access to EPHI) or unintentional (e.g., inadvertent data entry or deletion and inaccurate data entry) actions.
Environmental threats: like power failures, pollution, chemicals, and liquid leakage.

3- RISK: The net mission impact considering (1) the probability that a particular threat will exercise (accidentally trigger or intentionally exploit) a particular vulnerability and (2) the resulting impact if this should occur.

Risks arise from legal liability or mission loss due to:

Unauthorized (malicious or accidental) disclosure, modification, or destruction of information
Unintentional errors and omissions
IT disruptions due to natural or man-made disasters
Failure to exercise due care and diligence in the implementation and operation of the IT system.”

In fact, risk is a function of:

The likelihood of a given threat triggering or exploiting a particular vulnerability, and
The resulting impact on the organization.

Example Risk Analysis Steps

This section of the post provides an example approach to risk analysis which may be used by covered entities. Typically, risk analysis includes eight steps. We will discuss about all of them. These steps include:

ITperfection, HIPPA, Security Rule, Basics of Risk Analysis and Risk Management,example of risk analysis

1- Identify the Scope of the Analysis

The risk analysis scope that the Security Rule requires is the potential risks and vulnerabilities to the confidentiality, availability and integrity of all EPHI that a covered entity creates, receives, maintains, or transmits. This includes EPHI in all forms of electronic media.

Electronic media is defined:

Electronic storage media including memory devices in computers (hard drives) and any removable/transportable digital memory medium, such as magnetic tape or disk, optical disk, or digital memory card; or
Transmission media used to exchange information already in electronic storage media. This media include for example, the internet, extranet, leased lines, dial-up lines, private networks, and the physical movement of removable/transportable electronic storage media.

Certain transmissions, including of paper, via facsimile, and of voice, via telephone, are not considered to be transmissions via electronic media, because the information being exchanged did not exist in electronic form before the transmission.

2- Gather Data

For example, a covered entity must identify where the EPHI is stored, received, maintained or transmitted.

A covered entity could gather relevant data by reviewing past and/or existing projects; performing interviews; reviewing documentation; Or using other data gathering techniques. The data on EPHI gathered using these methods must be documented.

3- Identify and Document Potential Threats and Vulnerabilities

Identification of threats and vulnerabilities are central to determining the level of risk. These items could be separated into two distinct steps but are so closely related in the risk analysis process that they should be identified at the same time.

Independent identification may result in large lists of threats and vulnerabilities that, when analyzed (in subsequent steps to identify risk), do not provide valuable information.

Identify and Document Threats

Covered entities must identify and document reasonably anticipated threats to EPHI. To start, covered entities may compile a categorized list (such as natural, human, and environmental) of threats.

After the complete list is compiled, the covered entity should reduce the list to only those reasonably anticipated threats. For example, the geographic location of the entity will determine the natural threats that may create a risk.

For most covered entities, human threats will be of greatest concern, because human threats have the potential to be triggered or exploited more frequently than natural or environmental threats. Potential human sources that could target a covered entity and trigger or exploit vulnerabilities are employees (the most common source), ex-employees, hackers, commercial rivals, terrorists, criminals, general public, vendors, customers and visitors. Anyone that has the access, knowledge and/or motivation to cause an adverse impact on the covered entity can act as a threat.

Information sources such as any history of system break-ins, security violation reports, and ongoing input from systems administrators, help desk personnel and the user community should be reviewed.

Identify and Document Vulnerability

The process of identifying vulnerabilities is similar to the process used for identifying threats. The entity should create a list of vulnerabilities, both technical and non-technical, associated with existing information systems and operations that involve EPHI.

Sources of information to identify non-technical vulnerabilities may include previous risk analysis documentation, audit reports or security review reports. Sources of information to identify technical vulnerabilities may include assessments of information systems, information system security testing, or publicly available vulnerability lists and advisories. The Internet is a valuable resource for sharing technical vulnerability lists and advisories. Another important way to identify technical vulnerabilities in information systems is through information systems security testing. The output of the security testing may be a report identifying technical vulnerabilities that exist within the organization.

4- Assess Current Security Measures

The goal of this step is to analyze current security measures implemented to minimize or eliminate risks to EPHI.

Security measures can be both technical and nontechnical:

Technical measures are part of information systems hardware and software. Examples of technical measures include access controls, identification, authentication, encryption methods, automatic logoff and audit controls.
Non-technical measures are management and operational controls, such as policies, procedures, standards, guidelines, accountability and responsibility, and physical and environmental security measures.

The appropriate security measures that reduce the likelihood of risk to the confidentiality, availability and integrity of EPHI in a small covered entity may differ from those that are appropriate in large covered entities. The output of this step should be documentation of the security measures a covered entity uses to safeguard EPHI. These documentation should identify if current security measures are configured and used properly.

5- Determine the Likelihood of Threat Occurrence

The next two steps (steps 5 and 6) use information gathered from the previous steps to help the covered entity make likelihood and impact determinations.

Likelihood of occurrence: Probability that a threat will trigger or exploit a specific vulnerability.

Covered entities should consider each potential threat and vulnerability combination and rate them by likelihood (or probability) that the combination would occur. Ratings such as high, medium and low or numeric representations of probability may be used to express the likelihood of occurrence.

The ratings used will depend on the covered entity’s approach. For example, a covered entity may choose to rate risks as high, medium and low, which could be defined as:

High Likelihood: a high probability exists that a threat will trigger or exploit one or more vulnerabilities. This might be due to the existence of multiple organizational deficiencies, such as the absence, inadequacy or improper configuration of security controls, or due to geographic location (such as, within a flood zone).
Medium Likelihood: a moderate probability exists that a threat will trigger or exploit one or more vulnerabilities due to the existence of a single organizational deficiency, such as the lack of security measures.
Low Likelihood: a low probability exists that a threat will trigger or exploit a single vulnerability due to the existence of a single organizational deficiency, such as improper configuration of security controls.

6- Determine the Potential Impact of Threat Occurrence

If a threat triggers or exploits a specific vulnerability, there are many potential outcomes. For covered entities, the most common outcomes include, but are not limited to:

Unauthorized access to or disclosure of EPHI
Permanent loss or corruption of EPHI
Temporary loss or unavailability of EPHI
Loss of financial cash flow
Loss of physical assets

All of these outcomes have the potential to affect the confidentiality, availability and integrity of EPHI created, received, maintained, or transmitted by covered entities. Measuring the impact of a threat occurring in a covered entity can be performed using different methods. The most common methods are qualitative and quantitative.

Qualitative method: This method rates the magnitude of the potential impact resulting from a threat triggering or exploiting a specific vulnerability on a scale such as high, medium and low. The qualitative method is the most common measure used to measure the impact of risk.
Quantitative method: This method measures the tangible potential impact of a threat triggering or exploiting a specific vulnerability, using a numeric value associated with resource cost but it is generally difficult to assign numeric values to intangible losses. Therefore, all potential impacts generally cannot be determined using this method.

7- Determine the Level of Risk

Covered entities should determine the level of risk to EPHI. These entities will use the output of the previous two steps (steps 5 and 6) as inputs to this step. The output of those steps, likelihood and potential impact of threat occurrence data, will focus the covered entity’s risk level determination to reasonably anticipated risks to EPHI. The level of risk is determined by analyzing the values assigned to the likelihood of threat occurrence and resulting impact of threat occurrence. The risk level determination may be performed by assigning a risk level based on the average of the assigned likelihood and impact levels. Each risk level is labeled with a general action description to guide senior management decision making.

The action description identifies the general timeline and type of response needed to reasonably and appropriately reduce the risk to acceptable levels. For example, a risk level of “high” could have an action description requiring immediate implementation of corrective measures to reduce the risk to a reasonable and appropriate level.

8- Identify Security Measures and Finalize Documentation

Now, the covered entity should begin to identify the actions required to manage the risk. The purpose of this step is to begin identifying security measures that can be used to reduce risk to a reasonable and appropriate level. The risk analysis documentation is a direct input to the risk management process.

When identifying security measures that can be used, it is important to consider factors such as: the effectiveness of the security measure; legislative or regulatory requirements that require certain security measures to be implemented; and requirements of the organization’s policies and procedures. Any potential security measures that can be used to reduce risks to EPHI should be included in documentation.

The final step in the risk analysis process is documentation. A risk analysis report could be created to document the risk analysis process, output of each step and initial identification of security measures.

Example Risk Management Steps

This section of the post provides an example approach to risk management which may be used by covered entities. Typically, risk management includes three steps. We will discuss about all of them. These steps include:

1- Develop and Implement a Risk Management Plan

The purpose of a risk management plan is to provide structure for the covered entity’s evaluation, prioritization, and implementation of risk-reducing security measures. For the risk management plan to be successful, key members of the covered entity’s workforce, including senior management and other key decision makers, must be involved. The outputs of the risk analysis process will provide these key workforce members with the information needed to make risk prioritization and mitigation decisions. The risk prioritization and mitigation decisions will be determined by answering questions such as: Should certain risks be addressed immediately or in the future? Which security measures should be implemented? Many of the answers to these questions will be determined using data gathered during the risk analysis.

An important component of the risk management plan is the plan for implementation of the selected security measures. The implementation component of the plan should address:

Risks (threat and vulnerability combinations) being addressed
Security measures selected to reduce the risks
Implementation project priorities, such as: required resources; assigned responsibilities; start and completion dates; and maintenance requirements

Compliance with the Security Rule requires financial resources, management commitment, and the workforce involvement. Cost is one of the factors a covered entity must consider when determining security measures to implement. However, cost alone is not a valid reason for choosing not to implement security measures that are reasonable and appropriate. The output of this step is a risk management plan that contains prioritized risks to the covered entity, options for mitigation of those risks, and a plan for implementation.

2- Implement Security Measures

This step will focus on the actual implementation of security measures (both technical and non-technical) within the covered entity. Covered entities may want to consider the benefits, if any, of implementing security measures as part of another existing project, such as implementation of a new information system. A covered entity may choose to use internal or external resources to perform these projects. The Security Rule does not require or prohibit either method.

3- Evaluate and Maintain Security Measures

Risk analysis and risk management are not one-time activities. Risk analysis and risk management are ongoing, dynamic processes that must be periodically reviewed and updated in response to changes in the environment. The risk analysis will identify new risks or update existing risk levels resulting from environmental or operational changes.

The Security Rule does not specify how frequently to perform risk analysis and risk management. The frequency of performance will vary among covered entities. Some covered entities may perform these processes annually or as needed (e.g., bi-annual or every 3 years) depending on circumstances of their environment.

For example, if the covered entity is planning to incorporate new technology to make operations more efficient, such as using notebook computers or handheld devices that contain EPHI, the potential risk to these devices must be analyzed to ensure the EPHI is reasonably and appropriately protected. Performing the risk analysis and risk management processes before implementing the new technology will allow the covered entity to reduce the associated risks to reasonable and appropriate levels.

—————————–

Source:

This article is a summary from of the hhs.gov website. With the following link:

Basics of Risk Analysis and Risk Management

For more info please refer to hhs.gov