%201.png)
%201.png)
Identifying accounts and devices is foundational to creating a secure and accountable system. Accounts may have assignments to people and non-person entities. Establishing identity management policies and procedures supports the authorization and auditing functions. Identification of devices supports configuration management, maintenance, and system communications protection practices.
This blog will discuss the following topics around 3.5.1:
NIST introduced special publication (SP) 800-171 in 2015. NIST retained the identification number of 3.5.1 through the first and second revisions. NIST SP 800-171 Revision 3 has changed this requirement's number to 03.05.01.
The cybersecurity maturity model certification (CMMC) rule will verify SP 800-171 Rev 2. CMMC 1.02 numbered this practice IA.1.076 then AC.L1-3.5.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 practice:
NIST derived SP 800-171 basic security requirements from FIPS 200. Below is the original language from FIPS 200:
NIST abbreviated the language for 3.1.22 in SP 800-171 to:
NIST provides assessment procedures for the corresponding practices within SP 800-171A. Procedures apply assessment methods to assessment objects. These methods include examining artifacts, interviewing personnel, and testing mechanisms. The assessor evaluates each part of the practice to produce a finding. A “satisfied” finding indicates an acceptable implementation. A finding of “other than satisfied” indicates one or more anomalies.
The assessment objectives for 3.5.1 contains three parts:
Appendix D within SP 800-171 maps requirements to SP 800-53 Rev 4 controls. This mapping relates 3.5.1 and 3.5.2 to IA-2, IA-3 and IA-5. Our analysis of the discussion also uncovered a relationship with IA-4.
We mapped these three 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 CMMC Assessment Guide discussion includes supplemental guidance from SP 800-53 Rev 4.
The CMMC discussion draws on supplemental guidance from IA-4. Here are the first three sentences of the CMMC discussion:
Common device identifiers include:
Management of individual identifiers is not applicable to shared system accounts. Individual identifiers may include user names associated with system accounts.
The fifth sentence also references this supplement guidance:
This practice addresses individual identifiers that may not have associations with system accounts.
The fourth sentence is synonymous to a sentence within the IA-2 supplemental guidance.
Organizations may mandate unique identification of individuals in group accounts. This enables detailed accountability of individual activity.
The sixth sentence is indistinguishable to a sentence within the IA-3 supplemental guidance.
Organizational may identify devices by type, by device, or by a combination of type/device.
The CMMC Assessment Guide also provides a practical guide in the further discussion. This section simplifies the concept by including actionable steps:
Assign unique identifiers (e.g., user names) to all users and processes that the system. Authorized devices also should have unique identifiers. Unique identifiers can be simple. For example, a SW001 could refer to a network switch, SW002 could refer to a different network switch.
This practice provides a trusted identity that supports the access control mechanisms.
The CMMC Assessment Guide also provides an example:
Ensure all employees working on a project can access important information about it. Because this work may contain FCI, prevent access for anyone not working on that project. You assign each employee with a unique user ID, which they use to log into the system [a].
The NIST SP 800-171 DoD Assessment Methodology Version 1.2.1 assigns a 5-point value to this practice. Failing this practice may lead to exploitation of the network or data exfiltration. CMMC section 170.21(ii) removes this practice's eligibility for a limited deficiency. This practice aligns to the basic cybersecurity safeguards requirements of 52.204-21.
NIST SP 800-53 Rev 5 appendix C discusses three implementation approaches:
NIST defines the implementation of the corresponding SP 800-53 controls as:
The crosswalk suggests that 3.5.1 has both technical and administrative components. The Defense Contract Management Agency (DCMA) published guidance for assessing SP 800-171. The DCMA Guide identifies documents as the relevant evidence for parts (a), (b) and (c). We concluded all parts of this practice are technical.
You may have noticed the assessment objectives bear strong resemblance to the first three parts of 3.1.1:
Identification within the access control domain enables authorization. Authorization refers to granting (or the act of granting) access privileges. This implies there was consideration and approval when granting privilege or access. As we discussed in 3.1.1, organizations should document these authorizations. Authorizing is an administrative control reliant on policy decisions, rules, and procedures.
Identification within the access control domain enables authentication. Authentication refers to verifying the identity of a user, process, or device. This is a prerequisite to allowing access to resources within an information system. Authentication is a technical mechanism supporting security measures and verifying identities.
You may inherit this practice. An external service provider may manage the mechanism for identification and authentication. Both the following shared responsibility matrices show this as an inherited practice:
You may share some responsibility for this practice. External service providers may not manage the identification and authentication mechanism. The example below shows a shared responsibility for this practice:
The Department of Defense categorizes 3.5.1 as a configuration. Part (a) requires a standard to identify users. Common examples of user identifiers include name, card number, and user ID. Maintaining a list of system accounts will help meet this part of the practice. Organizations should also define procedures addressing user identification and identity proofing. NIST SP 800-63A focuses on the enrollment and verification of a digital identity. The figure below outlines the basic flow for identity proofing and enrollment.
Let’s review some key NIST terms:
Digital identity is the unique representation of a subject.
Identity proofing is the process of verifying a subject’s identity.
Applicant is the subject who has yet to complete the identity proofing process.
Subscriber or claimant is a subject who has completed the proofing process.
Relying party (RP) is an entity that relies on the validity of the claimant’s identity.
Identification is central to the process of associating a subscriber with their activity. The identity proofing process asserts one of three Identity Assurance Levels (IAL):
Identity Assurance Level 1 (AAL1) does not link the applicant to a real-life identity. The CSP should treat any attributes provided as self-asserted. These attributes are neither validated or verified.
Identity Assurance Level 2 (AAL2) requires evidence to support the identity's existence. IAL2 requires either remote or a physical presence for identity proofing.
Identity Assurance Level 3 (AAL3) requires a physical presence for identity proofing. An authorized and trained CSP representative must verify identifying attributes.
NIST SP 800-63a provides an example of the identity proofing process:
You may or may not have processes acting on behalf of users (b). Processes acting on behalf of users are not processes being run by a user (applications like Word, Excel, etc.). Processes are accounts that act like people but are not people. A classic example of a process acting on behalf of a user is a backup service. Establish a standard for authenticating process accounts.
Part (c) requires a standard to identify devices. Common examples of device identifiers include:
You’ll need a repository of identities and a system to authenticate them. A Credential Service Provider (CSP) is synonymous with identity provider (IdP). These systems create, manage, and store digital identities. Common examples include:
Microsoft provides guidance implementing this practice using Entra ID and Intune. At a high level, Microsoft has three types of identities:
Entra ID
Microsoft Intune
ATX Defense published similar instructions for Google Workspace.
Google Workspace
Endpoint Management
Identification
A continuous monitoring plan should verify that controls produce the desired outcome(s). The practice 3.5.1 has one desired outcome:
Both users (persons) and processes (non-persons) have accounts assigned to them. Start by creating and maintaining a list of authorized accounts. Maintaining an authorized list may include the following activities:
Updating the system component inventory is a good way to verify device identification. The FedRAMP moderate standard specifies monthly updates or whenever components change. Organizations may leverage automated tools to perform this task more often.
NIST SP 800-171 Rev 3 aligns 03.05.01 with IA-02 and IA-11 from SP 800-53 Rev 5. There are now five parts to 03.05.01:
The crosswalk below shows the mapping of these requirements back to related parts of 3.5.1 from Revision 2:
Identity management starts with an organization policy supported by defined procedures. Use an identity provider to create, manage, and store digital identities. Keep the identities of user and system accounts as well as devices updated. Implementing identity controls contributes to creating a secure, accountable and efficient information system.
