I am currently working on a new implementer’s course for the Payment Card Industry Data Security Standard (PCI DSS) and am looking at examples of segregating the Cardholder Data Environment (CDE) from the corporate network. This should hope to reduce the scope of applying the PCI DSS.
The PCI Security Standards Council (PCI SSC) states that “Adequate network segmentation, which isolates systems that store, process, or transmit cardholder data from those that do not, may reduce the scope of the cardholder data environment”. Segmentation is not mandatory, but does offer many organisations a means of simplifying compliance with the PCI DSS.
However, the standard does say;
- If there is a system on a network that does not store, process, or transmit card data, but that system is able to reach machines that do store, process, or transmit cardholder data, then the system is in scope.
- If the server is unable to see or connect such that no user on the system could traverse to any systems that store, process, or transmit card data, then the system is out of scope.
This leads to a question; what is in scope and what is out of scope? This question should concern a corporate network where domain controllers and time servers supply services to all corporate devices, including those within the CDE scope.
As requirement 10.4 states that all critical system clocks and times should be synchronised, I will look at the use of time servers as an example.
We could implement this by putting a time server within the CDE that receives the MSF signal from the Anthorn radio station, run by the National Physics Lab in the UK. However, other critical systems in an organisation should also be synchronised. A time server can be placed in the untrusted corporate network outside of the CDE, but will need to provide services to the CDE whilst maintaining compliance with the PCI DSS. By providing a service to the CDE it should be in scope and part of the CDE.
However, this could send you around in circles! Requirement 1.2 suggests to, “Build a firewall configuration that denies all traffic from “untrusted” networks and hosts, except for protocols necessary for the cardholder data environment”. This allows us to configure the firewall protecting the CDE, allowing services from the time server through to the CDE. Thus the firewall and the traffic itself is suitably protected and filtered so that only the time service from the time server is allowed through.
We also need to meet the intent of the PCI DSS: “No user on the system could traverse to any systems that store, process, or transmit card data”. This means that any server providing a service should be hardened to standards such as those from the following organisations.
- SysAdmin Audit Network Security Network (SANS)
- National Institute of Standards Technology (NIST)
- Center for Internet Security (CIS).
We also have requirements 1.4 which prohibits direct public access and has two sub requirements:
- Implement a Demilitarized Zone (DMZ) to filter and screen all traffic, prohibiting direct routes for inbound and outbound Internet traffic
- Restrict outbound traffic from payment card applications to IP addresses within the DMZ.
Therefore (in our example), if we are using the Network Time Protocol to update time servers, the time server in the CDE cannot directly connect to a public time server. Instead it will have to use an interim time server in the DMZ which then would access a public time server on the Internet.
This demonstrates some of the techniques that can be used in building and designing a secure, segregated network for the PCI DSS.
If you would like to know more information about PCI DSS, then book on to our PCI DSS Foundation Training Course. Taking place in London and Manchester, this course will give you an overview to PCI DSS and provide you with the guidance you need to start your project.
For those more advanced in PCI DSS, a range of reading materials and tools can be found on the IT Governance website.