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 document? 

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 later. 

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.