Blog

Preventing Scope Creep in PCI Compliance

QSAs have to validate the scope of a PCI assessment. It is one of the biggest areas of contention, but limiting scope is of paramount importance in reducing the complexity of an assessment. One of the ways in which QSA's are encouraged to validate scope is to have the client run a Cardholder Data (CHD) discovery tool over the entire environment (not just the expected Cardholder Data Environment (CDE)). This helps a QSA discover any unexpected Cardholder Data (CHD) and either bring those people, processes, and tools into the scope or get them excluded and their access to Cardholder Data (CHD) removed.

We were told in the PCI Qualified Security Assessor (QSA) class that clients often overlook is the requirement for redaction of any inadvertent Cardholder Data (CHD).For instance, customers may send mail saying, “please bill my CC” or ask a provider's helpdesk for assistance when having trouble accessing a database (full of CHD). These kinds of inquiries can bring mail servers, mail recipients, or helpdesk staff into the scope of a PCI assessment and make things more complicated than they need to be. PCI 3.1 added SMS devices explicitly to the possibilities for unauthorized collection and storage of Cardholder Data (CHD). Sections 3.1.b and 4.1.a of the PCI DSS standard are highlighted as being very easy to overlook when determining scope--with “for all locations of CHD” being the operative phrase.

If the recipient of an "unexpected" set of Cardholder Data (CHD) actually acts on the request or data by charging an amount to the card given, he or she has created a de facto process which is not documented, monitored, under change control, or auditable in any of the other ways that PCI compliance requires. Plus, that Cardholder Data (CHD) in an e-mail or SMS is unlikely ever to be masked or deleted, further expanding the possibilities of compromise in a breach.

A simple test is to send yourself two emails—one from outside your perimeter and another from within it, containing a dummy card number (with and without an expiration date)—and watch how each one is processed. Best practice has a tool that blocks the offending mail at the mail gateway and sends a warning back to the sender that they are being inappropriate. It then sends another notification to the intended recipient saying that inadmissible content was blocked in an email from the named sender. That way either side can initiate remedial actions.

Another frequent area of surprise in assessments is the discovery of spreadsheets or other unstructured data files, full of unredacted or unmasked Cardholder Data (CHD). Therefore, a pre-assessment test that can assist with ensuring that your scope isn't creeping outwards is to run a Cardholder Data (CHD) discovery tool. Some tools, while having impressively long lists of pre-programmed file extensions to include in their search for Cardholder Data (CHD), still manage to miss some obvious ones such as .csv, .iso, .tar, .rar, .zip, .7z, any flat file types such as databases, and all the variants of .doc and .xls. We strongly advise looking at the pre-programmed list and adding in any file types commonly found in your organization. Unfortunately, these tests generate lots of false positives, so you should allow enough time to research them all and ensure that there are no real positive results. The QSA is likely to request the results of that test to satisfy requirement 4.1.a in the Report on Compliance.

Related Articles By Topic

PCI DSS

Contact Us
Chat with our team about your PCI DSS compliance program.
Schedule a call
Contact Us