NIST SP 800-160 Vol. 2 Rev. 1 日本語訳

NIST Special Publication 800-160, Volume 2

Revision 1

A Systems Security Engineering Approach

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-160v2r1

NIST Special Publication 800-160, Volume 2

Revision 1

A Systems Security Engineering Approach

RON ROSS

VICTORIA PILLITTERI

Computer Security Division National Institute of Standards and Technology

RICHARD GRAUBART

DEBORAH BODEAU

ROSALIE MCQUAID

Cyber Resiliency and Innovative Mission Engineering Department The MITRE Corporation McLean, VA

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-160v2r1

December 2021

U.S. Department of Commerce

Gina M. Raimondo, Secretary

National Institute of Standards and Technology

James K. Olthoff, Performing the Non-Exclusive Functions and Duties of the Under Secretary of Commerce for Standards and Technology & Director, National Institute of Standards and Technology

This publication has been developed by NIST to further its statutory responsibilities under the Federal Information Security Modernization Act (FISMA), 44 U.S.C. § 3551 et seq., Public Law (P.L.) 113-283. NIST is responsible for developing information security standards and guidelines, including minimum requirements for federal information systems, but such standards and guidelines shall not apply to national security systems without the express approval of the appropriate federal officials exercising policy authority over such systems. This guideline is consistent with requirements of the Office of Management and Budget (OMB) Circular A-130.

Nothing in this publication should be taken to contradict the standards and guidelines made mandatory and binding on federal agencies by the Secretary of Commerce under statutory authority. Nor should these guidelines be interpreted as altering or superseding the existing authorities of the Secretary of Commerce, OMB Director, or any other federal official. This publication may be used by nongovernmental organizations on a voluntary basis and is not subject to copyright in the United States. Attribution would, however, be appreciated by NIST.

National Institute of Standards and Technology Special Publication 800-160, Vol. 2, Rev. 1

Natl. Inst. Stand. Technol. Spec. Publ. 800-160, Vol. 2, Rev. 1, 310 pages (December 2021)

CODEN: NSPUE2

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-160v2r1

Certain commercial entities, equipment, or materials may be identified in this document to describe an experimental procedure or concept adequately. Such identification is not intended to imply recommendation or endorsement by NIST, nor is it intended to imply that the entities, materials, or equipment are necessarily the best available for the purpose.

There may be references in this publication to other publications currently under development by NIST in accordance with its assigned statutory responsibilities. The information contained in this publication, including concepts, practices, and methodologies, may be used by federal agencies before the completion of such companion publications. Thus, until each publication is completed, current NIST requirements, guidelines, and procedures, where they exist, remain operative. For planning and transition purposes, federal agencies may wish to closely follow the development of these new publications by NIST.

Organizations are encouraged to review draft publications during the public comment periods and provide feedback to NIST. Many NIST publications, other than the ones noted above, are available at https://csrc.nist.gov/publications.

National Institute of Standards and Technology Attn: Computer Security Division, Information Technology Laboratory 100 Bureau Drive (Mail Stop 8930) Gaithersburg, MD 20899-8930 Email: security-engineering@nist.gov

All comments are subject to release under the Freedom of Information Act (FOIA) [FOIA96].

The National Institute of Standards and Technology (NIST) Information Technology Laboratory (ITL) promotes the U.S. economy and public welfare by providing technical leadership for the Nation’s measurement and standards infrastructure. ITL develops tests, test methods, reference data, proof of concept implementations, and technical analyses to advance the development and productive use of information technology (IT). ITL’s responsibilities include the development of management, administrative, technical, and physical standards and guidelines for the cost-effective security of other than national security-related information in federal information systems. The Special Publication 800-series reports on ITL’s research, guidelines, and outreach efforts in information systems security and privacy and its collaborative activities with industry, government, and academic organizations.

NIST Special Publication (SP) 800-160, Volume 2, focuses on cyber resiliency engineering—an emerging specialty systems engineering discipline applied in conjunction with systems security engineering and resilience engineering to develop survivable, trustworthy secure systems. Cyber resiliency engineering intends to architect, design, develop, implement, maintain, and sustain the trustworthiness of systems with the capability to anticipate, withstand, recover from, and adapt to adverse conditions, stresses, attacks, or compromises that use or are enabled by cyber resources. From a risk management perspective, cyber resiliency is intended to help reduce the mission, business, organizational, enterprise, or sector risk of depending on cyber resources.

This publication can be used in conjunction with ISO/IEC/IEEE 15288:2015, Systems and software engineering—Systems life cycle processes; NIST Special Publication (SP) 800-160, Volume 1, Systems Security Engineering—Considerations for a Multidisciplinary Approach in the Engineering of Trustworthy Secure Systems; NIST SP 800-37, Risk Management Framework for Information Systems and Organizations—A System Life Cycle Approach for Security and Privacy; and NIST SP 800-53, Security and Privacy Controls for Information Systems and Organizations. It can be viewed as a handbook for achieving the identified cyber resiliency outcomes based on a systems engineering perspective on system life cycle and risk management processes, allowing the experience and expertise of the implementing organization to help determine how the content will be used for its purpose. Organizations can select, adapt, and use some or all of the cyber resiliency constructs (i.e., goals, objectives, techniques, approaches, and design principles) described in this publication and apply the constructs to the technical, operational, and threat environments for which systems need to be engineered.

Advanced persistent threat; controls; cyber resiliency; cyber resiliency approaches; cyber resiliency design principles; cyber resiliency engineering framework; cyber resiliency goals; cyber resiliency objectives; cyber resiliency techniques; risk management strategy; system life cycle; systems security engineering; trustworthiness.

The authors gratefully acknowledge and appreciate the contributions from DJ Anand, Jon Boyens, Nicolas Chaillan, Ramaswamy Chandramouli, Ken Colerick, Ed Custeau, Holly Dunlap, David Ferraiolo, Avi Gopstein, Suzanne Hassell, Bill Heinbockel, Daryl Hild, Scott Jackson, Linda Jones, Lauren Knausenberger, Ellen Laderman, Logan Mailloux, Jeff Marron, Cory Ocker, Rebecca Onuskanich, James Reilly, Thom Schoeffling, Martin Stanley, Shane Steiger, Mike Thomas, Beth Wilson, and David Wollman whose thoughtful comments improved the overall quality, thoroughness, and usefulness of this publication. The authors would also like to acknowledge the INCOSE Systems Security Engineering and Resiliency Working Groups, the Air Force Research Laboratory (AFRL), and the National Defense Industrial Association (NDIA) Systems Security Engineering Committee for their feedback on the initial drafts of this publication.

In addition to the above acknowledgments, a special note of thanks goes to Jeff Brewer, Jim Foti, Jeff Marron, Isabel Van Wyk, Eduardo Takamura, and the NIST web services team for their outstanding administrative support. The authors also wish to recognize the professional staff from the NIST Computer Security Division and the Applied Cybersecurity Division for their contributions in helping to improve the technical content of the publication. Finally, the authors gratefully acknowledge the significant contributions from individuals and organizations in the public and private sectors, nationally and internationally, whose insightful, thoughtful, and constructive comments improved the quality, thoroughness, and usefulness of this publication.

NOTICE: The Information Technology Laboratory (ITL) has requested that holders of patent claims whose use may be required for compliance with the guidance or requirements of this publication disclose such patent claims to ITL. However, holders of patents are not obligated to respond to ITL calls for patents, and ITL has not undertaken a patent search in order to identify which, if any, patents may apply to this publication.

As of the date of publication and following call(s) for the identification of patent claims whose use may be required for compliance with the guidance or requirements of this publication, no such patent claims have been identified to ITL.

No representation is made or implied by ITL that licenses are not required to avoid patent infringement in the use of this publication.

The goal of the NIST Systems Security Engineering initiative is to address security, safety, and resiliency issues from the perspective of stakeholder requirements and protection needs using established engineering processes to ensure that those requirements and needs are addressed across the entire system life cycle to develop more trustworthy systems.¹ To that end, NIST Special Publication (SP) 800-160, Volume 2, focuses on cyber resiliency engineering—an emerging specialty systems engineering discipline applied in conjunction with resilience engineering and systems security engineering to develop more survivable, trustworthy systems. Cyber resiliency engineering intends to architect, design, develop, maintain, and sustain the trustworthiness of systems with the capability to anticipate, withstand, recover from, and adapt to adverse conditions, stresses, attacks, or compromises that use or are enabled by cyber resources. From a risk management perspective, cyber resiliency is intended to reduce the mission, business, organizational, or sector risk of depending on cyber resources.

This publication can be used in conjunction with ISO/IEC/IEEE 15288:2015, Systems and software engineering—Systems life cycle processes; NIST SP 800-160, Volume 1, Systems Security Engineering—Considerations for a Multidisciplinary Approach in the Engineering of Trustworthy Secure Systems; NIST SP 800-37, Risk Management Framework for Information Systems and Organizations—A System Life Cycle Approach for Security and Privacy; and NIST SP 800-53, Security and Privacy Controls for Information Systems and Organizations. The application of the concepts in this publication—in combination with the system life cycle processes in SP 800-160, Volume 1, and the risk management methodology in SP 800-37—can be viewed as a handbook for achieving cyber resiliency outcomes. Guided and informed by stakeholder protection needs, mission and business assurance needs, and stakeholder concerns with cost, schedule, and performance, the cyber resiliency constructs and analysis approach can be applied to critical systems to identify, prioritize, and implement solutions to meet the unique cyber resiliency needs of organizations.

NIST SP 800-160, Volume 2, presents a cyber resiliency engineering framework to aid in understanding and applying cyber resiliency, a concept of use for the framework, and the engineering considerations for implementing cyber resiliency in the system life cycle. The framework constructs include goals, objectives, techniques, implementation approaches, and design principles. Organizations can select, adapt, and use some or all of the cyber resiliency constructs in this publication and apply the constructs to the technical, operational, and threat environments for which systems need to be engineered.

Building from the cyber resiliency engineering framework, this publication also identifies considerations for determining which cyber resiliency constructs are most relevant to a system of interest and a tailorable cyber resiliency analysis approach to apply the cyber resiliency concepts, constructs, and practices to a system. The cyber resiliency analysis is intended to

The cyber resiliency engineering framework is supplemented by several technical appendices that provide additional information to support its application, including:

This publication is intended to be used in conjunction with and as a supplement to International Standard ISO/IEC/IEEE 15288, Systems and software engineering — System life cycle processes. It is strongly recommended that organizations using this publication obtain the standard in order to fully understand the context of the security-related activities and tasks in each of the system life cycle processes. Content from the international standard that is referenced in this publication is used with permission from the Institute of Electrical and Electronics Engineers and is noted as follows:

[ISO 15288]. Reprinted with permission from IEEE, Copyright IEEE 2015, All rights reserved.

Although the focus of [ISO 15288] is systems and software engineering processes, operational resilience, which includes cyber resiliency for systems that include or depend on cyber resources, is addressed indirectly by requiring organization-wide commitment, resources, practices, and processes. The interacting elements in the definition of a system include layers of resilience in hardware, software, data, information, humans, processes, procedures, facilities, materials, and naturally occurring physical entities. This is important because if the organization’s missions or business functions require sustainability during perturbations, disruptions, disturbances, or cyber-attacks, then operational resilience practices and procedures must be applied to all of the system’s assets. It would be of limited value to have resilience measures implemented in the software architecture if there is no redundancy and survivability in the hardware, if the communications networks are fragile, if critical personnel are not available (e.g., in a natural disaster or inclement weather) to operate and maintain the system, or if there are no facilities available for producing the organization’s products and/or services.

Numerous reports of cyber incidents and cyber breaches indicate that extended periods of time transpired between the time an adversary initially established a presence in an organizational system by exploiting a vulnerability and when that presence was revealed or detected. In certain instances, the time period before detection can be as long as months or years. In the worst case, the adversary’s presence may never be detected.

The following examples illustrate the types of situations in which an adversary can maintain a long-term presence or persistence in a system without attacking the system via cyberspace:

Cyber resiliency is based on the recognition that adversaries can establish and maintain a covert presence in systems. Therefore, many cyber resiliency techniques and approaches are not predicated on the assumption of successfully detecting adversity, including cyber-attacks. These include the Coordinated Protection, Deception, Diversity, Non-Persistence, Realignment, Redundancy, Substantiated Integrity, and Unpredictability techniques, and the Fragmentation, Distributed Functionality, Predefined Segmentation, Attribute-Based Usage Restriction, and Trust-Based Privilege Management approaches.

Other techniques and approaches can provide automatic responses or support cyber defender responses to detected indicators of possible or suspected adversity or to warnings of potential forthcoming adverse conditions (including announcements of planned outages of supporting services or the predictions of increased system load). These include the Adaptive Response technique and the Functional Relocation of Sensors, Functional Relocation of Cyber Resources, Asset Mobility, Dynamic Privileges, and Dynamic Segmentation and Isolation approaches.

Two cyber resiliency techniques directly involve the detection of adversity or its effects: Analytic Monitoring and Contextual Awareness. The Substantiated Integrity technique and the Consistency Analysis approach support detection of some effects of adversity.

This table contains changes that have been incorporated into Special Publication 800-160, Volume 2, Revision 1. Errata updates can include corrections, clarifications, or other minor changes in the publication that are either editorial or substantive. Any potential updates for this document that are not yet published in a formal errata update or revision—including additional issues and potential corrections—will be posted as they are identified (see SP 800-160 Volume 2, Revision 1 publication details).

PAGE xiii

“Providing satisfactory security controls in a computer system is in itself a system design problem. A combination of hardware, software, communications, physical, personnel and administrative-procedural safeguards is required for comprehensive security. In particular, software safeguards alone are not sufficient.”

The Ware Report Defense Science Board Task Force on Computer Security, 1970.

“Mission assurance requires systems that behave with predictability and proportionality.”

General Michael Hayden Former NSA and CIA Director, Syracuse University, October 2009

“In the past, it has been assumed that to show that a system is safe, it is sufficient to provide assurance that the process for identifying the hazards has been as comprehensive as possible, and that each identified hazard has one or more associated controls. While historically this approach has been used reasonably effectively to ensure that known risks are controlled, it has become increasingly apparent that evolution to a more holistic approach is needed as systems become more complex and the cost of designing, building, and operating them become more of an issue.”

Preface, NASA System Safety Handbook, Volume 1, November 2011

“This whole economic boom in cybersecurity seems largely to be a consequence of poor engineering.”

Carl Landwehr Communications of the ACM, February 2015

THE NEED FOR CYBER-RESILIENT SYSTEMS

The need for trustworthy secure systems² stems from a variety of stakeholder needs that are driven by mission, business, and other objectives and concerns. The principles, concepts, and practices for engineering trustworthy secure systems can be expressed in various ways, depending on which aspect of trustworthiness is of concern to stakeholders. NIST Special Publication (SP) 800-160, Volume 1 [SP 800-160 v1], provides guidance on systems security engineering with an emphasis on protection against asset loss.³ In addition to security, other aspects of trustworthiness include reliability, safety, and resilience. Specialty engineering disciplines address different aspects of trustworthiness. While each discipline frames the problem domain and the potential solution space for its aspect of trustworthiness somewhat differently, [SP 800-160 v1] includes systems engineering processes to align the concepts, frameworks, and analytic processes from multiple disciplines to make trade-offs within and between the various aspects of trustworthiness applicable to a system of interest.⁴

NIST SP 800-160, Volume 2, focuses on the property of cyber resiliency, which has a strong relationship to security and resilience but provides a distinctive framework for its identified problem domain and solution space. Cyber resiliency is the ability to anticipate, withstand, recover from, and adapt to adverse conditions, stresses, attacks, or compromises on systems that use or are enabled by cyber resources.⁵

Cyber resiliency can be sought at multiple levels, including for system elements, systems, missions or business functions and the system-of-systems that support those functions, organizations, sectors, regions, the Nation, or transnational missions/business functions. From an engineering perspective, cyber resiliency is an emergent quality property of an engineered system, where an “engineered system” can be a system element made up of constituent components, a system, or a system-of-systems. Cyber-resilient systems are systems that have security measures or safeguards “built in” as a foundational part of the architecture and design and that display a high level of resiliency. Thus, cyber-resilient systems can withstand cyber-attacks, faults, and failures and continue to operate in a degraded or debilitated state to carry out the mission-essential functions of the organization. From an enterprise risk management perspective, cyber resiliency is intended to reduce the mission, business, organizational, or sector risk of potentially compromised cyber resources.

Cyber resiliency supports mission assurance in a contested environment for missions that depend on systems that include cyber resources. A cyber resource is an information resource that creates, stores, processes, manages, transmits, or disposes of information in electronic form and that can be accessed via a network or using networking methods. However, some information resources are specifically designed to be accessed using a networking method only intermittently (e.g., via a low-power connection to check the status of an insulin pump, via a wired connection to upgrade software in an embedded avionic device). These cyber resources are characterized as operating primarily in a disconnected or non-networked mode.⁶

Cyber-resilient systems operate like the human body. The human body has an effective immune system that can readily absorb a continuous barrage of environmental hazards and provides the necessary defense mechanisms to maintain a healthy state. The body also has self-repair systems to recover from illnesses and injuries when defenses are breached. But cyber-resilient systems, like the human body, cannot defend against all hazards at all times. While the body cannot always recover to the same state of health as before an injury or illness, it can adapt. Similarly, cyber-resilient systems can recover minimal essential functionality (e.g., functionality to meet critical mission needs). Understanding the limitations of individuals, organizations, and systems is fundamental to managing risk.

Systems incorporate cyber resources as system elements and may be susceptible to harm⁷ resulting from the effects of adversity⁸ on those resources and particularly to harm resulting from cyber-attacks. In some cases, susceptibility to harm may exist even with the employment of traditional cybersecurity safeguards and countermeasures intended to protect systems from adversity. The cyber resiliency problem is defined as how to achieve adequate mission resilience by providing (1) adequate system resilience⁹ and (2) adequate mission/business function and operational/organizational resilience in the presence of possible adversities that affect cyber resources. The cyber resiliency problem domain overlaps with the security problem domain since a system should be securely resilient.¹⁰

The cyber resiliency problem domain is informed by an understanding of the threat landscape and, in particular, the advanced persistent threat (APT). The APT stems from an adversary that possesses significant levels of expertise and resources that allow it to create opportunities to achieve its objectives by using multiple attack vectors, including cyber, physical, and deception. These objectives include establishing and extending footholds within the systems of targeted organizations for the express purposes of exfiltrating information; undermining or impeding critical aspects of a mission, program, or organization; or positioning itself to carry out these objectives in the future. The APT pursues its objectives repeatedly over an extended period, adapts to defenders’ efforts to resist it, and is determined to maintain the level of interaction needed to execute its objectives [SP 800-39] [CNSSI 4009].¹¹ In addition, the APT can take advantage of human errors (e.g., lapses in basic cybersecurity), exploit other stresses on systems (e.g., increased or unusual system use in response to a natural disaster or other event), and execute sophisticated supply chain attacks.

All discussions of cyber resiliency focus on assuring mission or business functions and are predicated on the assumption that the adversary will breach defenses and establish a long-term presence in organizational systems. A cyber-resilient system is a system that provides a degree of cyber resiliency commensurate with the system’s criticality.

The purpose of this publication is to provide guidance on how to apply cyber resiliency concepts, constructs, and engineering practices to systems security engineering and risk management for systems and organizations.¹² This publication identifies considerations for the engineering of the following types of systems that depend on cyber resources:¹³

The guidance in this publication can be applied to new systems, reactive modifications to fielded systems, planned upgrades to fielded systems while continuing to sustain day-to-day operations, evolving systems, and systems identified for retirement.

This publication is intended for systems security engineering and other professionals who are responsible for the activities and tasks related to the system life cycle processes in [SP 800-160 v1], the risk management processes in [SP 800-39], or the Risk Management Framework (RMF) in [SP 800-37].¹⁶ The term systems security engineer is used in this publication to include those security professionals who perform any of the activities and tasks in [SP 800-160 v1]. This publication can also be used by professionals who perform other system life cycle activities that impact trustworthiness or who perform activities related to the education or training of systems engineers and systems security engineers. These include but are not limited to:

This publication assumes that the systems security engineering activities in [SP 800-160 v1] and risk management processes in [SP 800-37] are performed under the auspices of, or within, an organization (referred to as “the organization” in this document).¹⁷ The activities and processes take into consideration the concerns of a variety of stakeholders, within and external to the organization. The organization—through systems security engineering and risk management activities—identifies stakeholders, elicits their concerns, and represents those concerns in the systems security engineering and risk management activities.

This publication is intended to be used in conjunction with [SP 800-160 v1] and is designed to be flexible in its application to meet the diverse and changing needs of systems and organizations. It is not intended to provide a “recipe” for execution or a “cookbook” approach to developing cyber-resilient systems. Rather, the publication can be viewed as a tutorial for achieving the identified cyber resiliency outcomes from a systems engineering perspective, leveraging the experience and expertise of the individuals in the organization to determine what is correct for its purpose.

Stakeholders who choose to use this guidance can employ some or all of the cyber resiliency constructs (i.e., goals, objectives, techniques, approaches, and design principles) as well as the analytic and life cycle processes, tailoring them to the technical, operational, and threat environments for which systems need to be engineered. In addition, organizations that choose to use this guidance for their systems security engineering efforts can select and employ some or all of the 30 processes in [ISO 15288] and some or all of the security-related activities and tasks defined for each process. Note that there are process dependencies in [ISO 15288]. The successful completion of some activities and tasks invokes other processes or leverages the results of other processes.

The system life cycle processes can be used for new systems, system upgrades, or systems that are being repurposed. The processes can be employed at any stage of the system life cycle and can take advantage of any system or software development methodology, including waterfall, spiral, or agile. The life cycle processes can also be applied recursively, iteratively, concurrently, sequentially, or in parallel and to any system regardless of its size, complexity, purpose, scope, environment of operation, or special nature.

The full extent of the application of the content in this publication is informed by stakeholder needs, organizational capabilities, cyber resiliency goals and objectives, cost, schedule, and performance. The tailorable nature of the engineering activities and tasks and the system life cycle processes help to ensure that the systems resulting from the application of the security design principles and concepts have a level of trustworthiness deemed sufficient to protect stakeholders from suffering unacceptable losses of assets and the associated consequences. Such trustworthiness is made possible by the rigorous application of these cyber resiliency constructs within a structured set of processes that provides the necessary evidence and transparency to support risk-informed decision making and trades.

The remainder of this special publication is organized as follows:

The following sections provide additional cyber resiliency-related information, including:

While this publication focuses on cyber resiliency engineering, the higher-level cyber resiliency constructs (i.e., cyber resiliency goals, objectives, and techniques) are defined to have broad applicability. The definitions of these constructs are written in a technology-neutral manner and are silent with regard to cyber resources. Thus, while these constructs can be applied to “cyber systems” (i.e., systems entirely constituted of cyber resources or for which cyber components are viewed as central), they can also be readily applied to “non-cyber systems”— that is, systems that include no cyber resources (e.g., water-powered sawmills). For the lower-level construct of cyber resiliency implementation approaches, the definitions become technology-specific and focus on cyber resources. Moreover, except for the Deception and Unpredictability techniques, the higher-level constructs are defined so that they can be applied to adversarial (e.g., cyber-attacks) and non-adversarial (e.g., fires, floods) threat events.

The technology-neutral (and largely threat-neutral) nature of the higher-level cyber resiliency constructs reflects the fact that they are drawn from well-established, cross-cutting resilience concepts. In addition, it means that stakeholders and systems engineers for non-cyber systems (or systems for which cyber components are not viewed as central) can apply many of the constructs described in this publication, as can systems that are not concerned with adversarial threat events. This may prove beneficial given the rapid convergence of cyber and physical systems that reflects a movement of cyber into traditional non-cyber realms (e.g., vehicles, medical devices) and the growth of bio-integrated technology.

Finally, while much of the cyber resiliency analysis in this publication uses the MITRE Adversarial Tactics, Techniques, and Common Knowledge (ATT&CK™) framework [Strom17], organizations can employ any framework that is suitable to their organizational needs.

UNDERSTANDING THE CONCEPTS ASSOCIATED WITH CYBER RESILIENCY

This section presents an engineering framework for understanding and applying cyber resiliency, the cyber resiliency constructs that are part of the framework, a concept of use for the framework, and engineering considerations for implementing cyber resiliency in the system life cycle. The discussion relies on several terms including cyber resiliency concepts and constructs, engineering practices, and solutions.

Cyber resiliency concepts are related to the problem domain and the solution set for cyber resiliency. The concepts are represented in cyber resiliency risk models and by cyber resiliency constructs.¹⁹ The constructs are the basic elements (i.e., building blocks) of the cyber resiliency engineering framework and include goals, objectives, techniques, implementation approaches, and design principles.²⁰ The framework provides a way to understand the cyber resiliency problem and solution domain. Cyber resiliency goals and objectives identify the “what” of cyber resiliency—that is, what properties and behaviors are integral to cyber-resilient systems. Cyber resiliency techniques, implementation approaches, and design principles characterize the ways of achieving or improving resilience in the face of threats to systems and system components (i.e., the “how” of cyber resiliency). Cyber resiliency constructs address both adversarial and non-adversarial threats from cyber and non-cyber sources.

Cyber resiliency engineering practices are the methods, processes, modeling, and analytical techniques used to identify and analyze proposed solutions. The application of these practices in system life cycle processes ensures that cyber resiliency solutions are driven by stakeholder requirements and protection needs, which, in turn, guide and inform the development of system requirements for the system of interest [ISO 15288, SP 800-160 v1]. Such solutions consist of combinations of technologies, architectural decisions, systems engineering processes, and operational policies, processes, procedures, or practices that solve problems in the cyber resiliency domain. They provide a sufficient level of cyber resiliency to meet stakeholder needs and reduce risks to organizational mission or business capabilities in the presence of a variety of threat sources, including the APT.

Cyber resiliency solutions use cyber resiliency techniques and approaches to implementing those techniques, as described in Section 2.1.3. Cyber resiliency solutions apply the design principles described in Section 2.1.4 and implement mechanisms (e.g., controls and control enhancements defined in [SP 800-53]) that apply one or more cyber resiliency techniques or implementation approaches or that are intended to achieve one or more cyber resiliency objectives. These mechanisms are selected in response to the security and cyber resiliency requirements defined as part of the system life cycle and requirements engineering process described in [SP 800-160 v1] or to mitigate security and cyber resiliency risks that arise from architectural or design decisions.

The following sections provide a description of the framework for cyber resiliency engineering.²¹ The framework constructs include cyber resiliency goals, objectives, techniques, implementation approaches, and design principles. The relationship among constructs is also described. These constructs, like cyber resiliency, can be applied at levels beyond the system (e.g., mission or business function level, organizational level, or sector level). Table 1 summarizes the definition and purpose of each construct, and how each construct is applied at the system level.

TABLE 1: CYBER RESILIENCY CONSTRUCTS

Cyber resiliency, like security, is a concern at multiple levels in an organization. The four cyber resiliency goals, which are common to many resilience definitions, are included in the definition and the cyber resiliency engineering framework to provide linkage between risk management decisions at the system level, the mission and business process level, and the organizational level. Organizational risk management strategies can use cyber resiliency goals and associated strategies to incorporate cyber resiliency.²²

For cyber resiliency engineering analysis, cyber resiliency objectives rather than goals are the starting point. The term adversity, as used in the cyber resiliency goals in Table 2, includes stealthy, persistent, sophisticated, and well-resourced adversaries (i.e., the APT) who may have compromised system components and established a foothold within an organization’s systems.

TABLE 2: CYBER RESILIENCY GOALS

Cyber resiliency objectives²³ are specific statements of what a system is intended to achieve in its operational environment and throughout its life cycle to meet stakeholder needs for mission assurance and resilient security. Cyber resiliency objectives, as described in Table 3, support interpretation,²⁴ facilitate prioritization and assessment, and enable development of questions such as:

TABLE 3: CYBER RESILIENCY OBJECTIVES²⁵

Because stakeholders may find the cyber resiliency objectives difficult to relate to their specific concerns, the objectives can be tailored to reflect the organization’s missions and business functions or operational concept for the system of interest. Tailoring the cyber resiliency objectives can also help stakeholders determine which objectives apply and the priority to assign to each objective. Cyber resiliency objectives can be hierarchically refined to emphasize the different aspects of an objective or the methods to achieve an objective, thus creating sub-objectives.²⁷ Cyber resiliency objectives (and sub-objectives as needed to help stakeholders interpret the objectives for their concerns) enable stakeholders to assert their different resiliency priorities based on organizational missions or business functions.

Cyber resiliency goals and objectives provide a vocabulary for describing what properties and capabilities are needed. Cyber resiliency techniques, approaches, and design principles (discussed in Section 2.1.4) provide a vocabulary for discussing how a system can achieve its cyber resiliency goals and objectives. A cyber resiliency technique is a set or class of practices and technologies intended to achieve one or more goals or objectives by providing capabilities.

The following 14 techniques are part of the cyber resiliency engineering framework:

The cyber resiliency techniques are described in Appendix D. Each technique is characterized by both the capabilities it provides and the intended consequences of using the technologies or the processes it includes. The cyber resiliency techniques reflect an understanding of the threats as well as the technologies, processes, and concepts related to improving cyber resiliency to address the threats. The cyber resiliency engineering framework assumes the cyber resiliency techniques will be selectively applied to the architecture or design of organizational mission or business functions and their supporting system resources. Since natural synergies and conflicts exist among the cyber resiliency techniques, system engineering trade-offs must be made. Cyber resiliency techniques are expected to change over time as threats evolve, technology advances are made based on research, security practices evolve, and new ideas emerge.

Twelve of the 14 cyber resiliency techniques can be applied to adversarial or non-adversarial threats (including cyber-related and non-cyber-related threats). The cyber resiliency techniques specific to adversarial threats are Deception and Unpredictability. Cyber resiliency techniques are also interdependent. For example, the Analytic Monitoring technique supports Contextual

Awareness. The Unpredictability technique, however, is different from the other techniques in that it is always applied in conjunction with some other technique (e.g., working with the Dynamic Positioning technique to establish unpredictable times for repositioning potential targets of interest). The definitions of cyber resiliency techniques are intentionally broad to insulate the definitions from changing technologies and threats, thus limiting the need for frequent changes to the set of techniques.

To support engineering analysis, multiple representative approaches to implementing each technique are identified. As illustrated in Figure 1, an implementation approach (or, for brevity, an approach) is a subset of the technologies and processes included in a technique that are defined by how the capabilities are implemented or how the intended outcomes are achieved.

Table D-4 in Appendix D defines representative approaches and gives representative examples of technologies and practices. The set of approaches for a specific technique is not exhaustive and represents relatively mature technologies and practices. Thus, technologies emerging from research can be characterized in terms of the techniques they apply while not being covered by any of the representative approaches.²⁸

FIGURE 1: CYBER RESILIENCY TECHNIQUES AND IMPLEMENTATION APPROACHES

Systems engineers and architects use design principles²⁹ as guidance in design decisions and analysis. A design principle takes the form of a terse statement or a phrase identifying a key concept accompanied by one or more statements that describe how that concept applies to system design (where “system” is broadly construed to include operational processes and procedures and may also include development and maintenance environments) [Bodeau17]. Design principles are defined for many specialty engineering disciplines using the terminology, experience, and research results that are specific to the specialty.

Cyber resiliency design principles, like those from other specialty disciplines, can be applied in different ways at multiple stages in the system life cycle, including the operations and maintenance stage. The design principles can also be used in a variety of system development models, including agile and spiral development. The cyber resiliency design principles identified in this publication can serve as a starting point for systems engineers and architects. For any given situation, only a subset of the design principles is selected, and those principles are tailored or “re-expressed” in terms more meaningful to the program, system, or system-of-systems to which they apply.

The cyber resiliency design principles are strongly informed by and can be aligned with design principles from other specialty disciplines, such as the security design principles in [SP 800-160 v1]. Many of the cyber resiliency design principles are based on design principles for security, resilience engineering, or both. Design principles can be characterized as strategic (i.e., applied throughout the systems engineering process, guiding the direction of engineering analyses) or structural (i.e., directly affecting the architecture and design of the system or system elements) [Ricci14]. Both strategic and structural cyber resiliency design principles can be reflected in security-related systems engineering artifacts. A complete list of strategic and structural cyber resiliency design principles is provided in Appendix D.

Cyber resiliency constructs, including goals, objectives, techniques, implementation approaches, and design principles, enable systems engineers to express cyber resiliency concepts and the relationships among them. The cyber resiliency constructs also relate to risk management. That relationship leads systems engineers to analyze cyber resiliency solutions in terms of potential effects on risk and on specific threat events or types of malicious cyber activities. The selection and relative priority of these cyber resiliency constructs is determined by the organization’s strategy for managing the risks of depending on systems, which include cyber resources—in particular, by the organization’s risk framing.³⁰ The relative priority of the cyber resiliency goals and objectives and relevance of the cyber resiliency design principles are determined by the risk management strategy of the organization, which takes into consideration the concerns of, constraints on, and equities of all stakeholders (including those who are not part of the organization). Figure 2 illustrates the relationships among the cyber resiliency constructs. These relationships are represented by mapping tables in Appendix D. As Figure 2 illustrates, a cyber-resilient system is the result of the engineering selection, prioritization, and application of cyber resiliency design principles, techniques, and implementation approaches. The risk management strategy for the organization is translated into specific interpretations and prioritizations of cyber resiliency goals and objectives, which guide and inform trade-offs among different forms of risk mitigation.

FIGURE 2: RELATIONSHIPS AMONG CYBER RESILIENCY CONSTRUCTS

The following section describes general considerations for applying cyber resiliency concepts and framework constructs to system life cycle stages and processes.³¹ Considerations include addressing the similarities and differences in security and cyber resiliency terminology and how the application of cyber resiliency goals, objectives, techniques, implementation approaches, and design principles can impact systems at key stages in the life cycle. Figure 3 lists the system life cycle processes and illustrates their application across all stages of the system life cycle. It must be emphasized, however, that cyber resiliency engineering does not assume any specific life cycle or system development process, and cyber resiliency analysis can be performed at any point in and iteratively throughout the life cycle.³²

FIGURE 3: SYSTEM LIFE CYCLE PROCESSES AND LIFE CYCLE STAGES

Cyber resiliency constructs are interpreted and cyber resiliency engineering practices are applied in different ways depending on the system life cycle stages. During the Concept stage, cyber resiliency goals and objectives are tailored in terms of the concept of use for the system of interest. Tailoring actions are used to elicit stakeholder priorities for the cyber resiliency goals and objectives. The organization’s risk management strategy is used to help determine which strategic design principles are most relevant. The strategic design principles and corresponding structural design principles are aligned with design principles from other specialty engineering disciplines. Notional or candidate system architectures are analyzed with respect to how well the prioritized cyber resiliency goals and objectives can be achieved and how well the relevant strategic cyber resiliency design principles can be applied. The tailoring of objectives can also be used to identify or define potential metrics or measures of effectiveness for proposed cyber resiliency solutions. Once again, the risk management strategy that constrains risk response or risk treatment (e.g., commitment to specific technologies, requirements for interoperability with or dependence on other systems) is used to help determine which techniques and approaches can or cannot be used in cyber resiliency solutions. In addition, during the Concept stage, cyber resiliency concerns for enabling systems for production, integration, validation, and supply chain management are identified, and strategies for addressing those concerns are defined.

During the Development stage, the relevant structural cyber resiliency design principles (i.e., those principles that can be applied to the selected system architecture and that support the strategic cyber resiliency design principles) are identified and prioritized based on how well the design principles enable the prioritized cyber resiliency objectives to be achieved. The cyber resiliency techniques and approaches indicated by the structural design principles are analyzed with respect to whether and where they can be used in the selected system architecture given the constraints identified earlier. Cyber resiliency solutions are defined and analyzed with respect to potential effectiveness and compatibility with other aspects of trustworthiness.

Analysis of potential effectiveness considers the relative effectiveness of the solution against potential threat events or scenarios [SP 800-30] and the measures of effectiveness for cyber resiliency objectives. Analysis of compatibility with other aspects of trustworthiness considers potential synergies or conflicts associated with technologies, design principles, or practices specific to other specialty engineering disciplines, particularly security, reliability, survivability, and safety. In addition, specific measures for assessing whether or not the prerequisite requirements have been satisfied within the solution space are defined. This may include, for example, a determination of the baseline reliability of the technology components needed to deliver cyber-resilient capabilities within a system element.

In addition, during the Development stage, the implementation of cyber resiliency solutions is analyzed and evaluated. The verification strategy for cyber resiliency solutions at this stage typically includes adversarial testing or demonstration of mission or business function measures of performance in a stressed environment with adversarial activities. The operational processes and procedures for using technical solutions are defined, refined, and validated with respect to the ability to meet mission and business objectives despite the adversity involving systems containing cyber resources. The cyber resiliency perspective calls for testing and other forms of validation or verification that include adversarial threats among (and in combination with) other stresses on the system. During this life cycle stage, resources (e.g., diverse implementations of critical system elements, alternative processing facilities) required to implement specific courses of action are also developed.

During the Production stage, the verification strategy is applied to instances or versions of the system of interest and associated spare parts or components. The verification strategy for the cyber resiliency requirements as applied to such instances and system elements includes adversarial testing or demonstration in a stressed environment. In addition, during the Production stage, cyber resiliency concerns for enabling systems for production, integration, validation, and supply chain management continue to be identified and addressed.

During the Utilization stage, the effectiveness of cyber resiliency solutions in the operational environment is monitored. Effectiveness may decrease due to changes in the operational environment (e.g., new mission or business processes, new stakeholders, increased user population, configuration drift, deployment in new locations, addition or removal of systems or system elements with which the system of interest interacts), the threat environment (e.g., new threat actors, new vulnerabilities in commonly used technologies), or the technical environment (e.g., the introduction of new technologies into other systems with which the system of interest interacts). Cyber resiliency solutions may need to be adapted to address such changes (e.g., defining new courses of action, reconfiguring system elements, changing mission or business processes and procedures). The relative priorities of cyber resiliency objectives may shift based on changes to stakeholders, stakeholder concerns, mission or business processes, or project funding. Finally, changes in the threat or technical environment may make some techniques or approaches less feasible, while changes in the technical or operational environment may make others more viable.

During the Support stage, maintenance and upgrade of the system or system elements can include integration of new cyber resiliency solutions into the system of interest. This stage also provides opportunities to revisit the prioritization and tailoring of cyber resiliency objectives. Upgrades to or modifications of system capabilities can include significant architectural changes that address accumulated changes to the operational, threat, and technical environments. System modifications and upgrades can also introduce additional vulnerabilities, particularly with architectural changes.

During the Retirement stage, system elements or the entire system of interest are removed from operations. The retirement process can affect other systems with which the system of interest interacts and can decrease the cyber resiliency of those systems and of the supported mission or business processes. Retirement strategies can include phased removal of system elements, turnkey removal of all system elements, phased replacement of system elements, and turnkey replacement of the entire system of interest. Cyber resiliency objectives and priorities are identified for the systems, missions, and business functions in the operational environment to inform analysis of the potential or expected effects of different retirement strategies on the ability to achieve those objectives. Like the support stage, the retirement stage can introduce significant vulnerabilities, particularly during disposal and unintended residue remaining from decommissioned assets.³³

Table 4 illustrates changes in emphasis for the different cyber resiliency constructs, particularly with respect to cyber resiliency objectives (bolded).

TABLE 4: CYBER RESILIENCY IN LIFE CYCLE STAGES

Organizations manage the missions, business functions, and operational risks related to dependencies on systems that include cyber resources as part of a larger portfolio of risks,³⁴ including financial and reputational risks; programmatic or project-related risks associated with developing a system (e.g., cost, schedule, performance); security risks associated with the organization’s mission or business activities, information the organization processes or handles, or requirements arising from legislation, regulations, policies, or standards; and cybersecurity risks. A proposed cyber resiliency solution, while intended primarily to reduce mission, business, or operational risk, can also reduce other types of risk (e.g., security risk, reputational risk, supply chain risk, performance risk). However, like any solution to a risk management problem, it can also increase other types of risk (e.g., financial, cost, or schedule risk). As part of a multidisciplinary systems engineering effort, systems security engineers and risk management professionals are responsible for articulating the potential adverse impacts of alternative solutions, determining whether those impacts fall within the organizational risk tolerance, deciding whether the adoption of a proposed solution is consistent with the organization’s risk management strategy, and informing the organization’s risk executive of risk trade-offs.³⁵

At the organizational level, a cyber resiliency perspective on risk management can lead to the analysis and management of risks associated with programs and initiatives at multiple levels, which involve investment in, transition to, use of, or transition away from different cyber technologies. The environment in which a system of interest is engineered is rarely static. Related programs, initiatives, or other efforts at federal agencies, driven by [EO 14028], can include efforts to transition to a zero trust architecture, reduce software supply chain risks, and transition from IPv4 to IPv6. Such organization-level programs and initiatives can affect the execution of efforts at lower levels (e.g., an acquisition program for a specific system or service, an initiative to redefine a mission or business process to better accommodate telework).

Motivated by the cyber resiliency Adapt goal, an organization’s risk management strategy can also consider the following questions:

Cyber resiliency goals, objectives, and techniques are generally defined so they can be applied to all types of threats (not solely cyber threats) and all types of systems (not solely systems that include or are enabled by cyber resources). However, the motivation for these definitions and for the selection of objectives and techniques for inclusion in the cyber resiliency engineering framework is the recognition of dependence on systems involving cyber resources in a threat environment that includes the APT.

NIST is working with the United States Air Force and the Air Force Research Laboratory (AFRL) to explore ways to incorporate the cyber resiliency constructs in this publication into the system development life cycle through the use of automated support tools. The use of such tools can help ensure that cyber resiliency requirements are clearly defined and more easily integrated into the system development life cycle. Automated tools can provide an efficient and effective vehicle for incorporating cyber resiliency capabilities into a variety of systems (e.g., weapons systems, space systems, command and control systems, industrial control systems, enterprise IT systems) using any established life cycle development process or approach (e.g., agile, waterfall, spiral, DevOps). Automation can also support the rapid testing and evaluation of cyber resiliency capabilities in critical systems to reduce the time to operational deployment.

APPLYING CYBER RESILIENCY CONCEPTS, CONSTRUCTS, PRACTICES

This chapter identifies considerations for determining which cyber resiliency constructs are most relevant to a system of interest and describes a tailorable process for applying cyber resiliency concepts, constructs, and practices to a system. It also includes guidance on the cyber resiliency analysis carried out during the system life cycle to determine whether the cyber resiliency properties and behaviors of a system of interest, regardless of its life cycle stage, are sufficient for the organization using that system to meet its mission assurance, business continuity, or other security requirements in a threat environment and contested cyberspace that includes the APT.

The variety of concerns, technologies, and practices related to cyber resiliency results in an extensive framework for cyber resiliency engineering. For example, the engineering framework identifies 14 cyber resiliency techniques and 50 cyber resiliency implementation approaches. The engineering framework is also complex, with relationships among the constructs of goals, objectives, design principles, techniques, and approaches, as discussed in Appendix D. Cyber resiliency design principles, techniques, and approaches build on, complement, or function in synergy with mechanisms intended to ensure other quality properties (e.g., security, safety, and system resilience).

The variety of circumstances and types of systems for which cyber resiliency can be applied means that no single cyber resiliency technique, approach, or set of approaches is universally optimal or applicable. Systems security engineering seeks to manage risk rather than provide a universal solution. The choice of a risk-appropriate set of cyber resiliency techniques and approaches depends on various trade space considerations and risk factors that are assessed during the systems engineering processes. Employment of all cyber resiliency techniques and approaches is not needed to achieve the cyber resiliency objectives prioritized by stakeholders. In fact, it is not possible to employ all techniques and approaches simultaneously. The following subsections describe factors to consider when selecting a set of cyber resiliency techniques and implementation approaches that best fits the system of interest.

Cyber resiliency techniques and associated implementation approaches are employed to achieve mission or business objectives. The relative priorities of cyber resiliency goals and objectives are determined by the mission or business objectives. The selection of specific cyber resiliency techniques and approaches is, therefore, driven in part by the relative priorities of the objectives they support.³⁶

An organization’s cyber risk management strategy (i.e., its strategy for managing risks stemming from dependencies on systems that include cyber resources) is part of its risk management strategy and includes its risk framing for cyber risks.³⁷ The organization’s risk frame identifies which risks or risk factors (i.e., potential impacts or consequences) are unacceptable. For cyber resiliency, the risk frame assumes an adversary with a persistent presence in organizational systems. The risk response portion of the risk management strategy can include priorities or preferences for the types of effects on adversary activities³⁸ to seek in cyber resiliency solutions.

An organization’s risk management strategy is constrained by such factors as legal, regulatory, and contractual requirements as reflected in organizational policies and procedures, financial resources, legacy investments, and organizational culture. These constraints imply the need to consider the costs, ease of use, and operational impacts of security and cyber resiliency solutions. The constraints can be reflected in the selection and tailoring of cyber resiliency techniques, approaches, and design principles. For example, organizational policies and culture can influence whether and how the cyber resiliency technique of Deception is used. The risk management strategy can define an order of precedence for responding to identified risks analogous to the safety order of precedence, such as “harden, sensor, isolate, obfuscate.” Together with the strategic design principles selected and specifically tailored to a given program, mission, business function, or system, the order of precedence can guide the selection and application of structural design principles at different locations in an architecture.³⁹

The set of cyber resiliency techniques and approaches that are most relevant to and useful in a system depends on the type of system. The following present some general examples of system types and the techniques and approaches that might be appropriate for those types of systems. In addition to the techniques and approaches listed in the examples below, there may be other techniques and approaches that could be useful for a particular type of system. The specific aspects of the system in question will impact the selection as well.

Enterprise IT (EIT) systems are typically general-purpose computing systems—very often with significant processing, storage, and bandwidth—capable of delivering information resources that can meet the business or other mission needs of an enterprise or a large stakeholder community. As such, all of the cyber resiliency techniques and associated approaches may potentially be viable, although their selection would depend on the other considerations noted in this section.

Large-scale processing environments (LSPEs) handle large numbers of events and data (e.g., process transactions) with high confidence in service delivery. The scale of such systems makes them highly sensitive to disruptions to or degradation of service. Therefore, the selective use of the Offloading and Restriction implementations approaches can make the scale of such systems more manageable. This, in turn, will support the application of Analytic Monitoring and the Mission Dependency and Status Visualization approach to Contextual Awareness in a manner that does not significantly affect performance. LSPEs often implement Dynamic Positioning functionality that can be repurposed to help improve cyber resiliency via the Functional Relocation of Cyber Resources, Fragmentation, and Distributed Functionality approaches.

Many cyber resiliency techniques are likely to be applicable to a system-of-systems, but some techniques and approaches can offer greater benefits than others. For example, Contextual Awareness implemented via Mission Dependency and Status Visualization can be applied to predict the potential mission impacts of cyber effects of adversary activities on constituent systems or system elements. The Calibrated Defense-in-Depth and Consistency Analysis approaches to the technique of Coordinated Protection can help ensure that the disparate protections of the constituent systems operate consistently and in a coordinated manner to prevent or delay the advance of an adversary across those systems. For a system-of-systems involving constituent systems that were not designed to work together and that were developed with different missions, functions, and risk frames, Realignment could also be beneficial. In particular, the Offloading and Restriction approaches could be used to ensure that the core system elements are appropriately aligned to the overall system-of-system mission.

Critical infrastructure systems are often specialized, high confidence, dedicated, purpose-built systems that have highly deterministic properties. Therefore, the availability and integrity of the functionality of the systems are very important as the corruption or lack of availability of some of the key system elements could result in significant harm. For these reasons, techniques adapted from system resilience, such as Redundancy (particularly the Protected Backup and Restore and Surplus Capacity approaches) coupled with aspects of Diversity (e.g., Architectural Diversity, Supply Chain Diversity), could prevent attacks from having mission or business consequences and also maximize the chance of continuation of the critical or essential mission or business operations. Segmentation can isolate highly critical system elements to protect them from an adversary’s activities. Approaches such as Trust-Based Privilege Management and Attribute-Based Usage Restriction could constrain the potential damage that an adversary could inflict on a system.

As with critical infrastructure systems, cyber-physical systems (CPS) may have limitations regarding storage capacity, processing capabilities, and bandwidth. In addition, many of these systems have a high degree of autonomy with limited human interaction. Some cyber-physical systems operate with no active network connection, although they may connect to a network under specific circumstances (e.g., scheduled maintenance). Non-Persistent Services support the periodic refreshing of software and firmware from a trusted source (e.g., an offline redundant component), in effect flushing out any malware. However, that approach applies only if the organization can allow for the periodic downtime that the refresh would entail. Similarly, the Integrity Checks approach to Substantiated Integrity implemented via cryptographic checksums on critical software could help enable embedded systems to detect corrupted software components.

An Internet of Things (IoT) system consists of system elements with network connectivity and that communicate with an Internet-accessible software application. That software application, which is part of the IoT system, orchestrates the behavior of or aggregates the data provided by constituent system elements. The system elements have limitations in the areas of power consumption, processing, storage capacity, and bandwidth, which in turn may limit the potential for such processing-intensive cyber resiliency approaches such as Obfuscation or Adaptive Management at the device level. Because many “things” (e.g., light bulbs, door locks) are small and relatively simple, they often lack the capacity for basic protection. However, the Integrity Checks approach to Substantiated Integrity could still be viable when applied in conjunction with reliability mechanisms. An IoT system assumes Internet connectivity, although the set of “things” is usually capable of functioning independently if not connected. Because many IoT systems do not assume technical expertise on the part of users, cyber resiliency techniques and approaches that involve human interaction (e.g., Disinformation, Misdirection) may not be appropriate. In addition, the design of IoT systems accommodates flexibility and repurposing of the capabilities of constituent “things.” Thus, an application that orchestrated the behavior of one set of “things” may be upgraded to orchestrate additional sets, the members of which were not designed with that application in mind. Such changes to the IoT systems to which that application or the additional sets originally belong can benefit from the application of Realignment. At the level of an IoT system (rather than at the level of individual system elements), Segmentation and Consistency Analysis can be applied.

Cyber resiliency techniques can interact in several ways. One technique can depend on another so that the first cannot be implemented without the second; for example, Adaptive Response depends on Analytic Monitoring or Contextual Awareness since a response requires a stimulus. One technique can support another, making the second more effective; for example, Diversity and Redundancy are mutually supportive. One technique can use another so that more design options are available than if the techniques were applied independently; for example, Analytic Monitoring can use Diversity in a design, which includes a diverse set of monitoring tools.

However, one technique can also conflict with or complicate the use of another. For example, Diversity and Segmentation can each make Analytic Monitoring and Contextual Awareness more difficult. A design that incorporates Diversity requires monitoring tools that can handle the diverse set of system elements, while implementation of Segmentation can limit the visibility of such tools. By selecting techniques in accordance with the risk management strategy and design principles, synergies and conflicts between various techniques are taken into consideration. The text below offers three illustrative examples of the interplay, focusing on the techniques that increase an adversary’s work factor.

As a first example, Dynamic Positioning and Non-Persistence enable operational agility by making it more difficult for an adversary to target critical resources. These techniques support the Continue, Constrain, and Reconstitute objectives and are part of applying the Support agility and architect for adaptability strategic design principle and the Change or disrupt the attack surface structural design principle. At the same time, these techniques (and the associated implementation approaches) also make it more difficult for an organization to maintain situational awareness of its security posture. That is, Dynamic Positioning and Non-Persistence complicate the use of Contextual Awareness and aspects of Analytic Monitoring and, thus, can conflict with the Maintain situational awareness structural design principle.

As a second example, Redundancy and Diversity together are effective at resisting adversary attacks. These techniques enhance the system’s ability to achieve the Continue and Reconstitute objectives and apply the Plan and manage diversity and Maintain redundancy structural design principles. However, the implementation of both Redundancy and Diversity will increase the system’s attack surface.

As a final example, Deception can lead the adversary to waste effort and reveal tactics, techniques, and procedures (TTP), but it can also complicate the use of aspects of Analytic Monitoring and Contextual Awareness. In general, while Redundancy, Diversity, Deception, Dynamic Positioning, and Unpredictability will likely greatly increase the adversary work factor, they come at a cost to some other cyber resiliency objectives, techniques, and design principles.

No technique or set of techniques is optimal with respect to all decision factors. There are always ramifications for employing any given technique. The determination of the appropriate selection of techniques is a trade decision that systems engineers make considering all relevant factors. A more complete identification of potential interactions (e.g., synergies and conflicts) between cyber resiliency techniques is presented in Table D-3.

Many of the techniques and implementation approaches that support cyber resiliency are well established. Some technologies or processes are drawn from other disciplines (e.g., Continuity of Operations [COOP], cybersecurity) but are used or executed in a different manner to support cyber resiliency. These include Adaptive Response, Analytic Monitoring, Coordinated Protection, Privilege Restriction, Redundancy, and Segmentation. Others are drawn from disciplines that deal with non-adversarial threats (e.g., safety, reliability). These include Contextual Awareness, Diversity, Non-Persistence, Realignment, and Substantiated Integrity. Still others are cyber adaptations of non-cyber concepts drawn from disciplines that deal with adversarial threats (e.g., medicine, military/defense, sports). These include Deception, Dynamic Positioning, and Unpredictability. Legacy investments made by an organization in these other disciplines can influence which cyber resiliency techniques and approaches are most appropriate to pursue.

Redundancy-supporting approaches—such as backup, surplus capacity, and replication—are well established in COOP programs. From a cyber resiliency perspective, however, these approaches are not sufficient to protect against the APT. A threat actor might choose to target backup servers as optimum locations to implant malware if those servers are not sufficiently protected. In addition, remote backup servers that employ the same architecture as the primary server are vulnerable to malware that has compromised the primary server. However, if an organization has already invested in backup services (in support of COOP or cybersecurity), those services can be enhanced by requiring an adversary to navigate multiple distinct defenses, authentication challenges (Calibrated Defense-in-Depth approach to Coordinated Protection), or some form of Synthetic Diversity to compensate for known attack vectors.

Contextual Awareness and Analytic Monitoring capabilities are often provided by performance management and cybersecurity functions, including cyber situational awareness, anomaly detection, and performance monitoring. However, the off-the-shelf implementations of these functions are generally insufficient to detect threats from advanced adversaries. Enhancing existing investments in both detection and monitoring by integrating data from sensor and monitor readings from disparate sources is a way to take these existing investments and make them an effective cyber resiliency tool. Another way to make existing technology more cyber-resilient is to complement the existing monitoring services with information from threat intelligence sources, enabling these tools to be better tuned to look for known observables (e.g., indicators of adversary TTPs).

Some approaches to Segmentation and Coordinated Protection appear in information security or cybersecurity. Predefined Segmentation, as reflected in boundary demilitarized zones (DMZs), is a well-established construct in cybersecurity. One important distinction of cyber resiliency is that the segmentation is applied throughout the system, not just at the system boundary. In addition, the Dynamic Segmentation and Isolation approach allows for changing the placement and/or activation of the protected segments. For Coordinated Protection, the defense-in-depth approach is often used for security or system resilience. Ensuring that those protections work in a coordinated fashion is one of the distinguishing aspects of cyber resiliency.

Some cyber resiliency techniques and approaches come from disciplines such as safety or performance management. Diversity and certain implementations of Substantiated Integrity, such as Byzantine quorum systems⁴⁰ or checksums on critical software, can be traced back to the safety discipline.⁴¹ Therefore, systems that have been designed with safety in mind may already have implemented some of these capabilities. However, the safety capabilities were designed with the assumption that they were countering non-adversarial threat events. To make these capabilities useful against the APT, certain changes are needed. From a safety perspective, it may be sufficient to only employ checksums that are polynomial hash-based (e.g., a cyclic redundancy check used to detect accidental changes) on critical software to ensure that the software has not been corrupted over time. However, such checksums are not sufficient when dealing with the APT, which is able to corrupt the software and data and then recalculate or even construct the modified data to duplicate the original checksum. Instead, what is needed in those instances are checksums generated by cryptographic-based secure hash functions that are also cryptographically signed so that they fulfill Integrity Checks and Provenance Tracking to a specified cryptographic strength.

Other capabilities such as Non-Persistence and Adaptive Response are very common in cloud and virtualization architectures. Again, these capabilities were not designed or employed to specifically counter the APT but to facilitate the rapid deployment of implementations. From a system design and implementation perspective, it is easier to employ existing virtualization technology and change the criteria of when and why to refresh critical services (e.g., periodically refresh the software and firmware with the goal of flushing out malware) than it is to deploy Non-Persistence in a system that cannot implement the capability.

Several of the cyber resiliency techniques and approaches are cyber adaptions of non-cyber methods used in adversary-oriented disciplines (e.g., medicine, military, sports). These include the Deception, Unpredictability, and Dynamic Positioning techniques and the Dynamic Threat Awareness and Evolvability approaches. None of those techniques or approaches are used in non-adversarial disciplines. There is no reason in resilience engineering to attempt to “mislead” a hurricane, nor is there any benefit in safety engineering to include an element of purposeful unpredictability. The value of these constructs in non-cyber environments is well established. Because these adversarial-derived techniques and approaches are not typically found in disciplines such as safety, resilience engineering, or COOP, it is much more challenging to provide them by enhancing existing constructs. Therefore, they may be more challenging to integrate into an existing system.

The selection of cyber resiliency techniques or approaches depends, in part, on where (i.e., at what layers, to which components or system elements, at which interfaces between layers or system elements) in the system architecture cyber resiliency solutions can be applied. The set of layers, like the set of system components or system elements, in an architecture depends on the type of system. For example, an embedded system offers a different set of possible locations than an enterprise architecture that includes applications running in a cloud. The set of layers can include an operational (people-and-processes) layer, a support layer (e.g., programmatic, systems engineering, maintenance, and sustainment), and a layer to represent the physical environment.

Different cyber resiliency techniques or approaches lend themselves to implementation at different architectural layers.⁴² Some approaches can be implemented at multiple layers in different ways and with varying degrees of maturity. Other approaches are highly specific to a layer; for example, Asset Mobility is implemented in the operations layer or in the physical environment. For some layers, many approaches may be applicable; for others, relatively few approaches may be available. For example, relatively few approaches can be implemented at the hardware layer. These include Dynamic Reconfiguration, Architectural Diversity, Design Diversity, Replication, Predefined Segmentation, and Integrity Checks.

Similarly, some cyber resiliency approaches lend themselves to specific types of components or system elements. For example, Fragmentation applies to information stores. Some approaches assume that a system element or set of system elements has been included in the architecture specifically to support cyber defense. These include Dynamic Threat Awareness, Forensic and

Behavioral Analysis, and Misdirection. Other cyber resiliency approaches assume that a system element has been included in the architecture, explicitly or virtually, to support the mission, security, or business operations. These include Sensor Fusion and Analysis, Consistency Analysis, Orchestration, and all of the approaches to Privilege Restriction.

Finally, some techniques or approaches lend themselves to implementation at interfaces between layers or between system elements. These include Segmentation, Monitoring and Damage Assessment, and Behavior Validation.

The selection of cyber resiliency techniques and approaches can be motivated by potential effects on adversary activities or on risk. Two resiliency techniques or approaches listed as both potentially having the same effect may differ in how strongly that effect applies to a given threat event, scope (i.e., the set of threat events for which the effect is or can be produced), and affected risk factors. For example, all approaches to Non-Persistence can degrade an adversary’s ability to maintain a covert presence via the malicious browser extension TTP; closing the browser session when it is no longer needed, a use of Non-Persistent Services, degrades the adversary’s activity more than other Non-Persistence approaches do. Some techniques or approaches will affect more risk factors (e.g., reduce the likelihood of impact or reduce the level of impact) than others. The security mechanisms or processes used to implement a particular cyber resiliency approach will also vary with respect to their scope and strength. For example, a Misdirection approach to the Deception technique, implemented via a deception net, and the Sensor Fusion and Analysis approach to Analytic Monitoring, implemented via a holistic suite of intrusion detection systems, will both achieve the detect effect. However, the effectiveness and scope of the two vary widely. For this reason, engineering trade-offs among techniques, approaches, and implementations should consider the actual effects to be expected in the context of the system’s architecture, design, and operational environment.

In general, systems security engineering decisions seek to provide as complete a set of effects as possible and to maximize those effects with the recognition that this optimization problem will not have a single solution. The rationale for selecting cyber resiliency techniques or approaches that have complete coverage of the potential effects relates to the long-term nature of the threat campaigns. Potentially, engagements with the APT may go on for months, if not years, possibly starting while a system is in development or even earlier in the life cycle. Given the nature of the threat, its attacks will likely evolve over time in response to a defender’s actions. Having a selection of techniques and approaches—where each technique and approach supports (to different degrees and in different ways) multiple effects on the adversary, and the union of the techniques and approaches allows for all potential effects on an adversary— provides the systems engineers with the flexibility to evolve and tailor the effects to the adversary’s changing actions. This is analogous to team sports where a team will change its game plan in response to player injuries and the changing game plan of the other team. A team with players who can play multiple positions gives it the flexibility to respond to changes by the opposition and to potentially replace injured players.

Different cyber resiliency techniques and approaches can have different effects on threat events and risk. No single technique or approach can create all possible effects on a threat event, and no technique or approach or set of techniques or approaches can eliminate risk. However, by considering the desired effects, systems engineers can select a set of techniques that will collectively achieve those effects.⁴³

Approaches to applying cyber resiliency techniques vary in maturity and adoption. The decision to use less mature technologies depends on the organization’s risk management strategy and its strategy for managing technical risks. Many highly mature and widely adopted technologies and processes that were developed to meet the general needs of performance, dependability, or security can be used or repurposed to address cyber resiliency concerns. These pose little, if any, technical risk. Changes in operational processes, procedures, and configuration changes may be needed to make these technologies and processes effective against the APT and, thus, part of cyber resiliency solutions.

A growing number of technologies are specifically oriented toward cyber resiliency, including moving target defenses and deception toolkits. These technologies are currently focused on enterprise IT environments. As these technologies become more widely adopted, the decision to include the technologies is influenced more by policy than by technical risk considerations. This is particularly the case for applications of the Deception and Unpredictability cyber resiliency techniques.

Cyber resiliency is an active research area. Technologies are being explored to improve the cyber resiliency of cyber-physical systems, high-confidence, dedicated-purpose systems, and large-scale processing environments. The integration of solutions involving new technologies to reduce risks due to the APT should be balanced against risks associated with perturbing such systems.

In the context of systems security engineering, cyber resiliency analysis is intended to determine whether the cyber resiliency properties and behaviors of a system of interest, regardless of its system life cycle stage, are sufficient for the organization using that system to meet its mission assurance, business continuity, or other security requirements in a threat environment that includes the APT. Cyber resiliency analysis is performed with the expectation that such analysis will support systems engineering and risk management decisions about the system of interest. Depending on the life cycle stage, programmatic considerations, and other factors discussed above, a cyber resiliency analysis could recommend architectural changes, the integration of new products or technologies into the system, changes in how existing products or technologies are used, or changes in operating procedures or environmental protections consistent with and designed to implement the organization’s risk management strategy.

The following subsections describe a general, tailorable process for cyber resiliency analysis consisting of steps and tasks, as summarized in Table 5. A variety of motivations for a cyber resiliency analysis are possible, including ensuring that cyber risks due to the APT are fully considered as part of the RMF process or other risk management process, supporting systems security engineering tasks, and recalibrating assessments of risk and risk responses based on information about new threats (e.g., information about a cyber incident or an APT actor), newly discovered vulnerabilities (e.g., discovery of a common design flaw), and problematic dependencies (e.g., discovery of a supply chain issue). Although described in terms of a broad analytic scope, the process can be tailored to have a narrow scope, such as analyzing the potential cyber resiliency improvement that could be achieved by integrating a specific technology or identifying ways to ensure adequate cyber resiliency against a specific threat scenario.

The analytic processes and practices related to cyber resiliency are intended to be integrated with those for other specialty engineering disciplines, including security, systems engineering, resilience engineering, safety, cybersecurity, and mission assurance.⁴⁴ In addition, analytic processes and practices related to cyber resiliency can leverage system representations offered by model-based systems engineering (MBSE) and analytic methods (including those involving artificial intelligence [AI] and machine learning [ML]) integrated into MBSE. Cyber resiliency analysis, like other types of engineering analysis (e.g., safety, security), should be performed repeatedly throughout the life cycle as changes arise in the operational, technical, and threat environments.

A variety of artifacts can provide information used in a cyber resiliency analysis depending on its scope, the life cycle stage of the system or systems within the scope of the analysis, the step in the RMF of the in-scope system or systems, the extent to which the organization relying on the system or systems has done contingency planning, and (for systems in the Utilization life cycle stage) reports on security posture and incident response. These artifacts can include engineering project plans, system security plans, supply chain risk management plans [SP 800-161], reports on security posture [SP 800-37], penetration test results, contingency plans [SP 800-34], risk analyses [SP 800-30], after-action reports from exercises, incident reports, and recovery plans.

Cyber resiliency analysis complements both system life cycle and RMF tasks. The life cycle and RMF tasks produce information that can be used in cyber resiliency analysis, and cyber resiliency analysis enables cyber risks to be considered more fully in life cycle and RMF tasks.

TABLE 5: TAILORABLE PROCESS FOR CYBER RESILIENCY ANALYSIS

The problem of providing sufficient cyber resiliency properties and behaviors is inherently situated in a programmatic, operational, architectural, and threat context. This step is intended to ensure that the context is sufficiently understood and that cyber resiliency constructs can be interpreted in that context, the relative priorities of cyber resiliency objectives can be assessed, and the applicability of cyber resiliency design principles, techniques, and approaches can be determined. The activities in this step can and should be integrated into activities under the Technical Management Processes in [SP 800-160 v1] and the Prepare and Categorize steps of the RMF [SP 800-37].

The programmatic context identifies how the system of interest is being acquired, developed, modified, or repurposed, including the life cycle stage, life cycle model, or system development approach (e.g., spiral, waterfall, agile, DevOps). Identification of the life cycle stage, life cycle model, and system development approach enables maturity as a consideration in defining cyber resiliency solutions. The programmatic context also identifies the stakeholders for the system of interest, roles and responsibilities related to the system of interest, and entities (organizations, organizational units, or individuals) in those roles.

In particular, the programmatic context identifies the entities responsible for directing, executing, and determining the acceptability of the results of engineering efforts related to the system (e.g., program office, systems engineer, systems integrator, authorizing official, and mission or business function owner). Each of these key stakeholders has a risk management strategy focused on different potential risks (e.g., cost, schedule, and technical or performance risks for a program office or systems engineer; security risks for an authorizing official; mission or business risks for a mission or business function owner). When these entities are part of the same organization, the risk management strategies for their respective areas of responsibility instantiate or are aligned with the organization’s cyber risk management strategy.⁴⁵

Technical or performance risks can include risks that quality properties (e.g., security, safety, system resilience, cyber resiliency) are insufficiently provided, as evidenced by the absence or poor execution of behaviors that should demonstrate those properties. The programmatic risk management strategy can reflect the relative priorities that other stakeholders—in particular, the mission or business process owner and the authorizing official—assign to different quality properties. The programmatic risk management strategy can also include constraints on less mature technologies, less commonly used products, or less commonly applied operational practices as part of managing technical or performance risks.⁴⁶

In addition, other stakeholders may have their own risk management strategies or may be represented by an official within these entities (e.g., a system security officer to represent the security concerns of program managers whose proprietary information is handled by the system of interest) with a corresponding risk management strategy. An appreciation of the different risk management strategies (i.e., how the various stakeholders frame risk, including what threats and potential harms or adverse consequences are of concern to them, what their risk tolerances are, and what risk trade-offs they are willing to make) will enable the threat model to be defined and cyber resiliency constructs to be interpreted and prioritized in subsequent steps.

The programmatic context is not static. Technical, schedule, or security risks can include risks related to other programs or initiatives within the organization, its partners, or its suppliers. The design of the system of interest could assume successful completion of milestones by other programs or initiatives prior to a step in its development, contributing to technical or schedule risks. Schedule slips or failures to meet specific requirements by other programs or initiatives could also increase the attack surface of the system of interest or make it more fragile. Thus, understanding which other programs or initiatives could affect the system of interest is part of identifying the programmatic context.⁴⁷

Identification of the programmatic context highlights the aspects of the programmatic risk management strategy that constrain possible solutions. One aspect is the relative priority of such quality attributes as safety, security, reliability, maintainability, system resilience, and cyber resiliency. Another is the relative preference for operational changes versus technical changes. Depending on the life cycle stage and the programmatic risk management strategy, changes to operational processes and procedures may be preferred to technical changes to the system.

The architectural context identifies the type of system; its architecture or architectural patterns, if already defined; and its interfaces with or dependencies on other systems with consideration of whether it is (or is intended to be) part of a larger system-of-systems or a participant in a larger ecosystem. Key technologies, technical standards, or products included (or expected to be included) in the system are identified. Depending on the life cycle stage, identification of the architectural context can also include system locations, sub-systems or components, or layers in the architecture where cyber resiliency solutions could be applied. If this information is not yet available, it will be developed in a subsequent step.⁴⁸

The identification of the type of system begins with the identification of its general type (e.g., CPS,⁴⁹ application, enterprise service, common infrastructure as part of EIT or LSPE, EIT as a whole, or LSPE as a whole). The type of system determines which cyber resiliency techniques and approaches are most relevant.⁵⁰ Each type of system has an associated set of architectural patterns. For example, a CPS device typically includes a sensor, a controller (which is present in cyberspace), an actuator, and a physical layer. EIT typically includes enterprise services (e.g., identity and access management, mirroring and backup, email), common infrastructures (e.g., an internal communications network, a storage area network, a virtualization, or a cloud infrastructure), a demilitarized zone (DMZ) for interfacing with the Internet, and a collection of enterprise applications.

