This episode of The Deep Queue takes its inspiration from the thousandth time I was asked how to “turn on MQ security”. Yes, that’s right, the thousandth time. At least since I’ve been counting. There were perhaps half a thousand instances before I started keeping track. Unlike being the millionth customer at the local hair salon, you don’t want to be the thousandth person to ask me how to “turn on MQ security”.
“What do you mean ‘turn on’ security?” I asked. “What is it exactly you want security to do for you?”
“Well, you know…SECURE THE QUEUE MANAGER!” came the annoyed reply.
“What I mean is, are you trying to protect from eavesdropping, denial of service, message injection or what? And do you want prevention, detection or forensic capabilities?”
Since nobody there had thought about it in these terms, the answer back was “I don’t know, we will get back to you.” My dilemma is that if I have a ready-made answer for “how to turn on MQ security” it is likely not to address the real requirements…but at least I get work. If I try to drive out the real requirements, I put myself on the bench.
[display_podcast]
Links for this episode:
WMQ Security webinar for QSA’s, internal auditors, security professionals and anyone interested in knowing how to tell if your WebSphere MQ network leaks administrative access: PCIKnowledgebase.com http://is.gd/qqOX
The Black Swan by Nassim Nicholas Taleb: http://is.gd/qqXX
Choosing a PCI DSS Auditor? Does WMQ awareness count?
James DeLuccia’s post about choosing a PCI DSS QSA auditor has some good advice. I would add to his list a criteria one of my own: the auditor should at least know how to spell WMQ. Or JMS. Or “message oriented middleware”. While I haven’t been involved in any PCI audits, many of my customers are subject to PCI DSS. Until recently, it was hard to find a shop that had enabled SSL on their WMQ channels. Even now that we are starting to see SSL enabled, many MQ installations still have misconfigurations that may leave them exposed.
This is unfortunate because, as was seen first with Hannaford Brothers and now with Heartland, the “trusted internal network” is the new frontier of data theft. Enabling SSL is great for protecting messages on the wire but if administrative access is left exposed, the attackers can disable SSL or skip sniffing traffic entirely and instead just browse the messages passing through the queue. The answer to this is not redoubling security at the perimeter. The answer is to apply meaningful controls at the messaging layer. An auditor familiar with your messaging technology would seem to be a valuable asset if the goal is to actually assess security and not merely to pass the audit.
Hannaford was reportedly the first breach of data in transit. Heartland was the biggest card data breach ever. If the bad guys are only up the H’s, what’s in store for firms in the I – Z range? I prefer to think it’s strict auditing of the messaging layer and not massive name changes to monikers starting with A – G. One of these two alternatives actually could make a difference. The other is about as effective as what we have now.
To learn more about how to assess or secure WebSphere MQ, have a look at the presentations on the Links page.
Share this: