Implementing 3.1.1 from NIST SP 800-171 Rev 2: Everything You Need to Know

NIST SP 800-171 prescribes 110 security requirements to protect the confidentiality of data. NIST SP 800-171A details 320 assessment procedures for these security requirements.

A Brief History

NIST released the first draft of SP 800-171 in June of 2015. NIST retained the identification number of 3.1.1 through the first and second revisions. The final public draft of NIST SP 800-171 Revision 3 has recommended changing the number to 03.01.01.

The proposed cybersecurity maturity model certification (CMMC) rule verifies SP 800-171.  CMMC 1.02 numbered this practice AC.1.001 then AC.L1-3.1.1 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 requirement:

• CMMC Level 1 uses the label AC.L1-B.1.I. Section b(i) references the Federal Acquisition Regulation (FAR) clause 52.204-21.

• CMMC Level 2 uses the label AC.L2-3.1.1. AC references the access control domain. L2 references the applicability to CMMC Level 2.  3.1.1 references the original requirement number from NIST SP 800-171 (3.1.1).

Practice Statement

NIST incorporated fourteen security requirements from FIPS 200 into SP 800-171. Below is the original language from FIPS 200:

NIST abbreviated the language in SP 800-171 to:

Assessment Objective

NIST drafted SP 800-171A in 2017 to provide corresponding assessment procedures. These procedures involve applying assessment methods (examine, interview, test) to assessment objects. The assessor makes a determination for each objective. The assessor produces and/or compiles evidence to support the determination. A finding of “satisfied” indicates the implementation produces an acceptable result. A finding of “other than satisfied” indicates potential anomalies in the implementation.

The assessment objective for 3.1.1 contains six determination statements:

NIST SP 800-53 Crosswalk

Basic security requirements derived from FIPS 200 are more difficult to map to NIST SP 800-53. Table D-1 from NIST SP combines 3.1.1 with 3.1.2 and maps both to AC-2, AC-3, and AC-17.

We mapped the objectives from SP 800-171A to the closest SP 800-53A Rev 5 objectives. Then, we used NIST IR 8477 to define the relationship between the mapping from 800-171 to 800-53.

• AC.L1-3.1.1(a) is equal to AC-02d.01
• AC.L1-3.1.1(b) is a subset of IA-02[02] (strong)
• AC.L1-3.1.1(c) intersects with IA-03_ODP[01] (moderate)
• AC.L1-3.1.1(d) is equal to AC-02i.01
• AC.L1-3.1.1(e) is a subset o IA-02[02] (moderate)
• AC.L1-3.1.1(f) is equal to IA-03

Analysis of Discussion

The discussion for 3.1.1 orientates the focus onto account management. The crosswalk of objectives (a) and (d) support this orientation. The other objectives map better to the identification and authentication of users and devices.

Account Management

Control AC-2 from SP 800-53 is also named account management. Using AC-2 provides a more structured approach to implementing parts of 3.1.1. Limiting system access requires a list of authorized accounts (users and processes).  AC-2 provides more detail on how to create and maintain a list an authorized account list:

(a) Define the types of accounts allowed and prohibited.

Consider allowing the following account types:

• Individuals
• System
• Developer
• Service

Consider prohibiting the following account types:

• Shared
• Group
• Guest
• Anonymous
• Emergency
• Temporary

(b) Assign account managers for creating, maintaining, and terminating accounts.

(c) Establish specific conditions for group and role membership. A group is a collection of users whereas a role is a collection of permissions. Role-based access controls (RBAC) may simplify the management and review of access controls.

(d) Identify:

1. authorized users (or processes acting on their behalf),
2. group and role membership, and
3. access authorizations.

(e) Designate a person or role to authorize account creation requests.

(f) Establish a policy and procedures governing the account:

• Creation
• Enablement
• Modification
• Disablement
• Removal

(g) Continuously monitor the use of accounts.

(h) Specify the period of time to notify account managers when:

