What are my requirements? And how does it help?
PCI DSS is a challenge for many organisations, but it becomes an even greater challenge if you’re storing cardholder data.
Storing cardholder data not only creates a greater risk, but it also creates a much larger PCI compliance overhead, adding a minimum of 16 additional requirements in v3.2.1 and 18 additional requirements in the recently released v4.0. It’s important to note these are just the requirements that relate to how you store your data, and how you manage your keys. If you thought you could use Self-Assessment Questionnaire A with only a small number of controls, but you’re actually storing cardholder data, the number of increased controls would be exponential resulting in a significant increase to not only the time you have to devote to PCI compliance, but also the cost of maintaining compliance on an ongoing basis.
Is Cardholder Data Scanning Required by PCI?
The simple answer is no, cardholder data scanning isn’t mandatory under PCI DSS in any of the versions. But that’s not to say that it can’t help you significantly with meeting certain PCI requirements. In this post, we will cover off some of the areas where cardholder data scanning can help with compliance requirements, including:
- Proving you aren’t storing cards
- Prove you aren’t storing unprotected cardholder data
- Reduce risk of expanding your scope
- Helping you document and define your PCI compliance scope
- Have a process to respond to finding cardholder data
Prove You Aren’t Storing Cards
PCI Requirements
- Show you can use a self-assessment questionnaire (SAQ) with a reduced set of controls OR
- Show you can use a reduced set of controls on your report on compliance (RoC)
One of the things that you have to do when you’re using an Self-Assessment Questionnaire (SAQ) with a reduced set of controls is to attest to the fact that you are not storing any cardholder data on your systems. But how can you possibly do that if you haven’t looked?
We know from our experience that quite often cardholder data turns up where people least expect it. Unfortunately, if there’s a breach, this is the low hanging fruit that attackers will target. Even if you don’t think you store cardholder data, it’s possible to be the common point of compromise if someone is able to take card numbers that have been used on your system and later use them fraudulently.
So then how do you actually show that you’ve done your due diligence before you attest the fact that you’re not storing cardholder data and the risk of an “account data compromise” is minimized? You could spend days manually going through files, folders, databases, emails, and hoping to spot whether or not there’s card data, but the odds of finding all of it are extremely low. An alternative is to use cardholder data scanning tools, such as Quasar Scan to generate tangible evidence that you aren’t storing cards. Using automated tools to scan the whole of the environment gives you good assurance that you can take to the person signing that attestation of compliance (AoC) and prove that you’re not storing cards and they are putting their name to an accurate statement of fact.
Show You are Not Storing Unprotected Cardholder Data
PCI Requirements:
- PCI v4.0 – 3.5.1
- PCI v3.2.1 – 3.4
Following closely on from the above, if you do have to store cardholder data it has to be protected. This means you need to show evidence that you are not storing any cardholder data that is not protected. By scanning for cardholder data ahead of your PCI assessment, you can make sure that there are no locations where you are storing unprotected cardholder data, meaning no surprises and costly last minute remediation during the PCI assessment if your QSA finds clear-text PAN. While your QSA will still have to review your environment, you can be confident that if you’ve already found and remediated the data, there will be nothing left for your QSA to find.
In addition, you can show your QSA evidence that there are no databases, logs, or backups that contain unprotected cardholder data.
Reduce Risk of Expanding Scope
PCI Requirements:
- PCI v4.0 – 4.2.1
- PCI v3.2.1 – N/A
An applicability note in PCI DSS v4.0 specifically identified a risk area if you receive unsolicited PAN via an insecure communication channel. If this happens, “the entity can choose to either include the channel in the scope of their CDE and secure it according to PCI DSS or implement measures to prevent the channel from being used for cardholder data.”
The most common channels that we see unsolicited cardholder data come into the environment is via emails or support requests. But there can also be “shadow payment channels” which regularly get used for payments but bypass the regular controls put in place to make sure that these channels are part of the PCI DSS scope.
The easiest way to identify if there’s any risk to these channels is to use a data discovery tool like Quasar Scan. Then if you identify cards that’s an opportunity to put measures in place to prevent the channel from being used for cards going forwards, and an opportunity to reduce the risk by identifying and removing cardholder data that may have been unintentionally stored over a long period of time.
Document and Define Your PCI Scope
PCI Requirements:
- PCI v4.0 – 12.5.2
- PCI v3.2.1 – Support introductory section 3.1 by showing you have confirmed the accuracy of your scope.
One of the new requirements in PCI DSS v4.0 (Requirement 12.5.2) is to have a clearly documented PCI DSS scope which includes “identifying all locations where account data is stored, processed, and transmitted, including but not limited to: 1) any locations outside the currently defined CDE, 2) applications that process CHD, 3) transmissions between systems and networks, and 4) file backups”.
One of the really important things to notice in that list of things that you need to include in your scope is that you need to be able to identify any locations that are outside of your currently defined CDE where cardholder data is being stored. And this means that if you’re not checking these areas, you’re not going to be able to show that you’ve met the requirement for documenting your scope.
As part of the “Good Practice” noted in the PCI Standard for the scoping requirement:
A data discovery tool or methodology can be used to facilitate identifying all sources and locations of PAN, and to look for PAN that resides on systems and networks outside of the currently defined CDE or in unexpected places within the defined CDE – for example, in an error log or memory dump file. This approach can help ensure that previously unknown locations of PAN are detected and that the PAN is either eliminated or properly secured.
So this means that you need to make sure that you’re not just scanning where you think (or know) there are cards, but also where there might not be cards. It’s not just about showing that you know what you already know. It’s about finding those areas that you may not expect, so that you can accurately understand your scope, then find ways to reduce the risk and potentially even decrease your scope if you can make sure that only the smallest number of possible systems store, process, or transmit cardholder data.
Respond to Cardholder Data Being Found
PCI Requirements:
- PCI v4.0 – 12.10.7
- PCI v3.2.1 – N/A
It’s a rare situation where there’s not some accidental storage of cardholder data. Whether someone types their card number in the name field, adds it to an email support message for a refund, or they send it through a support request, it adds to the risk in your environment. PCI DSS v4.0 is adding some new controls around how you should be responding to those cardholder data incidents. One of the steps that you need to follow if you find cardholder data is to determine if there were any data leaks or process gaps that resulted in the storage of the account data where it was not expected.
Often the easiest way to find out what actually led to the cardholder data being stored is to understand if there are other instances of it which will help you identify the root cause. However, if the cause of the problem is intermittent, there’s a risk that it will be hard to find any similar data manually, which will make it that much harder to identify what the data leak or process gap was if you don’t have a data discovery tool.
And if you want to be able to show that you fixed the data leak or process gap where you found the cards in the first place, the easiest way to do that is to rerun the data discovery process and show that the cards you originally found have been cleaned up.
PCI has a strong focus on scan-fix-rescan for vulnerability scans, but you can perform a similar process with cardholder data scanning showing that when you find cardholder data, you act on it, remove it or protect it, and when the system is re-scanned showing that the data is no longer there. The result is tangible evidence that you can show your stakeholders or your QSA that you’ve fixed the issue.
How Often Should You Scan?
PCI uses a number of standard timeframes that regularly scheduled tasks are carried out. We’ve already established that there’s no specific PCI requirement that requires you to use cardholder data scanning, but there are a number of benefits to it.
Generally, it makes sense to scan your environment on a quarterly basis. This could be a quarterly scan of your entire environment or if you have a large environment, breaking the scan up over quarters to get through the whole of your environment. You can also match this up with when you would normally delete cardholder data that is no longer needed (PCI v4.0 – Req. 3.2.1 / PCI DSS v3.2.1 – Req. 3.1).
Treat your card-scanning timing like you do your penetration testing and plan to complete it far enough ahead of your PCI assessment that you have time to fix any underlying risks that were identified.
