Whether a company is going through PCI certification for the first time, is bringing a new section of the company into PCI, or is simply doing a routine recertification, scope is always an issue. The changes introduced with PCI DSS 3.2 do not make matters any simpler. In previous releases, systems could be considered as ‘supporting’ systems and be allowed to not be evaluated as critically as systems in the CDE. Unfortunately, this allowed multiple breaches to occur as attackers were able to use the weaker controls on the supporting systems as jumping-off points to attack trust channels into the CDE.
An important definition: The PCI DSS 3.2 definition of cardholder data (CHD) is Name, Expiration Date, and/or Service Code, specifically accompanying the PAN (primary account number—e.g. the 16 digit card number). If either of the other three elements are being transmitted without the PAN, it ceases to become CHD and is instead just sensitive information. There are other components to the account data, but those to not apply to this conversation.
The scope of the PCI compliance is specifically based around what devices intentionally or potentially store, process, or transmit CHD. This extends to those devices including network devices, servers, computing devices, and applications that host, connect, protect, manage, or influence the security posture of those previously mentioned devices that actually or potentially interact with the CHD. This includes but is not limited to authentication sources (e.g. Active Directory, LDAP, RSA), hypervisors and related storage, firewalls and switches, DNS and NTP services, system patching and configuration tools (e.g. WSUS, Puppet, Chef, SCOM), and other supporting devices and applications (e.g. Internal portal, proxies).
It is strongly recommended that the in-scope CHD environment (CDE) be segmented from the rest of the network that will be considered out of scope. To quote the DSS, “Without adequate network segmentation, the entire network is in scope of the PCI DSS assessment” and “To be considered out of scope for PCI DSS, a system component must be properly isolated (segmented) from the CDE, such that if the out-of-scope component was compromised it could not impact the security of the CDE.” This segmentation applies at multiple levels. The network must be segmented, any storage for systems or hypervisors must be segmented, even the hypervisors themselves must be segmented. Network switch management must be in-scope. Hypervisors must host either all in-scope systems or all out-of-scope systems. Storage can host both, but the management interface must be in-scope, any in-scope storage must be strictly controlled to be only available to in-scope systems, and all out-of-scope storage must be blocked from being available to in-scope systems.
One of the larger changes to the PCI DSS in the last 2-3 years is that the scoping has become more strictly in/out of scope versus levels or tiers (1,2,3). This applies regardless of where in the network the system device resides. Certain supporting systems are allowed to be outside the CDE but still be in-scope. While not explicitly defined in the DSS, those supporting systems cannot have the ability to initiate modifications to the CDE – all connections must be initiated from within the CDE, those systems cannot have any sensitive data, and those systems will still have to have all of the other security controls applied, such as 2FA, logging, etc.
Many companies who provide security services to PCI customers will employ a connector/collector of log data from the servers that process CHD. Those collectors will be in scope due to the collector receiving raw logs from customer devices and having a significant chance of receiving logs containing CHD. Subsequently, any system or device that connects to, manages, or receives system logs (from the collector system itself, not the “handled” logs) from that collector must be in scope. Then the network that those systems or devices are on also becomes in scope.
Since the collector is gathering logs and the design intent is to specifically filter the PAN data in the received logs, that technically would remove all downstream processors of the application logs from being in scope since the data would no longer be considered CHD. However, the logs would have to be 100% guaranteed to not contain any PAN to be allowed to be excluded from being in scope. Even then different auditors might have different views and still insist on the log collectors from being in scope.