System and Communications Protection (SC)¶

SC.L2-3.13.1 – Boundary Protection [CUI Data]¶

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.

Assessment Objectives¶

Source: NIST SP 800-171A, p. 53.

Determine if:

• [a] the external system boundary is defined;
• [b] key internal system boundaries are defined;
• [c] communications are monitored at the external system boundary;
• [d] communications are monitored at key internal boundaries;
• [e] communications are controlled at the external system boundary;
• [f] communications are controlled at key internal boundaries;
• [g] communications are protected at the external system boundary; and
• [h] communications are protected at key internal boundaries.

Potential Assessment Methods and Objects¶

Source: NIST SP 800-171A, p. 53.

Examine: [SELECT FROM: System and communications protection policy; procedures addressing boundary protection; system security plan; list of key internal boundaries of the system; system design documentation; boundary protection hardware and software; enterprise security architecture documentation; system audit logs and records; system configuration settings and associated documentation; other relevant documents or records].

Interview: [SELECT FROM: System or network administrators; personnel with information security responsibilities; system developers; personnel with boundary protection responsibilities].

Test: [SELECT FROM: Mechanisms implementing boundary protection capability].

Discussion¶

Source: NIST SP 800-171 Rev. 2, p. 36.

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 (e.g., routers protecting firewalls or application gateways residing on protected subnetworks). Restricting or prohibiting interfaces in organizational systems 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 in the implementation of security requirements associated with the use of such services. Commercial telecommunications services are commonly based on network components and consolidated management systems shared by all attached commercial customers and may also include third party-provided access lines and other service elements. Such transmission services may represent sources of increased risk despite contract security provisions. NIST SP 800-41 provides guidance on firewalls and firewall policy. NIST SP 800-125B provides guidance on security for virtualization technologies.

Further Discussion¶

Fences, locks, badges, and key cards help keep non-employees out of your physical facilities. Similarly, your company’s IT network or system has boundaries that must be protected. Many companies use a web proxy and a firewall. When an employee uses a company computer to go to a website, a web proxy makes the request on the user’s behalf, looks at the web request, and decides if it should let the employee go to the website. A firewall controls access from the inside and outside, protecting valuable information and resources stored on the company’s network. A firewall stops unwanted traffic on the internet from passing through an outside “fence” to the company’s networks and information systems. Internal boundaries determine where data can flow, for instance a software development environment may have its own boundary controlling, monitoring, and protecting the data that can leave that boundary. It may be wise to monitor, control, or protect one part of the company network from another. This can also be accomplished with a firewall and limits the ability of attackers and disgruntled employees from entering sensitive parts of your internal network and causing damage.

Examples¶

• You are setting up the new network and want to keep your company’s information and resources safe. You start by sketching out a simple diagram that identifies the external boundary of your network and any internal boundaries that are needed [a,b]. The first piece of equipment you install is the firewall, a device to separate your internal network from the internet. The firewall also has a feature that allows you to block access to potentially malicious websites, and you configure that service as well [a,c,e,g]. Some of your coworkers complain that they cannot get onto certain websites [c,e,g]. You explain that the new network blocks websites that are known for spreading malware. The firewall sends you a daily digest of blocked activity so that you can monitor the system for attack trends [c,d].

Potential Assessment Considerations¶

• What are the external system boundary components that make up the entry and exit points for data flow (e.g., firewalls, gateways, cloud service boundaries), behind which all system components that handle regulated data are contained? What are the supporting system components necessary for the protection of regulated data [a]?
• What are the internal system boundary components that make up the entry and exit points for key internal data flow (e.g., internal firewalls, routers, any devices that can bridge the connection between one segment of the system and another) that separate segments of the internal network – including devices that separate internal network segments such as development and production networks as well as a traditional Demilitarized Zone (DMZ) at the edge of the network [b]?
• Is data flowing in and out of the external and key internal system boundaries monitored (e.g., connections are logged and able to be reviewed, suspicious traffic generates alerts) [c,d]?
• Is data traversing the external and internal system boundaries controlled such that connections are denied by default and only authorized connections are allowed [e,f]?
• Is data flowing in and out of the external and key internal system boundaries protected (e.g., applying encryption when required or prudent, tunneling traffic as needed) [g,h]?

Key References¶

• NIST SP 800-171 Rev. 2 3.13.1
• FAR Clause 52.204-21 b.1.x

SC.L2-3.13.2 – Security Engineering¶

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

Assessment Objectives¶

Source: NIST SP 800-171A, pp. 53-54.

Determine if:

• [a] architectural designs that promote effective information security are identified;
• [b] software development techniques that promote effective information security are identified;
• [c] systems engineering principles that promote effective information security are identified;
• [d] identified architectural designs that promote effective information security are employed;
• [e] identified software development techniques that promote effective information security are employed; and
• [f] identified systems engineering principles that promote effective information security are employed.

Potential Assessment Methods and Objects¶

Source: NIST SP 800-171A, pp. 53-54.

Examine: [SELECT FROM: Security planning policy; procedures addressing system security plan development and implementation; procedures addressing system security plan reviews and updates; enterprise architecture documentation; system security plan; records of system security plan reviews and updates; system and communications protection policy; procedures addressing security engineering principles used in the specification, design, development, implementation, and modification of the system; security architecture documentation; security requirements and specifications for the system; system design documentation; system configuration settings and associated documentation; other relevant documents or records].

Interview: [SELECT FROM: Personnel with responsibility for determining information system security requirements; personnel with information system design, development, implementation, and modification responsibilities; personnel with security planning and system security plan implementation responsibilities; personnel with information security responsibilities].

Test: [SELECT FROM: Organizational processes for system security plan development, review, update, and approval; mechanisms supporting the system security plan; processes for applying security engineering principles in system specification, design, development, implementation, and modification; automated mechanisms supporting the application of security engineering principles in information system specification, design, development, implementation, and modification].

