Enterprise Vulnerability Description Language V0.1

Enterprise Vulnerability Description Language v0.1

OASIS Draft, February 2005

Document identifier:

EVDL Specification v0.1

Location:

Editor:

Peter Michalek,

Roger Thornton, Fortify Software,

Contributors:

Kevin Heineman, SPI Dynamics,

Jeff Williams, Aspect Security, Inc.,

Kent Landfield, Citadel Security,

Ivan Ristic,

Curphey Mark, FoundStone Inc., <>

David Raphael, Citadel Security <>

Participants:

Abstract:

This specification defines initial version 0.1 of Enterprise Vulnerability Description Language (EVDL).

Status:

This version of the specification is a Committee Draft within the OASIS WAS TC.

WAS TC members should send comments on this specification to the list. Others may use the following link and complete the comment form:

Table of Contents

EVDL-0.1-draft.doc

1Introduction

1.1Audience

1.2Glossary

1.3Notation

2EVDL Components (Schema Description)

2.1Metadata Element

2.2Profile Element

2.3Analysis Element

2.4Detect Element

2.5Protect Element

3EVDL Database and Transport

4Examples

4.1EVDL Instance with an Analysis Component

4.2EVDL Instance with a Protect Component

4.3Protect Component Example with Referenced Metadata

4.4EVDL Instance with a Detect Component

5Extending EVDL to new security domains.

6Appendix A. Acknowledgements

7Appendix B. Revision History

8Appendix C. Notices

EVDL-0.1-draft.doc

Table of Figures

EVDL-0.1-draft.doc

Figure 1: Graph of System Impact and Likelihood indices and an example...... 7

EVDL-0.1-draft.doc

1 Introduction

EVDL is a comprehensive application security markup language whose primary goal is to facilitate communication about specific application security vulnerabilities, techniques for discovering those vulnerabilities, and measures to protect against those vulnerabilities. . Today companies use a variety of technologies to assess and improve application security. These technologies include source code analysis and review (analysis), application security testing and monitoring (detect), and application runtime protections (protect). While there would be many advantages for these technologies to share information there is no single specification that exists to help facilitate this. In most cases each of these technologies (which we refer to as the “Application Security Domains”) have only basic standards for sharing information between tools in a single domain.

EVDL’s driving objectives and features include

 Unified application vulnerability classification (across all domains)

 Framework template that can accommodate multiple “security domains”

 Schema for several “security domains”, such as source code analysis (“analysis” component), application protection (“protect” component)

The “lifecycle” of a vulnerability extends from the time a mistake is made in the software development process until the time it is patched. During that lifecycle, a vulnerability may stay undiscovered and dormant, or may be exploited and widely publicized. Tools may be developed to automate attacks on that vulnerability, or it may even be exploited by a worm and spread widely. Ultimately, EVDL will address all aspects of the vulnerability lifecycle. In this version of the standard, we have provided domains for two different ways of finding software flaws (detect and analysis) and one domain for defending against these attacks (protect). Future extensions might include domains for:

 repairing the vulnerability by modifying the code or configuration

 identifying vulnerabilities in configuration data

 detection of a compromised system

A direct consequence of these objectives is the ability of EVDL to serve as the unifying glue in application security efforts and tool selection within an enterprise. . A unified framework is needed to ensure that a single vulnerability description can be shared across technologies for vulnerability analysis, vulnerability detection, and vulnerability remediation.

EVDL schema attempts to provide a comprehensive description of application vulnerabilities, including classification (metadata component of EVDL), source code analysis (analysis component), recipe for detection (detect component of EVDL), recipe for protection via an IDS system (protect component of EVDL). While the initial version of the specification is clearly targeting web applications, the long term goal of WAS is to evolve the specification to support applications other then Web applications and protocols other than HTTP.

1.1 Audience

This specification is to meet the needs of several audiences.

One group of readers will want to know: "What is EVDL?”
A reader of this type should:
- read the Concepts section thoroughly
- scan the Protocol section
- scan (at least the outline of) the Schema section.

