Skip to main content
NetStable
Level 2 SC.L2-3.13.6

Deny network communications traffic by default and allow by exception

📖 What This Means

This practice means that your network should block all traffic by default and only allow specific traffic that is explicitly permitted. Think of it like a bouncer at a club who denies everyone entry unless they are on the guest list. This approach minimizes the risk of unauthorized access and reduces the attack surface of your network. For example, if you have a web server, only traffic to port 80 (HTTP) and port 443 (HTTPS) should be allowed, while all other ports should be blocked. Another example is allowing only specific IP addresses to access your internal systems, blocking everything else.

🎯 Why It Matters

Allowing all traffic by default creates a significant security risk, as attackers can exploit open ports and services to gain unauthorized access to your network. For instance, in the 2017 Equifax breach, attackers exploited an unpatched vulnerability in a web application that was accessible from the internet. By denying traffic by default, you reduce the chances of such breaches. The DoD and CMMC emphasize this control because it is a fundamental aspect of network security, protecting sensitive defense information from unauthorized access and cyber threats.

How to Implement

  1. 1. Configure Network Security Groups (NSGs) in Azure or Security Groups in AWS to deny all inbound and outbound traffic by default.
  2. 2. Create explicit rules to allow traffic only to specific services (e.g., HTTP/HTTPS).
  3. 3. Use AWS WAF or Azure Firewall to add additional layer of protection.
  4. 4. Regularly review and update rules to ensure only necessary traffic is allowed.
  5. 5. Enable logging and monitoring for all traffic to detect anomalies.
⏱️
Estimated Effort
Implementation: 2-3 days; Ongoing Management: Monthly reviews (1-2 hours). Skill Level: Intermediate (network administrator).

📋 Evidence Examples

Firewall Configuration

Format: PDF/Text File
Frequency: Initial configuration and after any changes.
Contents: List of all firewall rules showing default deny and explicit allow rules.
Collection: Export from firewall management console.

Network Diagram

Format: PDF/Visio File
Frequency: Updated quarterly or after significant changes.
Contents: Diagram showing network segments and traffic flow.
Collection: Created using network diagramming tools.

Firewall Logs

Format: CSV/Log File
Frequency: Monthly.
Contents: Logs showing blocked and allowed traffic.
Collection: Export from firewall management console.

Security Policy

Format: PDF/Word Document
Frequency: Reviewed annually.
Contents: Policy document stating the default deny and allow by exception approach.
Collection: Created by IT security team.

Testing Results

Format: PDF/Excel File
Frequency: After each test (semi-annually).
Contents: Results of penetration testing showing effectiveness of default deny rules.
Collection: Generated by security testing tools.

📝 SSP Guidance

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

How to Write the SSP Narrative

For SC.L2-3.13.6 ("Deny network communications traffic by default and allow 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.L2-3.13.6 is implemented using cloud-native controls. [Organization] uses [specific cloud service/feature] to deny network communications traffic by default and allow by exception. 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.L2-3.13.6 is implemented through on-premise infrastructure controls. [Organization] uses [Active Directory/Group Policy/specific tool] to deny network communications traffic by default and allow by exception. 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.L2-3.13.6 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 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.L2-3.13.6
  • 📄 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 all traffic denied by default in your firewall configuration?

✅ YES → Proceed to Q2
❌ NO → GAP: Configure your firewall to deny all traffic by default. Remediation: 1 day.
Remediation:
Configure firewall to deny all traffic by default.

Question 2: Are explicit rules in place to allow only necessary traffic?

✅ YES → Proceed to Q3
❌ NO → GAP: Create explicit rules to allow only necessary traffic. Remediation: 1 day.
Remediation:
Create explicit allow rules for necessary traffic.

Question 3: Are firewall rules regularly reviewed and updated?

✅ YES → Proceed to Q4
❌ NO → GAP: Schedule monthly reviews of firewall rules. Remediation: Ongoing.
Remediation:
Schedule monthly reviews of firewall rules.

Question 4: Is logging enabled for all traffic?

✅ YES → Proceed to Q5
❌ NO → GAP: Enable logging for all traffic. Remediation: 1 hour.
Remediation:
Enable logging for all traffic.

Question 5: Are alerts set up for suspicious activity?

✅ YES → Compliance Confirmed
❌ NO → GAP: Set up alerts for suspicious activity. Remediation: 2 hours.
Remediation:
Set up alerts for suspicious activity.

⚠️ Common Mistakes (What Auditors Flag)

1. Not configuring default deny rule.

Why this happens: Misunderstanding of the requirement or oversight during configuration.
How to avoid: Double-check firewall configuration to ensure default deny rule is in place.

2. Allowing unnecessary traffic.

Why this happens: Lack of regular review of firewall rules.
How to avoid: Conduct monthly reviews of firewall rules and remove unnecessary exceptions.

3. Inconsistent rules across environments.

Why this happens: Different teams managing cloud and on-premise environments.
How to avoid: Use centralized management tools for hybrid environments.

4. Missing documentation.

Why this happens: Focus on implementation without documenting the process.
How to avoid: Document all firewall rules and review them during audits.

5. Not enabling logging.

Why this happens: Focus on blocking traffic without monitoring.
How to avoid: Enable logging for all traffic and set up alerts for suspicious activity.

📚 Parent Policy

This practice is governed by the System and Communications Protection Policy

View SC Policy →

📚 Related Controls