More Thoughts on Middleware and Regulatory Compliance by T.Rob

By T.Rob

In yesterday’s post Is Your Sarbanes-Oxley Certification Sound? I proposed that it is not possible to be SOX compliant if anonymous users can manipulate messaging traffic in the enterprise. I couched that in terms of WebSphere MQ because that is the messaging software I am most familiar with. I framed the discussion in terms of Sarbanes-Oxley because it is more broadly applicable than PCI-DSS. But I don’t want the message to be interpreted as narrowly as that.

Compliance

Let’s talk about compliance issues first. Sarbanes-Oxley is concerned primarily with the integrity of the data. In order to insure data are true and accurate, internal controls are required to enforce access and accountability. The Payment Card Industry Data Security Standard (PCI-DSS) is concerned with both integrity and privacy. In addition to controlling who can execute transactions, PCI requires protection of the data from prying eyes. There are plenty of other legislative and industry regulations with which companies must comply around the world. The bare minimum requirement to comply with any of these is data and transaction integrity. The typical embodiments of this requirement include such things as Role-Based Access Control, application isolation, checks and balances in human and automated processes and separation of duties. If these controls are not present, there is no accountability, no assurance that transactions are driven by legitimate users and that they have not been altered. Privacy protection builds on these by adding encryption so that the data is not readable by unauthorized users. This is important when the data itself is as valuable as the ability to execute transactions. The message of yesterday’s post is not that SOX compliance needs to be reexamined. It is that compliance of any type requires internal controls, at a minimum, and frequently also encryption. While these are well understood and practiced at the customer-facing systems and the back-end databases and transaction systems, the transport of that data is often left unguarded.  If the middleware layer over-authorizes legitimate users or allows anonymous update access then it should jeopardize any type of regulatory compliance certification, whether that is SOX, PCI-DSS or anything else.

WebSphere MQ Security

The other ting I mentioned in yesterday’s post is WebSphere MQ. I write a lot about the security of WebSphere MQ and I’ve been told that people may be getting the wrong message. Let me clarify that here and now. Any software product can be deployed unsecurely. Furthermore, no matter how good it is today, the security features of any software product can be improved. If you disagree, then just wait a while. Mere passage of time will make today’s security configurations obsolete. Evolving threats force software vendors into an arms race. So when I write that WebSphere MQ implementations are not secure, the message is that they can be, and I’m here to show you how to do that. When I write about features I’d like to see added to the product, it reflects the evolving threats. If I worked frequently with other flavors of middleware, I’m sure I’d be writing the same things about those products as well. What’s important here is that the middleware needs to have the same level of security as the front-end and back-end systems. In year-to-date 2009, the Privacy Rights Clearinghouse reported close to a breach a day. Of those, about a third were breaches of the internal network, by my count. The threats evolve. Linda McGlasson of BankInfoSecurity.com reports that several classic scams are enjoying a revival. Of the six she lists, most target users both at work and at home and potentially expose the internal network. These represent techniques that attackers use to fool employees into letting them in through the firewall. For example, phishing can result in compromised workstations that give an attacker free access to the intranet. The sixth item in the list is direct insider threat - when employees intentionally breach the network. McGlasson says that “the ways that insiders are getting to the juicy data or dollars is changing”. Even with classic scams, the threat evolves.

So my message is simply this: the threats have evolved to the point that it is now time to secure the messaging transports that have historically been ignored. Both users and vendors will need to respond to these threats by applying the security that is available in their messaging products now, and by looking forward and anticipating what will be needed to meet the threats of tomorrow head-on.

User ID Authentication

The particular challenge of WebSphere MQ is that the prevailing security practices have been to base authorization on a user ID that is not authenticated.  This practice dates back to the earliest versions of WebSphere MQ and reflects a simpler time when the intranet and legitimate users on it were implicitly trusted.  Although these assumptions are no longer valid as the basis for an enterprise security policy (and arguably never were), this security configuration continues to be the norm. Unfortunately, this security configuration is widely perceived to be effective.  In fairness to administrators, it is after all the prevailing practice.  It has been documented in articles, project plans, operation run books, cheat sheets and countless other places for the last fifteen years.  But the existence of all that history becomes a barrier to improving the situation.  People are so convinced that they have done enough to secure their messaging network that they are reluctant to even consider that there might be gaps.  There are methods to strongly authenticate connections to the queue manager but these are seldom implemented.  When I write about the issues, I have to overcome a lot of inertia just to get people to stop and examine their configurations.

To address these issues, I’ve been approaching new audiences.  Yesterday’s post reached out to executives responsible for SOX compliance to let them know they are stakeholders in the security of their messaging network.  The webinars at PCIKnowledgebase.com reach out to auditors so that they can function as a safety net to identify gaps and provide incentives for remediation.  I will also do what I can to facilitate the creation of tools to assess and report on the security of WebSphere MQ.  Of course, I will continue to reach out to the core audience of users and administrators in articles and at conferences.

So what does all this activity in the security arena say about WebSphere MQ?  My take is that any messaging transport that does not have a passionate and active community constantly looking to improve security as it is practiced, implemented and built into the product is the one that users need to be wary about.  The extent to which the MQ community is engaged in this discussion is one of the best indicators of the continued vitality of the product.

Tags: audit, breach, Compliance, middleware, PCI-DSS, QSA, Security, sox, vulnerability, WebSphere

This entry was posted on Wednesday, June 10th, 2009 at 7:39 AM and is filed under Community Manager, Guest Bloggers, Information Technology, Networking, Security. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.