%201.png)
%201.png)
If 3.1.1 authorizes access within the system boundary, 3.1.20 manages access to external systems. Organizations may have no supervision of controls on systems outside the system boundary. System architecture design and separation techniques may isolate assets that handle sensitive information. Organizations may consider these separated systems external to the system handling sensitive information. This blog will discuss the following topics around 3.1.20:
NIST introduced special publication (SP) 800-171 in June of 2015. NIST retained the identification number of 3.1.20 through the first and second revisions. NIST SP 800-171 Revision 3 has changed this requirement's number to 03.01.20.
The upcoming cybersecurity maturity model certification (CMMC) rule verifies SP 800-171 Rev 2. CMMC 1.02 numbered this practice AC.1.003 then AC.L1-3.1.20 under CMMC 2.0. This practice applies to organizations seeking compliance within any level of CMMC.
As of 12/22/23, CMMC 2.1 creates two numbers for this practice:
NIST SP 800-171 derived seventy-nine security requirements from SP 800-53 Rev 4. Below is the original language of this control from SP 800-53 Rev 4:
NIST abbreviated the language in SP 800-171 to:
NIST SP 800-171A provided assessment procedures for the corresponding security requirements. The procedures apply assessment methods (examine, interview, test) to assessment objects. The assessor evaluates each part to produce the finding. A “satisfied” finding indicates an acceptable result. A finding of “other than satisfied” indicates anomalies.
The assessment objectives for 3.1.20 contains six determination statements:
Appendix D within SP 800-171 maps security requirements to SP 800-53 controls. This mapping relates 3.1.20 to both AC-20 and AC-20(1).
We mapped these six objectives to the closest SP 800-53A Rev 5 objectives. We used guidance from NIST IR 8477 to define the nature and strength of the relationships. The findings indicated that:
The 3.1.20 discussion combines parts of use of external systems and limiting authorized use.
Parts (a) and (b) of 3.1.20 compel organizations to identify connections to and the use of external systems. NIST incorporated the some of the AC-20 supplemental guidance into the 3.1.20 discussion:
The first sentence of the CMMC Assessment Guide discussion provides a new narrative:
External information systems are information systems or components of information systems. They are outside of the authorization boundary established by organizations. Organizations may not have direct supervision over the application of security controls. They also may not have authority over the assessment of control effectiveness.
The fourth paragraph adds guidance when using separation techniques in the security architecture:
Note that “external” may refer to outside of the organization’s supervision. That definition is not always the case. The organization may have systems that process FCI or CUI and others that do not. There are likely access restrictions that apply between systems that process sensitive data . From this perspective, the organization may consider other internal systems “external" .
Parts (c), (d) focus on verifying the authorized use of external information systems. The third paragraph of the discussion maps to the supplemental guidance from AC-20(1):
The CMMC Assessment Guide provides a practical guide in the further discussion. This section simplifies the concept by including practical tools and actionable steps:
Control and manage connections between your company network and outside networks. Outside networks may include the public internet. It may include your own company’s networks that fall outside your CMMC Assessment Scope. For example, an isolated lab within your company. It may also include a network that does not belong to your company. Organizations may use tools including firewalls and connection allow/deny lists. External systems may run prohibited or blocked applications. Control and limit access from employee owned devices. This includes laptops, tablets, and phones. You may choose to limit connections to outside systems from network resources. You may also limit connections to external systems for certain employees.
The supplemental guidance from AC-4 was not included in 3.1.20. It does describe controls and limits to the use of and connections to external systems:
The NIST SP 800-171 DoD Assessment Methodology Version 1.2.1 assigned a 1-point value to this practice. Failing to limit use of external systems has a limited effect on network and data security. CMMC section 170.21(iii)(A) removes the eligibility of limited deficiency in this practice. This practice aligns to the basic cybersecurity safeguards requirements of 52.204-21.
Appendix C within NIST SP 800-53 Rev 5 discusses three implementation approaches:
NIST defines the implementation of the corresponding SP 800-53 controls as:
The crosswalk suggests that 3.1.20 requires both technical and nontechnical implementations. The Defense Contract Management Agency (DCMA) also published guidance for assessing SP 800-171. The DCMA Guide identifies documents as the relevant evidence for parts (a) and (b). Parts (c) and (d) list artifacts as the relevant evidence. Parts (e) and (f) list screen shares as the relevant evidence. We concluded part (a), (b), (c), and (d) are nontechnical while parts (e) and (f) call for a technical implementation.
Inheriting 3.1.20 is possible. External service providers may identify, verify, limit and control external system usage. The Ariento shared responsibility matrix identifies 3.1.20 as an inherited practice.
NIST SP 800-47 defines system interconnections. They are direct connections between two or more systems. Each system has different authorization boundaries. This includes systems owned by different organizations. But it also includes separated systems within the same organization.
Establishing a system authorization boundary is a prerequisite to identifying external system connections. Building a data flow diagram helps identify system elements. Elements include components processing, storing, or transmitting information or providing security functions.
Organizations should base system interconnection authorizations on an assessment of associated risks. NIST SP 800-41 advises:
Before creating a firewall policy, organizations should assess their risk. Develop a list of the types of traffic needed by the organization. Categorize how to secure each connection. Identify the types of traffic that can traverse a firewall under what circumstances. Analyze threats, vulnerabilities, countermeasures, and the impact of systems or data compromise. Document firewall policy in the system security plan. Update authorizations as vulnerabilities arise or as the needs of network applications change.
According to NIST SP 800-47, system interconnections have three basic components:
NIST SP 800-47 describes two types of connections:
NIST SP 800-113 compares several VPN protocols:
NIST SP 800-113 also includes a table that identifies the relevant protocols. These IP protocols include User Datagram Protocol (UDP) and Transmission Control Protocols (TCP):
Let's look at the requirements of 3.1.20 parts (a) and (b) first. Organizations should identify connections to and usage of external systems. Documenting these authorized connections also helps meet part (f) of practice 3.12.4. The FedRAMP Moderate Baseline SSP Template provides some identification guidance. The table headers detail how to document system interconnections:
Next we’ll look at requirements of 3.1.1 parts (c) and (d). Organizations should verify the use of and connections to external systems. Verification establishes confidence the external systems contain the necessary security safeguards. Third-party or independent assessments, attestations or other means may achieve these objectives.
Let’s look at the objectives from NIST SP 800-53A Rev 4 for AC-20(1):
Organizations have two options for verification. The first option identifies required controls and verifies their implementation. The second option establishes terms and conditions with the external hosting entity.
There are three contractual flow-down provisions to consider:
Finally, we’ll look at requirements of 3.1.20 parts (e) and (f). Organizations should control and limit connections to and the use of external systems. The Department of Defense categorizes 3.1.20 as implemented by hardware. Firewalls should block all traffic not permitted by the firewall policy. This decreases the risk of attack by reducing the volume of traffic on the network. A deny-by-default approach is more secure than permitting traffic that is not forbidden.
Microsoft Entra ID and Defender for Endpoint may play a role in Windows environments. These components prevent access to dangerous web domains via applications. Microsoft provides guidance that helps explain the potential steps for configuring access controls:
Entra ID (Azure AD)
Windows Defender Firewall
ATX Defense published similar instructions for Google Workspace. ATX recommends identifying external connections including VPNs or Managed Service Providers. They also suggest using an endpoint firewall to block unauthorized or dangerous connections.
Continuous monitoring activities verify that controls produce the desired outcome(s). The practice 3.1.20 has three desired outcomes:
Organizations should document external connections on a network diagram. Updating the network diagram helps maintain compliance with 3.1.20 parts (a), (b), and (e). Organizations should also update the network diagram when adding or removing system components.
Additional continuous monitoring activities may include:
Use of External Systems
Boundary Protection
NIST SP 800-171 Rev 3 aligns 03.01.20 with AC-20, AC-20(1) and AC-20(2) from SP 800-53 Rev 5. There are still six parts but the updated practice now incorporates the previous three parts of 3.1.21.
There is one organization defined parameter derived from AC-20. Organizations should define the security requirements for external systems. This should occur before allowing the use of or access to those systems.
Organizations should assess risk before authorizing system interconnections. The assessment should prescribe security requirements to protect organizational data and systems. Verifying the hosting entity meets those requirements establishes assurance for the external system. Organizations should document authorized connections and update authorizations based on evolving business needs. Mechanisms, like firewalls, help control and limit system interconnections to authorized external systems.
