SOA Security – Encryption

In this article I first look at the use cases for encryption in SOA and explore three scenarios: hop-by-hop, end-to-end and beyond messaging. I conclude that most folks just need hop-by-hop messaging, specifically SSL. I then look at issues relating to encrypting messages outside of the enterprise and conclude that most services probably don't need encryption but they'll use it anyway so to reduce harm they should at least use SSL enabled proxies in order to make the unencrypted messages available within the corporate network. I then look at using encryption within the enterprise and strongly caution most companies to avoid it if at all possible. The bottom line is that SSL is enough for almost everything, GPG cleans up the rest and XML Encryption and the WS-Security framework are almost certainly more trouble than they are worth.

Encryption Use Cases

The most common reason to use encryption is privacy. One wishes to prevent unauthorized entities from viewing one's messages. Right next to privacy comes tamper proofing which encryption also provides¹. However how private or tamper proof a message needs to be depends on one's security needs. Below I look at three different SOA security scopes:

Hop-by-Hop: The simplest scope of protection (and the one I argue most people really need) is hop-by-hop protection. That is, one wishes to protect the privacy and tamper proof a message while it is in transit from a sender directly to a receiver. This is also the simplest scenario to address. SSL provides an excellent encryption solution, is widely deployed, widely supported and well tested. I strongly suspect that for the vast majority of people SSL really is good enough.

End-to-End: A wider scope however than hop-by-hop is end-to-end. In an end-to-end system the same message may go through multiple intermediaries who do not necessarily all trust each other. I discuss this scenario and its security implications in some detail in the previously linked article and conclude that in general the expense and complexity of making this scenario work are rarely justified. This pretty much rules out XML encryption or WS-Security.

Beyond Messaging: It is quite possible that the content in a message may need to be kept private or tamper proof beyond the time that the message is actually in transit. One can imagine, for example, a service that stores medical reports used in an insurance case might actually send a multi-part message that contains routing and storage information along with an encrypted attachment that has the highly confidential medical testimony that validated the claim. In this case it is probably simplest to just encrypt the information that needs to be stored long term as a separate attachment using technology like GPG. GPG is open source, open standard and patent free.²

Encryption Outside The Company

Encryption is computationally very expensive. There's a reason why there is a market for hardware based SSL accelerators. There is also a reason why there are a bunch of new start ups around XML acceleration in general and XML encryption acceleration in particular. The end-to-end features provided by XML encryption make SSL look dirt cheap. Unlike SSL which can just blindly process every byte without too much regard to its value in XML encryption there are issues of canonicalization to be dealt with that mean the bytes being encrypted or decrypted actually have to be examined and potentially transformed. There there is the expensive and headaches involved in key management. Most encryption technologies use public key cryptography as their keying mechanism and running a PKI infrastructure is a pain. So don't imagine that just adding in SSL or WS-Security is going to be cheap or easy.

All of which argues that one should think twice before adding encryption, even for communication outside of one's company and/or across the open Internet. Eavesdropping on a network communication or intercepting the communication and changing its content isn't easy. It is certainly possible, especially for a determined opponent who can access an Internet hotel that handles traffic for either the source or destination or who understands DNS spoofing, IP spoofing, or IP splicing, but easy it isn't.

Still, according to the CSI/FBI 2005 Survey, Figure 16, the third most expensive security breach is theft of proprietary information. But, if a bad person is looking to steal information about a company then there are much easier ways of doing it than trying to intercept obscure machine-to-machine messages. More traditional techniques such as dumpster diving or social engineering are likely to produce higher quality data in a much shorter period of time. Another easy choice is just visiting your local airport email kiosk. or, as the recent Israeli corporate spying fiasco showed, Trojans work really well. I suspect money to be spent on encrypting service communications would probably be more effectively spent on user education, convenient but secure remote e-mail access technologies, good anti-virus software and bi-directional firewall software.

Of course the counter argument is 'well someone could still launch an IP spoofing or other attack'. Well, yes, someone could do anything. Someone could go to your admin and offer them $1,000,000 or put a gun to their head and get everything they need much faster than all this hacking nonsense.

And, of course, encryption itself is no panacea. Most companies, for example, just trust third party key issuers to validate encryption keys but we already know such issuers can make mistakes. So even if you do use encryption, depending on how valuable your content is and how determined the attacker is, you still may not be protected.

So what it all comes down to is – how likely is someone to launch an attack that encryption can protect against and how large is the damage such an attack could cause versus the cost of the hardware/software/infrastructure needed to effectively use encryption?

Of course the calculation most system administrators are making is "How quickly will I be fired on the rare chance something bad happens when I don't use SSL versus how hard will it be for me to justify buying SSL equipment to management?" Since most of the pointy haired set have at least heard of SSL and know 'security good' I suspect selling the need for SSL is pretty easy. I can't blame the admins, their behavior is rational given the average quality of senior management decision making after a security breach.

But to keep the damage from using SSL down it makes a lot of sense to buy SSL accelerator proxies who can handle the encryption on the edges and then forward the unencrypted messages internally. See the next section for why it's important to have access to unencrypted content within the corporate network.

Encryption Within The Company Network

Table 1 in the CSI/FBI 2005 survey shows that 50% or so of all security attacks are by insiders. Which should remind the reader of one of the more valuable security principles: "security in depth". That is, don't put up one barrier against the bad people, put up many and stagger them around.

But using encryption within a company network, especially hop-by-hop or end-to-end encryption, makes normal network management all but impossible. The same protections that keep out the bad folks equally keep out the good ones. Tools that gather business information, network health information, etc. will be crippled by the use of encryption. Attempts to trouble shoot and fix application problems will also be harmed.

Yes, these problems can be worked around. For example, one can put in "secure" back doors into existing applications to allow administrators and others to gain access to network stacks before and after the encryption layer. But such access only increases the probability of system failure, the more things a system does the more likely it is to fail especially since most network stacks tend to end up in places like the kernel for performance reasons. The matter gets especially sticky in debugging scenarios where an error may be compounded because of the introduction of the 'stack sniffer', an inherently extraneous factor. Besides, building up a big encrypted system only to put in a back door doesn't exactly defeat the purpose (since one can control access to the back door) but it certainly weakens it.

When considering encryption internally it's well worth looking at the actual risks one faces. For example, if the primary danger is from an insider one should ask 'what kind of insider'? If the most likely insider to do something bad is a(n):

• programmer then network encryption isn't going to help if that programmer can just change the code in the CVS server.
• administrator then network encryption isn't going to stop someone who already has back door access.
• lab technician then network encryption isn't going to stop someone with physical access to the machine.

I wish this all meant 'don't bother encrypting internal data'. That would certainly simplify things. But it would be wrong. Some companies face threats of sufficient severity and specificity that the protection internal network encryption provides (when used in the context of a whole list of other protections) more than justifies its enormous cost. But my guess is that those scenarios are exceedingly rare.

Conclusion

Of the three types of encryption approaches, hop-by-hop, end-to-end and beyond messaging I suspect the vast majority of systems will find the best expense/cost trade off is provided by hop-by-hop encryption using SSL followed by a distant second place to attachment encryption using GPG. Most companies probably don't need to encrypt their external communications but they probably will and so should just use SSL but should try to also use SSL enabled proxies in order to provide access to the unencrypted information within the network. Finally, very few companies can justify the expense and disruption of encryption within the corporate network and so should avoid it if at all possible.