Welcome to our comprehensive guide on Identification and Authentication (IA) for CMMC Level 2 compliance. This guide is tailored for small to mid-sized businesses that hold Department of Defense (DoD) contracts and need to meet the CMMC Level 2 IA requirements.
Our guide covers essential identification and authentication protocols, You’ll learn the steps required to meet CMMC Identification and Authentication standards, including compliance with IA.L2-3.5.3 multi-factor requirements. Additionally, we provide clear guidance on required documentation to streamline the certification process.
For those seeking personalized support, we offer free consultations to help you navigate CMMC Level 2 security controls. Our team is dedicated to simplifying the compliance journey, and helping your business achieve security and certification goals with confidence.
“Identify information system users, processes acting on behalf of users, or devices.”
Level Of Effort: Medium
This makes sure that every user of the system has a unique identifier. It also applies to processes and devices that act on behalf of these users. Each one must have its distinct identifier.
Here are steps to put in place this, along with the types of evidence that prove compliance:
Recommendations:
Use a directory service: Meeting these requirements can be hard without a Directory Service. This is a key system for managing user identities. A common option is Active Directory, which you can install on your company's server. But, many businesses now prefer Microsoft’s Entra ID for cloud-based management. For businesses using Mac computers, third-party tools are often necessary. One such option is JumpCloud, a cloud-hosted directory service.
Evidence:
Screenshots from your directory service: Keep screenshots of how your Directory Service is set up. This shows how you keep track of users and devices.
IA.L1-3.5.2 – AUTHENTICATION
“Authenticate (or verify) the identities of those users, processes, or devices, as a prerequisite to allowing access to organizational information systems.”
“Use multifactor authentication for local and network access to privileged accounts and for network access to non-privileged accounts.”
Level Of Effort: High
Using Multi-factor Authentication (MFA) is an important control in ensuring secure access to your systems. It's like having an extra layer of security, where users need to prove their identity in more than one way to get access. Here's how to put in place MFA in your organization and what kind of proof you should keep:
Recommendations:
Install MFA for all cloud systems: Make sure every cloud service you use has MFA. Follow the infographic below to choose the strongest MFA option.
Set up MFA for all computers within your scope: Users have to be prompted with MFA every time they log onto the network to access CUI. Privileged users need MFA for direct computer access too. Common tools for this include Duo Security or Okta. These typically cost around $3-9 per user per month. Discuss with your I.T. team about the best tool for your needs.
Ensure remote access has MFA: If your team uses a virtual private network (VPN), Secure access service edge (SASE), or any remote access tools, they must be configured with multifactor authentication (MFA).
Evidence:
MFA configuration screenshots: Keep screenshots from your MFA setup on cloud systems, computers, and remote access tools. These images should show that MFA is active and properly configured.
Vendor list: Create a list of all your cloud services and note the type of MFA each one uses.
Make sure to use the most secure MFA available. This infographic will guide you:
IA.L2-3.5.4 – REPLAY-RESISTANT AUTHENTICATION
“Employ replay-resistant authentication mechanisms for network access to privileged and non-privileged accounts.”
Level Of Effort: None
This should be addressed if you implement all of the recommendations under IA.L1-3.5.1 – IDENTIFICATION, plus using native Windows/Mac password features.
“Prevent the reuse of identifiers for a defined period.”
Level Of Effort: Low
When it comes to usernames and other identifiers, it's important to have guidelines about when they can be used again. This helps keep your systems secure, especially when someone leaves your company or changes their job.
Here’s a guide to managing identifier reuse and the type of evidence you should keep:
Recommendations:
Decide on rules for reusing usernames: Some businesses choose to disable usernames forever once a person leaves. Others delete them, which allows for reuse later. You'll need to decide which approach works for your company.
Set a time frame for reuse: Common practice is to wait six or twelve months before reusing a username. Make sure your I.T. team knows and follows this rule.
Evidence:
Add your policy to your SSP: Write down your rules about identifier reuse in your Security System Plan (SSP). This should include whether usernames are disabled or deleted and how long before they can be reused, if at all.
IA.L2-3.5.6 – IDENTIFIER HANDLING
“Disable identifiers after a defined period of inactivity.”
Level Of Effort: Medium
In meeting CMMC Level 2 standards, it's essential to turn off user accounts or identifiers that haven't been used for a predetermined time. This stops active but unused accounts from becoming a security problem. Here’s a simple way to manage these accounts and what kind of proof you need:
Recommendations:
Find accounts that aren't being used: Set up an alert or report to spot accounts that haven’t been active for some time, like 60 days.
Make a plan for inactive accounts: Decide who will check which accounts haven’t been used, who decides if an account gets turned off, and who does the turning off.
Evidence:
Inactive account report: Keep a report that shows which accounts haven’t been used.
Your process and logs: Write about how you handle inactive accounts in your Security System Plan (SSP). Also, keep track of any decisions to turn off accounts.
IA.L2-3.5.7 – PASSWORD COMPLEXITY
“Enforce a minimum password complexity and change of characters when new passwords are created.”
Level Of Effort: Low
Password complexity means setting up rules to make passwords strong and hard to guess. For instance, setting rules about the length or the use of different characters. Here's how to set up a strong password policy and the proof you need to show you're doing it:
Recommendations:
Set a password standard: You should decide on rules for creating passwords. A common set of rules includes:
Passwords should be 12 or more characters long.
They must have at least one lowercase letter, one uppercase letter, a number, and a symbol.
Apply the standard to all systems with CUI: Ensure this rule is used in your Directory Service. Also, apply it to any other systems not managed by your Directory Service, like cloud systems.
Don't forget about local computers: Use a service like Active Directory to apply this password policy to all computers. If you don't have such a system, you might need to set this up manually.
Evidence:
Document your password policy: Add your password rules to your Security System Plan (SSP).
Screenshots of your password policies: Take screenshots of the password policy settings from each system that handles CUI.
Proof of policy implementation on computers: Show screenshots of the password policy on local computers, and you can also use a vulnerability scanner to confirm it.
IA.L2-3.5.8 – PASSWORD REUSE
“Prohibit password reuse for a specified number of generations.”
Level Of Effort: Low
Making sure old passwords aren't used again is key to keeping your systems safe. Each new password should be unique and can’t be guessed based on previous ones. Here’s how to set this up and the kind of proof you should have:
Recommendations:
Set a rule for how often passwords can be reused: A common rule is not allowing the same password to be used for the last 10 changes.
Apply this rule to ALL systems with CUI: Make sure this password rule works in your Directory Service and on any cloud systems. Also, apply it to systems not managed by your Directory Service.
Include local computers: If you're using a Directory Service like Active Directory, you can apply this rule to all computers easily. If not, you may need to set this up on each computer manually.
Evidence:
Write down your password rule: Add rules about password reuse in your Security System Plan (SSP).
Screenshots of your password policies: Keep screenshots of the password policy settings from each system handling CUI.
Proof of policy on local computers: Show screenshots of the password policy settings on local computers. You can also use a vulnerability scanner to check it’s set up right.
“Allow temporary password use for system logons with an immediate change to a permanent password.”
Level Of Effort: Low
For CMMC compliance, handling temporary passwords correctly is crucial. They're meant only for the first login and should be changed immediately. This keeps your system logins secure from the start. Here’s a guide to managing temporary passwords and the type of evidence you should have:
Recommendations:
Set systems to force password changes after first use: Make sure your systems force users to create a new password after logging in with a temporary one. This rule should apply to your Directory Service and any other systems not managed by it.
Follow your standard password policy for temporary passwords: Temporary passwords should follow your password policy. Avoid simple and predictable passwords e.g. 123456.
Decide how to give out initial passwords: Plan a secure way to share first-time passwords. Like via phone, text, or printed notes for people in the office.
Evidence:
Screenshots of your computer settings: Take and keep screenshots of your password policy from each system with CUI.
How you do things in your security plan: In your Security System Plan, write down how you give out the first-time passwords and what you do with them. This is like your rule book for handling these starter passwords.
