Today we are going to look at PCI DSS Requirement 3.4 in a little more detail. This requirement, to refresh your memory, states the following:

"Render PAN unreadable anywhere it is stored (including on portable digital media, backup media, and in logs) by using any of the following approach"

  • One-way hashes based on strong cryptography (hash must be of the entire PAN)
  • Truncation (hashing cannot be used to replace the truncated segment of PAN)
  • Index tokens and pads (pads must be securely stored)
  • Strong cryptography with associated key-management processes and procedures

For the matter we'd like to point your attention specifically to testing procedure 3.4.d. Examine a sample of audit logs to confirm that the PAN is sanitised or removed from the logs.


While auditing two different Level 1 Service Providers through a combination of auditing efforts and penetration testing results, we recently experienced a scenario where a publicly accessible form is requesting the user to enter the first 6 numbers of a credit card without performing any client side length checks or setting a MAXLENGTH attribute on the involved form fields.

In addition, any subsequent HTTP request originated by such form is being sent over through the GET method. Assuming this, a regular end user could, erroneously and/or absent-mindedly, type in the whole PAN and eventually send it as a query string parameter in the HTTP GET request to an apache endpoint, which would verbosely log the requests.

Further server side validation routines applied on the mentioned HTTP request are not in the scope of this post, however, and will be ignored. Such credit card numbers were actually revealed within the apache standard log files while auditing the specific application server as part of the normal workflow of a PCI DSS audit on compliance.

In particular, several full PANs were detected within the attached query string which was expected originally to only contain their first 6 digits. Against all application and business logic, the PAN number ended up in a place where it should never have been. We could compare this scenario to the true story of where unsolicited PAN numbers were received via email from users. In the case of email, it suffices to include instructions on what to do with this data and how to get rid of it in your policy. Wheras the case of email is simpler, I am sure that you will agree that this is not the same for the log scenario.

We asked ourselves the following question: Would the PCI DSS compliance of our client be affected? In a way, wouldn't that be considered a "due diligence" issue and imply a direct (or indirect) responsibility for the entity under assessment? Even internally at Advantio Security different QSAs had opposing opinions on this matter.

The QSA working on the case decided it was a compliance invalidating issue. I would, however, like to raise the question as to what would happen if the "not so smart" user put his full PAN in the "name" field and it ends up in the raw apache log? Moreover, what if we were talking about a proxy log and we find the line "get /4111111111111111" ? Would our client still be accountable for any user misbehaviour?

If we fall into this logic there should be NO PCI DSS compliant environment without a sound DLP (Data Leakage Protection) solution in place to prevent any of this from happening. Even then, there is no 100% assurance that a misbehaving user cannot purposely poison our client's logs with PAN data and as such invalidate their compliance status. This invariably opens up the gates to nasty competitors doing this purposely.

In the end, we agreed with the client to mitigate this problem by setting a maxlength attribute to the http form field. However, they still need the same apache log level for their applications to keep working. This means there is still plenty of ways to plant a PAN into their Apache logs without their knowledge.

As usual the ultimate interpretation of the standard is left to the specific QSA and while we our sharing our opinion here, we are very interested in yours as well.

Marco Borza

Written by Marco Borza

I am the Founder of Advantio.
Technology has been my passion since I was a kid; when I first heard the handshake of an old 300bps modem I realised security would be key in an interconnected world. Since then it has become my passion and primary focus.
The reason why I've started my own business is to make IT Security simple.

Certifications: CISSP / CCSA (Checkpoint) / ITIL Foundations / ACSA (ArcSight)/ Linux+/ PCI-QSA / PA-QSA