The payment card industry standard articulates very prescriptively what should be done for all system components that are within the payment card process. An area of usual confusion is the depth of abstraction that should be applied to the “connected system” element of the standard. Specifically, the standard states the following:
The PCI DSS security requirements apply to all system components. In the context of PCI DSS, “system components” are defined as any network component, server, or application that is included in or connected to the cardholder data environment. ―”System components” also include any virtualization components such as virtual machines, virtual switches/routers, virtual appliances, virtual applications/desktops, and hypervisors. The cardholder data environment is comprised of people, processes and technology that store, process or transmit cardholder data or sensitive authentication data. Network components include but are not limited to firewalls, switches, routers, wireless access points, network appliances, and other security appliances. Server types include, but are not limited to the following: web, application, database, authentication, mail, proxy, network time protocol (NTP), and domain name server (DNS). Applications include all purchased and custom applications, including internal and external (for example, Internet) applications.
– PCI DSS 2.0 page 10
To simplify – there are the system components that are involved with the payment card process, and then there are the supporting systems (connected systems) that also are in scope of PCI DSS. An example would be the patch server where the in-scope PCI system is receiving patches (but there are dozens).
So a rule of thumb on scope most offered in the industry is:
If you can digitally communicate with the system it is a connected system (this includes UDP, TCP, etc …) it is in scope.
A nice write up by Jeff Lowder referring to specifically the security system components can be found here written in 2010.
A Korzybski abstraction problem:
How many levels of abstraction should one undertake? Meaning – should that same patch server then be examined to see what systems are connecting to it and thus also be included in the ‘connected system’ web?
The answer here is generally no – the abstraction is only one level deep. That doesn’t mean best practice risk and security practices evaporate, so no leaving that server unpatched on the internet or anything.
What Requirements of PCI DSS should be applied to these ‘connected systems’?
The standard makes it clear in the beginning “The PCI DSS security requirements apply to all…” So, every PCI control applies to the connected system under discussion and identified through the abstraction of the services supporting the CHD environment itself. Limitations can be applied to the core system components that make up this “connected system”. Such as in the virtualization space, the hypervisor risks and controls are differentially applied from the entire standard. These exceptions from fully applying the PCI standard directly to the connected system must be limited and done with clear awareness. [Updated: All requirements should be considered … each QSA is different but addressing the risk with an eye towards compliance is the best and safest bet. Shopping for someone to accept a state of controls is a painful road]
An “Open PCI DSS Scoping Toolkit“(pdf) published on August 24, 2012 is available that provides an excellent structure in methodically determining scope and the controls that would be applicable. While not a product of the PCI SSC or a technical group – there is good content here that should be carefully considered as part of every security and compliance strategy. Thanks to Eric Brothers for the note! [Updated 12/5/2012]
Another good write up is offered here where a good articulation on the two factor authentication exception; file integrity monitoring exception, and a few other practices are nicely elaborated by Andrew Plato (Plus check out the comment threads.. very informative though proceed with caution as this is one QSA interpretation). Definitely worth a review, though sadly after a review there appears no other elaborations within the PCI SSC on this topic.
This write-up is an exploratory effort to seek clarity by consolidating thoughts of leading individuals in the payment card space and client environment realities. Any additional insights or perspectives you have are welcomed and requested in the comments below! I’ll update as anything is shared.