This post gives practical, actionable steps for implementing network controls that meet FAR 52.204-21 and CMMC 2.0 Level 1 (Control AC.L1-B.1.III) expectations—specifically focused on firewall rules, whitelisting (allowlisting), and access control lists (ACLs) you can implement today within the Compliance Framework to reduce risk and produce auditor-ready evidence.
Overview and implementation approach
Under the Compliance Framework, AC.L1-B.1.III expects you to limit network access to authorized communications and services; the simplest, most defensible approach is "default deny" with explicit allow rules, documented justification for each exception, and logging/audit trails for rule changes. Start by mapping needed services (e.g., business apps, vendor portals, patch management), then create a minimal rule set: deny all inbound by default, allow only necessary inbound services, and restrict outbound traffic to known destinations where possible. Document the business reason (who, what, why) for every rule so auditors can quickly verify intent.
Firewall rules: concrete examples and priorities
When creating firewall rules, use service-specific ports and source/destination constraints. For example, allow inbound HTTPS only to a DMZ web server from the internet on TCP 443 with destination IP 198.51.100.10, and deny all other inbound traffic. In practice, implement rules like: allow TCP 443 from 0.0.0.0/0 to 198.51.100.10, allow TCP 22 from your corporate VPN subnet only (e.g., 10.10.0.0/24) to management hosts, and a default deny all policy at the end of the rule chain. Example snippets you can adapt quickly:
# iptables example (Linux firewall)
iptables -P INPUT DROP
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -d 198.51.100.10 -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -s 10.10.0.0/24 -d 198.51.100.20 -j ACCEPT
# AWS security group example (conceptual)
Allow: TCP 443 from 0.0.0.0/0 to EC2-Web01
Allow: TCP 22 from 10.10.0.0/24 to EC2-Bastion
Implicit Deny: no other inbound rules
Whitelisting / allowlisting strategies
Whitelisting means allowing only approved IPs, ports, or domains. For small businesses, implement IP allowlists for management interfaces (SSH, RDP) and vendor access; for cloud-hosted apps, use application-layer allowlists (Web Application Firewall or proxy) combined with DNS-based filtering for outbound traffic. Maintain an "approved destinations" list for patch servers, SaaS providers, and payment processors; configure outbound ACLs or security groups to permit only those IP ranges and FQDNs. Use short-lived exceptions for contractors—create a time-limited rule with automated removal or a manual change-control ticket that includes expiration.
ACLs on routers and switches: practical details
Network ACLs at the router/switch layer provide defense-in-depth and can stop lateral movement. On Cisco IOS, use extended ACLs to filter by source/destination and port, and apply them inbound on edge interfaces. Example Cisco commands: ip access-list extended EDGE-IN, permit tcp any host 198.51.100.10 eq 443, permit tcp 10.10.0.0 0.0.255.255 host 198.51.100.20 eq 22, then interface GigabitEthernet0/1 and ip access-group EDGE-IN in. Remember ACL order matters: first match wins. Test ACLs in a maintenance window and keep rollback commands ready.
Operational controls: logging, change control, and testing
Compliance is as much about proving control as it is implementing it. Enable detailed logging for firewall rule hits, send logs to a centralized syslog/SIEM (or cloud logging service), and retain them per your policy (typically 90 days+ for basic audit trails). Implement a rule-change process: every new or modified firewall rule must have a ticket with owner, justification, and expected expiry if temporary. Regularly test controls with internal scans (nmap, Nessus) and external scans from a trusted provider to validate no unintended open ports. Capture screenshots of rule tables and export configuration files to provide auditors evidence of your implementation.
Small-business real-world scenarios
Scenario 1: Small defense subcontractor with on-prem office and cloud servers. The contractor placed a managed UTM at the edge, configured default-deny inbound, allowed outbound only to known SaaS IP ranges, and restricted RDP/SSH to their VPN subnet. They documented each rule in a spreadsheet linked to tickets and enabled syslog forwarding to a low-cost cloud SIEM. Scenario 2: A distributed team using AWS only. They used Security Groups and NACLs: Security Groups provide instance-level allow lists (no deny rules), while a NACL between subnets provided stateless deny entries for risky ports. They enforced admin access through a bastion host that only accepts SSH from the corporate office IP allowlist and recorded all changes in their cloud-change log for auditors.
Risks of not implementing and compliance tips
Failing to implement these controls increases the likelihood of data exposure, lateral movement by attackers, ransomware propagation, and noncompliance penalties or contract loss under FAR 52.204-21. Practical compliance tips: start small and document everything; use templates for rule justification; automate expiry for temporary rules; use MFA and jump hosts for administration; keep firmware and signatures updated on firewall appliances; and schedule quarterly reviews of rules with business owners to remove stale entries. For CMMC Level 1, being able to show a maintained rule set, logs, and change records will satisfy most assessor checks.
In summary, meeting AC.L1-B.1.III for FAR 52.204-21 / CMMC 2.0 Level 1 is achievable for small businesses by applying a "deny by default" stance, implementing tight firewall rules and allowlists, using ACLs on infrastructure, enabling centralized logging, and enforcing change control and periodic testing; document each step and keep evidence ready for auditors to demonstrate that access is limited to authorized communications only.
