NIST Cybersecurity Framework: Third, Go Looking for Trouble

By: Josh Mayfield | 7/19/2018

Throughout this series, we’ve been exploring how a standard issue IT team can implement the NIST Cybersecurity Framework (CSF). Within the framework, there are five principle areas, what I call ‘pillars’, where IT and IT security teams can focus their attention to improve their cyber resilience.

We looked at the first two pillars—identify and protect—in previous posts. Here, we can zero-in on the next step to NIST CSF success: detect.

There are three focal points for the Detect pillar of the NIST CSF, and as we probe into the details of the framework, it is important to recognize three categories:

  • Anomalies and Events
  • Security Continuous Monitoring
  • Detection Processes

Think of it like this: In the domain of detection, anomalies and events are the what we are hunting for, security continuous monitoring is the when we are hunting for it, and detection process are the how we go hunting. The title to this post includes the phrase, “Go looking for trouble” and it’s an important distinction. In scouring the NIST literature, I have not found a demand for idleness; setting a few thresholds and watching the inbox fill up. Rather, to satisfy the NIST CSF Detect pillar demands action.

So, what are those actions?  Let’s take a closer look at the what, when, and how of looking for trouble under the NIST CSF.

Anomalies and Events

NIST CSF states: Anomalous activity is detected in a timely manner and the potential impact of events is understood.

Packed into this tightly wrapped statement are some key points to unravel. First, an anomaly is simply anything that deviates from what is standard, normal, or expected. This is why the first two pillars proudly stand at the front of the line. Because without identifying resources and then protecting them from would-be danger, we would never have a baseline from which we could determine if an activity is non-standard, abnormal, or unexpected.

Imagine you have an endpoint running a PHP process with a connection to an IP address in another country. Is it anomalous? Do we have a baseline? What is the endpoint’s hygiene status? Who is using it? Where is the device itself located? You see, without having visibility and control over this device, it is impossible to set an expectation for any activity, anomalous or otherwise. Secondly, we saw in the Protect pillar that cyber hygiene is the most effective baseline for decreasing cyber risk. The added benefit of a laser focus on hygiene is that anomalies are easier to identify and validate. When hygiene drifts, by definition, we have a deviation from the standard.

Our next stop on the journey to interpret the NIST statement is to understand the impact of security events, once identified. Now, this is where the insights of the physicist David Deutsch come in handy:

“Anything not prohibited by the laws of nature is achievable, given the right knowledge.”   

Understanding the potential impact of a security event comes from having the right knowledge. This is where asset intelligence comes to the rescue. Where is the device located? Is there additional behavior (machine or human) happening simultaneously? Is the current anomaly outside the bounds of security policy? What was happening on the device immediately before the event? Which data are at-risk, either by network connections or sensitive data saved locally? I could go on, but the point is that asset intelligence—intimate knowledge of the device, data, users, apps, and behaviors—allows us to satisfy the backend of this NIST CSF requirement.

This kind of asset intelligence must be indefatigable, unbreakable, and self-healing. We saw that without a constant stream of intelligence, we are unable to decide if an activity is anomalous. Further still, if we do not have a 360-view of the hardware and software we will be at a loss to understand the impact of a security event.

Anomalies and events get in the habit of springing out of nowhere. However, this is not an essential property of anomalies or events. They surprise us because we were not looking for them, which opens up the next segment of the Detect pillar of the NIST CSF.

Security Continuous Monitoring

NIST CSF states: The information system and assets are monitored at discrete intervals to identify cybersecurity events and verify the effectiveness of protective measures.

Once again, we have the opportunity to uncork the NIST CSF statement and see the sub-goals that bring us into alignment with the Detect pillar. Within the sub-goals of the NIST CSF Detect pillar we see the variables to monitor, and we can classify them into the categories of conditional and unconditional:

Conditional variables are factors that, under normal circumstances, do not generate cybersecurity events. Networks, physical environments, and personnel are a part of the organization’s fabric and provide measurable benefits when each has authorized access to data. However, each of these requires vigilance because their conditions can change and result in a cybersecurity event.

On the flipside, we have unconditional variables to monitor. These factors are, irrespective of circumstance, menaces to digital security. These include, malicious code, unauthorized software, personnel, connections, and devices, external service providers, and vulnerabilities.

Each of these unconditional variables create exposures to data confidentiality, integrity, and availability. Unauthorized software can corrupt datasets or degrade data integrity. Unauthorized personnel are, by definition, violating the principle of data confidentiality. Vulnerabilities and external service providers come with risk exposure within all three components of the CIA triangle.

To keep tabs on both conditional and unconditional variables, we come again to our baseline. This is where the Endpoint Hygiene Coefficient makes a repeat appearance.  In a previous post, I described this often-neglected security metric, where a score of “1” signals that each device is perfectly configured and operating in lockstep with security policy and standards. A score of “0” indicates that no device is aligned with security policy or conforming to the rules of the game.

Now, in the Detect pillar of the NIST CSF, we see how the conditional and unconditional variables play into our quest for pristine endpoint hygiene. When you incorporate each class of variables into your hygiene benchmark, you can more easily monitor security, because the variables that demand continuous monitoring are woven into the hygiene benchmark. As asset intelligence persists and extracts granular detail from each device, you become instantly aware of any changes to endpoint hygiene, which now includes conditional and unconditional cybersecurity variables.

