Service-Oriented-Architecture Security: What's Old is New

"SOAP" is a descendant of XML-RPC, and is another in the procession of web-layer security technologies we IT security professionals must grasp. SOAP provides many benefits to technology. Let's make it real: one of the chief functions it allows is a remote procedure call performed using eXtensible Markup Language (XML) over HTTP over port 80 over TCP/IP from a client to a server, with the answer coming back over the same connection.

We know and love (or hate) XML for its bloated but readable messaging format, where keys and values are used like pastels for HTML text -- the operations for a remote peer application to perform on the text are contained in the key-value pairs that are inside the tags around the text.
ie: "Make this text "Hello world' bold" in HTML = Hello world

RPC's we know and hate because multiple services are piggybacked onto dynamic Layer 3 transports that are connection-context-dependent. We can't tell a firewall at Layer 3 to allow MS Windows to talk only the Exhcange protocol but not offer allow other networking services from those devices. Consequently one wants to block it - because who wants to be vulnerable to a worm originating from a desktop into their Exchange cluster?

XML-RPC and SOAP are the answer to this. Designed to get around firewalls they use HTTP
and so the inference is they are OK to pass. Firewall admins who indiscriminately pass this traffic across security perimeters miss the point of their firewall's existence.

ie: Here is part of a SOAP call illustrating how open it is compared to binary protocols like CORBA/IIOP or DCOM/DCE-RPC.

<getStats xmlns="http://hockeystats.example.com/ws">
<goalieid>827635</goalieid>
</getstats>

There are inherent weaknesses in a perimeter where the enforcement device is unable determine what two peers are swaying to eachother when the speak across a security boundary. The intermediary device is unable to enforce the desired security policies within the protocol. So the peers have unencumbered reign over what information is exchanged between them, rendering the firewall useless. A firewall incapable of containing and managing risk is not meeting its security objective.

So why not just have the enforcement device learn the language and parse the traffic then? The issue is that the higher up the stack we go, the more compute time is required to decode the traffic, and also much more state information to track. This causes performance issues, solved by money and more hardware. The chief barrier is the lack of security policy definition to the precision these devices would need to understand.

Fortunately, many companies are unable to articulate enforcement of their security policies to that level of precision. This a recurring theme in IT security architecture even at layer 3 where I have some clients who years after a new firewall is implemented are unable to get their rules correct. So the security policies are enforced to a level that does not compromise performance of the network, but really that is simply a cover for the lack of precision with which an enterprise implements its security policy.

This has been a pretty simple battle in the past: productivity wins over security function. Perimeters have are brutalized to the point where their ability to reduce the exposure of vulnerable applications to threats has been gravely diminished. Enter IPS, which only kills the worst offending traffic known to be bad. However IPS does not enforce "least privilege", but only an incomplete policy: "Stop the known bad stuff we know about today." Enumerating badness is a trusty hammer. It works for screws too, but...

When serious management of security perimeters is required by the business, XML firewalls are a niche technology that solve this. As traditional firewalls are a TCP/UDP/IP layer big-brother to the application peer communications, XML firewalls perform a similar function to web services communications. XML firewalls are able to validate the XML calls between components in a distributed web services infrastructure. The security objective is to enforce security parameters which are missing or untrusted within the application itself.

This will get increasingly important as the shift back towards executing more on the client side within the browser using techniques like AJAX will make one peer much less trusted than the other. Sites leveraging those techniques will drive browsers to make XML calls directly to web application servers, rather than a simple HTTP request of a web server that causes a (the more trusted) web server to make those web-app calls themselves. It is inevitable as client-side issues with AJAX are already popping up.

More on the XML firewall technology capability in part two.