What a whirlwind the past few months have been for data security, breaches and hacking events. From the Wyndham v. FTC ruling to yet another breach by a BCBS affiliate, there is increasing pressure across the information security industry to push organizations to perform those pesky security risk assessments touted by the National Institute of Standards and Technology (NIST).

No matter what country you are based in, odds are your client’s data touches, passes through, or sources from the United States. Given that, if you have not performed a security risk assessment pursuant to the NIST guidelines, now is the time.

For those of you not familiar with NIST, it draws its funding from the U.S. government and traces its origin back to 1821 (yes, really). The goal of NIST is to research, develop, standardize and push innovation forward across a broad swath of fields for the betterment of everyone, at no cost (other than taxes) to anyone.

One of NIST’s best and most useful documents is its Guide for Conducting Security Risk Assessments. The security risk assessment procedures and guidelines outlined in this document now serve as the foundation for many industry standard risk assessment methods across a wide array of fields and industries. Because why reinvent the wheel?

If you can have the risk assessment playbook the government paid NIST to create telling you how to assess risk in your organization, why not use it?

SECURITY RISK ASSESSMENT

At the core of every security risk assessment lives three mantras: documentation, review, and improvement. Security risk assessments are only as valuable as the documentation you create, the honest review of the findings, and ultimately the steps towards improvement you take.

The goal of performing a risk assessment (and keeping it updated) is to identify, estimate and prioritize risks to your organization in a relatively easy-to-understand format that empowers decision makers. With that in mind, here is a break down of a NIST Security Risk Assessment framework that would be appropriate for a targeted risk assessment (as opposed to enterprise-wide).

For each of the steps listed below, track the results in a multi-page spreadsheet, and this document will serve as the root for further analysis.

1. Baseline the System – Create a lifecycle chart of all the data within the targeted technology or program; encompassing birth, use, and destruction.
   
2. Identify Threats – All of the threats you can imagine including intentional, unintentional, technical, non-technical, and structural. After you have made this list, cluster the threats into similar types (i.e. Non-Technical Threat – Fire, Flood, or Blood Events).
   
3. Identify Vulnerabilities – All of the Vulnerabilities your organization has, including: patches, policies, procedures, software, equipment, etc. It often helps to group these Vulnerabilities to more easily analyze them (i.e. Vulnerability – Un-patched Servers/Workstations).
   
4. Current Controls – All of the security and privacy controls you have in place to protect against the Vulnerabilities.
   
5. Likelihood of Impact – Assign a value from low to high (e.g. – .1, .5, or 1) of how likely it is that a Threat hits a Vulnerability. Here, pair each cluster of similar threats and with your major groups of vulnerabilities to create an Impact pairing.
   
6. Effect of Impact – Assign a value from low to high (e.g. – 10, 50, 100) of how bad the Impact would be on your organization if the Threat hit a Vulnerability.
   
7. Risk Determination – Likelihood x Impact = Risk Level (0-33 = Low; 34-66 = Medium; 67-100 = High)
   

At the end of this process, you should have a spreadsheet that contains sortable columns of Impact pairings and their associated Risk Level. This will allow you to sort and parse the list in a way that gives you an easy view of those items with the greatest Risk Level, thereby creating a targeted list of what threats and vulnerabilities must be addressed first. Here is an example:

TARGETED SECURITY RISK ANALYSIS – HOSPITAL CLIENT PHI DATABASE

1. Simple Baseline: Client PHI is entered, accessed, and stored within hospital EMR.
   
2. Technical Threat: Malicious hackers attempting to gain access and steal PHI.
   
3. Vulnerability: Un-patched Windows 2012 Server with default administrative password.
   
4. Current Controls: Password protected, behind firewall with factory settings.
   
5. Likelihood: .8 (Un-patched software accounted for the vast majority of breaches in 2014)
   
6. Impact: 100 (Loss or theft of PHI would catastrophic for a hospital)
   
7. Risk Determination: .8 x 100 = 80 (High Risk)
   

POST ANALYSIS BREAKDOWN

As you can see, the organization that produced the above analysis would need to immediately prioritize a Risk Determination of 80, especially on something so basic as maintaining patch updates. That aside, once you have completed your Security Risk Assessment and prioritized your Risk Determination list, turn to the Current Controls and make decisions of how to improve those controls to eliminate or mitigate the identified vulnerabilities.

Once you document those decisions, draft a summary of the Security Risk Assessment highlighting surprises, problems, fixes, and future plans. As you implement any changes, be sure to append the Security Risk Analysis, or if enough wholesale changes are made, perform an updated Security Risk Assessment.

This process seems daunting, and it can be. That said, once you have gone through the pain of doing it once, successive assessments will be quicker, more detailed, and serve to build upon what was done before. There are also third party tools that can streamline the process, such as the HHS Security Risk Analysis Tool created in conjunction with NIST. These third party tools vary wildly in quality, so choose wisely.

Whatever risk analysis process you choose, create, or purchase, make sure it fits your needs and gives you the documentation you want, the capability to thoroughly review results, and the tools necessary to make improvements.

Prepare now, or answer later when the investigators come knocking.

Via: tripwire