How SOA increases your application security risk

Service-oriented architectures mean greater reliance on others for development - with all the worries this involves

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, 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.

That’s one of the three main exposures Wagner sees with SOA, and organisations 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 which combines 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 minimise 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 organisation accepting XML-encoded files, which is the vast majority of organisations today, is exposed already.

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 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 organisation and purposely injected into its normal data traffic. Such targeted attacks are becoming increasingly common.

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 recognise 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 asking them to provide information in an interactive session. This 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 increase 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 utilise 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 minimise the danger.”

Join the newsletter!

Error: Please check your email address.

Tags Development IDsecuritySOA

Show Comments