NIST SP 800-61 Rev. 3 日本語訳

A CSF 2.0 Community Profile

Alex Nelson Sanjay Rekhi Murugiah Souppaya Karen Scarfone

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

A CSF 2.0 Community Profile

Alex Nelson Sanjay Rekhi Murugiah Souppaya*

Computer Security Division Information Technology Laboratory

Karen Scarfone Scarfone Cybersecurity

*Former NIST employee; all work for this publication was done while at NIST.

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

April 2025

U.S. Department of Commerce Howard Lutnick, Secretary of Commerce

National Institute of Standards and Technology

Craig Burkhardt, Acting Under Secretary of Commerce for Standards and Technology and Acting NIST Director

Certain equipment, instruments, software, or materials, commercial or non-commercial, are identified in this paper in order to specify the experimental procedure adequately. Such identification does not imply recommendation or endorsement of any product or service by NIST, nor does it imply that the materials or equipment identified 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 in this publication, including concepts and methodologies, may be used by federal agencies even before the completion of such companion publications. Thus, until each publication is completed, current 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 all draft publications during public comment periods and provide feedback to NIST. Many NIST cybersecurity publications, other than the ones noted above, are available at https://csrc.nist.gov/publications.

Authority This publication has been developed by NIST in accordance with its statutory responsibilities under the Federal Information Security Modernization Act (FISMA) of 2014, 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 appropriate federal officials exercising policy authority over such systems. This guideline is consistent with the 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, Director of the OMB, 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.

NIST Technical Series Policies Copyright, Use, and Licensing Statements NIST Technical Series Publication Identifier Syntax

Publication History Approved by the NIST Editorial Review Board on 2025-03-25 Supersedes NIST SP 800-61r2 (August 2012) https://doi.org/10.6028/NIST.SP.800-61r2

How to Cite this NIST Technical Series Publication Nelson A, Rekhi S, Souppaya M, Scarfone K (2025) Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-61r3. https://doi.org/10.6028/NIST.SP.800-61r3

Author ORCID iDs Alex Nelson: 0000-0002-3771-570X Sanjay Rekhi: 0009-0008-8711-4030 Murugiah Souppaya: 0000-0002-8055-8527 Karen Scarfone: 0000-0001-6334-9486

Contact Information 800-61-comments@nist.gov

National Institute of Standards and Technology Attn: Computer Security Division, Information Technology Laboratory 100 Bureau Drive (Mail Stop 8930) Gaithersburg, MD 20899-8930

Additional Information Additional information about this publication is available at https://csrc.nist.gov/pubs/sp/800/61/r3/final, including related content, potential updates, and document history.

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

This publication seeks to assist organizations with incorporating cybersecurity incident response recommendations and considerations throughout their cybersecurity risk management activities as described by the NIST Cybersecurity Framework (CSF) 2.0. Doing so can help organizations prepare for incident responses, reduce the number and impact of incidents that occur, and improve the efficiency and effectiveness of their incident detection, response, and recovery activities. Readers are encouraged to utilize online resources in conjunction with this document to access additional information on implementing these recommendations and considerations.

cyber threat information sharing; Cybersecurity Framework; cybersecurity incident; cybersecurity risk management; incident handling; incident management; incident response.

The Information Technology Laboratory (ITL) at the National Institute of Standards and Technology (NIST) 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. ITL’s responsibilities include the development of management, administrative, technical, and physical standards and guidelines for the cost-effective security and privacy 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 system security, and its collaborative activities with industry, government, and academic organizations.

Supplemental Content

NIST has established an Incident Response project page that hosts links to resources with additional information on incident response activities. By moving links from this document to a website, NIST can update and expand them as needed without having to release a new version of this publication.

For more information on CSF 2.0 Community Profiles, see the Framework Resource Center.

Audience

The target audience for this publication includes cybersecurity program leadership, cybersecurity personnel, and others who are responsible for preparing for, detecting, responding to, or recovering from cybersecurity incidents. This publication is intended for use by most organizations, regardless of sector, size, or other factors.

Trademark Information

All registered trademarks belong to their respective organizations.

Patent Disclosure Notice

NOTICE: 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.

Executive Summary

Incident response is a critical part of cybersecurity risk management and should be integrated across organizational operations. All six NIST Cybersecurity Framework (CSF) 2.0 Functions play vital roles in incident response:

Many individuals, teams, and third parties hold a wide variety of roles and responsibilities across all of the Functions that support an organization’s incident response. Organizations have no direct control over the tactics and techniques used by their adversaries, nor are they certain about the timing of a future incident other than knowing that another incident is inevitable. However, organizations can use an incident response life cycle framework or model that best suits them to develop strong cybersecurity risk management practices that reduce their risks to acceptable levels.

This publication uses the CSF 2.0 Functions, Categories, and Subcategories to organize its recommendations, considerations, and other information regarding incident response as a CSF 2.0 Community Profile. Doing so provides a common taxonomy that is already widely used for communicating about incident response and cybersecurity risk management and governance. This also enables organizations to access a range of online resources mapped to each Function, Category, and Subcategory through the NIST Cybersecurity and Privacy Reference Tool (CPRT). These resources include mappings to other incident response and cybersecurity risk management standards and guidance, as well as sources of implementation guidance that organizations can choose to utilize as needed.

Organizations should use the incident response life cycle framework or model that suits them best. The model in this document is based on CSF 2.0 to take advantage of the wealth of resources available for CSF 2.0 and aid organizations that are already using the CSF. Regardless of the incident response life cycle framework or model used, every organization should take incident response into consideration throughout their cybersecurity risk management activities.

Within this document, an event is any observable occurrence that involves computing assets, including physical and virtual platforms, networks, services, and cloud environments. Examples of events are user login attempts, the installation of software updates, and an application responding to a transaction request. Many events focus on security or have security implications. Adverse events are any events associated with a negative consequence regardless of cause, including natural disasters, power failures, or cybersecurity attacks. This guide addresses only adverse cybersecurity events. Additional analysis is often needed to determine whether adverse cybersecurity events indicate that a cybersecurity incident has occurred.

A cybersecurity incident (or simply incident) is

…an occurrence that actually or imminently jeopardizes, without lawful authority, the integrity, confidentiality, or availability of information or an information system; or constitutes a violation or imminent threat of violation of law, security policies, security procedures, or acceptable use policies. [FISMA2014]

原本PDFの抜粋画像

Examples of incidents include an attacker:

Because of the damage that cybersecurity incidents can inflict on organizations and their customers, business partners, and others, it is vital to respond quickly and effectively when an incident occurs. Effective implementation of incident response processes enables systematic responses to and recovery from incidents by analyzing information and taking appropriate action. This reduces cybersecurity and enterprise risks by minimizing data loss or theft, the disruption of services, and the overall impact of incidents. Lessons learned from incident response activities and root cause analysis help improve cybersecurity risk management and governance efforts and ensure that the organization is better prepared to identify its current technology assets and cybersecurity risks, protect its assets, and detect, respond to, and recover from future incidents.

This publication seeks to help organizations incorporate cybersecurity incident response recommendations and considerations throughout their cybersecurity risk management activities. It also provides a common language that all organizations can use to communicate internally and externally regarding their incident response plans and activities.

The scope of this publication differs significantly from previous versions. Because the details of how to perform incident response activities change so often and vary so much across technologies, environments, and organizations, it is no longer feasible to capture and maintain that information in a single static publication. Instead, this version focuses on improving cybersecurity risk management for all of the NIST Cybersecurity Framework (CSF) 2.0 Functions [CSF2.0] to better support an organization’s incident response capabilities.

Readers are encouraged to utilize other NIST resources in conjunction with this document, including the CSF 2.0 publication and supplemental resources, the Incident Response project page, and mappings to additional sources of information on implementing incident response considerations available through the NIST Cybersecurity and Privacy Reference Tool (CPRT). An example of a CPRT mapping is associating CSF 2.0 outcomes with NIST Special Publication (SP) 800-53 controls that can be implemented to help achieve the outcomes. In this way, CSF 2.0 provides a common language that facilitates access to a large number of other resources.

