Problem solve Get help with specific problems with your technologies, process and projects.

Watch out for overkill on Web services security

Robert Scheier issues a warning about Web services security solutions.

To quote Intel co-founder Andy Grove, "Only the paranoid survive." Being a little, or a lot, paranoid when it comes to Web services is just fine. Since Web services represent a whole new way of linking applications, I've argued myself that they require a whole new approach to security.

But let's get real. Few customers are actually deploying Web services, much less building complicated security fortresses to protect them. Whenever there's great fear (over security threats), great hope (about the potential for Web services) and great uncertainty (hey, what are Web services, anyhow?), you'll find vendors, analysts and yes, commentators like myself, cranking out new acronyms, buzzwords and new categories of software to help clear everything up.

Some of the new standards, software and security mechanisms being touted to safeguard Web services will become trusted, even vital parts of your security infrastructure. But, just as many others will wind up gathering dust on shelves or shortening the careers of CIOs and CSOs (chief security officers), because they were too clumsy, unwieldy or proprietary or just plain didn't work.

How do you tell the wheat from the chaff? By carefully looking under the hood of any vendor's Web services security "frameworks" or architectures, by only buying as much Web services security as your applications warrant and by looking for the low-hanging fruit where a little bit of security spending can deliver a clear and overwhelming hard-dollar return.

Web what?

Web services refer to the use of well-defined standards such as XML (Extensible Markup Language) and SOAP (Simple Object Access Protocol) to make application services (such as database access and security) more easily available to users over the World Wide Web. Backers claim Web services will be easier and less expensive to implement and maintain than the vendor-specific middleware traditionally used to connect individual applications to each other.

But, Web services are fundamentally different than earlier middleware in that security-related information (such as encryption, authentication and authorization credentials) must follow messages through corporate and public networks, rather than just residing within each application or server. It will be at least a year before true standards emerge to support this new security model. In the meantime, many customers are relying on current network-security protocols such as Secure Sockets Layer to protect the Web services they've deployed or are deploying Web services only behind the corporate firewall.

Acronyms aweigh!

Enter the buzzwords. Giga Information Group came up with Enterprise Application Security Integration (EASI) to refer to an architecture that can perform authentication, authorization, accountability and administrative chores across any Web services platform. Quadrasis, a division of Hitachi Computer Products Software Solutions Division has announced its EASI Security Unifier, which consists of "adapters, mappers and tools for connecting to a variety of applications and security products, and a framework that links together multiple security technologies." Base price: $100,000. AmberPoint Inc., an Oakland, Calif., company founded by former executives at Sun Microsystems and Forte Software Inc., offers its AmberPoint Management Foundation, an agent-based system for monitoring, managing and securing a Web services environment. Price of entry: $50,000.

A host of other vendors, ranging from Microsoft to IBM to VeriSign and RSA, are developing their Web services tools around the Security Assertions Markup Language (SAML). SAML is an emerging XML-based standard designed to allow systems using different sign-on and authentication mechanisms to communicate with each other.

Pardon me for asking, but isn't this all a little pricey and complicated for an application-integration technology that was supposed to make things easier? Some customers will undoubtedly need such high-powered security tools to protect their most critical data and widely used applications. But here are some things to consider first:

  • Beware of "marketechtures." By this, I mean an "architecture" or "framework" that is just a loose patchwork of a vendor's existing management or security tools – with you doing a lot of the knitting to hook these tools together. If the vendor promises "connectors" to existing authorization or access-control systems, ask which connectors already exist and which the vendor (or, even worse, you) will have to code. If the vendor claims the pieces of their "framework" fit together seamlessly, have your systems administrators work with the user interface to see if their "solution" looks like one tool or 20 once you start to use it.

  • Don't overbuy. Yes, a hacker could theoretically tap into any transaction at any stage from your supplier to your distributor to your end customer, but how likely is that to happen and how much might you lose if the hacker did get through? Especially in the wake of Sept. 11, it's easy to look at a diagram of a Web services architecture and see nothing but security holes. Nix the paranoia, use some common sense, and follow the lead of several customers to whom I've recently spoken: Deploy Web services outside the firewall using current security technology (such as SSL) if the business benefit is clear and the risk is manageable. Wait for the full emergence of Web services security standards before going to more widespread deployment.

  • Look for the "low-hanging fruit" that will at least pay for the foundation of your eventual Web services infrastructure. Single sign-on software, for example, allows users anywhere in an organization to log on once and get access to multiple applications. It's a common first step to a full Web services security system, but can pay for itself quickly if it allows users to reset their passwords themselves rather than making expensive calls to the help desk.

    Yes, only the paranoid survive. But don't go nuts securing "Web services" before you've fully deployed and understood them -- and their business benefits.

    About the author
    Robert L. Scheier writes frequently about security from Boylston, Mass. He can be reached at

  • This was last published in June 2002

    Dig Deeper on Web application and API security best practices

    Start the conversation

    Send me notifications when other members comment.

    Please create a username to comment.