DFARS In Depth – Part 4: Identification and Authentication

DFARS In Depth – Part 4: Identification and Authentication

duoskull

To continue our discussion of the DFARS requirements of NIST Special Publication 800-171, this week we’ll discuss the Identification and Authentication security requirement family.

This requirement family covers how we verify that the users and devices connected to our systems 1) are who they say they are, and 2) should have access to what they’re accessing.

Identification and Authentication - Basic Requirements

There are two basic requirements in the Identification and Authentication family:

  • Identify system users, processes acting on behalf of users, and devices.
  • Authenticate (or verify) the identities of users, processes, or devices, as a prerequisite to allowing access to organizational systems.

So, to successfully implement proper identification and authentication, both users and devices must be identified uniquely, and that identification must be properly verified before that user or device is allowed access to your network and systems. The Derived Requirements give us some more insight on how to accomplish this.

Identification and Authentication - Derived Requirements

The first of the derived security requirements mentions multifactor authentication (MFA):

  • Use multifactor authentication for local and network access to privileged accounts and for network access to non-privileged accounts.

Multifactor authentication includes “something you know”, like a password or PIN, and “something you have”, including a smartcard, token, soft token, or biometric information. The DOD uses the smartcard-based Common Access Card (CAC), but the requirements for DFARS specifically state that you are free to choose from other MFA solutions. Interestingly, the footnote for “network access” mentions that this includes access to systems over any network, including a local one. So even local workstations need to be protected with MFA in some way.

The next few requirements deal with the specifics of identifier security:

  • Employ replay-resistant authentication mechanisms for network access to privileged and non-privileged accounts.
  • Prevent reuse of identifiers for a defined period.
  • Disable identifiers after a defined period of inactivity.

A “replay-resistant” authentication mechanism is one that prevents someone who is snooping on network traffic from being able to store and re-use at a later time. Modern authentication mechanisms such as Kerberos are designed to resist replay attacks, but you will need to make sure that your systems cannot be tricked into “falling back” to a less-secure mechanism by an attacker.

The next two requirements have more to do with administrative housekeeping, but there are technical means to enforce them. Reuse of an identifier means assigning the same identifier (e.g. a username) to a different individual. For example, imagine you have a user named Bob Smith with the username BSMITH, and he resigns. Then, the next week a new user named Barbara Smith joins your company. You would need to make sure that Barbara is not assigned Bill’s old username -- she will need a unique username, unless a certain amount of time has passed since Bob left.

Secondly, you’ll need to make sure that unused identifiers are disabled after a period of time. For users, typically you would disable their account at the time they depart the company, but you’ll want to run regular checks to make sure that no one was overlooked (a very common occurrence). Similarly, machine accounts for domain-joined computers should be disabled after a certain amount of inactive time, if they’re not removed when the device is removed from service.

The last few security requirements for Identification and Authentication have to do specifically with passwords:

  • Enforce a minimum password complexity and change of characters when new passwords are created.
  • Prohibit password reuse for a specified number of generations.
  • Allow temporary password use for system logons with an immediate change to a permanent password.
  • Store and transmit only cryptographically-protected passwords.
  • Obscure feedback of authentication information.

While we’ve discussed the ins and outs of password complexity requirements, NIST SP 800-171, and therefore DFARS, still requires them. So you’ll need to enable them on your systems. Likewise, password re-use prevention and temporary password enforcement are built in to Microsoft Active Directory (AD DS), so enabling these is as simple as configuring a group policy. AD DS also stores passwords with one-way hashing by default -- but again, you’ll need to verify that insecure legacy protocols are disabled.

Authentication is one of the most important aspects to maintaining the security of your systems. If you’d like help in making sure your security is up to snuff, contact E-N Computers today.