DMZ (Demilitarized Zone)
PCIComplianceHubLast updated
A network segment, often positioned between an organization's internal network and the internet, where public-facing systems are isolated to limit exposure and reduce the potential impact of a security breach.
Applies to. In a PCI DSS network the DMZ is where systems that must accept connections from untrusted networks sit: public web servers, mail relays, the endpoints that take inbound partner connections. 1.4.2 allows inbound traffic from untrusted networks only to system components authorised to provide publicly accessible services, protocols and ports, and 1.4.4 keeps system components that store cardholder data off any direct path from an untrusted network. A DMZ is the usual structure for meeting both: the public-facing tier lives there, and the systems behind it are reached only through it.
Example. An e-commerce merchant hosts its own checkout. The web servers sit in a DMZ subnet that accepts HTTPS from the internet. The database that stores cardholder data sits in an internal subnet that accepts connections only from the web tier. One NSC separates the DMZ from the internet and another separates it from the internal subnet, so the database is never directly reachable from outside, which is the outcome 1.4.4 tests.
Limits. A DMZ is a design pattern, not a requirement. The requirement text of 1.4.2 and 1.4.4 describes the outcome without naming the DMZ, and the guidance to 1.4.1 offers it as one way to build the boundary, so a cloud layout of public and private subnets is acceptable if the traffic rules match. Placing a server in the DMZ does not take it out of scope: a DMZ web server that handles card entry transmits cardholder data and is part of the CDE. And the DMZ is not a substitute for the NSC rules on either side of it; without deny-by-default rules in both directions it is just another subnet.