This publication supersedes SP 800-61r2 (Revision 2), Computer Security Incident Handling Guide [SP800-61r2].

The remainder of this document is organized into the following sections and appendices:

This section explains the fundamental concepts of incident response as an integral part of cybersecurity risk management. Section 2.1 explores the incident response life cycle and proposes a new life cycle model based on CSF 2.0 Functions. Section 2.2 discusses incident response roles and responsibilities both inside and outside an organization. Finally, Section 2.3 briefly examines incident response policies, processes, and procedures.

Fig. 1 depicts the incident response life cycle model illustrated in the previous version of this publication [SP800-61r2].

Fig. 1. Previous incident response life cycle model

At that time, incidents were relatively rare, the scope of most incidents was narrow and well-defined, and incident response and recovery was usually completed within a day or two. Under those conditions, it was realistic to treat incident response as a separate set of activities performed by a separate team of personnel and to depict all incident response activities as part of a circular life cycle. Formal post-incident activities would identify needed improvements and feed them into the preparation stage, thus starting the cycle again. Incident response activities were typically intermittent rather than continuous.

However, the current state of incident response has greatly changed since then. Today, incidents occur frequently and cause far more damage. Recovering from them often takes weeks or months due to their breadth, complexity, and dynamic nature. Incident response is now considered a critical part of cybersecurity risk management that should be integrated across organizational operations. The lessons learned during incident response should often be shared as soon as they are identified, not delayed until after recovery concludes. Continuous improvement is increasingly necessary for all facets of cybersecurity risk management in order to keep up with modern threats.

Fig. 2 shows a high-level incident response life cycle model based on the six CSF 2.0 Functions, which organize cybersecurity outcomes at their highest level:

All six Functions have vital roles in incident response. Govern, Identify, and Protect help organizations prevent some incidents, prepare to handle incidents that do occur, reduce the impact of those incidents, and improve incident response and cybersecurity risk management practices based on lessons learned. Detect, Respond, and Recover help organizations discover, manage, prioritize, contain, eradicate, and recover from cybersecurity incidents, as well as perform incident reporting, notification, and other incident-related communications.

Fig. 2. Incident response life cycle model based on CSF 2.0 Functions

The bottom level reflects that the preparation activities of Govern, Identify, and Protect are not part of the incident response itself. Rather, they are much broader cybersecurity risk management activities that also support incident response. Incident response is shown in the top level of the figure: Detect, Respond, and Recover. Additionally, the need for continuous improvement is indicated as the middle level with the Improvement Category (ID.IM) within the Identify Function and the dashed green lines. Lessons learned from performing all activities in all Functions are fed into Improvement, and those lessons are analyzed, prioritized, and used to inform all of the Functions. This reflects that organizations can learn new lessons at all times (e.g., detecting the presence of a new threat and characterizing its behavior) and communicate those lessons to the appropriate personnel so that the organization’s incident response and other cybersecurity risk management policies, processes, and practices can be adjusted as needed.

Table 1 maps the previous SP 800-61 incident response life cycle model’s phases to the corresponding CSF 2.0 Functions used in this document.

Table 1. Previous incident response life cycle model’s phases and corresponding CSF 2.0 Functions

Organizations should use the incident response life cycle framework or model that suits them best. The model in this document is based on CSF 2.0 to take advantage of the wealth of resources available for CSF 2.0 and aid organizations that are already using the CSF. The appropriate incident response life cycle framework or model for an organization depends on many factors; for example, larger and more technology-dependent organizations are likely to benefit more from using a framework or model emphasizing continuous improvement than other organizations would. Regardless of the incident response life cycle framework or model used, every organization should take incident response into consideration throughout their cybersecurity risk management activities.

In the past, incident response activities were performed almost exclusively by incident handlers from the organization’s own incident response team. Today, while incident handlers are still critically important, most organizations increasingly recognize that the success of their incident response efforts depend on the participation of many internal and external parties who hold a wide variety of roles and responsibilities and may be spread around the world. Roles and responsibilities will differ for each organization and may also differ within an organization based on the nature of a particular incident.

