.
Risk Assessments ("RAs") are so difficult to do that it is hard knowing where to start. However, let's start with the requirement as it is contained in the HIPAA Security Rule:
Risk analysis (Required) 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 or business associate.
The first thing to be noted is that the Security Rule ("the Rule" or "Rule") does not use the word assessment. We use assessment because that is how the industry has come to refer to this "Required" implementation specification, although in many ways "analysis" is a more accurate description. Like everything else in the Rule, the RA requirement is descriptive and not prescriptive. The Rule does not specify how you should go about conducting an RA. Neither does it make any reference as to the quality or rigor by which the RA should be conducted. It simply states that you should conduct one. It turns out that this is your "out" so to speak. In this regard the requirement states only that the RA should be "accurate and thorough." Perfection is not implied either directly or indirectly in the Rule. Further what "accurate and thorough" mean is left completely up to you to decide, taking into consideration the Rule's flexibility principles as contained in § 164.306 (e.g. taking into consideration the size, complexity and resources of your organization).
Because the Rule does not specify how to conduct an RA (or meet any other requirement for that matter) practitioners have looked for guidance wherever they could find it; not surprisingly almost everyone, including us, has gravitated to the guidance provided by the National Institute of Standard and Technology ("NIST") and specifically to NIST Special Publication ("SP") 800-30, appropriately entitled: Guide for Conducting Risk Assessments, which is the de facto gold standard that the healthcare industry has universally adopted. NIST's mission, in part, is to provide compliance guidance to all U.S. federal agencies, not just those that are required to comply with HIPAA. Therefore NIST SP 800-30 describes a methodology for conducting RAs that is industry agnostic. SP 800-30 could be, and is, used by many industries as a model for conducting RAs. NIST SP 800-30 describes a seven step process for performing an RA. We will use each one of these steps to discuss the complexity involved in each step along the way, and by doing so; a description of the overall complexity of the requirement emerges. Finally, at the end of this article, we will briefly touch on tools that are available to "reduce the pain" of conducting an RA, and in our view, the minimum feature set that these tools should contain.
Step 1 Gather Data
You must first gather data in order to document your "As Is" Operational Environment. What kind of data? Data that pertains to your Security Objects (e.g. your Operations, Assets, and Individuals)-it's an inventorying process of your entire organization, rather than just the hardware devices within it. We refer to this inventory as one consisting of Security Objects because these are the persons, places, and things that Security Controls are subsequently applied to, in order to reduce Risks to levels that are "reasonable and appropriate."
As you might imagine, even for small organizations, gathering this inventory will not be easy. This is true due to the following non-exhaustive list of challenges: (1) not all the inventory is located in one place or tracked in one application; (2) some of this inventory may not even exist and you will have to create it (e.g. inventory of everyone's phones, pads, etc. and inventory of pertinent building, rooms, and other spaces); (3) the volume of data to be gathered quickly grows "out of control" especially for mid-size organizations and larger; and (4) you are unsure how this inventory should be stored or maintained.
As difficult as Step 1 is, it is arguably not the most daunting individual step in the process.
Step 2 Gather Threats and Vulnerabilities
Step 2 requires you to gather Threats & Vulnerabilities ("T&Vs") that pertain to your Operational Environment...which you will subsequently associate with Security Objects. First, unless you are an information security professional you likely will start to "pull your hair out" if you haven't done so already. Even experienced IT hands will be pulling their hair out because information security ("InfoSec") is a narrow and highly specialized IT discipline.
Most of us may understand T&Vs as abstractions but would have no idea: (1) where to look for them; (2) how to capture them; (3) how they are defined in practice; or (4) how to subsequently apply them to Security Objects as part of an RA.
With Step 2, we are not necessarily overwhelmed because of "volume" but rather we become cognitively distressed because our basic lack of subject matter expertise becomes manifest (i.e. we realize that we do not know what we are doing).
Step 3 Assess Existing Controls
Step 3 requires you to assess your current Security Controls and minimize or eliminate risks to ePHI based on well-functioning Security Controls that already exist within your Organization. To a large degree Step 3 assumes that you have done a good job of gathering inventory in Step 1. Otherwise you are not going to have the foggiest idea what Security Controls you may already have in place. All organizations have some Security Controls in place (e.g. passwords). However, this step requires you to gather what you have so that you can apply them to subsequent Risks that are identified during this RA.
Again, unless you are an InfoSec professional, you probably have no idea what a Security Control looks like in practice, let alone the ability to "gather them." You are likely to experience the same kind of cognitive dissonance that you did in Step 2 (i.e. you are in way over your head and you know it).
Step 4 Identify T&V Pairs & Likelihood of Exploitation
Step 4 requires you to determine the likelihood that a specific Threat will exploit a particular Vulnerability- that is, review Threat/Vulnerability "pairs" that are relevant to your Operational Environment and assign a subjective likelihood value (i.e. High, Medium, or Low) that the Threat in question will actually exploit its corresponding Vulnerability.
You must first identify T&V pairs. This means that a specific Threat must be associated with a specific Vulnerability. However you should also know that a specific Threat is capable of being associated with multiple Vulnerabilities and conversely a single Vulnerability can be paired with multiple Threats.
Identifying the respective T&V pairs is no small feat for the following reasons: (1) lack of the necessary fundamental understanding of Threat and Vulnerabilities, let alone how they are paired; and (2) lack of enabling technologies available to "physically" perform said pairing (i.e. assuming that you do indeed know what you are doing).
In short, you were likely overwhelmed a few steps back, but if you have persisted thus far you begin to wonder how it is you are going to pull all of this information together in a reasonable way in such a manner that allows you to continue with the RA. In other words, you are likely to realize that you are in "spreadsheet hell" and the words from Dante's Inferno become a recursive loop in your brain: "Abandon all hope all ye who enter here!"
Step 5 Calculate the Impact
Step 5 requires you to calculate the Impact that an Exploitation will have on your Operational Environment (i.e. the business Impact). The Impact measure encompasses the magnitude of harm that is likely to result from the unauthorized access or destruction of ePHI (i.e. to the confidentiality, integrity and availability of the ePHI) and the economic and/or reputational loss to the Organization resulting from the Impact.
This step requires you to answer the question assuming a specific Threat does Exploit a specific Vulnerability, what would be the resulting Impact to your organization. Impact, under the NIST model, can be assigned a subjective value of High, Medium, or Low. The same holds true for the probability that a Threat will Exploit a Vulnerability.
This step mandates that you "think hard" about the potential harm that occurs when "bad stuff" happens. For example will your entire Operational Environment be Impacted (e.g. in the case where Katrina strikes) or will only a minor application be affected?
Step 6 Calculate the Risk
Step 6 requires that you determine the level of Risk associated with a Threat/Vulnerability pair, taking into consideration the Impact to the Organization-remember that any given Threat is capable of exploiting one or more Vulnerabilities and vice versa. Once Threat/Vulnerability pairs are identified, then a specific Risk level is "calculated" as a function of the probability of a Threat exploiting a specific Vulnerability and the Impact that the Exploitation is likely to have on your Operations.
Again, under the NIST methodology it is recommended that you assign a subjective value to this calculation of High, Medium, or Low. It is counterintuitive but this step is relative straight-forward once you have managed to plow through all the preceding steps. By now you are a veteran (with the scar tissue to prove it) and some of the cognitive dissonance is dissipating.
However, despite your veteran status, you may still be facing the daunting task of making thousands of Risk calculations.
The following graphic depicts how an individual Risk is calculated.
Step 7 Document New Security Controls
Step 7 require you to document new/modified Security Controls that help mitigate identified Risks to levels that are "reasonable and appropriate" for your Organization. This step only includes identification of Security Controls-evaluation, prioritization, modification, and implementation of Security Controls identified in this Step are part of the Risk Management standard.
One of the challenges in this step is to determine what "reasonable and appropriate" means. Although these are terms of art in the HIPAA regulations, do not expect to find them defined anywhere. Your organization will have to decide, for a given RA: (1) which Risks that were identified during this iteration will be "attacked," given budget and resource constraints; and (2) which Security Controls will be attached to those Risks to bring them down to levels that are reasonable and appropriate.
Tools that Help Reduce the Pain
There are number of tools available in the marketplace, including the upcoming release of Expresso (see overview video below), that purport to help reduce the pain associated with RAs. The key point here is "reduce the pain" and not "eliminate the pain" or make an RS "easy." The latter is snake oil pure and simple. It defies reason that a process as complex as an RA can be reduced to "simplicity." No one with any business experience at all buys that nonsense. However, a reduction in pain is a reasonable objective. Just like QuickBooks Online ("QBO") online reduces the pain associated with manually keeping a set of books. QBO does not eliminate the pain of accounting, it simply reduces it, makes it tolerable, and if you appreciate the reduction in pain maybe even fun (especially if you don't have to pay a CPA to do the day-to-day work)!
So here is a short list of a minimum feature set for an RA tool (in no particular order): (1) it must allow for bulk import of Security Objects (people, places, and things that Security Controls are applied to); (2) it must come pre-populated with known threats and vulnerabilities to allow for easier pairing of the two; (3) it must allow Security Objects to be categorized via a user defined taxonomy so that Controls can be applied at various levels of classification; (4) it must allow for retaining instances of past RAs for reporting purposes; (5) it must allow for tracking the results of the Security Controls applied in the remediation step; and (6) it should be based on an authoritative methodology (e.g. NIST SP 800-30) so as to meet regulatory compliance objectives.
|
ACO regulations are inherently complex. ACOs require a complete understanding of these regulations because the Medicare Shared Savings Program regulations determine how an ACO gets paid. This training is divided into three sections to make it easier to understand. Session One is all about eligibility and the application process. Session Two discusses the regulatory basis for quality performance standards and Session Three covers pay for performance and revenue tracks.
