Using NIST 800-30 To Understand Your Threats

I’ve been getting asked about risk assessments lately. One of the big ones that comes up is NIST 800-30.

As you start implementing or addressing risk assessment questionnaires for your clients (trust me—if you haven’t started getting them, you soon will), I want you to be prepared to think about their threats.

Before you address threats, you will need to identify the scope of your assessment.

Why are you performing it? Is it to evaluate specific criteria to satisfy a compliance pressure? Or that of a contract? By first understanding why a risk assessment is needed will help you understand how to tackle it.

Once you understand its purpose, you will want to understand what is within your scope.

How much of your organization will be evaluated? Are there any specific technologies you are focusing in on? The scope of your assessment will help you craft recommendations based on your analysis and provide you with priorities to address. You will also lay down specific assumptions for which to conduct your analysis.

As you finalize your scope, you may ask for supplemental information with which to support claims within the report that may not be explicitly tested or evaluated. This information may help focus what specific threats are the most important within the environment.

The meat of your assessment will come from addressing the threats specific to that environment.

This is where you actually start conducting your assessment. Address the threat sources relevant to your organization given the information you know about it.

You will subsequently identify vulnerabilities that are most susceptible to different threat types and prioritize fixes based on how probable you believe those threats to be.

In cases where there is not one clear fix, you may identify a strategy to deal with the threat in the event an event happened (i.e., a incident response table top exercise) or have other ways to mitigate the aftermath of a specific type of event.

Today I want you to think hard about threat sources impacting that environment.

I want you to list our threat sources, the reason behind a threat, what that threat is capable of doing and how to target or identify a threat before, during and after it happening.

I like to think of threats coming from four sources.

Adversarial—people who have malicious intent, whether internal or external. An adversarial event may be from a nation state, a cybercrime ring, or an internal person wishing to cause harm. Adversarial events are a very real possibility across your client base right now.

Accidental—these events are also human-induced, stemming from a mistake. Maybe a bug in software, or a misconfigured device that resulted in a less than ideal outcome for your organizational operations.

Structural—equipment failure or software failure are real scenarios today, especially as operations rely heavily on their networks.

Environmental—Mother Nature or infrastructure- based threats may put your organization at risk. The key will be to identify what specific environmental factors may impact operations.

Here is a list of threats that we see from NIST 800-30:

Once you’ve identified your list of threats, evaluate the likelihood of that threat given the context of your client and their network. Some threats may be low enough in occurrence that they are probably not worth discussing.

For each threat, I recommend determining whether the threat source could perceivably initiate a threat event. Identify the conditions or vulnerabilities that would need to be to see an event from that threat source. Then determine what the impact would be on the organization. Would it be a site-wide outage? For how long? Is this something your client would be able to tolerate? If not, this is probably a pretty serious threat to them.

The risk analysis is a good way to wrangle your client into an evaluation of their cybersecurity posture—primarily how their cyber stack response to adversarial threats. This is the perfect way to communicate risk to your client in a way that they’d understand. To see how a risk analysis would work, consider getting a free stack evaluation of your network.