Implement subnetworks for publicly accessible system components
📖 What This Means
This control requires separating publicly accessible systems (like websites or email servers) from your internal network by placing them in their own dedicated subnetworks (subnets). Think of it like putting your front porch in a separate area from your living room—visitors can access the porch but not the rest of your house. This limits the damage if a public-facing system is compromised. For example, a small defense contractor might place their customer portal in a separate subnet from their internal file servers. Another example: a public-facing web server handling contract bids should be isolated from the subnet containing employee workstations.
🎯 Why It Matters
Publicly accessible systems are high-risk targets for attacks. If compromised, attackers can use them as a foothold to move laterally into internal networks. Without subnet isolation, a breach in a web server could lead to theft of sensitive contract data or intellectual property. A 2023 Verizon report found that 80% of breaches involving web applications could have been mitigated with proper network segmentation. The DoD requires this control because defense contractors often host public-facing systems (e.g., bid portals, supplier interfaces) that handle sensitive data. A single breach could cost $4M+ in remediation and lost contracts.
✅ How to Implement
- 1. In AWS/Azure/GCP, create a new VPC or dedicated subnet for public systems.
- 2. Configure Network ACLs/Security Groups to allow only necessary ports (e.g., 80/443 for web traffic).
- 3. Place public-facing resources (e.g., EC2 instances, Load Balancers) in the new subnet.
- 4. Set up a bastion host or VPN for administrative access (never expose RDP/SSH directly).
- 5. Enable VPC Flow Logs to monitor traffic between subnets.
- 6. Use AWS WAF/Azure Firewall to add application-layer protection.
- 7. Document the architecture in a network diagram.
📋 Evidence Examples
Network Diagram
Firewall Rules
Penetration Test Report
VPC Flow Logs (Cloud)
Subnet Configuration
📝 SSP Guidance
Use this guidance when writing the System Security Plan (SSP) narrative for this control.
How to Write the SSP Narrative
For SC.L1-3.13.2 ("Implement subnetworks for publicly accessible system components"), your SSP narrative should specifically describe: (1) the tools and technologies you use to implement this control, (2) the configuration or process that enforces it, (3) who is responsible for maintaining it, and (4) what evidence proves it's working. Describe your network security architecture, including segmentation, encryption standards, VPN configuration, session management, key management, and monitoring capabilities. Be specific -- name your actual products, settings, and responsible personnel.
Example SSP Narratives
"SC.L1-3.13.2 is implemented using cloud-native controls. [Organization] uses [specific cloud service/feature] to implement subnetworks for publicly accessible system components. The configuration is managed through [Azure Policy/AWS Config/Terraform] and monitored via [SIEM tool]. Responsible party: [IT Security Manager]. Evidence: [specific artifact, e.g., 'Azure AD Conditional Access policy screenshot, CloudTrail logs']."
"SC.L1-3.13.2 is implemented through on-premise infrastructure controls. [Organization] uses [Active Directory/Group Policy/specific tool] to implement subnetworks for publicly accessible system components. Configuration is documented in [location] and audited [frequency]. Responsible party: [System Administrator]. Evidence: [specific artifact, e.g., 'Group Policy export, Windows Event logs']."
"SC.L1-3.13.2 is implemented across both cloud and on-premise environments. [Organization] uses [Azure AD Connect/hybrid tool] to ensure consistent enforcement. Cloud resources are managed via [cloud tool] and on-premise systems via [on-prem tool]. Both environments report to [centralized SIEM]. Responsible party: [IT Director]. Evidence: [artifacts from both environments]."
System Boundary Considerations
- • Document network architecture with CUI boundary clearly marked
- • Identify all encryption mechanisms (at rest and in transit)
- • Specify network monitoring and IDS/IPS deployment
- • Ensure this control covers all systems within your defined CUI boundary where implement subnetworks for publicly accessible system components applies
- • Document any systems where this control is not applicable and explain why
Key Documentation to Reference in SSP
- 📄 System and Communications Protection Policy
- 📄 Network architecture diagram
- 📄 Firewall rule documentation
- 📄 Encryption configuration documentation
- 📄 Evidence artifacts specific to SC.L1-3.13.2
- 📄 POA&M entry if control is not fully implemented
What the Assessor Looks For
The assessor will review network diagrams for proper segmentation, test encryption settings, verify VPN split tunneling is disabled, and check FIPS 140-2 validation of cryptographic modules.
💬 Self-Assessment Questions
Use these questions to assess your compliance. Each "NO" answer provides specific remediation guidance.
Question 1: Do you have a dedicated subnet/VLAN for all public-facing systems?
Question 2: Are firewall rules blocking all unnecessary traffic between public and internal subnets?
Question 3: Can you demonstrate (via logs/tests) that internal systems can't be accessed from the public subnet?
Question 4: Is administrative access to public systems restricted (e.g., via jump server/VPN)?
Question 5: Is the subnet architecture documented in a network diagram?
⚠️ Common Mistakes (What Auditors Flag)
1. Using default 'allow any' firewall rules between subnets.
2. Placing internal databases in the same subnet as public web servers.
3. No logging/monitoring of cross-subnet traffic.
4. Missing documentation (no network diagrams).
5. Allowing direct RDP/SSH to public systems from the internet.
📚 Parent Policy
This practice is governed by the System and Communications Protection Policy