I have been playing with the alpha and beta versions IBM WebSphere MQ Advanced Message Security for quite a while, but I was unable to discuss it publicly prior to the announcement on October 5. Now that I can finally tell you about it, it’s almost like I'm back in school reporting on what I did over the summer – except that instead of squandering my summer on leisure activities, I was actually involved in a project that will make a significant impact on the security of messaging systems around the world.
Of course, IBM WebSphere MQ Extended Security Edition filled a similar place in the WebSphere MQ product line-up, but its footprint and complexity really made it more of an enterprise product. In contrast, WebSphere MQ Advanced Message Security has almost no visible footprint and is suitable for anyone at all who runs WebSphere MQ servers or clients on supported platforms, from big enterprise shops right on down to small shops with only one or two queue managers in production.
When I started presenting on WebSphere MQ security at conferences back in 2006, I predicted that in ten years certificate-based authentication and encryption would be routinely used on the messaging network. It seemed a very optimistic prediction at the time, given how few shops were configuring even basic WebSphere MQ security. But over the last few years I have seen a remarkable rise in security controls deployed in the field along with renewed customer interest. The new capabilities of WebSphere MQ V7.0, combined with WebSphere MQ Advanced Message Security, build on the functionality formerly available only in WebSphere MQ Extended Security Edition while making it accessible to the masses.
You might be wondering at this point why I believe "the masses" would need something like WebSphere MQ Advanced Message Security. The fact is, the ways in which messaging has been secured have not kept pace with the changing ways that messaging is used. Security controls exist at the connection and at the queue or topic, but the way messaging is commonly deployed today benefits from security at the message level. This trend is accelerating.
Let me take a few moments to explain this idea further and then I'll explain how WebSphere MQ Advanced Message Security can help.
Message-oriented middleware relies heavily on a perimeter security model. Traditionally, this class of software has operated on the "trusted internal network" to exchange messages between applications. But messaging has become pervasive and is no longer confined to these limited roles.
The term "trusted internal network" was coined to differentiate that part of the network that was internal from destinations outside the firewall. But the term "trusted" as used in this context is relative. It was not supposed to indicate that the internal network was trusted implicitly, only that it was more trusted than things outside the firewall. Unfortunately, the term is sometimes interpreted quite literally. I have had clients quite earnestly tell me by definition we trust everything on the "trusted internal network", that's why we call it that. Of course, this overstates the case, because even the staunchest believers in trusting the internal network still enforce password-based login to servers, databases, and applications. So the internal network is trusted, but only up to a point, and even on the internal network authentication and authorization are essential.
But even if we agree that we don't trust the internal network, do we know exactly where the internal network ends? The boundary between the internal and external network has blurred over the years. Extranets extend not just connectivity, but often also routing, name resolution, authentication, and other services to destinations outside the firewall. Virtual private networks (VPNs) extend the "trusted internal network" to employee laptops out in the wild: in homes, hotels, airports, coffee houses, and anywhere there happens to be an Internet connection. Where exactly is the perimeter when so many legitimate, full-service connections originate outside the firewall? Doesn't this inside-out approach to defining the perimeter demand stronger security controls?
Before answering that, consider also the shift from three-tier messaging systems to two-tier systems. Traditionally, messaging was used by the middle-tier applications. Users connected a browser or client on their workstation to an application server, which in turn connected to a queue manager. The recent trend, however, has been to directly connect the user's client to the queue manager. Newer technologies, such as the HTTP interface to WebSphere MQ and IBM WebSphere MQ Telemetry Transport, will accelerate this trend by delivering messaging functionality to an ever-growing population of devices at the edge of the network. In the three-tier architecture, the queue manager knew only the identity of the application. In the two-tier model, the queue manager must know about the identities of all the connected users and devices, and deal with the fact that they are frequently located outside the firewall.
The consequence of these trends is that we need increased granularity of one or two orders of magnitude in the security model at precisely the same time that we need better perimeter security. Fortunately, WebSphere MQ Advanced Message Security is here to meet that challenge.
WebSphere MQ Advanced Message Security, which became available on 8 October 2010, provides authentication, enhanced authorization, and encryption of messages. It was designed to integrate very closely with WebSphere MQ and to eliminate dependencies on external components. WebSphere MQ Advanced Message Security requires no additional servers or daemon processes to run, and, as a result, it is easy to implement and capable of securing additional IBM WebSphere products, such as IBM WebSphere MQ File Transfer Edition.
One of the primary design goals of WebSphere MQ Advanced Message Security was to avoid any requirement for making application code changes. To achieve that goal, WebSphere MQ Advanced Message Security is implemented as three types of interceptors:
- Java interceptors catch calls to the JMQI layer and therefore work with both Java and JMS applications.
- The C client interceptors catch calls to the C client libraries.
- An API exit intercepts bindings-mode calls. When the interceptor has performed its function, the call is passed to the original MQ library or class.
These three types of interceptors provide comprehensive application coverage. For example, there is longer any special handling of JMS managed object definitions required. This architecture also reduces dependencies on the native WebSphere MQ libraries so that applying maintenance to both WebSphere MQ and WebSphere MQ Advanced Message Security will be simple.
Because WebSphere MQ Advanced Message Security is entirely based on interceptors, there are no additional programs to run. When the queue manager or application is started, normal API calls are passed to the WebSphere MQ Advanced Message Security libraries that execute and then call the underlying WebSphere MQ libraries. The administrative functionality is provided through a WebSphere MQ Explorer plug-in and a set of command line tools.
WebSphere MQ Advanced Message Security can sign and encrypt messages at the point of production, and then decrypt and authenticate them at the point of consumption. At all points in between, the message is protected, either for integrity (using hashing) or for privacy (using encryption). If privacy is enabled, the message payload is encrypted on the wire, in memory, on the queue, in the log files, and in any traces that are taken. The message header remains in plain text so that the queue manager can route it properly. Depending on the policy that is set, access ranges from no special restrictions to the ability for the administrator to specify an enumerated list of authorized signers and recipients of messages on a particular queue.
This is really just a glimpse into WebSphere MQ Advanced Message Security, and so I encourage you to explore the product more using the Resources below.
One of the prime use cases for WebSphere MQ Advanced Message Security is to help with the problem of the disappearing perimeter, and B2B connections are a good example of this. Since WebSphere MQ Advanced Message Security does not require central policy servers it works quite well in B2B situations.
WebSphere MQ Advanced Message Security provides additional controls by establishing a security perimeter at the message level. Each message is transported in its own crypto envelope, which includes both the payload and the identity of the sender. This envelope travels with the message from the producing application all the way to the consuming application. WebSphere MQ Advanced Message Security enables authentication of inbound traffic on a per-message basis, as well as strict restrictions on which queues those messages can be sent to and which recipients can receive them. This is especially helpful for connectivity over VPNs or extranets.
A specialized case of the extranet topology is the clearing house, which is common in many industries; finance, healthcare, and insurance are a few that come to mind. In order to provide security and isolation of customers, many vendors running clearing houses provide separate paths for each customer. Usually, these involve separate queues, channels, and listeners, but in some cases these also involve dedicated queue managers. Essentially, this works by embedding security policy into the physical connectivity layers of the network. The more isolation that is provided, the more expensive the configuration is to maintain.
Since complexity is the enemy of security, there is also a limit to how much security can be attained this way. With WebSphere MQ Advanced Message Security involved, security is managed by policy, and the structure of the physical network is guided more by things like capacity planning. As a clearing house vendor, I would be interested in WebSphere MQ Advanced Message Security to move security management out of the network topology because it would greatly simplify my physical controls and save money. As a client, if I had a choice between a service offering with WebSphere MQ Advanced Message Security and one without, I would pick the WebSphere MQ Advanced Message Security version because of greater accountability and security.
One very common question I get is how to configure WebSphere MQ to meet PCI-DSS (Payment Card Industry Data Security Standard) or other regulatory compliance requirements. It is not really possible to declare any product PCI compliant, since much of the standard applies to human processes and controls. However, it is possible -- and appropriate -- to explore how specific configurations fit into the overall compliance requirements. In the case of PCI-DSS, a requirement exists for protection of cardholder data. This is usually implemented with encryption. WebSphere MQ alone can encrypt the data in transit as messages traverse channels, but it does not encrypt the messages while the queue manager processes them. This means that the text of the messages is readable in memory, in log files, in traces, and in the files that back the queue structures. For compliance, these issues can be addressed through the use of mitigating controls such as isolating the queue manager with a host-based firewall and auditing login sessions on the queue manager's server. Typically, multiple controls will be combined to form a layered defense. With WebSphere MQ Advanced Message Security, the messages are encrypted before they are handed off to the queue manager. This means that they are encrypted even on non-SSL channels, as well as in any of the ephemeral copies the queue manager might make. Because the messages are never in plaintext while in custody of the queue manager, the need for many mitigating controls is eliminated, and might even remove the queue manager from the scope of the PCI audit entirely.
Another aspect of regulatory compliance is separation of duties. A WebSphere MQ administrator has the ability to intercept, edit or inject messages to any queue. For compliance or for sensitive applications, this level of access is sometimes undesirable. When applications sign their messages using WebSphere MQ Advanced Message Security, it is impossible for even the WebSphere MQ administrator to alter them or to inject rogue messages without detection. If the messages are also encrypted, then the WebSphere MQ administrator will not be able to decipher them. Be aware that the administrator can still access the queue, including to remove protected messages. This is necessary, for example, to remove a poison message from the queue when an application gets stuck. However, the message will be unreadable to the administrator, which addresseses the compliance requirement. (You can configure whether the WebSphere MQ administrator should be able to read the encrypted message; a less restricted application can always choose to list the administrator as an authorized recipient when the message is first produced.)
The clearing house model discussed above is a hub-and-spoke pattern, where the spokes are each a different B2B interface and the goal is to keep the spokes from communicating with each other. But many shops have internal hub-and-spoke networks and these present the opposite security challenge.
In this case, the goal is to enable the spokes to exchange messages, but to do so in a secure manner. When authentication and authorization occurs on a per-connection basis (as is the case with WebSphere MQ), all messages arriving at a spoke node appear to have originated at the hub. In order to participate in the network, the spokes must implicitly trust the hub. Enforcing security at the destinations requires that identities of all spoke nodes are defined on the hub, as well as on a plethora of QRemote and QAlias definitions, against which authorizations can be set. Once again, this is the practice of embedding security policy into the physical network design. Not only is this complex, but it can result in an increased burden of security at the hub. This is because if the hub is compromised, the entire network is compromised.
WebSphere MQ Advanced Message Security moves the authentication and authorization functions from the connection down to the message level. Because messages on a queue can be traced back to their sender, and the security policy is applied at the point of consumption, it matters less that the entire network is aggregated in a single connection from the hub. This relieves the hub of much of the responsibility for security and greatly simplifies the hub configuration.
WebSphere MQ Advanced Message Security can also help with WebSphere MQ cluster security. Unless a channel auto-definition exit is used, authorization of all the remote nodes in the WebSphere MQ cluster is based on the MCAUSER value in the cluster receiver channel definition. This is very much like the hub-and-spoke, in that traffic from all nodes in the WebSphere MQ cluster arrives over a single channel; therefore, authorization for all cluster nodes is aggregated into that one connection. If any remote node in the cluster is authorized to a queue, then all nodes in the cluster can send messages there. WebSphere MQ Advanced Message Security does not change this, but it does add an additional layer of control at the message level so that something consuming messages from a queue can distinguish between different senders and reject unauthorized messages. Since a CHAD exit operates at the connection and queue level and WebSphere MQ Advanced Message Security operates at the message level, the two things are complimentary. Although WebSphere MQ Advanced Message Security might reduce or eliminate the need for a CHAD exit in the cluster, it will not displace an existing one.
One of the most useful features of WebSphere MQ Advanced Message Security is the ability to support a large population of identities. As noted earlier, users are coming out from behind server applications and connecting to the queue manager directly. In general, messaging connectivity is moving to the periphery of the network and showing up on user workstations, browsers, instrumentation, standalone devices, and even phones. This means that security in the messaging layer must now support many more individual users and do so with a per-user granularity. This will not scale well as long as security is managed at the connection and queue level. With WebSphere MQ Advanced Message Security, it is possible to aggregate security at the connection and the queue, which simplifies the physical network topology. The additional granularity is then implemented at the message level based on policies about who can sign and who can consume messages on a given queue.
This migration of messaging out to the network edge also means that connections to the queue manager now commonly originate from outside of the locked data center. When the connection migrates from a client-connected application server to a client application on a user's desktop, it appears to the queue manager to be just another client connection -- and often we are tempted to use the same controls and security model as before. But the removal of the physical security controls that were afforded by the locked data center mean that a client application "in the wild" should be more strongly authenticated and its access more strictly enforced. With WebSphere MQ Advanced Message Security, it is possible to use a single certificate to authenticate the connection and to sign the messages, or separate certificates can be used for each purpose. This provides a range of qualities of service and options to build additional security into shared office applications.
Naturally, there are many more use cases for WebSphere MQ Advanced Message Security than can be discussed in this limited space, but these are some of the ones that I encounter most frequently. The common thread is that the security models we implement for messaging need to keep pace with the ways in which we use messaging. Although basic security might have been good enough for the "trusted internal network" with point-to-point topology and a three-tiered architecture, today's messaging implementations require stronger authentication and controls at the message level.
An important feature in WebSphere MQ Advanced Message Security is the ability to protect the queue manager's internal queues. Many WebSphere products, such as WebSphere MQ File Transfer Edition, use SYSTEM.* queues for administration and for normal operation. Extending the WebSphere MQ Advanced Message Security functionality to include these other WebSphere MQ family products requires that the administrator be able to apply policy to these SYSTEM.* queues. WebSphere MQ Advanced Message Security was designed specifically to address this need.
Consider the example of WebSphere MQ File Transfer Edition. Like most WebSphere products, it listens on a queue, performs administrative and user actions based on commands placed there, and sends replies to the requestor. The first task in securing a WebSphere MQ File Transfer Edition agent is to restrict access to this command queue. For things that connect directly, such as the agent itself, this can be handled with basic WebSphere MQ security. But what about things that send commands from other queue managers? Because WebSphere MQ security is based on the connection, it is the other queue manager that is allowed to access the local command queue, and the individual users or applications on that queue manager are aggregated into that one connection. It would be much better if access could be granted (reliably) to specific identities sending commands from that remote queue manager.
Because WebSphere MQ Advanced Message Security attaches an identity to each message and enforces policy based on that identity, it is perfectly suited to the task. An administrator can now specify an enumerated list of users, instrumentation, and remote WebSphere MQ File Transfer Edition agents that are authorized to place messages on the command queue of a given agent. Any messages that do not have these authorized identities attached are rejected before the WebSphere MQ File Transfer Edition agent ever sees them. This makes it easier to place WebSphere MQ File Transfer Edition agents securely onto existing WebSphere MQ networks, including clusters and hub-and-spoke topologies.
With access to the WebSphere MQ File Transfer Edition agent's command queue suitably restricted, a useful enhancement might be to encrypt the file data as it flows between agents. Each agent has several dedicated queues, including one for exchanging data with other agents. By placing a WebSphere MQ Advanced Message Security protection policy on the WebSphere MQ File Transfer Edition agent's data queue, it is possible to transparently encrypt the file data as it is transferred between agents. Because the messages are encrypted before they are passed to the queue manager, the data is protected in memory, in the queue files, in logs, and in traces.
Protecting the WebSphere MQ File Transfer Edition agent's command and data queues provides the kind of security controls that help to meet regulatory requirements for any type of sensitive data. WebSphere MQ Advanced Message Security will reduce the need for many compensating controls, possibly even removing the queue manager from the scope of the PCI audit. The reduced cost of compliance might even more than offset the cost of a WebSphere MQ Advanced Message Security license, which translates to very fast (if not instant) ROI. In my opinion, I believe that PCI -- and for that matter, HIPAA, SOX, FISMA and pretty much any compliance requirement -- will be less expensive to meet with WebSphere MQ Advanced Message Security than without.
But from my perspective, as someone focused generally on security, compliance is perhaps the least important reason to consider WebSphere MQ Advanced Message Security. I'm more concerned with broader issues: Is there B2B connectivity in the picture? Is there a WebSphere MQ cluster? Is there a hub-and-spoke network? Are there large numbers of client connections? Do remote connections originate from end user devices? Is the population of identities requesting connections very large?
Security is easier to implement in all these scenarios with tools added to the mix that operate at the level of individual messages rather than per-connection or per-queue. Now that those tools are accessible to every size shop -- from global enterprises to a WebSphere MQ client-based application on a laptop -- the security model can catch up to the architecture. That would remove much of the latent risk that is currently built into our messaging networks and, at the end of the day, that risk mitigation is the real benefit of WebSphere MQ Advanced Message Security -- and that's something we can all use.
MQ Advanced Message Security product information
MQ Advanced Message Security Information Center
MQ Advanced Message Security announcement
Redpaper: Understanding IT Perimeter Security
Redbook: Enterprise Security Architecture using IBM ISS Security Solutions
Podcast: The Deep
Author's Web page: T-Rob.net
Blog on Messaging
Vienna WebSphere MQ List server
developerWorks WebSphere MQ forum
T.Rob Wyatt is a Senior Managing Consultant with IBM Software Services for WebSphere who assists customers with the administration, architecture, and security of WebSphere MQ. Recently he has focused on WebSphere MQ security, publishing in the IBM WebSphere Developer Technical Journal and presenting at the IMPACT and European Transaction and Messaging conferences. T.Rob also hosts The Deep Queue, a monthly WebSphere MQ security podcast.