My vote is MQ Series and other enterprise messaging systems. Schneier's succinct summary of BGP:
It's a man-in-the-middle attack. "The Internet's Biggest Security Hole" has been that interior relays have always been trusted even though they are not trustworthy.
That could apply word for word to how MQ Series and other enterprise messaging systems are deployed. Let's say you are a bank and have been happily running your business on a mainframe for decades. Life is good, come in at 9 leave at 5, count the cash. Then some dotcommer comes along and tells you that you need to get online. What are you gonna do? Rewrite your whole system from scratch? Hard to make that case.
Nope what you'll do is build out a web farm to talk to the consumer, but then you will realize all of your business runs on the mainframe, and you need to connect to it. How exactly? Enter MQ Series and friends, they broker the communications to legacy backends for most major corporations, but there is one slight problem - they didn't even bother to support useful security protocols until very recently, and most of the time the security protocols are not even implemented.
Typical anti-patterns include:
* no authentication, no authorization (just open up a queue) - run your whole book of business transaction backbone on anonymous ftp
* authorization with no authentication (mq enforces authorization policy on unverifiable tokens) - run your whole book of business transaction backbone on anonymous ftp, but think that you have security
What is strange about the MQ Series, enterprise messaging vulns is that there is no need for them, there are no technical excuses to not add better tokens, message security, and encryption. People don't do it, because of poor tool support, a mainframe mindset, silo projects, and a whole variety of reasons. But just because you choose to ignore a fact doesn't mean its not true. On the plus side, some of the open source ESBs are adding support for message security, so you can improve security and save your company money at the same time, what's not to like?
I think that in most J2EE environments databases pose an even greater problem. They are typically secured via username/password, however, this username and password is often available to the application server in clear text. What makes access to the database worse than MQ is that there is a standard way to query and modify the data.
Posted by: Dave Tauzell | September 05, 2008 at 09:59 AM
Hi Dave,
there are a lot of holes, the difference as I see it is - databases run applications and departments.
Mainframes run businesses.
Posted by: Gunnar | September 05, 2008 at 11:36 AM
I think you hit the bulls-eye with this post.
Your post is reminiscent of the fatal flaw within the PCI-DSS standard, in that it is acceptable to transmit credit card data inside of a corporate network in plaintext - the only transport security requirement involves credit card data being transmitted into the cloud. Crazy.
I would also like to say that IBM is not to blame - the problem is with the implementation - you can run MQ with strong transport security, auth and access control. http://www.ibm.com/developerworks/websphere/techjournal/0806_mismes/0806_mismes.html
Posted by: Jim Manico | September 07, 2008 at 01:46 PM
Hard crusty outside, soft chewy center :)
Posted by: Marinus van Aswegen | September 08, 2008 at 08:52 AM
The biggest issue i believe was the middleware authorization and authentication. Within MQ whatever you implement access control to Mainframe(actually this is not mean direct conection , you need some client like entireX) the user that authenticate over backend system is always the same. At that point JAVA2 security become more preventive..
Posted by: Paz | September 08, 2008 at 12:35 PM