Anybody who has spent more than a few nanoseconds working on PCI compliance invariably has been confronted with the mystical challenges of scope. What is considered in-scope for PCI compliance? How do you limit scope? And what constitutes the Cardholder Data Environment, or CDE?

These can be tough questions to answer. First, we need to start with some important distinctions.

Many people conflate the CDE with the PCI Scope.  In fact, the CDE and what is in-scope for compliance are not, necessarily, the same.

The CDE is where actual cardholder data is present. This could be a server that processes transactions, switches where CDE traffic is sent, and any other systems that is directly associated to the storage, transmission or processing of payment card data.  The CDE needs to be isolated and segmented from the rest of your network.  This is typically accomplished through ACLs on VLANs or, preferably, a firewall.  Isolation of the CDE is a PCI requirement.

However, the scope of a PCI assessment, often extends beyond the CDE.  Any system that is “connected to the CDE” is also in scope for compliance. This statement, taken directly from the PCI Standard, is very important.

The operative words here are “connected to.”  Any system that connects into the CDE is in scope for compliance, and therefore must meet the relevant PCI requirements.  That means servers that provide important management, administrative or monitoring functions are in-scope as well, even though they may reside outside the CDE.  For example, if you have a server in the CDE, and it connects to an Active Directory server outside the CDE, that Active Directory server is also in scope for PCI compliance.  It may not be inside the CDE and therefore warrant isolation, but it is still very much in-scope for compliance.

As such, any host that has a connection to the CDE (and your organization controls) is in-scope.

Connections can be anything, updates to a patch server, sending logs to a SIEM, anti-virus updates, management servers for file integrity monitoring.  All of these examples would be in-scope for compliance, even if they were not inside the CDE.

One of the ways we analyze this is to look at the ACLs or firewall rules.  If a device inside the CDE has a connection to a device inside your corporate LAN, then that device in the LAN is in-scope for compliance. It had better have anti-virus, log-management, patching, and all the other required host security controls for PCI.

There is one exception to this scope rule, and that is any access to the CDE which uses two-factor authentication.  If a host connects into the CDE, say for remote administration or to access a terminal server for example, and that access uses two-factor authentication, then the originating host is not in-scope.  This is a very useful and powerful exception.  It also is a very useful way to push hosts out of scope who need to access in-scope systems.  And given how inexpensive two-factor authentication systems are, anybody dealing with PCI should pay close attention to this exception.

One other oddity, the PCI DSS does not require file integrity monitoring on hosts outside the CDE. If your CDE is properly isolated and segmented, then FIM is not necessary on hosts outside the CDE (that are still in-scope).

These nuances of PCI are what make defining the scope of compliance extremely important.  Many companies do not consider these connected devices in-scope. This can result rude awakening when a QSA lists those devices as in-scope for assessment.

This also underscores the need for documenting and diagramming your data flows.  We see a lot of organizations that do not properly diagram how payment card data flows across the network.  The PCI DSS requires organizations to document and diagram all payment card data flows, as well as the CDE and all connected systems.

If you are struggling with PCI scope issues, we suggest the following course of action.

  1. Diagram your data flows in Visio. Be able to explain exactly where payment card data enters your network, where it travels, and where it rests.  You should be able to account for payment card data everywhere within your organization.
  2. Define your CDE. Be able to list the exact systems (that includes network infrastructure equipment) that is directly involved in handling card holder data.
  3. Isolate the CDE with a firewall. All traffic into and out of the CDE should be extremely tightly controlled. You cannot have any discretionary access.  Every rule should be defined down to a specific host or host range and port or port range.  No “any” rules on the CDE firewall.
  4. Inventory every system that has any connection into or out of the CDE. Those devices are in-scope and need to have all the other PCI in-scope requirements met.

After completing these steps, you should have a pretty good idea of what your scope is.  The next step is to start working on implementing the necessary host security controls for in-scope systems.  This includes:

  • Antivirus scanning and logging
  • Log monitoring
  • Host hardening standards and configuration control
  • Vulnerability management
  • Patch management
  • Unique accounts for all users and applications
  • Password complexity and reset policies
  • File integrity monitoring (for hosts in the CDE only)
  • Intrusion detection/prevention
  • Penetration testing

The good news here is that there are a lot of creative ways to limit the scope of your PCI compliance. However, be careful with “quick fix” solutions that promise easy compliance.  Some of these solutions make grandiose claims with dubious results.

Share This
%d bloggers like this: