The dreaded risk assessment

I have spent a good bit of my time over the past few months helping customers with risk assessments. Since many of the major regulatory frameworks, including HIPAA, PCI, and SSAE 16, all call for them, organizations have been forced, some kicking and screaming, to engage in reviewing their risks. 

Many companies treat the requirement for a completed risk assessment as a an exercise in “papering the file” – it must be done, so get through it as fast as possible, put it on file, and move on to something important. I don’t find this surprising, given that the guidance provided as part of the requirements is either minimal, or impossibly confusing. For example: HIPAA Section 164.308(a)(1)(ii)(A) has only 23 words on the subject; PCI 12.1.2 has 15; and SSAE 16 makes only general references.

A simple Internet search on the subject provides a wide variety of responses, many of which are quite complex. As an example, “Harmonized Threat and Risk Assessment,” which I use as a basis for much of my methodology, is 290 pages. To make matters more confusing, various standards for risk assessment exist, including OCTAVE, ISO 27005, and NIST SP-800-30. A risk assessment can clearly be an intimidating process.

While I realize that performing a risk assessment is less fun than a visit to the dentist, it can be an essential and relatively painless process. 

Let’s start with defining “risk” in this context. According to the PCI DSS Risk Assessment Guidelines, risk is “a function of the likelihood of a given threat-source’s exercising a particular potential vulnerability and the resulting impact of that adverse event on the organization.”  This may seem like a rather nebulous definition, but it contains the key elements involved in assessment of risk: 

Threat – put simply, something bad that might happen. A threat generally cannot be prevented. It just exists, and therefore must be addressed. 

Threat Source – the “actor(s)” that generate a threat. A threat source is not necessarily a person; it could be an act of nature. 

Vulnerability – a weakness or exposure that might be exploited by a threat. This might be a software design failure, access control error, or anything that might serve as window through which a threat might “jump.”  Generally, a vulnerability can be eliminated or mitigated in some way. 

Asset – the things we must protect from threats. This is a broad term, including systems, people, data, or anything of value to an organization. 

A risk assessment therefore, identifies risks generated by the possibility of threats acting on vulnerabilities, and what can be done to mitigate each one. Formal risk assessments come in two flavors: quantitative – involving specific dollar estimates resulting from any risk being realized; and qualitative – involving the use of scoring to rank order risks, without attempting to specifically quantify the dollar loss. Most organizations attempting to comply with HIPPA, PCI, etc will perform a qualitative assessment, because they find it genuinely impossible to arrive at an accurate dollar figure. 

With these simplified definitions in mind, we can lay out a practical process for assessing risks qualitatively.

Identify your assets

What “things” do you have that, if compromised, would cause harm to your organization? List them, along with appropriate details, like location and owner. In the case of organizations with many assets, I like to aggregate them for a risk assessment. For example, if you have four web servers splitting traffic for an eCommerce application, you can treat the four as a single asset. 

Identify threat sources

What are the “actors” that can produce a threat. As I said above, this can be, but is not limited to, people. Sources can include hackers, the government, competitors, etc. List them. 

Identify threats

From your list of sources, you can begin to identify your threats. Think broadly here, because this can include a wide variety of potential issues. Some examples include fraud, server failure and loss of utilities . List your threats, and link them to the related source(s). 

Vulnerabilities

Thinking about your list of threats, consider what occurrences (intentional or accidental) could take advantage of them to cause harm to your organization. Again, this is a broad category, and can include intentional and unintentional situations. Examples include change control failure, or phishing attack. List them, and tie them to one or more related threats. 

Score the results

There are various means of scoring threats and risks. I like to use a four point scale, with one being a minimal issue, and four being critical. I score each threat using this scale for likelihood (what is the realistic chance of that threat impacting the organization), and then impact (how bad it would be if the threat occurred). I average the two, do the same for vulnerabilities, and then average the score for a vulnerability with the highest score for a related threat. The result is the risk score. 

While everything with a non-zero score is a risk, the items with a risk score of 1 or 2 generally do not have to be specifically addressed. Anything with a 3 or 4 needs to have a mitigation plan established. This simply identifies how you plan to address the risk. This can involve a technical or policy change, or can simply be the statement that the organization will accept the risk, since there is no practical mitigation strategy. Items with a risk score of 4 should be addressed immediately, as they represent an eminent and significant threats. 

Once complete, the process should be updated at least yearly, although I recommend making this a living process, to be evaluated and updated continuously. 

Bottom line – if you must comply with any of the regulatory standards, a risk assessment is a requirement. Rather than seeing it as a necessary evil, treat it as the useful process it can be.