Risk Assessment
As of 2012, the healthcare industry had still not reached maturity in terms of establishing a protocol for conducting risk assessment of systems. The 2005 HIPAA Security Rule initiated a requirement that risk assessments be conducted, but left a lot of room for interpretation. However, organizations are being forced to catch up because of increased incidence of data breaches (up nearly 200% between 2010 and 2011), increased government oversight, and the Stage 1 Meaningful Use requirement that "hospitals and eligible professionals must "conduct or review a security risk analysis" to qualify for incentive payments. [1]
Example of a review on a Risk Assesment created for CPOE
Prescriptive requirements for risk assessments are typically ineffective because they stipulate too much, and fail to account for the unique circumstances of individual healthcare systems. Therefore system security should begin with an identification and prioritization of security and privacy risks, so that systems can allocate just enough resources to account for these risks. [2]
A good resource for conducting risk assessments is the National Institute of Standards and Technology's Risk Management Guide for Information Systems. It outlines the process of risk assessment in 9 steps:
• System Characterization - Identifying risk for an IT system requires a keen understanding of the system’s processing environment.
• Threat Identification - The goal of this step is to identify the potential threat-sources and compile a threat statement listing potential threat-sources that are applicable targeted at the intentional exploitation of a to the IT system being evaluated.
• Vulnerability Identification - The goal of this step is to develop a list of system vulnerabilities that could be exploited by the potential threat-sources.
• Control Analysis - The goal of this step is to analyze the controls that have been implemented, or are planned for implementation, by the organization to minimize or eliminate the likelihood (or probability) of a threat’s exercising a system vulnerability.
• Likelihood Determination - To derive an overall likelihood rating that indicates the probability that a potential vulnerability may be exercised within the construct of the associated threat environment, the following governing factors must be considered:
• Threat-source motivation and capability
• Nature of the vulnerability
• Existence and effectiveness of current controls.
• Impact Analysis - The next major step in measuring level of risk is to determine the adverse impact resulting from a successful threat exercise of a vulnerability.
• Risk Determination - The purpose of this step is to assess the level of risk to the IT system. The determination of risk for a particular threat/vulnerability pair can be expressed as a function of:
• The likelihood of a given threat-source’s attempting to exercise a given vulnerability
• The magnitude of the impact should a threat-source successfully exercise the vulnerability
• The adequacy of planned or existing security controls for reducing or eliminating risk.
• Control Recommendations - During this step of the process, controls that could mitigate or eliminate the identified risks, as appropriate to the organization’s operations, are provided. The goal of the recommended controls is to reduce the level of risk to the IT system and its data to an acceptable level. The following factors should be considered in recommending controls and alternative solutions to minimize or eliminate identified risks:
• Effectiveness of recommended options (e.g., system compatibility)
• Legislation and regulation
• Organizational policy
• Operational impact
• Safety and reliability.
• Results Documentation - Once the risk assessment has been completed (threat-sources and vulnerabilities identified, risks assessed, and recommended controls provided), the results should be documented in an official report or briefing. [3]
References
1. [1]
2. [2]
3. [csrc.nist.gov/publications/nistpubs/800-30/sp800-30.pdf]