Examples of incident response roles and responsibilities include the following:

On staff (e.g., an incident response team), o On contract (e.g., outsourcing a security operations center [SOC] to a managed o security services provider [MSSP] or leveraging a cloud service provider’s incident response team when an incident occurs within that provider’s cloud), and/or

Available when needed (e.g., from a parent organization, a cybersecurity services o provider, a business partner, or a law enforcement agency).

Many organizations may use more than one of these approaches, such as internally performing basic incident response and engaging third-party resources for assistance with certain incidents. Larger organizations may have multiple incident response teams, with each team responsible for a particular logical or physical segment of the organization. When this model is employed, the teams should be part of a single coordinated entity (e.g., a federation) to ensure that incident response processes, procedures, and training are consistent across the organization and that information is shared among teams.

Third parties may be under contract with an organization to help perform incident response activities. Some third parties may fill a primary role (e.g., an MSSP performing incident detection, response, and recovery activities), while other parties (e.g., cloud service providers [CSPs] and internet service providers [ISPs]) may be involved in certain incident response activities for particular types of incidents. This is a shared responsibility model in which the organization transfers some of its responsibilities to a provider. These responsibilities should be clearly defined in a contract, and the incident response team should be aware of the division of responsibilities, including information flows, coordination, and authority to act on behalf of the organization. This also includes restrictions on what the service provider can do, such as sharing sanitized incident information with other customers or making and implementing operational decisions (e.g., immediately deactivating certain services to contain an incident).

A service provider may detect malicious activity sooner than individual organizations would because it can correlate events across its customers. In some situations, a service provider might be able to use knowledge of an incident with one customer to proactively prevent similar incidents with its other customers. Service providers often have privileged access to organizational systems and may also have access to sensitive organizational data. Accordingly, the risk of malicious insiders or the service provider being compromised should be considered and addressed. Non-disclosure agreements (NDAs) and contracting clauses are options for deterring the unauthorized disclosure of sensitive data.

Organizations should have policies that govern their cybersecurity incident response. While a policy is highly individualized to the organization, most incident response policies include the same key elements:

Processes and procedures should be based on the incident response policy and plan. Documented procedures should explain how technical processes and other operating procedures should be performed. Procedures can be tested or exercised periodically to verify their accuracy and can be used to help train new personnel. While it is impossible to have detailed procedures for every possible situation, organizations should consider documenting procedures for responding to the most common types of incidents and threats. Organizations should also develop and maintain procedures for particularly important processes that may be urgently needed during emergency situations, such as redeploying the organization’s primary authentication platform.

Many organizations choose to create playbooks as part of documenting their procedures. Playbooks provide actionable steps or tasks for people to perform during various scenarios or situations. Formatting procedures within a playbook instead of another format can improve their usability. See the Cybersecurity and Infrastructure Security Agency (CISA) Cybersecurity Incident & Vulnerability Response Playbooks [CISA-PB] for incident response playbook examples.

A CSF Community Profile is a baseline of CSF outcomes that is created and published to address shared interests and goals for reducing cybersecurity risk among a number of organizations. A Community Profile is typically developed for a particular sector, subsector, technology, threat type, or other use case [CSF2.0].

This section defines NIST’s CSF 2.0 Community Profile for cyber incident risk management. It uses the CSF Core as the basis for highlighting and prioritizing cybersecurity outcomes that are important for incident response, makes recommendations, and provides other supporting information for certain CSF outcomes within the context of incident response [CSWP32]. The Community Profile is split into two tables: Table 2 covers Preparation (Govern, Identify, and Protect) and Lessons Learned (Identify-Improvement), while Table 3 covers Incident Response (Detect, Respond, and Recover).

Each CSF 2.0 Function, Category, and Subcategory has its own row in one of the two tables. Each row’s relative priority within the context of incident response is indicated by one of the following:

