Pitfalls aplenty going SOA |
 |
By Michael S. Mimoso
05 Feb 2007 | Information Security magazine |
|
|
The sophisticated business-to-business interactions occurring at a service level with service-oriented architectures pose a major challenge to security.
You don't go SOA to be more secure; you go SOA for the sake of efficiency and integration, standardization and code reuse. The returns are tantalizing, but like any other development scenario where a rush-to-market supersedes security, the results could be disastrous, experts say.
"There are definitely some positives, but there are some gotchas too," said Diana Kelley, vice president and service director with Burton Group.
|
|
|
|
|
"SOA makes you focus on security in a different way because every service you create could be used in a variety of ways by a variety of clients."
Kevin Schmidt,
Sun Microsystem's director of product management for SOA and business integration
|
|
|
|
|
|
|
|
|
|
SOA is a relatively new buzzword describing an old concept. XML-based Web services breathed new life into this type of architecture earlier this decade, and early adopters--financial services in particular--have gravitated to this design principle. Most early implementations were contained within the firewall and boundaries of the network perimeter, so security shortcuts were excused. But with insider threats and the exposure of more services to business partners and customers, security is no longer optional. Vendors are reacting by adding capabilities to their offerings--identity management in particular--and positioning them as Web services or SOA security products.
Sun Microsystems, for example has open-sourced most of its Access Manager code, including single sign-on, authentication, federation and policy features to help developers build in security from the outset of a project. Platform vendors like IBM sell customers on SOA security at the management level via Tivoli Identity Manager, Tivoli Access Manager for e-business and Tivoli Federated Identity Manager.
"SOA makes you focus on security in a different way because every service you create could be used in a variety of ways by a variety of clients. You need to think about securing [services] from the point of who can access it and what functions they can perform," said Kevin Schmidt, Sun's director of product management for SOA and business integration.
Open, standard languages and interfaces like XML, WSDL and SOAP, and directories like UDDI enable interactions between Web services, but security isn't native in any of them, forcing enterprises choosing SOA to secure not only the transport layer, but the complex message layer. Once some kind of authentication and authorization is accounted for in an SOA, security managers must ensure that interactions between systems remain private. One option is to encrypt SOAP messages or the transport layer via SSL VPN. Denial of service is also a potential pitfall with services extended to partners and customers. Another is the integrity of the endpoints accessing exposed services.
"When you SOA-enable an application, you expose a Web service from the data layer, pieces of business logic, and you expose an interface layer. All of a sudden there are lots of new access points to that app you have to secure," said Ian Goldsmith, vice president of product marketing with SOA Software. "That's the big issue for Web services. Standards are great and make it easy to integrate, but they're bad because they make it easy to access services. You have to figure out how to best secure those new access points you've created."
Since most Web services developed for an SOA are exchanged in XML, there are threats there to consider too, including an inadvertent denial of service caused by shoddy coding or the transmission of oversized messages, the manipulation of an XML schema or the injection of malicious code. Most attacks on XML are theoretical, experts say, yet a healthy XML firewall market exists. Vendors such as Forum Systems, Layer 7 Technologies, Vordel, IBM and others have positioned themselves as network perimeter tools that ensure authentication requests. They can also inspect XML content and prevent the transmission of malicious or sensitive content, something traditional firewalls cannot do.
"In a distributed environment, you still need to authenticate users and deploy access controls," said Jahan Moreh, chief security architect with Sigaba. "Now, you have to do it with more insight toward XML and Web services and such."
<< Return to our special coverage of RSA Conference 2007
|
|
|
|
