Americas

  • United States

Asia

Oceania

Contributor

The dreaded risk assessment

Opinion
Oct 14, 20155 mins
IT LeadershipSecurity

How to survive and benefit from the risk assessment process

nothing to fear thinkstock
Credit: Thinkstock

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.

Contributor

Robert C. Covington, the "Go To Guy" for small and medium business security and compliance, is the founder and president of togoCIO.com. Mr. Covington has B.S. in Computer Science from the University of Miami, with over 30 years of experience in the technology sector, much of it at the senior management level. His functional experience includes major technology implementations, small and large-scale telecom implementation and support, and operations management, with emphasis on high-volume, mission critical environments. His expertise includes compliance, risk management, disaster recovery, information security and IT governance.

Mr. Covington began his Atlanta career with Digital Communications Associates (DCA), a large hardware/software manufacturer, in 1984. He worked at DCA for over 10 years, rising to the position of Director of MIS Operations. He managed the operation of a large 24x7 production data center, as well as the company’s product development data center and centralized test lab.

Mr. Covington also served as the Director of Information Technology for Innotrac, which was at the time one of the fastest growing companies in Atlanta, specializing in product fulfillment. Mr. Covington managed the IT function during a period when it grew from 5 employees to 55, and oversaw a complete replacement of the company’s systems, and the implementation of a world-class call center operation in less than 60 days.

Later, Mr. Covington was the Vice President of Information Systems for Teletrack, a national credit bureau, where he was responsible for information systems and operations, managing the replacement of the company’s complete software and database platform, and the addition of a redundant data center. Under Mr. Covington, the systems and related operations achieved SAS 70 Type II status, and received a high audit rating from the Federal Deposit Insurance Corporation and the Office of the Comptroller of the Currency.

Mr. Covington also served as Director of Information Technology at PowerPlan, a software company providing software for asset-intensive industries such as utilities and mining concerns, and integrating with ERP systems including SAP, Oracle Financials, and Lawson. During his tenure, he redesigned PowerPlan's IT infrastructure using a local/cloud hybrid model, implemented IT governance based on ITIT and COBIT, and managed the development of a new corporate headquarters.

Most recently, Mr. Covington, concerned about the growing risks facing small and medium business, and their lack of access to an experienced CIO, formed togoCIO, an organization focused on providing simple and affordable risk management and information security services.

Mr. Covington currently serves on the board of Act Together Ministries, a non-profit organization focused on helping disadvantaged children, and helping to strengthen families. He also leads technical ministries at ChristChurch Presbyterian. In his spare time, he enjoys hiking and biking.

The opinions expressed in this blog are those of Robert C. Covington and do not necessarily represent those of IDG Communications, Inc., its parent, subsidiary or affiliated companies.

More from this author