SC.L1-3.13.3: Deny network communications traffic by default and allow network communications traffic by exception

📖 What This Means

This practice means that your network should block all traffic by default and only allow specific traffic that you explicitly permit. Think of it like locking all the doors in your house and only unlocking the ones you need to use. For example, if you have a web server, you would only allow traffic to port 80 or 443 (for HTTP and HTTPS) and block everything else. This reduces the risk of unauthorized access or attacks. Another example is allowing only your IT team to access the management interface of your firewall while blocking everyone else. The goal is to minimize exposure and reduce the attack surface.

🎯 Why It Matters

Allowing all network traffic by default poses a significant security risk, as attackers can exploit open ports or services to gain unauthorized access. For instance, in the 2017 Equifax breach, attackers exploited an unpatched vulnerability in a web application that was publicly accessible. By denying traffic by default, you reduce the likelihood of such incidents. The DoD and CMMC emphasize this control because it is a foundational security measure to protect sensitive data and systems. Failure to implement this can lead to data breaches, financial losses, and reputational damage.

✅ How to Implement

1. Use cloud-native firewall services like AWS Security Groups, Azure Network Security Groups, or GCP Firewall Rules.
2. Configure these firewalls to deny all inbound and outbound traffic by default.
3. Create explicit rules to allow only necessary traffic, such as HTTPS (port 443) for web servers or SSH (port 22) for management.
4. Regularly review and update firewall rules to ensure they align with current business needs.
5. Enable logging and monitoring for firewall rules to detect anomalies.
6. Use tools like AWS Config or Azure Policy to enforce compliance with firewall rules.
7. Document all rules and exceptions in a centralized policy document.

⏱️

Estimated Effort

4-8 hours for initial setup, plus ongoing maintenance. Requires intermediate networking knowledge.

📋 Evidence Examples

Firewall Configuration Document

Format: PDF/DOCX

Frequency: Update quarterly or when changes are made.

Contents: List of all firewall rules, including deny-by-default policy and exceptions.

Collection: Export from firewall management interface or cloud console.

Firewall Rule Screenshots

Format: PNG/JPG

Frequency: Capture during audits or changes.

Contents: Screenshots of firewall rules showing deny-by-default and allowed exceptions.

Collection: Capture from firewall management interface.

Firewall Logs

Format: CSV/Log File

Frequency: Review weekly.

Contents: Logs showing denied and allowed traffic.

Collection: Export from firewall or cloud logging service.

Policy Document

Format: PDF/DOCX

Frequency: Review annually.

Contents: Written policy detailing deny-by-default approach and exception process.

Collection: Store in document management system.

Audit Report

Format: PDF/DOCX

Frequency: Audit quarterly.

Contents: Report from firewall rule audit, including any changes made.

Collection: Generate during periodic audits.

📝 SSP Guidance

Use this guidance when writing the System Security Plan (SSP) narrative for this control.

How to Write the SSP Narrative

For SC.L1-3.13.3 ("Deny network communications traffic by default and allow network communications traffic by exception"), 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 network security architecture, including segmentation, encryption standards, VPN configuration, session management, key management, and monitoring capabilities. Be specific -- name your actual products, settings, and responsible personnel.

Example SSP Narratives

Cloud (Azure/AWS)

"SC.L1-3.13.3 is implemented using cloud-native controls. [Organization] uses [specific cloud service/feature] to deny network communications traffic by default and allow network communications .... 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']."

On-Premise

"SC.L1-3.13.3 is implemented through on-premise infrastructure controls. [Organization] uses [Active Directory/Group Policy/specific tool] to deny network communications traffic by default and allow network communications .... Configuration is documented in [location] and audited [frequency]. Responsible party: [System Administrator]. Evidence: [specific artifact, e.g., 'Group Policy export, Windows Event logs']."

Hybrid

"SC.L1-3.13.3 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

• Document network architecture with CUI boundary clearly marked
• Identify all encryption mechanisms (at rest and in transit)
• Specify network monitoring and IDS/IPS deployment
• Ensure this control covers all systems within your defined CUI boundary where deny network communications traffic by default and allow network communications traffic by exception applies
• Document any systems where this control is not applicable and explain why

Key Documentation to Reference in SSP

📄 System and Communications Protection Policy
📄 Network architecture diagram
📄 Firewall rule documentation
📄 Encryption configuration documentation
📄 Evidence artifacts specific to SC.L1-3.13.3
📄 POA&M entry if control is not fully implemented

What the Assessor Looks For

The assessor will review network diagrams for proper segmentation, test encryption settings, verify VPN split tunneling is disabled, and check FIPS 140-2 validation of cryptographic modules.

💬 Self-Assessment Questions

Use these questions to assess your compliance. Each "NO" answer provides specific remediation guidance.

Question 1: Is your firewall configured to deny all traffic by default?

✅ YES → Proceed to Q2

❌ NO → GAP: Configure your firewall to deny all traffic by default. Use your firewall management interface to set this rule. Complete within 1 week.

Remediation:

Configure your firewall to deny all traffic by default. Use your firewall management interface to set this rule. Complete within 1 week.

Question 2: Have you created explicit rules to allow only necessary traffic?

✅ YES → Proceed to Q3

❌ NO → GAP: Identify necessary traffic (e.g., HTTP/HTTPS, SSH) and create allow rules. Complete within 1 week.

Remediation:

Identify necessary traffic (e.g., HTTP/HTTPS, SSH) and create allow rules. Complete within 1 week.

Question 3: Are firewall logs enabled and reviewed regularly?

✅ YES → Proceed to Q4

❌ NO → GAP: Enable logging on your firewall and set up a process for regular review. Complete within 2 weeks.

Remediation:

Enable logging on your firewall and set up a process for regular review. Complete within 2 weeks.

Question 4: Is there a documented policy for firewall rules and exceptions?

✅ YES → Proceed to Q5

❌ NO → GAP: Create a policy document detailing the deny-by-default approach and exception process. Complete within 1 week.

Remediation:

Create a policy document detailing the deny-by-default approach and exception process. Complete within 1 week.

Question 5: Are firewall rules audited quarterly?

✅ YES → Compliance confirmed.

❌ NO → GAP: Schedule quarterly firewall rule audits and document findings. Complete within 1 month.

Remediation:

Schedule quarterly firewall rule audits and document findings. Complete within 1 month.

⚠️ Common Mistakes (What Auditors Flag)

1. Leaving firewall rules overly permissive.

Why this happens: Lack of understanding or convenience for IT staff.

How to avoid: Adopt a deny-by-default approach and only allow necessary traffic.

2. Failing to document firewall rules.

Why this happens: Focus on technical implementation over documentation.

How to avoid: Maintain a centralized document detailing all firewall rules and exceptions.

3. Not reviewing firewall logs.

Why this happens: Lack of resources or prioritization.

How to avoid: Set up automated log reviews and alerts for suspicious activity.

4. Forgetting to update firewall rules after changes.

Why this happens: Poor change management processes.

How to avoid: Implement a change management process that includes firewall rule updates.

5. Not auditing firewall rules regularly.

Why this happens: Lack of awareness or prioritization.

How to avoid: Schedule quarterly audits and document findings.

📚 Parent Policy

This practice is governed by the System and Communications Protection Policy

View SC Policy →

📚 Related Controls

SC.L1-3.13.1 - Monitor, control, and protect communications at external and internal network boundaries. SC.L1-3.13.2 - Implement subnetworks for publicly accessible system components. SC.L2-3.13.4 - Prevent unauthorized and unintended information transfer via shared system resources.