CMMC Section 3.5: Identification and Authentication

When it comes to achieving CMMC compliance, the old business maxim holds true — it’s not what you know, it’s who you know.

One of the most vital protections you have against cyberattacks is knowing who’s in your networks, who’s using your applications, and who’s accessing your data. Who you know is all about Section 3.5: Identification and Authentication.

Read on to discover what you must understand about this vital part of CMMC.

Table of Contents:

What You Need to Know About CMMC Identification and Authentication
Section 3.5.1
Section 3.5.2
Section 3.5.3
Section 3.5.4
Section 3.5.5
Section 3.5.6
Section 3.5.7
Section 3.5.8
Section 3.5.9
Section 3.5.10
Section 3.5.11
Your Guide to CMMC Compliance Success

Don't want to read the article? Watch the full recording below.
Be sure to register here for the “Cybersecurity for the Rest of Us” webinar series!

What You Need to Know About CMMC Section 3.5: Identification and Authentication

Cybersecurity Identification and Authentication fall under section 3.5, with 11 individual practices.

3.5.1

3.5.1: Identify system users, processes acting on behalf of users, and devices

When CMMC talks about identifying system users, processes acting on behalf of users, and devices, it’s not talking about your typical system accounts that are running jobs in the background, like a backup job or an archive job. It’s talking about users and their behaviors.

Often, you'll see things like a shared account where you can't identify the actual user. The intent of this control is to tie a person to an event or action. It's one simple little sentence, but it means a lot from an auditing perspective. After all, how do you identify what changes were made, who made them, when the change was made, and so on? System logs do a good job of detecting changes, but the process can be difficult. Even some SIEM and SOC tools have difficulty because all you’re doing is ingesting logs and running queries.

The key here is to set up your user accounts, structure, and roles properly. If you don’t, the data is only going to be as good as what was set up.

A lot of times, you'll look at an SIEM and think, “Well, I can try to dissect that data,” when, in reality, the SIEM is just helping you make the logs readable or put them in a readable format. So detailed logging is needed.

The important consideration here is to define what your user structure is and how you grant elevated privileges. Answer these questions:

• Are you using separate accounts?
• Are you using roles?
• Are you using shared accounts?
• Are you using local admin accounts where anyone can log in as a local admin and their behaviors are logged as that local admin?

All these questions need answering.

3.5.2

3.5.2: Authenticate (or verify) the identities of users, processes, or devices, as a prerequisite to allowing access to organizational systems

You need to validate who users are before you grant access, but there are different ways that CMMC wants you to do this. Two-factor authentication and multifactor authentication are the most common expectations here.

There are multiple types of authenticators, and CMMC calls them out, so you're not forced to use one particular type. It can be passwords, key cards, cryptographic devices, one-time password devices, or a combination of these things. The intent here with this control is to prevent granting first-time access to a system or device using something well-known or easily guessable.

This is where one-time passwords come into their own. In most systems nowadays, especially on the Windows side, when you log in for the first time, you're immediately prompted with a “You must change your password” notice. At that point, you enter the one-time password a second (and last) time and then create a new one.

One of the factors CMMC calls out is minimum password length. Some people disagree that your passwords must be 8, 10, 12, 15, or more characters, believing that length isn't the important part. What’s more important is password complexity, the standards you place around the complexity of your passwords, and the combination of MFA.

3.5.3

3.5.3: Use multifactor authentication for local and network access to privileged accounts and for network access to non-privileged accounts

It doesn't really matter what type of account you have: You should deploy MFA anywhere you can, on any device or application that has the capability.

As time goes on and every year passes, vendors update their software. New software automatically comes with MFA capability. But when you deal with a legacy environment, you're going to run into the potential for devices or applications that don't offer MFA.

Obviously, from an audit perspective, you should document these legacy applications and record with evidence that they don't allow MFA.

Then, whenever possible, put some other form of compensating control in place. This might mean moving legacy applications behind single sign-on where you're already authenticating with MFA elsewhere, and then giving access to a device or application. There are a lot of ways you can achieve this, but the goal is to show the auditor you’re aware of it, there was nothing you could do because you're not the owner of the code or the device itself from a vendor perspective, and you've done everything you can to mitigate this risk.

3.5.4

3.5.4: Employ replay-resistant authentication mechanisms for network access to privileged and non-privileged accounts

System users, like all access and all accounts, whenever possible, should employ replay-resistant authentication. The intent here is to prevent the reuse of an authentication method.

So, you don't want to have something that allows you to store information or reuse it because it doesn't time out or because it's not one-time use. You must prevent attackers from obtaining information that they can use to turn around and log back in as the user.

You can do this with one-time passwords and time-synchronous authenticators. Google Authenticator Duo type applications, for example, last for only 30 seconds or a minute. If an attacker tries to get back in after that time has elapsed, the password won’t be the same. One challenge here is picking a good length of time (most applications hover in the 30 seconds to 60 seconds timeframe). Pick a duration that is long enough to offer a good amount of security, but not so short that it causes problems for most users.

3.5.5

