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.
\n\nSC.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.
\n\nActionable 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.
\n\nExample: 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.
\n\nFollow 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.
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.
\n\nStart 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.
\n\nCompliance 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.
\n\nWithout 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.
\n\nIn 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.
", "plain_text": "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.\n\nWhy SC.L2-3.13.6 matters for the Compliance Framework\nSC.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.\n\nDesign and segmentation: start with a network picture\nActionable 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.\n\nPractical segmentation example (small business)\nExample: 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.\n\nFirewall and ACL implementation details (concrete examples)\nFollow 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.\n\nNGFW capabilities and how to configure them for SC.L2-3.13.6\nWhen 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.\n\nNGFW tuning tips\nStart 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.\n\nMonitoring, change control, and audit evidence\nCompliance 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.\n\nRisks of not implementing SC.L2-3.13.6 controls\nWithout 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.\n\nIn 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." }, "metadata": { "description": "Practical guidance for implementing firewalls, ACLs, and NGFW controls to meet NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 SC.L2-3.13.6 requirements for protecting CUI at network boundaries.", "permalink": "/how-to-use-firewalls-acls-and-ngfws-to-achieve-nist-sp-800-171-rev2-cmmc-20-level-2-control-scl2-3136-compliance.json", "categories": [], "tags": [] } }