What is AVDL?
The Application Vulnerability Description Language (AVDL) is a new security interoperability standard being proposed by members of the OASIS AVDL Technical Committee. The goal of AVDL is to create a uniform way of describing application security vulnerabilities using XML.
What is the business problem AVDL is addressing?
AVDL will address the business problem of how companies manage ongoing application security risk on a day-to-day basis. Application security, by definition, is far more complex than network security. To begin with, each application is entirely unique. With the wide adoption of web-based technologies, applications have also become far more dynamic, often changing daily, or even hourly. To make matters worse, enterprises must deal with a constant flood of new security patches from their application and infrastructure vendors.
To address this growing problem, companies have begun deploying best-of-breed security products to discover application vulnerabilities, block application-layer attacks, repair vulnerable web sites, distribute patches and manage security events. Unfortunately, there is currently no standard way for these products to communicate with each other, making the overall security management process far too manual and time-consuming.
What is needed to solve this problem?
We are proposing the creation of a standard XML description language to define, categorize and classify application vulnerabilities in a way that can be understood and used by a variety of security products throughout the application security lifecycle. Assessment tools, for example, could create an AVDL file for a particular application that could be read by attack prevention products to recommend the optimal policy for that specific application. Remediation products could use AVDL files to suggest the best course of action for correcting problems, while reporting tools could use AVDL to correlate event logs with areas of known vulnerability. This interoperability will make it far easier for security administrators to manage risk in a constantly changing environment.
How will this benefit customers?
During the application development and testing phases, AVDL will serve as a standard language used by developers and QA testers to identify and remediate pre-production security issues. Finding and correcting security defects early in the application lifecycle is a proven method of overall cost reduction. During the production phase, AVDL will improve the effectiveness of application security gateways through extended rules based on better definition of existing vulnerabilities. It will also serve as a consistent communication mechanism to improve the vulnerability reporting process and appropriate vulnerability remediation. In post production, auditors will spend less time understanding various reports from disparate sources and more time documenting their findings. Ultimately, customers will benefit from both reduced application security risk and decreased total cost of operations and ownership.
Why is the AVDL standard necessary?
Enterprise customers are asking their suppliers to provide products that interoperate. A consistent definition of application security vulnerabilities is a significant step towards that goal. Today, organizations are actively engaged in a project whereby XML-based vulnerability assessment output will be used to improve the effectiveness of attack prevention, event correlation, and remediation technologies. XML establishes a common framework, but XML alone does not ensure vendor interoperability. In fact, the first implementation of these XML-based information exchanges will be proprietary, as no suitable standard exists. Members of the OASIS AVDL Technical Committee believe that customers should ultimately be given the benefit of interoperability between all vendors in each category of the application security lifecycle, allowing them to select those products that offer the most useful functionality for their unique and individual requirements. As a vendor-neutral open forum, OASIS is an ideal vehicle for pursuit of this goal.
What types of companies will contribute to the formation of AVDL?
All members of OASIS are invited to help craft the AVDL specification. We anticipate active participation from leading vendors, integrators and enterprises with expertise in the technologies and real-world business problems of managing application security.
- Examples of how application attack prevention products will use AVDL
Application attack prevention products operate much like firewalls for the web data center. They typically sit in front of web applications, performing deep inspection of all incoming requests, blocking application-layer attacks that traditional network firewalls can't protect against. AVDL will make it easier for attack prevention products to recommend optimal policy settings based on vulnerabilities discovered by assessment tools or attack activity reported by event management systems. Using AVDL, the output of periodic vulnerability assessments could also be read directly by attack prevention products, ensuring up-to-date protection on an ongoing basis.
- Examples of how application vulnerability assessment products will use AVDL
Application vulnerability assessment products typically identify vulnerabilities, rank them by severity level, and provide detailed remediation information. These products identify and prioritize application security issues. Using this information, security administrators, developers and quality assurance professionals then determine how to actually implement the recommended solutions. With AVDL, a standard form of communication will exist whereby vulnerability assessment tools will be able to describe, in great detail, the state of application vulnerabilities at any point in time. This information will be used to develop secure applications, to improve the effectiveness of attack prevention products, to increase the success rate and effectiveness of remediation tools, and to further enhance the value of event management and reporting tools by providing important additional information to operations and management personnel.
- Examples of how remediation products will use AVDL
Remediation products are dependent on two vital types of information: They must understand where the vulnerabilities are and they must know what fixes are required. Remediation products may rely on outside sources to provide much of this information, particularly information related to the actual discovery of vulnerabilities. This is certainly true regarding application security vulnerabilities. Using AVDL, remediation products will be able to process an XML-based input stream that describes existing application vulnerabilities and the required corrective actions, then use that information to effect automated patches when appropriate. When vulnerabilities are corrected, remediation products could also use AVDL to communicate this information back to the attack prevention gateway protecting the site so that its policies could be modified accordingly.
- Examples of how security event management products will use AVDL
Security event management products address a common problem: Security administrators are required to process an inordinate amount of input from various sources and are then expected to focus on the issues that require immediate attention. In most organizations, and in virtually all large enterprises, these administrators are overwhelmed with sensory data. The objective of an event management product is to gather all of the data, apply a set of rules and policies against that data, and to prioritize information so that the administrators can truly focus on the areas of highest impact. The more information that an event management product can process, the better the results. AVDL will provide a standard vehicle for communication of existing application security vulnerabilities, their severity and their potential impact on the organization. As a result, event management products will be able to more efficiently correlate application security vulnerabilities with actual security events, making it easier to prioritize remediation activities and set policies in attack prevention gateways.
- Examples of how dev tools, app servers, ERP vendors, auditors use AVDL
As a standard format for application vulnerability descriptions, AVDL will be used by many other products throughout the application security lifecycle. Using AVDL as an input, for example, development tools will be able to include this information within "standard" reports during the development phase. ERP vendors could use AVDL as a format to communicate potentially vulnerable configurations, making it easier for customers to ensure secure deployments that fit their unique environments. Auditors could use AVDL output from assessments as input to reports that track trend analysis and compliance.
Will ADVL only address application vulnerabilities?
Yes. While network-layer attacks are obviously important, the primary focus of AVDL is to provide a common way to describe application vulnerabilities.
Will AVDL address viruses and worms?
Internet worms like Code Red and Nimda that attack vulnerabilities in web sites clearly fall within the scope of AVDL. The AVDL charter does not, however, attempt to address traditional viruses.
Will AVDL address XML-based web services?
We fully expect XML web services standards like SOAP to play a key role in application-layer vulnerabilities going forward. As such, this definitely falls within the scope of AVDL.
Who can participate in helping to define AVDL?
Anyone with interest in solving this problem is welcome to join the OASIS AVDL Technical Committee.
When will the first AVDL specification be completed?
The first meeting of the full OASIS Technical Committee for AVDL has been scheduled for May 15, 2003. The first candidate AVDL specification will be posted for comment by Q3 of 2003 with a final AVDL 1.0 specification posted by Q4 of 2003.
How is AVDL different from efforts like CVE and VulnXML?
AVDL is not intended to duplicate or replace any existing industry standard and should be entirely complimentary to efforts like CVE and VulnXML. Both CVE and VulnXML focus on creating more uniform ways for security researchers to describe and classify specific new vulnerabilities when they are initially discovered in much the same way anti-virus researchers have been attempting to do for years. CVE is valuable primarily for describing and classifying network-layer vulnerabilities, while VulnXML attempts to add some of the detail needed to adequately describe application-layer vulnerabilities. Members of the OASIS AVDL Technical Committee support both CVE and VulnXML.
AVDL addresses the broader business-oriented problem of how companies actually manage ongoing application security risk on a day-to-day basis. Managing application security risk in a highly dynamic environment can be an extraordinary challenge for security administrators. Fortunately, there are now a wide variety of best-of-breed products on the market to help companies with the task of discovering application vulnerabilities, blocking application-layer attacks, repairing vulnerable web sites, distributing patches and managing security events. Unfortunately, these products have no universal way to communicate with each other, making pragmatic management of this risk a highly manual, and often complex, process.
The goal of AVDL is to help companies begin managing the Full Application Security Lifecycle by providing a more uniform way of communicating application security vulnerabilities, policies and events via XML. It is the full intent of the members of the OASIS AVDL Technical Committee to repurpose any positive progress that has already been made by the security community to date.
