Truth in SOA

I was recently on a business trip last week and somehow I picked up a copy of "USA Today." This newspaper tends to find me rather than the other way around. Normally I try to avoid it, but am always drawn to it even if its just to see what the average American is supposed to care about.

I was looking through the business section and I was shocked to see a story on the front page on SQL Injection attacks!

I was surprised for a number of reasons. First off, SQL injection, or the attempt to insert SQL queries to return database information or spoof a login, is a very specific type of attack, but the USA Today story makes it seem like the average user should be "worried" about this type of attack, which is a little funny. It also claims that SQL injection turns your computer into a bot I think that attacks like cross-site request forgery or cross-site scripting have a much higher impact on the average Joe. XSS and CSRF can affect casual browsing if a user simply browses the wrong section of a website (such as the 'forums') where someone has managed to inject a <script&rt; tag.

Upon careful dissection, this article seems instead to be a sort of advertising placement for IBM:

"For the first five months of 2008 IBM ISS helped large corporations block about 5,000 SQL attacks a day. By mid-June, daily attacks spiked to 25,000;"

This is a bit ironic compared to the news that came out earlier in the year regarding the DoS attack against IBM DataPower or the problems the device has with persistent connections. I sure hope IBM ISS isn't recommending the DataPower device as an application firewall to protect against SQL injection!

As for content threats themselves, this is a very interesting area that I am sure will experience more growth in both the types of threats devised as well as the protection mechanisms. What is needed is a high-performance content processor that can at a minimum scan for different types of attacks within the application payload but also must be extensible as attacks are always changing and evolving.

What worries me the most here are cases of an attack that rely on an application firewall to keep state between HTTP requests. That is, rather than the attack being defined as a single SQL injection, or script injection it may be defined across a set of messages. In other words, the attack can't be detected by looking at a single message, but by a pattern of messages.

A hot issue in the context of SOA is how does one effectively mediate between services that may reside in different domains across an organization, and further, how does one accomplish data sharing amongst services without breaking the bank.

Traditionally, organizations have deployed hardware appliances to solve this problem, but Intel has a new solution called SOA Expressway, which is essentially an optimized software runtime that accomplishes the same mediation as a hardware appliance but with higher performance that is more closely aligned with cost-reduction trends in the datacenter such as virtualization and liquid computing.

Recently I gave a joint webinar with Burton on the software service mediation solution. Most surprising is how much faster the software is compared to a purpose-built XML appliance. In fact, the testing shows that for real-world (non-synthetic tests) scenarios, software on Intel(R) Multi-Core is at least 2 and at most 8 times faster than the ASIC for XML processing - quite suprising, oh and its cheaper too.

Sys-Con has just put up a link to Joshua Painter's presentation on Enterprise SOA and governance that was given at SOA World 2008.

The video is interesting in that it highlights Intel's SOA Expressway product in terms of the Enterprise Service Router concept, which tries to consolidate islands of integration with scalable software rather than a plethora of non-interoperable ESBs and custom built hardware appliances. The software scales on Intel Multi-Core such as the new i7 platform and uses standard servers rather than custom chips for XML message acceleration.

A friend of mine forwarded me this DoS attack against the IBM DataPower XS40 SOA Security Appliance using only the standard OpenSSL command line client. Apparently you can cause the box to reboot by sending a random string over an SSL-enabled socket connection.

I got in touch with a friend with access to an IBM DataPower XI50 and they were unable to reproduce the issue on the integration device, but that doesn't mean similar issues like this one aren't going to crop up, especially in a closed-off hardended device like this. I also wonder if this attack was an accident or if it was the result of a concentrated security analysis on the device itself.

I think this is where it makes sense to reexamine closed-off products in light of well known design principles like security through obscurity and ask if it makes sense to protect enterprise and SaaS applications with this type of device as contrasted with a software solution that runs on an open-source with a known risk profile.

It looks like a new binding for SAML v2.0 is soon to be ratified, the HTTP POST "SimpleSign" Binding . The "SimpleSign" binding was originally crafted by Jeff Hodges and Scott Cantor relaxes the XML Signature requirements on the SAML Protocol, making it easier for scripting environments to send signed SAML requests and verify signed SAML responses. The main problem with XML Signature is performance - very few people know that the cryptography involved in XML Signature is often dwarfed many times over by the extensive XML processing requirements including parsing, transformation and XML canonicalization (e.g. c14n).

