Lustratus LiteBytes

Archive for June, 2007

I was talking to my colleague, Dr. Ronan Bradley, the other day and I suddenly got worried about a potential SOA security hole.

As we all know, SOA systems tend to operate with XML data streams, for example when invoking web services. XML is a self-defining mechanism for data, with pointers and references to ensure the data format can be understood by anyone else. However, it is possible to cross-refer to different parts of the XML stream in such a way that the process becomes recursive. In other words, the parsing process to decode the XML information will loop.

My concern here is that this might offer an opportunity for a Denial of Service (DoS) attack. That is, a malicious party might deliberately send a message containing recursive XML, in the hope of causing the XML parser to loop, thereby blocking any other activity. I am not technically up-to-date enough on the various parsers available in the industry to know for sure, but if the parser does not have some sort of fail-safe then this form of attack would definitely seem to be possible.

The standard way to protect systems from outside attack in the case of the internet is to have a security ’sniffer’ at the boundary of the enterprise that watches incoming data and looks for threat signatures – that is, characteristics that occur in known threats and threat types. But the problem with the XML thing is that the only way to see if the XML is recursive is to parse it, thereby running in to the problem.

Perhaps this is old news, and the industry has already sorted the problem – but if it has, neither I nor my colleagues are aware of it. It is at least worth SOA adopters, and web services users for that matter, assuring themselves that they are protected from this potential SOA security exposure.

Steve

The Integration Consortium (IC), a not-for-profit consortium of all parties interested in any aspect of business integration, has scheduled its first European seminar for June 28th In Brussels.

Attendees will be able to hear real-life SOA experiences from companies such as Wells Fargo bank and Cap Gemini, as well as the award-winning paper from Lustratus, “SOA is Rubbish!”, to be published in the summer at the Lustratus store. Other sessions include feedback from the BPM Thinktank, and a panel on the relevance of open source in SOA.

The IC has been around for six years now, and has a track record of offering strongly user-oriented seminars and shows in North America, with its flagship global integration summit proving a particular hit with end user companies. This event marks the first in what the IC says will be a regular sequence of European-based seminars and summits, and this initial offering is being held in collaboration with the recently-formed SOA Consortium.

I look forward to this and subsequent IC events in Europe. It seems to me that nothing beats hearing about the challenges real users have faced concerning SOA.

Steve

I have been involved in some recent research into event-driven architecture (EDA) and its relationship to service-oriented architecture (SOA), as a result of confusion abounding over the two concepts.

Some people seem to think EDA = SOA 2.0. Others that they are already doing EDA in their SOA implementations because they are using asynchronous communications such as a JMS or IBM WebSphereMQ. This confusion is exacerbated by vendors with their own agendas – TIBCO has been banging the EDA drum for ages as the preferred way to go to solve integration problems, IBM has just held a massive event to drive its own SOA agenda, Oracle seem to be trying to straddle the two approaches, and complex event processing (CEP) vendors like Progress have their own stories about EDA.

My own analysis, together with Dr. Ronan Bradley, also of Lustratus, has concluded that as is so often the case, the problem comes down to confusion over terminology. EDA is an architecture, just like SOA. It is a way of running operations, and before anyone starts to ask whether I am on the side of SOA or EDA, the two can happily coexist. But the confusion arises when people start to use EDA as a term to refer to particular implementations rather than to the architecture itself.

In fact, we identified 3 major ways that EDA relates to SOA, and concluded that EDA may have a key role to play as SOA matures – to deal with the increasing management complexity of widescale SOA deployments through a ‘management by exception’ approach.

For those interested in reading the detailed research, Lustratus has published an Insight on the subject, available at the Lustratus site.

Steve