PCI-DSS: Your CDE may be getting bigger

In December, the PCI Security Standards Council released guidance around scoping and network segmentation for card data environment (CDE) assets. In their own words:

“Many organizations struggle to understand where PCI DSS controls are required and which systems need to be protected. This document provides guidance to help organizations identify the systems that, at a minimum, need to be included in scope for PCI DSS. Additionally, the document provides guidance on how segmentation can be used to help reduce the number of systems that require PCI DSS controls.”

The guidance goes on to visualise a scoping process, considering each category of system in turn:

I believe it’s worth highlighting the ‘broadness’ of the “Connected to OR Security Impacting Systems”. These are cases where the:
  • System component is on a different network (or subnet or VLAN), but can connect to or access the CDE (e.g., via internal network connectivity).
  • System component can connect to or access the CDE via another system—for example, via connection to a jump server that provides access to the CDE).
  • System component can impact configuration or security of the CDE, or how CHD/SAD is handled— for example, a web redirection server or name resolution server.
  • System component provides security services to the CDE—for example, network traffic filtering, patch distribution, or authentication management.
  • System component supports PCI DSS requirements, such as time servers and audit log storage servers.
  • System component provides segmentation of the CDE from out-of-scope systems and networks—for example, firewalls configured to block traffic from untrusted networks.

The guidance states that these systems: 
  • Are in scope for PCI DSS. Even where a connection is limited to specific ports or services on specific systems, those systems are included in scope to verify that the applicable security controls are in place.
  • Must be evaluated against all PCI DSS requirements to determine the applicability of each requirement.
  • Must not provide an access path between CDE systems and out- of-scope systems.

In my experience many organisations’ employ jump-posts or bastions heavily in order to facilitate access to their CDE, with assets on one side being clearly in-scope and assets on the other being strictly out of scope. With this intermediary many organisations then avoid the need for dedicated CDE workstations. If we work to the assumption then that this guidance will add to the requirements then this will represent a fundamental shift (albeit for the better) in improving the overall the security posture of many organisations. It will also require many organisation to seriously reconsider their approach to managing CDE assets.


Popular posts from this blog

Tools & Techniques - Kali Linux of a Raspberry Pi

Splunk Security Cheat Sheet

Developing Leeds Scene