Apply deny-by-exception policy to prevent the use of unauthorized software
📖 What This Means
This practice requires organizations to implement a 'deny-by-exception' policy for software usage, meaning that only explicitly approved software is allowed to run on systems, while all other software is automatically blocked. This approach minimizes the risk of malicious or unauthorized software compromising systems. For example, a company might create a list of approved applications like Microsoft Office and antivirus software, and block everything else. Another example is allowing only specific engineering tools in a manufacturing environment while preventing employees from installing personal software like games or media players. This policy ensures that systems run only what is necessary and authorized, reducing vulnerabilities.
🎯 Why It Matters
Unauthorized software can introduce malware, create security vulnerabilities, or lead to compliance violations. For instance, the 2017 NotPetya ransomware attack spread through unauthorized software updates, causing billions in damages. A deny-by-exception policy prevents such incidents by ensuring only vetted software is used. From the DoD's perspective, this control is critical to protecting Controlled Unclassified Information (CUI) and maintaining system integrity. Without this policy, organizations risk data breaches, operational disruptions, and reputational damage. Implementing this control helps mitigate these risks and ensures compliance with CMMC requirements.
✅ How to Implement
- 1. Use AWS Systems Manager or Azure Policy to define allowed software.
- 2. Configure Microsoft Defender for Cloud to enforce software restrictions.
- 3. Implement Application Control via GCP Security Command Center.
- 4. Regularly update the approved software list in your cloud management console.
- 5. Enable logging and monitoring to detect unauthorized software attempts.
- 6. Integrate with CI/CD pipelines to ensure only approved software is deployed.
- 7. Conduct periodic audits to verify compliance.
📋 Evidence Examples
Approved Software List
Group Policy Configuration Screenshot
Audit Logs
Policy Document
Training Records
📝 SSP Guidance
Use this guidance when writing the System Security Plan (SSP) narrative for this control.
How to Write the SSP Narrative
For CM.L2-3.4.8 ("Apply deny-by-exception policy to prevent the use of unauthorized software"), your SSP narrative should specifically describe: (1) the tools and technologies you use to implement this control, (2) the configuration or process that enforces it, (3) who is responsible for maintaining it, and (4) what evidence proves it's working. Describe your configuration management process, including baseline configurations, change control procedures, vulnerability management, and how configuration compliance is monitored and enforced. Be specific -- name your actual products, settings, and responsible personnel.
Example SSP Narratives
"CM.L2-3.4.8 is implemented using cloud-native controls. [Organization] uses [specific cloud service/feature] to apply deny-by-exception policy to prevent the use of unauthorized software. The configuration is managed through [Azure Policy/AWS Config/Terraform] and monitored via [SIEM tool]. Responsible party: [IT Security Manager]. Evidence: [specific artifact, e.g., 'Azure AD Conditional Access policy screenshot, CloudTrail logs']."
"CM.L2-3.4.8 is implemented through on-premise infrastructure controls. [Organization] uses [Active Directory/Group Policy/specific tool] to apply deny-by-exception policy to prevent the use of unauthorized software. Configuration is documented in [location] and audited [frequency]. Responsible party: [System Administrator]. Evidence: [specific artifact, e.g., 'Group Policy export, Windows Event logs']."
"CM.L2-3.4.8 is implemented across both cloud and on-premise environments. [Organization] uses [Azure AD Connect/hybrid tool] to ensure consistent enforcement. Cloud resources are managed via [cloud tool] and on-premise systems via [on-prem tool]. Both environments report to [centralized SIEM]. Responsible party: [IT Director]. Evidence: [artifacts from both environments]."
System Boundary Considerations
- • Identify all system types within the CUI boundary requiring baselines
- • Document configuration management tools and CMDB
- • Map change control workflow from request to implementation
- • Ensure this control covers all systems within your defined CUI boundary where apply deny-by-exception policy to prevent the use of unauthorized software applies
- • Document any systems where this control is not applicable and explain why
Key Documentation to Reference in SSP
- 📄 Configuration Management Policy
- 📄 Baseline configuration documents
- 📄 Change management records
- 📄 CMDB/asset inventory
- 📄 Evidence artifacts specific to CM.L2-3.4.8
- 📄 POA&M entry if control is not fully implemented
What the Assessor Looks For
The assessor will compare actual system configurations against documented baselines, review change tickets for proper approval workflow, and verify vulnerability remediation within SLA.
💬 Self-Assessment Questions
Use these questions to assess your compliance. Each "NO" answer provides specific remediation guidance.
Question 1: Do you have a documented deny-by-exception policy for software?
Question 2: Is the approved software list up to date?
Question 3: Are software restrictions enforced on all endpoints?
Question 4: Are logs maintained for unauthorized software attempts?
Question 5: Have employees been trained on the policy?
⚠️ Common Mistakes (What Auditors Flag)
1. Incomplete approved software list
2. Missing enforcement on endpoints
3. Lack of logging
4. Outdated policy document
5. Insufficient employee training
📚 Parent Policy
This practice is governed by the Configuration Management Policy