Security remediation – DIY?

It’s nice to have been around long enough to be able to watch the WMQ community grow over the years.  You can watch the postings on the Vienna List Server or work though themes as the community goes through its growing pains.  When I first came to MQSeries, the community was still wrapping it’s collective brain around messaging and there was a lot of discussion on how to design messaging applications, naming standards and even on what symbols to use to diagram a messaging network.  Later, discussion moved to things of a more technical nature such as how to keep channels up and running.  Over the years the community has worked through many story arcs, including performance & tuning, version compatibility, product family name changes, JMS, clustering and WebSphere family interoperability.  Security has been trending upward over the last year or so and I’m seeing this both in the online communities and at customer engagements.

The current topics of community interest give us an indication of what activity is going on in WMQ shops.  Security is a hot topic because people out there are getting serious about implementing it.  In the universe of Good Things, this is floating quite near the top, as far as I’m concerned.  But there is a hidden pothole that I want to warn you about and that is verification.  Let me explain further by given an example from my conference presentation.

I have always maintained that on a scale from bad to good, having ineffective security was worse  than having no security.  This is because ineffective security gives an unwarranted confidence.  If you know that you have no security, you don’t entrust your most valuable transactions to the network.  But if you believe you have good security those critical business transactions are the first thing to go onto the network.  If the network is secure, then great.  But what if it’s not secure yet you believe that it is?  Not only are you more likely to put critical data on there, but the probability of new funds being allocated to WMQ security projects actually declines at a point in time when the network is exposed.  What I’ve seen in a few cases, and what I’d like to see the community as a whole avoid if possible, are security implementations that left gaps.

Here’s an example.  I had a customer go to the trouble of writing a security exit pair that validates a user ID and password.  Of course, the exit exchanges credentials in the WMQ channel negotiation and since neither the exit nor the channel encrypted the data, it was easy to sniff the user credentials off the wire.  Although the customer thought they were more secure, anyone who could sniff the wire during the channel startup could capture user ID and passwords not just for WMQ, but in many cases the same password for the user’s domain or other accounts.  In some cases, the same password as the user’s online banking and other personal accounts.  To my thinking this led to a situation of less security, not more.

When I pointed out the problem, I suggested that SSL encryption on the channel would provide the confidentiality needed.  The customer informed me that SSL overhead and certificate maintenance was what they were trying to avoid and then they embarked on modifications to the exit to encrypt the user credentials.  Their approach was to take cryptographic hash of the credentials, salted with a shared secret key known to both sides of the channel.  When I reassessed the solution they proudly demonstrated that the user ID and password were now encrypted and that it was “computationally infeasible” to compute the actual ID and password.

Although this was a true statement, it did not mean the problem was solved.  Since the secret key used to salt the hash was static, the encrypted values for the ID and password never changed.  Although user’s personal passwords were now safe, I could still attack WMQ simply by capturing the credential exchange and replaying it.  I didn’t know what the plaintext credentials were, but I did not need to.  In order to be effective, the credential exchange has to be performed under session encryption with a single-use shared key, such as the encryption that SSL and TLS protocols provide.

My point here is that security is not easy or intuitive.  If you do not think like an attacker, if finding the tiniest seam in the armor and levering it open does not come natural to you, then there’s a good chance you will overlook something.  Even if you are extremely talented at hacking, there is the proofreading principle to contend with – the same mindset that leads you to make a mistake will lead you to overlook it in review.  That’s why typists and data entry clerks do not proofread their own work.  It’s also why an investment in a second opinion on your security remediation is a good idea.

So, by all means use the materials I and others have provided to do your own WMQ security implementation or remediation.  That’s the whole point of the work I’ve been doing, after all.  To build security skills and lower barriers to getting reasonably secure WMQ networks.  But there’s a couple of places where I draw the line.  First among these is that once you think you have your WMQ security in place, to get a second opinion from a specialist.  I have yet to perform a post-implementation review where I didn’t find something wrong.  Had those customers not contracted for a review, they would now be in that position of thinking they had effective security and entrusting their business to an unsecure network.  In other words, their security remediation investment would have actually made the situation worse.  The post-implementation review put that investment to good use by showing the customers how to close the remaining holes.

The other line I’ll draw is at designing and securing B2B interfaces as a DIY project.  All of the security reference materials I’ve posted so far have addressed the most basic WMQ security task there is – hardening administrative access.  But hardening a B2B interface is a few levels of difficulty above that.  With administrative hardening you just need to decide the level of access for non-administrators and apply a few templates.  With B2B hardening you have to consider not only intrusion prevention, but also intrusion detection, forensic analysis capability, data classification, partner isolation and system recovery.  I have a several page document full of nothing but bullet points that I use just to frame the discussion.  When it comes to B2B implementations you are much better off getting that second opinion in the design stages rather than as a post-implementation review.

Now, I know some of you are probably thinking “there’s T.Rob drumming up business.  He must be on the bench.”  Well, yes and no.  True, this is my primary business and I’d love to come and perform a security engagement at your shop.  But the fact is, there’s way more work out there than I can perform and I’d love it even more if everyone started on it now and didn’t wait for me to become available.  There are security consultants out there who know WMQ, WebSphere and WMQ consultancies who know security, and at least one company that specializes exclusively in WMQ security consulting.  The point is, get an independent set of eyes to review that WMQ security implementation, remediation or B2B interface design.  Worst that can happen is you will have validated your work.  But if they find something…then you’ve salvaged your security investment and, just possibly, dodged a bullet.

This entry was posted in IBMMQ, WMQ Security. Bookmark the permalink.

1 Response to Security remediation – DIY?

  1. Mary says:

    If you are interested in learning more about security network my client Cisco is hosting Cisco Live at The Mandalay Bay Resort in Las Vegas…June 27-July 1st.

Leave a Reply