These priorities are intended as a starting point for organizations, who are encouraged to customize this Community Profile to reflect their own priorities and needs.

The last column may contain one or more items that recommend what to do or describe additional considerations or supporting information for some rows. Each item in that column has an ID starting with one of the following:

An R, C, or N designation and its number can be appended to the row’s CSF ID to create an identifier that is unique within the Community Profile (e.g., “GV.OC-03.R1” is recommendation 1 for CSF Subcategory GV.OC-03).

Recommendations, considerations, and notes made at a higher level of the CSF (Function or Category) also apply to their component elements (Categories or Subcategories).

The recommendations, considerations, and notes supplement what the CSF 2.0 already provides through its documents and online resources. The recommendations, considerations, and notes are not comprehensive, and not all of them will be applicable to every organization. Technologies mentioned in recommendations, considerations, and notes are examples as of this writing and may become outdated.

Some recommendations, considerations, and notes use terms that are not defined in this publication (e.g., “data breach”). Organizations that adopt the Community Profile should define these terms in the context of their own environments, use cases, and applicable laws and regulations. Readers may also choose to consult NIST’s glossary, which contains an aggregation of terms and definitions from numerous NIST standards, guidelines, and other publications.

The Community Profile is intended for use by most organizations, regardless of sector, size, or other factors. Additional versions of this Community Profile could be developed for narrower audiences, such as federal agencies, small businesses, or educational institutions. For more information on CSF 2.0 Community Profiles, see the Framework Resource Center.

Table 2 contains the first part of the Community Profile: Preparation and Lessons Learned, which both support the Incident Response part of the Community Profile defined in Table 3.

Note: Most of the CSF elements in this part of the Profile are not specific to executing incident response activities, so they have lower priorities with respect to incident response and do not contain recommendations or considerations. This does not imply that they are unnecessary for organizations to achieve, but rather that they are outside of the direct scope of responding to incidents.

原本PDFの抜粋画像

Table 2. CSF 2.0 Community Profile part 1: Preparation and Lessons Learned

Table 3 contains the second part of the Community Profile: Incident Response.

Note: All of the CSF elements in this part of the Profile are specific to responding to incidents, so they have higher priorities with respect to incident response than those in the first part. Accordingly, all CSF elements in this part have recommendations or considerations.

原本PDFの抜粋画像

Table 3. CSF 2.0 Community Profile part 2: Incident Response

References

[CISA-PB] Cybersecurity and Infrastructure Security Agency (2021) Cybersecurity Incident & Vulnerability Response Playbooks: Operational Procedures for Planning and Conducting Cybersecurity Incident and Vulnerability Response Activities in FCEB Information Systems. (Cybersecurity and Infrastructure Security Agency, Arlington, VA). Available at https://www.cisa.gov/sites/default/files/publications/Federal_Government_Cybersecurity_Incident_and_Vulnerability_Response_Playbooks_508C.pdf

[CNSSI-4009] Committee on National Security Systems (2022) Committee on National Security Systems (CNSS) Glossary. (National Security Agency, Ft. Meade, MD). Committee on National Security Systems Instruction (CNSSI) 4009. Available at https://www.cnss.gov/CNSS/issuances/instructions.cfm

National Institute of Standards and Technology (2024) The NIST Cybersecurity Framework (CSF) 2.0. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Cybersecurity White Paper (CSWP) NIST CSWP 29. https://doi.org/10.6028/NIST.CSWP.29

[CSWP32] Pascoe C, Snyder JN, Scarfone K (2024) NIST Cybersecurity Framework 2.0: A Guide to Creating Community Profiles. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Cybersecurity White Paper (CSWP) NIST CSWP 32. https://doi.org/10.6028/NIST.CSWP.32.ipd

[FISMA2014] Federal Information Security Modernization Act of 2014, Pub. L. 113-283, 128 Stat. 3073. Available at https://www.govinfo.gov/app/details/PLAW-113publ283

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

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

[SP800-37r2] 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) NIST SP 800-37r2. https://doi.org/10.6028/NIST.SP.800-37r2

