Looking for a ThreePeat

By Pete Lindstrom, Director, Security Strategies 27 Sep 2002 | Hurwitz Group, special to SearchWebServices.com

Digg This!     StumbleUpon     Del.icio.us

Market Analysis

Looking for a ThreePeat*
The Web Services One Conference, at which developers plotted and planned a look for our next-generation Web infrastructure, wrapped up in Boston recently. Random security topics abounded within the sea of such programming delights as "JAXP -- the XML API for Java Processing." My talk on "Web Services Security Standards Overview" was well attended, even at 8:00 a.m. More important, Oasis held a concurrent forum on security standards Monday. Some thoughts follow.

THE HURWITZ TAKE: Developers are probably some of the smartest folks on the planet. Their job is highly complex (nothing like building a car, contrary to popular security belief, at least as relates to vulnerabilities), and their ingenuity in overcoming obstacles to "make it work" is beyond reproach. But I cringe when I sense that they might "spin their own" security solution. (This is the real reason people are so focused on security standards; they want to build it in and forget about it!). There I was providing insight into how the standards and protocols work, and my final recommendation is, "Don't do it yourself!"

The most common question asked at these shows is, "Why can't I just use SSL?" So we are stuck having to justify security for our next-generation infrastructure. My response is, if SSL suffices, use it. But perhaps the real question is, "Why use Web services?" If SSL is sufficient, that means that your existing architecture (at least conceptually) won't change much, which makes me wonder why you are redeveloping into a Web service to begin with.

SSL is not persistent security and was not intended to integrate the types of distributed components we are looking for with Web services. XML Encryption and XML Signature (and WS-Security for SOAP messages) are the standards that must be implemented, or at least planned, for sufficient security over Web services transactions.

It sometimes feels as if we are condemned to repeat the mistakes of our past. We never learn that even the best developers in the world fall victim to buffer overflow attacks.

* Term coined by former Lakers Coach Pat Riley.

Copyright 2002 Hurwitz Group Inc. This article is excerpted from TrendWatch, a weekly publication of Hurwitz Group Inc. - an analyst, research, and consulting firm. To register for a free email subscription, click here.

For more information:

• Looking for free research? Browse our comprehensive White Papers section by topic, author or keyword.
• Are you tired of technospeak? The Web Services Advisor column uses plain talk and avoids the hype.
• For insightful opinion and commentary from today's industry leaders, read our Guest Commentary columns.
• Hey Codeheads! Start benefiting from these time-saving XML Developer Tips and .NET Developer Tips.

• Visit our huge Best Web Links for Web Services collection for the freshest editor-selected resources.
• Visit Ask the Experts for answers to your Web services, SOAP, WSDL, XML, .NET, Java and EAI questions.
• Couldn't attend one of our Webcasts? Don't miss out. Visit our archive to watch at your own convenience.
• Choking on the alphabet soup of industry acronyms? Visit our helpful Glossary for the latest lingo.
• Discuss this article, voice your opinion or talk with your peers in the SearchWebServices Discussion Forums.

Digg This!     StumbleUpon     Del.icio.us

RELATED RESOURCES 2020software.com, trial software downloads for accounting software, ERP software, CRM software and business software systems Search Bitpipe.com for the latest white papers and business webcasts Whatis.com, the online computer dictionary