Discussion¶

Source: NIST SP 800-171 Rev. 2, pp. 36-37.

Organizations apply systems security engineering principles to new development systems or systems undergoing major upgrades. For legacy systems, organizations apply systems security engineering principles to system upgrades and modifications to the extent feasible, given the current state of hardware, software, and firmware components within those systems. The application of systems security engineering concepts and principles helps to develop trustworthy, secure, and resilient systems and system components and reduce the susceptibility of organizations to disruptions, hazards, and threats. Examples of these concepts and principles 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; ensuring that developers are trained on how 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. Organizations that apply security engineering concepts and principles can facilitate the development of trustworthy, secure systems, system components, and system services; reduce risk to acceptable levels; and make informed risk-management decisions. NIST SP 800-160-1 provides guidance on systems security engineering.

Further Discussion¶

Familiarity with security engineering principles and their successful application to your infrastructure will increase the security of your environment. NIST SP 800-160 System Security Engineering: Considerations for a Multidisciplinary Approach in the Engineering of Trustworthy Secure Systems can serve as a source of security engineering and design principles. Decide which designs and principles to apply. Some will not be possible or appropriate for a given company or for specific systems or components. Designs and principles should be applied to policies and security standards. Starting with the baseline configuration, they should be extended through all layers of the technology stack (e.g., hardware, software, firmware) and throughout all the components of the infrastructure. The application of these chosen designs and principles should drive you towards a secure architecture with the required security capabilities and intrinsic behaviors present throughout the lifecycle of your technology. As legacy components age, it may become increasingly difficult for those components to meet security principles and requirements. This should factor into life-cycle decisions for those components (e.g., replacing legacy hardware, upgrading or re-writing software, upgrading run-time environments).

Examples¶

• You are responsible for developing strategies to protect data and harden your infrastructure. You are on a team responsible for performing a major upgrade to a legacy system. You refer to your documented security engineering principles [c]. Reviewing each, you decide which are appropriate and applicable [c]. You apply the chosen designs and principles when creating your design for the upgrade [f]. You document the security requirements for the software and hardware changes to ensure the principles are followed. You review the upgrade at critical points in the workflow to ensure the requirements are met. You assist in updating the policies covering the use of the upgraded system so user behavior stays aligned with the principles.

Potential Assessment Considerations¶

• Does the organization have a defined system architecture [a,d]?
• Are system security engineering principles applied in the specification, design, development and implementation of the systems [d,e,f]?

Key References¶

• NIST SP 800-171 Rev. 2 3.13.2

SC.L2-3.13.3 – Role Separation¶

Separate user functionality from system management functionality.

Assessment Objectives¶

Source: NIST SP 800-171A, p. 54.

Determine if:

• [a] user functionality is identified;
• [b] system management functionality is identified; and
• [c] user functionality is separated from system management functionality.

Potential Assessment Methods and Objects¶

Source: NIST SP 800-171A, p. 54.

Examine: [SELECT FROM: System and communications protection policy; procedures addressing application partitioning; system design documentation; system configuration settings and associated documentation; system security plan; system audit logs and records; other relevant documents or records].

Interview: [SELECT FROM: System or network administrators; personnel with information security responsibilities; system developer].

Test: [SELECT FROM: Separation of user functionality from system management functionality].

Discussion¶

Source: NIST SP 800-171 Rev. 2, p. 37.

System management functionality includes functions necessary to administer databases, network components, workstations, or servers, and typically requires privileged user access. The separation of user functionality from system management functionality is physical or logical. Organizations can implement separation of system management functionality from user functionality by using different computers, different central processing units, different instances of operating systems, or different network addresses; virtualization techniques; or combinations of these or other methods, as appropriate. This type of separation includes web administrative interfaces that use separate authentication methods for users of any other system resources. Separation of system and user functionality may include isolating administrative interfaces on different domains and with additional access controls.

Further Discussion¶

Prevent users and user services from accessing system management functionality on IT components (e.g., databases, network components, workstations, servers). This reduces the attack surface to those critical interfaces by limiting who can access and how they can be accessed. By separating the user functionality from system management functionality, the administrator or privileged functions are not available to the general user. The intent of this requirement is to ensure:

• general users are not permitted to perform system administration functions; and
• system administrators only perform system administration functions from their privileged account.

This can be accomplished using separation like VLANs or logical separation using strong access control methods.

Examples¶

• As a system administrator, you are responsible for managing a number of core systems. Policy prevents you from conducting any administration from the computer or system account you use for day-to-day work [a,b]. The servers you manage also are isolated from the main corporate network. To work with them you use a special unique account to connect to a “jump” server that has access to the systems you routinely administer.

Potential Assessment Considerations¶

• Are physical or logical controls used to separate user functionality from system management-related functionality (e.g., to ensure that administration (e.g., privilege) options are not available to general users) [c]?

Key References¶

• NIST SP 800-171 Rev. 2 3.13.3

SC.L2-3.13.4 – Shared Resource Control¶

Prevent unauthorized and unintended information transfer via shared system resources.

Assessment Objectives¶

Source: NIST SP 800-171A, pp. 54-55.

Determine if:

• [a] unauthorized and unintended information transfer via shared system resources is prevented.

Potential Assessment Methods and Objects¶

Source: NIST SP 800-171A, pp. 54-55.

Examine: [SELECT FROM: System and communications protection policy; procedures addressing application partitioning; system security plan; system design documentation; system configuration settings and associated documentation; system audit logs and records; other relevant documents or records].

Interview: [SELECT FROM: System or network administrators; personnel with information security responsibilities; system developer].

Test: [SELECT FROM: Separation of user functionality from system management functionality].

Discussion¶

Source: NIST SP 800-171 Rev. 2, p. 37.

The 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 the actions of prior users or roles (or the actions of processes acting on behalf of prior users or roles) from being available to any current users or roles (or current processes acting on behalf of current users or roles) that obtain access to shared system resources after those resources have been released back to the system. This requirement also applies to encrypted representations of information. This requirement does not address information remnants, which refers to residual representation of data that has been nominally deleted; covert channels (including storage or timing channels) where shared resources are manipulated to violate information flow restrictions; or components within systems for which there are only single users or roles.

Further Discussion¶

No shared system resource, such as cache memory, hard disks, registers, or main memory may pass information from one user to another user. In other words, when objects are reused no residual information should exist on that object. This protects the confidentiality of the information. This is typically a feature provided by operating system and software vendors.

Examples¶

• You are a system administrator responsible for creating and deploying the system hardening procedures for your company’s computers. You ensure that the computer baselines include software patches to prevent attackers from exploiting flaws in the processor architecture to read data (e.g., the Meltdown and Spectre exploits). You also verify that the computer operating system is configured to prevent users from accessing other users’ folders [a].

Potential Assessment Considerations¶

• Are shared system resources identified and documented [a]?

Key References¶

• NIST SP 800-171 Rev. 2 3.13.4

SC.L2-3.13.5 – Public-Access System Separation [CUI Data]¶

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

Assessment Objectives¶

Source: NIST SP 800-171A, p. 55.

Determine if:

• [a] publicly accessible system components are identified; and
• [b] subnetworks for publicly accessible system components are physically or logically separated from internal networks.

Potential Assessment Methods and Objects¶

Source: NIST SP 800-171A, p. 55.

Examine: [SELECT FROM: System and communications protection policy; procedures addressing boundary protection; system security plan; list of key internal boundaries of the system; system design documentation; boundary protection hardware and software; system configuration settings and associated documentation; enterprise security architecture documentation; system audit logs and records; other relevant documents or records].

Interview: [SELECT FROM: System or network administrators; personnel with information security responsibilities; system developers; personnel with boundary protection responsibilities].

Test: [SELECT FROM: Mechanisms implementing boundary protection capability].

Discussion¶

Subnetworks that are physically or logically separated from internal networks are referred to as demilitarized zones (DMZs). DMZs are typically implemented with boundary control devices and techniques that include routers, gateways, firewalls, virtualization, or cloud-based technologies. NIST SP 800-41 provides guidance on firewalls and firewall policy. SP 800-125B provides guidance on security for virtualization technologies.

FURTHER DISCUSSION 196 Separate the publicly accessible systems from the internal systems that need to be protected. Do not place internal systems on the same network as the publicly accessible systems and block access by default from DMZ networks to internal networks. One method of accomplishing this is to create a DMZ network, which enhances security by providing public access to a specific set of resources while preventing connections from those resources to the rest of the IT environment. Some OSAs achieve a similar result through the use of a cloud computing environment that is separated from the rest of the company’s infrastructure.

Examples¶

• The head of recruiting at your company wants to launch a website to post job openings and allow the public to download an application form [a]. After some discussion, your team realizes it needs to use a firewall to create a perimeter network to do this [b]. You host the server separately from the company’s internal network and make sure the network on which it resides is isolated with the proper firewall rules [b].

Potential Assessment Considerations¶

• Are any system components reachable by the public (e.g., internet-facing web servers, VPN gateways, publicly accessible cloud services) [a]?
• Are publicly accessible system components on physically or logically separated subnetworks (e.g., isolated subnetworks using separate, dedicated VLAN segments such as DMZs) [b]?

Key References¶

• NIST SP 800-171 Rev. 2 3.13.5
• FAR Clause 52.204-21 b.1.xi

SC.L2-3.13.6 – Network Communication by Exception¶

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

Assessment Objectives¶

Source: NIST SP 800-171A, p. 55.

Determine if:

• [a] network communications traffic is denied by default; and
• [b] network communications traffic is allowed by exception.

Potential Assessment Methods and Objects¶

Source: NIST SP 800-171A, p. 55.

Examine: [SELECT FROM: System and communications protection policy; procedures addressing boundary protection; system security plan; system design documentation; system configuration settings and associated documentation; system audit logs and records; other relevant documents or records].

Interview: [SELECT FROM: System or network administrators; personnel with information security responsibilities; system developer; personnel with boundary protection responsibilities].

Test: [SELECT FROM: Mechanisms implementing traffic management at managed interfaces].

Discussion¶

Source: NIST SP 800-171 Rev. 2, p. 38.

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 network communications traffic policy ensures that only those connections which are essential and approved are allowed.

Further Discussion¶

Block all traffic entering and leaving the network, but permit specific traffic based on organizational policies, exceptions, or criteria. This process of permitting only authorized traffic to the network is called whitelisting and limits the number of unintentional connections to the network.

This requirement, SC.L2-3.13.6, requires a deny-all permit by exception approach for all network communications. In doing so, it adds specifics for SC.L2-3.13.1, which only requires monitoring, control, and protection of communication channels.

Examples¶

• You are setting up a new environment to house CUI. To properly isolate the CUI network, you install a firewall between it and other networks and set the firewall rules to deny all traffic [a]. You review each service and application that runs in the new environment and determine that you only need to allow http and https traffic outbound [b]. You test the functionality of the required services and make some needed adjustments, then comment each firewall rule so there is documentation of why it is required. You review the firewall rules on a regular basis to make sure no unauthorized changes were made.

Potential Assessment Considerations¶

• Are network communications traffic on relevant system components (e.g., host and network firewalls, routers, gateways) denied by default (e.g., configured with an implicit deny rule that takes effect in the absence of any other matching traffic rules) [a]?
• Are network communications traffic on relevant system components (e.g., host and network firewalls, routers, gateways) allowed by exception (e.g., configured with explicit allow rules that takes effect only when network traffic matches one or more rules) [b]?

Key References¶

• NIST SP 800-171 Rev. 2 3.13.6

SC.L2-3.13.7 – Split Tunneling¶

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).

Assessment Objectives¶

Source: NIST SP 800-171A, p. 56.

Determine if:

• [a] remote devices are prevented from simultaneously establishing non-remote connections with the system and communicating via some other connection to resources in external networks (i.e., split tunneling).

Potential Assessment Methods and Objects¶

Source: NIST SP 800-171A, p. 56.

Examine: [SELECT FROM: System and communications protection policy; procedures addressing boundary protection; system security plan; system design documentation; system hardware and software; system architecture; system configuration settings and associated documentation; system audit logs and records; other relevant documents or records].

Interview: [SELECT FROM: System or network administrators; personnel with information security responsibilities; system developer; personnel with boundary protection responsibilities].

Test: [SELECT FROM: Mechanisms implementing boundary protection capability; mechanisms supporting or restricting non-remote connections].

Discussion¶

Source: NIST SP 800-171 Rev. 2, p. 38.

Split tunneling might be desirable by remote users to communicate with local system resources such as printers or file servers. However, split tunneling allows unauthorized external connections, making the system more vulnerable to attack and to exfiltration of organizational information. This requirement is implemented in remote devices (e.g., notebook computers, smart phones, and tablets) through configuration settings to disable split tunneling in those devices, and by preventing configuration settings from being readily configurable by users. This requirement is implemented in the system by the detection of split tunneling (or of configuration settings that allow split tunneling) in the remote device, and by prohibiting the connection if the remote device is using split tunneling.

Further Discussion¶

Split tunneling for a remote user utilizes two connections: accessing resources on the internal network via a VPN and simultaneously accessing an external network such as a public network or the internet. Split tunneling presents a potential opportunity where an open unencrypted connection from a public network could allow an adversary to access resources on internal network. As a mitigation strategy, the split tunneling setting should be disabled on all devices so that all traffic, including traffic for external networks or the internet, goes through the VPN.

Examples¶

• You are a system administrator responsible for configuring the network to prevent remote users from using split tunneling. You review the configuration of remote user laptops. You discover that remote users are able to access files, email, database and other services through the VPN connection while also being able to print and access resources on their local network. You change the configuration settings for all company computers to disable split tunneling [a]. You test a laptop that has had the new hardening procedures applied and verify that all traffic from the laptop is now routed through the VPN connection.

Potential Assessment Considerations¶

• Does the system prevent remote devices that have established connections (e.g., remote laptops) with the system from communicating outside that communications path with resources on uncontrolled/unauthorized networks [a]?

Key References¶

• NIST SP 800-171 Rev. 2 3.13.7

SC.L2-3.13.8 – Data in Transit¶

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

Assessment Objectives¶

Source: NIST SP 800-171A, p. 56.

Determine if:

• [a] cryptographic mechanisms intended to prevent unauthorized disclosure of CUI are identified;
• [b] alternative physical safeguards intended to prevent unauthorized disclosure of CUI are identified; and
• [c] either cryptographic mechanisms or alternative physical safeguards are implemented to prevent unauthorized disclosure of CUI during transmission.

Potential Assessment Methods and Objects¶

Source: NIST SP 800-171A, p. 56.

Examine: [SELECT FROM: System and communications protection policy; procedures addressing transmission confidentiality and integrity; system security plan; system design documentation; system configuration settings and associated documentation; system audit logs and records; other relevant documents or records].

Interview: [SELECT FROM: System or network administrators; personnel with information security responsibilities; system developer].

Test: [SELECT FROM: Cryptographic mechanisms or mechanisms supporting or implementing transmission confidentiality; organizational processes for defining and implementing alternative physical safeguards].

Discussion¶

Source: NIST SP 800-171 Rev. 2, p. 38.

This requirement applies to internal and external networks and any system components that can transmit information including servers, notebook computers, desktop computers, mobile devices, printers, copiers, scanners, and facsimile machines. Communication paths outside the physical protection of controlled boundaries are susceptible to both interception and modification. Organizations relying on commercial providers offering transmission services as commodity services rather than as fully dedicated services (i.e., services which can be highly specialized to individual customer needs), may find it difficult to obtain the necessary assurances regarding the implementation of the controls for transmission confidentiality. In such situations, organizations determine what types of confidentiality services are available in commercial telecommunication service packages. If it is infeasible or impractical to obtain the necessary safeguards and assurances of the effectiveness of the safeguards through appropriate contracting vehicles, organizations 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, thereby ensuring the confidentiality of the information being transmitted.

Further Discussion¶

The intent of this requirement is to ensure CUI is cryptographically protected during transit, particularly on the internet. The most common way to accomplish this is to establish a TLS tunnel between the source and destination using the most current version of TLS. This requirement does not specify a mutually authenticated handshake, but mutual authentication is the most secure approach to creating a tunnel. Because the use of cryptography in this requirement is to protect the confidentiality of CUI, the cryptography used must meet the criteria specified in requirement SC.L2-3.13.11. This requirement, SC.L2-3.13.8, requires cryptographic mechanisms be used to prevent the disclosure of CUI in-transit and leverages SC.L2-3.13.11, which specifies that the algorithms used must be FIPS-validated cryptography.

Examples¶

• You are a system administrator responsible for configuring encryption on all devices that contain CUI. Because your users regularly store CUI on laptops and take them out of the office, you encrypt the hard drives with a FIPS-validated encryption tool built into the operating system. For users who need to share CUI, you install a Secure FTP server to allow CUI to be transmitted in a compliant manner [a]. You verify that the server is using a FIPS-validated encryption module by checking the NIST Cryptographic Module Validation Program website [c]. You turn on the “FIPS Compliance” setting for the server during configuration because that is what is required for this product in order to use only FIPS-validated cryptography [c].

Potential Assessment Considerations¶

• Are cryptographic mechanisms used to prevent unauthorized disclosure of information during transmission unless otherwise protected by alternative physical measures (e.g., PDS) [c]?

Key References¶

• NIST SP 800-171 Rev. 2 3.13.8

SC.L2-3.13.9 – Connections Termination¶

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

Assessment Objectives¶

Source: NIST SP 800-171A, p. 57.

Determine if:

• [a] a period of inactivity to terminate network connections associated with communications sessions is defined;
• [b] network connections associated with communications sessions are terminated at the end of the sessions; and
• [c] network connections associated with communications sessions are terminated after the defined period of inactivity.

Potential Assessment Methods and Objects¶

Source: NIST SP 800-171A, p. 57.

Examine: [SELECT FROM: System and communications protection policy; procedures addressing network disconnect; system design documentation; system security plan; system configuration settings and associated documentation; system audit logs and records; other relevant documents or records].

Interview: [SELECT FROM: System or network administrators; personnel with information security responsibilities; system developer].

Test: [SELECT FROM: Mechanisms supporting or implementing network disconnect capability].

Discussion¶

Source: NIST SP 800-171 Rev. 2, pp. 38-39.

This requirement applies to internal and external networks. Terminating network connections associated with communications sessions include 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 are using a single, operating system-level network connection. Time periods of user inactivity may be established by organizations and include time periods by type of network access or for specific network accesses.

Further Discussion¶

Prevent malicious actors from taking advantage of an open network session or an unattended computer at the end of the connection. Balance user work patterns and needs against security to determine the length of inactivity that will force a termination. This requirement, SC.L2-3.13.9, specifies network connections be terminated under certain conditions, which complements AC.L2-3.1.18 that specifies control of mobile device connections.

Examples¶

• You are an administrator of a server that provides remote access. Your company’s policies state that network connections must be terminated after being idle for 60 minutes [a]. You edit the server configuration file and set the timeout to 60 minutes and restart the remote access software [c]. You test the software and verify that the connection is terminated appropriately.

Potential Assessment Considerations¶

• Are the network connections requiring management and time-out for inactivity documented [a]?
• Are the network connections requiring management and time-out for inactivity configured and implemented [c]?

Key References¶

• NIST SP 800-171 Rev. 2 3.13.9

SC.L2-3.13.10 – Key Management¶

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

Assessment Objectives¶

Source: NIST SP 800-171A, p. 57.

Determine if:

• [a] cryptographic keys are established whenever cryptography is employed; and
• [b] cryptographic keys are managed whenever cryptography is employed.

Potential Assessment Methods and Objects¶

Source: NIST SP 800-171A, p. 57.

Examine: [SELECT FROM: System and communications protection policy; procedures addressing cryptographic key establishment and management; system security plan; system design documentation; cryptographic mechanisms; system configuration settings and associated documentation; system audit logs and records; other relevant documents or records].

Interview: [SELECT FROM: System or network administrators; personnel with information security responsibilities; personnel with responsibilities for cryptographic key establishment and management].

Test: [SELECT FROM: Mechanisms supporting or implementing cryptographic key establishment and management].

Discussion¶

Source: NIST SP 800-171 Rev. 2, p. 39.

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 specifying appropriate options, levels, and parameters. NIST SP 800-56A and NIST SP 800-57-1 provide guidance on cryptographic key management and key establishment.

Further Discussion¶

Develop processes and technical mechanisms to protect the cryptographic keys’ confidentiality, authenticity, and authorized use in accordance with industry standards and regulations. Key management systems provide oversight, assurance, and the capability to demonstrate the cryptographic keys are created in a secure manner and protected from loss or misuse throughout their lifecycle (e.g., active, expired, revoked). For a small number of keys, this can be accomplished with manual procedures and mechanisms. As the number of keys and cryptographic units increase, automation and tool support will be required. The first intent of this requirement is to ensure cryptographic keys are properly created in a secure manner that prevents them from being reproduced by an adversary. The second intent of this requirement is to ensure cryptographic keys are managed in a secure manner that prevents them from being stolen by an adversary. Key establishment involves the creation of keys and coordination among parties that will use the keys of the methodology for generating the final keying material. This is discussed in detail in SP 800-56A, B, and C. Key management involves protecting keys when they are distributed, when they are stored, when they are being used, and when they are being recovered. Key establishment best practices are identified in NIST SP 800-56A, B, and C. Key management best practices are identified in NIST SP 800-57 Parts 1, 2, and 3. This requirement, SC.L2-3.13.10, complements AC.L2-3.1.19 by specifying that any cryptographic keys in use must be protected.

Examples¶

• You are a system administrator responsible for providing key management. You have generated a public-private key pair to exchange CUI [a]. You require all system administrators to read the key management policy before you allow them to install the private key on their machines [b]. No one else is allowed to know or have a copy of the private key per the policy. You provide the public key to the other parties who will be sending you CUI and test the Public Key Infrastructure (PKI) to ensure the encryption is working [a]. You set a revocation period of one year on all your certificates per organizational policy [b].

• You encrypt all of your company’s computers using the disk encryption utility built into the operating system. As you configure encryption on each device, it generates a cryptographic key. You associate each key with the correct computer in your inventory spreadsheet and restrict access to the spreadsheet to the system administrators whose work role requires them to manage the computers [b].

Potential Assessment Considerations¶

• Are cryptographic keys established whenever cryptography is employed (e.g., digital signatures, authentication, authorization, transport, or other cryptographic mechanisms) [a]?
• Are cryptographic keys maintained whenever cryptography is employed (e.g., key storage, backup, recovery, revocation, destruction, etc.) [b]?

Key References¶

• NIST SP 800-171 Rev. 2 3.13.10

SC.L2-3.13.11 – CUI Encryption¶

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

Assessment Objectives¶

Source: NIST SP 800-171A, pp. 57-58.

Determine if:

• [a] FIPS-validated cryptography is employed to protect the confidentiality of CUI.

Potential Assessment Methods and Objects¶

Source: NIST SP 800-171A, pp. 57-58.

Examine: [SELECT FROM: System and communications protection policy; procedures addressing cryptographic protection; system security plan; system design documentation; system configuration settings and associated documentation; cryptographic module validation certificates; list of FIPS-validated cryptographic modules; system audit logs and records; any other relevant documents or records].

Interview: [SELECT FROM: System or network administrators; personnel with information security responsibilities; system developers; personnel with responsibilities for cryptographic protection].

Test: [SELECT FROM: Mechanisms supporting or implementing cryptographic protection].

Discussion¶

Source: NIST SP 800-171 Rev. 2, p. 39.

Cryptography can be employed to support many security solutions including the protection of controlled unclassified information, the provision of digital signatures, and the enforcement of information separation when authorized individuals have the necessary clearances for such information but lack the necessary formal access approvals. Cryptography can also be used to support random number generation and hash generation. Cryptographic standards include FIPS-validated cryptography and/or NSA-approved cryptography.

Further Discussion¶

FIPS-validated cryptography means the cryptographic module has to have been tested and validated to meet FIPS 140-2 requirements. Simply using an approved algorithm is not sufficient – the module (software and/or hardware) used to implement the algorithm must be separately validated under FIPS 140. Accordingly, FIPS-validated cryptography is required to protect CUI when transmitted or stored outside the protected environment of the covered OSA information system (including wireless/remote access). Encryption used for other purposes, such as within applications or devices within the protected environment of the covered OSA information system, would not need to use FIPS-validated cryptography. This requirement, SC.L2-3.13.11, complements AC.L2-3.1.19, MP.L2-3.8.6, SC.L2-3.13.8, and SC.L2-3.13.16 by specifying that FIPS-validated cryptography must be used. While FIPS-validated modules and algorithms are critical for protecting CUI, in limited cases Enduring Exceptions and temporary deficiencies may apply when implementing such cryptographic mechanisms.

Examples¶

• You are a system administrator responsible for deploying encryption on all devices that contain CUI. You must ensure that the encryption you use on the devices is FIPS-validated cryptography [a]. An employee informs you of a need to carry a large volume of CUI offsite and asks for guidance on how to do so. You provide the user with disk encryption software that you have verified via the NIST website that uses a CMVP-validated encryption module [a]. Once the encryption software is active, the user copies the CUI data onto the drive for transport.

Potential Assessment Considerations¶

• Is cryptography implemented to protect the confidentiality of CUI at rest and in transit, through the configuration of systems and applications or through the use of encryption tools [a]?

Key References¶

• NIST SP 800-171 Rev. 2 3.13.11

SC.L2-3.13.12 – Collaborative Device Control¶

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

Assessment Objectives¶

Source: NIST SP 800-171A, p. 58.

Determine if:

• [a] collaborative computing devices are identified;
• [b] collaborative computing devices provide indication to users of devices in use; and
• [c] remote activation of collaborative computing devices is prohibited.

Potential Assessment Methods and Objects¶

Source: NIST SP 800-171A, p. 58.

Examine: [SELECT FROM: System and communications protection policy; procedures addressing collaborative computing; access control policy and procedures; system security plan; system design documentation; system audit logs and records; system configuration settings and associated documentation; other relevant documents or records].

Interview: [SELECT FROM: System or network administrators; personnel with information security responsibilities; system developer; personnel with responsibilities for managing collaborative computing devices].

Test: [SELECT FROM: Mechanisms supporting or implementing management of remote activation of collaborative computing devices; mechanisms providing an indication of use of collaborative computing devices].

Discussion¶

Source: NIST SP 800-171 Rev. 2, p. 39.

Collaborative computing devices include networked white boards, cameras, and microphones. Indication of use includes signals to users when collaborative computing devices are activated. Dedicated video conferencing systems, which rely on one of the participants calling or connecting to the other party to activate the video conference, are excluded.

Further Discussion¶

Notification that a device is in use can include an indicator light that turns on or a specific text window that appears on screen. If a device does not have the means to alert a user when in use, the organization should provide manual means. Manual means can include, as necessary:

• paper notification on entryways; and
• locking entryways when a collaborative computing device is in use.

This requirement is not intended to include technologies that enable users to share the contents of their computer screens via the internet.

Examples¶

• A group of remote employees at your company routinely collaborate using cameras and microphones attached to their computers [a]. To prevent the misuse of these devices, you disable the ability to turn on cameras or microphones remotely [c]. You ensure the machines alert users when the camera or microphone are in use with a light beside the camera and an onscreen notification [b]. Although remote activation is blocked, this enables users to see if the devices are active.

Potential Assessment Considerations¶

• Are the collaborative computing devices configured to provide indication to users when in use (e.g., a light, text notification, or audio tone) or are users alerted before entering a space (e.g., written notice posted outside the space) where they are in use [b]?
• Are the collaborative computing devices configured to prevent them from being turned on without user interaction or consent [c]?

Key References¶

• NIST SP 800-171 Rev. 2 3.13.12

SC.L2-3.13.13 – Mobile Code¶

Control and monitor the use of mobile code.

Assessment Objectives¶

Source: NIST SP 800-171A, pp. 58-59.

Determine if:

• [a] use of mobile code is controlled; and
• [b] use of mobile code is monitored.

Potential Assessment Methods and Objects¶

Source: NIST SP 800-171A, pp. 58-59.

Examine: [SELECT FROM: System and communications protection policy; procedures addressing mobile code; mobile code usage restrictions, mobile code implementation policy and procedures; system audit logs and records; system security plan; list of acceptable mobile code and mobile code technologies; list of unacceptable mobile code and mobile technologies; authorization records; system monitoring records; system audit logs and records; other relevant documents or records].

Interview: [SELECT FROM: System or network administrators; personnel with information security responsibilities; personnel with responsibilities for managing mobile code].

Test: [SELECT FROM: Organizational process for controlling, authorizing, monitoring, and restricting mobile code; mechanisms supporting or implementing the management of mobile code; mechanisms supporting or implementing the monitoring of mobile code].

Discussion¶

Source: NIST SP 800-171 Rev. 2, pp. 39-40.

Mobile code technologies include Java, JavaScript, ActiveX, Postscript, PDF, Flash animations, and VBScript. Decisions regarding the use of mobile code in organizational systems are based on the potential for the code to cause damage to the systems if used maliciously. Usage restrictions and implementation guidance apply to the selection and use of mobile code installed on servers and mobile code downloaded and executed on individual workstations, notebook computers, and devices (e.g., smart phones). Mobile code policy and procedures address controlling or preventing the development, acquisition, or introduction of unacceptable mobile code in systems, including requiring mobile code to be digitally signed by a trusted source.

Further Discussion¶

Ensure mobile code is authorized to execute in company systems only in accordance with policy and technical configuration, and that unauthorized mobile code is not. Monitor the use of mobile code through boundary devices (e.g., firewalls), audit logs, or security utilities (e.g., mobile device management, advanced endpoint protection) and implement remediation activities as needed. The first intent of this requirement is to ensure the limits of mobile code usage and usage restrictions are documented and enforced. This includes documenting all authorizations for the use of mobile code and ensuring it is not used in other ways. Usage restrictions and implementation guidance apply to the selection and use of mobile code installed on servers and mobile code downloaded and executed on individual workstations and devices to include all mobile devices and smart phones. The second intent is to monitor the use of mobile code and implement remediation steps if its use does not align with policy.

Examples¶

• Your company has decided to prohibit the use of Flash, ActiveX, and Java plug-ins for web browsers on all of its computers [a]. To enforce this policy you configure the computer baseline configuration to disable and deny the execution of mobile code [a]. You implement an exception process to re-enable mobile code execution only for those users with a legitimate business need [a]. One department complains that a web application they need to perform their job no longer works. You meet with them and verify that the web application uses ActiveX in the browser. You submit a change request with the Change Review Board. Once the change is approved, you reconfigure the department’s computers to allow the running of ActiveX in the browser. You also configure the company firewall to alert you if ActiveX is used by any website but the allowed one [b]. You set a reminder for yourself to check in with the department at the end of the year to verify they still need that web application.

Potential Assessment Considerations¶

• Are there defined limits of mobile code usage and established usage restrictions, which specifically authorize use of mobile code (e.g., Java, JavaScript, ActiveX, PDF, Flash, Shockwave, Postscript, VBScript) within the information system [a]?
• Is the use of mobile code documented, monitored, and managed (e.g., Java, JavaScript, ActiveX, PDF, Flash, Shockwave, Postscript, VBScript) [b]?

Key References¶

• NIST SP 800-171 Rev. 2 3.13.13

SC.L2-3.13.14 – Voice over Internet Protocol¶

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

Assessment Objectives¶

Source: NIST SP 800-171A, p. 59.

Determine if:

• [a] use of Voice over Internet Protocol (VoIP) technologies is controlled; and
• [b] use of Voice over Internet Protocol (VoIP) technologies is monitored.

Potential Assessment Methods and Objects¶

Source: NIST SP 800-171A, p. 59.

Examine: [SELECT FROM: System and communications protection policy; procedures addressing VoIP; VoIP usage restrictions; VoIP implementation guidance; system security plan; system design documentation; system audit logs and records; system configuration settings and associated documentation; system monitoring records; other relevant documents or records].

Interview: [SELECT FROM: System or network administrators; personnel with information security responsibilities; personnel with responsibilities for managing VoIP].

Test: [SELECT FROM: Organizational process for authorizing, monitoring, and controlling VoIP; mechanisms supporting or implementing authorizing, monitoring, and controlling VoIP].

Discussion¶

Source: NIST SP 800-171 Rev. 2, p. 40.

VoIP has different requirements, features, functionality, availability, and service limitations when compared with the Plain Old Telephone Service (POTS) (i.e., the standard telephone service). In contrast, other telephone services are based on high-speed, digital communications lines, such as Integrated Services Digital Network (ISDN) and Fiber Distributed Data Interface (FDDI). The main distinctions between POTS and non-POTS services are speed and bandwidth. To address the threats associated with VoIP, usage restrictions and implementation guidelines are based on the potential for the VoIP technology to cause damage to the system if it is used maliciously. Threats to VoIP are similar to those inherent with any Internet-based application. NIST SP 800-58 provides guidance on Voice Over IP Systems.

Further Discussion¶

Controlling VoIP technologies starts with establishing guidelines and enforcing the appropriate usage that is described in organizational policies. Monitoring should include the users’ activity for anything other than what is permitted and authorized and detection of insecure or unauthorized use of the VoIP technology. Security concerns for VoIP include eavesdropping on calls and using ID spoofing to impersonate trusted individuals. Selecting a solution that can encrypt VoIP traffic is helpful in maintaining the confidentiality and integrity of the voice data.

Examples¶

• You are a system administrator responsible for the VoIP system. You configure VoIP for new users after being notified that they have signed the Acceptable Use Policy for VoIP technology [a]. You verify that the VoIP solution is configured to use encryption and have enabled requirements for passwords on voice mailboxes and on phone extension management. You require phone system administrators to log in using multifactor authentication when managing the system [a]. You add the VoIP software to the list of applications that are patched monthly as needed [a,b]. Finally, you configure the VoIP system to send logs to your log aggregator so that they can be correlated with those from other systems and examined for signs of suspicious activity [b].

Potential Assessment Considerations¶

• Are VoIP technologies (e.g., approved and managed products or solutions) that may or may not be used in the system defined [a]?
• Is monitoring for unapproved VoIP technologies or unapproved use of the allowed VoIP solutions employed [b]?

Key References¶

• NIST SP 800-171 Rev. 2 3.13.14

SC.L2-3.13.15 – Communications Authenticity¶

Protect the authenticity of communications sessions.

Assessment Objectives¶

Source: NIST SP 800-171A, p. 59.

Determine if:

• [a] the authenticity of communications sessions is protected.

Potential Assessment Methods and Objects¶

Source: NIST SP 800-171A, p. 59.

Examine: [SELECT FROM: System and communications protection policy; procedures addressing session authenticity; system security plan; system design documentation; system configuration settings and associated documentation; system audit logs and records; other relevant documents or records].

Interview: [SELECT FROM: System or network administrators; personnel with information security responsibilities].

Test: [SELECT FROM: Mechanisms supporting or implementing session authenticity]

Discussion¶

Source: NIST SP 800-171 Rev. 2, p. 40.

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 versus packet level (e.g., sessions in service-oriented architectures providing web-based services) and establishes grounds for confidence at both ends of communications sessions in ongoing identities of other parties and in the validity of information transmitted. NIST SP 800-77, NIST SP 800-95, and NIST SP 800-113 provide guidance on secure communications sessions.

Further Discussion¶

The intent of this requirement is to ensure a trust relationship is established between both ends of a communication session. Each end can be assured that the other end is who it is supposed to be. This is often implemented using a mutual authentication handshake when the session is established, especially between devices. Session authenticity is usually provided by a security protocol enforced for a communication session. Choosing and enforcing a protocol will provide authenticity throughout a communications session.

Examples¶

• You are a system administrator responsible for ensuring that the two-factor user authentication mechanism for the servers is configured correctly. You purchase and maintain the digital certificate and replace it with a new one before the old one expires. You ensure the TLS configuration settings on the web servers, VPN solution, and other components that use TLS are correct, using secure settings that address risks against attacks on the encrypted sessions [a].

Potential Assessment Considerations¶

• Is a communications protocol used that ensures the sending and receiving parties do not change during a communications session [a]?
• Are controls in place to validate the identities and information transmitted to protect against man-in-the-middle attacks, session hijacking, and insertion of false information into communications sessions [a]?

Key References¶

• NIST SP 800-171 Rev. 2 3.13.15

SC.L2-3.13.16 – Data at Rest¶

Protect the confidentiality of CUI at rest.

Assessment Objectives¶

Source: NIST SP 800-171A, pp. 59-60.

Determine if:

• [a] the confidentiality of CUI at rest is protected.

Potential Assessment Methods and Objects¶

Source: NIST SP 800-171A, pp. 59-60.

Examine: [SELECT FROM: System and communications protection policy; procedures addressing protection of information at rest; system security plan; system design documentation; list of information at rest requiring confidentiality protections; system configuration settings and associated documentation; cryptographic mechanisms and associated configuration documentation; other relevant documents or records].

Interview: [SELECT FROM: System or network administrators; personnel with information security responsibilities; system developer].

Test: [SELECT FROM: Mechanisms supporting or implementing confidentiality protections for information at rest].

Discussion¶

Source: NIST SP 800-171 Rev. 2, p. 40.

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. The focus of protection at rest is not on the type of storage device or the frequency of access but rather the state of the information. Organizations can use different mechanisms to achieve confidentiality protections, including the use of cryptographic mechanisms and file share scanning. Organizations may also use other controls including secure off-line storage in lieu of online storage when adequate protection of information at rest cannot otherwise be achieved or continuous monitoring to identify malicious code at rest.

Further Discussion¶

CUI at rest means information that is not moving through the network; typically this means data currently stored on hard drives, media, and mobile devices. Implement the necessary security controls to protect the confidentiality of CUI at rest. Although an approved encryption method protects data stored at rest, there are other technical and physical solutions. The methods chosen should depend on the environment and business needs. Implementing encryption for CUI is one approach to this requirement, but it is not mandatory. Physical security is often employed to restrict access to CUI, particularly when it resides on servers within a company’s offices. Other approaches for protecting CUI include system-related protections such as configurations and rule sets for firewalls, gateways, intrusion detection/prevention systems, filtering routers, and authenticator content that eliminate attempts at exfiltration. You may also employ other security requirements including secure off-line storage. Because the use of cryptography in this requirement is to protect the confidentiality of CUI, the cryptography used must meet the criteria specified in requirement SC.L2-3.13.11. This requirement, SC.L2-3.13.16, specifies confidentially be provided for CUI at rest and complements MP.L2-3.8.9, which specifies confidentially of CUI at backup storage locations. This requirement, SC.L2-3.13.16, also leverages SC.L2-3.13.11, which specifies that the algorithms used must be FIPS-validated cryptography.

Examples¶

• Your company has a policy stating CUI must be protected at rest and you work to enforce that policy. You research Full Disk Encryption (FDE) products that meet the FIPS encryption requirement. After testing, you deploy the encryption to all computers to protect CUI at rest [a].

• You have used encryption to protect the CUI on most of the computers at your company, but you have some devices that do not support encryption. You create a policy requiring these devices to be signed out when needed, stay in possession of the signer when checked out, and to be signed back in and locked up in a secured closet when the user is done with the device [a]. At the end of the day each Friday, you audit the sign-out sheet and make sure all devices are returned to the closet.

Potential Assessment Considerations¶

• Is the confidentiality of CUI at rest protected using encryption of storage devices and/or appropriate physical methods [a]?

Key References¶

• NIST SP 800-171 Rev. 2 3.13.16