Authorization without Authentication

Great to see this on IBM's site wrt MQ Series making authorization decisions with no way to authenticate the assertions. The article is on how supposedly you would meet PCI reqts in MQ deployment (emphasis added)

Implement strong access control measures
The requirements addressing this principle are all about authorization. But you cannot have meaningful authorization without also having meaningful authentication. There needs to be some reasonable assurance that you are who you say you are before determining what resources you can access. If the default settings for WebSphere MQ are not updated after installation, the authentication of remote users is only a good faith effort and can easily be bypassed. But it is possible to authenticate remote users at the link level using the native facilities of the product. With this configuration, an ID is assigned to the channel at connection time and lasts for the duration of the session. When the session is from a single user or application, this might be sufficient. But what if the connection is from another queue manager? Or the entire cluster? Is one identity sufficient to authorize all messages from a remote queue manager or the entire cluster? If not, then link-level authentication might not be sufficient. Per-message authentication is possible using WebSphere MQ Extended Security Edition, which cryptographically signs each message that is produced. When the identity is bound to the message, much finer grained access control is possible. This is a case where what we might consider “PCI compliant authentication” depends on the network topology and the degree to which applications share queue managers.
...
For example, when using a gateway or hub in combination with channel security, the hub is authorized to all legitimate destinations in the network. Therefore, any message passing through the hub is also authorized to these destinations -- even though it might not have originated from an authorized application or user. Similarly, applications are typically authorized broadly and are expected to mediate the access of individual users when interacting with WebSphere MQ. When access controls are delegated out to the gateway or the application in this fashion, it is necessary to strongly authenticate the connection to be sure it originates with the trusted component (for example, using SSL) at the very least. In some cases, performing authentication and access control on each message might be a better solution to meet this requirement.

Its the attacker's Royal Road to your enterprise backbone.

The author's conclusion is:

I truly believe that in ten years this will no longer be the case. WebSphere MQ administrators will routinely enable SSL, utilize per-message authentication, strongly authenticate users, change the default settings, restrict administrative rights, and perform penetration tests.

Scary part is there are plenty of MQ implementations published over external B2B or directly connected to web portals (which are "behind the firewall" and so trusted). Anyhow if any of you cloud wonks are looking at a distributed systems security anti-pattern, MQ is a good place to start

Comments

[T.Rob]

Hi Gunnar,

Thanks for the post. I was surprised that you characterized the article as "how supposedly you would meet PCI reqts in MQ deployment". I don't believe it is possible to take any product out of context and make it PCI compliant because compliance is more about the human processes and disciplines than it is about a configuration checklist. But, in the absence of a checklist for a particular product, little or no attention is paid to securing it. This is unfortunately the case with many WMQ installations today. The resources go to the components that are likely to be scrutinized in an audit and WMQ is not one of those components.

The intent of the article was to prop up a straw man that would provoke discussion about what PCI compliance might look like in a WMQ context and to suggest that maybe WMQ security deserves some attention despite the fact that it isn't on many checklists yet. The article was not supposed to be the missing checklist but to engage stakeholders in possibly working to fill that gap. From the article: "In this article, I will discuss some of the PCI DSS requirements to see how they might be applied in a WebSphere MQ context. This area is still emerging and there is not yet a consensus on how these standards might apply to WebSphere MQ -- even within the payment card industry -- but I hope to spark a dialog on the subject."

Hopefully most folks will not come to the conclusion you did that the article was a tutorial on making WMQ PCI compliant. All it was supposed to do was get the WMQ folks talking to the security folks so we could build some consensus about how to apply the PCI criteria to WMQ in a meaningful way. Short of that it also makes a case that a reasonable WMQ administrator evaluating the prevailing practices should find them deficient without needing an audit to point that out. From the article: "I hope this got you thinking about what 'reasonable care' or 'due diligence' means in a WebSphere MQ context. Most of the mitigations discussed here are not widely practiced in the WebSphere MQ community today. However, that doesn’t make them any less reasonable."

I think we have more common ground here than the tone of your post would suggest and I'd certainly welcome any other interpretations of how to apply PCI DSS to WMQ other than my own first stab at it.

Regards,
-- T.Rob

[Gunnar Peterson]

T. Rob- I am glad you published this doc - my comments are not negative towards your paper whatsoever, and I think you described the field level pluses and minuses of real world MQ deployment quite well. Whenever I see MQ in the field I expect to see vulns,

I have never understood how a messaging system can have a coherent security model that does not include message level security. I think the authZ without authN gives people the impression there is far more security than there actually is.

I have been encouraged to see some architectural progress in MQ over the last 4 years, but these things are buried very deep in IT shops and more awareness of what the threats and capabilities is needed, which your article is a great starting point for.