This leads us to the final piece of the Detect pillar of the NIST CSF: detection processes.

Detection Processes

NIST CSF states: Detection processes and procedures are maintained and tested to ensure timely and adequate awareness of anomalous events.

We explored how anomalies and events serve as the what we need to detect and security continuous monitoring is the when we do our detection. Now, we can dive into the how we perform detection to satisfy the Detect pillar of the NIST CSF.

Specifically, NIST CSF calls for regular maintenance and testing for processes and procedures. Notice how playbooks, workflows, and forensic tactics are excluded from the framework. Why? Because businesses are like snowflakes: they are composed of the same material but arranged in their own unique ways. However, to maintain and test the effectiveness of any detection process, we can look at the components that go into that process and determine where there are gaps to address.

Roles and responsibilities. The status quo bias is hard to break. Left on our own, we humans have a tendency to continue current practices unless something provokes us to new action. To nudge us away from the status quo bias and replace it with a bias to action, we need to know what part we play in the grand narrative. Roles and responsibilities provide such a nudge.

Activities. NIST CSF moves beyond the roles and responsibilities of individual people and jumps headlong into a rigorous test to determine if activities are working. Often, we rely on folk wisdom and rules of thumb when judging whether a system is working. When we falsify our assumption of universal effectiveness, we open up a new world of possibilities to move closer to cyber resilience. Once activities are established, we have the opportunity to see if they work.

Testing.  This is where we benefit from treating ideas as hypotheses to be tested rather than possessions to be guarded.  The established detection processes are rooted in ideas of what would be most effective. These ideas are subject to testing and being falsified. Thankfully, detection processes lend themselves to such scrutiny, because detection processes are used daily and provide us with an ample sample size if these processes work.

Personally, my favorite metrics to track for detection signal how quickly we can find anomalies, how long we remain open to exploit (vulnerable), and how much of our environment harbors anything unauthorized.

  • Mean-Time-To-Discovery/Detection (MTTD)
  • Window of Vulnerability (WoV)
  • Authorized-to-Unauthorized (A/U) Ratio

First, MTTD is a helpful leading indicator of how quickly the detection process works to find cybersecurity anomalies and events. Next, the Window of Vulnerability (WoV) is an expression of how long it takes to mitigate a vulnerability after it has been disclosed. A time series that demonstrates a decreasing WoV is a strong indicator that detection processes are working. Finally, A/U Ratios will show the total share of computing activity that is happening with some authorized or unauthorized hardware, software, user, or connection. Again, a time series serves us best to see if our processes for detecting the unauthorized is improving.

Communications. The last mile of the journey to better detection is making sure we faithfully represent what has happened to appropriate parties. The core of communication is knowledge-transfer. When looking at your communication practices, you can ask, “Did knowledge successfully transfer from those who know to those who previously did not?” If  you find  there are hurdles interfering with successfully transferring knowledge, then it may be time to adjust the current practice.

In the domain of endpoints, one such communication tool is an Endpoint Risk Assessment (ERA).  A laptop has been stolen or compromised, check all the vitals, summarize the forensics, evaluate the risks, score the exposure, and communicate the information with simple documentation.


The Detect pillar of the NIST CSF can challenge many of our assumptions of what it means to be a threat hunter. First, we have to acknowledge that anomalies depend on a rational and secure baseline for any device. Once these endpoints are brought to a state of pristine hygiene, we have a greater opportunity to detect deviations from what is standard, normal, or expected.

Additionally, the Detect pillar pulls us away from the bias that focuses on malware, ransomware, DDoS, and other attacker tactics, techniques, and procedures. When we go looking for trouble, NIST CSF reminds us that conditional and unconditional variables require a laser focus. Often, we make the mistake by creating an extraordinary short list of what counts as trouble; we wait for indicators of compromise (IOCs) without adopting the NIST CSF mindset that pays special attention to indicators of exposure (IOEs). We must widen the aperture and this can be much easier than you think.  With streaming asset intelligence and a maniacal focus on endpoint hygiene, we can more readily see when drift occurs and exposures mount.

Finally, it is vital to iterate on the methods for trouble-finding. We may have strong opinions and decades of experience at cybersecurity detection, but NIST CSF shows us that all things are subject to testing and calibrating for greater effectiveness.

In our next installment, I’ll plunge into the fourth pillar of NIST CSF: respond. This cybersecurity discipline requires the framework unlike any other.  Because we simply do not experience it with the same frequency as identify, protect, and detect.  After all, when you have line-of-sight to identify assets, protection that persists from unbreakable control, and detection that keys on exposures when resources drift, then you don’t have as many opportunities to respond to cybersecurity events.

Because of all those security events you stopped in their tracks.

To learn more about the NIST Cybersecurity Framework and how to use it for improved security, listen to the webinar, Nailing it! 5 Ways to Win with the NIST Cybersecurity Framework with Josh and Forrester principal analyst, Renee Murphy.



Financial Services