This post explains how small and medium businesses can design, deploy, and document firewalls, access control lists (ACLs), and next-generation firewalls (NGFWs) to satisfy the Compliance Framework requirement SC.L2-3.13.6 (NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2) — focusing on boundary protections, network segmentation, rule governance, monitoring, and audit evidence.
Why SC.L2-3.13.6 matters for the Compliance Framework
SC.L2-3.13.6 is aimed at controlling and protecting communications at network boundaries so that Controlled Unclassified Information (CUI) cannot be exposed or exfiltrated through poorly managed routing and filtering; the Compliance Framework requires demonstrable controls (firewalls/ACLs/NGFWs) and documentation showing that rules are intentional, least-privilege, and monitored. For a small business this means using built-in and low-cost network protections correctly and keeping clear artifacts for auditors: device configs, rule justification lists, review records, and log archives.
Design and segmentation: start with a network picture
Actionable step one: map all flows involving systems that store, process, or transmit CUI. Create a simple diagram showing Internet edge, VPN/remote access, DMZ, CUI LANs, cloud integration points, and administrative management networks. Use VLANs or VRFs to separate CUI environments from general user networks and place stateful firewall or NGFW boundary devices between these zones. Implement “deny by default” between zones and only open explicit, documented flows. For small shops, a single NGFW with zone-based rules often replaces multiple point products but ensure physical or logical separation of admin/management interfaces.
Practical segmentation example (small business)
Example: a small engineering firm has an on-prem file server with CUI (192.168.50.0/24), a corporate user VLAN (192.168.10.0/24), and an Internet-connected DMZ with a web portal (10.10.10.0/24). Implement firewall rules that allow: (a) corporate-to-file-server over TCP 445 only from allowed hosts, (b) remote VPN to file server only via authenticated VPN endpoints, and (c) block direct Internet-to-file-server traffic. Use ACLs on the access switch to ensure only the file server IP is reachable from the CUI subnet where appropriate.
Firewall and ACL implementation details (concrete examples)
Follow these practical rule-writing principles: name rules with purpose and ticket number, use explicit source/destination/port/protocol, prefer host or small-subnet granularity for CUI flows, and avoid broad “allow any any” rules. Example Cisco IOS extended ACL for allowing HTTPS access to a DMZ web server from a specific external IP: access-list 101 permit tcp host 198.51.100.23 host 10.10.10.5 eq 443 then apply with interface GigabitEthernet0/0 and ip access-group 101 in. For internal segmentation, an example to allow only SMB from specific hosts: access-list 110 permit tcp host 192.168.10.25 host 192.168.50.10 eq 445. Document each ACL entry in your rule matrix with business justification and expected logging behavior.
NGFW capabilities and how to configure them for SC.L2-3.13.6
When using NGFWs (Palo Alto, Fortinet, Check Point, Cisco FTD, etc.), leverage application identification (App-ID), user identity, URL filtering, SSL/TLS inspection (where legally and operationally permissible), and IPS/IDS. Configure policies that combine application and user context (example: allow Microsoft 365 application traffic only from corporate users to prevent shadow cloud uploads from unmanaged devices). Tune SSL inspection to capture risky app traffic while excluding personally identifiable or sensitive administrative traffic when necessary. Enable logging at allow/deny policy hits and forward logs to a centralized collector or SIEM for retention and alerting.
NGFW tuning tips
Start with a conservative policy (deny by default), then open flows based on the documented rule matrix. Use NGFW features to reduce rule count by grouping users, apps, and destinations into objects. Regularly run policy hit reports and remove unused rules older than 90 days as part of rule hygiene. For small businesses without SIEMs, configure a syslog server with 90–365 day retention and export critical deny events for quarterly review.
Monitoring, change control, and audit evidence
Compliance requires more than rules: it requires governance. Implement change control (ticketing) for all firewall/ACL changes and require rule justification, risk assessment, start/stop times, and rollback plans. Keep automated backups of device configs and timestamped rule snapshots (daily or weekly). Capture logs and generate monthly reports showing top allow/deny events, rule changes, and policy hit counts. For Compliance Framework artifacts, store: 1) current firewall/ACL configs, 2) rule matrix with business justification, 3) change tickets and approvals, 4) review meeting minutes (at least quarterly), and 5) log retention evidence. These items align with SSP and POA&M requirements for SC.L2-3.13.6.
Risks of not implementing SC.L2-3.13.6 controls
Without properly configured firewalls/ACLs/NGFWs you expose CUI to several risks: external attackers exploiting open services, lateral movement from compromised user devices to CUI systems, unmonitored data exfiltration via allowed tunnels or cloud apps, and accidental exposure due to overly broad rules. For small businesses, these failures can lead to contract loss, regulatory penalties, reputational damage, and costly incident response. Demonstrable boundary protections and logging materially reduce those risks and are required evidence in a Level 2 assessment.
In summary, meeting SC.L2-3.13.6 under the Compliance Framework means designing zone-based networks, applying least-privilege ACLs, leveraging NGFW features for application-aware and identity-aware controls, and running a disciplined governance program that captures change control, rule justification, and logs as audit evidence; for small businesses, these steps are achievable with clear diagrams, a prioritized rule matrix, routine reviews, and documented backups and logs.
