Skip to content
All federal government contractors handle Federal Contract Information (FCI) in some form or another. We cover the definition of FCI in a previous post, but it is important to note that FCI is not just handled by large tier 1 prime contractors, but by business all down the supply chain, including small business suppliers and vendors. Businesses that handle FCI are required by the FAR 52.204-21 contract clause to implement some basic cybersecurity safeguards to protect that FCI. (The lone exception for this clause is for Commercial Off The Shelf (COTS) item suppliers.) When a business uses networked Information Technology (IT) assets – such as workstations, servers, mobile devices, routers, and Wi-Fi access points — to handle FCI, the business must apply some of those safeguards to those devices. One of these safeguards requires “device authentication.” Those of us in the DoD supply chain will need to assess our implementation of device authentication as part of the Cybersecurity Maturity Model Certification (CMMC). However, device authentication can be a confusing topic for small businesses, so in this post we describe what it is, why it is important, and a couple of ways to implement it.
What does “device authentication” mean?
Let’s start with what the word “authentication” means: to authenticate means to prove your identity, in other words, to prove you are who you say you are. People authenticate themselves all the time in normal life, e.g., showing a state-issued license with a photograph at the airport, or providing a PIN when we call our insurance company to file a claim. If we didn’t authenticate, how would TSA know we aren’t a terrorist, or how would our insurance company know we aren’t trying to file a false claim in someone else’s name?
We also authenticate regularly when using computers and applications, e.g., following up a username (identity) with a password, fingerprint, or one-time code. The password, fingerprint, or code are different examples of authenticators. Without authentication, we don’t know if the person trying to access the computer is actually who they say they are. If we didn’t identify computer system users, how would we know that an adversary isn’t usurping a user account to perform nefarious activity, such as installing malware or stealing sensitive information?
“Device authentication” just means that, just like a human user, a device must prove its identity by some means, i.e., it must authenticate itself. Only after it authenticates is the device allowed access to the network. The device can do this itself, or an authorized human using the device can assist.
Precisely how the heck can a device provide authentication, you ask? Read on and we’ll explain, but first a quick note on why the government and CMMC requires us to authenticate devices and not just human users.
Why is device authentication important?
The human user authentication examples above show that authentication is important to prevent unauthorized access, whether that access is to an airport, an insurance claims system, or a computer or network. In the case of FCI we handle on its behalf, understandably the government wants us to ensure we control access to the FCI. I.e., it wants us to ensure FCI doesn’t fall into the hands of unauthorized individuals, such as our adversaries.
But stealing another human’s username isn’t the only way to get unauthorized access to FCI; we could perhaps compromise a device and then install that device on an IT network. Then we could use that “rogue” device to, say, funnel network traffic—including FCI in digital form transmitted over the network—to Internet-based servers we control. Or we could use the device as a “launching pad” from which to attack other assets on the network to try to move laterally and find the valuable IT assets, such as fileservers. Hackers and our adversaries constantly use these types of tricks to try to get access to the information they want. And wireless networks are extremely vulnerable to rogue device infiltration because the adversary is not required to be present inside a facility to connect a cable for network access.
But not all unauthorized device threats are intentionally malignant. Consider Bring Your Own Device (BYOD) environments, in which organizations allow their staff to use personally owned devices to connect to IT resources. What if a staff member brings in an old, unpatched, and buggy laptop, connects it their company’s network, and one of those bugs crashes the network. It wasn’t intentional, but since that company did not limit network access to only authorized and authenticated devices, havoc ensued. The company lost access to their network and the information that resides thereon.
To help ensure against intentional and unintentional FCI compromise, the government includes the following subclause in the FAR 52.204-21 contract clause for the safeguarding of FCI:
“Authenticate (or verify) the identities of those users, processes, or devices, as a prerequisite to allowing access to organizational information systems.”
So, we are under government mandate — and CMMC will hold us accountable– to ensure “users, processes, or devices” authenticate.
Above we briefly discussed how to authenticate users, and in a previous post we discussed process authentication. We’ll get to device authentication just below. But first: did you notice above that the FAR clause uses the phrase “Authenticate (or verify)…”? Let’s start by exploring the “verify” part of that clause and explain why verification and authentication are not the same thing.
Are device verification and authentication the same thing?
Imagine you’re trying to get into an exclusive nightclub. You’re excited because a friend that works at the club put your name on “the list”. You wait your turn in line and when it’s your turn the bouncer asks your name. You give it to him, and he checks “the list.” He sees your name there, unhooks the velvet rope, and you’re in! Party on!
But do you see a problem here? He didn’t ask you for your photo ID.
Anyone else who knew that your name was on the list could have gotten in line before you, given the bouncer your name, and taken your spot! In this case, all the bouncer did was verify your name on the list; he did not require you to authenticate your identity, by presenting an ID. Verification is therefore not the same as authentication.
As the FAR 52.204-21 clause is currently written, you are allowed to do simple device verification in your network. MAC address filtering or MAC allowlisting is the most common device verification method. Every networked device has an associated hexadecimal MAC address that it digitally presents to a network switch as a prerequisite to communicate on that network. When MAC filtering is engaged, prior to allowing access, the switch checks the MAC address against a pre-configured allowlist. If the MAC address is not on that list, the device doesn’t get to participate in the network communications. In our club analogy, the device doesn’t get to party! The problem with this approach is that, just like with your name on the nightclub list, bad girls can get in front and spoof MAC addresses, and by doing so unauthorized devices can connect to the network.
It’s important to note also that the language used in the FAR clause is NOT echoed in the National Institutes of Standards and Technology (NIST) 800-171A rev 3 publication, which in the near future under the CMMC program will be used to assess our implementation of the FAR clause. 800-171A rev 3 does away with the word “verify” and instead requires device authentication:
“[devices] are authenticated before establishing a system connection.”
So, from both a security best practice as well as a CMMC compliance perspective, device authentication is a better option than device verification.
Now with a firm understanding of authentication, let’s explore options for how devices can authenticate themselves.
How can we authenticate a device?
Obviously, a device like a workstation is not a human that can authenticate itself by typing in a password or pressing a finger to a fingerprint reader. So, we need to find other more automated methods to ensure devices authenticate themselves to networks. Luckily, a couple of widely adopted device authentication methods have been around for decades:
- IT administrators can pre-install on the device an electronic file containing identification information and encryption keys. We call this file a “certificate.” When requesting access, the device digitally transmits this certificate to a “certificate authority” on the network, typically a network switch or Network Access Control (NAC) appliance. The switch or NAC appliance then checks the certificate against an allowlist, confirms the encrypted contents, and allows or denies the device access accordingly. This is the method used by the 802.1x protocol and some implementations of the Extensible Authentication Protocol (EAP) for wireless.
- Users can periodically – typically every 8 to 10 hours – input their password at a prompt on their device they are using to solicit a network server to issue an encrypted “ticket” for the device. This ticket is then checked by the server periodically and allows the user to continue using the device to access network-based resources, such as fileservers and applications. This method is the Kerberos protocol used in Microsoft Windows Active Directory or Entra ID environments.
The average reader of our blog will not be interested, nor have the attention span, to suffer here a deep dive on these device authentication protocols, so we’ll spare you 😊. The bottom line is that both authentication methods outlined above incorporate difficult-to-spoof cryptography, which makes these methods more robust than MAC address verification.
Configuring true device authentication takes some IT administration skill and is not a task the average small-business-owner-doubling-as-the-company’s-IT-guy/gal can accomplish on their own. So, you’ll want to leave device authentication setup to the pros.
Wrapping up
There you have an overview of device authentication. It’s important to control all access to your organization’s IT resources, whether that access is human, software, or hardware. Rogue hardware devices represent a significant threat to networks, facilitating both intentional and unintentional harm. Configuring device authentication can help mitigate this risk. There are several common device authentication methods, but they do require some IT administration skill to implement.
If you’re interested in discussing this topic more, or understanding how device authentication works in the context of the DoD’s CMMC, consider joining one of our CMMC Readiness Workshops. We’d love to have you with us in our next cohort!
Good Hunting!
–Adam
