Subject: [NEXTEL-1] Spreading thin Distributed Web services and XML raise new security concerns

From: Marcel <[email-masked]>
Date: Wed, 12 Mar 2003 13:06:12 -0500

Spreading thin Distributed Web services and XML raise new security concerns

BY Paul Korzeniowski
March 10, 2003

Recently, the Web services buzz has been getting louder. Once in place, this group of data
exchange and application standards promises to enable government agencies to swap
information more easily — within their own systems, with other agencies and with citizens.

Extensible Markup Language is the foundation for those new capabilities, which can play a
vital role in many homeland security efforts, from tightening borders to spotting
bioterror attacks. XML breaks traditional barriers in application design by replacing
proprietary software interfaces with standard components. As a result, information from
different sources can move dynamically, allowing agencies to respond more quickly to new
operational requirements.
But as agencies have begun tinkering with the alluring technology, they have found some
glaring holes. "Most security products were designed to operate with simple point-to-point
connections and cannot handle the one-to-many links possible with Web services," said
Susan Eustis, president of WinterGreen Research Inc., a Lexington, Mass., market research
firm.
Suppliers are aware of the problem and are moving to boost the security capabilities of
their products. They are also crafting an array of standards so agencies can be sure XML
transactions move securely from place to place.  The work is complex and has resulted in a
hodgepodge of standards and initiatives (see "Web security standards no easy task").
Ideally, the developments will meld into a security architecture that federal agencies can
easily deploy using off-the-shelf products, but that outcome is far from certain.
"With XML, an agency can create a document one time and then move it from a browser to a
printer and then to a file system," said Marion Royal, the General Services
Administration's XML expert and co-chairman of the CIO Council's XML Working Group.
However, the new markup language evolved in a manner similar to other dramatic changes,
such as the explosive popularity of personal computers and the Web: The foundation for
efficient processing was put in place first and security issues were addressed later.
"XML by itself is not secure," said Barry Leffew, vice president of VeriSign Inc.'s public
sector group. "Vendors need to add new distributed security components to make sure XML
transactions are not open to interference from outsiders."
Because of the security limitation, federal agencies are adopting XML on a selective,
rather than widespread, basis. "Many organizations are implementing XML only behind the
firewall and using it to help different internal applications communicate," said Owen
Ambur, a systems analyst at the Fish and Wildlife Service and co-chairman of the CIO
Council's XML Working Group. For instance, information technology executives can use XML
to add Web-based services to human resources management systems on their agencies'
intranets.
Only in rare cases are agencies going outside their firewalls with XML (see "XML allows
Census to change directions"). However, when they do, many rely on Secure Sockets Layer to
improve security. Although SSL ensures that no outsider taps into a line and reads a
communication, the protocol cannot help an agency determine if certain information is safe
enough to be downloaded or if it is being delivered to an authorized user.
Federal agencies have three options for meeting those needs. First, agencies can build
their own XML security systems. Because the work is complex, government departments may
prefer to hand it over to a third-party security specialist. "There are a number of firms
that are making a pretty good living developing security systems for government agencies,"
Eustis said.
A second option is to use proprietary products to fill the void. A growing number of
vendors offer middleware software and services that boost XML security. They include BEA
Systems Inc. in San Jose, Calif.; Tibco Software Inc. in Palo Alto, Calif.; and VeriSign
in Mountain View, Calif.
Both options can ensure that XML transactions are protected, but they can be costly and
time-consuming to deploy. Furthermore, they lock agencies into a single vendor's solution,
which may make it difficult to keep IT costs down over time.
The third and perhaps ideal option is to build a distributed security system using a
variety of commercially available products that can be easily integrated. However,
creating such an infrastructure requires standards. Developing such standards will be
tricky because people have different visions about how XML security systems should work
and how much security is enough.
Underscoring the complexity of the task, vendors are creating a slew of standards — more
than a dozen from three organizations — to secure XML links. The standards are evolving in
a building-block manner, starting with the transport layer (basically the network) and
working up the protocol stack to the top (the application layer).
However, there are a couple of potential stumbling blocks. The World Wide Web Consortium
(W3C), the Organization for the Advancement of Structured Information Standards (OASIS)
and the Internet Engineering Task Force are all contributing to the mix.
"With different groups working on various security standards, there is a distinct
possibility that they will deliver items that don't quite fit with one another," Eustis
said.
Proponents are aware of potential problems and are trying to help ensure that the various
standards will interoperate. For instance, they are basing higher-level standards, such as
Web Services Security (WS-Security), on lower-level standards, such as those for XML-based
digital signatures and encryption.
Also, OASIS and W3C have been comparing their efforts with the aim of crafting consistent
security standards. The cooperation was evident with WS-Security, a specification IBM
Corp., Microsoft Corp. and VeriSign developed and turned over to OASIS in 2002. A short
time later, OASIS and W3C sponsored a forum to evaluate work being done by both groups.
Vendors are also trying to help ensure consistency. "A number of the engineers, such as
myself, who are part of OASIS working groups also work on [W3C] committees," said Krishna
Sankar, a distinguished engineer at Cisco Systems Inc.
"Most vendors are ready to move into beta testing now with their WS-Security-compliant
products, expect to have them in production in the summer and anticipate users ramping up
deployments as the year ends," said Bob Blakley, chief scientist for security at IBM's
Tivoli software group in Austin, Texas.
Such projections are based on the belief that vendors will deliver products that can be
easily connected, but that may not be the case. "These XML security specification are
quite broad, and compliance is open to interpretation," said Pete Lindstrom, research
director at Spire Security LLC, a Malvern, Pa., consulting firm. "A vendor can leave out
one full set of functions but still claim to comply with the standard. Obviously, such a
product would not work with another system using all of the functions."
Ideally, a customer would be able to tell how well different products would interoperate
by turning to a third party responsible for compliance testing, a step typically taken
with networking products, such as Ethernet switches. To date, no group has stepped forward
to fill that void and it seems unlikely that anyone will.
"There was a lot of discussion initially among vendors about setting up a
conformance-testing entity, but there were hurdles, such as how much money would be
required to fund it and its legal liability, so the talk died down," said Eve Maler, XML
standards architect at Sun Microsystems Inc.
So how smooth will the migration to XML security functions be? "Already, a few
interoperability demonstrations have been held, and there have been only minor problems
getting different products connected," Sankar said.
Others are pessimistic. "Distributed security is a complex issue, one that will require
significant investments by users and vendors," Eustis said. "Progress is being made, but
it will take a few years — maybe more — before we see easy-to-install solutions based on
industry standards."

http://www.fcw.com/supplements/homeland/2003/sup1/hom-web-03-10-03.asp
--
    "NEXTEL-1 IT'S NOT JUST NEXTEL"
  Note The New address
Subscribe to Nextel-1: http://www.groups.yahoo.com/subscribe/NEXTEL-1

  "NEXTEL2 FOR iDEN SOFTWARE DEVELOPERS"
Subscribe to Nextel2: http://www.groups.yahoo.com/subscribe/NEXTEL2

  "WIRELESS FORUM HOMELAND SECURITY GROUP"
     The Complete Resource for Wireless Homeland Security.
Subscribe to WFHSG:  http://www.groups.yahoo.com/subscribe/WFHSG

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/