I have a question for you. Do you know what is meant by the word “authorized” in the CMMC?
QUIZ
What would count as evidence for the cybersecurity objective “Authorized users are identified”?
A) Every account has a password
B) Account exists in directory
C) Note that CISO approved user
Did you choose an answer? Good! Now let’s test your logic.
Sometimes it can help to take the same words and apply them to a different situation. Which of these scenarios make sense?
Would Scenario A work for you?
Dick (the assessor), and Stan (the security officer) are standing outside the office building together during an assessment.
Dick says, “Who is authorized to be in the building?”
Stan says, “Let’s go see who is in the building.”
Scenario B?
Dick says, “Who is authorized to be in the building?”
Stan says, “You need a key to get in.”
Scenario C?
Dick says, “Who is authorized to be in the building?”
Stan says, “I have a list of names that I approved”
Do you see how these scenarios match the quiz choices, and are each common ways that people try to meet this requirement?
Here is what your peers chose
(note: the correct answer is “Note that CISO approved user” or “Other (comments)”)
My best attempt at explaining authorized
Authenticated vs Authorized
It seems like people mix up “Authenticated” with “Authorized”. Even very experienced cybersecurity pros do this.
Authorization means “Access privileges granted to a user, program, or process OR the act of granting those privileges.”
https://csrc.nist.gov/glossary/term/authorization
Authenticate means “Verifying the identity of a user, process, or device, often as a prerequisite to allowing access to resources in an information system.”
https://csrc.nist.gov/glossary/term/authenticate
Passwords are not the same as authorization
Having a password is != authorization. For example, I can log on to my Google account which authenticates that I’m the owner of that Google account. However, if I attempt to access someone else’s email, I will fail, because Google has not authorized me to access other people’s email.
Having access is not the same as authorization
Simply being in the directory is <> to authorization. Cyber-criminals love to create their own admin accounts once they’ve hacked a business. Do we really want to say that a badguy’s account is authorized simply because it exists?
Note that my certainty level for the directory statement above is only about 70%. This is because cybersecurity is both a manual and a technical process. Being in the directory means that the account meets technical requirements for authorization: “access privileges granted to a user”, and if a user presented their username/password, they would be authorized access to the system using technical means. But it doesn’t improve security to simply point at the as-is state without any review.
My ideal evidence for how to show that “only authorized ________ can _________”
When I see the word “authorized” in the CMMC objectives, I always want to be able to trace the statement back to an original authorization step.
So if the statement is that “only authorized users can access the system”, I want to see both that the system is limited to <list of users> by verifying their account has the right to access the system and that there was an act of granting those privileges at some point in the past.
The difference between “what is authorized” and “what should be”
What about situations where the account was never disabled after the user left the company? Is the account authorized or not?
Does evaluation of “authorized” go to the depth of “what should be”?
We have three potential levels of goodness.
- What is
- What we decided
- What it should be
“What is” comes to the example of an account existing in a directory. It doesn’t verify that anyone reviewed or approved the account.
“What we decided” is the evidence Jeff Dalton mentions later in this article: a record showing that a certain level of access was reviewed and approved, and the actual account matching that.
“What it should be” is a situation where your records are not correct due to changing conditions.
If someone left the company but a process was never initiated to let the IT department know, then I think their account still counts as authorized because the original decision (and record) still stands until replaced, but the company is failing a different cybersecurity requirement.
For example, the requirement to update access permissions when users change roles should be what fails in this example.
I asked cybersecurity professionals on LinkedIn to chime in with their thoughts on this question…
As a cybersecurity assessor, what evidence do you want to see that “only authorized _____________ can _____________” ?
Here were their responses.
Jeff Baldwin, CMMC Provisional Instructor
Out of the three options, “Note that CISO approved user” is the best one. Like discussed, an unauthorized account can exist within a directory and just having a password does not mean the account is authorized. Ideally, account authorization should be a step of account creation, was this account requested and subsequently approved by CIO/CISO or their designee?
Now caveating that a bit. If it were a L1 assessment and there are a very few amount of users, where looking at the directory and personally knowing everyone on the list and having the auditing controls in place to capture new account creation, then it becomes more debatable. So, for me, system context of the practice is another element to consider. What is your process to manage user accounts, how are they approved, how are they decommissioned, what happens if an unauthorized account is found when reviewing the directory? Is the scale of the operation small enough where a directory alone is sufficient, or is more maturity needed due to the complexity and scale of the environment? So, L1 is debatable but L3 is where not having the policy and procedures documented and followed is where this becomes unsatisfactory.
Vince Scott, founder Defense Cybersecurity Group
In reference to the poll results showing many people selecting answers unrelated to authorized
“What then does this mean for the conduct of assessments relative to the AC CMMC requirements? And should that approach then be standardized/published? My thought is that 90% of companies are using the fact of an account as their authorized list without other documentation. Larger more advanced companies will be able to point to a ticketing system but in general SMB’s won’t. If some assessors hold to the standard of needing other documentation for authorized and some assessors do not require that, this will cause problems. Of course, that is probably a giant can of worms across so many controls.”
Matthew Titcombe, Provisional Assessor
“This is a straightforward paradigm I see many getting mixed up with the verbs authorize, identify, and authenticate.
Authorize is primarily an Organizationally implemented mechanism (O) per NIST SP 800-53 Rev 5, APPENDIX C CONTROL SUMMARIES.
Identify is normally a hybrid mechanism “implemented by an organization, a system, or a combination of the two” (O/S) For example, in the onboarding process, everything starts with identifying who we are talking about; then authorizing access; and back to system level identification (IA.1.076).
Authentication happens as a system (S) mechanism.
If you follow the AO thread, AC.1.001[a] (O) ==> AC.1.002[a] (O) ==> CM magic in the middle (O/S) ==> IA.1.076[a] system users are identified (S) ==> IA.1.077[a] the identity of each user is authenticated or verified as a prerequisite to system access (S)
The AC AOs can be replaced by the PE AOs where a physical access control system (e.g., RFIOD badge system) is used.”
Jason Sproesser, Cyber Security Assurance Manager
In reference to 60% of the poll responses being wrong
“60% facing “expectations not met-insufficient supporting evidence“
Why looking at the active user list is the wrong answer
Authorized implies permission was given . An Unauthorized user can show up in a directory in a case where someone was terminated but no access was removed or worse .
“A note ( I’m hoping you meant some sort of consistent document used for all access ) from authorizing personnel ( CISO in this case ) deems this person has been given permission to access whatever asset is in question . However , this is still not enough. The authorization is complementary evidence to the identification of the users ; which would have to be accomplished utilizing output from the directory or self maintained roster of users . A process in place to VERIFY the roster in a defined frequency (policy ) which is carried out as specified then would validate the output (roster ) used to identify who is authorized for access .”
The policy (maturity) side of authorization
“Policy and procedures would dictate those authorizing parties .
Policy says CISO is only person permitted to provide authorization .
On boarding document confirm [John Smith] is authorized with CISO signature to be added to Xyz role in AD under user name [JSmith].
AD permissions should be defined based on AC groupings .
Then your matrix is compared against whatever referencing documentation you have that details the list of active users .The organization has now identified authorized users . And the parties who hold the “A” RACI can then speak with confidence that they are able to positively identify all users on the system”
Why CMMC asks companies to identify authorized users
“The goal is to establish awareness in management of who should be on the system , why they should be on it , and what they are supposed to be doing when connected . By institutionalizing practices of verification , you are doing your due diligence to verify that unauthorized access (intentional or not ) is not taking place .”
In reference to accounts having outdated permissions or still being active after the user has left the company
“I am someone who once was tasked with cleaning up a mess with a very similar description to this. This is lack of managerial process in change of status/ termination AS WELL as a continued practice to validate access / confirm permissions .
Sure , you make sure the people with access are validated to have continued access , but how granular is your validation process ?
Most people are committed to “joe has access , I authorized joe , he is good to go “ when in reality , it should be “joe is listed as an authorized user , I authorized joe for access to ________, these accesses also match the verification document used at account creation “
Alex Imani, IT Advisory
What evidence would show which users are authorized
“1. User identified by a directory or user list
2. Each user is backed by a documented (traceable) access request form, approved by appropriate parties per the Access Control Policy
3. Core user and admin listings are reviewed by information or system owners monthly/quarterly for on-going appropriateness”
Chris Hughes, CISO
When employees leave the company (becoming unauthorized), their accounts can still exist in the directory
“Even more interesting, when it comes to systems, how are you handling de-provisioning access upon an employees departure or change of role/responsibility? Crickets and piles of orphan accounts, or accounts that have slowly accrued large amounts of access over the years.”
Zero trust concepts relating to authorization logic (to supplement manual authorization activities)
“Also taking this all a step further towards zero trust, not just a name and associated access but items like geographic location, device compliance posture, etc all should be factored in to level of access dynamically granted, if at all.”
Joy Beland, CMMC Provisional Instructor
Identified (another key concept!) and the use of policy for authorizing categories of things
“I’m thinking the word “identified” might need the focus here. I’d like to see who all has access to any given system or data that is in scope and compare that with the list of users (and policy) that are authorized to handle that data. In my MSP days, when taking on a new client, I would generate a report on sensitive data folders that showed every user group and process acting on behalf of users able to access that folder. I would review that report with the owner of the data and they would be shocked and often horrified at who had access to it that shouldn’t.”
Jeff Dalton, CMMC-AB, CMMI Lead Appraiser
In reference to evidence that would show authorization
“Matrix of authorized users with description of their access, validity dates, and manager that approved it.”
Conclusion
The word “Authorized” occurs 51 times in the practice statements and assessment objectives of the CMMC Level 3 assessment guide.
Authorized is a key concept. Not just about user accounts. Not just AC.1.001
In order to achieve high quality, consistent assessments and a good experience for the Defense Industrial Base, at the very least we need to have a common understanding of the vocabulary.
This of course applies to all cybersecurity frameworks, not just CMMC or #800-171 since making sure that only authorized things can do _____ is core to cybersecurity.
I hope this article and the insights provided by cybersecurity experts, assessors, and instructors in has been enlightening to you. And if you are planning to re-write your system security plan tomorrow based on what you learned here, at least know that you are in good company.
Please sign up for our newsletter for articles, news, and commentary like this!
V. Amira Armond (CISSP, CISA, PMP, MBA) is a computer systems architect, cyber-security consultant, and owner of the C3PAO candidate Kieri Solutions LLC. She specializes in CMMC preparation and DFARS 252.204-7012 compliance, and designing secure and resilient enterprise systems for private sector and the DoD. She is the chief editor for cmmcaudit.org, a public resource for news and informational articles about the Cybersecurity Maturity Model Certification.