1. Accounts are no longer required
2. Termination or transfer of accounts
3. System usage or need-to-know changes for an individual

(i) Base authorized access to the system on:

1. A valid access authorization
2. Intended system usage, and
3. Any other required attributes

(j) Specifying time periods for reviewing accounts for compliance with requirements.

(k) Implementing a process for changing authenticators after removing individuals from a group.

(l) Align account management processes with termination and transfer processes.

Identification and Authentication (Organizational Users)

AC-2(d) references identifying processes, but the corresponding determination statement only references users. The CMMC Assessment Guide advises associating processes with the users who authorized them. The crosswalk identified IA-2 as the corresponding control from NIST SP 800-53. The discussion from IA-2 also advises identifying the authorizing individuals for processes.

Combining AC-2(d) and IA-2 provides clarity for meeting 3.1.1 (b):

• AC-2(d) identifying processes acting on behalf of authorized users
• IA-2 identify individuals who authorized each process

Device Identification and Authentication

The crosswalk indicates a relationship between 3.1.1 (c) and (f) and IA-3. The discussion from IA-3 advises defining the devices requiring identification. IA-3 also requires authentication of devices before establishing a connection to the system.

Identifier Management

IA-4 provides guidance on identifying individuals, groups, roles, services, or devices. The usernames of user accounts suffice as user identifiers. Common device identifiers include:

• MAC addresses
• IP addresses
• Device-unique tokens

IA-4 describes the process of managing system identifiers as follows:

1. Defining a role to authorize the assignment of identifiers
2. Selecting an identifier
3. Assigning the identifier
4. Preventing the reuse of identifiers for a defined period of time

DoD Criticality

The NIST SP 800-171 DoD Assessment Methodology Version 1.2.1 assigns a 5-point value to this practice. Failing this practice could lead to exploitation of the network or data exfiltration. CMMC section 170.21 removes limited deficiency eligibility for this practice.

Scope of Applicability

Appendix C within NIST SP 800-53 Rev 5 discusses three implementation approaches:

• (S) implemented by an information system through technical means
• (O) implemented by an individual through nontechnical means
• (O/S) implemented by individuals, a system, or a combination of the two

NIST defines the implementation of the corresponding SP 800-53 controls as:

• AC-2 as (O) organizational
• IA-2 as (O/S) organizational or system specific
• IA-3 as (S) system specific

The crosswalk suggests that 3.1.1 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 a, b, and c. It also lists screen shares as artifacts for objectives d, e, and f. We concluded a, b, and c are nontechnical, while d, e, and f are technical implementations.

NIST SP 800-53B states that controls may not apply to every component in the system. They only apply to components that provide or support the capabilities they address. The Microsoft Product Placement for CMMC identifies the following system components:

• Microsoft Entra ID (formerly Azure AD)
• Azure RBAC
• Intune/Microsoft Endpoint Manager
• Microsoft 365 Defender

Inheritance

Inheriting 3.1.1 is difficult since the authorization of users is an internal function. The PreVeil shared responsibility matrix identifies 3.1.1 as a shared responsibility.

Summit7 also lists the identification of authorized users as a client requirement.

Implementation

The Department of Defense categorizes 3.1.1 as a configuration. The first half requires identifying a list of authorized users, processes, and devices. AC-2 from SP 800-53 provides a more comprehensive roadmap for fulfilling this part. A simple Excel table could document authorized devices and accounts (user and process). Larger enterprises may use a human resources information system (HRIS) for managing accounts. An information technology asset management (ITAM) platform might manage authorized devices.

Configurations will limit system access to authorized users, processes, and devices. NIST SP 800-215 recommends the use of an enterprise-managed identity provider (IdP). We explore this based on the Microsoft and Google environments below.

Microsoft Environment

Configuration of Microsoft Entra ID (formerly Azure AD) can limit system access. Microsoft provides guidance that helps explain the potential steps for configuring access controls:

Setting up users may be as simple as adding or deleting users.

• How to add or delete Microsoft Entra ID users

Larger enterprises may require integration and synchronization.

• Integration with cloud-based HR applications
• Synchronize between on-premises and Microsoft Entra ID

Setting up device identities allows device-based Conditional Access policies.

• What is device identity in Microsoft Entra ID

Conditional Access policies block or grant access to resources.

• What is Conditional Access in Microsoft Entra ID
• Conditional Access requires managed device

Configuring authorizations to access applications.

• QuickStart: Register an app in the Microsoft identity platform
• Microsoft identity platform scopes, permissions, & consent
• Securing service principals in Microsoft Entra ID

Google Environment

ATX Defense published similar instructions for Google Workspace. ATX recommends using either Enterprise Plus, Education Standard, or Education Plus. These Google Workspace editions include Security Sandbox for malware detection in email attachments.

Configuration of Google Cloud Identity and Endpoint Management can limit system access. Google provides guidance that helps explain the potential steps for configuring access controls:

Using Google as the primary Identity Provider (IdP)

• Using Google as IdP and authoritative source
• Using Google as IdP with an HRIS as an authoritative source

Best Practices

• Best practices for planning accounts
• Planning the onboarding process

Creating a Cloud Identity or Google Workspace account

• Preparing your Google Workspace or Cloud Identity Account

Enroll authorized devices in Endpoint Management

• Enterprise Endpoint Management
• Require admin approval for device access
• Advanced Mobile Management
• Computer and laptop Endpoint verification

Combine conditions and values to define user or device access

• Creating Context-Aware access levels

Continuous Monitoring Tasks

Continuous monitoring strategies should verify that the controls produce the desired outcome(s).  The security requirement 3.1.1 has two desired outcomes:

• Identification of authorized users, processes, and devices
• Limiting system access to authorized users, processes, and devices

Start by creating and maintaining a list of authorized accounts. This list should include both user accounts and non-person entities. Each account should have documented authorization from an organization-defined delegate.

Conduct briefings with users before granting access to the system. Schedule annual briefings thereafter. Briefings help ensure users have appropriate access and privileges based on their responsibilities.

Review system access at the application layer monthly. Confirm accounts are active and have valid authorizations for accessing the system.

Update the system component inventory at least monthly. Define a strategy for identifying unauthorized devices accessing their system. This strategy may entail using automated tools or manually reviewing the component inventory.

Policy Statements

Account Management

• HR maintains a list of authorized users
• Requests to establish new accounts require appropriate authorization

• IT maintains a list of authorized process
• IT identifies individuals who authorized each process
• IT reviews and monitors authorized accounts
• IT revokes access for any terminated users

• IT disables accounts with 30 days of inactivity
• IT tracks and monitors role assignments for privileged user accounts
• IT disables or removes default accounts

Access Enforcement

• Job requirements form the basis of authorizations granting access to systems and data.  
• A centralized identity provider (IdP) limits system access to authorized users and processes
• An endpoint management solution limits system access to authorized devices

Mobile Devices

• Only approved, owned, and maintained mobile devices may connect to the system

System Component Inventory

• The IT department maintains an inventory of system assets that:
  
  • Reflects the current system
  • Includes all components within the authorization boundary
  • Includes granularity deemed necessary for tracking and reporting

Proposed Rev 3 Changes

The final public draft of SP 800-171 Rev 3  proposes aligning 3.1.1 with AC-2. To a lesser extent, NIST also proposed including enhancements from AC-2(3) and AC-2 (13) into 3.1.1. This proposed change would incorporate 21 assessment objectives and 1 organization-defined parameter. Incorporating AC-2 today will help you meet the proposed changes in revision 3.

Conclusion

Implementation of 3.1.1 is foundational to the access control domain. The applicability extends beyond enclaves and into any systems handling federal contract information. Organizations can meet half of the objectives through activities performed by individuals. Configuration of an identity provider (IdP) will help limit system access. Continuous monitoring activities should assess the implementation efficacy frequently.