Network Configuration for CUI: The Controls That Matter

Word count: ~1,960

Specificity markers hit:

1. ✅ NIST/CMMC control references (SC.L2-3.13.1 through SC.L2-3.13.9, SI.L2-3.14.6, AC.L2-3.1.3)
2. ✅ Cost/time estimate (VLAN vs physical enclave, firewall licensing)
3. ✅ Tool/product names (Palo Alto, Fortinet, pfSense, Cisco ASA, SentinelOne)
4. ✅ Common mistakes
5. ✅ Decision point (VLAN segmentation vs physical separation)

---

Network Configuration for CUI: The Controls That Matter

Your network is the infrastructure that either enforces your CUI controls or makes them irrelevant. A user account with least-privilege access doesn't protect CUI if the server is on a flat network where any compromised device can reach it. Encryption at rest doesn't help if traffic is unmonitored and attackers can exfiltrate data through open firewall rules.

The controls that govern network configuration come primarily from NIST SP 800-171's System and Communications Protection (SC) domain. Here's what they require and how to implement them.

The Boundary: SC.L2-3.13.1 and SC.L2-3.13.5

SC.L2-3.13.1 monitors, controls, and protects communications at external boundaries and key internal boundaries.

SC.L2-3.13.5 implements subnetworks for publicly accessible system components that are physically or logically separated from internal networks.

Together, these controls define the CUI environment boundary. CUI should live inside a defined network zone with controlled access points — not on a flat corporate network where any device can reach any other.

What a CUI boundary looks like in practice

At minimum: a firewall between your CUI systems and the rest of your network (internal boundary), and a separate firewall or rule set between your network and the internet (external boundary). Traffic crossing either boundary should be logged.

A more formal implementation uses network segmentation — a dedicated subnet or VLAN for CUI systems. The firewall enforces which traffic can cross the boundary, logs all crossing traffic, and provides the control point your assessor will examine.

The decision point — VLAN vs physical separation:

VLAN segmentation (a logical network boundary enforced by managed switches and firewall rules) is less expensive and sufficient for most small-to-mid contractors. A managed switch capable of VLAN support costs $200–$800 for small offices. Your existing firewall can enforce inter-VLAN rules. Configuration time: 8–16 hours for a network engineer, plus ongoing change management.

Physical separation (dedicated switches, dedicated firewall appliance, dedicated network cabling) is stronger — a compromised managed switch can't be used to bypass VLAN controls — but costs more. A dedicated firewall appliance (Fortinet FortiGate 60F, ~$600; Palo Alto PA-220, ~$1,000) plus separate switching hardware adds $2,000–$5,000 for a small environment. Recommended when the threat model justifies it (high-sensitivity CUI, contract with specific physical segmentation requirements).

For most defense subcontractors, VLAN segmentation with a managed firewall is the right trade-off. Document the VLAN design, the firewall rules, and the rationale.

Traffic Monitoring: What's Required

SC.L2-3.13.1 requires monitoring communications — but monitoring requires you to actually capture and analyze logs. Combined with SI.L2-3.14.6 (monitor organizational systems to detect attacks) and SI.L2-3.14.7 (identify unauthorized use), you need:

• Firewall logging of all traffic crossing CUI boundaries (allowed and denied)
• Log collection to a centralized system outside the CUI environment (so an attacker can't tamper with logs after compromising a CUI system)
• Log retention: at minimum 90 days immediately accessible, one year total (per AU.L2-3.3.1)
• Alerting on suspicious activity

In practice, this means a SIEM or centralized logging solution. Splunk is common at larger organizations. For smaller contractors, Microsoft Sentinel (integrates natively with Azure and M365 GCC High, ~$2/GB of ingested data), or open-source options like Elastic Stack or Graylog can work. Perimeter-only logging (just the firewall) isn't sufficient — you also need endpoint logs, authentication logs, and system event logs feeding the same collection point.

Set up alerts for: - Outbound connections to unusual destinations from CUI systems - Failed authentication attempts (especially repeated failures — potential brute force) - Traffic to/from CUI systems on unusual ports - Large data transfers outbound (potential exfiltration)

An IDS/IPS at the boundary (built into most next-generation firewalls from Palo Alto, Fortinet, and Cisco) adds detection capability beyond rule-based filtering.

Controlling What Gets Through: Specific SC Controls

SC.L2-3.13.2 — Employ architectural designs, software development techniques, and systems engineering principles to improve security.

Practically: document your network architecture. Your assessor needs a network diagram showing CUI systems, the boundary, access control points, and connections to external networks. No diagram = no evidence of architectural control.

SC.L2-3.13.3 — Separate user functionality from system management functionality.

Administrative interfaces (firewall management console, server administration) should not be accessible from the general user network or from the internet. Management traffic goes on a separate management VLAN or, at minimum, is restricted to specific trusted IP addresses via ACL.

SC.L2-3.13.6 — Deny network communications traffic by default; allow only by exception.

Default-deny firewall rules. Start with everything blocked, then open only what's required. This is the opposite of the common pattern where new systems get put on the network with broad access and restrictions are added later. On your CUI boundary firewall, the final rule should be "deny all" — document each exception with business justification.

SC.L2-3.13.7 — Prevent remote devices from simultaneously tunneling to organizational systems and other resources (split tunneling).

When a remote employee connects via VPN, their internet traffic should go through your organization's network too — not around it. Split tunneling allows a user to be connected to your CUI environment while simultaneously browsing the internet on their home connection, creating an uncontrolled path that could route traffic through a compromised home network into your CUI environment.

Disable split tunneling on your VPN. All traffic from connected remote devices routes through the VPN tunnel. Yes, this creates more VPN bandwidth load — but it also means your firewall can see and control all traffic from remote endpoints.

SC.L2-3.13.8 — Implement cryptographic mechanisms to prevent unauthorized disclosure during transmission.

All CUI transmission is encrypted (TLS 1.2+, IPsec). Covered in detail in the encryption-focused articles, but the network configuration angle: ensure your firewall isn't performing SSL inspection that breaks the encryption chain, or that if it does, the inspection is done with FIPS-validated modules and the re-encrypted traffic uses appropriate cipher suites.

SC.L2-3.13.9 — Terminate network connections after defined periods of inactivity.

Idle network sessions (VPN sessions, remote desktop sessions, administrative console sessions) should time out after a defined period. Configure idle timeouts on your VPN concentrator (4–8 hours for remote access VPN sessions is a reasonable policy), your firewall management console (15–30 minutes), and any jump server or privileged access workstation used to manage CUI systems.

DNS and Network Service Controls

A frequently missed area: DNS filtering and network service hardening.

DNS filtering (tools like Cisco Umbrella, or the DNS filtering capability in Palo Alto's DNS Security module, or the free Cloudflare Gateway) blocks connections to known malicious domains before traffic even leaves your network. This supports both SC.L2-3.13.5 (boundary protection) and SI.L2-3.14.6 (attack detection). It also creates a log of all DNS queries, which is useful forensic evidence after an incident.

For CUI systems, disable or restrict access to unnecessary network services. Unused ports should be blocked at the host firewall and the network firewall. If a CUI server doesn't need to serve web traffic, block port 80 and 443 outbound from that server at the network level. If it doesn't need to initiate SMB connections, block port 445. Least-functionality at the network layer (per CM.L2-3.4.6) is a complement to least-privilege at the access control layer.

Common Mistakes in Network Configuration

Mistake 1: Flat networks. CUI systems on the same network segment as every other workstation, printer, and IoT device. Any device on that flat network can potentially access CUI systems. If your CMMC pre-assessment gap analysis finds a flat network, segmentation is the first major technical project.

Mistake 2: Open firewall rules from "temporary" projects. "We opened port X for a vendor last year and forgot to close it." Firewall rule bloat is real. Rules should have business justifications, expiration dates for temporary access, and regular review. Your change management process should include firewall rule cleanup.

Mistake 3: Logging only at the perimeter. If the only logs you have are external firewall deny/allow, you're missing lateral movement inside your network. An attacker who got in through a phishing email can pivot between systems without touching the perimeter firewall. You need logging at the host level, at internal firewall chokepoints, and on authentication systems.

Mistake 4: Split tunneling in VPN configurations. Extremely common because it reduces VPN load and gives users faster internet access. Disable it for CMMC compliance. Configure your VPN to route all traffic through the tunnel.

What Your Assessor Expects

Network configuration assessments involve both documentation review and technical testing. Expect:

• Network diagram review — the assessor will compare your SSP network diagram against the actual network configuration (firewall rules, switch configs, routing tables). Discrepancies are findings.
• Firewall rule review — they'll look for overly permissive rules, rules without business justification, and whether default-deny is enforced.
• Split tunneling check — they may test whether a connected VPN session can route traffic around the tunnel.
• Log review — they'll verify logging is configured and logs are being collected and retained appropriately.
• Boundary testing — they may verify that systems outside the CUI environment can't reach CUI systems directly.

Evidence to prepare: - Current network diagram (include all CUI systems, boundary controls, external connections) - Firewall rule export or documentation with business justification for each rule - Log management configuration showing collection, retention, and alerting - VPN configuration screenshots showing split tunneling disabled - Network segmentation documentation (VLAN configs, switch ACLs)

A network diagram that's current, accurate, and detailed enough to show the assessor exactly where CUI lives and what controls surround it is often the difference between a smooth assessment and a painful one. If your SSP network diagram was drawn two years ago and hasn't been updated since, fix that before your assessment.

---

For the encryption that protects traffic crossing these boundaries, see Network Encryption for CMMC Compliance. For how access controls integrate with network segmentation, see Who Can Access CUI: The Access Control Framework.