A second group of readers will want to know: "How would I use EVDL?"
A reader of this type should:
- read the Concepts section thoroughly
- read the Protocol section (with special attention to the purpose and examples)
- scan the Schema section

A third group of readers will want to know: "How must I implement EVDL?"
A reader of this type must:
- read the Concepts section
- read the Protocol section (with special attention to normative sub-sections)
- read the Schema section (with special attention to normative sub-sections)

1.2 Glossary

TBD

1.3 Notation

The Keywords “MUST,” “MUST NOT,” “REQUIRED,” “SHALL,” “SHALL NOT,” “SHOULD,” “SHOULD NOT,” “RECOMMENDED,” “MAY,” “MAY NOT,” and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.

2 EVDL Components (Schema Description)

EVDL schema is composed of the following components:

 Metadata– Basic information

 Profile– Application vulnerability classification

 Analysis– Source Code Analysis vulnerability information

 Detect– Application vulnerability detection recipes

 Protect – Application runtime protection recipes

2.1 Metadata Element

The metadata element describes basic information related to creation of the vulnerability such as a unique ID, provider name, restriction on usage and history. This information is important as it provides the basic information required to create, search, and maintain a library of vulnerabilities.

2.2 Profile Element

The profile element provides detailed vulnerability profile, including vulnerability type/classification, risk ranking, abstract and description, processes contributing to vulnerability creation. Profile information is important in automating the processing of high volume of vulnerabilities within an organization where proper ranking and prioritization need to be performed.

EVDL takes an approach different from that of other schemas to vulnerability classification. Instead of trying to force classification of a vulnerability into only one category, vulnType is a "tag" that can be attached to a vulnerability instance. Multiple tags can be associated with one vulnerability instance, so that for example a vulnerability caused by a buffer overflow that is due to incorrect input validation and allows the attacker shell remote access to a computer system can be classified as both BufferOverflow.Stack and InputValidation.Network. This allows for a more flexible approach to vulnerability classification, ranking and prioritization within a company.

A major part of the profile element is the concrete classification scheme list enumerated in the "vulnType". There are 13 major vulnType categories:

AccessControl

ConfigurationManagement

IntegerOverflow

DataProtection

InputValidation

Concurrency

AppDOS

BufferOverflow

Injection

ErrorHandling

Monitoring

Cryptography

Authentication

A complete list of vulnTypes contains 54 entries:

AccessControl

ConfigurationManagement

ConfigurationManagement.Administration

ConfigurationManagement.Application

ConfigurationManagement.Infrastructure

IntegerOverflow

DataProtection

DataProtection.Storage

DataProtection.Transport

InputValidation

InputValidation.User

InputValidation.Network

InputValidation.File

Concurrency

AppDOS

AppDOS.Flood

AppDOS.Lockout

BufferOverflow

BufferOverflow.Heap

BufferOverflow.Stack

BufferOverflow.Format

Injection

Injection.SQL

Injection.HTML

Injection.OSCommand

Injection.LDAP

Injection.XSS

ErrorHandling

Monitoring

Monitoring.Logging

Monitoring.Detection

Cryptography

Cryptography.Algorithm

Cryptography.KeyManagement

Authentication

Authentication.User

Authentication.UserManagement

Authentication.Entity

Authentication.SessionManagement

As defined in the schema today, vulnTypes are strongly typed: i.e. when an entity registers or store a vulnerability in EVDL compliant format, only one of the given types may be specified.

For more information on vulnerability classification, please see

Evaluating severity of vulnerabilities is not an exact science: there are different approaches security products take. Sometimes the ranges are within 0-100 numerical levels, others employ a simple Low, Medium, High system. WAS developed a simple scheme to describe severities rankings:

• Informational
• Low
• Medium
• High
• Critical

The rankings are calculated using two indices:

• System Impact
• Likelihood

