Masking PAN

[jjs]

The section 3.3 provides a recommendation for masking account numbers - display only first 6 and last 4.
Does this type of masking take the application out of PCI scope? In other words, there will be no further need to comply with the PCI DSS requirements due to the application no longer storing, processing or transmitting credit card numbers?

[jbhall56]

You wish. LOL

The answer is obviously no. The application will still be in scope for PCI because it stores PCI data. It will still have to be assessed to ensure that (1) only the masked PAN, cardholder name and expiration date are stored by the application and (2) that the PAN masking is consistently applied by the application.

[AllanPoll]

Hang on, if the system upon which the application is running only ever receives a masked PAN then surely that system is out of scope as it never actually processes, transmits nor stores an actual PAN.

Similar to a system that only ever acts upon a computationally irreversible PAN (ie. one way hashed, sanitised/masked). Fact is it's not card data.

[lyalc]

Lets get some clarification, please.

Does the application store the date masked as 6.4, but accept the full PAN, then mask it, or is the masking done in the application?

Is the 6.4 for display purposes, storage, or both?

Is the application within the scoped cardholder data environment?



Lyal

[cmark]

If the system receives 'truncated' PAN of only first six and last four then it will be out of scope IF:

It is properly segmented from the CHD environment.

We try to differentiate between masking and truncating. Truncation indicates that the data is stored with the middle digits replaced or truncated.

Properly truncated data is not considered CHD under the PCI DSS.

[jbhall56]

Just because an organization says that the data is truncated or masked, does not mean that a QSA will not examine the application.

A QSA is still required to prove that the data is truly truncated/masked before the application is taken out of scope. That will require the QSA to examine the result of queries or perform other examination procedures to prove the data is truncated/masked. If the QSA is able to satisfy themself that the data store is truncated/masked, the the application will then be determined to be out of scope of the PCI assessment.

And just so we're clear, just because the application is out of scope, the server it runs on is not necessarily also out of scope. If the server has other PCI in scope applications running on it or stores PCI data, then the server is still in scope.

[cmark]

The question, as I understood it, was regarding the applicability of the PCI DSS and not the requirements for the QSA. If an organization is not storing, transmitting, or processing CHD then the services of a QSA are not required.

The expectation/hope is that organizations will find ways to minimize their use of CHD and not simply try to build complex security infrastructures.

[jbhall56]

The problem we are running into out in the field is that organizations are ruling applications/servers out of scope for PCI because the PAN is masked and then insisting that QSAs not look at them because they are out of scope. We then have to fight with them over the ability to confirm the facts. The real shame is that these arguments always take more time than it would have to confirm that the PAN is masked.

This problem also occurs with an organization's internal auditors. I can't tell you how many organizations I've worked with where internal audit only looked at systems that had actual data and skipped anything that just passed PCI data through or it was masked because it was out of scope. Some of this is due to internal audit's interpretation and the organization's IT department's interpretation of the PCI DSS.

Your answers need to be VERY clear that when PCI related data is involved, there is still a requirement of the QSA or internal audit to confirm the facts.

[cmark]

Jeff,
My answer was related to applicability of the standard only and not the QSA or internal auditors' role. To expand on your comments, simply because a system has CHD does not put it 'in scope' of validation although it will be required to comply with the standard. With regard to Merchants only those systems involved in authorization and settlement or data stores with more than 500K accounts are in scope of validation. If a merchant has a marketing application that stores CHD it would be out of scope of a QSA's assessment unless it had more than 500K accounts. It would not be a QSA's role to 'confirm the facts' in this instance.

I certainly understand the challenges QSA's are encountering. Many of the challenges would be alleviated with a more comprehensive understanding of the PCI DSS and the card brand's programs. I will be happy to discuss any aspect of the PCI or the various card brands' programs offline if you wish to contact me directly.

Thanks,

[lyalc]

This is the first time I've seen the '500k' number mentioned in context of PCI validation, although I've heard it verbally twice before.

Where does this number come from, where is it referenced and thus how can I quote it reliably?

Is this detail something thats specific to MasterCard, Visa or another Brand. Is it from PCI SSC?
Does it only apply in North America, or globally?

Having just been through re-certification, I've never heard of this 'validation by volume' limitation before.

Thanks
Lyal

[cmark]

It is referenced in the 'scoping' section of the PCI DSS Security Audit procedures...third bullet that starts: "Any data repositories..."

[mdahn]

To find the PCI Security Audit Procedures (SAP) look on the PCI Security Standards Council (SSC) website:
https://pcisecuritystandards.org/

[wconway]

Just to be clear (and at the risk of appearing silly) we are talking about merchant databases containing 500K or more accounts requiring "validation" of compliance. I am assuming such databases must still be PCI "compliant," and we are only discussing QSA validation.