[SP800-61r2] Cichonski PR, Millar T, Grance T, Scarfone KA (2012) Computer Security Incident Handling Guide. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-61r2. https://doi.org/10.6028/NIST.SP.800-61r2

[SP800-84] Grance T, Nolan T, Burke K, Dudley R, White G, Good T (2006) Guide to Test, Training, and Exercise Programs for IT Plans and Capabilities. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-84. https://doi.org/10.6028/NIST.SP.800-84

[SP800-92r1] Scarfone K, Souppaya M (2023) Cybersecurity Log Management Planning Guide. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-92r1 ipd. https://doi.org/10.6028/NIST.SP.800-92r1.ipd

[SP800-150] Johnson CS, Waltermire DA, Badger ML, Skorupka C, Snyder J (2016) Guide to Cyber Threat Information Sharing. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-150. https://doi.org/10.6028/NIST.SP.800-150

[SP800-160v1] Ross RS, McEvilley M, Winstead M (2022) Engineering Trustworthy Secure Systems. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-160v1r1. https://doi.org/10.6028/NIST.SP.800-160v1r1

[SP800-184] Bartock MJ, Scarfone KA, Smith MC, Witte GA, Cichonski JA, Souppaya MP (2016) Guide for Cybersecurity Event Recovery. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-184. https://doi.org/10.6028/NIST.SP.800-184

[SP800-216] Schaffer KB, Mell PM, Trinh H, Van Wyk I (2023) Recommendations for Federal Vulnerability Disclosure Guidelines. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-216. https://doi.org/10.6028/NIST.SP.800-216

[SP800-218] Souppaya MP, Scarfone KA, Dodson DF (2022) Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-218. https://doi.org/10.6028/NIST.SP.800-218

Appendix A. List of Symbols, Abbreviations, and Acronyms

CISA Cybersecurity and Infrastructure Security Agency

CPRT Cybersecurity and Privacy Reference Tool

CSF Cybersecurity Framework

CSP Cloud Service Provider

CTI Cyber Threat Intelligence

ISAC Information Sharing and Analysis Center

ISP Internet Service Provider

MOU Memorandum of Understanding

MSSP Managed Security Services Provider

NDA Non-Disclosure Agreement

SIEM Security Information and Event Management

SOAR Security Orchestration, Automation, and Response

SOC Security Operations Center

SOP Standard Operating Procedures

TTPs Tactics, Techniques, and Procedures

adverse cybersecurity event — Any event with a potentially negative impact on cybersecurity.

computer security incident — See cybersecurity incident.

cyber threat intelligence — Cyber threat information that has been aggregated, transformed, analyzed, interpreted, or enriched to provide the necessary context for decision-making processes. [SP800-150, adapted]

cybersecurity incident — An occurrence that actually or imminently jeopardizes, without lawful authority, the integrity, confidentiality, or availability of information or an information system; or constitutes a violation or imminent threat of violation of law, security policies, security procedures, or acceptable use policies. [FISMA2014]

event — Any observable occurrence involving computing assets, including physical and virtual platforms, networks, services, and cloud environments.

incident — See cybersecurity incident.

incident response — The remediation or mitigation of violations of security policies and recommended practices. [FISMA2014]

indicators of compromise — Technical artifacts or observables that suggest that an attack is imminent or is currently underway or that a compromise may have already occurred. [SP800-150, adapted]

tactics, techniques, and procedures — The behavior of an actor. A tactic is the highest-level description of this behavior, while techniques give a more detailed description of behavior in the context of a tactic, and procedures an even lower-level, highly detailed description in the context of a technique. [SP800-150]

threat — 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. [SP800-30r1]

vulnerability — A weakness in a system, system security procedures, internal controls, or implementation by which an actor or event may intentionally exploit or accidentally trigger the weakness to access, modify, or disrupt the normal operations of a system, resulting in a security incident or violation of the system’s security policy. [CNSSI-4009, adapted]

Appendix C. Change Log

This publication revises the previous version, NIST SP 800-61 Revision 2 (2012), as follows: