This is the second of a 3-blog series on Practical Cyber Resilience. In the first part, I covered the four key characteristics (or guiding principles) of cyber resilience. In this blog we will review the main objectives and 5-step Cyber Resilience Analysis methodology, as defined by the NIST Special Publication 800-160, Developing Cyber Resilient Systems.
Within the context of this framework, cyber resilience efforts should focus on four key goals: Anticipate, Withstand, Recover from incidents, and Adapt. Sometimes with different wording, these goals are included in most cyber-resilience definitions. But their meaning is always the same:
- Anticipate – maintain a state of informed preparedness for adversity.
- Withstand – continue essential mission or business functions despite adversity.
- Recover – restore mission or business functions during and after adversity.
- Adapt – modify business functions and/or support capabilities to predicted changes in the technical, operational, or threat environments.
Because cyber resiliency is a concern at multiple levels in an organization, the four goals are essential in providing linkage between various functions and levels of the organization such as program managers, mission owners or cyber defenders. These different audiences need to learn whether cyber resources for which they are responsible for, or which they depend on, are sufficiently resilient against advanced cyber threats and, if not, what can be done to improve resiliency.
To help achieve the goals, NIST provides a structured approach in the form of the cyber resiliency analysis process. In developing this process, NIST leveraged previous work done by MITRE : The Structured Cyber Resiliency Analysis Methodology (SCRAM). Both methodologies rely on five key steps:
- Understand the context
- Establish the initial cyber resiliency baseline
- Analyze the systems
- Define and analyze specific alternatives
- Develop recommendations
Each step focuses on a specific problem:
Step 1: What do we care about? This step establishes the purpose of the cyber resiliency analysis. Those performing the analysis and the stakeholders who will use the results of the analysis must establish a common understanding of the context. They must agree on what information will be provided to analysts and on what will be assumed. They also must identify factors that constrain the selection of cyber resiliency solutions.
Step 2: What can we build on? As I mentioned in a previous blog, cyber resiliency overlaps with cybersecurity but also with other business continuity planning efforts. Activities in this step establish a baseline assessment of the system, which includes existing capabilities that can contribute to cyber resiliency.
Step 3: How do cyber risks affect overall business risks? Now is the moment to have a closer look at the business architecture (including systems architecture) to identify how advanced cyber attackers, by taking advantage of architectural and design decisions, could affect the business effectiveness. In other words, this is risk analysis.
Step 4: What could we do to improve cyber resilience? A wide variety of cyber resiliency techniques, with corresponding approaches and technologies, can be identified. Some of these will and some will not be feasible in the context for which the cyber resiliency analysis is performed. Activities in this step identify and analyze specific alternatives for improving cyber resiliency.
Step 5: What do we recommend? Cyber resiliency techniques are interdependent and interact with techniques for cybersecurity and business continuity. Thus, we need to analyze combinations of specific alternatives and provide potential courses of action. All of these in the context of the constraining factors identified earlier. This step produces recommendations consistent with the defined purpose of the cyber resilience analysis.
What is obvious looking at these steps is the criticality of stakeholder engagement. Program management office, user community, operations, security, all need to be engaged in various stages of the process. Without strong engagement of these stakeholders, the results of the analysis can easily become useless.
Not so obvious is the complexity hidden behind the five steps. To help on executing the process, NIST (and MITRE SCRAM) includes detailed activities that need to be carried out in each step.
While the diagram looks busy, keep in mind that this is a blueprint, a general approach that can and should be tailored for the needs of each organization.
In the final part of this blog series, I will cover approaches, techniques, and technologies to be considered when developing specific alternatives to improve resilience.