Web services: Security nightmare?

The hype surrounding Web services has reached crescendo proportions. That's not surprising given how eager some big information-technology companies are to find some sort of recurring, high-margin business in a down tech economy.

But in their rush, an important data security issue is being ignored: Confidential information is vulnerable to malicious employees or hackers because customer data, which gets stored in applications or databases operated by the Web services provider, still exist in clear or unencrypted form.

Is the threat farfetched? Not at all.

At AOL, an employee offered to trade internal customer information to a hacker for a $700 Barney's pearl necklace. Elsewhere, a Robin Hood hacker hacked into an internal New York Times Web service and came away with a bounty that included home phone numbers of 3,000 op-ed contributors, including former President Jimmy Carter, Internet legend Vint Cerf and actor Warren Beatty.

Although these were relatively benign intrusions, imagine data from your enterprise CRM Web service being made available to your competitor for the right price. What happens then?

Any enterprise Web service--from customer-relationship management to human resources--uses data residing in applications or external databases operated by the service provider. In other words, a mother lode of information is visible to insiders. But unlike a hack attack, there is no data trail to follow. You won't ever notice the theft, but your business will sure feel it. It would be as if the competitor could watch and counter your every move by having access to your Web service data trail.

In our security-conscious era, Web services have surprisingly escaped scrutiny. That's a strange lapse given how these services are supposed to form the underpinning of our information infrastructure. The headlong rush for Web services needs to be tempered with sane business realities and priorities--namely, securing customer information first and leveling with the customer, instead of treating them as beta testers for insecure technology.

In our security-conscious era, Web services have surprisingly escaped scrutiny. That's a strange lapse given how these services are supposed to form the underpinning of our information infrastructure.

Most Web service providers deploy several methods to convince customers about the security of their information. These run the gamut, including multiple firewalls, intrusion detection, application and system portioning, encryption, biometrics tools, and even armed guards. In the end, however, they are all but useless since, according to the Internet Security Task Force, about 70 percent of business computer-security breaches are internal.

Clearly, the proffered benefits of Web services are immense. But that vision cannot be realized if sensitive corporate and subscriber information can be made available to third parties for the right price. This ticking security time bomb needs to be defused, because a single, publicized theft of corporate data would irreparably harm this nascent industry. Recall how the concern about security contributed to the decline in popularity of application service providers.

How do we solve this critical problem without affecting the underlying, existing Web service architecture? Fortunately, draft protocols submitted to standards body the World Wide Web Consortium--such as XML encryption and key management and signature--are flexible enough for work to get started in addressing this issue.

This new security architecture will involve some retooling of the data-field components of an application. Hence, only the encrypted value of a critical field component, such as the dollar amount of a sale or a salary contained in an HR application, would get stored in the service provider database. Such values would get decrypted on the client application for final presentation through the use of a series of "keys" on the client device.

The client device typically would either hold these keys internally or download them from an internal key server or trusted third party as part of the sign-on process. Some of the lightweight processing would then occur using the client's DOM/XML capability. Only these sorts of mechanisms can provide the confidentiality and security of proprietary data sought by customers.

Revolutionary cooperation
The W3C, led by the venerable Tim Berners-Lee, deserves commendation for its continued foresight and diligent work in the standards body--even more so in light of the haranguing of some W3C members for not moving quickly enough. Certain companies have offered the customary lip service about "open protocols," but they are more concerned about making a land grab than about securing customer data.

This ticking security time bomb needs to be defused, because a single, publicized theft of corporate data would irreparably harm this nascent industry.

The last few years have witnessed unseen levels of industry cooperation leading to the development of the SOAP, UDDI and WSDL protocols for Web services. Even if the original intent behind developing these protocols might have been to neutralize Java's mobile code advantage, they have nevertheless been accepted by the entire industry as fundamental building blocks. This new cooperation and camaraderie is the real revolution fostered by Web services.

But the security of Web services will depend on such continued cooperation. What's more, these services must remain interoperable without chaining customers to a single company's "innovation" on the standard protocol. As old habits are hard to break, this is easier said than done.

So it behooves chief information officers to speak out. They need to approach this issue now, rather than after a security mishap makes them sorry. Before signing on with a particular provider or technology, they must demand the proper security architectures and interoperability. Otherwise, I'll be damned before putting my CRM data on a Web service.

Would you?