NIST SP 800-17 R2

NIST Special Publication 800-171, Revision 2 — Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations — is a National Institute of Standards and Technology (NIST) publication that provides federal agencies with recommended security requirements for protecting the confidentiality of Controlled Unclassified Information (CUI) when that information resides in nonfederal systems and organizations.

Withdrawal notice

Withdrawn publication	Detail
Series/Number	NIST SP 800-171r2
Title	Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations
Publication date(s)	February 2020 (includes updates as of January 28, 2021)
Withdrawal date	May 14, 2024
Withdrawal note	NIST SP 800-171r2 is withdrawn and superseded in its entirety by NIST SP 800-171r3

Superseding publication	Detail
Series/Number	NIST SP 800-171r3
Title	Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations
Author(s)	Ron Ross; Victoria Pillitteri
Publication date(s)	May 2024
URL/DOI	Template:URL

Contact: Computer Security Division (Information Technology Laboratory). Related information: Template:URL. Date updated: May 14, 2024.

Front matter

Authority

This publication was 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. Such information security standards and guidelines do 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 the requirements of Office of Management and Budget (OMB) Circular A-130.

Nothing in the 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 the guidelines be interpreted as altering or superseding the existing authorities of the Secretary of Commerce, the OMB Director, or any other federal official. The publication may be used by nongovernmental organizations on a voluntary basis and is not subject to copyright in the United States, although attribution is appreciated by NIST.

National Institute of Standards and Technology Special Publication 800-171, Revision 2
Natl. Inst. Stand. Technol. Spec. Publ. 800-171, Revision 2, 113 pages (February 2020)
CODEN: NSPUE2
Template:URL

Reports on Computer Systems Technology

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. ITL's responsibilities include developing 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.

Abstract

The protection of Controlled Unclassified Information (CUI) resident in nonfederal systems and organizations is of paramount importance to federal agencies and can directly impact the ability of the federal government to successfully conduct its essential missions and functions. This publication provides agencies with recommended security requirements for protecting the confidentiality of CUI when the information is resident in nonfederal systems and organizations; when the nonfederal organization is not collecting or maintaining information on behalf of a federal agency or using or operating a system on behalf of an agency; and where there are no specific safeguarding requirements for protecting the confidentiality of CUI prescribed by the authorizing law, regulation, or governmentwide policy for the CUI category listed in the CUI Registry. The requirements apply to all components of nonfederal systems and organizations that process, store, and/or transmit CUI, or that provide protection for such components. The security requirements are intended for use by federal agencies in contractual vehicles or other agreements established between those agencies and nonfederal organizations.

Keywords: Basic Security Requirement; Contractor Systems; Controlled Unclassified Information; CUI Registry; Derived Security Requirement; Executive Order 13556; FIPS Publication 199; FIPS Publication 200; FISMA; NIST Special Publication 800-53; Nonfederal Organizations; Nonfederal Systems; Security Assessment; Security Control; Security Requirement.

Acknowledgements

The authors wish to recognize the scientists, engineers, and research staff from the Computer Security Division and Applied Cybersecurity Division for their exceptional contributions in helping to improve the content of the publication, and thank Pat O'Reilly, Jim Foti, and Jeff Brewer of the NIST web team for their administrative support. The authors also acknowledge the contributions from individuals and organizations in the public and private sectors, nationally and internationally, whose comments improved the overall quality, thoroughness, and usefulness of the publication.

Historical contributions to previous versions of Special Publication 800-171, since its inception in June 2015, were made by Carol Bales, Matthew Barrett, Jon Boyens, Devin Casey, Christian Enloe, Peggy Himes, Robert Glenn, Elizabeth Lennon, Vicki Michetti, Dorian Pappas, Karen Quigg, Mary Thomas, Matthew Scholl, Murugiah Souppaya, Patricia Toth, and Patrick Viscuso.

Patent disclosure notice

The Information Technology Laboratory (ITL) 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. Holders of patents are not obligated to respond to ITL's calls for patents, and ITL has not undertaken a patent search to identify which, if any, patents may apply to the publication. As of the date of publication and following the call(s) for identification of patent claims, no such patent claims had 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 the publication.

Cautionary note

FISMA of 2014 requires federal agencies to identify and provide information security protections commensurate with the risk resulting from the unauthorized access, use, disclosure, disruption, modification, or destruction of information collected or maintained by or on behalf of an agency, or of information systems used or operated by an agency, a contractor of an agency, or another organization on behalf of an agency. This publication focuses on protecting the confidentiality of CUI in nonfederal systems and organizations and recommends specific security requirements to achieve that objective. It does not change the requirements set forth in FISMA, nor does it alter the responsibility of federal agencies to comply with the full provisions of the statute, OMB policy, and supporting NIST standards and guidelines.

The requirements recommended in the publication are derived from FIPS 200 and the moderate security control baseline in SP 800-53, and are based on the CUI regulation (32 CFR 2002). These requirements and controls have, over time, been determined to provide the necessary protection for federal information and systems covered under FISMA. The tailoring criteria applied to the FIPS 200 requirements and SP 800-53 controls are not an endorsement of eliminating those requirements and controls; rather, the tailoring focuses on protecting CUI from unauthorized disclosure in nonfederal systems and organizations. Because the security requirements are derived from the NIST publications listed above, organizations should not assume that satisfying these particular requirements will automatically satisfy the requirements and controls in FIPS 200 and SP 800-53.

In addition to confidentiality, the objectives of integrity and availability remain a high priority for organizations concerned with establishing and maintaining a comprehensive information security program. While the primary purpose of this publication is to define requirements to protect the confidentiality of CUI, confidentiality and integrity are closely related since many underlying security mechanisms at the system level support both objectives; the basic and derived security requirements therefore provide protection from both unauthorized disclosure and unauthorized modification of CUI. Organizations that must comply with the recommendations in this publication are strongly advised to review the complete listing of controls in the moderate baseline in Appendix E to ensure their security plans and control deployments provide the necessary and sufficient protection against cyber and kinetic threats to organizational missions and business operations.

CUI security requirements

The recommended security requirements contained in this publication are only applicable to a nonfederal system or organization when mandated by a federal agency in a contract, grant, or other agreement. The security requirements apply to the components of nonfederal systems that process, store, or transmit CUI, or that provide security protection for such components.

Framework for Improving Critical Infrastructure Cybersecurity

Organizations that have implemented, or plan to implement, the NIST Framework for Improving Critical Infrastructure Cybersecurity (Cybersecurity Framework) can find in Appendix D a direct mapping of the CUI security requirements to the security controls in SP 800-53 and ISO/IEC 27001. These controls are also mapped to the categories and subcategories associated with the Cybersecurity Framework's core functions: Identify, Protect, Detect, Respond, and Recover. The mappings can be useful to organizations that wish to demonstrate compliance with the security requirements in the context of an established information security program built around the NIST or ISO/IEC security controls.

Additional resources:

• Mapping security controls to the Cybersecurity Framework: Template:URL
• Mapping CUI security requirements to the Cybersecurity Framework: Template:URL

Errata

This table contains changes that have been incorporated into the publication since its original February 2020 release. Errata updates can include corrections, clarifications, or other minor changes that are either editorial or substantive in nature. All entries below are dated January 28, 2021.

Location	Type	Change
Front matter (Cautionary note)	Editorial	Changed "The requirements apply only" to "The security requirements apply"
Chapter One, §1.1, paragraph 1	Editorial	Deleted the sentence "The requirements apply only to components of nonfederal systems that process, store, or transmit CUI, or that provide security protection for such components."
Chapter One, §1.1, paragraph 2	Editorial	Added a passage on the scope of applicability and on isolating designated system components into a separate CUI security domain
Chapter One, §1.1, paragraph 3	Editorial	Changed "The requirements are" to "The recommended security requirements in this publication are"
Chapter One, §1.1, paragraph 6	Editorial	Deleted a passage on isolating CUI into its own security domain (superseded by the paragraph 2 addition above)

Table of contents

• Chapter One: Introduction
  • 1.1 Purpose and Applicability
  • 1.2 Target Audience
  • 1.3 Organization of this Special Publication
• Chapter Two: The Fundamentals
  • 2.1 Basic Assumptions
  • 2.2 Development of Security Requirements
• Chapter Three: The Requirements
  • 3.1 Access Control
  • 3.2 Awareness and Training
  • 3.3 Audit and Accountability
  • 3.4 Configuration Management
  • 3.5 Identification and Authentication
  • 3.6 Incident Response
  • 3.7 Maintenance
  • 3.8 Media Protection
  • 3.9 Personnel Security
  • 3.10 Physical Protection
  • 3.11 Risk Assessment
  • 3.12 Security Assessment
  • 3.13 System and Communications Protection
  • 3.14 System and Information Integrity
• Appendix A: References
• Appendix B: Glossary
• Appendix C: Acronyms
• Appendix D: Mapping Tables
• Appendix E: Tailoring Criteria

Chapter One: Introduction

The need to protect Controlled Unclassified Information

Today, more than at any time in history, the federal government relies on external service providers to help carry out a wide range of federal missions and business functions using information systems. Many federal contractors process, store, and transmit sensitive federal information to support the delivery of essential products and services to federal agencies (e.g., providing financial services; providing web and electronic mail services; processing security clearances or healthcare data; providing cloud services; and developing communications, satellite, and weapons systems). Federal information is frequently provided to or shared with entities such as state and local governments, colleges and universities, and independent research organizations. The protection of sensitive federal information while residing in nonfederal systems and organizations is of paramount importance to federal agencies, and can directly impact the ability of the federal government to carry out its designated missions and business operations.

The protection of unclassified federal information in nonfederal systems and organizations is dependent on the federal government providing a process for identifying the different types of information that are used by federal agencies. Executive Order 13556 established a governmentwide Controlled Unclassified Information (CUI) Program to standardize the way the executive branch handles unclassified information that requires protection. Only information that requires safeguarding or dissemination controls pursuant to federal law, regulation, or governmentwide policy may be designated as CUI. The CUI Program is designed to address several deficiencies in managing and protecting unclassified information, including inconsistent markings, inadequate safeguarding, and needless restrictions, both by standardizing procedures and by providing common definitions through a CUI Registry maintained by NARA. The CUI Registry is the online repository for information, guidance, policy, and requirements on handling CUI, including issuances by the CUI Executive Agent. It identifies approved CUI categories, provides general descriptions for each, identifies the basis for controls, and sets out procedures for the use of CUI, including marking, safeguarding, transporting, disseminating, reusing, and disposing of the information.

Executive Order 13556 also required that the CUI Program emphasize openness, transparency, and uniformity of governmentwide practices, and that implementation take place consistent with applicable OMB policies and federal standards and guidelines issued by NIST. The federal CUI regulation, developed by the CUI Executive Agent, provides guidance to federal agencies on the designation, safeguarding, dissemination, marking, decontrolling, and disposition of CUI, establishes self-inspection and oversight requirements, and delineates other facets of the program.

1.1 Purpose and Applicability

The purpose of this publication is to provide federal agencies with recommended security requirements for protecting the confidentiality of CUI: (1) when the CUI is resident in a nonfederal system and organization; (2) when the nonfederal organization is not collecting or maintaining information on behalf of a federal agency or using or operating a system on behalf of an agency; and (3) where there are no specific safeguarding requirements for protecting the confidentiality of CUI prescribed by the authorizing law, regulation, or governmentwide policy for the CUI category listed in the CUI Registry.

The requirements apply to components of nonfederal systems that process, store, or transmit CUI, or that provide security protection for such components. If nonfederal organizations designate specific system components for the processing, storage, or transmission of CUI, those organizations may limit the scope of the security requirements by isolating the designated system components in a separate CUI security domain. Isolation can be achieved by applying architectural and design concepts (e.g., implementing subnetworks with firewalls or other boundary protection devices and using information flow control mechanisms). Security domains may employ physical separation, logical separation, or a combination of both. This approach can provide adequate security for the CUI and avoid increasing the organization's security posture to a level beyond that which it requires for protecting its missions, operations, and assets.

The recommended security requirements in this publication are intended for use by federal agencies in appropriate contractual vehicles or other agreements established between those agencies and nonfederal organizations. In CUI guidance and the CUI Federal Acquisition Regulation (FAR), the CUI Executive Agent will address determining compliance with security requirements.

In accordance with the federal CUI regulation, federal agencies using federal systems to process, store, or transmit CUI must, at a minimum, comply with:

• Federal Information Processing Standards (FIPS) Publication 199, Standards for Security Categorization of Federal Information and Information Systems (moderate confidentiality);
• Federal Information Processing Standards (FIPS) Publication 200, Minimum Security Requirements for Federal Information and Information Systems;
• NIST Special Publication 800-53, Security and Privacy Controls for Federal Information Systems and Organizations; and
• NIST Special Publication 800-60, Guide for Mapping Types of Information and Information Systems to Security Categories.

The responsibility of federal agencies to protect CUI does not change when such information is shared with nonfederal partners. Therefore, a similar level of protection is needed when CUI is processed, stored, or transmitted by nonfederal organizations using nonfederal systems. The recommended requirements for safeguarding CUI in nonfederal systems and organizations are derived from the above authoritative federal standards and guidelines to maintain a consistent level of protection. However, recognizing that the scope of the safeguarding requirements in the federal CUI regulation is limited to the security objective of confidentiality (i.e., not directly addressing integrity and availability), and that some of the security requirements expressed in the NIST standards and guidelines are uniquely federal, the requirements in this publication have been tailored for nonfederal entities.

The tailoring criteria described in Chapter Two are not intended to reduce or minimize the federal requirements for safeguarding CUI as expressed in the federal CUI regulation. Rather, the intent is to express the requirements in a manner that allows for and facilitates equivalent safeguarding measures within nonfederal systems and organizations and does not diminish the level of protection of CUI required for moderate confidentiality. Additional or differing requirements, other than those described in this publication, may be applied only when based on law, regulation, or governmentwide policy and when indicated in the CUI Registry as CUI-specified, or when an agreement establishes requirements to protect CUI Basic at higher than moderate confidentiality. The provision of safeguarding requirements for CUI in a specified category will be addressed by NARA in its CUI guidance and in the CUI FAR, and reflected as specific requirements in contracts or other agreements. Nonfederal organizations may use the same CUI infrastructure for multiple government contracts or agreements, if that infrastructure meets the safeguarding requirements for the organization's CUI-related contracts and/or agreements, including any specific safeguarding required or permitted by the authorizing law, regulation, or governmentwide policy.

1.2 Target Audience

This publication serves a diverse group of individuals and organizations in both the public and private sectors, including, but not limited to, individuals with:

• System development life cycle responsibilities (e.g., program managers, mission/business owners, information owners/stewards, system designers and developers, system/security engineers, systems integrators);
• Acquisition or procurement responsibilities (e.g., contracting officers);
• System, security, or risk management and oversight responsibilities (e.g., authorizing officials, chief information officers, chief information security officers, system owners, information security managers); and
• Security assessment and monitoring responsibilities (e.g., auditors, system evaluators, assessors, independent verifiers/validators, analysts).

These roles and responsibilities can be viewed from two distinct perspectives: the federal perspective, as the entity establishing and conveying the security requirements in contractual vehicles or other inter-organizational agreements; and the nonfederal perspective, as the entity responding to and complying with the security requirements set forth in contracts or agreements.

1.3 Organization of this Special Publication

The remainder of this special publication is organized as follows:

• Chapter Two describes the fundamental assumptions and methodology used to develop the security requirements for protecting the confidentiality of CUI; the format and structure of the requirements; and the tailoring criteria applied to the NIST standards and guidelines to obtain the requirements.
• Chapter Three describes the fourteen families of security requirements for protecting the confidentiality of CUI in nonfederal systems and organizations.
• Supporting appendices provide additional information related to the protection of CUI in nonfederal systems and organizations, including general references; definitions and terms; acronyms; mapping tables relating security requirements to the security controls in SP 800-53 and ISO/IEC 27001; and tailoring actions applied to the moderate security control baseline.

Chapter Two: The Fundamentals

Assumptions and methodology for developing security requirements

This chapter describes the assumptions and the methodology used to develop the recommended security requirements to protect CUI in nonfederal systems and organizations; the structure of the basic and derived security requirements; and the tailoring criteria applied to the federal information security requirements and controls.

2.1 Basic Assumptions

The recommended security requirements described in this publication have been developed based on three fundamental assumptions:

• Statutory and regulatory requirements for the protection of CUI are consistent, whether such information resides in federal systems or nonfederal systems, including the environments in which those systems operate;
• Safeguards implemented to protect CUI are consistent in both federal and nonfederal systems and organizations; and
• The confidentiality impact value for CUI is no less than FIPS 199 moderate.

These assumptions reinforce the concept that federal information designated as CUI has the same intrinsic value and potential adverse impact if compromised — whether the information resides in a federal or a nonfederal organization. Thus, protecting the confidentiality of CUI is critical to the mission and business success of federal agencies and to the economic and national security interests of the nation. Additional assumptions affecting the development of the security requirements, and the expectation of federal agencies working with nonfederal entities, include:

• Nonfederal organizations have information technology infrastructures in place, and are not necessarily developing or acquiring systems specifically for processing, storing, or transmitting CUI;
• Nonfederal organizations have specific safeguarding measures in place to protect their information, which may also be sufficient to satisfy the security requirements;
• Nonfederal organizations may not have the necessary organizational structure or resources to satisfy every security requirement and may implement alternative, but equally effective, security measures to compensate for the inability to satisfy a requirement; and
• Nonfederal organizations can implement a variety of potential security solutions directly, or using external service providers (e.g., managed services), to satisfy security requirements.

Implementing a single, state security solution for CUI: Controlled Unclassified Information has the same value whether it is resident in a federal system that is part of a federal agency or a nonfederal system that is part of a nonfederal organization. Accordingly, the recommended security requirements in this publication are consistent with, and complementary to, the standards and guidelines used by federal agencies to protect CUI.

2.2 Development of Security Requirements

The security requirements for protecting the confidentiality of CUI in nonfederal systems and organizations have a well-defined structure consisting of a basic security requirements section and a derived security requirements section. The basic security requirements are obtained from FIPS 200, which provides the high-level and fundamental security requirements for federal information and systems. The derived security requirements, which supplement the basic security requirements, are taken from the security controls in SP 800-53. Starting with the security requirements and controls in the moderate baseline (i.e., the minimum level of protection required for CUI in federal systems and organizations), the requirements and controls are tailored to eliminate requirements, controls, or parts of controls that are:

• Uniquely federal (i.e., primarily the responsibility of the federal government);
• Not directly related to protecting the confidentiality of CUI; or
• Expected to be routinely satisfied by nonfederal organizations without specification.

Appendix E provides a complete listing of security controls that support the CUI derived security requirements, and those controls that have been eliminated from the moderate baseline based on the CUI tailoring criteria described above.

The combination of the basic and derived security requirements captures the intent of FIPS 200 and SP 800-53 with respect to protecting the confidentiality of CUI in nonfederal systems and organizations. Appendix D provides informal mappings of the security requirements to the relevant security controls in SP 800-53 and ISO/IEC 27001. The mappings promote a better understanding of the CUI security requirements and are not intended to impose additional requirements on nonfederal organizations.

Example — structure of a CUI requirement (Media Protection family):

Basic Security Requirements

#	Requirement
3.8.1	Protect (i.e., physically control and securely store) system media containing CUI, both paper and digital.
3.8.2	Limit access to CUI on system media to authorized users.
3.8.3	Sanitize or destroy system media containing CUI before disposal or release for reuse.

Derived Security Requirements

#	Requirement
3.8.4	Mark media with necessary CUI markings and distribution limitations.
3.8.5	Control access to media containing CUI and maintain accountability for media during transport outside of controlled areas.
3.8.6	Implement cryptographic mechanisms to protect the confidentiality of CUI stored on digital media during transport unless otherwise protected by alternative physical safeguards.
3.8.7	Control the use of removable media on system components.
3.8.8	Prohibit the use of portable storage devices when such devices have no identifiable owner.
3.8.9	Protect the confidentiality of backup CUI at storage locations.

For ease of use, the security requirements are organized into fourteen families. Each family contains the requirements related to the general security topic of the family. The families are closely aligned with the minimum security requirements for federal information and systems described in FIPS 200. The contingency planning, system and services acquisition, and planning requirements are not included within the scope of this publication due to the tailoring criteria.

Table 1: Security requirement families

Family	Family
Access Control	Media Protection
Awareness and Training	Personnel Security
Audit and Accountability	Physical Protection
Configuration Management	Risk Assessment
Identification and Authentication	Security Assessment
Incident Response	System and Communications Protection
Maintenance	System and Information Integrity

A discussion section follows each CUI security requirement, providing additional information to facilitate implementation and assessment of the requirement. This information is derived primarily from the security control discussion sections in SP 800-53 and is provided to give organizations a better understanding of the mechanisms and procedures used to implement the controls that protect CUI. The discussion section is informative, not normative: it is not intended to extend the scope of a requirement or to influence the solutions organizations may use to satisfy it. The use of examples is notional, not exhaustive, and not reflective of the potential options available to organizations. The example below illustrates basic security requirement 3.8.3 with its supporting discussion section.

3.8.3

Sanitize or destroy system media containing CUI before disposal or release for reuse.

DISCUSSION

This requirement applies to all system media, digital and non-digital, subject to disposal or reuse. Examples include: digital media found in workstations, network components, scanners, copiers, printers, notebook computers, and mobile devices; and non-digital media such as paper and microfilm. The sanitization process removes information from the media such that the information cannot be retrieved or reconstructed. Sanitization techniques, including clearing, purging, cryptographic erase, and destruction, prevent the disclosure of information to unauthorized individuals when such media is released for reuse or disposal. Organizations determine the appropriate sanitization methods, recognizing that destruction may be necessary when other methods cannot be applied to the media requiring sanitization. Organizations use discretion in employing sanitization techniques and procedures for media containing information that is in the public domain, is publicly releasable, or is deemed to have no adverse impact on organizations or individuals if released for reuse or disposal. Sanitization of non-digital media includes destruction, removing CUI from documents, or redacting selected sections or words from a document by obscuring the redacted sections or words in a manner equivalent in effectiveness to removing the words or sections from the document. NARA policy and guidance control sanitization processes for controlled unclassified information. (SP 800-88 provides guidance on media sanitization.)

Chapter Three: The Requirements

Security requirements for protecting the confidentiality of CUI

This chapter describes fourteen families of recommended security requirements for protecting the confidentiality of CUI in nonfederal systems and organizations. The security controls from SP 800-53 associated with the basic and derived requirements are listed in Appendix D. Organizations can use the NIST publication to obtain additional, non-prescriptive information related to the recommended security requirements (e.g., explanatory information in the discussion section for each of the referenced security controls, mapping tables to ISO/IEC 27001 security controls, and a catalog of optional controls that can be used to specify additional security requirements, if needed). This information can help clarify or interpret the requirements in the context of mission and business requirements, operational environments, or assessments of risk. Nonfederal organizations can implement a variety of potential security solutions, either directly or using managed services, to satisfy the security requirements, and may implement alternative, but equally effective, security measures to compensate for the inability to satisfy a requirement.

Discussion section: The discussion section associated with each CUI requirement is informative, not normative. It is not intended to extend the scope of a requirement or to influence the solutions organizations may use to satisfy a requirement. In addition, the use of examples is notional, not exhaustive, and not reflective of potential options available to organizations.

Nonfederal organizations describe, in a system security plan, how the security requirements are met or how organizations plan to meet the requirements and address known and anticipated threats. The system security plan describes: the system boundary; operational environment; how security requirements are implemented; and the relationships with or connections to other systems. Nonfederal organizations develop plans of action that describe how unimplemented security requirements will be met and how any planned mitigations will be implemented. Organizations can document the system security plan and the plan of action as separate or combined documents and in any chosen format.

When requested, the system security plan (or extracts thereof) and the associated plans of action for any planned implementations or mitigations are submitted to the responsible federal agency/contracting office to demonstrate the nonfederal organization's implementation or planned implementation of the security requirements. Federal agencies may consider the submitted system security plans and plans of action as critical inputs to a risk management decision to process, store, or transmit CUI on a system hosted by a nonfederal organization, and whether it is advisable to pursue an agreement or contract with the nonfederal organization.

The recommended security requirements in this publication apply only to the components of nonfederal systems that process, store, or transmit CUI or that provide protection for such components. Some systems, including specialized systems (e.g., industrial/process control systems, medical devices, computer numerical control machines), may have limitations on the application of certain security requirements. To accommodate such issues, the system security plan, as reflected in requirement 3.12.4, is used to describe any enduring exceptions to the security requirements. Individual, isolated, or temporary deficiencies are managed through plans of action, as reflected in requirement 3.12.2.

The meaning of organizational systems: The term organizational system is used in many of the recommended CUI security requirements in this publication. This term has a specific meaning regarding the scope of applicability for the security requirements: the requirements apply only to the components of nonfederal systems that process, store, or transmit CUI, or that provide protection for the system components. The appropriate scoping for the CUI security requirements is an important factor in determining protection-related investment decisions and managing security risk for nonfederal organizations that have the responsibility of safeguarding CUI.

3.1 Access Control

Basic Security Requirements

3.1.1

Limit system access to authorized users, processes acting on behalf of authorized users, and devices (including other systems).

Discussion: Access control policies (e.g., identity- or role-based policies, control matrices, and cryptography) control access between active entities or subjects (i.e., users or processes acting on behalf of users) and passive entities or objects (e.g., devices, files, records, and domains) in systems. Access enforcement mechanisms can be employed at the application and service level to provide increased information security. Other systems include systems internal and external to the organization. This requirement focuses on account management for systems and applications. The definition of and enforcement of access authorizations, other than those determined by account type (e.g., privileged versus non-privileged), are addressed in requirement 3.1.2.

3.1.2

Limit system access to the types of transactions and functions that authorized users are permitted to execute.

Discussion: Organizations may choose to define access privileges or other attributes by account, by type of account, or a combination of both. System account types include individual, shared, group, system, anonymous, guest, emergency, developer, manufacturer, vendor, and temporary. Other attributes required for authorizing access include restrictions on time-of-day, day-of-week, and point-of-origin. In defining other account attributes, organizations consider system-related requirements (e.g., scheduled system upgrades and maintenance) and mission or business requirements (e.g., time zone differences, customer requirements, remote access to support travel requirements).

Derived Security Requirements

3.1.3

Control the flow of CUI in accordance with approved authorizations.

Discussion: Information flow control regulates where information can travel within a system and between systems (versus who can access the information), without explicit regard to subsequent accesses to that information. Flow control restrictions include: keeping export-controlled information from being transmitted in the clear to the Internet; blocking outside traffic that claims to be from within the organization; restricting requests to the Internet that are not from the internal web proxy server; and limiting information transfers between organizations based on data structures and content.

Organizations commonly use information flow control policies and enforcement mechanisms to control the flow of information between designated sources and destinations (e.g., networks, individuals, and devices) within systems and between interconnected systems. Flow control is based on characteristics of the information or the information path. Enforcement occurs in boundary protection devices (e.g., gateways, routers, guards, encrypted tunnels, firewalls) that employ rule sets or configuration settings that restrict system services, provide packet-filtering based on header information, or message-filtering based on message content. Organizations also consider the trustworthiness of filtering and inspection mechanisms critical to information flow enforcement.

Transferring information between systems representing different security domains with different security policies introduces the risk that such transfers violate one or more domain security policies. In such situations, information owners or stewards provide guidance at designated policy enforcement points between interconnected systems. Enforcement includes prohibiting information transfers between interconnected systems (i.e., allowing access only), employing hardware mechanisms to enforce one-way information flows, and implementing trustworthy regrading mechanisms to reassign security attributes and labels.

3.1.4

Separate the duties of individuals to reduce the risk of malevolent activity without collusion.

Discussion: Separation of duties addresses the potential for abuse of authorized privileges and helps reduce the risk of malevolent activity without collusion. It includes dividing mission functions and system support functions among different individuals or roles; conducting system support functions with different individuals (e.g., configuration management, quality assurance and testing, system management, programming, and network security); and ensuring that security personnel administering access control functions do not also administer audit functions. Because separation-of-duty violations can span systems and application domains, organizations consider the entirety of organizational systems and components when developing policy on separation of duties.

3.1.5

Employ the principle of least privilege, including for specific security functions and privileged accounts.

Discussion: Organizations employ the principle of least privilege for specific duties and authorized accesses for users and processes, with the goal of authorized privileges no higher than necessary to accomplish required missions or business functions. Organizations consider creating additional processes, roles, and system accounts as necessary to achieve least privilege, and also apply least privilege to the development, implementation, and operation of organizational systems. Security functions include establishing system accounts, setting logged events, setting intrusion detection parameters, and configuring access authorizations.

Privileged accounts, including super user accounts, are typically described as system administrator accounts for various commercial off-the-shelf operating systems. Restricting privileged accounts to specific personnel or roles prevents day-to-day users from having access to privileged information or functions. Organizations may differentiate application of this requirement between local and domain accounts, provided they retain the ability to control system configurations for key security parameters and otherwise sufficiently mitigate risk.

3.1.6

Use non-privileged accounts or roles when accessing nonsecurity functions.

Discussion: This requirement limits exposure when operating from within privileged accounts or roles. The inclusion of roles addresses situations where organizations implement access control policies such as role-based access control, and where a change of role provides the same degree of assurance in the change of access authorizations for the user and all processes acting on the user's behalf as would be provided by a change between a privileged and non-privileged account.

3.1.7

Prevent non-privileged users from executing privileged functions and capture the execution of such functions in audit logs.

Discussion: Privileged functions include establishing system accounts, performing system integrity checks, conducting patching operations, or administering cryptographic key management activities. Non-privileged users are individuals who do not possess appropriate authorizations. Circumventing intrusion detection and prevention mechanisms or malicious code protection mechanisms are examples of privileged functions requiring protection from non-privileged users. This requirement represents a condition to be achieved by the definition of authorized privileges in 3.1.2.

Misuse of privileged functions, whether intentional or unintentional by authorized users, or by unauthorized external entities that have compromised system accounts, is a serious and ongoing concern with potentially significant adverse impacts. Logging the use of privileged functions is one way to detect such misuse and help mitigate the risk from insider threats and the advanced persistent threat.

3.1.8

Limit unsuccessful logon attempts.

Discussion: This requirement applies regardless of whether the logon occurs via a local or network connection. Due to the potential for denial of service, automatic lockouts initiated by systems are, in most cases, temporary and automatically release after a predetermined period established by the organization (i.e., a delay algorithm). Organizations may employ different delay algorithms for different system components based on their capabilities. Responses to unsuccessful logon attempts may be implemented at the operating system and application levels.

3.1.9

Provide privacy and security notices consistent with applicable CUI rules.

Discussion: System use notifications can be implemented using messages or warning banners displayed before individuals log in to organizational systems. System use notifications are used only for access via logon interfaces with human users and are not required when such human interfaces do not exist. Based on a risk assessment, organizations consider whether a secondary system use notification is needed to access applications or other system resources after the initial network logon. Where necessary, posters or other printed materials may be used in lieu of an automated system banner. Organizations consult with the Office of General Counsel for legal review and approval of warning banner content.

3.1.10

Use session lock with pattern-hiding displays to prevent access and viewing of data after a period of inactivity.

Discussion: Session locks are temporary actions taken when users stop work and move away from the immediate vicinity of the system but do not want to log out because of the temporary nature of their absence. Session locks are implemented where session activities can be determined, typically at the operating system level, but can also be at the application level. Session locks are not an acceptable substitute for logging out of the system, for example, if organizations require users to log out at the end of the workday.

Pattern-hiding displays can include static or dynamic images, such as screen-saver patterns, photographic images, solid colors, a clock, a battery-life indicator, or a blank screen, with the additional caveat that none of the images convey controlled unclassified information.

3.1.11

Terminate (automatically) a user session after a defined condition.

Discussion: This requirement addresses the termination of user-initiated logical sessions, in contrast to the termination of network connections associated with communications sessions (i.e., disconnecting from the network). A logical session (for local, network, and remote access) is initiated whenever a user (or process acting on a user's behalf) accesses an organizational system. Such user sessions can be terminated (and thus terminate user access) without terminating network sessions. Session termination terminates all processes associated with a user's logical session except those specifically created by the user (i.e., session owner) to continue after the session is terminated. Conditions or trigger events requiring automatic session termination can include organization-defined periods of user inactivity, targeted responses to certain types of incidents, and time-of-day restrictions on system use.

3.1.12

Monitor and control remote access sessions.

Discussion: Remote access is access to organizational systems by users (or processes acting on their behalf) communicating through external networks (e.g., the Internet). Remote access methods include dial-up, broadband, and wireless. Organizations often employ encrypted virtual private networks (VPNs) to enhance confidentiality over remote connections; the use of encrypted VPNs does not make the access non-remote, but when adequately provisioned with appropriate controls, may provide sufficient assurance that the organization can effectively treat such connections as internal networks. VPNs with encrypted tunnels can affect the capability to adequately monitor network communications traffic for malicious code.

Automated monitoring and control of remote access sessions allows organizations to detect cyberattacks and help ensure ongoing compliance with remote access policies by auditing connection activities of remote users on a variety of system components (e.g., servers, workstations, notebook computers, smart phones, and tablets). NIST Special Publications 800-46, 800-77, and 800-113 provide guidance on secure remote access and virtual private networks.

3.1.13

Employ cryptographic mechanisms to protect the confidentiality of remote access sessions.

Discussion: Cryptographic standards include FIPS-validated cryptography and NSA-approved cryptography.

3.1.14

Route remote access via managed access control points.

Discussion: Routing remote access through managed access control points enhances explicit, organizational control over such connections, reducing susceptibility to unauthorized access to organizational systems resulting in the unauthorized disclosure of CUI.

3.1.15

Authorize remote execution of privileged commands and remote access to security-relevant information.

Discussion: A privileged command is a human-initiated (interactively or via a process operating on the human's behalf) command executed on a system involving the control, monitoring, or administration of the system, including security functions and associated security-relevant information. Security-relevant information is any information within the system that can potentially impact the operation of security functions or the provision of security services in a manner that could result in failure to enforce the system security policy or maintain isolation of code and data. Privileged commands give individuals the ability to execute sensitive, security-critical, or security-relevant system functions. Controlling such access from remote locations helps ensure that unauthorized individuals cannot freely execute such commands with the potential to do serious or catastrophic damage to organizational systems. The ability to affect the integrity of the system is considered security-relevant, as it could enable a means to bypass security functions, even without directly impacting the function itself.

3.1.16

Authorize wireless access prior to allowing such connections.

Discussion: Establishing usage restrictions and configuration/connection requirements for wireless access to the system provides criteria for organizations to support wireless access authorization decisions, reducing the susceptibility to unauthorized access to the system through wireless technologies. Wireless networks use authentication protocols that provide credential protection and mutual authentication. NIST Special Publication 800-97 provides guidance on secure wireless networks.

3.1.17

Protect wireless access using authentication and encryption.

Discussion: Organizations authenticate individuals and devices to help protect wireless access to the system. Special attention is given to the wide variety of devices that are part of the Internet of Things, which may have wireless access to organizational systems.

3.1.18

Control connection of mobile devices.

Discussion: A mobile device is a computing device with a small form factor that can easily be carried by a single individual; is designed to operate without a physical connection (e.g., wirelessly transmitting or receiving information); possesses local, non-removable or removable data storage; and includes a self-contained power source. Mobile devices may also include voice communication capabilities, on-board sensors allowing the device to capture information, or built-in features for synchronizing local data with remote locations. Examples include smart phones, e-readers, and tablets.

Due to the large variety of mobile devices with different technical characteristics and capabilities, organizational restrictions may vary for different device types. Usage restrictions and implementation guidance for mobile devices include: device identification and authentication; configuration management; implementation of mandatory protective software (e.g., malicious code detection, firewall); scanning devices for malicious code; updating virus protection software; scanning for critical software updates and patches; conducting operating system integrity checks; and disabling unnecessary hardware (e.g., wireless, infrared). Many controls for mobile devices are reflected in other CUI security requirements. NIST Special Publication 800-124 provides guidance on mobile device security.

3.1.19

Encrypt CUI on mobile devices and mobile computing platforms.

Discussion: Organizations can employ full-device encryption or container-based encryption to protect the confidentiality of CUI on mobile devices and computing platforms. Container-based encryption provides a more fine-grained approach, including encrypting selected data structures such as files, records, or fields.

3.1.20

Verify and control/limit connections to and use of external systems.

Discussion: External systems are systems or components for which organizations typically have no direct supervision and authority over the application of security requirements and controls, or the determination of the effectiveness of implemented controls. External systems include personally owned systems, components, or devices, and privately owned computing and communications devices resident in commercial or public facilities. This requirement also addresses the use of external systems for the processing, storage, or transmission of CUI, including accessing cloud services (e.g., infrastructure as a service, platform as a service, or software as a service) from organizational systems.

Organizations establish terms and conditions for the use of external systems in accordance with organizational security policies and procedures, addressing at a minimum the types of applications that can be accessed on organizational systems from external systems. If terms and conditions with the owners of external systems cannot be established, organizations may impose restrictions on organizational personnel using those external systems.

This requirement recognizes that there are circumstances where individuals using external systems (e.g., contractors, coalition partners) need to access organizational systems. In those situations, organizations need confidence that the external systems contain the necessary controls so as not to compromise, damage, or otherwise harm organizational systems. Verification that the required controls have been effectively implemented can be achieved through third-party independent assessments, attestations, or other means, depending on the assurance or confidence level required.

Note that while "external" typically refers to outside of the organization's direct supervision and authority, that is not always the case: an organization may have systems that process CUI and others that do not, and among the systems that process CUI there are likely access restrictions that apply between systems. Therefore, from the perspective of a given system, other systems within the organization may be considered "external" to that system.

3.1.21

Limit use of portable storage devices on external systems.

Discussion: Limits on the use of organization-controlled portable storage devices in external systems include complete prohibition of use, or restrictions on how and under what conditions the devices may be used. As with 3.1.20, "external" does not always mean outside the organization; from the perspective of a given system, other systems within the organization may be considered "external" to that system.

3.1.22

Control CUI posted or processed on publicly accessible systems.

Discussion: In accordance with laws, executive orders, directives, policies, regulations, or standards, the public is not authorized access to nonpublic information (e.g., information protected under the Privacy Act, CUI, and proprietary information). This requirement addresses systems that are controlled by the organization and accessible to the public, typically without identification or authentication. Individuals authorized to post CUI onto publicly accessible systems are designated, and the content of information is reviewed prior to posting to ensure that nonpublic information is not included.

3.2 Awareness and Training

Basic Security Requirements

3.2.1

Ensure that managers, systems administrators, and users of organizational systems are made aware of the security risks associated with their activities and of the applicable policies, standards, and procedures related to the security of those systems.

Discussion: Organizations determine the content and frequency of security awareness training and techniques based on specific organizational requirements and the systems to which personnel have authorized access. Content includes a basic understanding of the need for information security and user actions to maintain security and respond to suspected security incidents, as well as awareness of the need for operations security. Techniques include formal training, supplies inscribed with security reminders, email advisories, logon screen messages, security awareness posters, and information security awareness events. NIST Special Publication 800-50 provides guidance on security awareness and training programs.

3.2.2

Ensure that personnel are trained to carry out their assigned information security-related duties and responsibilities.

Discussion: Organizations determine the content and frequency of security training based on assigned duties, roles, and responsibilities, and the security requirements of organizations and the systems to which personnel have authorized access. Organizations provide system developers, architects, acquisition/procurement officials, system/network administrators, configuration management and auditing personnel, independent verification and validation personnel, security assessors, and others with system-level access, security-related technical training tailored to their assigned duties. Comprehensive role-based training addresses management, operational, and technical roles and responsibilities covering physical, personnel, and technical controls, and can include policies, procedures, tools, and artifacts for the defined security roles. Organizations also provide training for responsibilities related to operations and supply chain security. NIST Special Publication 800-181 provides guidance on role-based information security training; NIST Special Publication 800-161 provides guidance on supply chain risk management.

Derived Security Requirements

3.2.3

Provide security awareness training on recognizing and reporting potential indicators of insider threat.

Discussion: Potential indicators and possible precursors of insider threat include behaviors such as: inordinate, long-term job dissatisfaction; attempts to gain access to information not required for job performance; unexplained access to financial resources; bullying or sexual harassment of fellow employees; workplace violence; and other serious violations of organizational policies, procedures, directives, rules, or practices. Security awareness training includes how to communicate employee and management concerns about potential indicators of insider threat through appropriate organizational channels. Organizations may consider tailoring insider threat awareness topics to the role (e.g., training for managers focused on changes in team members' behavior, training for employees focused on more general observations).

3.3 Audit and Accountability

Basic Security Requirements

3.3.1

Create and retain system audit logs and records to the extent needed to enable the monitoring, analysis, investigation, and reporting of unlawful or unauthorized system activity.

Discussion: An event is any observable occurrence in a system, including unlawful or unauthorized system activity. Organizations identify event types for which a logging functionality is needed as those significant and relevant to the security of systems and their operating environments. Event types can include password changes, failed logons or accesses, administrative privilege usage, or third-party credential usage. Organizations consider the monitoring and auditing appropriate for each CUI security requirement, balanced with other system needs; for example, systems may have the capability to log every file access but not activate that capability except in specific circumstances due to the potential burden on performance.

Audit records can be generated at various levels of abstraction, including at the packet level. Selecting the appropriate level of abstraction is a critical aspect of audit logging and can facilitate identifying root causes of problems. Organizations consider the logging necessary to cover related events, such as steps in distributed, transaction-based processes and actions occurring in service-oriented or cloud-based architectures.

Audit record content that may be necessary includes time stamps, source and destination addresses, user or process identifiers, event descriptions, success or failure indications, filenames involved, and access control or flow control rules invoked. Organizations consider limiting additional audit log information to only what is explicitly needed, to avoid misleading information or making it harder to locate information of interest. Audit logs are reviewed and analyzed as often as needed to facilitate risk-based decision making. NIST Special Publication 800-92 provides guidance on security log management.

3.3.2

Ensure that the actions of individual system users can be uniquely traced to those users, so they can be held accountable for their actions.

Discussion: This requirement ensures that audit record content includes the information needed to link an audit event to the actions of an individual, to the extent feasible. Organizations consider logging for traceability including account usage, remote access, wireless connectivity, mobile device connection, boundary communications, configuration settings, physical access, nonlocal maintenance, use of maintenance tools, temperature and humidity, equipment delivery and removal, system component inventory, use of mobile code, and use of Voice over Internet Protocol (VoIP).

Derived Security Requirements

3.3.3

Review and update logged events.

Discussion: The intent of this requirement is to periodically re-evaluate which logged events will continue to be included in the list of events to be logged. Event types logged by organizations may change over time; periodic review and updating ensures that the current set remains necessary and sufficient.

3.3.4

Alert in the event of an audit logging process failure.

Discussion: Audit logging process failures include software and hardware errors, failures in audit record capturing mechanisms, and audit record storage capacity being reached or exceeded. This requirement applies to each audit record data storage repository, the total audit record storage capacity of organizations, or both.

3.3.5

Correlate audit record review, analysis, and reporting processes for investigation and response to indications of unlawful, unauthorized, suspicious, or unusual activity.

Discussion: Correlating audit record review, analysis, and reporting processes helps ensure they operate collectively rather than independently. The requirement is agnostic as to whether correlation is applied at the system level or the organization level across all systems.

3.3.6

Provide audit record reduction and report generation to support on-demand analysis and reporting.

Discussion: Audit record reduction manipulates collected audit information and organizes it into a summary format more meaningful to analysts. Reduction and report generation capabilities do not always come from the same system or organizational entity conducting auditing activities, and can include modern data mining techniques with advanced data filters to identify anomalous behavior. Time ordering of audit records can be a significant issue if time stamp granularity in the record is insufficient.

3.3.7

Provide a system capability that compares and synchronizes internal system clocks with an authoritative source to generate time stamps for audit records.

Discussion: Internal system clocks generate time stamps, expressed in Coordinated Universal Time (UTC), a modern continuation of Greenwich Mean Time (GMT), or local time with an offset from UTC. Granularity of time measurements refers to the degree of synchronization between system clocks and reference clocks (e.g., within hundreds or tens of milliseconds); organizations may define different granularities for different components. Time service can also be critical to other security capabilities such as access control and identification and authentication. This requirement provides uniformity of time stamps for systems with multiple clocks and systems connected over a network.

3.3.8

Protect audit information and audit logging tools from unauthorized access, modification, and deletion.

Discussion: Audit information includes all information (e.g., audit records, audit log settings, and audit reports) needed to successfully audit system activity. Audit logging tools are the programs and devices used to conduct audit and logging activities. This requirement focuses on the technical protection of audit information and limits the ability to access and execute audit logging tools to authorized individuals; physical protection of audit information is addressed by media protection and physical/environmental protection requirements.

3.3.9

Limit management of audit logging functionality to a subset of privileged users.

Discussion: Individuals with privileged access to a system who are also subject to audit by that system may affect the reliability of audit information by inhibiting audit logging activities or modifying audit records. This requirement specifies that privileged access be further defined between audit-related privileges and other privileges, limiting the users who have audit-related privileges.

3.4 Configuration Management

Basic Security Requirements

3.4.1

Establish and maintain baseline configurations and inventories of organizational systems (including hardware, software, firmware, and documentation) throughout the respective system development life cycles.

Discussion: Baseline configurations are documented, formally reviewed, and agreed-upon specifications for systems or configuration items within them, serving as a basis for future builds, releases, and changes. Baseline configurations include information about system components (e.g., standard software packages installed on workstations, notebook computers, servers, network components, or mobile devices; current version, update, and patch information for operating systems and applications; and configuration settings and parameters), network topology, and the logical placement of components within the system architecture. Maintaining effective baseline configurations requires creating new baselines as systems change over time, including reviewing and updating the baseline when changes are made based on security risks and deviations from the established configuration.

Organizations can implement centralized system component inventories spanning multiple organizational systems, ensuring the inventories include system-specific information required for proper component accountability (e.g., system association, system owner). Information for effective accountability includes hardware inventory specifications, software license information, software version numbers, component owners, and, for networked components, machine names and network addresses. NIST Special Publication 800-128 provides guidance on security-focused configuration management.

3.4.2

Establish and enforce security configuration settings for information technology products employed in organizational systems.

Discussion: Configuration settings are the parameters that can be changed in hardware, software, or firmware components that affect the security posture or functionality of the system. Products for which security-related settings can be defined include mainframe computers, servers, workstations, input/output devices, network components, operating systems, middleware, and applications.

Security parameters are those impacting the security state of systems, including parameters required to satisfy other security requirements, such as registry settings, account/file/directory permission settings, and settings for functions, ports, protocols, and remote connections. Organizations establish organization-wide configuration settings and derive specific settings for systems, which become part of the systems' configuration baseline. Common secure configurations (also called security configuration checklists, lockdown and hardening guides, security reference guides, or security technical implementation guides) provide recognized, standardized benchmarks for secure configuration of specific IT platforms/products. NIST Special Publications 800-70 and 800-128 provide guidance on security configuration settings.

Derived Security Requirements

3.4.3

Track, review, approve or disapprove, and log changes to organizational systems.

Discussion: Tracking, reviewing, approving/disapproving, and logging changes is called configuration change control, which involves the systematic proposal, justification, implementation, testing, review, and disposition of changes to systems, including upgrades and modifications. It includes changes to baseline configurations, changes to configuration settings for IT products, unscheduled and unauthorized changes, and changes to remediate vulnerabilities. Processes for managing configuration changes include Configuration Control Boards or Change Advisory Boards that review and approve proposed changes. NIST Special Publication 800-128 provides guidance on configuration change control.

3.4.4

Analyze the security impact of changes prior to implementation.

Discussion: Personnel with information security responsibilities (e.g., system administrators, security officers, security managers, security engineers) conduct security impact analyses, possessing the necessary skills and technical expertise to analyze changes and their security ramifications. This may include reviewing security plans and system design documentation to understand controls and how changes might affect them, and may include risk assessments to understand impact and determine if additional controls are required. NIST Special Publication 800-128 provides related guidance.

3.4.5

Define, document, approve, and enforce physical and logical access restrictions associated with changes to organizational systems.

Discussion: Any changes to hardware, software, or firmware components can potentially have significant effects on overall system security. Organizations therefore permit only qualified and authorized individuals to access systems to initiate changes, including upgrades and modifications; access restrictions for change also include software libraries. Restrictions include physical and logical access control requirements, workflow automation, media libraries, abstract layers, and change windows. NIST Special Publication 800-128 provides related guidance.

3.4.6

Employ the principle of least functionality by configuring organizational systems to provide only essential capabilities.

Discussion: Systems can provide a wide variety of functions and services, some of which, though provided by default, may not be necessary to support essential organizational missions or operations. Providing multiple services from a single system component increases risk relative to limiting the services provided by any one component; where feasible, organizations limit component functionality to a single function per component. Organizations review functions and services to determine candidates for elimination, disable unused or unnecessary physical and logical ports and protocols, and can use network scanning tools, intrusion detection and prevention systems, and end-point protections to identify and prevent the use of prohibited functions, ports, protocols, and services.

3.4.7

Restrict, disable, or prevent the use of nonessential programs, functions, ports, protocols, and services.

Discussion: Restricting nonessential software includes restricting the roles allowed to approve program execution, prohibiting auto-execute, program blacklisting and whitelisting, or restricting the number of program instances executed simultaneously. Organizations make a security-based determination of which functions, ports, protocols, and services are restricted. Bluetooth, File Transfer Protocol (FTP), and peer-to-peer networking are examples of protocols organizations consider preventing, restricting, or disabling.

3.4.8

Apply deny-by-exception (blacklisting) policy to prevent the use of unauthorized software or deny-all, permit-by-exception (whitelisting) policy to allow the execution of authorized software.

Discussion: The process used to identify software programs not authorized to execute is commonly called blacklisting; the process used to identify programs that are authorized to execute is commonly called whitelisting. Whitelisting is the stronger of the two policies. Organizations also consider verifying the integrity of whitelisted software using, for example, cryptographic checksums, digital signatures, or hash functions, either prior to execution or at system startup. NIST Special Publication 800-167 provides guidance on application whitelisting.

3.4.9

Control and monitor user-installed software.

Discussion: Users can install software in organizational systems if given the necessary privileges. To maintain control, organizations identify permitted and prohibited actions regarding software installation through policy. Permitted installations may include updates and security patches from organization-approved "app stores"; prohibited installations may include software with unknown or suspect pedigrees or software considered potentially malicious. Policy enforcement methods include procedural methods, automated methods, or both.

3.5 Identification and Authentication

Basic Security Requirements

3.5.1

Identify system users, processes acting on behalf of users, and devices.

Discussion: Common device identifiers include Media Access Control (MAC) addresses, Internet Protocol (IP) addresses, or device-unique token identifiers. Management of individual identifiers does not apply to shared system accounts; typically, individual identifiers are the user names associated with system accounts assigned to individuals. Organizations may require unique identification of individuals in group accounts, and this requirement also addresses individual identifiers not necessarily associated with system accounts. Organizational devices requiring identification may be defined by type, by device, or by a combination of both. NIST Special Publication 800-63-3 provides guidance on digital identities.

3.5.2

Authenticate (or verify) the identities of users, processes, or devices, as a prerequisite to allowing access to organizational systems.

Discussion: Individual authenticators include passwords, key cards, cryptographic devices, and one-time password devices. Developers ship system components with factory default authentication credentials to allow for initial installation and configuration; default credentials are often well known, easily discoverable, and present a significant security risk. Systems support authenticator management through organization-defined settings and restrictions for authenticator characteristics, including minimum password length, validation time windows for time-synchronous one-time tokens, and the number of allowed rejections during biometric verification. Authenticator management includes issuing and revoking authenticators for temporary access, such as for remote maintenance. Device authenticators include certificates and passwords. NIST Special Publication 800-63-3 provides guidance on digital identities.

Derived Security Requirements

3.5.3

Use multifactor authentication for local and network access to privileged accounts and for network access to non-privileged accounts.

Discussion: Multifactor authentication requires two or more different factors: something you know (e.g., password, PIN); something you have (e.g., cryptographic identification device, token); or something you are (e.g., biometric). Solutions featuring physical authenticators include hardware authenticators providing time-based or challenge-response authentication and smart cards. Organizations may also employ authentication mechanisms at the application level, when necessary.

Access to organizational systems is defined as local access or network access. Local access is any access obtained by direct connection without the use of networks; network access is access obtained through network connections. Remote access is a type of network access involving communication through external networks. Encrypted virtual private networks connecting organization-controlled and non-organization-controlled endpoints may be treated as internal networks with regard to confidentiality protection. NIST Special Publication 800-63-3 provides guidance on digital identities.

3.5.4

Employ replay-resistant authentication mechanisms for network access to privileged and non-privileged accounts.

Discussion: Authentication processes resist replay attacks if it is impractical to successfully authenticate by recording or replaying previous authentication messages. Replay-resistant techniques include protocols using nonces or challenges, such as time-synchronous or challenge-response one-time authenticators. NIST Special Publication 800-63-3 provides guidance on digital identities.

3.5.5

Prevent reuse of identifiers for a defined period.

Discussion: Identifiers are provided for users, processes acting on their behalf, or devices (see 3.5.1). Preventing reuse implies preventing the assignment of previously used individual, group, role, or device identifiers to different individuals, groups, roles, or devices.

3.5.6

Disable identifiers after a defined period of inactivity.

Discussion: Inactive identifiers pose a risk because attackers may exploit them to gain undetected access to organizational devices; owners of inactive accounts may not notice if unauthorized access has occurred.

3.5.7

Enforce a minimum password complexity and change of characters when new passwords are created.

Discussion: This requirement applies to single-factor authentication of individuals using passwords as individual or group authenticators, and similarly when passwords are used as part of multifactor authenticators. The number of changed characters refers to the number of changes required relative to the total number of positions in the current password. Organizations may also consider salting passwords to mitigate certain brute-force attacks.

3.5.8

Prohibit password reuse for a specified number of generations.

Discussion: Password lifetime restrictions do not apply to temporary passwords.

3.5.9

Allow temporary password use for system logons with an immediate change to a permanent password.

Discussion: Changing temporary passwords to permanent passwords immediately after system logon ensures the necessary strength of the authentication mechanism is implemented at the earliest opportunity, reducing susceptibility to authenticator compromise.

3.5.10

Store and transmit only cryptographically-protected passwords.

Discussion: Cryptographically protected passwords use salted one-way cryptographic hashes of passwords.

3.5.11

Obscure feedback of authentication information.

Discussion: System feedback does not provide information that would allow unauthorized individuals to compromise authentication mechanisms. For systems with relatively large monitors (e.g., desktop or notebook computers), the threat of "shoulder surfing" may be significant; for systems with small displays (e.g., mobile devices) this threat may be less significant but is balanced against the increased likelihood of typographic input errors from small keyboards. The means for obscuring feedback — such as displaying asterisks when users type passwords, or showing feedback briefly before fully obscuring it — is selected accordingly.

3.6 Incident Response

Basic Security Requirements

3.6.1

Establish an operational incident-handling capability for organizational systems that includes preparation, detection, analysis, containment, recovery, and user response activities.

Discussion: Incident-handling capability depends on the capabilities of organizational systems and the mission/business processes they support; organizations consider incident handling as part of the definition, design, and development of those processes and systems. Incident-related information can come from audit monitoring, network monitoring, physical access monitoring, user and administrator reports, and reported supply chain events. Effective incident-handling capability includes coordination among many organizational entities, including mission/business owners, system owners, authorizing officials, human resources, physical and personnel security offices, legal departments, operations personnel, procurement offices, and the risk executive.

As part of user response activities, incident response training is linked to assigned roles and responsibilities: regular users may only need to know who to call or how to recognize an incident, system administrators may need additional training on handling or remediating incidents, and incident responders may receive more specific training on forensics, reporting, and system recovery and restoration. Training includes identifying and reporting suspicious activities from external and internal sources; user response activities also include help desk support, assistance groups, and access to forensics or consumer redress services when required. NIST Special Publication 800-61 provides guidance on incident handling; NIST Special Publications 800-86 and 800-101 provide guidance on integrating forensic techniques into incident response; NIST Special Publication 800-161 provides guidance on supply chain risk management.

3.6.2

Track, document, and report incidents to designated officials and/or authorities both internal and external to the organization.

Discussion: Tracking and documenting incidents includes maintaining records about each incident, its status, and other pertinent information necessary for forensics and for evaluating incident details, trends, and handling. Incident information can be obtained from incident reports, incident response teams, audit monitoring, network monitoring, physical access monitoring, and user/administrator reports.

Reporting incidents addresses specific internal reporting requirements as well as formal reporting requirements applicable to the organization. Suspected security incidents may also be reported, including the receipt of suspicious email communications that could contain malicious code. The types of incidents reported, the content and timeliness of reports, and the designated reporting authorities reflect applicable laws, executive orders, directives, regulations, and policies. NIST Special Publication 800-61 provides guidance on incident handling.

Derived Security Requirements

3.6.3

Test the organizational incident response capability.

Discussion: Organizations test incident response capabilities to determine their effectiveness and identify potential weaknesses or deficiencies. Testing includes checklists, walk-through or tabletop exercises, simulations (parallel and full interrupt), and comprehensive exercises, and can include determining the effects of incident response on organizational operations, assets, and individuals. NIST Special Publication 800-84 provides guidance on testing programs for information technology capabilities.

3.7 Maintenance

Basic Security Requirements

3.7.1

Perform maintenance on organizational systems.

Discussion: This requirement addresses the information security aspects of the system maintenance program and applies to all types of maintenance on any system component (including hardware, firmware, applications) conducted by any local or nonlocal entity. System maintenance also includes components not directly associated with information processing or data retention, such as scanners, copiers, and printers.

3.7.2

Provide controls on the tools, techniques, mechanisms, and personnel used to conduct system maintenance.

Discussion: This requirement addresses security issues with maintenance tools that are outside the organizational system boundaries that process, store, or transmit CUI, but are used specifically for diagnostic and repair actions on those systems. Organizations have flexibility in determining controls for maintenance tools, which can include approving, controlling, and monitoring their use. Maintenance tools are potential vehicles for transporting malicious code into a facility and into organizational systems, and can include hardware, software, and firmware items such as diagnostic test equipment and packet sniffers.

Derived Security Requirements

3.7.3

Ensure equipment removed for off-site maintenance is sanitized of any CUI.

Discussion: This requirement addresses the information security aspects of system maintenance performed off-site and applies to all types of maintenance conducted by a local or nonlocal entity (e.g., in-contract, warranty, in-house, software maintenance agreement). NIST Special Publication 800-88 provides guidance on media sanitization.

3.7.4

Check media containing diagnostic and test programs for malicious code before the media are used in organizational systems.

Discussion: If, upon inspection, organizations determine that media containing maintenance diagnostic and test programs contain malicious code, the incident is handled consistent with incident handling policies and procedures.

3.7.5

Require multifactor authentication to establish nonlocal maintenance sessions via external network connections and terminate such connections when nonlocal maintenance is complete.

Discussion: Nonlocal maintenance and diagnostic activities are conducted by individuals communicating through an external network. The authentication techniques employed for these sessions reflect the network access requirements in 3.5.3.

3.7.6

Supervise the maintenance activities of maintenance personnel without required access authorization.

Discussion: This requirement applies to individuals performing hardware or software maintenance on organizational systems, while 3.10.1 addresses physical access for individuals whose maintenance duties place them within the physical protection perimeter of the systems (e.g., custodial staff, physical plant maintenance personnel). Individuals not previously identified as authorized maintenance personnel — such as IT manufacturers, vendors, consultants, and systems integrators — may require privileged access, for example when conducting maintenance with little or no notice. Organizations may choose to issue temporary credentials to such individuals based on risk assessments; these may be for one-time use or very limited time periods.

3.8 Media Protection

Basic Security Requirements

3.8.1

Protect (i.e., physically control and securely store) system media containing CUI, both paper and digital.

Discussion: System media includes digital media (e.g., diskettes, magnetic tapes, external and removable hard disk drives, flash drives, compact disks, digital video disks) and non-digital media (e.g., paper, microfilm). Physically controlling system media includes conducting inventories, maintaining accountability for stored media, and ensuring procedures allow individuals to check out and return media to the media library. Secure storage includes a locked drawer, desk, or cabinet, or a controlled media library. NIST Special Publication 800-111 provides guidance on storage encryption technologies for end-user devices.

3.8.2

Limit access to CUI on system media to authorized users.

Discussion: Access can be limited by physically controlling system media and secure storage areas, including conducting inventories, ensuring procedures allow individuals to check out and return media to the media library, and maintaining accountability for all stored media.

3.8.3

Sanitize or destroy system media containing CUI before disposal or release for reuse.

Discussion: This requirement applies to all system media, digital and non-digital, subject to disposal or reuse. Examples include digital media found in workstations, network components, scanners, copiers, printers, notebook computers, and mobile devices, and non-digital media such as paper and microfilm. Sanitization removes information such that it cannot be retrieved or reconstructed; techniques include clearing, purging, cryptographic erase, and destruction. Organizations determine appropriate sanitization methods, recognizing destruction may be necessary when other methods cannot be applied, and use discretion for media containing information that is public, publicly releasable, or deemed to have no adverse impact if released. Sanitization of non-digital media includes destruction, removing CUI from documents, or redacting sections or words in a manner equivalent to removal. NARA policy and guidance control sanitization processes for CUI. NIST Special Publication 800-88 provides guidance on media sanitization.

Derived Security Requirements

3.8.4

Mark media with necessary CUI markings and distribution limitations.

Discussion: The term security marking refers to the application or use of human-readable security attributes. Marking of system media (digital and non-digital) reflects applicable federal laws, executive orders, directives, policies, and regulations.

3.8.5

Control access to media containing CUI and maintain accountability for media during transport outside of controlled areas.

Discussion: Controlled areas are areas or spaces for which organizations provide physical or procedural controls to meet requirements for protecting systems and information. Controls to maintain accountability for media during transport include locked containers and cryptography, which can provide confidentiality and integrity protections depending on the mechanisms used. Activities associated with transport include the transport itself as well as releasing media for transport and ensuring media enters the appropriate transport processes; authorized transport and courier personnel may include individuals external to the organization. Maintaining accountability includes restricting transport activities to authorized personnel and tracking and obtaining explicit records of transport activities to prevent and detect loss, destruction, or tampering.

3.8.6

Implement cryptographic mechanisms to protect the confidentiality of CUI stored on digital media during transport unless otherwise protected by alternative physical safeguards.

Discussion: This requirement applies to portable storage devices (e.g., USB memory sticks, digital video disks, compact disks, external or removable hard disk drives). NIST Special Publication 800-111 provides guidance on storage encryption technologies for end-user devices.

3.8.7

Control the use of removable media on system components.

Discussion: In contrast to requirement 3.8.1, which restricts user access to media, this requirement restricts the use of certain types of media on systems, for example restricting or prohibiting flash drives or external hard disk drives. Organizations can employ technical and nontechnical controls (e.g., policies, procedures, rules of behavior), such as physical cages on workstations to prohibit access to certain external ports, or disabling the ability to insert, read, or write to such devices. Organizations may also limit use to approved devices only, or prohibit writeable portable devices by disabling or removing write capability.

3.8.8

Prohibit the use of portable storage devices when such devices have no identifiable owner.

Discussion: Requiring identifiable owners (individuals, organizations, or projects) for portable storage devices reduces overall risk by allowing organizations to assign responsibility and accountability for addressing known vulnerabilities in the devices (e.g., insertion of malicious code).

3.8.9

Protect the confidentiality of backup CUI at storage locations.

Discussion: Organizations can employ cryptographic mechanisms or alternative physical controls to protect the confidentiality of backup information at designated storage locations. Backed-up information containing CUI may include system-level information (system-state information, operating system software, application software, licenses) and user-level information (information other than system-level information).

3.9 Personnel Security

Basic Security Requirements

3.9.1

Screen individuals prior to authorizing access to organizational systems containing CUI.

Discussion: Personnel security screening (vetting) activities involve evaluating an individual's conduct, integrity, judgment, loyalty, reliability, and stability (i.e., trustworthiness) prior to authorizing access to organizational systems containing CUI. Screening activities reflect applicable federal laws, executive orders, directives, policies, regulations, and criteria established for the level of access required for assigned positions.

3.9.2

Ensure that organizational systems containing CUI are protected during and after personnel actions such as terminations and transfers.

Discussion: Protecting CUI during and after personnel actions may include returning system-related property (e.g., hardware authentication tokens, identification cards, technical manuals, keys, building passes) and conducting exit interviews, which can address nondisclosure agreements and potential limitations on future employment. Exit interviews may not be possible for some terminated individuals (e.g., job abandonment, illness, non-availability of supervisors); for cause terminations, timely execution is essential, and organizations may consider disabling accounts prior to notifying the individual.

This requirement applies to reassignments or transfers when the personnel action is permanent or of such extended duration as to require protection. Organizations define appropriate protections, which may include returning old and issuing new keys, identification cards, and building passes; changing system access authorizations; closing old accounts and establishing new ones; and providing access to official records the individual had access to at previous work locations and accounts.

(This family has no Derived Security Requirements.)

3.10 Physical Protection

Basic Security Requirements

3.10.1

Limit physical access to organizational systems, equipment, and the respective operating environments to authorized individuals.

Discussion: This requirement applies to employees, individuals with permanent physical access authorization credentials, and visitors. Authorized individuals have credentials that include badges, identification cards, and smart cards; organizations determine the necessary strength of credentials consistent with applicable laws, policies, and standards. The requirement applies only to areas within facilities not designated as publicly accessible. Limiting physical access to equipment may include placing equipment in locked rooms or secured areas accessible only to authorized individuals, and in locations that can be monitored by organizational personnel. Examples of equipment include computing devices, external disk drives, networking devices, monitors, printers, copiers, scanners, facsimile machines, and audio devices.

3.10.2

Protect and monitor the physical facility and support infrastructure for organizational systems.

Discussion: Monitoring of physical access includes publicly accessible areas within organizational facilities, accomplished for example through guards, sensor devices, or video surveillance. Examples of support infrastructure include system distribution, transmission, and power lines; security controls applied to support infrastructure prevent accidental damage, disruption, and physical tampering, and may also prevent eavesdropping or modification of unencrypted transmissions. Physical access controls for support infrastructure include locked wiring closets, disconnected or locked spare jacks, protection of cabling by conduit or cable trays, and wiretapping sensors.

Derived Security Requirements

3.10.3

Escort visitors and monitor visitor activity.

Discussion: Individuals with permanent physical access authorization credentials are not considered visitors. Audit logs can be used to monitor visitor activity.

3.10.4

Maintain audit logs of physical access.

Discussion: Organizations have flexibility in the types of audit logs employed, which can be procedural (e.g., a written log), automated (e.g., capturing ID from a PIV card), or a combination. Physical access points can include facility access points, interior access points to systems or components requiring supplemental access controls, or both.

3.10.5

Control and manage physical access devices.

Discussion: Physical access devices include keys, locks, combinations, and card readers.

3.10.6

Enforce safeguarding measures for CUI at alternate work sites.

Discussion: Alternate work sites may include government facilities or the private residences of employees. Organizations may define different security requirements for specific alternate work sites or types of sites depending on the work-related activities conducted there. NIST Special Publications 800-46 and 800-114 provide guidance on enterprise and user security when teleworking.

3.11 Risk Assessment

Basic Security Requirements

3.11.1

Periodically assess the risk to organizational operations (including mission, functions, image, or reputation), organizational assets, and individuals, resulting from the operation of organizational systems and the associated processing, storage, or transmission of CUI.

Discussion: Clearly defined system boundaries are a prerequisite for effective risk assessments, which consider threats, vulnerabilities, likelihood, and impact based on the operation and use of organizational systems, as well as risk from external parties (e.g., service providers, contractors, individuals accessing organizational systems, outsourcing entities). Risk assessments, formal or informal, can be conducted at the organization, mission/business process, or system level, and at any phase of the system development life cycle. NIST Special Publication 800-30 provides guidance on conducting risk assessments.

Derived Security Requirements

3.11.2

Scan for vulnerabilities in organizational systems and applications periodically and when new vulnerabilities affecting those systems and applications are identified.

Discussion: Organizations determine required vulnerability scanning for all system components, ensuring potential sources such as networked printers, scanners, and copiers are not overlooked, and update the vulnerabilities scanned for as new ones are discovered. Vulnerability analyses for custom software applications may require static analysis, dynamic analysis, binary analysis, or a hybrid approach. Scanning includes patch levels, functions/ports/protocols/services that should not be accessible, and improperly configured information flow control mechanisms. Organizations consider using SCAP-validated products, tools that use the CVE naming convention and OVAL, and sources such as the Common Weakness Enumeration (CWE) and the National Vulnerability Database (NVD).

Security assessments such as red team exercises provide additional sources of potential vulnerabilities to scan for; organizations also consider tools that express impact using the Common Vulnerability Scoring System (CVSS). Privileged access authorization to selected components facilitates thorough scanning and protects the sensitive nature of such scanning. NIST Special Publication 800-40 provides guidance on vulnerability management.

3.11.3

Remediate vulnerabilities in accordance with risk assessments.

Discussion: Vulnerabilities discovered, for example via the scanning conducted per 3.11.2, are remediated with consideration given to the related assessment of risk, which influences the prioritization of remediation efforts and the level of effort expended for specific vulnerabilities.

3.12 Security Assessment

Basic Security Requirements

3.12.1

Periodically assess the security controls in organizational systems to determine if the controls are effective in their application.

Discussion: Organizations assess security controls in organizational systems and their operating environments as part of the system development life cycle. Security controls are the safeguards or countermeasures implemented to satisfy security requirements; assessing them determines whether they are in place and operating as intended. Assessments ensure information security is built into organizational systems, identify weaknesses and deficiencies early, provide information for risk-based decisions, and ensure compliance with vulnerability mitigation procedures. Assessment reports document results in sufficient detail to determine accuracy, completeness, and whether controls are implemented correctly and producing the desired outcome, and results are provided to appropriate individuals or roles.

Organizations ensure assessment results are current, relevant, and obtained with appropriate assessor independence, and can use other activities such as vulnerability scanning and system monitoring to maintain security posture throughout the system life cycle. NIST Special Publication 800-53 provides guidance on security and privacy controls; NIST Special Publication 800-53A provides guidance on developing assessment plans and conducting assessments.

3.12.2

Develop and implement plans of action designed to correct deficiencies and reduce or eliminate vulnerabilities in organizational systems.

Discussion: The plan of action is a key document in the information security program, describing how unimplemented security requirements will be met and how planned mitigations will be implemented. Organizations can document the system security plan and plan of action as separate or combined documents in any chosen format. Federal agencies may consider submitted system security plans and plans of action as critical inputs to risk management decisions about hosting CUI on a nonfederal system.

3.12.3

Monitor security controls on an ongoing basis to ensure the continued effectiveness of the controls.

Discussion: Continuous monitoring programs facilitate ongoing awareness of threats, vulnerabilities, and information security to support risk management decisions. "Continuous" and "ongoing" imply that organizations assess and analyze security controls and risks at a frequency sufficient to support risk-based decisions; results generate appropriate risk response actions. Providing access to security information through reports or dashboards gives officials the capability to make effective, timely decisions; automation supports more frequent inventory updates. Effectiveness is enhanced when monitoring outputs are specific, measurable, actionable, relevant, and timely. NIST Special Publication 800-137 provides guidance on continuous monitoring.

3.12.4

Develop, document, and periodically update system security plans that describe system boundaries, system environments of operation, how security requirements are implemented, and the relationships with or connections to other systems.

Discussion: System security plans relate security requirements to a set of security controls and describe, at a high level, how the controls meet those requirements, without providing detailed technical descriptions of design or implementation. Plans contain sufficient information to enable a design and implementation unambiguously compliant with the plan's intent, and need not be single documents — they can be a collection of various documents, including ones that already exist, making extensive use of references to policies, procedures, and additional documents. This reduces documentation requirements and keeps security-related information within established management/operational areas related to enterprise architecture, system development life cycle, systems engineering, and acquisition.

Federal agencies may consider submitted system security plans and plans of action as critical inputs to risk management decisions about hosting CUI on a nonfederal system. NIST Special Publication 800-18 provides guidance on developing security plans.

(This family has no additional Derived Security Requirements.)

3.13 System and Communications Protection

Basic Security Requirements

3.13.1

Monitor, control, and protect communications (i.e., information transmitted or received by organizational systems) at the external boundaries and key internal boundaries of organizational systems.

Discussion: Communications can be monitored, controlled, and protected at boundary components and by restricting or prohibiting interfaces in organizational systems. Boundary components include gateways, routers, firewalls, guards, network-based malicious code analysis and virtualization systems, or encrypted tunnels implemented within a system security architecture. Restricting or prohibiting interfaces includes restricting external web communications traffic to designated web servers within managed interfaces and prohibiting external traffic that appears to be spoofing internal addresses.

Organizations consider the shared nature of commercial telecommunications services when implementing security requirements, since such services are commonly based on network components and consolidated management systems shared by all attached commercial customers, which may represent sources of increased risk despite contract security provisions. NIST Special Publication 800-41 provides guidance on firewalls and firewall policy; NIST Special Publication 800-125B provides guidance on security for virtualization technologies.

3.13.2

Employ architectural designs, software development techniques, and systems engineering principles that promote effective information security within organizational systems.

Discussion: Organizations apply systems security engineering principles to new development systems or systems undergoing major upgrades, and, to the extent feasible, to legacy system upgrades and modifications. Applying these concepts and principles helps develop trustworthy, secure, and resilient systems and reduces susceptibility to disruptions, hazards, and threats. Examples include developing layered protections; establishing security policies, architecture, and controls as the foundation for design; incorporating security requirements into the system development life cycle; delineating physical and logical security boundaries; training developers to build secure software; and performing threat modeling to identify use cases, threat agents, attack vectors and patterns, design patterns, and compensating controls needed to mitigate risk. NIST Special Publication 800-160, Volume 1 provides guidance on systems security engineering.

Derived Security Requirements

3.13.3

Separate user functionality from system management functionality.

Discussion: System management functionality includes functions necessary to administer databases, network components, workstations, or servers, and typically requires privileged user access. Separation of user functionality from system management functionality is physical or logical, and can be implemented using different computers, different central processing units, different operating system instances, different network addresses, virtualization techniques, or combinations thereof. This includes web administrative interfaces using separate authentication methods from other system resources, and may include isolating administrative interfaces on different domains with additional access controls.

3.13.4

Prevent unauthorized and unintended information transfer via shared system resources.

Discussion: Control of information in shared system resources (e.g., registers, cache memory, main memory, hard disks) is also commonly referred to as object reuse and residual information protection. This requirement prevents information produced by prior users or roles from being available to current users or roles that obtain access to shared system resources after those resources have been released back to the system, and also applies to encrypted representations of information. It does not address information remanence, covert channels, or components with only single users or roles.

3.13.5

Implement subnetworks for publicly accessible system components that are physically or logically separated from internal networks.

Discussion: Subnetworks physically or logically separated from internal networks are referred to as demilitarized zones (DMZs), typically implemented with boundary control devices and techniques including routers, gateways, firewalls, virtualization, or cloud-based technologies. NIST Special Publications 800-41 and 800-125B provide related guidance.

3.13.6

Deny network communications traffic by default and allow network communications traffic by exception (i.e., deny all, permit by exception).

Discussion: This requirement applies to inbound and outbound network communications traffic at the system boundary and at identified points within the system. A deny-all, permit-by-exception policy ensures that only essential and approved connections are allowed.

3.13.7

Prevent remote devices from simultaneously establishing non-remote connections with organizational systems and communicating via some other connection to resources in external networks (i.e., split tunneling).

Discussion: Split tunneling might be desirable for remote users to communicate with local system resources such as printers or file servers, but it allows unauthorized external connections, making the system more vulnerable to attack and exfiltration. This requirement is implemented in remote devices through configuration settings that disable split tunneling and prevent users from readily reconfiguring them, and in the system by detecting split tunneling on the remote device and prohibiting the connection if detected.

3.13.8

Implement cryptographic mechanisms to prevent unauthorized disclosure of CUI during transmission unless otherwise protected by alternative physical safeguards.

Discussion: This requirement applies to internal and external networks and any system components that can transmit information, including servers, notebook and desktop computers, mobile devices, printers, copiers, scanners, and facsimile machines. Communication paths outside the physical protection of controlled boundaries are susceptible to interception and modification. Organizations relying on commercial providers offering transmission as a commodity service rather than a dedicated service may find it difficult to obtain the necessary assurances, and in such cases implement compensating safeguards or explicitly accept the additional risk. An example of an alternative physical safeguard is a protected distribution system (PDS), where the distribution medium is protected against electronic or physical intercept.

3.13.9

Terminate network connections associated with communications sessions at the end of the sessions or after a defined period of inactivity.

Discussion: This requirement applies to internal and external networks. Terminating network connections includes de-allocating associated TCP/IP address or port pairs at the operating system level, or de-allocating networking assignments at the application level if multiple application sessions share a single operating-system-level network connection. Organizations may establish time periods of inactivity by type of network access or for specific network accesses.

3.13.10

Establish and manage cryptographic keys for cryptography employed in organizational systems.

Discussion: Cryptographic key management and establishment can be performed using manual procedures or mechanisms supported by manual procedures. Organizations define key management requirements in accordance with applicable federal laws, executive orders, policies, directives, regulations, and standards. NIST Special Publications 800-56A and 800-57 Part 1 provide guidance on cryptographic key management and establishment.

3.13.11

Employ FIPS-validated cryptography when used to protect the confidentiality of CUI.

Discussion: Cryptography can support many security solutions, including protecting CUI, providing digital signatures, enforcing information separation, and supporting random number and hash generation. Cryptographic standards include FIPS-validated cryptography and/or NSA-approved cryptography.

3.13.12

Prohibit remote activation of collaborative computing devices and provide indication of devices in use to users present at the device.

Discussion: Collaborative computing devices include networked white boards, cameras, and microphones. Indication of use includes signals to users when such devices are activated.

3.13.13

Control and monitor the use of mobile code.

Discussion: Mobile code technologies include Java, JavaScript, ActiveX, Postscript, PDF, Flash animations, and VBScript. Decisions on the use of mobile code are based on its potential to cause damage if used maliciously; usage restrictions apply both to mobile code installed on servers and to code downloaded and executed on individual workstations, notebook computers, and devices. Mobile code policy and procedures address controlling or preventing the development, acquisition, or introduction of unacceptable mobile code, including requiring mobile code to be digitally signed by a trusted source. NIST Special Publication 800-28 provides guidance on mobile code.

3.13.14

Control and monitor the use of Voice over Internet Protocol (VoIP) technologies.

Discussion: VoIP has different requirements, features, functionality, availability, and service limitations compared with plain old telephone service (POTS). To address VoIP-related threats — which are similar to those inherent in any Internet-based application — usage restrictions and implementation guidelines are based on the technology's potential to cause damage if used maliciously. NIST Special Publication 800-58 provides guidance on VoIP systems.

3.13.15

Protect the authenticity of communications sessions.

Discussion: Authenticity protection includes protecting against man-in-the-middle attacks, session hijacking, and the insertion of false information into communications sessions. This requirement addresses communications protection at the session level (as opposed to the packet level) and establishes confidence at both ends of a session in the ongoing identity of the other party and the validity of information transmitted. NIST Special Publications 800-77, 800-95, and 800-113 provide guidance on secure communications sessions.

3.13.16

Protect the confidentiality of CUI at rest.

Discussion: Information at rest refers to the state of information when it is not in process or in transit and is located on storage devices as specific components of systems. Protection focuses on the state of the information rather than the type of storage device or frequency of access. Organizations can use mechanisms such as cryptography and file share scanning to achieve confidentiality protection, and may also use secure off-line storage or continuous monitoring to identify malicious code at rest.

3.14 System and Information Integrity

Basic Security Requirements

3.14.1

Identify, report, and correct system flaws in a timely manner.

Discussion: Organizations identify systems affected by announced software and firmware flaws, including potential vulnerabilities resulting from those flaws, and report this information to designated personnel with information security responsibilities. Security-relevant updates include patches, service packs, hot fixes, and anti-virus signatures. Organizations address flaws discovered during security assessments, continuous monitoring, incident response activities, and system error handling, and can take advantage of resources such as the Common Weakness Enumeration (CWE) and Common Vulnerabilities and Exposures (CVE) databases. Organization-defined time periods for updating security-relevant software and firmware may vary based on factors such as the criticality of the update, and some remediation may require more testing than others. NIST Special Publication 800-40 provides guidance on patch management technologies.

3.14.2

Provide protection from malicious code at designated locations within organizational systems.

Discussion: Designated locations include system entry and exit points, which may include firewalls, remote-access servers, workstations, electronic mail servers, web servers, proxy servers, notebook computers, and mobile devices. Malicious code includes viruses, worms, Trojan horses, and spyware, and can be encoded in various formats, contained within compressed or hidden files, or hidden using techniques such as steganography; it can be inserted via web accesses, email and attachments, and portable storage devices, typically through the exploitation of system vulnerabilities.

Malicious code protection mechanisms include anti-virus signature definitions and reputation-based technologies. Pervasive configuration management and comprehensive software integrity controls may be effective in preventing execution of unauthorized code. Malicious code may also be present in custom-built software (e.g., logic bombs, back doors), which traditional protection mechanisms cannot always detect; in these situations organizations rely on secure coding practices, configuration management and control, trusted procurement processes, and monitoring practices. NIST Special Publication 800-83 provides guidance on malware incident prevention.

3.14.3

Monitor system security alerts and advisories and take action in response.

Discussion: There are many publicly available sources of system security alerts and advisories, for example the Department of Homeland Security's Cybersecurity and Infrastructure Security Agency (CISA), which generates alerts and advisories to maintain situational awareness across the federal government and nonfederal organizations. Software vendors, subscription services, and industry information sharing and analysis centers (ISACs) may also provide alerts and advisories. Response actions can include notifying relevant external organizations, such as mission/business partners, supply chain partners, external service providers, and peer or supporting organizations. NIST Special Publication 800-161 provides guidance on supply chain risk management.

Derived Security Requirements

3.14.4

Update malicious code protection mechanisms when new releases are available.

Discussion: Malicious code protection mechanisms include anti-virus signature definitions and reputation-based technologies. As with 3.14.2, pervasive configuration management and comprehensive software integrity controls help prevent execution of unauthorized code, including custom-built malicious code that traditional mechanisms cannot always detect, in which case organizations rely on secure coding practices, configuration management, trusted procurement, and monitoring.

3.14.5

Perform periodic scans of organizational systems and real-time scans of files from external sources as files are downloaded, opened, or executed.

Discussion: Periodic and real-time scans can detect malicious code, which can be encoded in various formats, contained within compressed or hidden files, or hidden using techniques such as steganography, and inserted through web accesses, email and attachments, or portable storage devices via the exploitation of system vulnerabilities.

3.14.6

Monitor organizational systems, including inbound and outbound communications traffic, to detect attacks and indicators of potential attacks.

Discussion: System monitoring includes external monitoring (observation of events at the system boundary, part of perimeter defense and boundary protection) and internal monitoring (observation of events within the system). Organizations can monitor systems by observing audit record activities in real time or by observing access patterns and other actions, using tools such as intrusion detection and prevention systems, malicious code protection software, scanning tools, audit record monitoring software, and network monitoring software. Strategic locations for monitoring devices include selected perimeter locations and near server farms supporting critical applications.

System monitoring is an integral part of continuous monitoring and incident response programs. Unusual or unauthorized activities or conditions related to inbound/outbound communications traffic include internal traffic indicating the presence of malicious code, unauthorized exporting of information, or signaling to external systems; evidence of malicious code is used to identify potentially compromised systems or components. NIST Special Publication 800-94 provides guidance on intrusion detection and prevention systems.

3.14.7

Identify unauthorized use of organizational systems.

Discussion: System monitoring, comprising external and internal monitoring, can detect unauthorized use of organizational systems and is an integral part of continuous monitoring and incident response programs, achieved through tools such as intrusion detection and prevention systems, malicious code protection software, scanning tools, audit record monitoring software, and network monitoring software. Unusual/unauthorized activities or conditions related to communications traffic include internal traffic indicating malicious code, unauthorized exporting of information, or signaling to external systems. NIST Special Publication 800-94 provides guidance on intrusion detection and prevention systems.

Appendix A: References

Laws, executive orders, regulations, instructions, standards, and guidelines. References in this section without specific publication dates or revision numbers are assumed to refer to the most recent updates to those publications.

Laws And Executive Orders

[ATOM54]

Atomic Energy Act (P.L. 83-703), August 1954.

[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/STATUTE-68/STATUTE-68-Pg919 https://www.govinfo.gov/app/details/PLAW-104publ231

[FISMA]

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

[40 USC 11331]

Title 40 U.S. Code, Sec. 11331, Responsibilities for Federal information systems standards. 2017 ed. https://www.govinfo.gov/app/details/USCODE-2017-title40/USCODE-2017-title40subtitleIII-chap113-subchapIII-sec11331

[44 USC 3502]

Title 44 U.S. Code, Sec. 3502, Definitions. 2017 ed.

[44 USC 3552]

Title 44 U.S. Code, Sec. 3552, Definitions. 2017 ed.

[44 USC 3554]

Title 44 U.S. Code, Sec. 3554, Federal agency responsibilities. 2017 ed.

[EO 13526]

Executive Order 13526 (2009) Classified National Security Information. (The White House, Washington, DC), DCPD-200901022, December 29, 2009. https://www.govinfo.gov/app/details/USCODE-2017-title44/USCODE-2017-title44chap35-subchapI-sec3502 https://www.govinfo.gov/app/details/USCODE-2017-title44/USCODE-2017-title44chap35-subchapII-sec3552 https://www.govinfo.gov/app/details/USCODE-2017-title44/USCODE-2017-title44chap35-subchapII-sec3554 https://www.govinfo.gov/app/details/DCPD-200901022

[EO 13556]

Executive Order 13556 (2010) Controlled Unclassified Information. (The White House, Washington, DC), DCPD-201000942, November 4, 2010. https://www.govinfo.gov/app/details/DCPD-201000942

Policies, Regulations, Directives, And Instructions

[32 CFR 2002]

32 CFR Part 2002, Controlled Unclassified Information, September 2016. https://www.govinfo.gov/app/details/CFR-2017-title32-vol6/CFR-2017-title32vol6-part2002/summary

[OMB A-130]

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

[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

Standards, Guidelines, And Reports

[ISO 27001]

International Organization for Standardization/International Electrotechnical Commission (2013) Information Technology—Security techniques— Information security management systems—Requirements. (International Organization for Standardization, Geneva, Switzerland), ISO/IEC 27001:2013. https://www.iso.org/standard/54534.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

[FIPS 200]

National Institute of Standards and Technology (2006) Minimum Security Requirements for Federal Information and Information Systems. (U.S. Department of Commerce, Washington, DC), Federal Information Processing Standards Publication (FIPS) 200. https://doi.org/10.6028/NIST.FIPS.200

[SP 800-18]

Swanson MA, Hash J, Bowen P (2006) Guide for Developing Security Plans for Federal Information Systems. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-18, Rev. 1. https://doi.org/10.6028/NIST.SP.800-18r1

[SP 800-28]

Jansen W, Winograd T, Scarfone KA (2008) Guidelines on Active Content and Mobile Code. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-28, Version 2. https://doi.org/10.6028/NIST.SP.800-28ver2

[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-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-40]

Souppaya MP, Scarfone KA (2013) Guide to Enterprise Patch Management Technologies. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-40, Rev. 3. https://doi.org/10.6028/NIST.SP.800-40r3

[SP 800-41]

Scarfone KA, Hoffman P (2009) Guidelines on Firewalls and Firewall Policy. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-41, Rev. 1. https://doi.org/10.6028/NIST.SP.800-41r1

[SP 800-46]

Souppaya MP, Scarfone KA (2016) Guide to Enterprise Telework, Remote Access, and Bring Your Own Device (BYOD) Security. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-46, Rev. 2. https://doi.org/10.6028/NIST.SP.800-46r2

[SP 800-50]

Wilson M, Hash J (2003) Building an Information Technology Security Awareness and Training Program. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-50. https://doi.org/10.6028/NIST.SP.800-50

[SP 800-53]

Joint Task Force Transformation Initiative (2013) Security and Privacy Controls for Federal Information Systems and Organizations. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-53, Rev. 4, Includes updates as of January 22, 2015. https://doi.org/10.6028/NIST.SP.800-53r4

[SP 800-53A]

Joint Task Force Transformation Initiative (2014) Assessing Security and Privacy Controls in Federal Information Systems and Organizations: Building Effective Assessment Plans. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-53A, Rev. 4, Includes updates as of December 18, 2014. https://doi.org/10.6028/NIST.SP.800-53Ar4

[SP 800-53B]

Control Baselines and Tailoring Guidance for Federal Information Systems and Organizations. (National Institute of Standards and Technology, Gaithersburg, MD), Draft NIST Special Publication (SP) 800-53B. [Forthcoming].

[SP 800-56A]

Barker EB, Chen L, Roginsky A, Vassilev A, Davis R (2018) Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm Cryptography. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-56A, Rev. 3. https://doi.org/10.6028/NIST.SP.800-56Ar3

[SP 800-57-1]

Barker EB (2016) Recommendation for Key Management, Part 1: General. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-57 Part 1, Rev. 4. https://doi.org/10.6028/NIST.SP.800-57pt1r4

[SP 800-58]

Kuhn R, Walsh TJ, Fries S (2005) Security Considerations for Voice Over IP Systems. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-58. https://doi.org/10.6028/NIST.SP.800-58

[SP 800-60-1]

Stine KM, Kissel RL, Barker WC, Fahlsing J, Gulick J (2008) Guide for Mapping Types of Information and Information Systems to Security Categories. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-60, Vol. 1, Rev. 1. https://doi.org/10.6028/NIST.SP.800-60v1r1

[SP 800-60-2]

Stine KM, Kissel RL, Barker WC, Lee A, Fahlsing J (2008) Guide for Mapping Types of Information and Information Systems to Security Categories: Appendices. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-60, Vol. 2, Rev. 1. https://doi.org/10.6028/NIST.SP.800-60v2r1

[SP 800-61]

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) 800-61, Rev. 2. https://doi.org/10.6028/NIST.SP.800-61r2

[SP 800-63-3]

Grassi PA, Garcia ME, Fenton JL (2017) Digital Identity Guidelines. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-63-3, Includes updates as of December 1, 2017. https://doi.org/10.6028/NIST.SP.800-63-3

[SP 800-70]

Quinn SD, Souppaya MP, Cook MR, Scarfone KA (2018) National Checklist Program for IT Products: Guidelines for Checklist Users and Developers. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-70, Rev. 4. https://doi.org/10.6028/NIST.SP.800-70r4

[SP 800-77]

Frankel SE, Kent K, Lewkowski R, Orebaugh AD, Ritchey RW, Sharma SR (2005) Guide to IPsec VPNs. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-77. https://doi.org/10.6028/NIST.SP.800-77

[SP 800-83]

Souppaya MP, Scarfone KA (2013) Guide to Malware Incident Prevention and Handling for Desktops and Laptops. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-83, Rev. 1. https://doi.org/10.6028/NIST.SP.800-83r1

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

[SP 800-86]

Kent K, Chevalier S, Grance T, Dang H (2006) Guide to Integrating Forensic Techniques into Incident Response. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-86. https://doi.org/10.6028/NIST.SP.800-86

[SP 800-88]

Kissel RL, Regenscheid AR, Scholl MA, Stine KM (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-92]

Kent K, Souppaya MP (2006) Guide to Computer Security Log Management. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-92. https://doi.org/10.6028/NIST.SP.800-92

[SP 800-94]

Scarfone KA, Mell PM (2007) Guide to Intrusion Detection and Prevention Systems (IDPS). (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-94. https://doi.org/10.6028/NIST.SP.800-94

[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-97]

Frankel SE, Eydt B, Owens L, Scarfone KA (2007) Establishing Wireless Robust Security Networks: A Guide to IEEE 802.11i. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-97. https://doi.org/10.6028/NIST.SP.800-97

[SP 800-101]

Ayers RP, Brothers S, Jansen W (2014) Guidelines on Mobile Device Forensics. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-101, Rev. 1. https://doi.org/10.6028/NIST.SP.800-101r1

[SP 800-111]

Scarfone KA, Souppaya MP, Sexton M (2007) Guide to Storage Encryption Technologies for End User Devices. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-111. https://doi.org/10.6028/NIST.SP.800-111

[SP 800-113]

Frankel SE, Hoffman P, Orebaugh AD, Park R (2008) Guide to SSL VPNs. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-113. https://doi.org/10.6028/NIST.SP.800-113

[SP 800-114]

Souppaya MP, Scarfone KA (2016) User's Guide to Telework and Bring Your Own Device (BYOD) Security. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-114, Rev. 1. https://doi.org/10.6028/NIST.SP.800-114r1

[SP 800-124]

Souppaya MP, Scarfone KA (2013) Guidelines for Managing the Security of Mobile Devices in the Enterprise. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-124, Rev. 1. https://doi.org/10.6028/NIST.SP.800-124r1

[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-128]

Johnson LA, Dempsey KL, Ross RS, Gupta S, Bailey D (2011) Guide for Security-Focused Configuration Management of Information Systems. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-128. https://doi.org/10.6028/NIST.SP.800-128

[SP 800-137]

Dempsey KL, Chawla NS, Johnson LA, Johnston R, Jones AC, Orebaugh AD, Scholl MA, Stine KM (2011) Information Security Continuous Monitoring (ISCM) for Federal Information Systems and Organizations. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-137. https://doi.org/10.6028/NIST.SP.800-137

[SP 800-160-1]

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

[SP 800-167]

Sedgewick A, Souppaya MP, Scarfone KA (2015) Guide to Application Whitelisting. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-167. https://doi.org/10.6028/NIST.SP.800-167

[SP 800-171A]

Ross RS, Dempsey KL, Pillitteri VY (2018) Assessing Security Requirements for Controlled Unclassified Information. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-171A. https://doi.org/10.6028/NIST.SP.800-171A

[SP 800-181]

Newhouse WD, Witte GA, Scribner B, Keith S (2017) National Initiative for Cybersecurity Education (NICE) Cybersecurity Workforce Framework. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-181. https://doi.org/10.6028/NIST.SP.800-181

Miscellaneous Publications And Websites

[IETF 5905]

Mills D, Martin J (ed.), Burbank J, Kasch W (2010) Network Time Protocol Version 4: Protocol and Algorithms Specification. (Internet Engineering Task Force), IETF Request for Comments (RFC) 5905. https://doi.org/10.17487/RFC5905

[NARA CUI]

National Archives and Records Administration (2019) Controlled Unclassified Information (CUI) Registry. https://www.archives.gov/cui

[NARA MARK]

National Archives and Records Administration (2016) Marking Controlled Unclassified Information, Version 1.1. (National Archives, Washington, DC). https://www.archives.gov/files/cui/20161206-cui-marking-handbook-v1-1.pdf CUI Notice 2019-01, Controlled Unclassified Information Coversheets and Labels. https://www.archives.gov/files/cui/documents/20190222-cui-notice-2019-01coversheet-label.pdf

[NIST CAVP]

National Institute of Standards and Technology (2019) Cryptographic Algorithm Validation Program. https://csrc.nist.gov/projects/cavp

[NIST CMVP]

National Institute of Standards and Technology (2019) Cryptographic Module Validation Program. https://csrc.nist.gov/projects/cmvp

[NIST CRYPTO]

National Institute of Standards and Technology (2019) Cryptographic Standards and Guidelines. https://csrc.nist.gov/projects/cryptographic-standards-and-guidelines

[NIST CSF]

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

[NIST CUI]

National Institute of Standards and Technology (2019) Special Publication 800-171 Publication and Supporting Resources. https://csrc.nist.gov/publications/detail/sp/800-171/rev-1/final

Appendix B: Glossary

Common terms and definitions used within this publication. Unless specifically defined in this glossary, all terms are consistent with the definitions in CNSSI 4009, the National Information Assurance Glossary.

advanced persistent threat

An adversary that possesses sophisticated levels of expertise and significant resources which 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.

agency

Any executive agency or department, military department, Federal Government corporation, Federal Government-controlled corporation, or other establishment in the Executive Branch of the Federal Government, or any independent regulatory agency.

assessment

See security control assessment.

assessor

See security control assessor.

audit log

A chronological record of system activities, including records of system accesses and operations performed in a given period.

audit record

An individual entry in an audit log related to an audited event.

authentication

Verifying the identity of a user, process, or device, often as a prerequisite to allowing access to resources in a system. [FIPS 200, Adapted]

availability

Ensuring timely and reliable access to and use of information.

baseline configuration

A documented set of specifications for a system, or a configuration item within a system, that has been formally reviewed and agreed on at a given point in time, and which can be changed only through change control procedures. [OMB A-130] [44 USC 3552] [SP 800-39]

bidirectional authentication

Two parties authenticating each other at the same time. Also known as mutual authentication or two-way authentication.

blacklisting

A process used to identify software programs that are not authorized to execute on a system or prohibited Universal Resource Locators (URL)/websites.

confidentiality

Preserving authorized restrictions on information access and disclosure, including means for protecting personal privacy and proprietary information.

configuration management

A collection of activities focused on establishing and maintaining the integrity of information technology products and systems, through control of processes for initializing, changing, and monitoring the configurations of those products and systems throughout the system development life cycle.

configuration settings

The set of parameters that can be changed in hardware, software, or firmware that affect the security posture and/or functionality of the system.

controlled area

Any area or space for which the organization has confidence that the physical and procedural protections provided are sufficient to meet the requirements established for protecting the information or system.

controlled unclassified information

Information that law, regulation, or governmentwide policy requires to have safeguarding or disseminating controls, excluding information that is classified under Executive Order 13526, Classified National Security Information, December 29, 2009, or any predecessor or successor order, or the Atomic Energy Act of 1954, as amended.

CUI categories

Those types of information for which laws, regulations, or governmentwide policies require or permit agencies to exercise safeguarding or dissemination controls, and which the CUI Executive Agent has approved and listed in the CUI Registry.

CUI Executive Agent

The National Archives and Records Administration (NARA), which implements the executive branch-wide CUI Program and oversees federal agency actions to comply with Executive Order 13556. NARA has delegated this authority to the Director of the Information Security Oversight Office (ISOO).

CUI program

The executive branch-wide program to standardize CUI handling by all federal agencies. The program includes the rules, organization, and procedures for CUI, established by Executive Order 13556, 32 CFR Part 2002, and the CUI Registry. [44 USC 3552] [EO 13556] [32 CFR 2002]

CUI registry

The online repository for all information, guidance, policy, and requirements on handling CUI, including everything issued by the CUI Executive Agent other than 32 CFR Part 2002. Among other information, the CUI Registry identifies all approved CUI categories, provides general descriptions for each, identifies the basis for controls, establishes markings, and includes guidance on handling procedures.

cyber-physical systems

Interacting digital, analog, physical, and human components engineered for function through integrated physics and logic.

dual authorization

The system of storage and handling designed to prohibit individual access to certain resources by requiring the presence and actions of at least two authorized persons, each capable of detecting incorrect or unauthorized security procedures with respect to the task being performed.

executive agency

An executive department specified in 5 U.S.C. Sec. 101; a military department specified in 5 U.S.C. Sec. 102; an independent establishment as defined in 5 U.S.C. Sec. 104(1); and a wholly owned Government corporation fully subject to the provisions of 31 U.S.C. Chapter 91.

external network

A network not controlled by the organization.

external system (or component)

A system or component of a system that is outside of the authorization boundary established by the organization and for which the organization typically has no direct control over the application of required security controls or the assessment of security control effectiveness.

external system service

A system service that is implemented outside of the authorization boundary of the organizational system (i.e., a service that is used by, but not a part of, the organizational system) and for which the organization typically has no direct control over the application of required security controls or the assessment of security control effectiveness.

external system service provider

A provider of external system services to an organization through a variety of consumer-producer relationships including, but not limited to: joint ventures; business partnerships; outsourcing arrangements (i.e., through contracts, interagency agreements, lines of business arrangements); licensing agreements; and/or supply chain exchanges.

federal agency

See executive agency.

federal information system

An information system used or operated by an executive agency, by a contractor of an executive agency, or by another organization on behalf of an executive agency. [32 CFR 2002] [CNSSI 4009, Adapted] [OMB A-130] [40 USC 11331]

FIPS-validated cryptography

A cryptographic module validated by the Cryptographic Module Validation Program (CMVP) to meet requirements specified in FIPS Publication 140-2 (as amended). As a prerequisite to CMVP validation, the cryptographic module is required to employ a cryptographic algorithm implementation that has successfully passed validation testing by the Cryptographic Algorithm Validation Program (CAVP). See NSA-approved cryptography.

firmware

Computer programs and data stored in hardware - typically in read-only memory (ROM) or programmable read-only memory (PROM) - such that the programs and data cannot be dynamically written or modified during execution of the programs. See hardware and software.

hardware

The material physical components of a system. See software and firmware.

identifier

Unique data used to represent a person’s identity and associated attributes. A name or a card number are examples of identifiers. A unique label used by a system to indicate a specific entity, object, or group.

impact

With respect to security, the effect on organizational operations, organizational assets, individuals, other organizations, or the Nation (including the national security interests of the United States) of a loss of confidentiality, integrity, or availability of information or a system. With respect to privacy, the adverse effects that individuals could experience when an information system processes their PII.

impact value

The assessed worst-case potential impact that could result from a compromise of the confidentiality, integrity, or availability of information expressed as a value of low, moderate or high.

incident

An occurrence that actually or imminently jeopardizes, without lawful authority, the confidentiality, integrity, 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.

information

Any communication or representation of knowledge such as facts, data, or opinions in any medium or form, including textual, numerical, graphic, cartographic, narrative, electronic, or audiovisual forms.

information flow control

Procedure to ensure that information transfers within a system are not made in violation of the security policy.

information resources

Information and related resources, such as personnel, equipment, funds, and information technology. [CNSSI 4009] [FIPS 199] [44 USC 3552] [OMB A-130] [44 USC 3502]

information security

The protection of information and systems from unauthorized access, use, disclosure, disruption, modification, or destruction in order to provide confidentiality, integrity, and availability.

information system

A discrete set of information resources organized for the collection, processing, maintenance, use, sharing, dissemination, or disposition of information.

information technology

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.

insider threat

The threat that an insider will use her/his authorized access, wittingly or unwittingly, to do harm to the security of the United States. This threat can include damage to the United States through espionage, terrorism, unauthorized disclosure, or through the loss or degradation of departmental resources or capabilities.

integrity

Guarding against improper information modification or destruction, and includes ensuring information non-repudiation and authenticity.

internal network

A network where establishment, maintenance, and provisioning of security controls are under the direct control of organizational employees or contractors; or the cryptographic encapsulation or similar security technology implemented between organizationcontrolled endpoints, provides the same effect (with regard to confidentiality and integrity). An internal network is typically organization-owned, yet may be organization-controlled while not being organization-owned. [44 USC 3552] [44 USC 3502] [OMB A-130]

least privilege

The principle that a security architecture is designed so that each entity is granted the minimum system authorizations and resources that the entity needs to perform its function.

local access

Access to an organizational system by a user (or process acting on behalf of a user) communicating through a direct connection without the use of a network.

malicious code

Software or firmware intended to perform an unauthorized process that will have adverse impact on the confidentiality, integrity, or availability of a system. A virus, worm, Trojan horse, or other code-based entity that infects a host. Spyware and some forms of adware are also examples of malicious code.

media

Physical devices or writing surfaces including, but not limited to, magnetic tapes, optical disks, magnetic disks, Large-Scale Integration (LSI) memory chips, and printouts (but not including display media) onto which information is recorded, stored, or printed within a system.

mobile code

Software programs or parts of programs obtained from remote systems, transmitted across a network, and executed on a local system without explicit installation or execution by the recipient.

mobile device

A portable computing device that has a small form factor such that it can easily be carried by a single individual; is designed to operate without a physical connection (e.g., wirelessly transmit or receive information); possesses local, nonremovable/removable data storage; and includes a selfcontained power source. Mobile devices may also include voice communication capabilities, on-board sensors that allow the devices to capture information, or built-in features that synchronize local data with remote locations. Examples include smartphones, tablets, and E-readers.

multifactor authentication

Authentication using two or more different factors to achieve authentication. Factors include something you know (e.g., PIN, password); something you have (e.g., cryptographic identification device, token); or something you are (e.g., biometric). See authenticator.

mutual authentication [CNSSI 4009]

The process of both entities involved in a transaction verifying each other. See bidirectional authentication.

network

A system implemented with a collection of interconnected components. Such components may include routers, hubs, cabling, telecommunications controllers, key distribution centers, and technical control devices. [FIPS 200]

network access

Access to a system by a user (or a process acting on behalf of a user) communicating through a network (e.g., local area network, wide area network, Internet).

nonfederal organization

An entity that owns, operates, or maintains a nonfederal system.

nonfederal system

A system that does not meet the criteria for a federal system.

nonlocal maintenance

Maintenance activities conducted by individuals communicating through a network, either an external network (e.g., the Internet) or an internal network.

on behalf of (an agency)

A situation that occurs when: (i) a non-executive branch entity uses or operates an information system or maintains or collects information for the purpose of processing, storing, or transmitting Federal information; and (ii) those activities are not incidental to providing a service or product to the government.

organization

An entity of any size, complexity, or positioning within an organizational structure.

personnel security

The discipline of assessing the conduct, integrity, judgment, loyalty, reliability, and stability of individuals for duties and responsibilities requiring trustworthiness.

portable storage device

A system component that can be inserted into and removed from a system, and that is used to store data or information (e.g., text, video, audio, and/or image data). Such components are typically implemented on magnetic, optical, or solid-state devices (e.g., floppy disks, compact/digital video disks, flash/thumb drives, external hard disk drives, and flash memory cards/drives that contain nonvolatile memory).

potential impact

The loss of confidentiality, integrity, or availability could be expected to have: (i) a limited adverse effect (FIPS Publication 199 low); (ii) a serious adverse effect (FIPS Publication 199 moderate); or (iii) a severe or catastrophic adverse effect (FIPS Publication 199 high) on organizational operations, organizational assets, or individuals.

privileged account

A system account with authorizations of a privileged user.

privileged user

A user that is authorized (and therefore, trusted) to perform security-relevant functions that ordinary users are not authorized to perform.

records

The recordings (automated and/or manual) of evidence of activities performed or results achieved (e.g., forms, reports, test results), which serve as a basis for verifying that the organization and the system are performing as intended. Also used to refer to units of related data fields (i.e., groups of data fields that can be accessed by a program and that contain the complete set of information on particular items).

remote access

Access to an organizational system by a user (or a process acting on behalf of a user) communicating through an external network (e.g., the Internet). [32 CFR 2002] [FIPS 200, Adapted] [SP 800-53] [FIPS 199]

remote maintenance

Maintenance activities conducted by individuals communicating through an external network (e.g., the Internet).

replay resistance

Protection against the capture of transmitted authentication or access control information and its subsequent retransmission with the intent of producing an unauthorized effect or gaining unauthorized access.

risk

A measure of the extent to which an entity is threatened by a potential circumstance or event, and typically is a function of: (i) the adverse impact, or magnitude of harm, that would arise if the circumstance or event occurs; and (ii) the likelihood of occurrence.

risk assessment

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 a system.

sanitization

Actions taken to render data written on media unrecoverable by both ordinary and, for some forms of sanitization, extraordinary means. Process to remove information from media such that data recovery is not possible. It includes removing all classified labels, markings, and activity logs.

security

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

security assessment

See security control assessment.

security control

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 control assessment

The testing or evaluation of security controls to determine the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security requirements for an information system or organization.

security domain

A domain that implements a security policy and is administered by a single authority.

security functions

The hardware, software, or firmware of the system responsible for enforcing the system security policy and supporting the isolation of code and data on which the protection is based. [OMB A-130] [SP 800-30] [CNSSI 4009] [CNSSI 4009, Adapted]

split tunneling

The process of allowing a remote user or device to establish a non-remote connection with a system and simultaneously communicate via some other connection to a resource in an external network. This method of network access enables a user to access remote devices (e.g., a networked printer) at the same time as accessing uncontrolled networks.

system

See information system.

system component

A discrete identifiable information technology asset that represents a building block of a system and may include hardware, software, and firmware.

system security plan

A document that describes how an organization meets the security requirements for a system or how an organization plans to meet the requirements. In particular, the system security plan describes the system boundary; the environment in which the system operates; how the security requirements are implemented; and the relationships with or connections to other systems.

system service

A capability provided by a system that facilitates information processing, storage, or transmission.

system user

Individual, or (system) process acting on behalf of an individual, authorized to access a system.

threat

Any circumstance or event with the potential to adversely impact organizational operations, organizational assets, individuals, other organizations, or the Nation through a system via unauthorized access, destruction, disclosure, modification of information, and/or denial of service.

whitelisting

A process used to identify software programs that are authorized to execute on a system or authorized Universal Resource Locators (URL)/websites.

wireless technology

Technology that permits the transfer of information between separated points without physical connection. Wireless technologies include microwave, packet radio (ultra-high frequency or very high frequency), 802.11x, and Bluetooth. [SP 800-128] [SP 800-30]

Appendix C: Acronyms

Acronym	Meaning
CFR	Code of Federal Regulations
CNSS	Committee on National Security Systems
CUI	Controlled Unclassified Information
CISA	Cybersecurity and Infrastructure Security Agency
DMZ	Demilitarized Zone
FAR	Federal Acquisition Regulation
FIPS	Federal Information Processing Standards
FISMA	Federal Information Security Modernization Act
IoT	Internet of Things
IP	Internet Protocol
ISO/IEC	International Organization for Standardization/International Electrotechnical Commission
ISOO	Information Security Oversight Office
IT	Information Technology
ITL	Information Technology Laboratory
NARA	National Archives and Records Administration
NFO	Nonfederal Organization
NIST	National Institute of Standards and Technology
OMB	Office of Management and Budget
SP	Special Publication
VoIP	Voice over Internet Protocol

Appendix D: Mapping Tables

Appendix D provides informal mappings between the CUI security requirements in Chapter Three and the relevant security controls in NIST Special Publication 800-53, Revision 4 (the moderate security control baseline). The original publication also cross-references each requirement to the relevant control(s) in ISO/IEC 27001:2013, Annex A; because that cross-reference spans a complex, multi-column table, it is summarized narratively below rather than reproduced cell-by-cell. Organizations that have implemented or plan to implement the NIST Framework for Improving Critical Infrastructure Cybersecurity can use the mapping of security requirements to SP 800-53 and ISO/IEC 27001 controls to locate the equivalent controls in the Categories and Subcategories associated with the Cybersecurity Framework's core functions: Identify, Protect, Detect, Respond, and Recover.

Note: this summary lists the primary NIST SP 800-53, Revision 4 control(s) associated with each requirement. Consult the original publication for the full, detailed ISO/IEC 27001 sub-control cross-references, which are organized in a multi-column table not fully reproduced here.

3.1 Access Control

Table D-1: Mapping Access Control Requirements to Controls

Security Requirement	NIST SP 800-53 Relevant Security Control(s)
3.1.1	AC-2
3.1.2	AC-3
3.1.3	AC-4
3.1.4	AC-5
3.1.5	AC-6
3.1.6	AC-6(2)
3.1.7	AC-6(9), AC-6(10)
3.1.8	AC-7
3.1.9	AC-8
3.1.10	AC-11, AC-11(1)
3.1.11	AC-12
3.1.12	AC-17(1)
3.1.13	AC-17(2)
3.1.14	AC-17(3)
3.1.15	AC-17(4)
3.1.16	AC-18
3.1.17	AC-18(1)
3.1.18	AC-19
3.1.19	AC-19(5)
3.1.20	AC-20, AC-20(1)
3.1.21	AC-20(2)
3.1.22	AC-22

3.2 Awareness and Training

Table D-2: Mapping Awareness and Training Requirements to Controls

Security Requirement	NIST SP 800-53 Relevant Security Control(s)
3.2.1	AT-2
3.2.2	AT-3
3.2.3	AT-2(2)

3.3 Audit and Accountability

Table D-3: Mapping Audit and Accountability Requirements to Controls

Security Requirement	NIST SP 800-53 Relevant Security Control(s)
3.3.1	AU-2, AU-3, AU-12
3.3.2	AU-6, AU-12
3.3.3	AU-2
3.3.4	AU-5
3.3.5	AU-6
3.3.6	AU-7
3.3.7	AU-8
3.3.8	AU-9
3.3.9	AU-9(4)

3.4 Configuration Management

Table D-4: Mapping Configuration Management Requirements to Controls

Security Requirement	NIST SP 800-53 Relevant Security Control(s)
3.4.1	CM-2, CM-8
3.4.2	CM-6
3.4.3	CM-3
3.4.4	CM-4
3.4.5	CM-5
3.4.6	CM-7
3.4.7	CM-7(1)
3.4.8	CM-7(2), CM-7(5)
3.4.9	CM-11

3.5 Identification and Authentication

Table D-5: Mapping Identification and Authentication Requirements to Controls

Security Requirement	NIST SP 800-53 Relevant Security Control(s)
3.5.1	IA-2, IA-4, IA-5, IA-8
3.5.2	IA-2, IA-8
3.5.3	IA-2(1), IA-2(2), IA-2(3), IA-2(4)
3.5.4	IA-2(8), IA-2(9)
3.5.5	IA-4
3.5.6	IA-4
3.5.7	IA-5(1)
3.5.8	IA-5(1)
3.5.9	IA-5(1)
3.5.10	IA-5(1)
3.5.11	IA-6

3.6 Incident Response

Table D-6: Mapping Incident Response Requirements to Controls

Security Requirement	NIST SP 800-53 Relevant Security Control(s)
3.6.1	IR-2, IR-4, IR-5, IR-6, IR-7
3.6.2	IR-6
3.6.3	IR-3

3.7 Maintenance

Table D-7: Mapping Maintenance Requirements to Controls

Security Requirement	NIST SP 800-53 Relevant Security Control(s)
3.7.1	MA-2
3.7.2	MA-3
3.7.3	MA-2, MA-3(3)
3.7.4	MA-3(2)
3.7.5	MA-4
3.7.6	MA-5

3.8 Media Protection

Table D-8: Mapping Media Protection Requirements to Controls

Security Requirement	NIST SP 800-53 Relevant Security Control(s)
3.8.1	MP-2, MP-4
3.8.2	MP-2
3.8.3	MP-6
3.8.4	MP-3
3.8.5	MP-5
3.8.6	MP-5(4)
3.8.7	MP-7
3.8.8	MP-7(1)
3.8.9	CP-9

3.9 Personnel Security

Table D-9: Mapping Personnel Security Requirements to Controls

Security Requirement	NIST SP 800-53 Relevant Security Control(s)
3.9.1	PS-3
3.9.2	PS-4, PS-5

3.10 Physical Protection

Table D-10: Mapping Physical Protection Requirements to Controls

Security Requirement	NIST SP 800-53 Relevant Security Control(s)
3.10.1	PE-2, PE-3, PE-5, PE-6
3.10.2	PE-6, PE-20
3.10.3	PE-3
3.10.4	PE-6, PE-8
3.10.5	PE-3
3.10.6	PE-17

3.11 Risk Assessment

Table D-11: Mapping Risk Assessment Requirements to Controls

Security Requirement	NIST SP 800-53 Relevant Security Control(s)
3.11.1	RA-3
3.11.2	RA-5
3.11.3	RA-5

3.12 Security Assessment

Table D-12: Mapping Security Assessment Requirements to Controls

Security Requirement	NIST SP 800-53 Relevant Security Control(s)
3.12.1	CA-2
3.12.2	CA-5
3.12.3	CA-7
3.12.4	PL-2

3.13 System and Communications Protection

Table D-13: Mapping System and Communications Protection Requirements to Controls

Security Requirement	NIST SP 800-53 Relevant Security Control(s)
3.13.1	SC-7
3.13.2	SA-8
3.13.3	SC-2
3.13.4	SC-4
3.13.5	SC-7(3)
3.13.6	SC-7(5)
3.13.7	SC-7(7)
3.13.8	SC-8, SC-8(1)
3.13.9	SC-10
3.13.10	SC-12
3.13.11	SC-13
3.13.12	SC-15
3.13.13	SC-18
3.13.14	SC-19
3.13.15	SC-23
3.13.16	SC-28

3.14 System and Information Integrity

Table D-14: Mapping System and Information Integrity Requirements to Controls

Security Requirement	NIST SP 800-53 Relevant Security Control(s)
3.14.1	SI-2
3.14.2	SI-3
3.14.3	SI-5
3.14.4	SI-3
3.14.5	SI-3(2)
3.14.6	SI-4
3.14.7	SI-4(24)

Appendix E: Tailoring Criteria

This appendix lists the security controls in the SP 800-53 moderate baseline — one of the sources, along with FIPS 200, used to develop the CUI security requirements in Chapter Three — together with the tailoring action applied to each. Tables E-1 through E-17 contain the specific tailoring actions carried out on the controls in accordance with the tailoring criteria established by NIST and NARA, which facilitated development of the CUI derived security requirements that supplement the basic security requirements. There are three primary criteria for eliminating a security control or control enhancement from the moderate baseline:

• The control or control enhancement is uniquely federal (i.e., primarily the responsibility of the federal government);
• The control or control enhancement is not directly related to protecting the confidentiality of CUI; or
• The control or control enhancement is expected to be routinely satisfied by nonfederal organizations without specification.

Table E: Tailoring action symbols

Symbol	Tailoring criteria
NCO	Not directly related to protecting the confidentiality of CUI
FED	Uniquely federal, primarily the responsibility of the federal government
NFO	Expected to be routinely satisfied by nonfederal organizations without specification
CUI	The CUI basic or derived security requirement is reflected in, and is traceable to, the security control, control enhancement, or specific elements of the control/enhancement

Note: the security controls in these tables are taken from NIST Special Publication 800-53, Revision 4.

Table E-1: Tailoring Actions For Access Controls

NIST SP 800-53 Moderate Baseline Security Control	Tailoring Action
AC-1 — Access Control Policy and Procedures	NFO
AC-2 — Account Management	CUI
Automated system account management	NCO
Removal of temporary / emergency accounts	NCO
Disable inactive accounts	NCO
Automated audit actions	NCO
AC-3 — Access Enforcement	CUI
AC-4 — Information Flow Enforcement	CUI
AC-5 — Separation of Duties	CUI
AC-6 — Least Privilege	CUI
Authorize access to security functions	CUI
Non-privileged access for nonsecurity functions	CUI
Privileged accounts	CUI
Auditing use of privileged functions	CUI
Prohibit non-privileged users from executing privileged functions	CUI
AC-7 — Unsuccessful Logon Attempts	CUI
AC-8 — System Use Notification	CUI
AC-11 — Session Lock	CUI
Pattern-hiding displays	CUI
AC-12 — Session Termination	CUI
AC-14 — Permitted Actions without Identification or Authentication	FED
AC-17 — Remote Access	CUI
Automated monitoring / control	CUI
Protection of confidentiality / integrity using encryption	CUI
Managed access control points	CUI
Privileged commands / access	CUI
AC-18 — Wireless Access	CUI
Authentication and encryption	CUI
AC-19 — Access Control for Mobile Devices	CUI
Full device / container-based encryption	CUI
AC-20 — Use of External Systems	CUI
Limits on authorized use	CUI
Portable storage devices	CUI
AC-21 — Information Sharing	FED
AC-22 — Publicly Accessible Content	CUI

Table E-2: Tailoring Actions For Awareness And Training Controls

NIST SP 800-53 Moderate Baseline Security Control	Tailoring Action
AT-1 — Security Awareness and Training Policy and Procedures	NFO
AT-2 — Security Awareness Training	CUI
Insider threat	CUI
AT-3 — Role-Based Security Training	CUI
AT-4 — Security Training Records	NFO

Table E-3: Tailoring Actions For Audit And Accountability Controls

NIST SP 800-53 Moderate Baseline Security Control	Tailoring Action
AU-1 — Audit and Accountability Policy and Procedures	NFO
AU-2 — Audit Events	CUI
Reviews and updates	CUI
AU-3 — Content of Audit Records	CUI
Additional audit information	CUI
AU-4 — Audit Storage Capacity	NCO
AU-5 — Response to Audit Logging Process Failures	CUI
AU-6 — Audit Review, Analysis, and Reporting	CUI
Process integration	NCO
Correlate audit repositories	CUI
AU-7 — Audit Reduction and Report Generation	CUI
Automatic processing	NCO
AU-8 — Time Stamps	CUI
Synchronization with authoritative time source	CUI
AU-9 — Protection of Audit Information	CUI
Access by subset of privileged users	CUI
AU-11 — Audit Record Retention	NCO
AU-12 — Audit Generation	CUI

Table E-4: Tailoring Actions For Security Assessment And Authorization Controls

NIST SP 800-53 Moderate Baseline Security Control	Tailoring Action
CA-1 — Security Assessment and Authorization Policies and Procedures	NFO
CA-2 — Security Assessments	CUI
Independent assessors	NFO
CA-3 — System Interconnections	NFO
Restrictions on external system connections	NFO
CA-5 — Plan of Action and Milestones	CUI
CA-6 — Security Authorization	FED
CA-7 — Continuous Monitoring	CUI
Independent assessment	NFO
CA-9 — Internal System Connections	NFO

Table E-5: Tailoring Actions For Configuration Management Controls

NIST SP 800-53 Moderate Baseline Security Control	Tailoring Action
CM-1 — Configuration Management Policy and Procedures	NFO
CM-2 — Baseline Configuration	CUI
Reviews and updates	NFO
Retention of previous configurations	NCO
Configure systems, components, or devices for high-risk areas	NFO
CM-3 — Configuration Change Control	CUI
Test / validate / document changes	NFO
CM-4 — Security Impact Analysis	CUI
CM-5 — Access Restrictions for Change	CUI
CM-6 — Configuration Settings	CUI
CM-7 — Least Functionality	CUI
Periodic review	CUI
Prevent program execution	CUI
CM-8 — System Component Inventory	CUI
Updates during installations / removals	CUI
Automated unauthorized component detection	NCO
No duplicate accounting of components	NFO
CM-9 — Configuration Management Plan	NFO
CM-10 — Software Usage Restrictions	NCO
CM-11 — User-Installed Software	CUI

Table E-6: Tailoring Actions For Contingency Planning Controls

NIST SP 800-53 Moderate Baseline Security Control	Tailoring Action
CP-1 — Contingency Planning Policy and Procedures	NCO
CP-2 — Contingency Plan	NCO
Coordinate with related plans	NCO
Resume essential missions / business functions	NCO
Identify critical assets	NCO
CP-3 — Contingency Training	NCO
CP-4 — Contingency Plan Testing	NCO
Coordinate with related plans	NCO
CP-6 — Alternate Storage Site	NCO
Separation from primary site	NCO
Accessibility	NCO
CP-7 — Alternate Processing Site	NCO
Separation from primary site	NCO
Accessibility	NCO
Priority of service	NCO
CP-8 — Telecommunications Services	NCO
Priority of service provisions	NCO
Single points of failure	NCO
CP-9 — System Backup	CUI
Testing for reliability / integrity	NCO
CP-10 — System Recovery and Reconstitution	NCO
Transaction recovery	NCO

Table E-7: Tailoring Actions For Identification And Authentication Controls

NIST SP 800-53 Moderate Baseline Security Control	Tailoring Action
IA-1 — Identification and Authentication Policy and Procedures	NFO
IA-2 — Identification and Authentication (Organizational Users)	CUI
Network access to privileged	CUI
Network access to non-privileged	CUI
Local access to privileged	CUI
Network access to privileged	CUI
Network access to non-privileged	CUI
Remote access - separate device	FED
Acceptance of piv credentials	FED
IA-3 — Device Identification and Authentication	CUI
IA-4 — Identifier Management	CUI
IA-5 — Authenticator Management	CUI
Password-based authentication	CUI
Pki-based authentication	FED
In-person or trusted third-party registration	FED
Hardware token-based authentication	FED
IA-6 — Authenticator Feedback	CUI
IA-7 — Cryptographic Module Authentication	FED
IA-8 — Identification and Authentication (Non-Organizational Users)	FED
Acceptance of piv credentials	FED
Acceptance of third-party	FED
Use of ficam-approved	FED
Use of ficam-issued profiles	FED

Table E-8: Tailoring Actions For Incident Response Controls

NIST SP 800-53 Moderate Baseline Security Control	Tailoring Action
IR-1 — Incident Response Policy and Procedures	NFO
IR-2 — Incident Response Training	CUI
IR-3 — Incident Response Testing	CUI
Coordination with related plans	NCO
IR-4 — Incident Handling	CUI
Automated incident handling processes	NCO
IR-5 — Incident Monitoring	CUI
IR-6 — Incident Reporting	CUI
Automated reporting	NCO
IR-7 — Incident Response Assistance	CUI
Automation support for availability of information / support	NCO
IR-8 — Incident Response Plan	NFO

Table E-9: Tailoring Actions For Maintenance Controls

NIST SP 800-53 Moderate Baseline Security Control	Tailoring Action
MA-1 — System Maintenance Policy and Procedures	NFO
MA-2 — Controlled Maintenance	CUI
MA-3 — Maintenance Tools	CUI
Inspect tools	CUI
Inspect media	CUI
MA-4 — Nonlocal Maintenance	CUI
Document nonlocal maintenance	NFO
MA-5 — Maintenance Personnel	CUI
MA-6 — Timely Maintenance	NCO

Table E-10: Tailoring Actions For Media Protection Controls

NIST SP 800-53 Moderate Baseline Security Control	Tailoring Action
MP-1 — Media Protection Policy and Procedures	NFO
MP-2 — Media Access	CUI
MP-3 — Media Marking	CUI
MP-4 — Media Storage	CUI
MP-5 — Media Transport	CUI
Cryptographic protection	CUI
MP-6 — Media Sanitization	CUI
MP-7 — Media Use	CUI
Prohibit use without owner	CUI

Table E-11: Tailoring Actions For Physical And Environmental Protection Controls

NIST SP 800-53 Moderate Baseline Security Control	Tailoring Action
PE-1 — Physical and Environmental Protection Policy and Procedures	NFO
PE-2 — Physical Access Authorizations	CUI
PE-3 — Physical Access Control	CUI
PE-4 — Access Control for Transmission Medium	CUI
PE-5 — Access Control for Output Devices	CUI
PE-6 — Monitoring Physical Access	CUI
Intrusion alarms / surveillance equipment	NFO
PE-8 — Visitor Access Records	NFO
PE-9 — Power Equipment and Cabling	NCO
PE-10 — Emergency Shutoff	NCO
PE-11 — Emergency Power	NCO
PE-12 — Emergency Lighting	NCO
PE-13 — Fire Protection	NCO
Automatic fire suppression	NCO
PE-14 — Temperature and Humidity Controls	NCO
PE-15 — Water Damage Protection	NCO
PE-16 — Delivery and Removal	NFO
PE-17 — Alternate Work Site	CUI

Table E-12: Tailoring Actions For Planning Controls

NIST SP 800-53 Moderate Baseline Security Control	Tailoring Action
PL-1 — Security Planning Policy and Procedures	NFO
PL-2 — System Security Plan	CUI
Plan / coordinate with other organizational entities	NFO
PL-4 — Rules of Behavior	NFO
Social media and networking restrictions	NFO
PL-8 — Information Security Architecture	NFO

Table E-13: Tailoring Actions For Personnel Security Controls

NIST SP 800-53 Moderate Baseline Security Control	Tailoring Action
PS-1 — Personnel Security Policy and Procedures	NFO
PS-2 — Position Risk Designation	FED
PS-3 — Personnel Screening	CUI
PS-4 — Personnel Termination	CUI
PS-5 — Personnel Transfer	CUI
PS-6 — Access Agreements	NFO
PS-7 — Third-Party Personnel Security	NFO
PS-8 — Personnel Sanctions	NFO

Table E-14: Tailoring Actions For Risk Assessment Controls

NIST SP 800-53 Moderate Baseline Security Control	Tailoring Action
RA-1 — Risk Assessment Policy and Procedures	NFO
RA-2 — Security Categorization	FED
RA-3 — Risk Assessment	CUI
RA-5 — Vulnerability Scanning	CUI
Update tool capability	NFO
Update by frequency / prior to new scan / when identified	NFO
Privileged access	CUI

Table E-15: Tailoring Actions For System And Services Acquisition Controls

NIST SP 800-53 Moderate Baseline Security Control	Tailoring Action
SA-1 — System and Services Acquisition Policy and Procedures	NFO
SA-2 — Allocation of Resources	NFO
SA-3 — System Development Life Cycle	NFO
SA-4 — Acquisition Process	NFO
Functional properties of security controls	NFO
Design / implementation information for security controls	NFO
Functions / ports / protocols / services in use	NFO
Use of approved piv products	NFO
SA-5 — System Documentation	NFO
SA-8 — Security Engineering Principles	CUI
SA-9 — External System Services	NFO
Identification of functions / ports / protocols / services	NFO
SA-10 — Developer Configuration Management	NFO
SA-11 — Developer Security Testing and Evaluation	NFO

Table E-16: Tailoring Actions For System And Communications Protection Controls

NIST SP 800-53 Moderate Baseline Security Control	Tailoring Action
SC-1 — System and Communications Protection Policy and Procedures	NFO
SC-2 — Application Partitioning	CUI
SC-4 — Information in Shared Resources	CUI
SC-5 — Denial of Service Protection	NCO
SC-7 — Boundary Protection	CUI
Access points	NFO
External telecommunications services	NFO
Deny by default / allow by exception	CUI
Prevent split tunneling for remote devices	CUI
SC-8 — Transmission Confidentiality and Integrity	CUI
Cryptographic or alternate physical protection	CUI
SC-10 — Network Disconnect	CUI
SC-12 — Cryptographic Key Establishment and Management	CUI
SC-13 — Cryptographic Protection	CUI
SC-15 — Collaborative Computing Devices	CUI
SC-17 — Public Key Infrastructure Certificates	FED
SC-18 — Mobile Code	CUI
SC-19 — Voice over Internet Protocol	CUI
SC-20 — Secure Name /Address Resolution Service (Authoritative Source)	NFO
SC-21 — Secure Name /Address Resolution Service (Recursive or Caching Resolver)	NFO
SC-22 — Architecture and Provisioning for Name/Address Resolution Service	NFO
SC-23 — Session Authenticity	CUI
SC-28 — Protection of Information at Rest	CUI
SC-39 — Process Isolation	NFO

Table E-17: Tailoring Actions For System And Information Integrity Controls

NIST SP 800-53 Moderate Baseline Security Control	Tailoring Action
SI-1 — System and Information Integrity Policy and Procedures	NFO
SI-2 — Flaw Remediation	CUI
Automated flaw remediation status	NCO
SI-3 — Malicious Code Protection	CUI
Central management	NCO
Automatic updates	NCO
SI-4 — System Monitoring	CUI
Automated tools for real-time analysis	NCO
Inbound and outbound communications traffic	CUI
System-generated alerts	NFO
SI-5 — Security Alerts, Advisories, and Directives	CUI
SI-7 — Software, Firmware, and Information Integrity	NCO
Integrity checks	NCO
Integration of detection and response	NCO
SI-8 — Spam Protection	NCO
Central management	NCO
Automatic updates	NCO
SI-10 — Information Input Validation	NCO
SI-11 — Error Handling	NCO
SI-12 — Information Handling and Retention	FED
SI-16 — Memory Protection	NFO