Figure 1: Graph of System Impact and Likelihood indices and an example

2.3 Analysis Element

The analysis element provides extensions to EVDL required to express vulnerabilities derived from source code analysis and as such includes artifacts critical to expressing source code constructs including: files, line numbers, functions/methods, variables/arguments, and flow paths through program source code.

Source code security auditing is a highly effective (dependent on the skills of the auditor) method to locate vulnerabilities in applications due to the ability to cover all possible conditions when reviewing the code (i.e. following all the possible paths of execution); this of course can be quite difficult to force a program to do when running the application and analyzing dynamically. Historically, the technique of source code auditing has been limited to the most critical projects, typically in the Defense and Financial Services domains, due to the deep security expertise and extreme diligence required on the part of the auditor. The technique is rapidly becoming more pervasive with the advent and adoption of source code analysis tools that reduce the knowledge required to inspect code while simplifying the process and making it more scalable and repeatable.

The Analysis element is unique to EVDL. Existing schemas for expressing application vulnerabilities (both proprietary and open source) were constructed to support information sharing in the “detect” and “prevent” Application Security Domains. As such, this element does not have a pre-existing baseline for comparison and it is expected that the specification will evolve as integration with commercial and open source tools provides feedback.

The principle portion of the analysis element is the “AnalysisInfo” element that has a unique identifier (Vulnerability ID) and contains any number of “Dataflow” elements that describe the vulnerability. A Dataflow element can be either “global” or “local” in scope. This describes weather the vulnerability points to a single method (local) or is the result of a flow path (global). In either case the Dataflow element contains one or more pointers to methods and arguments that are categorized as Sources, Nodes, or Sinks. Sources and Sinks are used to mark a starting and ending point to a vulnerability that occurs over a flow path and a Node is used to describe a single function or method as the vulnerability.

The following example will help illustrate the use of Source, Sink, and Node:

01#define MAX_SIZE 128

02

03void doMemCpy(char* buf, char* in, int chars) {

04 memcpy(buf, in, chars);

05}

06

07int main() {

08 char buf[64];

09 char in[MAX_SIZE];

10 int bytes;

11

12 printf("Enter buffer contents:\n");

13 read(0, in, MAX_SIZE-1);

14 printf("Bytes to copy:\n");

15 scanf("%d", &bytes);

16

17 doMemCpy(buf, in, bytes);

18

19 return 0;

20}

Most source code analysis scanners (including simple lexical analyzers like RATS & ITS4) would flag line #4 as a possible stack buffer overflow vulnerability. This result would be expressed as a “local” Dataflow element with a Node element at line #4. A more advanced source code analysis engine that supports semantic and dataflow analysis should catch the fact that user input read at line #15 (a Source) is passed through the call to doMemCpy at line #17 (a Node) to the memcpy call at line #4 (a Sink). The result would be expressed as a “global” Dataflow element containing the Source, Node, and Sink as described above to fully express the flow path that creates the vulnerability.

2.4 Detect Element

The detect element is semantically similar to AVDL's vulnerability-probe section. It describes simulated attacks on applications and scripts that detect vulnerabilities during these attacks.

An approach somewhat different from AVDL in this components is incorporation of scripting directly into the schema, rather than using solely XML constructs to express logic that tests for presence of data elements in responses.

Peter: … to b3e completed

2.5 Protect Element

Web application vulnerabilities can be discovered in several ways:

• By inspecting the application, either manually or via a web vulnerability scanner that can test for generic problems.
• For ready-made applications, by enumerating the installed applications, determining their versions, and referencing the vulnerability databases.
• By utilizing Detect entries to test applications for specific vulnerabilities.

The preferred resolution is to resolve the problem on the programming level, by upgrading the application or by making changes to the source code. However, there are many instances in which this is not possible:

• The source code is not available.
• The vulnerability exists in a legacy application, which is very difficult to fix.
• The organization does not posses the resources to fix the error in timely manner.

