CMMC Practice CM.L2-3.4.8

Application Execution Policy: 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.

Monarch ISC Guidance

Allow-listing or deny-listing 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. Deny-listing, or deny-by-exception, is the place to start if your organization is less mature in the information security function. Deny-listing 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 deny, you add that to the system you're using to restrict software. Allow-listing, 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 allow-listing side, you're denying all executable programs that are not on the allow-list. 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 deny-listing, while building the internal intelligence that comes with planning to move to a allow-listing 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, or 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 allow-listing 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 allow-list before it will run.

Security Catapult

Be prepared for CMMC

Our Q&A assessment tool is designed by security advisors for MSPs and DoD contractors of all sizes.

Try now for free

Security Catapult

Understand your gaps

See compliance gaps, compliance scores and proactive security tasks in a single interface.

Try now for free

Security Catapult

Validate NIST SP 800-171

Based on your CMMC answers, we let you know where you stand on NIST.

Try now for free

Security Catapult

Build a plan of action

Track your burn down and stay on top of security needs.

Try now for free

Security Catapult

Build your policy

Say goodbye to maintaining a security policy. We do it for you.

Try now for free

Discussion From Source

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. NIST SP 800-167 provides guidance on application whitelisting.