In my previous posts, we explored how to identify, protect and implement detection measures established in the NIST Cybersecurity Framework (CSF). Throughout this series, we’ve been noting how any IT and IT security team can implement the NIST CSF with deliberate and tangible steps that improve their security posture. The framework consists of what I call ‘pillars’ and this installment is about the fourth pillar: Respond.
Once the first three pillars are established—identify, protect, and detect—we come to a point where reality gives us a cold splash and we realize we don’t live anywhere close to Utopia. Things fall apart, disasters strike, and technology falls from order to disorder. Thankfully, the NIST CSF enters the stage in this narrative with a set of tactics and procedures that can help anyone become more adept at responding to IT crisis. Just as with every other pillar in the NIST CSF, the Respond pillar can be achieved with a set of sub-goals:
- Response Planning
Let’s take a look at each.
NIST CSF states: Response processes and procedures are executed and maintained, to ensure timely response to detected cybersecurity events.
In a very real sense, the present moment is all that exists. The past was and the future may be but the only thing you can point to and say, “This is” is the present moment. Often, this reality becomes erroneously applied to planning. “I don’t know what the future holds and it isn’t necessarily going to mirror the past, so I should simply wait and see what happens.”
This is the opposite of having a bias to action. Most of the time, the present moment calls for robust planning and maniacal focus on what needs to happen when things fall apart. Notice how the NIST CSF provides guidance for planning and presumes processes and procedures are already up-and-running. An essential part of the response planning is to step back and measure the effectiveness of the current methods. These honest questions give rise to answers which are the inputs of the planning process.
In every conversation I have with IT and IT security teams, answering the following five questions has always provided the focus and robustness that goes into any response plan. They are:
- What could happen?
- What should happen?
- What would happen?
- What is happening?
- What did happen?
Each of these questions demand answers that give a high accuracy of what needs to go into your response plan. The first question (What could happen?) provides the answer of your security posture. Knowing where you currently sit is important to your response plan because it shows you where your weaknesses are. These weaknesses—whether few or many—give you the opportunity to have an honest appraisal of the posture. If I understand my posture (how I am positioned) in a combat zone, it awakens me to the directions and steps I can take to improve the likelihood of survival. IT security posture is no different. But it takes intestinal fortitude to stare at the current situation and say, “This is what is”. You will be liberated from folk wisdom and best guesses with this honest, fact-based understanding of your security posture.
The second question (What should happen?) speaks to your security policy. Security policy is the bedrock of all security efforts, because it says, “This can do that. That cannot do this”. Though this may seem reductionistic, when each policy is examined, they all end with this structure: what is allowed and what is not. The third question (What would happen?) gives you the space for security modeling.
Security modeling does not have to take place inside of clever apps with squiggle lines and enhanced visualizations. It may simply consist of imagined outcomes from proposed policy changes or control settings. Irrespective of the tools used, having this model in place shows you the counterfactual situations and project variations so you can isolate the influential factors. Sound familiar? This is what we call “experimentation”. Technology can be pressed into service, in the case of visualization, or you may choose thought experiments to do the job. Either way, modeling will give you a picture of what would happen under a particular set of circumstances.
The fourth question (What is happening?) once again forces us to fearlessly look at the current happenings in the network, within devices, across IoT, and the always vulnerable endpoint. This is the security monitoring aspect of response planning. By monitoring the effects of the policy and current environment, you have the opportunity to discover anomalous activities and have a well-calibrated response. At last, we come to the final question (What did happen?) which gives us a repository of previous events that serve as vital inputs to response planning. Here we sit with a gold mine of information about previous events and can determine what brought down the ship. This is security investigations that allow us to take a hard look at the facts and assess their likelihood of a repeat occurrence.
By answering the five questions, you have the necessary inputs to your response planning. Notice how the focus shifts from ethereal, loose projections into fact-based, quantitative, data-driven, statistically understood knowledge of what needs to happen when things go sideways.
NIST CSF states: Response activities are coordinated with internal and external stakeholders, as appropriate, to include external support from law enforcement agencies.
There is a parable about how thoughts and words must pass through three gates on their way to being uttered. Each gate has a guard standing ready with a question. The first guard asks, “Is it true?” The second guard asks, “Is it helpful?” The third guard asks, “Is it necessary?”
When all three guards are satisfied, communication is free to flow. Now, why would I tell you this parable? Because when it comes to communications during an security event, the three guards and their attendant questions serve us well. Rather than saying, “Everything is falling apart” when an incident comes your way, the first guard requires that your communication is honest. Is everything truly falling apart? Unlikely. State what is, give the facts and be honest. The second aspect of response communication is all about the second guard in the parable. What is communicated needs to be “coordinated with internal and external stakeholders” the NIST CSF politely explains. This means that the communication needs to be helpful. The only way to determine the helpfulness of event communication is by seeing if the information shared was coordinated with stakeholders. To coordinate is to be helpful. Finally, the third guard and question come into view. At times, a security event can be damaging enough to communicate to law enforcement. This is the ‘necessary’ aspect of communication.
When we answer the three questions, we find that communication methods start to take on a new life. They are pithy, expressive, detailed, and voided from evocative statements. You will see that NIST CSF illustrates these principles within the sub-goals of communication.
- Personnel know their roles
- Events have been consistently reported
- Information is shared in lockstep with the response plan
- Coordination is aligned with the response plan
- Voluntary outward communication is shared when necessary
NIST CSF states: Analysis is conducted to ensure adequate response and support recovery activities.
The analysis portion of the program is goal-directed, rather than a reflex to what appears to be a tragic security event. Look at the two assurances: adequate response and support recovery. When analyzing what happened, it is not an intellectual or academic exercise. We’ll leave that for the historians with more time to comb through the wreckage. IT and IT security teams need analysis that serves the goal to have a response that is tuned to the situation and supports efforts to recover.
Don’t waste time. If you are anything like me, you are excited by the prospect of learning something new, of discovering new ideas, and the chance to reverse engineer how things work. However, this natural curiosity (which many reading this may have in droves) is not aimed to satisfy the NIST CSF. It comes from a congenital sense of rationalizing the world. But this does little to ensure an adequate response or support recovery.
Instead, consider analyzing in the same counterfactual game we played when implementing security modeling. In this response scenario, we can model what actions would lead to a satisfactory response and expedite recovery. Rather than looking for root causes, the NIST CSF steps into the practical realm of resolving issues quickly. If there is a fire in your home, it would be imprudent to search for the source and determine if your home’s wiring was the culprit. Further still, it would be a colossal misappropriation of resources if when the firefighters arrived, you solicited their assistance to find the initial spark while the home is burning. There will be plenty of time to reverse engineer the causes, seek the explanation, and model new systems to prevent similar incidents.
For now, analyze with the goal in mind: adequate response, support recovery.
NIST CSF states: Activities are performed to prevent expansion of an event, mitigate its effects, and eradicate the incident.
Seeing as we derive many of our English words from Latin origins, it is only natural to see the appearance of Latin forms in the directives of IT and IT security management. What do we really mean when we say, “mitigation”? Well, here is where the sub-goals of the NIST CSF come to the rescue to pull us out of an abstract word soup and help improve cybersecurity.
Mitigation is strictly speaking to reduction. To mitigate something is to reduce the severity of something in size or character. Reducing the severity of a security incident’s size is to halt the spread of vulnerable resources. In order to stop the spread, we have to hop in the time machine and go back to the first two pillars of the NIST CSF. To prevent the expansion of an event requires that we identify the IT resources that could be sitting ducks. We cannot know this without robust asset intelligence. Once we have identified resources through asset intelligence, we can move on to second pillar: Protect. If we are to know the directions the incident could spread, it is inherent that we know which protective measures are currently in place to shield those resources from becoming infected.
The pillars of the NIST CSF do not line up like boxcars on a track, but are woven together like a braided rope to ensure strong cyber resilience. Once the potential expansion is understood, we can swiftly take actions to foreclose that opportunity. This comes in the form of isolating infected systems, removing communication, block port accesses, and even locking an endpoint with remote command. These actions mitigate expansion and damaging effects because the attack surface has been narrowed to include only those points of compromise. Once isolated, we can examine the current state of the compromise and take action at that point in space-time to reduce risks; the ultimate goal of mitigation.
NIST CSF states: Organizational response activities are improved by incorporating lessons learned from current and previous detection/response activities.
One of the wisest men I’ve known told me that a mistake is only a mistake if you didn’t learn anything from it. Without pointing fingers or trying to locate a villain, improvements come from retooling our knowledge and charting a better course forward. Now comes the moment for cogitation and root cause analysis. What happened? What would have happened if X was different? If we changed X, would that reduce the risk of reoccurrence? Now that we’ve decided to change X, where could our reasoning be flawed? What would make us change our minds?
This collective introspection gives you the opportunity to cast doubt on assumptions and follow the method of learning that is empirical and verifiable. The post-event learnings feed right back to the top of the response planning phase. We now have a new input to signal if our security posture, policy, modeling, monitoring, or forensics are vulnerable. By repeating the process, IT and IT security operations are much more agile. But it takes still more intestinal fortitude to hold ideas as hypotheses to be tested, rather than treasures to be guarded.
Without this recognition that ideas must be tested against reality, we will never learn anything. Don’t become attached to a method, control, setting, or procedure. When these are all subject to falsification and revision, we built a safer and more resilient cyber world.Using NIST CSF, we can halt the spread of security events and we can learn from the bruises that indicate we have fallen down. Click To Tweet
No one wants to see a security incident. On a personal level, I find it morally pernicious to steal what doesn’t belong to you. But we live in a world where there are plenty of people who want what you have: information. When information is stolen or the means of processing information is enslaved (e.g. ransomware, cryptomining), we have an imperative to plan for these scenarios. We benefit from communicating with honest reflection. We can understand and respond appropriately when our analysis is directed to those ends. Using NIST CSF, we can halt the spread of security events and we can learn from the bruises that indicate we have fallen down.
We don’t live in Utopia. But with careful and deliberate application of the NIST CSF, we can become more adaptive to this imperfect world. We can become resilient.
In a 2018 Absolute survey, IT and compliance professionals weighed in on their efforts to implement the five pillars of the NIST Cybersecurity Framework. See the infographic for how do you stack up. And, gather insights and learn how to avoid implementation pitfalls with our recent webcast Nailing It! 5 Ways to Win with the NIST Cybersecurity Framework with Josh Mayfield and Forrester analyst Renee Murphy.