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