This post gives a practical, compliance-focused walkthrough for implementing deny-by-default network controls to satisfy NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 control SC.L2-3.13.6: deny network communications by default and allow only necessary traffic. It is written for small businesses and compliance teams who need concrete steps, sample rules, and validation methods to show auditors that network communications are restricted to the minimum necessary.
High-level implementation approach (Compliance Framework)
Start by treating the requirement as a network access control policy: default-deny all inbound and lateral traffic, then explicitly allow only what is needed. Implementation steps: (1) inventory hosts, services, and users that require network access; (2) segment networks into zones (management, user, servers, CUI processing); (3) build a baseline deny-by-default policy on perimeter and internal firewalls/ACLs; (4) create a documented exception process and change control; (5) validate and monitor. For the Compliance Framework context, map each rule and zone to the control objective, keep evidence (rule screenshots, change tickets, logs), and schedule periodic re-certification of rules.
Inventory, segmentation, and least privilege
Practical implementation begins with discovery: use asset inventory tools (e.g., Nmap, endpoint inventory, DHCP logs) to list IPs, OS, and services. Segment into VLANs or security zones so you can apply different deny-by-default policies per zone (example: separate CUI servers into a restricted VLAN with only service ports open). Build an access matrix: for each source zone/user and destination service, document the business justification and protocol/port. This matrix becomes the source of truth for firewall rules and helps during audits to show "why" a rule exists.
Making deny-by-default concrete — firewall/ACL examples
On perimeter and internal devices, implement an implicit deny at the end of the rulebase and avoid overly broad allow rules. Example iptables sequence for a Linux gateway (simplified):
iptables -P INPUT DROP
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -s 198.51.100.10 -j ACCEPT (management IP only)
iptables -A INPUT -p tcp --dport 443 -s 0.0.0.0/0 -j ACCEPT (public web service)
Note the policy: default DROP, then allow established traffic, then explicit permits with source scoping. On Cisco IOS routers, an ACL entry might look like:
access-list 101 permit tcp host 198.51.100.10 host 192.0.2.20 eq 22
access-list 101 permit tcp any host 192.0.2.30 eq 443
interface GigabitEthernet0/1
ip access-group 101 in
End with an implicit "deny ip any any" by rule ordering or use an explicit deny to make intent clear.
Cloud and host-based controls — specific examples
Cloud platforms differ: AWS Security Groups are stateful and are used as explicit allow lists, while Network ACLs (NACLs) are stateless and evaluated in order. Example AWS best practice for a small business: Security Group A for web servers: inbound TCP 443 from 0.0.0.0/0; inbound TCP 22 only from the corporate management IP; outbound allowed as needed but restrict to known backend IPs where possible. For Azure, use NSGs with service tags and application security groups to reduce CIDR management. On hosts, enforce local firewall rules (Windows Defender Firewall, nftables) to add defense-in-depth. Ensure VPN endpoints and jump hosts reside in dedicated, strictly controlled zones and require MFA for access — do not rely on broad administrative rules across zones.
Testing, logging, and change control
Verification is essential for compliance evidence. Test rules with active scans (nmap) from multiple network locations to ensure only expected ports respond. Example tests: external scan from the Internet shows only published service ports; internal lateral scan from a user VLAN shows no access to CUI server ports. Enable logging for denied traffic on firewalls and export to a SIEM or centralized log store for retention. Implement a formal change control process: every rule change must reference an access matrix entry or approved exception ticket, with reviewer and expiration date. Keep snapshots of rulebases and change history for audit trails.
Risk of not implementing deny-by-default (and mitigation tips)
Failing to deny by default leaves the network exposed to scanning, lateral movement, and credential theft, increasing the risk of CUI exfiltration and contract loss with DoD customers. Common pitfalls: wide-open rules like 0.0.0.0/0 for management ports, stale rules that are no longer needed, and undocumented exceptions. Mitigations: enforce least privilege, use IP/source scoping, apply time-limited exceptions, and automate rule review (e.g., quarterly reviews with justification required or automated unused rule detection). For small businesses, use a UTM or managed firewall service if you lack in-house expertise, but still insist on rule documentation and log forwarding for auditability.
Compliance tips and best practices
Practical tips to pass an audit under the Compliance Framework: keep a rulebook that maps each allow rule to a business justification and control reference (SC.L2-3.13.6), record the reviewer and review date, and capture before/after screenshots of rule changes. Avoid "any-any" or broad CIDR allowances; if you must open to the Internet, restrict to application-level controls and use web application firewalls. Implement defense-in-depth: firewall/ACLs + host firewalls + VPN + MFA + IDS/IPS. Automate evidence collection where possible (scripts that pull rulebases and produce timestamped exports) to save time during assessments.
In summary, meeting NIST SP 800-171 Rev.2 / CMMC 2.0 SC.L2-3.13.6 means enforcing deny-by-default across perimeter and internal boundaries, documenting explicit allow rules with business justification, testing to prove only necessary communications succeed, and maintaining logs and change control as audit evidence. For small businesses, focus first on inventory and segmentation, then implement explicit allow rules with strict source scoping, VPN/jump hosts with MFA for management, and a repeatable review process so the network stays locked down and auditable over time.
