Shielding Web services from attack

Web services are almost irresistible. Every popular IDE makes them easy to build — to unlock the data and business logic in legacy systems, to provision common functions that can be shared across multiple platforms, or to provide partner organizations direct access to information or applications. And by their nature, Web services helpfully describe themselves, allowing one system to find and interact with another with little or no human intervention.

Free IT resource Hear how top CIOs turn change into a competitive advantage. Sponsored by HP Free IT resource Attend the SOA Executive Forum: Breaking SOA Bottlenecks SOAExecForum.com/may2007 Sponsored by InfoWorld

Yet the very virtues that make Web services compelling — their use of trusted ports and protocols, their ease in exposing back-end systems, their eagerness to describe exactly what services are offered and how to get at them, and their use of multiple intermediaries — also make them a potential windfall for criminals crossing an enterprise’s perimeter (see also "Web services security standards aren't enough").

“You’re taking all of these systems that you would never put on the Internet — you would never hook your mainframe up to a DSL line — but now you’re exposing all their functionality through a Web service, and if you’re not thinking about security when you do that, you’re also exposing all those vulnerabilities,” says Alex Stamos, principal partner at iSec Partners, a security consulting company.

Few organizations have fully grasped the situation, in part because Web services technology is still relatively new. Even enterprises that are implementing an SOA (service-oriented architecture) — which provides a framework for building, running, and managing services — seldom recognize the new security risks. Ultimately, the recognition that we need to tackle Web services’ vulnerabilities is part of a growing awareness that security must be addressed in the code of applications, not just through firewalls and gateways.

Click for larger view.

The limits of trust

Topping the long list of excuses for not locking down Web services is the mistaken belief that the applications they expose are known only to internal personnel or trusted partners, rather than the world at large.

For instance, a Web app developer at a bank that provides online credit card processing may assume the SOAP interface he just implemented is invisible to all but the handful of customers who received his instructions on how the new service works.

“That’s not true,” says iSec’s Stamos, who has come up with a simple white-hat hacking tool he says is remarkably good at identifying the Web services that lurk behind IP addresses and figuring out how to use them without authorization. “In fact, they all have these systems built in to Web services to advertise their presence, and people don’t understand how pervasive those systems are,” he says. Stamos estimates that as many as 400 of the Fortune 500 companies have at least one b-to-b Web service. “Almost none of them are going to be completely secure,” he warns.

Another common reason for vulnerabilities is the belief that security is the other guy’s responsibility, says Paul Henry, vice president of technology evangelism at Secure Computing, which provides gateway devices to help secure Web services. “Unfortunately, you’ll have a team that’s working on the front-end software, and a separate team on the back end,” he explains. “Both assume the other has taken care of security.” What’s more, enterprises tend to design Web service applications from scratch rather than buying them from vendors that have put them through rigorous testing.