3.13.5 — DMZ for Public Systems

The One-Liner

If your public web server and your CUI database sit on the same network segment, a web application compromise is a CUI breach.

What It Says

Implement subnetworks for publicly accessible system components that are physically or logically separated from internal networks.

What It Actually Means

Any system reachable from the internet must be in a DMZ — a separate network zone between the internet and your internal network. The DMZ is the sacrificial zone: if a public-facing system is compromised, the attacker is trapped in the DMZ and can’t reach CUI systems directly.

What goes in the DMZ:

• Web servers
• Email gateways
• VPN concentrators
• Any system with a public IP

What stays out of the DMZ:

• CUI databases
• File servers
• Internal applications
• Directory services (AD)

The firewall between the DMZ and the internal network should be strict: only the specific ports and protocols needed for the public-facing service to function. No “allow all” rules between DMZ and internal.

If you don’t have any public-facing systems (everything is cloud-hosted by a CSP), document that in your SSP. This requirement may be simpler than you think.

---

Pass or Fail

Your assessor needs a “yes” to every row:

#	Question	What “yes” looks like
1	Are publicly accessible system components identified?	List of all internet-facing systems
2	Are public-facing components in subnetworks separated from internal networks?	DMZ exists with firewall between it and internal CUI network
3	Is the separation physical or logical?	Network diagram shows DMZ zone with distinct subnet and firewall rules

---

What to Have Ready on Assessment Day

Documents they’ll review: System and communications protection policy; system security plan; network diagrams; system design documentation; system configuration settings showing DMZ configuration; firewall rules between DMZ and internal

People they’ll talk to: System or network administrators; personnel with information security responsibilities

Live demos they’ll ask for: Mechanisms implementing DMZ separation; firewall rules between DMZ and internal networks

---

The Assessor’s Playbook

These are the actual questions. Have answers ready.

• “Do you have any publicly accessible systems? Where do they sit?”
• “Show me your DMZ on the network diagram.”
• “What firewall rules exist between the DMZ and internal network?”
• “Can a system in the DMZ directly access your CUI database?”
• “What happens if a public-facing system is compromised — can the attacker reach CUI?”

Real-World Example

A contractor hosts a public website and an email gateway. Both sit in a DMZ subnet behind the external firewall but in front of the internal firewall. The internal firewall allows only: SMTP (port 25) from the email gateway to the internal mail server, and HTTPS (port 443) from the web server to an internal API — no other traffic. The CUI file share and AD server are on the internal network with no DMZ exposure. The assessor reviews the firewall rules and confirms: no direct path from DMZ to CUI systems except the two documented, controlled flows.

---

Where Companies Trip Up

No DMZ. Public-facing systems on the same network as CUI. Classic architecture failure.

DMZ rules too permissive. DMZ firewall allows ‘any’ traffic to the internal network. Restrict to specific ports and IPs.

Direct database access from DMZ. Web server in DMZ connects directly to a SQL database containing CUI on the internal network. Use an application tier in between.

Cloud but no documentation. All public services are cloud-hosted but you haven’t documented that the requirement is satisfied by the CSP’s architecture.

---

How to Talk About This

To a CEO or Board

Our public-facing systems are isolated in a DMZ, completely separated from our CUI networks. A web server compromise can’t reach CUI.

To an Engineering Team

DMZ subnet for all internet-facing services. Firewall: DMZ-to-internal rules allow only specific ports/protocols to specific hosts. No direct CUI database access from DMZ. Application tier between web and data. Cloud-hosted public services documented in SSP with CSP architecture reference.

---

Connected Requirements

Requirement	Why it matters here
3.13.1 — Guard the Boundaries	DMZ is an internal boundary that must be monitored
3.13.6 — Deny Everything by Default	DMZ-to-internal firewall rules must be default-deny
3.1.22 — Keep CUI Off Public Systems	Public systems in the DMZ must never contain CUI

---

Implementation

🔒

Step-by-step guides for Microsoft 365, AWS, Azure, and GCP are available to Ancitus clients.

Start a conversation →

---

CMMC Practice ID: SC.L2-3.13.5 | SPRS Weight: 5 points | POA&M Eligible: No