By Christopher Moschella, CPA, CISA, Risk Advisory Services Senior Manager
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.
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.L1-3.5.2 |
|---|
| Practice: Authenticate (or verify) the identities of those users, processes, or devices, as a prerequisite to allowing access to organizational information systems. |
| Assessment Objectives |
|---|
| Determine if: |
| [a] the identity of each user is authenticated or verified as a prerequisite to system access; |
| [b] the identity of each process acting on behalf of a user is authenticated or verified as a prerequisite to system access; and |
| [c] the identity of each device accessing or connecting to the system is authenticated or verified as a prerequisite to system access. |
CMMC Maturity Level (ML) 1 Practices: Overview of IA.L1-3.5.2
This practice closely tied to IA.L1-3.5.1, which identifies requirements around having unique identifiers, such as userIds, for users, processes acting on behalf of users, and devices. By comparison, this practice requires authenticators to go along with those identifiers.
Authenticators can vary, though in most cases they will be passwords. Other examples can include key cards, API keys, multi-factor authentication (MFA).
Taken together, IA.L1-3.5.1 and IA.L1-3.5.2, in most circumstances, simply require that users have unique ids and passwords. With more complex systems and networks, the requirements can become equally complex.
To comply with this requirement, organizations should review the details of NIST SP 800-63-3, Digital Identity Guidelines, which provides best practices related to passwords and authenticators. Organizations should be prepared to demonstrate that their systems require the use of hard to guess passwords, and we would recommend, wherever possible, MFA. Although MFA is not strictly a requirement of this practice, it is a requirement for IA.3.083, an ML-3 practice, and it can help reduce authentication risk of systems that you might only have limited ability to control passwords.
Conclusion
IA.L1-3.5.2 requires passwords (and other authenticators as appropriate) to go along with the userIds (and other identifiers) required in IA.L1-3.5.1. There is wide ranging guidance regarding passwords, however, we recommend organizations try to adhere to the recommendations in NIST SP 800-63-3, Digital Identity Guidelines, to help ensure you are complying with the same standards to be used by CMMC assessors. Additionally, many organizations may find themselves tied to systems with limited password configurability, and for that reason, we highly recommend MFA as a way to buttress your compliance.
Lastly, we recommend organizations define their corporate password requirements into a policy, even if you only need to meet Maturity Level 1 requirements. There is no one-size-fits-all password policy. Nuances in technology platforms, availability of MFA, and even the available keys on a device to enter a password, can impact an organizations password policy. The policy should outline password requirements around length, complexity, MFA, history, changes, invalid attempts, etc. If there are instances where your organization cannot comply with its own requirements, then it should be documented and justified. For example, if your organization requires upper, lower, numbers, and special characters, but a cloud product you use employs an algorithmic strength checker, such as the well-respected zxcvbn library, that does not fit neatly into common definitions of “complexity.” Without a password policy, your assessor will need to exercise judgement to determine if your password rules are sufficient in each system. By documenting a clear policy, your assessor will have a clear set of requirements against which to test your systems.
Interested in learning more about CMMC services for your defense contracts? Contact us. We are here to help.
Understanding the DoD’s Cybersecurity Maturity Model Certification (CMMC)
About the Author
Christopher Moschella, CPA, CISA, Risk Advisory Services Senior Manager
Chris is a Senior Manager in Keiter’s Risk Advisory Services. Chris has a strong combination of IT skills, which range from IT audit and internal control assessments, including general computer controls and application controls, to full stack web development. Most recently, Chris developed a Cybersecurity web application that assesses an organization’s resistance to social engineering attacks. Chris shares his cybersecurity insights on our blog.
More Insights from Christopher MoschellaThe 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.
