One of the reasons I started this blog was to give me a place to put updates things I publish elsewhere. I have discovered that web-based journals can be almost as difficult to get updated as printed journals and yet I have no shortage of updates I need to make. On the one hand, there are the usual typos and clarifications. Other times readers send questions that would add to the discussion but the articles have no online feedback like a blog does.
The other reason I need this vehicle is that security practices are ever changing. The developerWorks journal is a great place for the kind of articles that I write because of the very broad and deep readership it enjoys. I am privileged to be able to contribute for that audience and within that community of authors. But the articles published there capture security practices as a snapshot in time. The more specific the article is in terms of providing technical configurations, the more likely it is to need updates sooner rather than later. This is true of security in general but especially true in the case of WebSphere MQ security, simply because the field is changing so fast right now.
Going forward, I’ll post a blog entry for each new article. Feel free to make comments or ask questions about the articles through the blog. As I have updates, I will update the blog post rather than make a new one and in this way we will capture the history and discussion in one place.
If you wish to subscribe to these posts, I will use the categories “Publications“. When and if there are any errata to report, I will add the category “Errata” when I update the post. I will be creating placeholder posts for past articles shortly.
WebSphere MQ security heats up
developerWorks article WebSphere MQ Security heats up from November 2007.
WebSphere MQ had been in the market 14 years when this article was published. During that time the two big changes to the product’s security posture were to set MCAUSER blank by default due to strong customer feedback, and the addition of SSL as a channel option. The first made WMQ wide open by default and the second was only used by a relatively few customers. Over the years, WMQ security was systematically ignored by users and hackers alike.
But Martyn Ruks presentation at Defcon 15 changed that. WebSphere MQ was “outed” to the hacker community. For me and at least a few WMQ shops out there, this signaled the start of an arms race. In this article and in presentations at the conferences I made a case to start securing the messaging network now – before there is a breach reported. Of course, for many shops out there it will take one or more publicly reported breaches of WMQ before they perceive a business case to secure WMQ.
The problem with that approach is that security is not something you just “turn on” and walk away. As I discuss in my most recent article, WebSphere MQ, PCI DSS, and security standards, security is just as much about the human processes and policies as it is about configuration. It is a discipline and as such it needs time to mature within an organization and it requires an ongoing commitment. The idea that you can wait for a breach to occur (and hope it happens to someone else) and then just magically switch on security is unrealistic. Continue reading →
Share this: