If practice 3.1.1 is the "front door" (authentication), NIST SP 800-171 Practice 3.1.2 defines what you can do once inside (authorization). It mandates that organizations control the functions and transactions authorized users are permitted to perform on a system.
With a 5-point value in DoD assessments, failure here is critical—it's the primary gap
If 3.1.1 authorizes access to the system, 3.1.2 authorizes permissions within the system. The rules of chess, for example, limit the types of functions allowed for each piece. Access control policies restrict the types of functions authorized for each subject. These policies will dictate what a subject can or cannot do to an object or a resource.
This blog will discuss the following topics around 3.1.2:
NIST SP 800-171 dates back to June of 2015. NIST retained the identification number of 3.1.2 through the first and second revisions. NIST SP 800-171 Revision 3 has changed this requirement's number to 03.01.02.
The proposed cybersecurity maturity model certification (CMMC) rule verifies SP 800-171 Rev 2. CMMC 1.02 numbered this practice AC.1.002 then AC.L1-3.1.2 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:
NIST SP 800-171 incorporated fourteen security requirements from FIPS 200. Below is the original language of this requirement from FIPS 200:
NIST abbreviated the language in SP 800-171 to:
NIST published SP 800-171A in 2017 to provide corresponding assessment procedures. These procedures apply assessment methods (examine, interview, test) to assessment objects. The assessor evaluates each part. The assessor produces and compiles evidence to support the finding. A “satisfied” finding indicates an acceptable result. A finding of “other than satisfied” indicates implementation anomalies.
The assessment objectives for 3.1.2 contain two determination statements:
We mapped these two objectives to the closest SP 800-53 Rev 5 control parts. We also used NIST IR 8477 to define the nature and strength of the relationships. The findings indicated that:
The discussion for 3.1.2 combines parts of account management and access enforcement. Part of account management includes defining access privileges or other attributes. Account enforcement limits access based on defined authorizations.
Part (a) of 3.1.2 requires organizations to define access authorizations. NIST incorporated some of the AC-2 supplemental guidance into the 3.1.2 discussion:
The Level 2 CMMC Assessment Guide also provides a further discussion section.
Limit users to the permitted information systems, roles, or applications. Base permissions on needs for their roles and responsibilities. Limit access to applications and data based on the users’ roles and responsibilities. Common types of assigned user functions are create, read, update, and delete.
The further discussion does not trace back to SP 800-53. NIST may have derived part of the discussion from the NIST Handbook 162. NIST withdrew this handbook in September of 2022. They identify the superseding publication as NIST SP 800-171A.
Both texts include the phrase “permitted to use”. The handbook uses the term to describe user authorizations for parts of the system. The CMMC guide uses it about information systems, roles or applications.
Both texts recommend using “roles” as a means to categorize authorizations. Both recommend basing authorizations on needs or a need-to-know.
Handbook 162 does not reference the common types of assigned user functions.
Create, read, update, and delete (CRUD) are the four operations a subject may perform on an object. This concept dates back to the Trusted Computer System Evaluation Criteria. Industry veterans often refer to this as the “Orange Book”. This publication detailed fundamental computer security requirements for the Department of Defense.
Part (b) focuses on enforcing access controls. This resembles AC-3 but the discussion does not include supplemental guidance from AC-3:
This supplemental guidance defines the primary components of access control policies. Subjects (active entities) include both users and processes acting on behalf of users. The objects (passive entities) include devices, files, records, and domains. It also identifies several levels of potential enforcement. Systems contain an increasing number of applications and services. Architecture design may limit the scope of coverage of access control mechanisms. Access control mechanisms may enforce policies at the system, application, or service level.
The NIST SP 800-171 DoD Assessment Methodology Version 1.2.1 assigned a 5-point value to this practice. Failing to enforce access controls could lead to network exploitation or data exfiltration. CMMC section 170.21 removes eligibility for limited deficiency in this practice.
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.2 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 part (a). Part (b) lists a screen share as the relevant evidence. We concluded part (a) is nontechnical and part (b) is a technical implementation.
Security requirements may not apply to every component of the system. They only apply to components that provide or support the capabilities they address. The Microsoft Product Placement for CMMC identifies the following primary services:
Microsoft Azure
Microsoft’s customer responsibility matrix indicates that AC-02(d) is a shared control.
Customers are responsible for specifying access privileges using their identity management infrastructure. These users utilize the customer AD infrastructure to apply permissions to that user's session. Customers communicate the associated permissions to Entra ID via certificate-based authentication.
Amazon AWS
Amazon’s customer responsibility matrix indicates that AC.L2-3.1.2 is a shared control.
Users interact with AWS Services using AWS defined APIs.
AWS IAM authorizes the users and services before allowing access to respective APIs. Customers can use AWS IAM roles and policies to implement customer specific access control requirements, which includes the privileged commands and actions that can be executed remotely.
Google Workspace
Google’s CMMC Implementation Guide indicates that AC.L2-3.1.2 is a shared control.
When configured correctly, the following key service(s) in Google Cloud Console may be used to support this control:
OS Login - Control the level of function permitted within a Linux VM SSH session based on IAM authorization.
The Department of Defense categorizes 3.1.2 as a configuration. The CMMC assessment guide provides an example using a role-based access control policy. Each role limits whether an employee has read access or create/read/delete/update access. The supporting Microsoft documentation provides instructions on how to configure RBAC. Using RBAC is an example of defining access privileges by the type of account.
The Microsoft documentation also references attribute-based access control (ABAC). ABAC policies may replace or supplement RBAC. ABAC uses defined attributes to match users with the resources they need to do a job. Remember from the discussion:
Other attributes include restrictions on time of day, day of week, and point of origin.
These are great examples of environmental specifics used within ABAC policies. ABAC can also use non-environmental attributes related to the subject or object. ABAC allows for more flexibility and enforcement than RBAC. As a trade-off, it also takes more time, effort, and resources to implement.
Configuration of Microsoft Entra ID (Azure AD) can limit system access. Microsoft provides guidance that helps explain the potential steps for configuring access controls:
Set up rules-based access control (RBAC)
Set up attribute-based access control (ABAC)
Configure groups for role assignment
ATX Defense published similar instructions for Google Workspace. ATX recommends classifying users based on roles and configuring context-aware access levels.
Classify users based on roles:
Enforce what resources users can access
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 strategies verify that controls produce the desired outcome(s). The security requirement 3.1.2 has two desired outcomes:
Start by creating and maintaining a list of authorized accounts. This list should include both user accounts and non-person entities. Assigning roles and or attributes ties account membership to authorized transactions and functions. Each account should have documented authorization from an organization-defined delegate.
Conduct quarterly reviews of account types. Ensure authorizations match intended system usage. Only use temporary or emergency accounts only for a short period. Remove any shared, group, anonymous, or guest accounts.
Conduct annual system access briefings to ensure access aligns with approvals. As roles and responsibilities change, briefings help enforce the principle of least privilege.
Several statements with the CMMC Access Control Policy template align to 3.1.2:
Access Enforcement
System access is granted based on an employee's role and business unit, ensuring users only possess the privileges necessary for their tasks. An internal user's supervisor must validate the need for access to perform their duties.
Logical and physical access authorizations (including system accounts and facility entry badges) are assigned to security groups or roles. Users will be added to and removed from these roles as their responsibilities change to ensure they only possess the privileges necessary for their current tasks.
Resources may be assigned to multiple groups with varying levels of rights (e.g., Read-Only vs. Modify) to strictly enforce the principle of least privilege.
Access permissions for both user accounts and application service accounts are configured at a granular level to ensure entities only possess the specific capabilities necessary for their function.
Rights shall be distinguished between Read, Write, Modify, Delete, and Execute. Users requiring only "Read" access must not be granted "Write" or "Delete" privileges.
Access rights granted to external applications and service accounts (e.g., via APIs) are strictly limited to the specific data sets and functions required for interoperability. Wildcard or "full admin" access for service accounts is prohibited unless explicitly justified.
NIST SP 800-171 Rev 3 aligns 3.1.2 with AC-3. There are still two parts to this requirement. Part [01] requires logical access enforcement to controlled unclassified information (CUI). Part [02] requires logical access enforcement to system resources. These updated requirements incorporate both current parts of 3.1.2. NIST withdrew the related requirement 3.13.3. That capability applies to both parts of 03.01.02.
Organizations should define and enforce access controls within systems. This involves permitting or denying subject access to system objects. This is often accomplished using attribute and or role-based access control mechanisms. These rules also govern authorized operations that subjects can perform on system objectives. Access controls help protect system resources and data against inappropriate or undesired access.
