How to ensure PCI DSS compliance when dealing with message queues

In part 1 of this series, I detailed issues around PCI and message queuing. Here in part 2, we will get more into the nitty-gritty of how to ensure PCI DSS compliance when dealing with message queues.

First off, how do you know if the message is in scope for PCI? It’s in scope if it stores, processes or transmits PCI data. The nature of queuing means that it’s certainly transmitting data.

If that transmission includes any of the following data types: card Primary Account Number (PAN), cardholder name, service code, expiration date, full track data, CVV codes or PIN blocks; then it’s in-scope for PCI.

[ See part 3: Practical tips to ensure PCI DSS compliance when dealing with message queues ]

With that, if you use queuing services with PCI data, it’s imperative to consider what happens to cardholder data (CHD) in transit should the queuing of transaction data be invoked due to various process inefficiencies, latencies or errors?

Let’s start by considering instances where CHD is being transmitted in a traditional point of sale system that is running on some variant of Windows, and for some reason the communications channel is no longer available to process a recently executed transaction request.

To most familiar with such a scenario, we know this is often referred to as ‘store and forward’ transaction scenario or sometimes also as offline processing. To mitigate any possible risk associated with store and forward, some PCI payment application vendors choose to simply not store and forward’ transaction data. Their applications will void the transaction request after a specific communications inactivity timeout threshold has been reached, and the transaction data is safely cleared from volatile RAM. Hence, if the connection does not return, the transaction request is voided and no CHD is intentionally persisted to the system’s non-volatile data storage.

Those vendors that are more concerned with minimizing failed transactions due to connection interruptions have designed their payment application to temporarily store pre-authorization transaction data until the interrupted communications returns. The transaction request is only then processed. This is in a sense a primitive form of data queueing.

From a PCI compliance perspective this is indeed allowed if, and only, if the application temporarily stores encrypted CHD (including in some instances sensitive authentication data) in a temporary file location until the required connection is restored. Once the connection is restored, the data is decrypted and transmitted for processing and, when the transaction is finally authorized or declined, the application securely deletes the temporarily stored CHD.

As for encryption and cryptography, the PCI Council defines strong cryptography as based on industry-tested and accepted algorithms, along with strong key lengths (minimum 112-bits of effective key strength) and proper key-management practices. Currently, examples of industry-tested and accepted standards and algorithms for minimum encryption strength include AES (128 bits and higher), TDES (minimum triple-length keys), RSA (2048 bits and higher), ECC (160 bits and higher), and ElGamal (2048 bits and higher).

When queuing works, you don’t have to give it much thought. The big gotcha and ensuring PCI headache comes along when things fail; such a transactions crash, or page file dump. There can be PCI data being transmitted, and if the action does not fail gracefully, you can have a few bits or a few megabytes of in-scope PCI data.

In most payment applications that rely on traditional Windows and Linux systems that might be involved with store and forward scenarios, it is a fairly straight-forward process to review and validate that store and forward situations are being handled in a PCI compliant fashion. One can utilize forensics analysis techniques to ensure that the data has been handled properly.

But what about payment processing applications that are designed for intensive transaction volumes and that may actually connect directly to payment and issuing networks? In these cases, the payment applications may be running on mid-range or even mainframe systems with dozens of functional sub-process modules, or might even be deployed into highly complex cloud infrastructures. In these instances, the transaction messages containing both the PAN and sensitive authentication data (SAD) may actually get backed up or even go into an error state. The question then becomes once again, “…what happens to CHD in transit should the queuing of transaction data be invoked due to various process inefficiencies or latencies?”

Action items

Here are a few action items:

1. Analyze and understand data queue operations – don’t simply presume that cardholder and sensitive authentication data is being handled properly by messaging protocols and queues. Do not rely on vendor claims of expected behavior and performance. Analyze and completely understand what is happening to cardholder and sensitive authentication data in storage, transmission, and all points in between. Empirically test and review what happens to the messages under various loading and error conditions.
2. Encrypt the queue – an encrypted message payload contains data that can’t be read if the queue fails. If you can use encryption, then certainly do so.
3. Check event logs for errors and warnings – check the operating system, database and application event logs of the message queue. Search for possible errors and alerting related to CHD. Also if data is being temporarily queued to disk and written to a file or database, application and system logging must be able to detect any attempts by unauthorized users and processes to access that data even if it is encrypted.
4. Storage of CHD in Temp Files – some have tried to assert that writing CHD to temporary files is still considered ‘data in transit’. The net-net; anytime this data is written to disk, per the PCI requirements it is not considered to be in transition.
5. Disable anonymous administrative access to the message queue – the default configuration of IBM WebSphere MQ for example allows anonymous administrative access. It’s imperative to restrict anonymous administrative access to the message queue. If this is not done, then no other security configuration matters, as the queue has been left wide open.
6. Be aware of Journaling File Systems (JFS) – Most operating systems perform some sort of file system journaling to ensure data integrity via continuous updates to directories and metadata. This data is often written to disk logs temporarily to help ensure data recovery in the event of a catastrophic system failure.

Next up

In part 3, we continue with action items on how to ensure PCI compliance