NIST CSF Overview: Respond

This blog post is about Respond, one of five "pillars" of the NIST CSF. This blog post is one of a series of posts, one per pillar.

Here links to the other posts in this series: Identify Protect Detect (Respond) Recover.

What is the NIST CSF and why does Pythia Cyber use it? The NIST CSF is the cybersecurity Framework (CSF) put out by the National Institute of Standards & Technology (NIST) when designing and implementing a custom Cybersecurity Program (CSP). Pythia Cyber is guided by the NIST CSF for programs that are the modest first steps of new or small organizations, for programs that are formal, rigorous programs for mature, mid-sized organizations, and for programs anywhere in between.

The NIST CSF mantra is simple: Identify, Protect, Detect, Respond, Recover. But this overview is also very abstract. So this blog post is one of a series to make these concepts a bit more concrete.

As we covered in the first post in this series (follow the "Identify" link above), the Identify pillar gives us a list of assets (what we are protecting) and for each asset, a risk (what we are trying to avoid). In the second post in this series we saw that the Protect pillar assigns a control to each risk and defines evidence that validates each control. In the third post in this series, we learned that the Detect pillar defines the process and the personnel who collect evidence about how well (or how poorly) the controls are working.

Both the Respond pillar the Recover pillar are unlike the other three, they are triggered by an incident and different from the other steps because the other steps are part of normal operations. Respond and Recover also always happen in tandem, which is why we group them together as part of the Incident Response Plan (IRP).

The IRP formalizes incident handling, so that everyone knows what their role is in advance. The IRP covers both the Respond step (halting the problem and trying to restore normal operations) and the Recover step (undoing as much of the damage as possible, preventing a recurrence). The IRP gives us a Respond checklist, a Recover checklist, a review process which looks backward at what happened (the Incident Report) and which looks forward to improvements (the Recommendations).

What distinguishes Respond from Recover is the time frame: Respond is always urgent, perhaps even emergent. This is why the part of the IRP dealing with Respond is so important: in a crisis, people fall back on what they know. With a good IRP, everyone knows the following about the Response:

1. Who is in charge of what; this is crucial to acting with both rapidity and effectiveness.
2. Who is part of the response and who is not: too many cooks in the kitchen is a problem to be avoided
3. What the lines of communication are: you need a quick, authoritative and correct answers

In the real world, the IRP will not solve every problem, nor will it answer every question. Every incident is a learning experience. The goal is to avoid re-learning what you should already know and to avoid learning things you could have foreseen.

In particular, Respond is not a good time for philosophical debates about the relative value of, say, getting back to normal operations versus ensuring that the incident does not reoccur. This is part of the reason that it is so useful to know who is in charge of what: when Ops screams for uptime and Cybersecurity demands downtime, someone has to avoid deadlock by making a decision.

Responding to an incident is unpleasant, but it does not need to be a stomach-churning nightmare. You can plan ahead and make this situation as painless as it can be--and Pythia Cyber can help with both the planning and avoidance of unnecessary pain.