Requirement
NIST SP 800-171 REV.2 / CMMC 2.0 Level 2 - Control - SC.L2-3.13.6 – Deny network communications traffic by default and allow network communications traffic by exception (i.e., deny all, permit by exception).
Understanding the Requirement
This control requires that your network be configured to block all inbound and outbound traffic by default, and only permit specific traffic that is explicitly authorized. The goal is to implement a whitelist approach so that only the communications needed to support business functions are allowed, reducing accidental or malicious connections. For organizations following NIST SP 800-171 REV.2 / CMMC 2.0 Level 2, this means documenting which flows are allowed and enforcing those decisions with technical controls and an exception process.
Technical Implementation
- Inventory and categorize traffic. Start with a short discovery period (7–14 days) using firewall logs, flow records (NetFlow/sFlow), and endpoint data to identify normal business traffic: source/destination IPs, ports, protocols, and services. Label flows by business purpose (e.g., payroll, SaaS app, vendor backup).
- Create a documented allowlist policy. Translate the inventory into a written policy that lists allowed flows, who approved them, and why they're necessary. Include a regular review cadence (quarterly or after major changes) and an exception approval workflow.
- Implement deny-by-default firewall rules. On perimeter and internal firewalls, apply a default deny (implicit or explicit) for both inbound and outbound rulesets. Only create rules that match entries in the allowlist. Use least-privilege ports/protocols and restrict by IP or subnet where possible.
- Segment the network and apply micro-perimeters. Use VLANs, internal firewalls, or host-based firewalls to separate critical systems (e.g., servers with controlled unclassified information) from general user networks. Limit east-west traffic so a compromise in one segment cannot freely access others.
- Control remote access and third-party connections. Require authenticated, encrypted VPNs or zero-trust access tools. Allow vendor or cloud vendor traffic only from known addresses and enforce strict rules that permit only the required management ports and protocols.
- Monitor, log, and validate rules. Enable logging for allowed and denied traffic, retain logs for incident response, and review exceptions and denied attempts regularly. Use periodic testing (scheduled scans and simulated traffic) and change control to ensure rules remain accurate and do not drift over time.
Example in a Small or Medium Business
Acme Manufacturing (70 employees) needs to protect design files and supplier data while keeping cloud services and remote users functional. The IT lead runs a two-week capture of firewall and proxy logs and identifies the minimal set of services required: Office365, the ERP vendor IP ranges on specific ports, a cloud backup service, and approved remote support tools. They document these flows in an allowlist, including business justification and the approving manager, then create firewall rules that deny all other outbound and inbound traffic. Internally, Acme segments engineering workstations from the guest Wi‑Fi and from the administrative network so designers cannot reach payroll systems. For remote access, they replace broad VPN access with a zero-trust gateway that permits only the specific applications each user needs. They implement a simple exception ticket process for temporary allowances (with automatic expiration), and they schedule monthly reviews of logs and firewall rules. Over the next quarter Acme blocks several unexpected outbound connections from an infected workstation, verifies the cause, and tightens host-based firewall rules—demonstrating the deny-by-default posture reduced their exposure.
Summary
Adopting a deny-all, permit-by-exception approach requires both clear policy and precise technical enforcement: inventory your traffic, document an allowlist with approvals, implement deny-by-default firewall and segmentation controls, and maintain monitoring and change control. For SMBs this combination limits unnecessary connections, reduces the attack surface, and ensures that only vetted, business-critical communications are permitted—meeting the control's intent while keeping operations functional through documented exceptions and regular review.
