This article can also be found in the Premium Editorial Download "Information Security magazine: Help! Evaluating AV solutions and tech support."
Download it now to read this article plus other related content.
Picture a United Nations meeting. Sitting around a huge table is a bunch of diplomats wearing upside-down headphones (yes, I know they're called "translators"). Each delegate is among his country's political and cultural elite. He's intelligent, articulate and uniquely positioned to represent the interests of his nation to the international community. And yet, without the upside-down headphones, he might as well be deaf and dumb. It's the translator that allows him to understand and be understood.
Network security is like a U.N. meeting without the upside-down headphones. We've got all these intelligent devices that perform unique and important functions, but there's no lingua franca that allows them to understand each other. Sure, they can talk to "neighboring" devices in the same way that delegates from England can talk to those from Australia and the U.S. But in the network world, most security devices are incapable of communicating beyond that.
In a nutshell, AVDL is a standard XML format that allows the tools engaged in Web vulnerability discovery to communicate with the tools dedicated to Web vulnerability remediation. Let's say, for instance, that a Web scanner finds a XSS condition in a Web page. Using AVDL, the scanner can send the vulnerability information in an XML format to a policy or correlation tool, which determines the best way to remediate the vulnerability. The correlation tool then uses AVDL to communicate the fix or workaround to, say, an application firewall, which would block connections to that page until the XSS condition can be fixed.
The reason I love AVDL is that it treats security for what it is: a lifecycle involving continuous vulnerability and threat correlation. Vulnerabilities are interesting only in the context of threat viability; you could be wide open to a threat but not give a hoot if that attack is technically infeasible. Likewise, threats are only interesting in the context of a target's vulnerability. The IDS vendors are on to this. Many NIDSes now use a target's OS, port and service information to weed out untenable threats.
AVDL automates the communication and workflow process among the devices involved in this lifecycle. And, because it's an open standard, it can be used in mixed-vendor as well as mixed-device environments.
Mind you, AVDL isn't a silver bullet. Version 1.0 is very limited in scope, focusing only on Web app vulnerabilities. In version 2.0, OASIS hopes to expand AVDL's scope to network- and OS-layer vulnerability management--the equivalent of expanding a language shared among five nations to 50. Monumental obstacles stand in the way, not the least of which is the difficulty of expressing non-HTTP-based vulnerabilities in XML. Getting VA and firewall vendors with bigger sandboxes to agree to play nice will also be challenging. So far, vendors like ISS have shown no interest.
Nevertheless, OASIS deserves a nod for the AVDL effort. Combined with other efforts designed to standardize vulnerability intelligence?I'm thinking mostly of MITRE's work on the Open Vulnerability Assessment Language (OVAL)--AVDL paints a picture of how the future could be. It's a future where vulnerability and threat management devices throughout the network, and up and down the stack, can be managed through a common language.
About the author:
Andrew Briney, CISSP, is editor-in-chief of Information Security and editorial director of the TechTarget Security Media Group.
This was first published in October 2004