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.
The following blog explores in detail the first security requirement 3.1.1 and covers:
Table of Contents
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:
Image Source: FIPS 200
NIST abbreviated the language in SP 800-171 to:
Image Source: NIST SP 800-171
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:
Image Source: NIST SP 800-171A
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:
authorized users (or processes acting on their behalf),
group and role membership, and
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:
Accounts are no longer required
Termination or transfer of accounts
System usage or need-to-know changes for an individual
(i) Base authorized access to the system on:
A valid access authorization
Intended system usage, and
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.
Image Source: NIST SP 800-53 Rev 5
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.
Image Source: NIST SP 800-53 Rev 5
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:
Defining a role to authorize the assignment of identifiers
Selecting an identifier
Assigning the identifier
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.
Image Source: PreVeil CMMC-ComplyingDoD-Jan2024v17-final-1.pdf
Summit7 also lists the identification of authorized users as a client requirement.
Image Source: Summit7 Shared Responsibility Matrix
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.
Larger enterprises may require integration and synchronization.
Setting up device identities allows device-based Conditional Access policies.
Conditional Access policies block or grant access to resources.
Configuring authorizations to access applications.
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)
Best Practices
Creating a Cloud Identity or Google Workspace account
Enroll authorized devices in Endpoint Management
Combine conditions and values to define user or device access
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
Image Source: NIST SP 800-171 Rev 3 Crosswalk Calculator
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.
