Analyst: SOA may overwhelm current security measures

Three security vulnerabilities of SOA, and how they can be managed

SOA doesn't present new security risks. The problem is that SOA multiplies existing risks to the point where they may simply overwhelm an enterprise's security measures.

Three security vulnerabilities of SOA, and how they can be managed

There are three main security vulnerabilities that SOA presents to enterprises. Gartner's Ray Wagner, discussed these threats in a new report in ComputerWorld, and how they can be best managed.  

Exposure #1: SOA crosses the firewall to consume outside services. Reliance on Web-based third-party services has obvious obvious security implications. Security software then employs cryptographic operations such as hashes and digital signatures to verify. The problem is , Wagner says, is that "doing this hundreds of times an hour may have implications for computing loads." However, he observes, "but it really is just a change of degree" not a qualitative change.

Best solution: Technology helps, but the best approach may be to educate employees about the types of outside services they access, Wagner says.

Exposure #2: XML files. "XML basically can contain any kind of executable or data, including things designed to do damage," says Wagner. SOA will potentially increase the number of XML transfers, and therefore the exposure, by orders of magnitude. Pieces of malware may also fall into that flow, he warns.

Best solution: Employ third-party products that can intercept and process XML transactions. Wagner mentions Crossbeam Systems and Forum Systems, which have partnered to provide a firewall-based solution. I might add that SOA-based appliances, such as those offered through Datapower (now a part of IBM), also may be effective in intercepting miscreant XML messages without taxing the main servers.

Exposure #3: SOA may be too complex for identity management:  In a simple transaction, the user authenticates at the beginning of the session, and that authentication carries through the session, Wagner says. However, in SOA, the user may initiate a transaction and disconnect from the server, while the transaction flows through a group of back-end services. "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.

Best solution: Wagner says that "the most promising approach" to address this disconnect is to employ Security Assertion Markup Language "to create a representative identity that can be attached to the transaction."