3.5.5: Prevent reuse of identifiers for a defined period

Depending on the size of your organization, the number of devices, and so on, you may have a problem with the reuse of identifiers.

For example, if you're a large organization, and if you don't have a large number of identifiers with the right defined period, you could get the same identifiers coming up and being reused.

This isn’t a problem when you're using Google Authenticator or an RSA token or key fobs. As such, make sure you have enough unique identifiers that can be used over a certain period of time so they're not reused. If you're using key fobs, one-time passwords, and mobile authenticators, this control is probably not a concern these days.

Look at the well-known vendor applications versus ones you've never heard of. Most well-known vendors have taken this into consideration, while others haven't. So, before adopting a standard, run through these things.

3.5.6

3.5.6: Disable identifiers after a defined period of inactivity

If you visit a website and request a one-time password, you typically get an SMS message containing that password and a warning that it’s good for only 10 minutes. Other banks offer one-time passwords that don’t expire — or the banks don’t tell you they expire.

What’s important for your organization is that you define and communicate to your employees how long your identifiers last.

Then you must remove or delete both the identifiers and the accounts when no longer needed versus simply disabling them. There are times when disabling things makes sense, but in most cases these days, there are ways to get access to data and archival information. So, barring something like a legal hold or having to deal with law enforcement, there's really no reason to leave this information around. After all, if something is disabled instead of deleted, hackers might have the ability to enable it and use it again.

3.5.7

3.5.7: Enforce a minimum password complexity and change of characters when new passwords are created

You should employ standard password-complexity requirements. Almost everybody these days is going to say you must have a combination of uppercase, lowercase, numbers, and special characters. But there are instances where special characters are recommended but not required, or where three out of four of these are required, but not all four.

You must decide on the level of password complexity you require and then communicate this standard.

There are also variations to this, however:

Let's say you have someone who uses happytobehere1 as their password, knowing they’re required to change that password frequently. Next time, it's happytobehere2, followed by happytobehere3. All they do is change the last number.

There are mechanisms you can employ for a lot of the software applications that exist, where you can prevent users from changing only the last character. You can also prevent users from using specific words in the English language, such as using a portion of the website name in a password.

3.5.8

3.5.8: Prohibit password reuse for a specified number of generations

Many sites prevent users from reusing passwords until they’ve gone through a rotation of multiple passwords (10, for example). This control is popular with the DoD because of how strict some DoD regulations have become over the years.

This control involves a minimum password duration before it can be changed, as well as the number of passwords. After a password change, for example, you can prevent a user from changing it for 48 hours. This prevents someone from cycling through five or 10 passwords quickly just to get back to their original password. Obviously, this can still happen. It's just going to take a user longer to do it. And the question becomes: Are they willing to go through that headache?

One thing to note here is that 800-171 specifically states that password lifetime restrictions don’t apply to temporary passwords. But you should tie your one-time passwords and temporary passwords to a timeout duration anyway. As for password complexity, go with what you know is already the norm. Also go with what other certifications are requiring. This way, you're likely to meet CMMC requirements as well as other requirements.

3.5.9

3.5.9: Allow temporary password use for system logons with an immediate change to a permanent password

Some organizations allow users to use temporary passwords over and over on applications, though not necessarily user accounts for their workstations or the network. This should never happen. If a user can use a temporary password repeatedly, the likelihood is that the temporary password is set for everybody.

Instead, allow temporary password use only for system logons, with an immediate requirement to change to a permanent password.

3.5.10

3.5.10: Store and transmit only cryptographically-protected passwords

This brings us to storage. You should use salted, one-way cryptographic hashes of passwords whenever possible.

So, what does this mean? You start with a password. Then you append a set of characters to the end of it, called a salt. Some will say append it to the beginning, some will say at the end — it doesn't really matter. In the end, you use an encryption algorithm to create a hash, which is the password plus the salt. This becomes a stored hash-salted-password and the salt.

So, you end up storing two things. You store the hash, and you store the salt. If you have the salt, you're able to get to the password. Whereas if you don't have the salt, you can't. This effectively makes it extremely difficult for someone to crack your password because it's not just a password. There are extra characters almost for space and complexity purposes.

You have to protect this information, of course. You have to store all the salts. Do this by storing and transmitting only cryptographically protected passwords and salts.

3.5.11

3.5.11: Obscure feedback of authentication information

Online resources abound when it comes to obscuring sensitive data. If you're in an office environment, for example, screen protectors prevent passersby from viewing what’s on computer monitors. Other examples are covers over PIN keypads. If you don't use a badge to swipe or to press up against a reader, require your users to cover the keypad with their other hand or body.

Your Guide to CMMC Compliance Success

Achieving CMMC compliance is all about staying a few steps ahead of hackers. Cyber threats are everywhere and are constantly changing. Achieving CMMC compliance helps you reduce risk and protect your networks and data. If you’re finding it almost impossible to maintain a fully staffed, full-time, on-site IT security department that provides the cyberstrategy and protection you need, then consider partnering with Ntiva. Discover our Managed Cybersecurity Services.