Practical tips to ensure PCI DSS compliance when dealing with message queues

In this final piece, I will continue with some more detailed items on how to ensure PCI message queue compliance.

queue line
Xiaojun Deng (Creative Commons BY or BY-SA)

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

In this final piece, we will continue with some more detailed items on how to ensure PCI message queue compliance.

Queueing; Mobile phones to mainframes

From mobile phones to mainframes, cardholder data and sensitive authentication data is always either in one of three states; being processed in memory, transmitted across a network, or written to disk. If cardholder and sensitive authentication data is ever written to disk for any reason (including temporarily), it must be protected via PCI compliant encryption. Also remember that it also must be securely deleted by some industry standard secure delete process when no longer needed, and per PCI requirements the data must be rendered ‘irrecoverable’. The PCI SSC recommends NIST Special Publication 800-88, Guidelines for Media Sanitization.

PCs and servers

For in-scope PC’s and servers, be aware of any possible ‘store and forward’ scenario where cardholder or sensitive authentication data can be temporarily written to a file or database if transaction communications are inadvertently interrupted. Also for payment applications that run on Windows, ensure that cardholder and sensitive authentication data is not captured by swap or page files.

For Windows systems, consider running Microsoft Encrypted File System (EFS). EFS will encrypt the directories and files that contain the disk-based information. EFS directories will be unreadable by anyone other than the Local Service account. But this does not help though for data in transit.

Midrange and mainframe systems

Midrange and mainframe systems are non-trivial in scope and complexity and so are the payment processing applications that run on them. Payment applications that run these systems may include dozens of inter-host subsystems, modules and various data and messaging queues. It can take quite a bit of analysis and system tuning to ensure reduced transaction latencies and ensure fault tolerance while transaction data winds its way through its pre-disposed path.

Under normal transaction loading a midrange or mainframe payment application will typically process clear-text transaction data only in memory as designed; however, under extreme loading conditions and due to high transaction volumes, transaction messages may overflow the allotted message queue storage capacity and get written to disk in the clear.

Some astute midrange and mainframe administrators have resolved this by creating application programs to monitor the dynamics of all message queues processing cardholder and sensitive authentication data. Message queues have finite size limitations, and the monitoring application constantly measures how full the message queues are in real-time. When pre-determined thresholds are reached (say 80 percent to 90 percent of maximum capacity) the application triggers a PCI compliant encryption process when the queue starts writing to disk under extreme loading conditions.

When the transaction loading recedes to more normal levels, the application then reads and decrypts the temporarily stored data, transmits it for processing and securely deletes the previously encrypted data when no longer needed (post authorization). If there are multiple message queues to be monitored and ultimately overflowed at some time, the application can be tuned to prioritize which queues get attended to first, with special priority given to the ‘oldest’ data in the queues that overflowed. This infers that administrators and application developers better have a solid understanding of overall system loading behavior and performance under various conditions to invoke such ‘active’ monitoring.


When it comes to the cloud, your ability to audit a cloud service provider is often limited to only their set of compliance documentation. With that, the best thing to do to ensure PCI compliance for your messaging infrastructure is to ensure that the cloud provider is PCI certified.

Amazon SQS has a robust feature set and is PCI certified and has a rich feature set. From a security perspective, authentication to SQS is done via the Amazon API key and a secret key. Permissions can be granted and revoked for other AWS accounts to access your queues via the AWS Management Console.

The other big player in the cloud space, Rackspace Cloud Queues is not PCI certified at this time.

Other cloud solutions such as IronMQ run in a third-party PCI certified environment, but the service itself is not PCI certified.

Since most third-party cloud provider don’t provide a PCI certified queueing service, the onus of compliance fall upon the merchant.


For those organizations that want to ensure they are PCI compliant, getting a handle on message queuing is an important step. While the words queue and message queue don’t appear explicitly in the PCI DSS, the fact that the message queue transmits cardholder data and/or sensitive authentication data means that it is something you need to be concerned about if PCI compliance is on your to-do list.

Copyright © 2016 IDG Communications, Inc.

7 hot cybersecurity trends (and 2 going cold)