Identification of other systems with which the system of interest interfaces or on which it depends includes consideration of federation, networking, and scope. Federation typically restricts the set of solutions that can be applied and the metrics that can be defined and used since different system owners may be unwilling or unable to use the same technologies or share certain types or forms of information. Some systems are designed to operate without a network connection, at least transiently and often normally. The cyber resiliency solutions and means of assessing system cyber resiliency or solution effectiveness will be limited by whether the system is operating in detached mode. Depending on the programmatic context, the scope of “other systems” can include those constituting the system’s development, test, or maintenance environment.

The operational context identifies how the system of interest is used or will be used (i.e., its usage context, which is closely related to the architectural context), how it will be administered and maintained (i.e., its support context, which is closely related to the programmatic and architectural contexts), how it interacts with or depends on other systems (i.e., its dependency context), and how usage and dependencies change depending on the time or circumstances (i.e., its temporal context).

The usage context identifies the primary mission or business functions that the system supports, any secondary or supporting missions or business functions, and the criticality and reliability with which the missions or business functions are to be achieved. Thus, the usage context can:

performance, or not performing to the missions it supports, human life or safety, national security, or economic security (e.g., as in the context of critical infrastructure [NIST CSF]).

The usage context also provides a general characterization of the system user population, including its size, scope, and assumed user awareness of and ability to respond to cyber threats. The usage context also indicates whether cyber defenders are actively involved in monitoring the system and responding to indications and warnings (I&W) of adverse conditions or behaviors.

The support context similarly provides a general characterization of the administrative and maintenance population, describes how system maintenance or updates are performed, and describes operational restrictions on maintenance activities or updates. For example, updates to embedded control units (ECUs) in a vehicle should be disallowed when driving. These aspects of the operational context determine the extent to which procedural solutions can be applied to the system of interest.

The dependency context identifies adjacent systems (i.e., systems with which the system of interest is connected, for example, through procedure calls or information sharing); describes the types of information received from, supplied to, or exchanged with those systems; and identifies the criticality of the information connection to the system of interest and to the mission or business functions it supports. The dependency context also identifies infrastructures on which the system of interest depends (e.g., networks, power suppliers, and environmental control systems). These aspects of the operational context are used to bound the scope of the analysis (e.g., whether and for which adjacent or infrastructure systems changes are in scope, whether characteristics and behavior of these systems can be investigated or must be assumed). If the system of interest is part of a system-of-systems or is a participant in a larger ecosystem, the dependency context identifies the implications of aggregation or federation for governance, system administration, and information sharing with other organizations or systems.

The temporal context identifies whether and how the usage and dependency contexts can change, depending on whether the system is operating under normal, stressed, or maintenance conditions; whether the system is being used for one of its secondary purposes; and how the system’s usage and dependencies change over time during the course of executing mission or business functions.

Information about the support and dependency contexts can be used at this point in the analysis to characterize and subsequently identify the system’s attack surfaces.⁵² The operational context can be communicated by defining a motivating operational scenario or a small set of operational scenarios.

The threat context identifies threat sources, threat events, and threat scenarios of concern for the system of interest. In particular, the threat context helps to identify the characteristics and behaviors of adversaries whose attacks would necessarily undermine the system’s ability to execute or support its missions, as well as the characteristics of relevant non-adversarial threats. Adversaries can include insiders as well as individuals or groups located outside of the system’s physical and logical security perimeter. Adversary goals are identified and translated into cyber and mission effects. Adversary behaviors (i.e., threat events, attack scenarios, or TTPs) are also identified.

The threat context can:

A threat model can also include potential threat scenarios related to non-adversarial threat sources. For these threat sources, the scope or scale of effects, duration or time frame, and types of assets affected are identified. If possible, provide a reference to a publicly available description of a similar scenario to serve as an anchoring example.

Depending on its scope and purpose, a cyber resiliency analysis can focus on a single threat scenario. For example, a cyber resiliency analysis can be motivated by a publicized incident with the purpose of the analysis being to determine the extent to which a particular system, mission or business function, or organization could be affected by a similar incident.

To ensure that cyber resiliency concepts and constructs are meaningful in the identified contexts, one or more of the following sub-tasks can be performed:

The determination that some cyber resiliency constructs are not applicable, based on the considerations discussed in Section 3.1, narrows the focus of subsequent steps in the cyber resiliency analysis, which saves work and increases the usefulness of the results.

In order to determine whether cyber resiliency improvement is needed, the baseline for the system (as it is understood at the stage in the life cycle when the cyber resiliency analysis is performed) must be established.

As discussed in Section 3.1.5.1, a system reflects architectural and design decisions and investments in specific technologies and products motivated by other specialty engineering disciplines. Capabilities are identified from such functional areas as COOP and contingency planning; security, cybersecurity, and cyber defense; performance management; reliability, maintainability, and availability (RMA); safety; and survivability. Identification of capabilities can involve decomposition of the system of interest into constituent sub-systems, functional areas, and/or architectural locations.⁵⁶

Capabilities can be characterized in terms of the cyber resiliency techniques and approaches they can implement and/or the cyber resiliency design principles they can be used to apply. Capabilities can also be characterized in terms of how easily their configuration or operational use can be adapted to address specific cyber resiliency concerns, how dynamically they can be reconfigured or repurposed, and how compatible they are with other cyber resiliency techniques and approaches (e.g., deception, unpredictability).

Depending on the life cycle stage, issues may already be tracked, or it may be possible to identify gaps in required capabilities and issues with the system’s design, implementation, or use. Such information can be found in after-action reports from exercises, penetration test reports, incident reports, and reporting related to ongoing assessments and ongoing risk response actions (RMF tasks M-2 and M-3) [SP 800-37]. Security gaps may also have been identified from a coverage analysis with respect to a taxonomy of attack events or TTPs [DHSCDM].

Because senior leadership is often aware of issues and gaps, recommended cyber resiliency solutions will need to be characterized in terms of how and how well the solutions address the issues and gaps, as well as in terms of other benefits that the recommended solutions provide (e.g., improved stability, improved performance).

One or more evaluation criteria are established and used to make an initial assessment. Cyber resiliency can be evaluated in multiple ways, including:

Additional evaluation criteria can consider how well the system meets its security requirements or achieves its security objectives and how well the system satisfies its mission or business function requirements. While such evaluations are independent of cyber resiliency analysis, they can form part of the baseline against which potential solutions can be evaluated.

Stakeholder concerns and priorities are used to determine which (or which combination) of these will be used to evaluate alternative solutions. Approaches to assessment (e.g., scoring systems, qualitative assessment scales, metrics and measures of effectiveness) and candidate metrics can be identified for use in subsequent steps. In addition, evaluation criteria can involve assessments of potential costs in terms of financial investment over subsequent life cycle stages (e.g., acquiring, integrating, operating, and maintaining a cyber resiliency solution), opportunity costs (e.g., constraints on future engineering decisions or system uses), and increased programmatic risk (e.g., potential cost risk, schedule impacts, performance impacts).

In this step, the system is analyzed in its operational context from two perspectives. First, a mission or business function perspective is applied to identify critical resources (i.e., those resources for which damage or destruction would severely impact operations) and sources of system fragility. Second, an adversarial perspective is applied to identify high-value primary and secondary targets of APT actors [OMB M-19-03] and develop representative attack scenarios. Based on this analysis and the results of the previous baseline assessment, opportunities for improvement are identified.

A critical resource can be a resource for which damage (e.g., corruption or reduced availability), denial of service, or destruction results in the inability to complete a critical task. In addition, if a resource is used in multiple tasks, it can be highly critical overall even if it is not critical to any of those functions individually if its damage, denial, or destruction results in a delay for a time-critical mission or business function. Critical resources can be identified using a variety of methods specific to contingency planning, resilience engineering, and mission assurance. These include Criticality Analysis [IR 8179], Mission Impact Analysis (MIA), Business Impact Analysis (BIA) [SP 800-34], Crown Jewels Analysis (CJA), and cyber mission impact analysis (CMIA).

For cyber resiliency analysis, the identification of critical resources is based on an understanding of functional flows or of mission or business function threads. A resource can be highly critical at one point in a functional flow or a mission thread and of very low criticality at other points. A functional flow analysis or a mission thread analysis can reveal such time dependencies.

Systems can also be analyzed to identify sources of fragility or brittleness. While identification of single points of failure is a result of the analysis methods mentioned above, network analysis or graph analysis (i.e., analysis of which system elements are connected, how and how tightly the system elements are connected, and whether some sets of system elements are more central) can determine whether the system is fragile (i.e., whether it will break if a stress beyond a well-defined set is applied). Similarly, graphical analysis of the distribution of different types of components can help determine how easily a given stress (e.g., exploitation of a zero-day vulnerability) could propagate.

Finally, the attack surfaces to which cyber resiliency solutions can be applied can be identified. Information about the programmatic, architectural, and operational context determines which attack surfaces are within the scope of potential cyber resiliency solutions. For example, if the programmatic context determines support systems to be in scope, those systems are an attack surface in addition to the interfaces and procedures by which updates are made to the system of interest; if the system of interest is an enterprise service (architectural context), its interfaces to other services on which it depends as well as to applications which use it are also attack surfaces; if the system has users (operational context), the user community is an attack surface.⁶²

Cyber resiliency analysis assumes an architectural, operational, and threat context for the system being analyzed.⁶³ These contextual assumptions provide the starting point for a detailed analysis of how an adversary could affect the system and thereby cause harm to the mission or business functions it supports, the organization, individuals for whom the system handles PII or whose safety depends on the system, or the operational environment. The attack scenarios of concern that were identified as part of the threat context serve as a starting point.⁶⁴ Depending on the scope of the analysis,⁶⁵ these attack scenarios can be complemented by scenarios driven by adversary goals, scenarios targeting critical assets or high-value assets,⁶⁶ or scenarios that take advantage of sources of fragility.

The adversary perspective (i.e., what harm can be done, how easily, and at what cost to the attacker) can be represented in different ways, depending on the stage of the system life cycle and the corresponding level and amount of information about the system architecture, design, implementation, and operations. At a minimum, an attack scenario can identify stages in the attack (e.g., administer, engage, persist, cause effect, and maintain ongoing presence), the adversary objectives or categories of TTPs at each stage (e.g., reconnaissance, exploitation, lateral movement, denial), and the system elements compromised in each stage. Depending on the system life cycle stage, it may be possible to identify individual TTPs (e.g., pass the hash) or examples of specific malware.⁶⁷

Attack scenarios can be represented as part of a model-based engineering effort; using attack tree or attack graph analysis; in terms of fault tree analysis or failure modes, effects, and criticality analysis (FMECA); or based on the identification of loss scenarios from System-Theoretic Process Analysis (STPA). Common elements across the attack scenarios (e.g., recurring adversary TTPs) can be starting points for identifying potential alternative solutions.

Depending on the scope of the cyber resiliency analysis, attack scenarios can be developed that target supporting systems. Such attack scenarios may be the result of a supply chain risk analysis or a cyber resiliency or cybersecurity analysis of systems or organizations responsible for development, integration, testing, or maintenance.

The identification of potential areas of improvement typically relies on the interpretation and prioritization of cyber resiliency constructs performed earlier.⁶⁸ Potential cyber resiliency techniques or implementation approaches can be identified in system-specific terms, mapped to system elements or architectural layers, and stated as desired improvements to system elements or to the system as a whole. Desired improvements are prioritized based on how and how well they are expected to reduce risks as identified by stakeholders.⁶⁹

In more detail, this task in the analysis process can include the following sub-tasks:

In this step, specific ways to make desired improvements (i.e., architectural changes, ways to implement cyber resiliency techniques in the context of the existing architecture, ways to use existing system capabilities more effectively to improve resilience) are identified and analyzed in terms of potential effectiveness. These specific alternatives form a solution set that will be used in the final step to construct potential courses of action.

Potential applications of cyber resiliency techniques and implementation approaches to the system of interest in its environment of operations in order to provide one or more desired improvements are identified.⁷³ These applications (i.e., potential solutions to the problem of improving mission or operational resilience by improving cyber resiliency) can be purely technical, purely procedural, or combinations of the two.

Potential solutions can incorporate or build on investments from other disciplines.⁷⁴ The set of technologies and products that is available at some level of maturity⁷⁵ for incorporation into the system depends on the system type.⁷⁶ The degree to which relatively immature technologies can be considered depends on the programmatic risk management strategy.⁷⁷

The level of detail with which a potential solution is described depends on how specifically the context was described in the first step.⁷⁸ In particular, if the architectural and operational contexts were described in general terms, potential solutions will necessarily be described at a high level. Alternatively, if the cyber resiliency analysis is being performed for an existing system, a potential solution can be described in terms of specific technologies or products to be integrated into the system, where in the system those technologies will be used, how they will interface with other system elements, configuration settings or ranges of settings for products, and processes or procedures to make effective use of existing or newly acquired technologies.

The description of a potential solution can include identification of the gaps it is expected to address,⁷⁹ the threats (e.g., attack scenarios, adversary objectives or categories of TTPs, or adversary actions) it is intended to address,⁸⁰ or the reduced exposure of critical resources, sources of fragility, or attack surfaces to threats.⁸¹ These different elements of a potential solution’s description can be used to evaluate the solution.⁸²

If programmatic and operational contexts support improvements to supporting systems and processes, the potential applications of cyber resiliency techniques and approaches to these systems and processes are also identified. Such applications can include modifications to contracting to help ensure that controlled unclassified information (CUI) or other sensitive information is protected [SP 800-171], improvements to supply chain risk management (SCRM) as determined by SCRM analysis [SP 800-161], and restrictions on or re-architecting of system development, testing, or maintenance environments to improve the cyber resiliency of those environments.

Potential solutions can be analyzed with respect to one or more criteria.⁸³ Evaluation can employ qualitative or semi-quantitative assessments (using subject matter expert [SME] judgments) or quantitative metrics (evaluated in a model-based environment, laboratory, cyber range, or test environment; metrics to support analysis of alternatives are typically not evaluated in an operational environment). For example, potential solutions can be analyzed to determine:

In addition, the potential costs of a solution can be identified or assessed. The product of this step is a list of alternative solutions, with each alternative characterized (e.g., using a coverage map or a description) or assessed with respect to the identified criteria.

This step results in a plan of action to address recommended implementation approaches. Unless the scope of the cyber resiliency analysis is narrow, the number and variety of potential solutions may be large. Potential solutions that could be implemented at the same time can be constructed and analyzed to ensure compatibility, identify possible synergies, and determine whether specific solutions should be applied sequentially rather than simultaneously. In addition, programmatic and operational risks associated with alternative solutions can be identified.

One or more alternatives (i.e., sets of potential solutions that could be implemented at the same time or sequentially such as in successive spirals) can be identified using either total cost or a requirement for a consistent level of maturity⁸⁶ (e.g., requiring all technical solutions in the set to be available as commercial products by a specific milestone) to bound each set. Where possible, a set of potential solutions should be defined to take advantage of synergies (as discussed in Section 3.1.4 and identified in Appendix D, Table D-3). At a minimum, each set should be analyzed to ensure that there are no internal conflicts. If the solutions in a set are to be implemented sequentially, functional dependencies among those solutions should be identified. In addition, functional dependencies on other system elements (particularly those involving investments due to other disciplines)⁸⁷ should be identified since changes in system elements can be made for a variety of reasons. Finally, functional dependencies on other organizational efforts (e.g., programs, initiatives) should be identified to ensure that changes to the attack surfaces of the system of interest, the organization’s infrastructure and supporting services, and other systems or assets are understood and the associated risks managed.⁸⁸

Each alternative can be assessed or characterized in terms of the evaluation criteria.⁸⁹ To support assessments, the adversarial analysis⁹⁰ can be revisited for each alternative. Due to synergies or other interactions between cyber resiliency techniques, changes in scores, heat maps, or coverage maps must be determined by analysis rather than by simply combining previously determined values. In addition, each alternative should be analyzed to determine whether it makes new attack scenarios (or non-adversarial threat scenarios) possible. If it does, those scenarios should be analyzed to determine whether changes should be made to the alternative.

Each alternative can also be described in terms of the issues it resolves, the gaps it fills,⁹¹ or whether it provides improved protection for critical resources, reduced fragility, or the ability to address threats more effectively. Finally, each alternative can be assessed or described in terms of its effects on programmatic risk (e.g., total costs, changes to schedule risk, changes to technical or performance risk) or other risks of concern to stakeholders. If an alternative diverges from the risk management strategies of one or more stakeholders, this divergence should be noted so that a compensating risk management approach can be made part of the recommendation if the alternative is in fact recommended.

A recommended plan of action resulting from a cyber resiliency analysis can take the form of a set of selected alternatives to be implemented in successive phases. For each phase, the costs, benefits, and risk management approaches can be identified, accompanied by the identification of circumstances that could indicate the need to revisit the recommendations. However, as noted in Section 3.1, a cyber resiliency analysis can be narrowly focused. If this is the case, the recommendations resulting from the analysis will take a form directed by the focus of the analysis.

LAWS, POLICIES, DIRECTIVES, REGULATIONS, STANDARDS, AND GUIDELINES

[FISMA] Federal Information Security Modernization Act (P.L. 113-283), December 2014. https://www.govinfo.gov/app/details/PLAW-113publ283

[FOIA96] Freedom of Information Act (FOIA), 5 U.S.C. § 552, As Amended By Public Law No. 104-231, 110 Stat. 3048, Electronic Freedom of Information Act Amendments of 1996. https://www.govinfo.gov/app/details/PLAW-104publ231

