When you start a PCI DSS compliance project, scoping is what some of us QSAs use to call “requirement zero”. The more complex your processes and systems for storing, transmitting and/or processing cardholder data are, the harder it will be to achieve and maintain compliance. This explains why reducing the PCI DSS scope represents such a crucial objective for any organization: it will indeed eventually result in (even dramatically) lowered total cost of compliance. It is in fact pretty obvious that if you take a system out of scope you can avoid the cost and effort of involving it in PCI DSS-compliance activities, both in terms of recurring tasks (e.g. patching, vulnerability scans, etc.) and annual onsite assessment.
Further advantages are easier maintenance of security controls and reduction of risk due to limiting the attack surface.
Scope reduction is therefore the primary tool you have to limit the size of the compliance effort. Therefore, it is strongly recommended that organizations look to implement a scope-reduction strategy. It should be done right at the start of your compliance project since the scoping exercise defines the perimeter within which all requirements should be in place.
Scope reduction may however involve relevant changes to both network architecture and business processes, so it isn’t always an easy task to accomplish. The challenge is how to do it without affecting service or incurring prohibitive costs.
Important terms
It is very important to keep two key words in mind:
- “out-of-scope”: a system (or system component) is deemed to be out-of-scope only when it is fully isolated from the CDE (Card Data Environment), such that even if that system component is compromised it would not impact the security of the CDE.“
- connected systems”: CDE and all connected systems are considered as being in-scope items. A connected system is any system component that establishes or participates in any communication with any system component in the CDE, regardless of the reason for the connection, of the type of communication protocol used, or of which device actually initiates the communication session. A system component is, on the contrary, considered as a not connected (isolated) item – and thus out of scope – only when it cannot communicate with any component in the CDE, and it has been evaluated to confirm that it is unable to compromise the security of the CDE.
How to verify that a system is out of scope
Verifying what is out of scope entails that organizations have to “Implement a methodology for penetration testing, and perform penetration tests to verify that implemented segmentation methods are operational and effective”. On March 2015 the PCI Council issued a specific technical guidance on how to conduct a penetration test and in that document they explicitly state: “The segmentation check is performed by conducting tests used in the initial stages of a network penetration test (i.e., host discovery, port scanning, etc.). It should verify that all isolated LANs do not have access into the CDE”. At the same time the PCI Council does not give any guidance or specifications to define the approved and recommended scope-reduction methods. Organizations need a guidance document that clarifies the methods for controlling and reducing the scope of compliance. A document to help them recognize how to avoid including components in scope unnecessarily as a result of uncertainty regarding the PCI DSS Standard intent.
In addition to the risk assessment and to the evaluation of all components within the scope, PCI DSS v3.1 also requires verification of excluded system components to confirm that their exclusion from the scope of compliance is valid. Therefore, organizations should perform a risk assessment on connected systems as well as on the excluded system components, in order to determine whether excluded components, if compromised, could impact the security of the CDE. If the answer is “yes”, they must be included in the scope.
Ways to reduce PCI DSS scope
Organizations can limit their PCI DSS scope by reducing the number of places where CHD is at risk. Here are the main ways:
Remove: using a detailed, up-to-date CHD flow diagram, so that organizations can physically and logically consolidate all systems that store, process or transmit CHD and eliminate redundant storage, systems and applications.
Truncate/Mask: when the full PAN is not necessary, using or storing appropriately truncated PAN data reduces the risk of compromise and may, in most cases, remove it from scope.
Hashing: using strong cryptography to replace the PAN with a fixed-length message digest that is computationally infeasible to revert to the PAN. It is recommended that an additional, random input value be added to the cardholder data prior to hashing to reduce the feasibility of an attacker comparing the data against tables of pre-computed hash values.
Several organizations nowadays prefer to combine advanced point-to-point encryption with a hosted tokenization solution, since it offers a flexible and comprehensive way to protect data at every point in the transaction lifecycle while still providing the opportunity for data mining and detailed customer analytics based on tokens.
Tokenization: moving away from encryption is a big benefit, in particular due to the challenges around cryptographic key management and the increased frequency of attacks where memory parsing malware is used to extract keys or sensitive data directly from RAM. There have been significant improvements in tokenization solutions, including solutions from the card brands themselves. Tokenization as a Service (TaaS) is gradually gaining ground. Traditional designs are being replaced with innovations such as vault-less and in-memory tokenization that reduce complexity and provide significant advantages in performance. On April 2015 the PCI Council issued a specific guidance document on tokenization product security.
Point-to-Point Encryption (P2PE): this is a very important and recommended data protection method for any merchant. The number of approved P2PE solutions, in particular those that offer payment terminals that also support EMV, is still very limited – at the moment of writing there are 16 validated Point-to-Point Encryption Solutions listed on the PCI Council web site. The amount of is expected to increase in 2016 and the announced update of the P2PE standards will provide more granular certification solutions aimed in that direction.
