Editor’s Note: In this post, Steve Levinson outlines sampling strategies for companies establishing their cardholder data discovery processes. This post is the third in a series of four from the “Hitchhiker’s Guide to PCI DSS 2.0 Scoping.” The first post offers a step-by-step methodology, the second post offers a strategy for cardholder data discovery, and the fourth post will provide remediation guidelines for addressing issues with discovered cardholder data.

Retailers with thousands of in scope POS systems have often asked us if they need to perform cardholder data discovery searches on all of their retail devices (POS systems and store servers).  Understandably, it is a daunting task to perform this type of search across so many systems, let alone costs associated with potential licensing costs for discovery tools could become astronomical. Critical Success Factors for Cardholder Data Discovery”

There are many instances where we have worked with retail clients to determine a sampling approach to cardholder data discovery.  For those companies who maintain their retail systems on a consistent basis, it is possible to create a sampling methodology to perform cardholder data discovery. Some critical factors to consider for this approach include the following:

  • It should go without saying that all POS systems should be implemented and maintained in a PCI-compliant manner. Just because a payment application is certified as PA-DSS compliant does not mean that system has been implemented properly.
  • Make sure you understand your payment application. If it was provided by a third party or payment application provider, find out if they have any information about whether the payment application is capable of dumping cardholder data – for example, to a log file. If the application has been developed in-house, work with your payment application developers to understand this. If there is no logical way for a payment application to output cardholder data into a hard drive or a log file, the probability of finding cardholder data there is greatly diminished. If there is a logical way for your payment application to dump cardholder data, then make sure you monitor the process(es) that would cause this event to take place and the destinations where the cardholder data would potentially land.
  • In the event that any cardholder data is discovered, companies should create a remediation strategy that applies to all appropriate POS systems, since it is possible that cardholder data appeared on other systems. This will be covered further in a future post on remediation.
  • In the event that any cardholder data is discovered, companies should perform a root cause analysis to determine how the cardholder data appeared there so that action can be taken to prevent a recurrence.
  • In the event that any cardholder data is discovered, companies should run additional cardholder data discovery scans on a new set of systems to ensure that remediation was effective across the board.
  • Companies should change their sample set for each discovery scan. This will allow for more systems to be scanned over time.
  • While cardholder data discovery tools are not going to find stores of encrypted cardholder data, you should remain vigilant for any unauthorized or undocumented repositories of encrypted cardholder data (even this is easier said than done).

Please keep in mind that different QSAs may interpret this PCI requirement differently.  Companies to be assessed should collaborate with their QSA prior to or early in their PCI assessment to determine that QSA’s interpretation of sampling for cardholder data scans. It will be up to the merchant to be able to demonstrate a sound approach to their QSA regarding sampling of POS systems for cardholder data.

Have you implemented a sampling methodology to perform cardholder data discovery? If so, how are you determining what entities to scan for cardholder data? What additional strategies have you employed in the event of discovery cardholder data in a sampled environment?