The situation only gets worse as the size of the XML document increases or the number of references to be signed increases. This profile takes a less sophisticated approach and interprets the XML content of the SAML request or response as an octet stream and then represents the signature as a base-64 encoded blob. While I think that this type of profile will do wonders to help scripting environments support signed SAML requests, this specification does not replace the signature on the actual SAML assertion - it just applies to the and messages.

This means that for persistent message level security on SAML assertions, XML Signature is still required. Other solutions to this problem are to decouple the XML signature processing from the scripting environment and moves it to the network with a SOA software appliance. This approach uses the original XML Signature as specified in the original spec (you will likely have to use it anyway if you want signed SAML assertions) and avoids having to implement and test a new profile.

I was at SOAWorld 2008 yesterday and had the pleasure of hearing David Linthicum's keynote presentation entitled "SOA by the Numbers".

One of the powerful messages he made was that the era of "management by magazine" is over and the fact that there are less SOA projects starting implies not that SOA adoption is waning, but that more projects are in-flight. This will inevitably lead to a scaling problem as SOA scales from micro-domains (also called the "little-bus") to macro-domains (also called the "big-bus") where the benefits of SOA are amplified for the business. Currently, other than Intel and and few other players, most vendors have been focused on the micro-domain with the proliferation of ESBs.

While I agreed for the most part with David's point about having a true services strategy and the right people for the job, these are truisms - the fact remains that SOA is steeped in technology right now. The line-of-business doesn't care so much about implementing SOA for its own sake, they are thinking in business terms where SOA is of instrumental or utilitarian value - a means to compete and not an end in itself; I think this is part of the adoption challenge as SOA is driven internally at the micro-domain level by software architects and engineers.

SOA promises to bring increased agility to business, but it seems that there is a philosophical conflict between purpose-built hardware appliances and the design principles around SOA. Typically, hardware appliances have been used as XML Firewalls or Web Services Security gateways to provide trust enablement, authentication, perimeter defense, and XML acceleration functions to a partner B2B scenario. The problem here is that providing this in a "mysterious black box" seems odd to me.

In particular, we can break down the concept of SOA Agility into four components: Network Performance Agility, Business Processing Agility, Development Agility, and Security Agility.

Network performance agility is the ability of the network infrastructure to closely match the necessary architecture for the deployed services. Business processing agility is the capability of the services to match the business mediation or required business processes. Development agility is the capability of the SOA infrastructure to support a distributed development team across geographic boundaries (typical of modern enterprises), and finally, security agility is the capability of the infrastructure to support changing security standards, evolving threats, and an "open" process for security analysis.

It seems that purpose built appliances from companies like Vordel or IBM DataPower represent an opposing force for each one of these SOA Agility areas. We can summarize SOA Agility, its aspects, and how hardware appliances seem opposed to SOA Agility in the following table:

Requirement	Hardware Appliance	Explanation
Network Performance Agility	X	Fixed NIC ports - supporting larger networks means buying more proprietary appliances. High Data center Costs - High TPS/Watt Usage over general purpose servers. Low Reusability Potential - Old appliances must be discarded or returned to the vendor, unlike general purpose servers which can be reused. Lack of Virtualization - Appliances have no capability to take part in data center efficiencies achieved through virtualization.
Business Processing Agility	X	Non-extensible - Impossible to add custom business processing on the appliance without a new feature request or vendor upgrade (possible hardware upgrade). Lagging Standards Support - Keeping up with all of the latest standards requires a full-cycle hardware upgrade
Development Agility	X	High Development Costs - Distributed development teams require additional high cost (generally $50K - $60K) appliances just for application development. The cost of the appliance approximates the cost for the developer! Serialized Development - Due to their high cost, development teams must often share a small number of appliances, cutting down efficiencies for business agility
Security Agility	X	Guaranteed Standards Lag - Latest security standards on hardware must wait for a full-cycle upgrade. Guaranteed O/S Security Lag - New security vulnerabilities in the underlying O/S actually running the appliance mean the customer must rely on the vendor for a patch. Inflexible Security Model - Additional monitoring, security and maangement software can't be added to the hardware appliance due to its "closed" nature. Security by Obscurity - Because appliances are proprietary black boxes its often not clear how security policies such as key management or user accounts are really handled. Did the vendor put in a back-door for management or support purposes? Who knows?

Rather than a hardware appliance, why not just achieve the same thing with specially optimized software that supports SOA agility?