CMMC Practice CM.3.069
Apply deny-by-exception (blacklisting) policy to prevent the use of unauthorized software or deny-all, permit-by-exception (whitelisting) policy to allow the execution of authorized software.
Bold Coast Security Guidance
For Level 2 compliance your policy must state that one or more approaches is required to restrict software to approved and required applications, and prevent unauthorized software from running in your environment. For Level 3 compliance, there must be a management plan describing how the policy is implemented and sustained, measured and reported to appropriate stakeholders.
Whitelisting and blacklisting are two approaches to limiting exposure, but they are not always exclusive. Some systems, like Internet Filtering systems, allow both approaches simultaneously, while underpinning control with content-type restrictions, e.g., block all social media or access to personal webmail accounts.
However, at the core these are different approaches related to maturity. Blacklisting, or deny-by-exception, is the place to start if your organization is less mature in the information security function. Blacklisting requires that you identify applications that you will not allow to run in your IT environment. This is an ongoing process. As you discover new software to blacklist, you add that to the system you're using to restrict software.
Whitelisting, or permit-by-exception, is the better approach from a security perspective, though it requires more maturity, or what we like to call "organizational self-awareness". This is due to the fact that there are many hidden dependencies in any IT environment. Once you're approaching software restriction from the whitelisting side, you're denying all executable programs that are not on the whitelist. This means, in some cases, systems will stop functioning because perhaps they shared a DLL, or there is a component software or service that must be enabled for another application to work.
We recommend starting the practice with blacklisting, while building the internal intelligence that comes with planning to move to a whitelisting approach. Some prerequisites for this capability include:
- Creating and maintaining an Approved Software list.
- Researching each approved software, as well as operating systems, to ensure there is complete understanding of requirements, dependencies, and possible conflicts in your IT environment.
- Having a mature change management function established so that back-out plans -going back to a previous state if a change has a negative impact- are reliable if the worst should happen.
If these core capabilities are in place, then whitelisting is the best way to go. The main reason for this, is that any new software, including unknown malicious software, will not be permitted to run in your environment. New software you need must be added to the whitelist before it will run.
DRAFT NIST SP 800-171 R2
The process used to identify software programs that are not authorized to execute on systems is commonly referred to as blacklisting . The process used to identify software programs that are authorized to execute on systems is commonly referred to as whitelisting.
Whitelisting is the stronger of the two policies for restricting software program execution. In addition to whitelisting, organizations consider verifying the integrity of whitelisted software programs using, for example, cryptographic checksums, digital signatures, or hash functions. Verification of whitelisted software can occur either prior to execution or at system startup.