In a discussion today with Wes Swensen of Forum Systems
about XML security appliances, the concept of "business context
security" came up. The idea is relatively simple: in the past
people have mostly thought of security as an edge game. Given a
firewall and access control to the network and publicly viewable
machines, I can do a lot to secure my business. Sure, security
experts have been telling us for years that this isn't enough, but for
the most part it has been good enough.
One of the unmistakable trends in IT is the need to integrate
systems, not only internally, but with trading partners and
customers. This has been fueled by XML and the creation of
standards for exchanging data as well as Web services which give us the
ability to decentralize our computing. This trend has huge
ramifications for the security folks: they can't treat the edges of the
network as a secure perimeter and call it good. Intrusion
detection is a lot harder when you're allowing people and software
agents access to your internal data and systems.
Consider the common firewall. Almost every corporation has a
firewall in front of their network. Almost every corporate
firewall is configured to pass port 80 traffic (HTTP traffic)
unhindered and unnoticed because no one can live without the web.
The problem is obvious: if port 80 can carry Web service traffic and
XML data, then everything in your network is potentially exposed.
Your firewall is filtering out one kind of attack only to allow another
kind right in. Firewalls are designed to filter packets,
not the content in the packet.
Integration is being driven by business needs. This means that
security policies need to talk about documents, data, actions, people,
and corporations instead of machines and networks. This security model
is infinitely more complex than the old "secure perimeter" model. Even
if you do define your policy, how do you ensure its properly
implemented across dozens or even hundreds of systems? How do you
manage access control to field of the database or paragraphs of the
XML security products aim to fill this hole. I suspect that if
you don't have one now, you will in the near future. Even if
you're not actively pursuing Web services, you'll need to protect
yourself from rogue SOAP insertions into your network, since Murphy
will ensure that there's a machine somewhere in your network with a
SOAP server running. I'm working on a review of XML security
appliances right now and will have more to say about these products
What everyone needs to realize is that tools like XML and Web
services are making some jobs, like legacy system integration easier,
but they're making other jobs, like security, much more
difficult. The answer isn't just more technology, its also more
discipline. Well run IT organization will manage this job the way
they manage other tough jobs: using well documented processes with well
thought-out metrics and reviews to ensure that the policies are
implemented correctly and doing the job. Enterprises that
continue to treat security in and ad hoc manner will get burnt.