CMMC Weekly Series #2
Posted on April 3, 2020 by Robert Goyette
Identification and Authentication
This article will talk about Identification and Authentication, one of the seventeen domains in the Cybersecurity Maturity Model Certification (CMMC). Each domain in the Cybersecurity Maturity Model is broken up into processes, capabilities and practices as seen in Figure 1. For those familiar with NIST or RMF work, domains are the rough equivalent to control families. In this article we will focus on the capability and practices for the Identification and Authentication domain.
The capability or capabilities of a domain can be thought of as the Domain’s purpose or goal and the practices all lend towards accomplishing that goal. This capability, or goal, is important to remember when implementing the practices as you must implement a solution that not only obeys the letter of the law but also the spirit of the law.
The capability for the Identification and Authentication domain is to “Grant access to authenticated entities.”
CMMC allows for five levels of cyber maturity, with different levels requiring different security practices. The table below shows the 11 security practices of the Identification and Authentication domain mapped to the applicable levels.
Below is an overview of these practices and examples of how one might apply these practices in a Windows Active Directory Environment. As you will see, some of these practices are very easy to implement while others require considerable time and effort or may even require a third-party paid solution. It should be noted that the examples below are not an exhaustive list. You may need to apply some of these settings in places other than Windows Active Directory.
A Quick Overview of the Practices
Level 1 Practices: Identification and Authentication of Users
The first practice (IA.1.076) deals with identification which is important because it enables an organization to allow and restrict different amounts of access for different users. Identification can never safely be used on its own because users or malicious actors can impersonate other users. That is where the second practice, (IA.1.077) dealing with authentication, comes into the picture. Authentication requires a user verify his identify by giving some sort of proof of identification, often a password. Since this password is being used to verify the user’s identity the password must be known by only that user. Anyone else knowing the user’s password would be able to impersonate that user.
Applying These Practices to Windows Active Directory
IA.1.076: To fulfill this in a Windows environment would be as simple as creating usernames for all users. If you create these usernames using employee names it also will also give the added benefit of describing the identity of the username. The username robert.goyette would be the username used for Robert Goyette.
IA.1.077: The easiest way to fulfill the authentication requirement, is to use passwords. Passwords are used by default in Windows. It is important here to remember that different users should have different passwords and should be keeping their passwords a secret from each other.
Level 2 Practices: Strength and Storage of Passwords
The level 2 practices all deal with making passwords both strong and secure. The first setting (IA.2.078) deals with the objective strength of the password. The setting not only demands that there be certain password complexity requirements but also that when a user changes their password the new password must be significantly different than the current password. The second setting (IA.2.079) deals with password reuse and disallows password reuse for a specified number of generations. The third setting (IA.2.080) allows temporary password use, if upon first logon they are required to change that password. Temporary passwords are often used by domain admins in the provisioning of new accounts. The fourth setting (IA.2.081) requires that passwords not only be stored in a non-reversible hashed format but also that they be transmitted in that format as well. The last setting (IA.2.082) simply requires that the password field does not display what the user is typing onto the screen or if it does it is not something that can be seen by a shoulder-surfer.
Applying These Practices to Windows Active Directory
IA.2.078: Enforcing a minimum password complexity can be done through Windows Active Directory. This might involve minimum password length, maximum password age, as well as the windows complexity requirements. These three settings can be seen in Image 1 below. However, Windows Active Directory does not provide any way of requiring a minimum change of characters when new passwords are created. This single setting can require significant time or money to fulfill. You can try your hand at creating your own dll to accomplish this goal, but unless you have experience in this area it is a better idea to play it safe and use a third party paid solution. Looking into some security vendors revealed an optimistic cost would be around $3000 a year. Despite the steep cost it is still probably a better option than crashing your domain controller with your custom built dll and getting fired.
IA.2.079: This can be set with the “Enforce password history” setting as seen in the Image 1 above.
IA.2.080: This can be set by checking the box for “User must change password at next logon” as seen in the image below. When administrators provision new accounts, they should always apply this setting before giving the newly created user the temporary password.
IA.2.081: This can be set with the “Store passwords using reversible encryption” setting as seen in Image 1 above.
IA.2.082: Windows does this by default. The password section just shows black dots, not cleartext.
Level 3 Practices: Multi-factor and Old Account Management
This level ramps up the security a good deal. It adds multi-factor authentication settings as well as policies on old accounts. The first setting (IA.3.083) requires multi-factor not only for all privileged user accounts but also for all non-privileged user accounts that access systems or information not locally. This means user accounts do not need multi-factor authentication to log into their laptop, but they do require multi-factor authentication when trying to access a network file share. The second practice (IA.3.084) requires replay resistant authentication for network access. Since this setting is only required for network access the replay resistant authentication can be accomplished through the multi-factor authentication that was is required by the first practice (IA.3.083). The third practice (IA.3.085) requires that identifiers not be reused for a certain amount of time. This means there must be a cool-off time after retiring a username before it can be used again. The fourth and last practice (IA.3.086) requires that usernames be disabled after certain amount of inactivity time. If an account has been inactive for months, it is probably safe to say that employee doesn’t work there anymore or at least doesn’t need that access anymore.
Applying These Practices to Windows Active Directory
IA.3.083: Setting up multifactor is a more difficult setting to accomplish. If standard users are given low privileged usernames they will not need multi-factor authentication when logging in locally to their computers. However, when those users log into Active Directory over the network (either by VPN or connecting the the organizations network) they will need multi-factor. To accomplish this goal, Windows Hello for Business can be used. Windows Hello, in a nutshell, is using your laptop or desktop itself as one authentication factor (something you have) and a pin or password (something you know) as the second authentication factor. Windows Hello for Business is multi factor when logging into Active Directory but is really only single factor when simply logging in locally (not connected to the organizations network). This is because while the computer can act as something you have when logging into Active Directory it cannot act as something you have for logging into itself. If it could, then every computer or cellphone is automatically multi factor. This is a problem when you want to have a privileged account able to log on locally – for example a local admin account. So you either don’t use any local admin accounts or you find another solution.
IA.3.084: If using Windows Hello for Business, this control is fulfilled because – according to Microsoft – the second factor is replay resistant. Being replay resistant means that a malicious actor cannot replay an authentication sequence he has eavesdropped on. Looking into the documentation it appears that Windows Hello for Business utilizes Kerberos when used in an Active Directory environment and Kerberos does in fact provide some protection against replay attacks. Most multi factor solutions will be replay resistant and thus this practice will most likely be accomplished after implementing the previous practice.
IA.3.085: In our examples, we have been talking about the username as the identifier. Thus, to prevent reuse of identifiers simply requires usernames to not be reused, at least for a defined period of time. If my company fires me and hires another person named Robert Goyette they cannot give my old username to him, at least not right away. Maybe a username has to be out of use for 6 months or so before being used again.
IA.3.086: This setting is dealing with disabling usernames that are no longer in use. The main example here would be disabling old employees usernames. This setting can be accomplished either manually or through a script.
