How SOA Increases Your Security Risk

Service-oriented architecture changes the security equation by introducing a greater reliance on third parties for application development and operation. But according to Ray Wagner, managing vice president of information security and privacy at Gartner Inc., this is a matter of degree rather than an introduction of a totally new security exposure.

For instance, an SOA application may depend on a Web-based third-party service to provide vital functionality, with obvious security implications. But thousands of users already do this when they activate Microsoft's automatic updates.

"Ultimately, it's a matter of trust," he says.

"You decide whether you trust Microsoft to send you good code. Then the computer checks that it has received what Microsoft sent, using cryptographic operations like hashes and digital signatures."

SOA may increase the number of these exchanges hugely.

"Doing this hundreds of times an hour may have implications for computing loads, but it really is just a change of degree," not a qualitative change, Wagner says.

He acknowledges that normally trustworthy partners may occasionally accidentally send bad code or a bad identity assertion. But, Wagner says, overall, "it is much more likely that someone will decide to trust the wrong site because it promises to provide the functionality he needs."

Already malware commonly masquerades as useful code and sometimes does provide the function it promises while doing other, less desirable things in secret.

Technology and education

That's one of the three main exposures Wagner sees with SOA, and organizations are already experiencing problems when employees access the wrong sites from their work desktops and accidentally import malware into the enterprise. Combating malware -- whether it is associated with SOA or someone downloading "free" music from a file-sharing site -- requires a strategy combining technology with education.

The security technology needs to be able to stop malware before it can infect the network. But the best solution is to educate users about the dangers of unknown sites to minimize the exposure in the first place.

The second major exposure is more technical and harder to intercept.

"XML basically can contain any kind of executable or data, including things designed to do damage," Wagner warns.

Again, every organization accepting XML-encoded files, which is the vast majority of organizations today, is exposed already.

Page Break

But SOA promises to increase the number of XML transfers -- and, therefore, the exposure -- by orders of magnitude, while the huge volume of these transmissions in the SOA architecture also complicates the problem of intercepting the occasional piece of malware in that flow, even as it attracts increasing attention from criminals.

And the increasing technical sophistication of malware clearly demonstrates that those crooks are able to pervert the technology to their uses.

Education is much less effective in dealing with this exposure, because it is more likely to be injected into an otherwise legitimate packet flow entering the enterprise and may further disguise itself by entering in several separate packets mixed into legitimate traffic.

The user may not have done anything wrong, and the infection may be a targeted attack tailored to that organization and purposely injected into its normal data traffic. Such targeted attacks are becoming increasingly common.

Addressing the problem

However, products are already appearing to address this problem. Crossbeam Systems, a unified threat management (UTM) vendor focused on SOA security, and Forum Systems have created an alliance to combine Crossbeam's X-Series security services switches, a high-performance, high-reliability UTM solution, with Forum's XWall Web services firewall and the Forum Sentry Web services gateway for a best-of-breed solution for intercepting malware in XML and other transmissions entering the enterprise.

A third concern, Wagner says, is that the session model for identity management does not fit the more complex needs of SOA. In a simple transaction, the user authenticates at the beginning of the session, and that authentication carries through the session.

However, in an SOA model, the user may initiate a transaction and disconnect from the server, while the transaction flows through a group of back-end services, so the user has no direct connection to the final transaction.

"I need to recognize not only who initiated the transaction, but also who [or what, in the case of an automatic process] approved it and handled it," Wagner says.

"I need to authenticate all of these individuals and/or processes" using information carried with the transaction, he says, rather than by asking them to provide information in an interactive session. That is a problem that is not fully solved at present.

"The most promising approach to this solution uses [Security Assertion Markup Language] to create a representative identity that can be attached to the transaction," he says.

Again, Wagner says, the issue is already present, but SOA architectures using components accessed from the Internet increases the degree of exposure.

"The worry is that people won't wait for the solution, or won't make the attempt to get it right or will get it right for a trusted internal service that later is released externally, increasing the security exposure, and that vulnerabilities will result," Wagner says.

"Because SOA is both very powerful and designed to utilize outside code and other outside trust relationships easily, the vulnerabilities could be very large. Enterprises need to be conscious of this potential and develop security policies, combined with user training and technology, to minimize the danger."