[EO 13800] Executive Order 13800 (2017), Strengthening the Cybersecurity of Federal Networks and Critical Infrastructure. (The White House, Washington, DC), DCPD-201700327, May 11, 2017. https://www.govinfo.gov/app/details/DCPD-201700327

[EO 14028] Executive Order 14028 (2021), Improving the Nation’s Cybersecurity. (The White House, Washington, DC), May 12, 2021. https://www.federalregister.gov/d/2021-10460

[OMB A-130] Office of Management and Budget (2016) Managing Information as a Strategic Resource (The White House, Washington, DC), OMB Circular A-130, July 2016. https://www.whitehouse.gov/sites/whitehouse.gov/files/omb/circulars/A130/a130revised.pdf

[CNSSI 1253] Committee on National Security Systems (2014) Security Categorization and Control Selection for National Security Systems. (National Security Agency, Fort George G. Meade, MD), CNSS Instruction 1253. https://www.cnss.gov/CNSS/issuances/Instructions.cfm

[CNSSI 4009] Committee on National Security Systems (2015) Committee on National Security Systems (CNSS) Glossary. (National Security Agency, Fort George G. Meade, MD), CNSS Instruction 4009. https://www.cnss.gov/CNSS/issuances/Instructions.cfm

[HSPD23] National Security Presidential Directive/NSPD-54 Homeland Security Presidential Directive/HSPD-23, Cybersecurity Policy, January 2008.

[OMB M-19-03] Office of Management and Budget (2018) Management of High Value Assets. (The White House, Washington, DC), OMB Memorandum M-19-03, December 2018. https://www.whitehouse.gov/wp-content/uploads/2018/12/M-19-03.pdf

[PPD8] Presidential Policy Directive (PPD) 8, National Preparedness, March 2011, last published August 2018. https://www.dhs.gov/presidential-policy-directive-8-national-preparedness

[FMRS20] Federal Mission Resilience Strategy 2020, December 2020. https://www.hsdl.org/?view&did=848323

REFERENCES

[PPD21] Presidential Policy Directive (PPD) 21, Critical Infrastructure Security and Resilience, February 2013. https://obamawhitehouse.archives.gov/the-press-office/2013/02/12/presidential-policy-directive-critical-infrastructure-security-and-resil

[IEC 62443-3-3] International Electrotechnical Commission (2013) IEC 62443-3-3:2013, Industrial communication networks – Network and system security – Part 3-3: System security requirements and security levels. https://webstore.iec.ch/publication/7033

[IEC 62443-4-2] International Electrotechnical Commission (2019) IEC 62443-4-2:2019, Security for industrial automation and control systems – Part 4-2: Technical security requirements for IACS components. https://webstore.iec.ch/publication/34421

[ISO 73] International Organization for Standardization (2009) ISO Guide 73:2009 – Risk management – Vocabulary (ISO, Geneva, Switzerland). https://www.iso.org/standard/44651.html

[ISO 15288] International Organization for Standardization/International Electrotechnical Commission/Institute of Electrical and Electronics Engineers (2015) ISO/IEC/IEEE 15288:2015 – Systems and software engineering — Systems life cycle processes (ISO, Geneva, Switzerland). https://www.iso.org/standard/63711.html

[ISO 24765] International Organization for Standardization/International Electrotechnical Commission/Institute of Electrical and Electronics Engineers (2017) ISO/IEC/IEEE 24765-2017 – Systems and software engineering – Vocabulary (ISO, Geneva, Switzerland). https://www.iso.org/standard/71952.html

[FIPS 199] National Institute of Standards and Technology (2004) Standards for Security Categorization of Federal Information and Information Systems. (U.S. Department of Commerce, Washington, DC), Federal Information Processing Standards Publication (FIPS) 199. https://doi.org/10.6028/NIST.FIPS.199

[SP 800-30] Joint Task Force Transformation Initiative (2012) Guide for Conducting Risk Assessments. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-30, Rev. 1. https://doi.org/10.6028/NIST.SP.800-30r1

[SP 800-34] Swanson MA, Bowen P, Phillips AW, Gallup D, Lynes D (2010) Contingency Planning Guide for Federal Information Systems. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-34, Rev. 1, Includes updates as of November 11, 2010. https://doi.org/10.6028/NIST.SP.800-34r1

[SP 800-37] Joint Task Force (2018) Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-37, Rev. 2. https://doi.org/10.6028/NIST.SP.800-37r2

REFERENCES

[SP 800-39] Joint Task Force Transformation Initiative (2011) Managing Information Security Risk: Organization, Mission, and Information System View. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-39. https://doi.org/10.6028/NIST.SP.800-39

[SP 800-53] Joint Task Force Transformation Initiative (2020) Security and Privacy Controls for Information Systems and Organizations. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-53, Rev. 5, Includes updates as of December 10, 2020. https://doi.org/10.6028/NIST.SP.800-53r5

[SP 800-53B] Joint Task Force Transformation Initiative (2019) Control Baselines for Systems and Organizations. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-53B, Includes updates as of December 10, 2020. https://doi.org/10.6028/NIST.SP.800-53B

[SP 800-82] Stouffer KA, Lightman S, Pillitteri VY, Abrams M, Hahn A (2015) Guide to Industrial Control Systems (ICS) Security. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-82, Rev. 2. https://doi.org/10.6028/NIST.SP.800-82r2

[SP 800-88] Kissel R, Regenscheid A, Scholl M, Stine K (2014) Guidelines for Media Sanitization. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-88, Rev. 1. https://doi.org/10.6028/NIST.SP.800-88r1

[SP 800-95] Singhal A, Winograd T, Scarfone KA (2007) Guide to Secure Web Services. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-95. https://doi.org/10.6028/NIST.SP.800-95

[SP 800-125B] Chandramouli R (2016) Secure Virtual Network Configuration for Virtual Machine (VM) Protection. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-125B. https://doi.org/10.6028/NIST.SP.800-125B

[SP 800-160 v1] Ross RS, Oren JC, McEvilley M (2016) Systems Security Engineering: Considerations for a Multidisciplinary Approach in the Engineering of Trustworthy Secure Systems. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-160, Vol. 1, Includes updates as of March 21, 2018. https://doi.org/10.6028/NIST.SP.800-160v1

[SP 800-161] Boyens JM, Paulsen C, Moorthy R, Bartol N (2015) Supply Chain Risk Management Practices for Federal Information Systems and Organizations. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-161. https://doi.org/10.6028/NIST.SP.800-161

REFERENCES

[SP 800-171] Ross RS, Dempsey KL, Viscuso P, Riddle M, Guissanie G (2016) Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-171, Rev. 1, Includes updates as of June 7, 2018. https://doi.org/10.6028/NIST.SP.800-171r1

[SP 800-183] Voas, J (2016) Networks of ‘Things’. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-183. https://doi.org/10.6028/NIST.SP.800-183

[SP 800-207] Rose S, Borchert O, Mitchell S, Connelly S (2020) Zero Trust Architecture.

(National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-207. https://doi.org/10.6028/NIST.SP.800-207

[SP 1500-201] Burns MJ, Greer C, Griffor ER, Wollman DA (2017) Framework for Cyber-Physical Systems: Volume 1, Overview, Version 1.0. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 1500-201. https://doi.org/10.6028/NIST.SP.1500-201

[SP 1190]

Butry D, et al. (2016) Community Resilience Planning Guide for Buildings and Infrastructure Systems, Volume I. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 1190, Vol. 1. https://doi.org/10.6028/NIST.SP.1190v1

[IR 8179]

Paulsen C, Boyens JM, Bartol N, Winkler K (2018) Criticality Analysis Process Model: Prioritizing Systems and Components. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Interagency or Internal Report (IR) 8179. https://doi.org/10.6028/NIST.IR.8179

[IR 8202]

Yaga DJ, Mell PM, Roby N, Scarfone KA (2018) Blockchain Technology Overview. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Interagency or Internal Report (IR) 8202. https://doi.org/10.6028/NIST.IR.8202

[IR 8259]

Fagan M, Megas KN, Scarfone KA, Smith M (2019) Foundational Cybersecurity Activities for IoT Device Manufacturers. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Interagency or Internal Report (IR) 8259. https://doi.org/10.6028/NIST.IR.8259

[IR 8286]

Stine K, Quinn S, Witte G, Gardner RK (2020) Integrating Cybersecurity and Enterprise Risk Management (ERM). (National Institute of Standards and Technology, Gaithersburg, MD), NIST Interagency or Internal Report (IR) 8286. https://doi.org/10.6028/NIST.IR.8286

[IR 8301]

Lesavre L, Varin P, Yaga D (2021) Blockchain Networks: Token Design and Management Overview. National Institute of Standards and Technology, Gaithersburg, MD), NIST Interagency or Internal Report (IR) 8301. https://doi.org/10.6028/NIST.IR.8301

REFERENCES

[IR 8360]

Hu VC (2021) Machine Learning for Access Control Policy Verification. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Interagency or Internal Report (IR) 8360. https://doi.org/10.6028/NIST.IR.8360

[MIL-STD-882E] Department of Defense (2012) MIL-STD-882E – Standard Practice: System Safety (U.S. Department of Defense, Washington, DC).

https://www.dau.edu/cop/armyesoh/DAU%20Sponsored%20Documents/MIL-STD-882E.pdf

[Avizienis04] Avižienis A, Laprie JC, Randell B (2004) Dependability and Its Threats: A Taxonomy. Building the Information Society, IFIP International Federation for Information Processing, ed Jacquart R (Springer, Boston, MA), Vol. 156, pp 91-120. https://doi.org/10.1007/978-1-4020-8157-6_13

[Bodeau11] Bodeau D, Graubart R (2011) Cyber Resiliency Engineering Framework, Version 1.0. https://www.mitre.org/sites/default/files/pdf/11_4436.pdf

[Bodeau15] Bodeau D, Graubart R, Heinbockel W, Laderman E (2015) Cyber Resiliency Engineering Aid – The Updated Cyber Resiliency Engineering Framework and Guidance on Applying Cyber Resiliency Techniques. (The MITRE Corporation, Bedford, MA), MITRE Technical Report MTR-140499R1. http://www.mitre.org/sites/default/files/publications/pr-15-1334-cyber-resiliency-engineering-aid-framework-update.pdf

[Bodeau16] Bodeau D, Graubart R (2016) Cyber Prep 2.0: Motivating Organizational Cyber Strategies in Terms of Threat Preparedness. (The MITRE Corporation, Bedford, MA), MITRE Technical Report MTR-150264.

https://www.mitre.org/sites/default/files/publications/15-0797-cyber-prep-2-motivating-organizational-cyber-strategies.pdf

[Bodeau17] Bodeau D, Graubart R (2017) Cyber Resiliency Design Principles: Selective Use Throughout the Life Cycle and in Conjunction with Related Disciplines. (The MITRE Corporation, Bedford, MA), MITRE Technical Report MTR-170001. https://www.mitre.org/sites/default/files/publications/PR%2017-0103%20Cyber%20Resiliency%20Design%20Principles%20MTR17001.pdf

[Bodeau18a] Bodeau DJ, McCollum CD, Fox DB (2018) Cyber Threat Modeling: Survey, Assessment, and Representative Framework. (The MITRE Corporation, McLean, VA), PR 18-1174. https://www.mitre.org/sites/default/files/publications/pr_18-1174-ngci-cyber-threat-modeling.pdf

REFERENCES

[Bodeau18b] Bodeau D, Graubart R, McQuaid R, Woodill J (2018) Cyber Resiliency Metrics, Measures of Effectiveness, and Scoring: Enabling Systems Engineers and Program Managers to Select the Most Useful Assessment Methods. (The MITRE Corporation, Bedford, MA), MITRE Technical Report MTR-180314. https://www.mitre.org/sites/default/files/publications/pr-18-2579-cyber-resiliency-metrics-measures-of-effectiveness-and-scoring.pdf

[Bodeau21] Bodeau D, Graubart R, Jones LK, Laderman E (2021). Cyber Resiliency Approaches and Controls to Mitigate Adversary Tactics, Techniques, and Procedures (TTPs): Mapping Cyber Resiliency to the ATT&CK® Framework – Revision 2. (The MITRE Corporation, Bedford, MA), MITRE Technical Report MTR-200286R2.

[Brtis16] Brtis J (2016) How to Think about Resilience in a DoD Context. (The MITRE Corporation, Colorado Springs, CO), MITRE Technical Report MTR-160138.

[CISA HVA] Cybersecurity and Infrastructure Security Agency, Secure High Value Assets. https://www.cisa.gov/publication/secure-high-value-assets

[Clemen13] Clemen RT, Reilly T (2013) Making Hard Decisions with the Decision Tools Suite (South-Western Cengage Learning, Mason, OH), 3rd Ed., pp 848.

[DHS10] Department of Homeland Security Risk Steering Committee (2010) DHS Risk Lexicon. (U.S. Department of Homeland Security, Washington, DC), 2010 Edition. https://www.dhs.gov/xlibrary/assets/dhs-risk-lexicon-2010.pdf

[DHSCDM] Department of Homeland Security, “CDM Program What is .govCAR?” https://www.cisa.gov/sites/default/files/publications/2020%2009%2003_%20CDM%20Program%20govCAR_Fact%20Sheet_2.pdf

[DOD20] Department of Defense, “Department of Defense Cybersecurity Test and Evaluation Guidebook,” Version 2.0, Change 1, February 2020. https://www.dau.edu/cop/test/DAU%20Sponsored%20Documents/Cybersecurity-Test-and-Evaluation-Guidebook-Version2-change-1.pdf

[DOD16] Department of Defense (2016) Mission Assurance (U.S. Department of Defense, Washington, DC), DoD Directive (DODD) 3020.40. https://www.esd.whs.mil/Portals/54/Documents/DD/issuances/dodd/302040p.pdf?ver=2018-09-11-131221-983

[DSB13] Defense Science Board (2013) Resilient Military Systems and the Advanced Cyber Threat. (U.S. Department of Defense, Washington, DC). https://dsb.cto.mil/reports/2010s/ResilientMilitarySystemsCyberThreat.pdf

[Folk15] Folk C, Hurley DC, Kaplow WK, Payne JF (2015) The Security Implications of the Internet of Things. (AFCEA International Cyber Committee). https://www.afcea.org/site/sites/default/files/files/AFC_WhitePaper_Revised_Out.pdf

REFERENCES

[GAO18] Government Accountability Office (2018) Weapon Systems Cybersecurity. (Government Accountability Office, Washington, DC), GAO-19-128, October 2018. https://www.gao.gov/assets/700/694913.pdf

[Heckman15] Heckman KE, Stech FJ, Thomas RK, Schmoder B, Tsow AW (2015) Cyber Denial, Deception and Counter Deception: A Framework for Supporting Active Cyber Defense, Advances in Information Security (Springer, Cham, Switzerland), Vol. 63.

[Höller15] Höller A, Rauter T, Iber J, Kreiner C (2015) Towards Dynamic Software Diversity for Resilient Redundant Embedded Systems. Proceedings of Software Engineering for Resilient Systems: 7th International Workshop, SERENE 2015 (Springer, Paris, France), pp 16-30. https://doi.org/10.1007/978-3-319-23129-7_2

[Hutchins11] Hutchins EM, Cloppert MJ, Amin RM (2011) Intelligence-driven computer network defense informed by analysis of adversary campaigns and intrusion kill chains. Leading Issues in Information Warfare & Security Research, ed Ryan J (Academic Publishing International, Reading, UK), Vol. 1, pp 78-104.

[IEEE90] Institute of Electrical and Electronics Engineers (1990) IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries, (IEEE, New York, NY).

[IEEE17] Institute of Electrical and Electronics Engineers, Association for Computing Machinery (2017) Enterprise IT Body of Knowledge – Glossary. Enterprise IT Body of Knowledge. http://eitbokwiki.org/Glossary#eit

[INCOSE11] International Council for Systems Engineering (2011) Resilient Systems Working Group Charter. (INCOSE, San Diego, CA).

[INCOSE14] International Council on Systems Engineering (2015) System Engineering Handbook—A Guide for System Engineering Life Cycle Processes and Activities. (John Wiley & Sons, Hoboken, NJ), 4th Ed.

[ISACA] ISACA (2019) ISACA Glossary of Terms. https://www.isaca.org/pages/glossary.aspx

[Jackson07] Jackson S (2007) A Multidisciplinary Framework for Resilience to Disasters and Disruptions. Transactions of the Society for Design and Process Science 11(2):91-108.

[Jackson13] Jackson S, Ferris T (2013) Resilience Principles for Engineered Systems. Systems Engineering 16(2): 152-164.

Systems Engineering 16(2): 152-164.

[Jajodia11] Jajodia S, Ghosh AK, Swarup V, Wang C, Wang XS (eds.) (2011) Moving Target Defense: Creating Asymmetric Uncertainty for Cyber Threats (Springer-Verlag, New York, NY), Advances in Information Security, Vol. 54, pp 184. https://doi.org/10.1007/978-1-4614-0977-9

REFERENCES

[Jajodia12] Jajodia S, Ghosh AK, Subrahmanian VS, Swarup V, Wang C, Wang XS (eds.) (2013) Moving Target Defense II: Application of Game Theory and Adversarial Modeling (Springer-Verlag, New York, NY), Advances in Information Security, Vol. 100, pp 204.

[JCS17] Joint Chiefs of Staff (2017) Cyber Survivability Endorsement Implementation Guide (CSEIG). (U.S. Department of Defense, Washington, DC), v1.01.

[King12] King S (2012) National and Defense S&T Strategies & Initiatives.

[Leveson12] Leveson NG (2012) Engineering a Safer World: Systems Thinking Applied to Safety (MIT Press, Cambridge, MA), pp 560.

[Madni07] Madni AM (2007) Designing for Resilience. ISTI Lecture Notes on Advanced Topics in Systems Engineering (University of California at Los Angeles (UCLA), Los Angeles, CA).

[Madni09] Madni AM, Jackson S (2009) Towards a Conceptual Framework for Resilience Engineering, IEEE Systems Journal 3(2):181-191.

[MITRE07] The MITRE Corporation (2019) Common Attack Pattern Enumeration and Classification (CAPEC). https://capec.mitre.org/index.html

[MITRE18] The MITRE Corporation (2018) Adversarial Tactics, Techniques & Common Knowledge (ATT&CK™). https://attack.mitre.org

[MITRE21] The MITRE Corporation (2021) CALDERA™: A Scalable, Automated Adversary Emulation Platform. https://caldera.mitre.org

[Musman18] Musman S, Agbolosu-Amison S, Crowther K (2019) Metrics Based on the Mission Risk Perspective. Cyber Resilience of Systems and Networks, eds Kott A, Linkov I (Springer International Publishing, Cham, Switzerland) Chapter 3, pp 41-65. https://doi.org/10.1007/978-3-319-77492-3

[NASA19] National Aeronautics and Space Administration (2019) Systems Engineering Handbook, Section 6.4: Technical Risk Management. https://www.nasa.gov/seh/6-4-technical-risk-management

[Neumann04] Neumann P (2004) Principled Assuredly Trustworthy Composable Architectures. (SRI International, Menlo Park, CA), CDRL A001 Final Report. http://www.csl.sri.com/users/neumann/chats4.pdf

[NIAC10] National Infrastructure Advisory Council (NIAC) (2010) A Framework for Establishing Critical Infrastructure Resilience Goals: Final Report and Recommendations by the Council. (U.S. Department of Homeland Security, Washington, DC). https://www.dhs.gov/xlibrary/assets/niac/niac-a-framework-for-establishing-critical-infrastructure-resilience-goals-2010-10-19.pdf

REFERENCES

[NIST16] National Institute of Standards and Technology Workshop (2016) Exploring the Dimensions of Trustworthiness: Challenges and Opportunities. https://www.nist.gov/news-events/events/2016/08/exploring-dimensions-trustworthiness-challenges-and-opportunities

[NIST CSF] National Institute of Standards and Technology (2018) Framework for Improving Critical Infrastructure Cybersecurity, Version 1.1. (National Institute of Standard, Gaithersburg, MD). https://doi.org/10.6028/NIST.CSWP.04162018

[ODNI17] Office of the Director of National Intelligence (2017) Cyber Threat Framework. https://www.dni.gov/index.php/cyber-threat-framework

[Okhravi13] Okhravi H, Rabe MA, Mayberry TJ, Leonard WG, Hobson TR, Bigelow D, Streilein WW (2013) Survey of Cyber Moving Targets. (Lincoln Laboratory, Lexington, MA), Technical Report 1166. http://web.mit.edu/ha22286/www/papers/LLTechRep.pdf

[Pitcher19] Pitcher S (2019) New DoD Approaches on the Cyber Survivability of Weapon Systems [presentation]. https://www.itea.org/wp-content/uploads/2019/03/Pitcher-Steve.pdf

[Pitcher21] Pitcher S, Andress T (2021) Cyber Survivability for Future and Legacy DoD Weapon Systems [presentation]. https://www.ndia.org/-/media/sites/ndia/divisions/systems-engineering/se---june-2021-meeting/cse-support-to-future-and-legacy-dod-systems-10-jun-2021-for-ndia.ashx

[Reilly19] Reilly J (2019) Cyber Survivability Attributes: CSA Tool (8ABW-2019-2267) (Air Force Research Laboratory, Rome, NY).

[Ricci14] Ricci N, Rhodes DH, Ross AM (2014) Evolvability-Related Options in Military Systems of Systems. Procedia Computer Science 28:314-321. https://doi.org/10.1016/j.procs.2014.03.039

[Richards08] Richards MG, Ross AM, Hastings DE, Rhodes DH (2008) Empirical Validation of Design Principles for Survivable System Architecture. Proceedings of the 2nd Annual IEEE Systems Conference, (IEEE, Montreal, Quebec, Canada), pp 1-8. https://doi.org/10.1109/SYSTEMS.2008.4518999

[Richards09] Richards MG, Hastings DE, Rhodes DH, Ross AM, Weigel AL (2009) Design for Survivability: Concept Generation and Evaluation in Dynamic Tradespace Exploration. Second International Symposium on Engineering Systems (Massachusetts Institute of Technology, Cambridge, MA). https://pdfs.semanticscholar.org/3734/7b58123c16e84e2f51a4e172ddee0a8755c0.pdf

REFERENCES

[SEBoK] BKCASE Editorial Board (2019) The Guide to the Systems Engineering Body of Knowledge (SEBoK), v. 2.0, ed Cloutier RJ (The Trustees of the Stevens Institute of Technology, Hoboken, NJ). BKCASE is managed and maintained by the Stevens Institute of Technology Systems Engineering Research Center, the International Council on Systems Engineering, and the Institute of Electrical and Electronics Engineers Computer Society. https://www.sebokwiki.org/wiki/Guide_to_the_Systems_Engineering_Body_of_Knowledge_(SEBoK)

[Sheard08] Sheard S (2008) A Framework for System Resilience Discussions. INCOSE International Symposium 18 (Wiley, Utrecht, The Netherlands), pp 1243–1257. https://doi.org/10.1002/j.2334-5837.2008.tb00875.x

[Shetty16] Shetty S, Yuchi X, Song M (2016) Moving Target Defense for Distributed Systems (Springer International, Switzerland), pp 76. https://doi.org/10.1007/978-3-319-31032-9

[Sterbenz06] Sterbenz J, Hutchinson D (2006) ResiliNets: Multilevel Resilient and Survivable Networking Initiative.

[Sterbenz10] Sterbenz JPG, Hutchison D, Çetinkaya EK, Jabbar A, Rohrer JP, Schöller M, Smith P (2010) Resilience and survivability in communication networks: Strategies, principles, and survey of disciplines. Computer Networks 54:1245-1265. http://www.ittc.ku.edu/resilinets/papers/Sterbenz-Hutchison-Cetinkaya-Jabbar-Rohrer-Scholler-Smith-2010.pdf

[Sterbenz14] Sterbenz JP, Hutchison D, Çetinkaya EK, Jabbar A, Rohrer JP, Schöller M, Smith P (2014) Redundancy, diversity, and connectivity to achieve multilevel network resilience, survivability, and disruption tolerance. Journal of Telecommunications Systems 56(1):17-31. https://doi.org/10.1007/s11235-013-9816-9

[Strom17] Strom BE, Battaglia JA, Kemmerer MS, Kupersanin W, Miller DP, Wampler C, Whitley SM, Wolf RD (2017) Finding Cyber Threats with ATT&CK-Based Analytics. (The MITRE Corporation, Annapolis Junction, MD), MITRE Technical Report MTR-170202. https://www.mitre.org/sites/default/files/publications/16-3713-finding-cyber-threats%20with%20att%26ck-based-analytics.pdf

[Temin10] Temin A, Musman S (2010) A Language for Capturing Cyber Impact Effects. (The MITRE Corporation, Bedford, MA), MITRE Technical Report MTR-100344.

[Zimmerman14] Zimmerman C (2014) Ten Strategies of a World-Class Cybersecurity Operations Center. (The MITRE Corporation, Bedford, MA). http://www.mitre.org/sites/default/files/publications/pr-13-1028-mitre-10-strategies-cyber-ops-center.pdf

REFERENCES

Appendix A provides definitions for terminology used in NIST SP 800-160, Volume 2. Sources for terms used in this publication are cited as applicable. Where no citation is noted, the source of the definition is SP 800-160, Volume 2.

adaptability — The property of an architecture, design, and implementation that can accommodate changes to the threat model, mission or business functions, systems, and technologies without major programmatic impacts.

advanced cyber threat — See advanced persistent threat. Note 1: The phrase “advanced cyber threat” implies either that an adversary executes a cyber-attack or that an adversary subverts the supply chain in order to compromise cyber resources.

advanced persistent threat [SP 800-39] — An adversary that possesses sophisticated levels of expertise and significant resources that allow it to create opportunities to achieve its objectives by using multiple attack vectors including, for example, cyber, physical, and deception. These objectives typically include establishing and extending footholds within the IT infrastructure of the targeted organizations for purposes of exfiltrating information, undermining or impeding critical aspects of a mission, program, or organization, or positioning itself to carry out these objectives in the future. The advanced persistent threat pursues its objectives repeatedly over an extended period; adapts to defenders’ efforts to resist it; and is determined to maintain the level of interaction needed to execute its objectives. Note 1: While some sources define APT (or advanced cyber threat) as an adversary at Tier V or Tier VI in the threat model in [DSB13]—in particular, to be a state actor—the definition used here includes criminal actors. Note 2: For brevity, “the APT” refers to any adversary with the characteristics described above or to the set of all such adversaries; “an APT actor” refers to a representative member of that set. Note 3: The APT may establish its foothold by subverting the supply chain in order to compromise cyber resources. Thus, the APT may be able to achieve its objectives without executing a cyber-attack against the organization’s systems (e.g., by inserting a logic bomb or time). Note 4: The term “APT” does not include the insider threat. However, if an APT actor establishes and extends its foothold by masquerading as a legitimate system user and taking advantage of that user’s authorized access privileges, it may be indistinguishable from an insider threat.

adversity — Adverse conditions, stresses, attacks, or compromises. Note 1: The definition of adversity is consistent with the use of the term in [SP 800-160 v1] as disruptions, hazards, and threats. Note 2: Adversity in the context of the definition of cyber resiliency specifically includes but is not limited to cyber-attacks.

agility — The property of a system or an infrastructure that can be reconfigured, in which resources can be reallocated, and in which components can be reused or repurposed so that cyber defenders can define, select, and tailor cyber courses of action for a broad range of disruptions or malicious cyber activities.

approach — See cyber resiliency implementation approach.

asset [SP 800-160 v1] — An item of value to stakeholders. An asset may be tangible (e.g., a physical item such as hardware, firmware, computing platform, network device, or other technology component) or intangible (e.g., humans, data, information, software, capability, function, service, trademark, copyright, patent, intellectual property, image, or reputation). The value of an asset is determined by stakeholders in consideration of loss concerns across the entire system life cycle. Such concerns include but are not limited to business or mission concerns.

attack surface [SP 800-53, adapted] — The set of points on the boundary of a system, a system element, or an environment where an attacker can try to enter, cause an effect on, or extract data from. Note: An attack surface can be reduced by removing points on the boundary (reducing the extent of the attack surface, such as by reducing the amount of code running) or reducing the exposure of some points to an attacker (e.g., by placing inessential functions on a different system element than essential functions, by layering defenses, by reducing the period of exposure); changed by changing the set of points on the boundary (e.g., by moving some points), by changing the exposure of some points to an attacker (e.g., by adding logic to check data or commands), or by changing the properties of some points (e.g., by applying principles of least privilege and least functionality); or disrupted by making changes unpredictably or by reducing its extent or exposure for limited time periods (e.g., by temporarily isolating components).

authorization [CNSSI 4009] — Access privileges granted to a user, program, or process or the act of granting those privileges.

blockchain [IR 8202] [IR 8301] — A distributed digital ledger of cryptographically-signed transactions that are grouped into blocks. Each block is cryptographically linked to the previous one (making it tamper evident) after validation and undergoing a consensus decision. As new blocks are added, older blocks become more difficult to modify (creating tamper resistance). New blocks are replicated across copies of the ledger within the network, and any conflicts are resolved automatically using established rules.

boundary [CNSSI 4009] — A physical or logical perimeter of a system.

contested cyber environment — An environment in which APT actors, competing entities, and entities with similar resource needs contend for control or use of cyber resources.

control [ISACA] — The means of managing risk, including policies, procedures, guidelines, practices, or organizational structures, which can be of an administrative, technical, management, or legal nature. Note: See security control.

criticality [SP 800-160 v1] — An attribute assigned to an asset that reflects its relative importance or necessity in achieving or contributing to the achievement of stated goals.

cyber incident [CNSSI 4009] — Actions taken through the use of an information system or network that result in an actual or potentially adverse effect on an information system, network, and/or the information residing therein.

cyber resiliency — The ability to anticipate, withstand, recover from, and adapt to adverse conditions, stresses, attacks, or compromises on systems that use or are enabled by cyber resources. Cyber resiliency is intended to enable mission or business objectives that depend on cyber resources to be achieved in a contested cyber environment. Note: Cyber resiliency can be a property of a system, network, service, system-of-systems, mission or business function, organization, critical infrastructure sector or sub-sector, region, or nation.

cyber resiliency concept — A concept related to the problem domain and/or solution set for cyber resiliency. Cyber resiliency concepts are represented in cyber resiliency risk models as well as by cyber resiliency constructs.

cyber resiliency construct — Element of the cyber resiliency engineering framework (i.e., a goal, objective, technique, implementation approach, or design principle). Additional constructs (e.g., sub-objectives or methods, capabilities or activities) may be used in some modeling and analytic practices.

cyber resiliency control — A control (i.e., a base control or a control enhancement), as defined in [SP 800-53], that applies one or more cyber resiliency techniques or approaches or that is intended to achieve one or more cyber resiliency objectives.

cyber resiliency design principle — A guideline for how to select and apply cyber resiliency analysis methods, techniques, approaches, and solutions when making architectural or design decisions.

cyber resiliency engineering practice — A method, process, modeling technique, or analytical technique used to identify and analyze cyber resiliency solutions.

cyber resiliency goal — A high-level statement supporting (or focusing on) one aspect (i.e., anticipate, withstand, recover, adapt) in the definition of cyber resiliency.

cyber resiliency implementation approach — A subset of the technologies and processes of a cyber resiliency technique defined by how the capabilities are implemented or how the intended consequences are achieved.

cyber resiliency objective — A statement of what must be performed (e.g., what a system must achieve in its operational environment and throughout its life cycle) to meet stakeholder needs for mission assurance and resilient security.

cyber resiliency risk model — A risk model that explicitly represents the threats and classes of harm considered by those concerned with cyber resiliency. (This accommodates other stakeholders in addition to systems security engineers.)

Note: A cyber resiliency risk model emphasizes (but is not limited to) the APT as a threat source and emphasizes the effects of malicious cyber activities on missions, organizations, and systems that include cyber resources.

cyber resiliency solution — A combination of technologies, architectural decisions, systems engineering processes, and operational processes, procedures, or practices that solves a problem in the cyber resiliency domain. A cyber resiliency solution provides enough cyber resiliency to meet stakeholder needs and to reduce risks to mission or business capabilities in the presence of advanced persistent threats.

cyber resiliency sub-objective — A statement, subsidiary to a cyber resiliency objective, that emphasizes different aspects of that objective or identifies methods to achieve that objective.

cyber resiliency technique — A set or class of technologies and processes intended to achieve one or more objectives by providing capabilities to anticipate, withstand, recover from, and adapt to adverse conditions, stresses, attacks, or compromises on systems that include cyber resources. The definition or statement of a technique describes the capabilities it provides and/or the intended consequences of using the technologies or processes it includes.

cyber resource — An information resource that creates, stores, processes, manages, transmits, or disposes of information in electronic form, and that can be accessed via a network or using networking methods.

Note: A cyber resource is an element of a system that exists in or intermittently includes a presence in cyberspace.

cyber risk — The risk of depending on cyber resources (i.e., the risk of depending on a system or system elements that exist in or intermittently have a presence in cyberspace).

Note: Cyber risk overlaps with security risk [SP 800-160 v1], information security risk [SP 800-30] [CNSSI 4009], and cybersecurity risk [IR 8286], and includes risks due to cyber incidents, cybersecurity events, and cyberspace attacks.

cybersecurity [NIST CSF] — The process of protecting information by preventing, detecting, and responding to attacks.

[CNSSI 4009] — Prevention of damage to, protection of, and restoration of computers, electronic communications systems, electronic communications services, wire communication, and electronic communication, including information contained therein, to ensure its availability, integrity, authentication, confidentiality, and nonrepudiation.

cybersecurity event [NIST CSF] — A cybersecurity change that may have an impact on organizational operations (including mission, capabilities, or reputation).

cyberspace [CNSSI 4009] [HSPD23] — The interdependent network of information technology infrastructures that includes the Internet, telecommunications networks, computer systems, and embedded processors and controllers in critical industries.

cyberspace attack [CNSSI 4009] — Cyberspace actions that create various direct denial effects (i.e., degradation, disruption, or destruction) and manipulation that leads to denial and that is hidden or that manifests in the physical domains.

cyber survivability [Pitcher21] — The ability of warfighter systems to prevent, mitigate, recover from and adapt to adverse cyber-events that could impact mission-related functions by applying a risk-managed approach to achieve and maintain an operationally relevant risk posture throughout its life cycle.

damage — Harm caused to something in such a way as to reduce or destroy its value, usefulness, or normal function.

Note 1: From the perspective of cyber resiliency, damage can be to the organization (e.g., loss of reputation, increased existential risk), organizational missions or business functions (e.g., decrease in the ability to complete the current mission and to accomplish future missions), security (e.g., decrease in the ability to achieve the security objectives of confidentiality, integrity, and availability or to prevent, detect, and respond to cyber incidents), the system (e.g., decrease in the ability to meet system requirements, unauthorized use of system resources); or specific system elements (e.g., physical destruction; corruption, modification, or fabrication of information).

Note 2: Damage includes, and in some circumstances can be identified with, asset loss as discussed in [SP 800-160 v1].

design principle — A distillation of experience designing, implementing, integrating, and upgrading systems that systems engineers and architects can use to guide design decisions and analysis. A design principle typically takes the form of a terse statement or a phrase identifying a key concept, accompanied by one or more statements that describe how that concept applies to system design (where “system” is construed broadly to include operational processes and procedures, and may also include development and maintenance environments).

enabling system [ISO 15288] — A system that provides support to the life cycle activities associated with the system of interest. Enabling systems are not necessarily delivered with the system of interest and do not necessarily exist in the operational environment of the system of interest.

enterprise information technology [IEEE17] — The application of computers and telecommunications equipment to store, retrieve, transmit, and manipulate data, in the context of a business or other enterprise.

fault tolerant [SP 800-82] — Of a system, having the built-in capability to provide continued, correct execution of its assigned function in the presence of a hardware and/or software fault.

federation [SP 800-95] — A collection of realms (domains) that have established trust among themselves. The level of trust may vary but typically includes authentication and may include authorization.

high-value asset [CISA HVA] — Information or an information system that is so critical to an organization that the loss or corruption of this information or loss of access to the system would have serious impacts on the organization’s ability to perform its mission or conduct business.

information resources [OMB A-130] — Information and related resources, such as personnel, equipment, funds, and information technology.

information security [OMB A-130] — The protection of information and information systems from unauthorized access, use, disclosure, disruption, modification, or destruction in order to provide confidentiality, integrity, and availability.

information system [OMB A-130] — A discrete set of information resources organized for the collection, processing, maintenance, use, sharing, dissemination, or disposition of information.

Note: Information systems also include specialized systems such as industrial/process controls systems, telephone switching and private branch exchange (PBX) systems, and environmental control systems.

information technology [OMB A-130] — Any services, equipment, or interconnected system(s) or subsystem(s) of equipment, that are used in the automatic acquisition, storage, analysis, evaluation, manipulation, management, movement, control, display, switching, interchange, transmission, or reception of data or information by the agency. For purposes of this definition, such services or equipment if used by the agency directly or is used by a contractor under a contract with the agency that requires its use; or to a significant extent, its use in the performance of a service or the furnishing of a product. Information technology includes computers, ancillary equipment (including imaging peripherals, input, output, and storage devices necessary for security and surveillance), peripheral equipment designed to be controlled by the central processing unit of a computer, software, firmware and similar procedures, services (including cloud computing and help-desk services or other professional services which support any point of the life cycle of the equipment or service), and related resources. Information technology does not include any equipment that is acquired by a contractor incidental to a contract which does not require its use.

mission assurance [DOD16, adapted] — A process to protect or ensure the continued function and resilience of capabilities and assets—including personnel, equipment, facilities, networks, information and information systems, infrastructure, and supply chains—critical to the execution of organizational mission-essential functions in any operating environment or condition.

Note: This definition differs from the DoD definition by replacing “DoD” with “organizational.”

mission resilience [FMRS20, adapted] — The ability to continuously maintain the capability and capacity to perform essential functions and services, without time delay, regardless of threats or conditions, and with the understanding that adequate warning of a threat may not be available.

Note: This definition differs from the source definition by omitting “of the Federal executive branch” after “the ability.” Because essential functions and services are performed using systems, mission resilience can often be identified with operational resilience; usage depends on the intended emphasis.

mitigation — A decision, action, or practice intended to reduce the level of risk associated with one or more threat events, threat scenarios, or vulnerabilities.

non-adversarial threat — A threat associated with accident or human error, structural failure, or environmental causes.

Note: See [SP 800-30].

operational resilience [CNSSI 4009] — The ability of systems to resist, absorb, and recover from, or adapt to an adverse occurrence during operation that may cause harm, destruction, or loss of the ability to perform mission-related functions.

operational technology — Programmable systems or devices that interact with the physical environment (or manage devices that interact with the physical environment). These systems or devices detect or cause a direct change through the monitoring or control of devices, processes, and events. Examples include industrial control systems, building management systems, fire control systems, and physical access control mechanisms.

other system [ISO 15288] — A system that the system of interest interacts with in the operational environment. These systems may provide services to the system of interest (i.e., the system of interest is dependent on the other systems) or be the beneficiaries of services provided by the system of interest (i.e., other systems are dependent on the system of interest).

protection [SP 800-160 v1] — In the context of systems security engineering, a control objective that applies across all types of asset types and the corresponding consequences of loss. A system protection capability is a system control objective and a system design problem. The solution to the problem is optimized through a balanced proactive strategy and a reactive strategy that is not limited to prevention. The strategy also encompasses avoiding asset loss and consequences; detecting asset loss and consequences; minimizing (i.e., limiting, containing, restricting) asset loss and consequences; responding to asset loss and consequences; recovering from asset loss and consequences; and forecasting or predicting asset loss and consequences.

quality property [SP 800-160 v1] — An emergent property of a system that includes, for example: safety, security, maintainability, resilience, reliability, availability, agility, and survivability. This property is also referred to as a systemic property across many engineering domains.

reliability [IEEE90] — The ability of a system or component to function under stated conditions for a specified period of time.

resilience [OMB A-130] — The ability to prepare for and adapt to changing conditions and withstand and recover rapidly from disruption. Resilience includes the ability to withstand and recover from deliberate attacks, accidents, or naturally occurring threats or incidents.

[INCOSE14] — The ability to maintain required capability in the face of adversity.

resilient otherwise [SP 800-160 v1] — Security considerations applied to enable system operation despite disruption while not maintaining a secure mode, state, or transition; or only being able to provide for partial security within a given system mode, state, or transition.

See securely resilient.

risk [CNSSI 4009] [OMB A-130] — A measure of the extent to which an entity is threatened by a potential circumstance or event, and typically a function of the adverse impacts that would arise if the circumstance or event occurs; and the likelihood of occurrence.

risk analysis [ISO 73] — Process to comprehend the nature of risk and to determine the level of risk.

risk assessment [ISO 73] [SP 800-39, adapted] — The process of identifying risks to organizational operations (including mission, functions, image, reputation), organizational assets, individuals, other organizations, and the Nation, resulting from the operation of an information system. A part of risk management incorporates threat and vulnerability analyses, and considers mitigations provided by security controls planned or in place.

Overall process of risk identification, risk analysis, and risk evaluation.

risk-adaptive access control [SP 800-95] — Access privileges are granted based on a combination of a user’s identity, mission need, and the level of security risk that exists between the system being accessed and a user. RAdAC will use security metrics, such as the strength of the authentication method, the level of assurance of the session connection between the system and a user, and the physical location of a user, to make its risk determination.

risk factor [SP 800-30] — A characteristic used in a risk model as an input for determining the level of risk in a risk assessment.

risk framing [SP 800-39] — Risk framing is the set of assumptions, constraints, risk tolerances, and priorities/trade-offs that shape an organization’s approach for managing risk.

risk management strategy [SP 800-39] — Strategy that addresses how organizations intend to assess risk, respond to risk, and monitor risk—making explicit and transparent the risk perceptions that organizations routinely use in making both investment and operational decisions.

risk model [SP 800-30] — A key component of a risk assessment methodology (in addition to assessment approach and analysis approach) that defines key terms and assessable risk factors.

risk response [SP 800-39] — Accepting, avoiding, mitigating, sharing, or transferring risk to organizational operations (i.e., mission, functions, image, or reputation), organizational assets, individuals, other organizations, or the Nation.

safety [SP 800-82] [MIL-STD-882E] — Freedom from conditions that can cause death, injury, occupational illness, damage to or loss of equipment or property, or damage to the environment.

securely resilient [SP 800-160 v1] — The ability of a system to preserve a secure state despite disruption, to include the system transitions between normal and degraded modes. Securely resilient is a primary objective of systems security engineering.

security [SP 800-160 v1] — Freedom from those conditions that can cause loss of assets with unacceptable consequences.

[ISO 15288] — Protection against intentional subversion or forced failure. A composite of four attributes – confidentiality, integrity, availability, and accountability – plus aspects of a fifth, usability, all of which have the related issue of their assurance.

[CNSSI 4009] [SP 800-37] — A condition that results from the establishment and maintenance of protective measures that enable an enterprise to perform its mission or critical functions despite risks posed by threats to its use of information systems. Protective measures may involve a combination of deterrence, avoidance, prevention, detection, recovery, and correction that should form part of the enterprise’s risk management approach.

Note: See also information security and cybersecurity.

security control [SP 800-160 v1] — A mechanism designed to address needs as specified by a set of security requirements.

security controls [OMB A-130] — The safeguards or countermeasures prescribed for an information system or an organization to protect the confidentiality, integrity, and availability of the system and its information.

security criteria — Criteria related to a supplier’s ability to conform to security-relevant laws, directives, regulations, policies, or business processes; a supplier’s ability to deliver the requested product or service in satisfaction of the stated security requirements and in conformance with secure business practices; the ability of a mechanism, system element, or system to meet its security requirements; whether movement from one life cycle stage or process to another (e.g., to accept a baseline into configuration management, to accept delivery of a product or service) is acceptable in terms of security policy; how a delivered product or service is handled, distributed, and accepted; how to perform security verification and validation; or how to store system elements securely in disposal.

security function [SP 800-160 v1] — The capability provided by the system or a system element. The capability may be expressed generally as a concept or specified precisely in requirements.

security relevance [SP 800-160 v1] — The term used to describe those functions or mechanisms that are relied upon, directly or indirectly, to enforce a security policy that governs confidentiality, integrity, and availability protections.

security requirement [SP 800-160 v1] — A requirement that specifies the functional, assurance, and strength characteristics for a mechanism, system, or system element.

survivability [Richards09] — The ability of a system to minimize the impact of a finite-duration disturbance on value delivery (i.e., stakeholder benefit at cost), achieved through the reduction of the likelihood or magnitude of a disturbance; the satisfaction of a minimally acceptable level of value delivery during and after a disturbance; and/or a timely recovery.

system [ISO 15288] [SP 800-160 v1] — Combination of interacting elements organized to achieve one or more stated purposes.

Note 1: There are many types of systems. Examples include: general and special-purpose information systems; command, control, and communication systems; crypto modules; central processing unit and graphics processor boards; industrial/process control systems; flight control systems; weapons, targeting, and fire control systems; medical devices and treatment systems; financial, banking, and merchandising transaction systems; and social networking systems.

Note 2: The interacting elements in the definition of system include hardware, software, data, humans, processes, facilities, materials, and naturally occurring physical entities.

Note 3: System-of-systems is included in the definition of system.

system component [SP 800-53] — Discrete identifiable information technology assets that represent a building block of a system and include hardware, software, firmware, and virtual machines.

system element [ISO 15288] [SP 800-160 v1] — Member of a set of elements that constitute a system.

Note 1: A system element can be a discrete component, product, service, subsystem, system, infrastructure, or enterprise.

Note 2: Each element of the system is implemented to fulfill specified requirements.

Note 3: The recursive nature of the term allows the term system to apply equally when referring to a discrete component or to a large, complex, geographically distributed system-of-systems.

Note 4: System elements are implemented by: hardware, software, and firmware that perform operations on data / information; physical structures, devices, and components in the environment of operation; and the people, processes, and procedures for operating, sustaining, and supporting the system elements.

system of interest [ISO 15288] [SP 800-160 v1] — A system whose life cycle is under consideration in the context of [ISO/IEC/IEEE 15288:2015].

Note: A system of interest can be viewed as the system that is the focus of the systems engineering effort. The system of interest contains system elements, system element interconnections, and the environment in which they are placed.

system-of-systems [SP 800-160 v1] [INCOSE14] — System of interest whose system elements are themselves systems; typically, these entail large-scale interdisciplinary problems with multiple heterogeneous distributed systems.

Note: In the system-of-systems environment, constituent systems may not have a single owner, may not be under a single authority, or may not operate within a single set of priorities.

technical risk [NASA19] — The risk associated with the evolution of the design and the production of the system of interest affecting the level of performance necessary to meet the stakeholder expectations and technical requirements.

Note: Technical risk is often associated with novel technologies being proposed for integration into the system of interest or being used in systems that interact with the system of interest. It can also be associated with new discoveries of inherent vulnerabilities in technologies, or with products being withdrawn from use or losing support.

technique — See cyber resiliency technique.

threat event [SP 800-30] — An event or situation that has the potential for causing undesirable consequences or impact.

threat scenario [SP 800-30] — A set of discrete threat events, associated with a specific threat source or multiple threat sources, partially ordered in time.

threat source [CNSSI 4009] — Any circumstance or event with the potential to adversely impact organizational operations (including mission, functions, image, or reputation), organizational assets, individuals, other organizations, or the Nation through an information system via unauthorized access, destruction, disclosure, or modification of information, and/or denial of service.

trustworthiness [SP 800-160 v1] — Worthy of being trusted to fulfill whatever critical requirements may be needed for a particular component, subsystem, system, network, application, mission, business function, enterprise, or other entity.

zero trust architecture [EO 14028] — A security model, a set of system design principles, and a coordinated cybersecurity and system management strategy based on an acknowledgement that threats exist both inside and outside traditional network boundaries. The zero trust security model eliminates implicit trust in any one element, component, node, or service and instead requires continuous verification of the operational picture via real-time information from multiple sources to determine access and other system responses.

APPENDIX A

COMMON ABBREVIATIONS

ABAC Attribute-Based Access Control AFRL Air Force Research Laboratory Artificial Intelligence AI

Application Programming Interface

API

Advanced Persistent Threat

APT

Address Resolution Protocol

ARP ASIC Application-Specific Integrated Circuit ATT&CK Adversarial Tactics, Techniques & Common Knowledge

Business Impact Analysis

BIA

BMS Building Management Systems (BMS)

Command, Control, and Communications

C3

CAN Controller Area Network CAPEC Common Attack Pattern Enumeration and Classification

CCoA Cyber Courses of Action CDM Continuous Diagnostics and Mitigation CERT Computer Emergency Response Team

Critical Infrastructure System

CIS

Crown Jewels Analysis

CJA

Command Line Interface

CLI CMIA Cyber Mission Impact Analysis

CNSS Committee on National Security Systems

CNSSI Committee on National Security Systems Instruction COOP Continuity of Operations or Continuity of Operations Plan COTS Commercial Off-The-Shelf Cyber-Physical System or Systems CPS

Cyber Resilience Review

CRR

Cyber Survivability Attributes

CSA

CSRC Computer Security Resource Center Cyber Threat Intelligence CTI

APPENDIX B

Controlled Unclassified Information

CUI

Department of Homeland Security

DHS

Defense Industrial Base

DIB DMZ Demilitarized Zone

Domain Name System

DNS

DoD Department of Defense Defense Science Board DSB Digital Signal Processor DSP Embedded Control Unit ECU E-ISAC Electricity ISAC

Enterprise Information Technology

EIT EMS Energy Management System

ERM Enterprise Risk Management FDNA Functional Dependency Network Analysis

FPGA Field-Programmable Gate Array FMECA Failure Modes, Effects, and Criticality Analysis Federal Information Processing Standard(s) FIPS

FISMA Federal Information Security Modernization Act FOIA Freedom of Information Act

FOSS Free and Open-Source Software Global Positioning System GPS

HACS Highly Adaptive Cybersecurity Services

Hardware Description Language

HDL HMI Human-Machine Interface HVA High-Value Asset HVAC Heating, Ventilation, and Air Conditioning

Input/Output

I/O I&W Indications and Warnings

IdAM Identity and Access Management IACD Integrated Adaptive Cyber Defense

ICAM Identity, Credential, and Access Management

Industrial Control System

ICS

Information and Communications Technology

ICT

APPENDIX B

Intrusion Detection System

IDS

International Electrotechnical Commission

IEC

Intelligent Electronic Device

IED

Institute of Electrical and Electronics Engineers

IEEE INCOSE International Council on Systems Engineering

Internet of Things

IoT

International Organization for Standardization

ISO

Information Technology

IT

Information Technology Laboratory

ITL LSPE Large-Scale Processing Environment

MCU Master Control Unit MFA Multi-Factor Authentication

Mission Impact Analysis

MIA MIL-STD Military Standard

M&S Modeling and Simulation MBSE Model-Based Systems Engineering Machine Learning ML

MOE Measure of Effectiveness MOP Measure of Performance

MTD Moving Target Defense NASA National Aeronautics and Space Administration

NDIA National Defense Industrial Association

NIAC National Infrastructure Advisory Council NIST National Institute of Standards and Technology

Network of Things

NoT OEM Original Equipment Manufacturer

OMB Office of Management and Budget OPSEC Operations Security

Operational Technology

OT

Private Branch Exchange

PBX

PETE Potential Efforts on Threat Events

Personally Identifiable Information

PII

Programmable Logic Controller

PLC

APPENDIX B

Presidential Policy Directive

PPD

RAdAC Risk-Adaptive Access Control RAID Redundant Array of Independent Disks RBAC Role-Based Access Control RMA Reliability, Maintainability, Availability

RMF Risk Management Framework RMM Resilience Management Model Return on Investment ROI Remote Terminal Unit RTU RSWG (INCOSE) Resilient Systems Working Group

Society of Automotive Engineers

SAE SCADA Supervisory Control and Data Acquisition

SCRM Supply Chain Risk Management Software Defined Networking SDN

Software Engineering Institute

SEI

Safety Instrumented System

SIS SME Subject Matter Expert

Security Operations Center

SOC SOW Statement of Work

Special Publication

SP

Systems Security Engineering

SSE

STAMP Systems-Theoretic Accident Model and Processes

STPA System-Theoretic Process Analysis

Tactics, Techniques, and Procedures

TTP

Table Top Exercise

TTX

Uninterruptible Power Supply

UPS

VCU Vehicle Control Unit VOA Voice of the Adversary