Even in the cases where there is a genuine will to fix the problem in code, some time may pass before the fix is actually deployed. This is often unacceptable.

The purpose of the Protect element is to provide means to neutralize vulnerabilities on the HTTP level, i.e. with no access to the application source code. This is possible because the interactions between web clients (e.g. browsers) and web applications are carried out in a manner similar to that of function invocation in programming languages. Special devices, called web application firewalls, can intercept these function invocations, analyze the parameters, and decide whether the request is an attack. The Protect element serves to specify the tests needed to determine if a request is valid, or if it constitutes an attack against the application.

The following usage scenarios are envisioned for the Protect element:

• A routine web vulnerability scan discovers a known problem in the application. The Protect rule for the problem was previously designed by the (web vulnerability scanner) vendor. The scanning tool communicates with the web application firewall to apply the rule.
• Problem is discovered during manual inspection. The web application administrator can design a custom rule to protect the application from attacks.
• The deployed web application firewall is aware of the ready-made products running, and it also knows their versions. When a problem is reported the vendor creates a Protection rule, which is then propagated to the web application firewall installations through an automatic update mechanism. The rule is therefore installed automatically.

3 EVDL Database and Transport

4 Examples

The following examples illustrate typical usage of EVDL in different security domains. For the sake of brevity, only relevant sections of examples are shown here. Complete sample EVDL instances can be retrieved at

Examples are provided for several security domains. Some of them contain, in addition to the security domain specific section, a metadata and a profile section which provides generic vulnerability information.

One example illustrates how security domain information can be provided without including metadata and profile section, by referring to an existing description via an ID.

4.1 EVDL Instance with an Analysis Component

For a complete example, please see

This example contains the optional metadata and profile components followed by source code analysis domain component “analysis”.

<evdl>

<metaData>

…

</metaData>

<profile>

…

</profile>

<analysis>

…

</analysis>

</evdl>

4.2 EVDL Instance with a Protect Component

For a complete example, please see

This example contains the optional metadata and profile components followed by the protect component with rules that specify how the application should be protected.

<evdl>

<metaData>

…

</metaData>

<profile>

…

</profile>

<recipe>

…

</recipe>

</evdl>

4.3 Protect Component Example with Referenced Metadata

For a complete example, please see

This example doesn’t contain the optional metadata and profile but instead references their description by ID of another document. Therefore it contains only protect component under the root EVDL element:

<evdl>

<recipe id="magnolia-9E9BC8AD2338EBBBF6986C4255409A6D">

<ruleSet stage="requestHeaders" action="error" condition="and">

…

4.4 EVDL Instance with a Detect Component

Peter: complete once detect component finalized

5 Extending EVDL to new security domains.

EVDL proposes to support embedding documents that support new application security domains and define new application security domain schema descriptions in the future.

A necessary condition to include new schemas would be if developers of security domains use EVDL metadata and profile in a manner similar to example 2.5 and thus avoid duplication of generic security constructs used in metadata (including ID, license, history) and profile (including classification i.e. vulnTypes and riskRanking).

6 Appendix A. Acknowledgements

The WAS Technical Committee would like to acknowledge other efforts for standardization of application vulnerabilities, most notable work done by AVDL TC and

And OVAL board at Mitre Corporation, as well as pioneering work done by OWASP, including VulnXML whose continuation was one of the impulses of creating this WAS TC. EVDL has built upon earlier standardization efforts and will evolve with other standards in mind.

7 Appendix B. Revision History

Rev / Date / By Whom / What
EVDL-01 / 2005-01-04 / Peter Michalek / Version 0.1 - First committee draft
EVDL-02 / 2005-02-01 / Peter Michalek / Merged feedback from Roger and Jeff
EVDL-03 / 2005-02-13 / Peter Michalek / Merged new content based on 2/2/5 action items

8 Appendix C. Notices

OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS's procedures with respect to rights in OASIS specifications can be found at the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification, can be obtained from the OASIS Executive Director.