Americas

  • United States

Asia

Oceania

benrothke
Contributor

Message in a PCI bottle – preserving message queue integrity

Tip
Jun 28, 20164 mins
Cloud ComputingSecuritySoftware Development

Ben Rothke and David Mundhenk close out their series on achieving PCI compliance when dealing with message queues.

First, a confession. When David and I started writing this series, we envisioned it would be completed after the third part. It appears we were a bit short-sighted. An astute reader challenged us to help address the concepts of preserving queue message data integrity. With that, we welcome you to part 4.

In parts 1, 2 and 3 of this series we wrote at length about the possible compliance and security issues associated with the queueing of cardholder data (CHD) within a PCI compliant cardholder data environment (CDE).

The queuing of CHD in volatile system memory can sometimes be affected by system resource issues due to loading, transaction latencies, intervention by journaling file system processes and more. Under such circumstances, a payment application or operating system may temporarily write CHD to disk. When this happens, and it’s not infrequently, the CHD is often written to disk undetected and unprotected.

Our interested reader of the previous article asked how to ensure the integrity of CHD when it’s transmitted from one queue to another within a given system, or even if such data transmission occurs across a suspect trust boundary such as the internet. What tools or safeguards are available to application developers that could help protect the integrity of the messages being sent? Also, he asked, wouldn’t it be great if there could be some level of assurance that the sender of the message is genuine and can be validated as a trusted entity? This would be especially important if the content of such messages contained payment transaction data including cardholder data, or even other such sensitive data such as personally identifiable information (PII) or other authentication requests.

MAC – meet HMAC

Enter the dragon that is the Message Authentication Code (MAC), and its more secure cousin the hash-based Message Authentication Code (HMAC). A MAC is a minimal piece of information used to authenticate a transmitted message. The HMAC is a specific, albeit special type of message authentication code that couples a cryptographic mathematical hashing function along with pre-shared secret cryptographic keys. HMAC authentication code provides the server and the client with a cryptographic key that helps to protect the integrity of given message while in transit, and also helps substantiate the sender as a trusted entity.

[ MORE FROM THIS SERIES: How to ensure PCI DSS compliance when dealing with message queues ]

For the HMAC, the secret key is known only to the server and specific client system. Using the secret key and a cryptographic hashing function, the client creates a unique mathematical hash to be sent to the server per each message being transmitted. Upon receipt of the message, the server then generates its own HMAC based upon the pre-shared, secret cryptographic key and compares the two values. If the values match, the client has been trusted and there is a high-level of assurance that the message has not been tampered with. If not, the data and the sender are suspect, the message is discarded and the event is hopefully recorded within an event log. Inordinate numbers of discarded messages are often harbinger of an untrusted sender attempting to communicate with a message recipient in an unauthorized fashion.

While authentication and data integrity has been preserved in HMAC use, it should be noted that any sensitive data contained with the message (such as CHD) could still require additional protections. This can be accomplished by encrypting the data prior to transmission using strong cryptographic algorithm, or by using a cryptographically strong, encrypted transmission protocol such as TLS v1.2 or IPsec.

HMAC use is becoming ubiquitous due in part to the prevalence of cloud computing and web services architectures. Entities attempting to connect to Internet exposed web services must have a valid, pre-shared cryptographic key or the messages being transmitted are suspect and ultimately discarded. That using Amazon Web Services can integrate its own messaging architecture called Amazon Simple Queue Service (SQS)

HMAC at AWS

Not only is it quite easy to get queuing working on AWS, they also provide good documentation on how to do it. For anyone using AWS, a good place to start is here. Amazon does a good job of providing the steps on how the HMAC basic authentication process works.

For those who want a more detailed understanding of how Amazon SQS queues work, a great place to see is here.

Conclusion

As stated previously, message queue security is something not enough people think much about. In this, our final installment in this four-part series, we hope you now have a better appreciation of the importance of message queuing, especially for those needing to be PCI compliant or otherwise interested in preserving message data integrity in transit.

benrothke
Contributor

Ben Rothke, CISSP, CISM, CISA is a senior information security specialist at Tapad and has over 16 years of industry experience in information systems security and privacy.

His areas of expertise are in risk management and mitigation, security and privacy regulatory issues, design and implementation of systems security, encryption, cryptography and security policy development.

Ben is the author of Computer Security - 20 Things Every Employee Should Know (McGraw-Hill). He writes security and privacy book reviews for Slashdot and Security Management and is a former columnist for Information Security, Unix Review and Solutions Integrator magazines.

He is a frequent speaker at industry conferences, such as RSA and MISTI, holds numerous industry certifications and is a member of ASIS, Society of Payment Security Professionals and InfraGard.

He holds the following certifications: CISM, CISA, CGEIT, CRISC, CISM, CISSP, SMSP, PCI QSA.

The opinions expressed in this blog are those of Ben Rothke and do not necessarily represent those of IDG Communications, Inc., its parent, subsidiary or affiliated companies.