PCI Compliance Blind Spot: Middleware
One of the great things about industry standards is that there are usually more than one to salute at any given time. The true acid test for any security compliance standard is how applicable the standard remains given changes in technology, business and governmental requirements and ever evolving threats.
The PCI Data Security Standard is one that, despite grumbling by some detractors in the market space, is written well enough to do exactly that. When one thinks of PCI compliance as it relates to various IT architectures one usually thinks of traditional Point of Sale systems, e-commerce web implementations, and payment processing gateways. To date most of these architectures have involved classical client-server types of infrastructure, and in some instances even with some integrated components that are mainframe based.
A not-so-new, albeit rapidly evolving web-facing IT architecture implemented over recent years is currently testing just how well written the PCI DSS is. It is known as a Service Bus Architecture (SBA) and also sometimes referred to as a Service Oriented Architecture (SOA). It is from these types of implementations that highly sophisticated, large-scale web portals are often comprised. Essentially well-designed, and they often employ non-trivial web application front ends which provide large scale, highly available access to multiple and duplicitous web service offerings and highly diverse database storage capabilities. Due to their scalability and stringent service level fulfillment capabilities they often comprise the core of industrial scale e-commerce, banking and finance web applications and services.
Certainly one can view this type of architecture as essentially being built from a myriad of various client server based modular components. Often they require the addition of additional auxiliary software systems to help ‘sew together’ the components into a cohesive, highly dynamic web and data services framework. These components are often referred to as ‘middleware’. A very specific type of middleware that helps to translate complex messaging across this type of architecture is called, quite simply, message-oriented middleware or "MOM".
From Wikipedia we derive the following definition of MOM:
“Message-oriented middleware (MOM) is infrastructure focused on sending and receiving messages that increases the interoperability, portability, and flexibility of an application by allowing the application to be distributed over heterogeneous platforms. It reduces the complexity of developing applications that span multiple operating systems and network protocols by insulating the application developer from the details of the various operating system and network interfaces.”
Traditionally PCI DSS compliance assessments of web-facing applications have focused on assessing the security of the overall web-facing server and applications components, DMZ-based logical separation components such as firewalls and routers, relevant database storage elements deployed in the interior network, and the communications services between them all. Assessing the PCI data flows associated with such traditional client-server based web application infrastructures is a fairly straightforward endeavor.
Assessing the PCI compliance of highly sophisticated SOA or SBA implementations, however, is a bit more challenging. This is due to the multiple cardholder data flow combinations possible throughout the various SOA application interfaces, numerous database components and possible interconnections with customers, and also between various business partners. This is not a bad thing – it’s exactly why SOA/SBA architectures have been conceived of, and implemented wide scale in the first place. If well designed and correctly implemented, they are remarkably suited and scaled to accommodate industrial scale web application based business services provision.
In large part, a good percentage of communications between such non-trivial architecture components is facilitated by middleware messaging software and systems. And as one might suspect is the case when dealing with the storage, processing, and transmission of cardholder data, it is often precisely the scheme used to help transmit various aspects of the payment card transaction authorization and settlement processes. These can include actual transaction requests and responses, back-end settlement capabilities, and various types of reporting.
When considering middleware systems compliance with the PCI DSS, the very same requirements that are applied to client-server or mainframe systems applies. At a very high level they can be summarized as follows:
1) Develop and maintain system build standards that reflect industry recommendations for securing such systems. These are often referred to as “hardened” build standards.
2) Design and implement ‘hardened’ system builds to reflect the principles of disabling unnecessary services and protocols, denying most access and permitting only a select few to use, log all privileged access to such systems, and protect passwords in both storage and transmission.
3) Build, implement, and maintain all PCI system supporting components from these standardized, “hardened” system build specifications.
4) Protect systems from un-authorized access and compromise attempts.
5) Protect the storing, processing or transmitting cardholder information in accordance with PCI DSS specifications.
There are obviously more subtle aspects to the PCI DSS that also apply, however, the fact remains that middleware is by no means allowed any differing or diminished security considerations than any other systems handling cardholder information.
As with many operating systems, web software, payment applications, network components, etc., it is often the case that default installations of associated software are not auto-magically configured to be compliant with PCI DSS or any other security standard. It is incumbent upon those architecting and implementing such systems to sufficiently harden their configurations such that standards compliance, and indeed optimal critical data protection is achieved. A good example of this is with respect to message-oriented middleware software is IBM’s WebSphere MQ (WMQ). A default installation of the product right out of the box will most assuredly not be PCI DSS compliant.
The good news is that IBM has its own core WMQ subject matter expertise, and indeed an evangelizing subject matter expert on the proper assessment and securing of WMQ implementations. His name is T.Rob Wyatt.
T.Rob has many years of experience with WMQ and has provided guidance to quite literally hundreds of IBM customers, as well as the IBM ISS Global PCI Practice in assessing and supporting PCI compliant WMQ implementations.
T.Rob’s diligence, passion for “getting the message out” and un-yielding efforts to accurately convey WMQ best practices and techniques are commendable. He is a tremendous asset and is ready, willing and able to help. His thinking and efforts are entirely consistent with the philosophy of the Information Security industry whereby “security through obscurity” never works out. Even if attempted, more damage will probably occur over the long run than not. He also believes that the best defense is a good offense when it comes to securely configuring WMQ and other systems. As was said in Ghostbusters the movie, “…we have the tools and we have the technology.” Now let's go forth and make it a better, no check that, “let’s make it a smarter WMQ world”.
You can find more about T.Rob and his efforts at the following website and twitter:
In the next blog installments, we will review T.Rob's WebSphere WMQ best practices recommendations, and how not addressing them can adversely affect your overall PCI compliance if using WMQ in PCI environments.