Note: Important Change as of November 2021
The Department of Defense announced a major overhaul to the Cybersecurity Maturity Model Certification (CMMC) program. No new contracts will feature CMMC compliance requirements until the Department completes its rulemaking process for CMMC 2.0. Read our summary of the changes, Goodbye CMMC 1.0, Hello CMMC 2.0. For more detailed information, visit the CMMC website.
Keiter’s Cybersecurity team will continue to monitor the rollout of the CMMC program and update you on new information and changing requirements for DoD contractors.
CMMC Maturity Level (ML) 1 Practices: Overview of IA.1.076
Editor’s note: This article is one of a series of articles about the CMMC Maturity Level (ML) 1 Practices. In these articles we dive in to the CMMC Practice Guides and provide our thoughts about the practices and what contractors should consider. The CMMC ecosystem is still developing, and as those developments occur, we will update these articles accordingly. As such, we hope that these articles represent an evergreen CMMC ML-1 resource.
|Practice Number: IA.1.076|
|Practice: Identify information system users, processes acting on behalf of users, or devices.|
|[a] system users are identified;|
|[b] processes acting on behalf of users are identified; and|
|[c] devices accessing the system are identified.|
(source: CMMC ML-1 Assessment Guide)
Overview of IA.1.076: Identification and Authentication
This is the first of two Level 1 requirements related to Identification and Authentication. The Assessment Objectives are closely related to the objectives in AC.1.001, which focuses on the procedures to authorize access. IA.1.076, however, focuses on ensuring system functions are performed unique IDs.
Throughout the CMMC, we see access related practices repeatedly divided into objectives related to users (people), processes, and devices. This practice is no different, and as such, the only difference between the three assessment objectives here are that they apply separately to users (people), processes, and devices.
In that regard, this practice simply requires that when users, processes, and devices access a network or system, that they do so with a unique identifier. For most systems that a user logs into, this will typically be a userId that is specific to that user. This also means that users should not be assigned shared accounts. Shared accounts may be convenient, but they also impair non-repudiation and audit trails.
|Key to Success|
|To meet this objective, organizations should verify their ability to generate lists of identifiers for all in-scope systems and networks.
The obvious source of identifiers are the userId’s that employees use to login to the company network and in-scope applications.
However, assessors may also examine service/system accounts used by processes and systems and device identifiers used by printers, switches, etc. So, organizations should consider these identifiers as well.
Frequently, systems need to interact with each other, and when they do, they too should have a unique identifier to authenticate requests. This could also be a userId if a system needs to perform a function, such as an application using a MS Active Directory userId to write to a SQL Server database, run a PowerShell script on a network, or save a file to a network folder. It could also use an API key or other unique identifiers to authenticate requests.
The CMMC Assessment Guide also points out that for network devices, the identifier could be a MAC address, IP address, or some other device specific identifier. An example of a device accessing a system could be a multi-function printer that needs to be able to save files to a network location or email files to another user. It should have a unique userId from which it performs these tasks. The CMMC Assessment Guide goes as far as to indicate that network switches should have unique identifiers, which is notable not because it is particularly difficult, but because it is a clear indication of how expansive the regulators consider the scope of CMMC to be.
Lastly, organizations should be able to demonstrate evidence that they comply with these objectives, such as user lists, device lists (with the device Id), or system/service account lists. We recommend companies maintain the ability to generate lists of these identifiers for all in-scope systems and supporting networks.
To look at this practice casually, one might be inclined to think it is a throwaway item that any organization would naturally comply with. “Of course our users have IDs!” But there is more to it than that. IA.1.076 builds on the access control practices by requiring not only users but also, processes acting on behalf of users, and devices be assigned identifiers. With identifiers, interactions with systems and networks can be logged, creating an audit trail that is important for accountability as well as investigating security events
About the Author
The information contained within this article is provided for informational purposes only and is current as of the date published. Online readers are advised not to act upon this information without seeking the service of a professional accountant, as this article is not a substitute for obtaining accounting, tax, or financial advice from a professional accountant.