Please help us in welcoming T.Rob as our first contributor to the Tek-Tips blog. Please see our blog post to learn more about T.Rob and his expertise in all things WebSphere MQ.
Some time ago, I worked for a school board in Florida. One interesting aspect of that job was that the projects from year to year were decided by the state legislature. Unlike many IT projects in private industry, these carried the weight of law and came ready-made with proscribed fines and/or jail terms for failure to complete the projects on time. Talk about an incentive to bring your project in on time!
In private industry, choice of projects and deadlines are a little more flexible but there are still regulatory compliance requirements that carry the rule of law. Here in the US, one of those is the Sarbanes-Oxley Act, or SOX as it is more commonly known. SOX holds corporate executives personally accountable for the accuracy of their financial data.
I propose that many of the SOX certifications in place today rightfully should not have been issued.
Let me explain. One key requirement of SOX is that execs are required to certify under penalty of law that their financial data are true and accurate. For example, most corporations don’t let just anybody in the company update the financial records. There are processes in place to limit access to these records, and checks and balances to limit the ability of any one person to make fraudulent entries. If these controls were not present, there would be no accountability and therefore no basis on which to claim that the data are indeed true and accurate.
It’s one thing to certify that the aggregate financial data are true and accurate, but what about the actual transactions from which revenue flows? Suppose that it was common practice to let anybody in the company, from the CEO on down to the maintenance and houskeeping staff, access, modify and update customer transactions? Would it be accurate then to say that there were sufficient controls and accountability to satisfy SOX? I would say definitely not. Yet, this is the situation that I encounter in the vast majority of cases in my role as a WebSphere MQ security consultant.
Although WebSphere MQ can be configured to restrict administrative access, in most cases, it is not. The result is that anyone with an IP route to the queue manager (a queue manager is a running instance of WebSphere MQ) can anonymously connect and access any message flowing through the system, delete messages, update them or inject rogue messages into the system. This situation is what I usually find when performing security assessments. The queue manager is completely exposed to the entire intranet. Occasionally I find a shop where anonymous connections have been restricted. In nearly all of those cases though, legitimate users and applications are granted administrative access. This still falls far short of what I’d consider to be effective internal controls.
What is at Risk and Why?
You might be wondering what exactly is the exposure here. Message queuing is the glue that connects applications and is ubiquitous in corporate IT shops. Messages may be ATM transactions, patient health data, insurance claims, card payment transactions, travel bookings, fleet dispatch orders or just about anything else. The risk is in either stealing the data or in executing rogue transactions. In addition, WebSphere MQ provides its administrators a function to remotely execute commands on the MQ host server. When ordinary users and applications are inappropriately granted administrative access, they inherit this remote code execution capability on the servers which host the company’s most critical business applications.
There are a number of factors which give rise to and perpetuate this problem. Primary among these is that WebSphere MQ security is not well understood. By default a remote connection will pass the user’s local ID to the queue manager for authorization. This is widely used as the basis for very granular and often complex security models. What is not commonly known however is that the user can optionally choose to pass in any arbitrary ID, including an administrative one. WebSphere MQ can be configured to authenticate these IDs that are passed in but usually it is not.
Because the ID passed in appears to have been authenticated, there is a general misconception that it has been and can be trusted. In fact, the exact opposite is true. The result is that the companies most exposed are usually the ones that are most confident in their messaging security. They certify the veracity of their financial data simply because they don’t know any better.
How to Tell if You Are Impacted
Wondering how good your MQ security is? Try this thought exercise. Ask around to see what the opinion of the MQ security is among the administrators, project managers, architects and other stakeholders. If you find that the company is highly confident in the MQ security, chances are there’s trouble brewing.
If the company knows the network is wide open, chalk up some points for self-awareness. The company has either accepted the risk or is in the process of mitigating it.
On the other hand, if the company has deep security skills the confidence will probably not be as high, especially with a large network. The larger the network, the more likely something is missed. There is also the notion that the more you know about information security, the less confident you are. It’s an arms race between the white hats and the black hats and you never know how where you stand until you are breached. A shop with deep security skills will have a healthy skepticism and a certain amount of doubt about the security of all their systems, including the middleware. They will have a program in place to subscribe to security updates for all their products, automated scanning, incident response plans and continuing education. When someone tells me they think the messaging network is “fairly secure” or otherwise qualifies their opinion, I have some hope.
But if you find a high level of confidence in the security of the MQ network there are only two possibilities. One is that the company has invested in training the administrators, funded the necessary security hardening, performs regular scans and has some reason to believe the job was done correctly. The other is that the network is wide open and the company does not know how to assess it. Since the first possibility is something that rarely happens, there is a very strong correlation between high confidence and poor security.
If you are one of the executives who signs off on the SOX certification for your company, it’s time to check your messaging network. If security has not been enabled correctly, the SOX certification may not be worth the paper it’s written on.
You are Invited to Participate in this Discussion
I’ll be blogging here from time to time on WebSphere MQ and messaging in general. Your thoughtful comments and feedback are essential and welcome. Please join me in raising awareness of the role that messaging plays in today’s information systems and the need to build good security into these networks. I look forward to hearing from you.
For more information on WebSphere MQ security, visit me at T-Rob.net, home of The Deep Queue WebSphere MQ Security podcast. You can download Basic WebSphere MQ Security presentation from the Links page there if you want to know how to secure the MQ network. Join me Friday July 10th for a webinar What You Don’t Know About Middleware Vulnerabilities Will Hurt You where I will talk in more detail about assessing WebSphere MQ networks.