#sensitive authentication data

I was recently reminded of a situation we PA-QSAs face fairly often that I believe is worth discussing. The issue is, what constitutes "storage?"

In this case, a particular client had a local queuing mechanism in which track data were placed, then picked up by a processing module and sent to the payment processor. This is a fairly common occurrence in payment applications. The argument was that data were not actually "stored" in the queue, since it was typically picked up within one second.

Let's first digress a bit to briefly discuss what data are being stored. In this case, the stored data are sensitive authentication data (SAD), which includes magstripe/track data, CVV values and PIN blocks. The PA-DSS is clear about how these data must be treated:

"1.1 Do not store sensitive authentication data after authorization (even if encrypted): Sensitive authentication data includes the data as cited in the following Requirements 1.1.1 through 1.1.3."

The key here is "after authorization." We strongly recommend avoiding storing sensitive authentication data in any way. Indeed, in many cases, a simple re-tooling of the application can obviate the need for storing such elements. If it is absolutely necessary, it is permissible to store SAD up until the transaction has been authorized. Note that the phrase used throughout this discussion is authorization, not settlement. We again sometimes get into a debate about this, and it is quite clear from the language and intent of the requirements that the practice of storing sensitive data is to be exceptionally limited. Thus, this data should be properly encrypted if data is not directly submitted, for example, by an HTTPS request to the processor.

So what happens when we insert a queue into the mix? By definition, a queue must store data, if even for a brief time. That means our data must now be protected, and deleted securely immediately after authorization. The DSS does not make any distinction as to how LONG these data are stored, only that they ARE stored. Whether it is for one day or 100ms, the data are stored, and must be protected.

So what's an application developer to do? Two things must be accomplished:

1) Data must be properly encrypted according to their sensitivity. SAD, PAN data, etc. must be encrypted using strong encryption and appropriate key management as defined elsewhere in the PA-DSS.

2) In the case of SAD, data must be securely deleted as soon as the authorization is complete. A method to detect "dead letters" in the queue should be developed such that an authorized individual can remove dead items in the queue or retry them as appropriate.