To queue or not to queue, that is the PCI question

In the first of this three-part series, we detail issues surrounding message queuing and how to ensure it doesn’t break your PCI DSS compliance effort.

waiting in line
VeloBusDriver (Creative Commons BY or BY-SA)

Growing up, while other boys dreamed of being astronauts or NFL quarterbacks, one of the authors (we won’t say which) dreamed of being a message queue programmer. While the NFL quarterback gets all the glory, it’s the message queue programmer who ensures the packets get there.

While no one really dreams of a message queue programmer, and in fact most people are clueless to the underpinnings of message queuing, it’s a highly important part of IT. From a security perspective, there are a number of key considerations to ensure the security of the data being transmitted. From a PCI DSS perspective, the message queue is often an area not even considered, which may indeed be in scope for PCI.

In our previous set of articles, we discussed application security and PCI. In this piece, we are going to address queuing issues and PCI. During recent PCI assessments, we have uncovered some edge cases where cardholder and sensitive authentication data is written to disk unbeknownst to application developers and owners. That’s why we are writing this piece. For those looking for guidance on queuing and PCI, we found that there isn’t a lot written on the topic.

Queue 101

Most applications and programs use some sort of queuing. In the open source space, some popular programs include Apache ActiveMQ and Qpid, JBoss Messaging, stormmq, Beanstalkd, IronMQ and others.

In the commercial space, SQS has become quite popular. Microsoft Message Queuing (MSMQ) is heavily used within Microsoft applications. Another big player is IBM WebSphere MQ.

Message queues are powerful for reasons too many to list here, but some of the more compelling ones include:

  • Decoupled services – ability to separate the messaging functionality from the application logic
  • Resiliency – a fault in the queue won’t bring down the application in event of a failure
  • Guaranteed delivery – can ensure that the message is delivered

When it comes to security, many queuing services are optimized for speed and not for security. And that is a red-flag when it comes to PCI.

Depending on the service and how it’s configured, the messages may or may not be sent securely. Authentication mechanisms are available, but it’s up to the designer to ensure that it’s implemented.

The surest way to ensure the data in the queue is secured is by using encryption supported by queue application. If the data is effectively encrypted, then most of your security issues will be obviated.

The challenge with queuing and encryption is that depending on the scenario, you may not have direct control of the ephemeral data used by the queuing software.

Also, the software may write data to log files. Depending on the configuration, the data could remain in the log files until it’s overwritten or is actively deleted. Adding to the potential security headache is that data could exist for years. In addition, based on the backup scenario, the data could be copied to tape or cloud backup.

The queue and PCI

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.

Coming up next

If you use queuing services with PCI data, it’s imperative to consider what happens to cardholder data in transit should the queuing of transaction data be invoked due to various process inefficiencies, latencies or errors.

Read part 2 of this series. And then move on to part 3.

Copyright © 2016 IDG Communications, Inc.

7 hot cybersecurity trends (and 2 going cold)