Skip to content
Federal government contractors that handle Controlled Unclassified Information (CUI) must implement the National Institutes of Standards and Technology (NIST) Special Publication 800-171. NIST 800-171 lists 110 cybersecurity safeguards –aka controls – for the protection of CUI. One of those safeguards requires us to implement application allowlisting, in which our IT systems are configured in such a way to guarantee only approved software can execute. For those of us contracting in the DoD supply chain, the Cybersecurity Maturity Model Certification (CMMC) requires us to provide evidence that we have implemented application allowlisting. In this post we’ll explain what application allowlisting is, why it is important, and explain how we can implement it.
What is application allowlisting?
Application allowlisting is a concept that can be referred to by many different names, including “software whitelisting”, “application control”, “software execution policy”, or “deny-by-default; allow by exception”. These phrases can be ambiguous, verbose, and / or a little confusing. So, the concept is easiest explained through analogy.
If you’re old enough, you remember the days before the Transportation Security Administration (TSA), which was formed after the events of 9/11. Before TSA, anyone could get into the airport, all the way up to the gates, even if they weren’t flying. All you needed was to pass through a metal detector to ensure you didn’t have weapons. I remember a trip to Florida in early 2001, a time in my life when I was terrified of flying (I’m better about it now). To help get me “loose” enough to tolerate the flight, my brother and a friend joined me at an airport bar to knock back a few. The kicker: I was the only one that was flying, my brother and friend were there just to help me out!
Now, it wasn’t a total free for all back then. To be sure, you needed a paper ticket to get on the plane, but your friends and family could hang out with you before your trip. The airlines also maintained what were called “blacklists”, lists of names of passengers that were denied the access to fly for whatever reason, e.g. past belligerency or known terrorist affiliation. (Blacklisting or “denylisting” is also known as allow-by-default; deny-by-exception.) But that was about all that was done to restrict access to the planes.
After 9/11 that all changed. Now, in addition to a ticket to board the plane, you need positive identification just to get through the TSA checkpoints and into the terminals. And the identification must match certain official criteria, such as official passport, Real-ID, etc. You can’t just use your library card (does anyone remember those?) as your identification. On top of presenting official ID, your face is scanned, and the image is compared to that on your passport or ID. If you don’t have a ticket, state-issued-ID, and positive face match, you get denied access to the terminals.
What has been established by the TSA after 9/11 is a “deny-by-default, allow-by-exception” security protocol. The airlines, by issuing tickets to confirmed buyers, establish a list of allowed passengers. Anyone without a ticket is immediately denied access by the TSA. TSA’s job after confirming the individual is on the allowed list is to then authenticate the identity of the allowed person. Only after that is the traveler allowed through security.
Essentially the same thing happens with application allowlisting. We, as an organization, establish ahead of time which software applications –e.g. Microsoft Office apps like Word, browsers like Chrome, or specialty CAD applications – we are going to allow to run on, say a laptop. Then we require all applications on that laptop to present some sort of credentialed identification at run time. Without the proper credentials, the application will not run.
Why is it required for CMMC?
While revision 2 of the NIST 800-171 allows an organization to choose between “whitelisting” (allowlisting) and “blacklisting” (denylisting), with revision 3 of the standard NIST definitively specifies allowlisting as the only application control method commensurate to protect CUI.
“Implement a deny-all, allow-by-exception policy for the execution of authorized software programs on the system.”
NIST made this change between revision 2 and revision 3 because application allowlisting is, alongside multifactor authentication, one of the two best technological protections for information. (Don’t just take our word for it, see the Australian Cyber Security Centre Essential 8, or the National Security Agency’s Top 10.) By implementing application allowlisting, you are denying all pre-approved software – including malicious software like that associated with ransomware – from being able to execute. This means that no matter how many times a user clicks on an application icon, a script runs an executable file, or a process tries to kick off, if that application, file, or process isn’t on the allowlist, it’s not running.
Since CMMC assesses DoD contractors’ implementation of the NIST 800-171 standard, ensuring application allowlisting is crucial for CMMC success.
Why is allowlisting so powerful?
What makes allowlisting so effective is that the organization, ahead of time, establishes a list of the applications it wants to allow to execute. While a workstation like a laptop might need several dozen applications running, really critical and high-value IT components like servers shouldn’t need many applications running at all – only those critical to the server’s function.
Instead of having to maintain a dynamic and ever-expanding list of applications that we should deny from executing — which is what antivirus blacklisting or denylisting software does — the organization simply needs to maintain a smaller, relatively stable list of applications it does want to allow to run.
And just like the airlines issuing tickets to confirmed passengers, the organization configures an allowlisting tool with their list of allowed applications. The allowlisting tool then plays the role of the TSA checkpoint: checking all “passengers”, i.e. applications, to ensure they are on the allowlist. And just like the TSA still maintains a list of known terrorists, we can combine allowlisting and denylisting for very powerful effects.
Allowlisting is so important, we’ve included it as #3 in our Totem Top Ten™. And, as we’ve covered it above, allowlisting is required by CMMC.
Now you might be thinking: application allowlisting sounds great! What application allowlisting tools are out there, and how can we implement them? Read on!
How can we implement application allowlisting?
Before we discuss how to implement application allowlisting, a word of caution: allowlisting is a powerful tool. With great power, comes great responsibility. If care isn’t taken in the beginning to establish a thorough list of authorized applications, organizations run great risks of blocking necessary and critical applications by mistake. Remember: if it’s not on the allowlist, it’s not going to run.
So, it’s critical for the organization’s stakeholders to invest the time up front to thoroughly analyze the software applications that need to run and establish an allowlist accordingly. The problem with this is that, on a Windows 11 device for instance, there are literally thousands of applications — aka executables — that need to run for the operating system (OS) to function efficiently. And in a “deny-by-default” paradigm if we only account for the major applications – your MS Office apps, your browsers, your design software – and forget about the lesser known but crucial “under the hood” applications, we can literally cause the device to stop functioning.
To alleviate the burden on an organization to individually identify and add to an allowlist the thousands of executables an OS needs to run, the security industry over time has evolved different approaches to application allowlisting. For instance, using Microsoft Windows’ built in “AppLocker” tool, one can create and enforce an allowlist based on folder location, cryptographic hash, and/or Microsoft signatures.
But using AppLocker requires experience and advanced IT administration skills. Luckliy, there are products on the market that make allowlisting easier. These products “pre-authorize” applications, and operate similarly to how Clear or TSA Precheck make passing through the airport TSA checkpoints easier. Once such product — which we highly recommend — is PC Matic Pro. So, we’ve invited our partners at PC Matic to explain their approach to application allowlisting in layperson’s terms. PC Matic team, take it away!
PC Matic’s approach to application allowlisting
At PC Matic, we understand that terms like “allowlisting” can sound complex, especially for small business owners navigating regulated standards like NIST 800-171 or CMMC. That’s why our malware research team works tirelessly behind the scenes to make allowlisting straightforward, secure, and hassle-free. Here’s a simple explanation of how our team ensures only approved software runs on your devices.
When a new program (called an “executable”) tries to run on one of your devices and it’s not already on our global allowlist of over 22 billion trusted files, we block it by default. That file is then sent to our servers for review. Our malware research team steps in to examine it, using a mix of advanced tools and automated processes to determine if it’s safe.
Here’s what happens during their review:
- File Analysis: The team checks the file’s details, like where it came from and what it does. They may run it in a “sandbox”—a secure, isolated environment—to see how it behaves without risking harm. For example, they look for suspicious actions, like installing unwanted files or making unauthorized changes to your system. They also monitor system attributes for abnormal memory usage and CPU activity.
- Signature Verification: Many programs have digital “signatures” that act like a seal of authenticity from the software vendor. Our team verifies these signatures by checking the vendor’s identity, the signature’s issuer (a trusted authority), and its validity. If the signature is legitimate and from a trusted source, it’s added to our global allowlist. However, not all signatures make the cut—self-signed certificates, for instance, aren’t trusted globally and must be approved on your local allowlist instead.
- Deep Investigation: Our researchers dig into the file’s “hash” (a unique digital fingerprint) and other file metadata. They also cross-check the file against VirusTotal, a database of known threats, and stay updated on the latest cybersecurity trends to spot potential risks.
- Approval or Rejection: If the file or its signature is deemed safe, it’s added to our global allowlist, meaning it can run on your devices without further action. If it’s suspicious or malicious, it remains blocked to protect your business.
When PC Matic runs on your devices, we check each program against our global allowlist. If the program itself or its verified signature is on the list, it’s allowed to run. If not, it’s blocked until our team reviews it or until you add it to your local allowlist for specific cases, like trusted self-signed software.
This process ensures that your devices only run secure, verified software, keeping your business compliant with regulations and protected from threats. Our team handles the heavy lifting, so you don’t need to be a cybersecurity expert to stay secure. With PC Matic on your devices, allowlisting is like having a dedicated TSA agent at the security checkpoint—only letting through what’s proven to be secure.
Tailoring allowlisting with PC Matic’s Protection Modes
PC Matic knows that every small business is unique, with different needs and comfort levels when it comes to managing software. That’s why PC Matic goes a step further, offering flexible Device Protection Modes to make allowlisting work seamlessly for your environment. These modes let you customize how strictly you control which programs run on your devices, balancing security with ease of use.
Here’s a simple breakdown of our Device Protection Modes:
- Global: Only files explicitly listed on PC Matic’s global allowlist or your local allowlist can run. This mode offers a balanced approach, leveraging PC Matic’s extensive global allowlist while allowing you to approve specific software locally over time.
- Adaptive: All files and signatures must be on your local allowlist. If a signed file on your local allowlist gets updated, the new version is automatically allowed to run, even if it’s not explicitly listed, reducing manual updates.
- Standard: Similar to Adaptive, but with tighter control. Updated versions of signed files on your local allowlist must be manually added to the allowlist to run; otherwise, they’re blocked, giving you more control when applications change.
- Strict: The most rigorous mode, matching Standard’s requirements but also requiring all operating system files to be on your local allowlist, making this ideal for high-security environments. However, missing critical OS files could prevent your device from booting, meaning your organization must spend the effort to add the OS files to the allowlist before engaging this mode.
These modes empower you to tailor PC Matic’s allowlisting to your business’s specific security needs and operational preferences, ensuring compliance with regulations like NIST 800-171 or CMMC without overwhelming your team. Whether you want a hands-off approach or granular control, PC Matic makes allowlisting both secure and manageable.
Real-World Example: Totem Technologies
When Totem Technologies began using PC Matic, they encountered an issue during their initial setup that illustrates the differences in Protection Modes. During testing, the Totem Tech team switched a device from Global to Adaptive Mode. While Global Mode relied on PC Matic’s global allowlist, Adaptive Mode began depending on a local list built over time.
Because of this shift, even common applications—like the Windows Calculator (“calc.exe”)—were initially blocked. Though Calc.exe is on PC Matic’s global allowlist, it wasn’t yet included on that specific device’s local list.
While Adaptive mode can flag benign applications like Calculator, it powerfully worked to stop unwanted and unapproved applications from running as well. An example is the “ai.exe” application, associated with Microsoft’s neverending attempts to inject AI and Copilot into all of their products, whether consented to or not. Despite ai.exe being signed by Microsoft, it wasn’t on Totem Tech’s local allowlist, and so was blocked.
PC Matic’s notification of the blocked ai.exe is shown in the screenshot below:
This example shows how Protection Modes affect the user experience and how important it is to choose a mode that aligns with your team’s comfort level and security requirements. Adaptive, Standard, or Strict allowlisting Protection Modes should suffice for NIST 800-171 and CMMC requirements.
Wrapping up
So there you have an overview of application allowlisting, including why it is so powerful, and why it is required by CMMC.
We also want to thank our friends at PC Matic for a detailed description of their allowlisting product. We highly recommend their approach to allowlisting for small business in general, and we include it in our single hardened PC CUI enclave for CMMC. You can find out more about their product here.
Of course, if you’re facing CMMC, you’ll want to confirm your organization’s allowlisting approach will pass muster with a C3PAO before you schedule your final assessment. Let us know if you have any additional questions on allowlisting, and consider participating in one of our CMMC Readiness Workshops, in which we discuss this topic and more in-depth.
Good Hunting!
–Adam
