LiteBytes from Lustratus Research

Secure mainframe SOA-in-a-box

I was reading the announcement from Layer7 about its 'SOA-in-a-box' for IBM mainframe users, and a number of things struck me. First, I am SO PLEASED to see someone remembering that CICS is not the only mainframe transaction processing environment in use today. A significant number of large enterprises, particularly in the finance industry, use IBM's IMS transaction processing system instead. With the strength and penetration of CICS in mainframe enterprises, it sometimes seems like these users have become the forgotten tribe, but investments in IMS are still huge in anyone's numbers and it is a smart move to cater to them. I am sure that the fact that this solution serves IMS as well as CICS users will be a big plus.

The other point that struck me was that I have felt for some time that, with the security/intrusion detection/firewall/identity management market seeing such a shift to security appliances, it was time vendors thought of piggy-backing functionality onto these platforms. Of course, one reason for having an appliance is to provide a dedicated environment to address issues such as security, but in truth these appliances are rarely used to anywhere near capacity. Therefore it makes a lot of sense to optimize the use of the available processing power rather than slavishly locking it away where it can;t help anyone.

Finally, I have to admit my first reaction to this announcement was to worry about how good connectivity would be to the mainframe. Dealing with mainframes is an arcane area, and I was not aware that Layer7 had any special expertise or credentials here, but I see that GT Software is apparently providing the mainframe integration piece. This makes me a lot happier, since this company has been dealing with mainframes for 20 years. In fact, Lustratus did a review recently on GT Software's Ivory mainframe SOA tool, which is apparently what is included in the Layer7 box.

Anyway, on behalf of all those IMS users out there, thanks Layer7!

Steve

Can SOA be bad for your health?

Recently I featured in a podcast and wrote an article on the 5 SOA Security traps, and one particularly sticks in my mind. The issue is about flexibility - a good thing, most people agree, but in security / governance terms it can be a two-edged sword, and so it proves to be in the case of SOA.

The problem comes down to security domains. IT implementations can be thought of as a group of structures with varying levels of security - all the way from a community village where anyone can wander in anywhere, up to castles with moats, drawbridges and even boiling oil! Imagine for example a company with a particular silo application which is highly sensitive and must be absolutely secure. This could be implemented on a high-availability cluster with hardware encryption, and even have physical access controlled by putting it in a room with locks on the door and a guard! Well, OK, this might a little over the top, but the point is the company can take whatever measures it sees fit to implement a high level security domain - think castle.

Now along comes SOA, with its philosophy of flexibility and shared, reusable services. Instead of running silos, applications become a linked set of services and logic, and the wonderful flexibility of SOA means these services could be running anywhere across the enterprise, on any platform and in any technology environment. So supposing there is a shared 'create customer' service, and the high-security application switches to using this service instead of its own redundant create customer code. Now, since the security is only as good as the weakest link, the security domain is broken. Someone just drilled a hole in the castle wall.

Of course, companies can take measures to ensure this disaster does not befall their critical apps. Procedures can be put in place to protect the integrity of the security domains, restricting changes to these applications and blocking them from SOA-based distribution. But many people are unaware of the exposure, and sometimes programmers, with the best intentions, might accidentally end up compromising operations. In the end, it is up to management to put in place any education programs, working practices and policies and then to enforce them. But at least forewarned is forearmed.

Steve