An Overview of NIST Special Publications 800-34, 800-61, 800-63, and 800-218

Published 04/26/2023

Known more commonly as NIST, the National Institute of Standards and Technology provides cybersecurity frameworks that not only are integral for many government and Department of Defense contracts but are also widely accepted as a solid launch point for most organizations’ cybersecurity efforts.

In this article, we’ll provide an overview of four commonly referenced NIST Special Publications:

SP 800-34 Rev. 1 Contingency Planning Guide for Federal Information Systems
SP 800-61 Rev. 2 Computer Security Incident Handling
SP 800-63-3 Digital Identity Guidelines
SP 800-218 Secure Software Development Framework

We already explained some of the other, particularly popular NIST Special Publications in NIST 800-37, NIST 800-53, and NIST 800-171. Read on to glean even more clarity regarding some others.

What is NIST SP 800-34 Rev. 1?

What Does It Address? Contingency Planning Guide for Federal Information Systems

Working to identify and mitigate threats, vulnerabilities, and risks to your systems is important, and a big part of those efforts must be building a resilient infrastructure that helps alleviate the impact of any process failures.

That’s where NIST SP 800-34 comes in with its guidelines for such contingency planning, which is defined as preparing plans that document interim measures to recover information system services after a disruption. At a base level, it recommends establishing measures for:

The relocation of information systems or operations to an alternate site;
Recovery of information system functions using alternate equipment; or
The performance of information system functions using manual methods.

NIST SP 800-34 also provides a seven-step process for the development of a viable Information System Contingency Plan (ISCP):

Develop the contingency planning policy statement which formally establishes the organizational authority and guidance necessary to enforce an effective contingency plan.
Conduct the business impact analysis (BIA) to help identify and prioritize information systems and components critical to supporting your mission and business processes.
Identify preventive controls including defining measures that may be taken to mitigate system disruptions or increase system availability.
Create contingency strategies so that systems and processes may be recovered quickly and effectively following a disruption.
Develop an information system contingency plan that contains procedures for restoring a damaged system or circumventing its functional processes.
Ensure plan testing, training, and exercises that both validate your personnel’s preparation for plan activation and identify gaps that may have gone unnoticed.
Continue plan maintenance to accommodate changes to systems and organizational structures to ensure your contingency plans don’t become stale and ineffective over time.

For organizations interested in bolstering their contingency planning, NIST SP 800-34 also provides details regarding:

How ISCPs relate to the NIST Risk Management Framework (RMF), as well as various other security and emergency management-related plans
Approaches to incorporating relevant FIPS 199 impact levels and related NIST SP 800-53 contingency planning controls (e.g., CP-2, CP-3, CP-4)
Fundamental planning elements for the development of an effective plan, including business impact analysis, alternate site selection, and recovery strategies
Distinctions between an ISCP and other related plans for cyber incident response, disaster recovery, business continuity, critical infrastructure protection, occupant emergency, and crisis communication, as well as thoughts on how to coordinate these different plans
Contingency plan teams and the roles and responsibilities commonly assigned to personnel during plan activation
Activities necessary to document the contingency strategy and develop the ISCP
Approaches for maintaining, testing, training, and exercising the contingency plan
Contingency planning concerns specific to the three common platform types (client/server, telecommunications, and mainframe systems) to help in the identification, selection, and implementation of the appropriate technical contingency measures for those systems

What is NIST SP 800-61 Rev. 2?

What Does It Address? Computer Security Incident Handling

Given that cyber incidents can cause significant disruptions in your ability to conduct business and may result in lost income, increased costs, and a blemished reputation, computer security incident response is an extremely important component of your technology strategies.

Its principles are so important that federal agencies and service providers typically are contractually required to adhere to the models described in NIST SP 800-61. With its guidelines and templates, it’s intended to help assure effective incident response for any organization—a complex undertaking that requires substantial planning and resources.

Using NIST SP 800-61, you can establish important foundational elements of an incident response plan within your organization, including:

Incident Response Policy and Plan	These authoritative documents set the tone for your organization, provide a basis for enforcement, and are essential for attesting to incident response capabilities.
Procedures For Performing Incident Handling And Reporting	Cyber incidents may source from different places, including infected external or removable media, network brute force attacks, attacks executed from a website or web-based application, infected email messages or attachments, improper usage by an authorized user, and loss or theft of equipment. Each of these potential sources as well as any others that you may be subject to should be addressed in documented procedures.
Guidelines For Communicating With Outside Parties Regarding Incidents	When handling an incident, you’ll need to communicate with outside parties, such as other incident response teams, law enforcement, the media, vendors, and partner organizations. NIST SP 800-61 can help you establish a plan in place so that only appropriate information is shared with the right parties and your interests and relationships are not compromised.
Team Structure	Incident response teams may be centrally organized, distributed, or coordinated across several disparate teams within your organization.
Incident Response Coordination	For success, you must establish relationships and lines of communication between the incident response team and other groups, both internal (e.g., legal department, Information Technology, Operations, HR, Media Relations, etc.) and external (e.g., law enforcement agencies, vendors, or partners).
Staffing And Training The Incident Response Team	Depending on your unique incident response needs, these teams may consist of combinations of internal staff, outsourced personnel, or specific services that may be sourced from specialized service organizations.
Other Services/Roles for Incident Response Team	In addition to incident response, you may also want that team to provide other, complementary services such as intrusion detection, education, awareness, advisory management, and post-incident analysis and follow-up.

What is NIST SP 800-63-3?

What Does It Address? Digital Identity Guidelines

“Digital identity is considered to be the unique representation of a subject engaged in an online transaction. A digital identity is always unique in the context of a digital service but does not necessarily need to uniquely identify the subject in all contexts. In other words, accessing a digital service may not mean that the subject’s real-life identity is known.”

The inherent difficulty of proving one’s identity - particularly over the internet, creates a dearth of opportunities for an impersonator to assume someone’s identity and take advantage of their victims’ resources and trust.

To help secure individual identities, NIST 800-63-3 publication provides an overview of general identity frameworks, using authenticators, credentials, and assertions together in a digital system, and a risk-based process of selecting assurance levels from both a normative and informative perspective.

Moreover, appendant publications 800-63A, B & C are presented alongside SP 800-63-3 which contain further considerations for the following related topics:

Enrollment and Identity Proofing: Or, how applicants may prove their identities and become enrolled as valid subscribers within an identity system.
- Introduces and defines Identity Assurance Levels IAL1, IAL2, IAL3.
Lifecycle Management of Authenticators: Applicable to services where return visits are appropriate, as the guidance helps to establish an assurance that the subscriber accessing the service today is the same as that accessed the service previously.
- Introduces and defines Authenticator Assurance Levels AAL1, AAL2, and AAL3.
Authenticator Federation and Assertions: Covers the conveyance of the results of authentication processes to an agency application, including recommendations for techniques to enhance authentication privacy as well as methods for strong multi-factor authentication.
- Introduces and defines Federal Assurance Levels FAL1, FAL2, FAL3.

Each of the publications is extremely detailed and defines required standards and well as recommendations for consideration. The Identity, Authentication, and Federal Assurance Levels (IAL, AAL, and FAL) are leveraged for minimum standards by the FedRAMP program.

What is NIST SP 800-218?

What Does It Address? Secure Software Development Framework

Maintaining a mature Software Development Life Cycle (SDLC) within a Secure Software Development Framework (SSDF) is critical for avoiding coding flaws, inappropriate security configuration settings, incorrect trust assumptions, and outdated risk analysis.

NIST SP 800-218 identifies acceptable practices in this area but, like the other publications we’ve highlighted, is not prescriptive in how they should be implemented.

The recommended practices are suitable for organizations of any size, may be integrated into any software development workflows and SDLCs, and can help organizations create bridges from classic workflows towards modern software development models (e.g., Agile or DevOps).

The recommended practices are organized into four groups:

NIST SP 800-218 Recommended Practice Groups

1. Prepare the Organization (PO):

Ensure that your people, processes, and technology are suitably prepared to perform secure software development at the organizational level.

2. Protect the Software (PS):

Protect all components of software from tampering and unauthorized access.

3. Produce Well-Secured Software (PW):

Produce well-secured software with minimal security vulnerabilities in software releases.

4. Respond to Vulnerabilities (RV):

Identify residual vulnerabilities in software releases and respond appropriately to both address them and prevent similar ones from occurring in the future.

Within each of these groups, NIST SP 800-218 provides explanations and recommendations on how the practice should be structured, as well as examples of how they may be implemented.

Next Steps for Your Cybersecurity and Compliance

In general, NIST provides a wealth of information directed at establishing, enriching, and maintaining secure and sustainable computing environments, including the four publications overviewed here. Though these resources are a requirement for those organizations who engage (or wish to engage) in federal and DoD contracts, they’re available to anyone interested in achieving the same level of capabilities demanded of those working in the Defense Industrial Base.

A catalog of the Special Publications highlighted in this paper, as well as the larger library of all NIST’s computer and information security publications, can be found here.

And if you’re interested in learning more about specific federal compliance initiatives, check out our other content that breaks down your options, including a couple of the more popular programs:

Cloud Incident Response Compliance Standards