%201.png)
%201.png)
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-53A Rev 5 objectives. We also used NIST IR 8477 to define the nature and strength of the relationships. The findings indicated that:
AC.L2-3.1.2(a) is equal to AC-02d.03[01]
Specify access authorizations for each account;
AC.L2-3.1.2(b) is intersects with AC-03 (moderate strength)
Enforce approved authorizations for logical access to information and system resources. Enforcement is by applicable access control policies.
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:
Inheriting 3.1.2 is possible. External service providers may define and enforce access control policies. The PreVeil shared responsibility matrix identifies 3.1.2 as an inherited requirement.
Keep in mind the scope of any shared responsibility matrix. PreVeil satisfies the requirement as long as the CUI data remains in PreVeil. Inheritance does not apply to other systems or endpoints processing or storing CUI.
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.
Account Management
Access Enforcement
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.
