Hello and welcome to the NIST 800-171 learning path. My name is Dave Hadar and I'm your instructor for this class. This is Course 2, understanding and implementing the 110 NIST, 800-171 requirements. As we've discussed, there are 14 requirements families. In this video, we'll take a look at requirements family 3.5, identification and authentication. This is really about implementing measures to ensure that only authorized individuals and processes can access CUI. There are 11 requirements in this requirements' family. Let's take a look at the first one. Our first requirement of this family is 3.5.1, identify system users, processes acting on behalf of users and devices. This is a basic requirement. It basically says you need to have processes and mechanisms to identify users and devices. Common identifiers include things like IP address, MAC address, tokens, and username. Thankfully, NIST provides a good resource for you, NIST special publication 800-63-3 for guidance on digital identities. 3.5.2 is authenticate or verify the identities of users, processes, or devices as a prerequisite to allowing access to organizational systems. This is also a basic requirement. You need to verify the identity of users and devices before granting access to organizational resources. Authentication can include things like passwords, certificates, tokens, biometric, onetime passcodes, etc. You need to have processes and mechanisms to issue and revoke authentication information. Again, you can turn to NIST special publication 800-63-3 for guidance on digital identities for more information. 3.5.3 is use multifactor authentication for local and network access to privilege accounts and for network access to non-privileged accounts. This is a derived requirement. They say multifactor authentication is the use of additional identity verification. MFA can be deployed at the operating system or application level. Multifactor authentication provides much stronger defense. Google and Microsoft, both independent of one another, have indicated that MFA can stop 99 percent of automated attacks. I really can't strongly recommend enough from what we see out in the real-world for you to turn on multifactor authentication, sometimes known as two-factor authentication, sometimes known as two-step verification, depending on the platform. Again, the language may vary, but the concept is essentially the same, that in addition to typical user credentials like a username and password, you're going to be required to provide a onetime passcode, possibly through an authenticator app. That's the best way to do it in most cases, unless you have a hardware token or through a onetime passcode that's sent via text to a phone, something like that. But it really makes it difficult on the bad guys because even if they have credentials or they can brute-force credentials or guess credentials, they still can't access the system because they won't have access to that onetime passcode. Again, I can't stress enough how important it is to use multifactor authentication everywhere you can. For more information, you can turn to NIST special publication, 800-63-3 for further guidance on digital identities. Up next we have 3.5.4, employ replay resistant authentication mechanisms for network access to privileged and non-privileged accounts. This is a derived requirement. They say replay resistant mechanisms make it difficult to record an authentication session and play it back later to gain access. Nonces, challenges, certificates, and time synchronous or challenge response onetime authenticators can prevent replay attacks. They give you, again, remember this is never prescriptive. They're not telling you exactly what you need to do. But here NIST gives you a list of different ways you might use replay resistant authentication mechanisms to meet this requirement. They also, once again, send you back to NIST special publication 800-63-3 for guidance. You've got requirement 3.5.5, prevent reuse of identifiers for a defined period. This is a derived requirement. Basically they say, don't allow an identifier to be reused at all if possible, or at least for a significant period of time so that that slows the bad guys down and or potentially blocks them entirely. 3.5.6 disable identifiers after a defined period of inactivity. Another derived requirement. Inactive identifiers can allow undetected unauthorized access. Dormant accounts laying around that are still enabled but haven't been used in awhile. Someone that maybe it was terminated a long time ago, but there account is still enabled. Could allow bad guys to guess a bad password without associated with that account, use those credentials to log in. Because no one's paying attention, they might have unfettered access to your systems for a substantial period of time. The idea is there, disable any identifier when it's no longer needed and set an expiration date if possible, so that accounts must be proactively renewed. Even for accounts for active users, it's not a bad idea to say, this account's going to expire in six months. Then you have to go through the process of renewing them. That's especially true if you have contractors, part-time workers, etc. You're going to want to go ahead and set those accounts to expire so that when they're gone, you don't necessarily have the likelihood of an account that slips through the cracks and can continue to provide access to the bad guys. 3.5.7 enforce the minimum password complexity and change of characters when new passwords are created. It's a derived requirement. It's pretty straightforward when you create a new account, set minimum password complexity. Obviously, the more complex the password is, the better it will be, the stronger it will be, but obviously the more difficult for someone to remember. You may want to strike a balance there things like password managers can simplify this to an extent because it makes it easier for people to create very strong passwords with substantial complexity without the need to remember those. But some type of password complexity longer is better is a good thing, and they give you again, special publications 800-63B be for guidance on digital identities. 3.5.8 prohibit password reuse for a specified number of generations. Another derived requirement. More generations is better. Microsoft recommends 24, and just to add some clarity to this, all they're saying is, each time you have to change your password, you can't reuse that password for some number of generations or iterations. Again, Microsoft recommends 24. You would not be able to reuse that password again for a substantial period of time. Reducing the likelihood that if it were compromised, some will be able to use that password. They once again point you back to special publication 800-63B for guidance on digital identities for further information. You've got 3.5.9, allow temporary password use for system logons with immediate change to the permanent password. This is a derived requirement. Essentially, this just says, the first time a user logs on, you're going to want to force them through a password reset process. So that they have to pick a new password and then ideally, it would be a strong unique password for that system. Following the good password guidance that you can get from some of these NIST special publications. 3.5.10, store and transmit only cryptographically protected passwords. Another derived requirement. In whatever system that you're storing credentials, you want to make sure that those passwords are salted and hashed. You don't want to have open clear text passwords. Even an encrypted password could potentially, if a key is stolen, leaked, whatever could be reversed. Using something like salted hashed passwords, ideally, maybe even with pepper, we'll make those passwords more secure. Again, you may add friction to the system. But since passwords are still the main way we access systems today, very critical that you are cryptographically protecting your passwords. Then finally, control 3.5.11, obscure feedback of authentication information. This is another derived requirement. This basically just says, when someone goes to login, don't do anything that would make it easy for the bad guys to figure out why the credentials are not working. The less information you can give about why credentials are not working the better because it makes it harder for the bad guys to use any feedback they're getting to break into the system. As it says in that bullet point, don't provide any feedback that would aid in attacker in defeating authentication mechanisms. That gets us through all 11 of the requirements in family 3.5, identification and authentication. I will see you in the next video where we'll take a look at family 3.6. Thanks.
