This post provides a practical, step-by-step approach for small businesses to implement VLAN and subnetwork segmentation for publicly accessible systems in order to meet FAR 52.204-21 requirements and CMMC 2.0 Level 1 control SC.L1-B.1.XI, describing configuration patterns, test procedures, and compliance evidence to collect.
Implementation overview and compliance context
At a high level, SC.L1-B.1.XI expects organizations to separate public-facing systems from internal or sensitive systems so that unauthorized access or exploitation of public services does not automatically expose internal resources. FAR 52.204-21 requires basic safeguarding of information systems used for government contracts. For a small business this typically means placing web servers, mail relays, and other internet-facing hosts into a dedicated VLAN/subnet (a DMZ) with tightly controlled inbound and outbound flows, enforcing management-plane segregation, and proving the controls through documentation and observable configuration.
Implementation steps
Step 1 — Inventory and classify public-facing systems
Begin by creating an inventory: list every host or service that is reachable from the internet (web portals, API endpoints, VPN gateways, mail relays, FTP, etc.), record its function, required protocols/ports, owner, and sensitivity of data processed. This is your scope for segmentation. For example, a small contractor hosting a customer portal would mark the portal servers as "public" and any database servers storing CUI as "internal" — these must not share the same VLAN/subnet.
Step 2 — Design VLAN and subnet topology
Design a minimal, clear addressing plan. Example for a small shop: VLAN 100/10.10.100.0/24 for Public DMZ servers, VLAN 10/10.10.10.0/24 for Corporate workstations, VLAN 20/10.10.20.0/28 for Management interfaces, VLAN 200/172.16.200.0/24 for Guest Wi‑Fi. Decide which VLANs require routing between them and ensure routing only occurs through a controlled device (typically a firewall). Apply the principle "no implicit trust" — default deny between VLANs, allow only explicitly required flows (e.g., web server to backend DB on 10.10.10.50 TCP/3306 only from the app server IPs).
Step 3 — Configure switches and routers (technical details)
On switches, create VLANs and assign access/trunk ports appropriately. Example Cisco configuration snippets: "vlan 100" then on the server access port "switchport mode access; switchport access vlan 100; switchport port-security maximum 2; switchport port-security violation restrict; switchport port-security mac-address sticky". On the L3 device create an SVI: "interface Vlan100; ip address 10.10.100.1 255.255.255.0". Use 802.1Q trunks between switches and the distribution router/firewall, and tag only the VLANs you need on each trunk. For small offices using managed cloud-managed switches, apply equivalent VLAN configuration in the vendor UI and enable port isolation features for ports hosting public servers.
Step 4 — Implement access control and perimeter enforcement
Do not rely on VLANs alone — enforce inter-VLAN policies on a firewall or router. Example ACL approach: block all traffic from the public VLAN to internal VLANs except specific allowed flows (e.g., permit tcp host 10.10.100.10 eq 443 any to 10.10.10.50 eq 443 if a reverse proxy must reach an internal API) and explicitly deny everything else. Use NAT for outward connections if needed and place services that require inbound internet access behind reverse proxies or load balancers. Consider an inline WAF/CDN for web applications and a separate management VLAN with access allowed only from a hardened jump host via SSH with key auth and MFA where possible.
Step 5 — Management, monitoring, and logging
Segmentation must be observable: send switch and firewall logs to a central syslog (or cloud SIEM) and enable flow logging (NetFlow/IPFIX) to show traffic patterns. Configure SNMP read-only community strings or SNMPv3 for device monitoring, and enable audit logging for configuration changes. Implement periodic automated scans (authenticated and unauthenticated) of the public VLAN to detect open ports and misconfigurations; save scan reports as evidence. For small businesses, services like open-source osquery, OSSIM, or lightweight cloud logging can be sufficient if retained and indexed.
Step 6 — Documentation, testing, and evidence collection
Create a segmentation policy document that maps VLAN IDs to purposes, lists allowed flows with justification, and documents owners and change-control processes. Build a test plan: internal vulnerability scans, segmentation validation using tools like hping3 or nc to ensure denied flows are blocked, and a recorded test showing that an internal asset is unreachable from the public VLAN except on approved ports. Retain configuration snapshots, firewall rulesets, change request tickets, and test results for auditors. For contractors, tie this evidence to the FAR 52.204-21 compliance artifacts and CMMC Level 1 practice mapping.
Risks of not implementing segmentation and best practices
Without segmentation a single compromised public server can be a pivot point into an internal network, leading to data exfiltration, lateral movement, ransomware, or exposure of Controlled Unclassified Information (CUI) — outcomes that can lead to contract termination, breach notifications, and financial/legal penalties. Best practices: enforce least privilege, separate management-plane access (use management VLAN and jump hosts), use defense-in-depth (firewall + ACLs + WAF + host hardening), rotate credentials and keys, apply automated configuration backups, and include segmentation checks in regular change-control and incident response processes.
In summary, meeting FAR 52.204-21 and CMMC 2.0 Level 1 SC.L1-B.1.XI for public systems is achievable for small businesses by following a structured process: inventory public assets, design a clear VLAN/subnet topology, implement switch and firewall rules that default-deny inter-VLAN traffic, enable monitoring and logging, and collect configuration and test evidence. With these actionable steps, a small organization can reduce attack surface, show demonstrable controls to auditors, and better protect contract-related information.
