An Introduction to Cardholder Data Discovery as Part of a PCI DSS Assessment

The Payment Card Industry Security Standards Council (PCI SSC) requires organisations to determine the scope of their PCI DSS assessment accurately.

Prior to discussing data discovery, it is important to define PCI DSS assessment scoping. The official definition by the PCI SSC for scoping is:

'Process of identifying all system components, people, and processes to be included in a PCI DSS assessment'.

During the initial investigation phase, systems in scope for assessment are categorised with the following profiles:

• Store Cardholder Data
• Process Cardholder Data
• Transmit Cardholder Data
• Are connected to or could impact the security of any of the above systems

I often note when I am onsite, that clients find it a struggle to identify all locations where cardholder data is located. The obvious locations are often identified without any hesitation such as within a database, but this is normally second-hand knowledge that has been provided by the auditees colleagues over a Teams/Email/Skype/WhatsApp throwaway message. The system and network administrators generally have little knowledge of the actual data being stored as their priority is managing system components as opposed to the data therein. This is not a criticism by the way 😃.

In order to properly identify cardholder data a detailed investigation needs to be carried out. The investigation needs to initially involve review of existing network, data flow diagrams and CHD locations, alongside interviews with the stakeholders that are involved with the storage, processing and transmission of cardholder data. Once this process is complete, either the current scope will be identified as accurate or, as more often is the case, the scope defined is often too small. With both system managers and data managers working together progress can be made.

So, at this stage the known locations would have been identified; but how do you get assurance that this is all the cardholder data both within and outside of the environment. What I mean by this is that often data is stored outside of anticipated locations and these locations need to be identified. This is often called data leakage.

As an example, 'One of my clients received chargeback files containing full pan via email, these files were then stored locally on the chargeback administrator’s desktop'. This scenario brought into scope at least two additional locations for CHD storage that were previously not considered to contain cardholder data, the email server and additionally the chargeback administrator’s desktop (email .pst and flat files). This would also expand further as the email server was backed up, therefore bringing the backup system into scope and these backups were forwarded to a disaster recovery location. Aaah!

So, by not accurately scoping an environment, required controls to secure card holder data during storage would be difficult to maintain or not implemented at all. Now this is where card scanning tools can help.

Manual tools exist that can scan for PAN such as ccsrch, Find SSN’s, SENF and CUSpider and these typically work best in simple small environments and operate locally on the device being scanned. These tools also tend to throw up a lot of false positives, work with flat files only and are unable to interrogate databases for PAN’s, however they are a good starting point to scanning for PANs. The results of the scans also need to be reviewed, false positives removed and unapproved data storage remediated; this process can be a task in itself.

Specialised tools exist that are able to scan for PAN in a variety of locations such as:

• Operating System Types

Windows and Mac desktops.

Windows, Linux, Solaris, HP-UX, AIX, EBCDIC servers.

• Target Types

Local storage, free space, shadow volumes and memory.

• File Types

Encoded files, flat files, compressed files, database files, email files, audio files and image files.

Some of the additional features that are often included in these tools are:

• Having a small footprint on the system being scanned.
• Having a central management console.
• Having the ability to search for other types of sensitive data, therefore allowing compliance with standards other that PCI DSS.
• Having the ability to automate the remediation process.

These tools would typically work well in large heterogeneous environments. The tool you could use will depend on the results of the scoping exercise that you have conducted and assessing which specialised tools fit your environment. A non-exhaustive list of tools are Ground Labs Enterprise Recon, Security Metrics PANScan and Controlcase CDD.

Testing tools to find the right fit is always a good idea in my opinion and currently Ground Labs has announced the availability of Enterprise Recon NOW, a free, limited standalone version of its industry-leading data discovery solution, Enterprise Recon at no cost for 90 days.

In our next post in this series I will address strategies and approaches to the use of data discovery tools within an environment.