Your SlideShare is downloading. ×
EVDL 0.1 Draft
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

EVDL 0.1 Draft

257
views

Published on


0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
257
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
1
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. 1 2Enterprise Vulnerability Description 3Language v0.1 4OASIS Draft, February 2005 5 6Document identifier: 7 EVDL Specification v0.1 8Location: 9 http://TBD 10Editor: 11 Peter Michalek, peter@michalek.org 12 Roger Thornton, Fortify Software, roger@fortifysoftware.com 13Contributors: 14 Kevin Heineman, SPI Dynamics, kheineman@spidynamics.com 15 Jeff Williams, Aspect Security, Inc., jeff.williams@aspectsecurity.com 16 Kent Landfield, Citadel Security, klandfield@citadel.com 17 Ivan Ristic, ivanr@webkreator.com 18 Curphey Mark, FoundStone Inc., <mark.curphey@foundstone.com> 19 David Raphael, Citadel Security <draphael@citadel.com> 20 21 22Participants: 23 24Abstract: 25 This specification defines initial version 0.1 of Enterprise Vulnerability Description 26 Language (EVDL). 27 28Status: 29 This version of the specification is a Committee Draft within the OASIS WAS TC. 1evdl-01-draft3806.doc Page 1 of 14
  • 2. 30 WAS TC members should send comments on this specification to the was@lists.oasis- 31 open.org list. Others may use the following link and complete the comment form: 32 http://oasis-open.org/committees/comments/form.php?wg_abbrev=was. 33 34Table of Contents 351 Introduction.....................................................................................................................................3 36 1.1 Audience..................................................................................................................................3 37 1.2 Glossary...................................................................................................................................4 38 1.3 Notation...................................................................................................................................4 392 EVDL Components (Schema Description)......................................................................................4 40 2.1 Metadata Element....................................................................................................................4 41 2.2 Profile Element........................................................................................................................4 42 2.3 Analysis Element.....................................................................................................................8 43 2.4 Detect Element........................................................................................................................9 44 2.5 Protect Element.....................................................................................................................10 453 EVDL Database and Transport.....................................................................................................11 464 Examples......................................................................................................................................11 47 4.1 EVDL Instance with an Analysis Component.........................................................................11 48 4.2 EVDL Instance with a Protect Component ............................................................................12 49 4.3 Protect Component Example with Referenced Metadata......................................................12 50 4.4 EVDL Instance with a Detect Component .............................................................................12 515 Extending EVDL to new security domains....................................................................................13 526 Appendix A. Acknowledgements...................................................................................................13 537 Appendix B. Revision History........................................................................................................13 548 Appendix C. Notices......................................................................................................................13 55 56Table of Figures 57Figure 1: Graph of System Impact and Likelihood indices and an example.......................................7 58 59 60 2evdl-01-draft3806.doc Page 2 of
  • 3. 611 Introduction 62EVDL is a comprehensive application security markup language whose primary goal is to facilitate 63communication about specific application security vulnerabilities, techniques for discovering those 64vulnerabilities, and measures to protect against those vulnerabilities. . Today companies use a 65variety of technologies to assess and improve application security. These technologies include 66source code analysis and review (analysis), application security testing and monitoring (detect), 67and application runtime protections (protect). While there would be many advantages for these 68technologies to share information there is no single specification that exists to help facilitate this. In 69most cases each of these technologies (which we refer to as the “Application Security Domains”) 70have only basic standards for sharing information between tools in a single domain. 71 72EVDL’s driving objectives and features include 73 • Unified application vulnerability classification (across all domains) 74 • Framework template that can accommodate multiple “security domains” 75 • Schema for several “security domains”, such as source code analysis (“analysis” 76 component), application protection (“protect” component) 77 78The “lifecycle” of a vulnerability extends from the time a mistake is made in the software 79development process until the time it is patched. During that lifecycle, a vulnerability may stay 80undiscovered and dormant, or may be exploited and widely publicized. Tools may be developed to 81automate attacks on that vulnerability, or it may even be exploited by a worm and spread widely. 82Ultimately, EVDL will address all aspects of the vulnerability lifecycle. In this version of the 83standard, we have provided domains for two different ways of finding software flaws (detect and 84analysis) and one domain for defending against these attacks (protect). Future extensions might 85include domains for: 86 • repairing the vulnerability by modifying the code or configuration 87 • identifying vulnerabilities in configuration data 88 • detection of a compromised system 89 90 91A direct consequence of these objectives is the ability of EVDL to serve as the unifying glue in 92application security efforts and tool selection within an enterprise. . A unified framework is needed 93to ensure that a single vulnerability description can be shared across technologies for vulnerability 94analysis, vulnerability detection, and vulnerability remediation. 95 96EVDL schema attempts to provide a comprehensive description of application vulnerabilities, 97including classification (metadata component of EVDL), source code analysis (analysis 98component), recipe for detection (detect component of EVDL), recipe for protection via an IDS 99system (protect component of EVDL). While the initial version of the specification is clearly 100targeting web applications, the long term goal of WAS is to evolve the specification to support 101applications other then Web applications and protocols other than HTTP. 102 1031.1 Audience 104This specification is to meet the needs of several audiences. 3evdl-01-draft3806.doc Page 3 of
  • 4. 105One group of readers will want to know: "What is EVDL?” 106A reader of this type should: 107- read the Concepts section thoroughly 108- scan the Protocol section 109- scan (at least the outline of) the Schema section. 110A second group of readers will want to know: "How would I use EVDL?" 111A reader of this type should: 112- read the Concepts section thoroughly 113- read the Protocol section (with special attention to the purpose and examples) 114- scan the Schema section 115A third group of readers will want to know: "How must I implement EVDL?" 116A reader of this type must: 117- read the Concepts section 118- read the Protocol section (with special attention to normative sub-sections) 119- read the Schema section (with special attention to normative sub-sections) 1201.2 Glossary 121TBD 1221.3 Notation 123The Keywords “MUST,” “MUST NOT,” “REQUIRED,” “SHALL,” “SHALL NOT,” “SHOULD,” 124“SHOULD NOT,” “RECOMMENDED,” “MAY,” “MAY NOT,” and “OPTIONAL” in this document are 125to be interpreted as described in RFC 2119. 126 1272 EVDL Components (Schema Description) 128EVDL schema is composed of the following components: 129 • Metadata – Basic information 130 • Profile – Application vulnerability classification 131 • Analysis – Source Code Analysis vulnerability information 132 • Detect – Application vulnerability detection recipes 133 • Protect – Application runtime protection recipes 134 1352.1 Metadata Element 136 137The metadata element describes basic information related to creation of the vulnerability such as a 138unique ID, provider name, restriction on usage and history. This information is important as it 139provides the basic information required to create, search, and maintain a library of vulnerabilities. 1402.2 Profile Element 141 4evdl-01-draft3806.doc Page 4 of
  • 5. 142The profile element provides detailed vulnerability profile, including vulnerability type/classification, 143risk ranking, abstract and description, processes contributing to vulnerability creation. Profile 144information is important in automating the processing of high volume of vulnerabilities within an 145organization where proper ranking and prioritization need to be performed. 146EVDL takes an approach different from that of other schemas to vulnerability classification. Instead 147of trying to force classification of a vulnerability into only one category, vulnType is a "tag" that can 148be attached to a vulnerability instance. Multiple tags can be associated with one vulnerability 149instance, so that for example a vulnerability caused by a buffer overflow that is due to incorrect 150input validation and allows the attacker shell remote access to a computer system can be classified 151as both BufferOverflow.Stack and InputValidation.Network. This allows for a more flexible approach 152to vulnerability classification, ranking and prioritization within a company. 153A major part of the profile element is the concrete classification scheme list enumerated in the 154"vulnType". There are 13 major vulnType categories: 155 AccessControl 156 ConfigurationManagement 157 IntegerOverflow 158 DataProtection 159 InputValidation 160 Concurrency 161 AppDOS 162 BufferOverflow 163 Injection 164 ErrorHandling 165 Monitoring 166 Cryptography 167 Authentication 168A complete list of vulnTypes contains 54 entries: 169 AccessControl 170 ConfigurationManagement 171 ConfigurationManagement.Administration 172 ConfigurationManagement.Application 173 ConfigurationManagement.Infrastructure 174 IntegerOverflow 175 DataProtection 5evdl-01-draft3806.doc Page 5 of
  • 6. 176 DataProtection.Storage 177 DataProtection.Transport 178 InputValidation 179 InputValidation.User 180 InputValidation.Network 181 InputValidation.File 182 Concurrency 183 AppDOS 184 AppDOS.Flood 185 AppDOS.Lockout 186 BufferOverflow 187 BufferOverflow.Heap 188 BufferOverflow.Stack 189 BufferOverflow.Format 190 Injection 191 Injection.SQL 192 Injection.HTML 193 Injection.OSCommand 194 Injection.LDAP 195 Injection.XSS 196 ErrorHandling 197 Monitoring 198 Monitoring.Logging 199 Monitoring.Detection 200 Cryptography 201 Cryptography.Algorithm 202 Cryptography.KeyManagement 203 Authentication 204 Authentication.User 205 Authentication.UserManagement 206 Authentication.Entity 207 Authentication.SessionManagement 6evdl-01-draft3806.doc Page 6 of
  • 7. 208As defined in the schema today, vulnTypes are strongly typed: i.e. when an entity registers or store 209a vulnerability in EVDL compliant format, only one of the given types may be specified. 210For more information on vulnerability classification, please see 211http://www.oasis-open.org/apps/org/workgroup/was/download.php/6536/oasis-was1.0-vulntypes- 212version2.doc 213 214Evaluating severity of vulnerabilities is not an exact science: there are different approaches security 215products take. Sometimes the ranges are within 0-100 numerical levels, others employ a simple 216Low, Medium, High system. WAS developed a simple scheme to describe severities rankings: 217 • Informational 218 • Low 219 • Medium 220 • High 221 • Critical 222 223The rankings are calculated using two indices: 224 • System Impact 225 • Likelihood 226 227 228Figure 1: Graph of System Impact and Likelihood indices and an example 7evdl-01-draft3806.doc Page 7 of
  • 8. 229 230 231 232 2332.3 Analysis Element 234The analysis element provides extensions to EVDL required to express vulnerabilities derived from 235source code analysis and as such includes artifacts critical to expressing source code constructs 236including: files, line numbers, functions/methods, variables/arguments, and flow paths through 237program source code. 238Source code security auditing is a highly effective (dependent on the skills of the auditor) method to 239locate vulnerabilities in applications due to the ability to cover all possible conditions when 240reviewing the code (i.e. following all the possible paths of execution); this of course can be quite 241difficult to force a program to do when running the application and analyzing dynamically. 242Historically, the technique of source code auditing has been limited to the most critical projects, 243typically in the Defense and Financial Services domains, due to the deep security expertise and 244extreme diligence required on the part of the auditor. The technique is rapidly becoming more 245pervasive with the advent and adoption of source code analysis tools that reduce the knowledge 246required to inspect code while simplifying the process and making it more scalable and repeatable. 247The Analysis element is unique to EVDL. Existing schemas for expressing application 248vulnerabilities (both proprietary and open source) were constructed to support information sharing 249in the “detect” and “prevent” Application Security Domains. As such, this element does not have a 8evdl-01-draft3806.doc Page 8 of
  • 9. 250pre-existing baseline for comparison and it is expected that the specification will evolve as 251integration with commercial and open source tools provides feedback. 252The principle portion of the analysis element is the “AnalysisInfo” element that has a unique 253identifier (Vulnerability ID) and contains any number of “Dataflow” elements that describe the 254vulnerability. A Dataflow element can be either “global” or “local” in scope. This describes weather 255the vulnerability points to a single method (local) or is the result of a flow path (global). In either 256case the Dataflow element contains one or more pointers to methods and arguments that are 257categorized as Sources, Nodes, or Sinks. Sources and Sinks are used to mark a starting and 258ending point to a vulnerability that occurs over a flow path and a Node is used to describe a single 259function or method as the vulnerability. 260The following example will help illustrate the use of Source, Sink, and Node: 261 26201 #define MAX_SIZE 128 26302 26403 void doMemCpy(char* buf, char* in, int chars) { 26504 memcpy(buf, in, chars); 26605 } 26706 26807 int main() { 26908 char buf[64]; 27009 char in[MAX_SIZE]; 27110 int bytes; 27211 27312 printf("Enter buffer contents:n"); 27413 read(0, in, MAX_SIZE-1); 27514 printf("Bytes to copy:n"); 27615 scanf("%d", &bytes); 27716 27817 doMemCpy(buf, in, bytes); 27918 28019 return 0; 28120 } 282 283Most source code analysis scanners (including simple lexical analyzers like RATS & ITS4) would 284flag line #4 as a possible stack buffer overflow vulnerability. This result would be expressed as a 285“local” Dataflow element with a Node element at line #4. A more advanced source code analysis 286engine that supports semantic and dataflow analysis should catch the fact that user input read at 287line #15 (a Source) is passed through the call to doMemCpy at line #17 (a Node) to the memcpy 288call at line #4 (a Sink). The result would be expressed as a “global” Dataflow element containing the 289Source, Node, and Sink as described above to fully express the flow path that creates the 290vulnerability. 291 2922.4 Detect Element 293 294The detect element is semantically similar to AVDL's vulnerability-probe section. It describes 295simulated attacks on applications and scripts that detect vulnerabilities during these attacks. 9evdl-01-draft3806.doc Page 9 of
  • 10. 296 297An approach somewhat different from AVDL in this components is incorporation of scripting directly 298into the schema, rather than using solely XML constructs to express logic that tests for presence of 299data elements in responses. 300Peter: … to b3e completed 3012.5 Protect Element 302Web application vulnerabilities can be discovered in several ways: 303 • By inspecting the application, either manually or via a web vulnerability scanner that can 304 test for generic problems. 305 • For ready-made applications, by enumerating the installed applications, determining their 306 versions, and referencing the vulnerability databases. 307 • By utilizing Detect entries to test applications for specific vulnerabilities. 308The preferred resolution is to resolve the problem on the programming level, by upgrading the 309application or by making changes to the source code. However, there are many instances in which 310this is not possible: 311 • The source code is not available. 312 • The vulnerability exists in a legacy application, which is very difficult to fix. 313 • The organization does not posses the resources to fix the error in timely manner. 314Even in the cases where there is a genuine will to fix the problem in code, some time may pass 315before the fix is actually deployed. This is often unacceptable. 316The purpose of the Protect element is to provide means to neutralize vulnerabilities on the HTTP 317level, i.e. with no access to the application source code. This is possible because the interactions 318between web clients (e.g. browsers) and web applications are carried out in a manner similar to that 319of function invocation in programming languages. Special devices, called web application firewalls, 320can intercept these function invocations, analyze the parameters, and decide whether the request is 321an attack. The Protect element serves to specify the tests needed to determine if a request is valid, 322or if it constitutes an attack against the application. 323The following usage scenarios are envisioned for the Protect element: 324 • A routine web vulnerability scan discovers a known problem in the application. The Protect 325 rule for the problem was previously designed by the (web vulnerability scanner) vendor. 326 The scanning tool communicates with the web application firewall to apply the rule. 327 • Problem is discovered during manual inspection. The web application administrator can 328 design a custom rule to protect the application from attacks. 329 • The deployed web application firewall is aware of the ready-made products running, and it 330 also knows their versions. When a problem is reported the vendor creates a Protection rule, 331 which is then propagated to the web application firewall installations through an automatic 332 update mechanism. The rule is therefore installed automatically. 333 10evdl-01-draft3806.doc Page 10
  • 11. 334 3353 EVDL Database and Transport 336 3374 Examples 338 339The following examples illustrate typical usage of EVDL in different security domains. For the sake 340of brevity, only relevant sections of examples are shown here. Complete sample EVDL instances 341can be retrieved at http://www.evdl.net/latest/examples/ 342Examples are provided for several security domains. Some of them contain, in addition to the 343security domain specific section, a metadata and a profile section which provides generic 344vulnerability information. 345One example illustrates how security domain information can be provided without including 346metadata and profile section, by referring to an existing description via an ID. 347 3484.1 EVDL Instance with an Analysis Component 349 350For a complete example, please see http://www.evdl.net/latest/examples/example-sca-1.xml 351This example contains the optional metadata and profile components followed by source code 352analysis domain component “analysis”. 353<evdl> 354 <metaData> 355 … 356 </metaData> 357 <profile> 358 … 359 </profile> 360 <analysis> 361 … 362 </analysis> 363</evdl> 364 11evdl-01-draft3806.doc Page 11
  • 12. 3654.2 EVDL Instance with a Protect Component 366 367For a complete example, please see http://www.evdl.net/latest/examples/example-protect-1.xml 368This example contains the optional metadata and profile components followed by the protect 369component with rules that specify how the application should be protected. 370 371<evdl> 372 <metaData> 373 … 374 </metaData> 375 <profile> 376 … 377 </profile> 378 <recipe> 379 … 380 </recipe> 381</evdl> 382 383 3844.3 Protect Component Example with Referenced Metadata 385 386For a complete example, please see http://www.evdl.net/latest/examples/example-protect-by- 387ref-1.xml 388This example doesn’t contain the optional metadata and profile but instead references their 389description by ID of another document. Therefore it contains only protect component under the root 390EVDL element: 391<evdl> 392 <recipe id="magnolia-9E9BC8AD2338EBBBF6986C4255409A6D"> 393 <ruleSet stage="requestHeaders" action="error" condition="and"> 394 … 395 3964.4 EVDL Instance with a Detect Component 397Peter: complete once detect component finalized 12evdl-01-draft3806.doc Page 12
  • 13. 3985 Extending EVDL to new security domains. 399 400EVDL proposes to support embedding documents that support new application security domains 401and define new application security domain schema descriptions in the future. 402A necessary condition to include new schemas would be if developers of security domains use 403EVDL metadata and profile in a manner similar to example 2.5 and thus avoid duplication of 404generic security constructs used in metadata (including ID, license, history) and profile (including 405classification i.e. vulnTypes and riskRanking). 406 407 4086 Appendix A. Acknowledgements 409The WAS Technical Committee would like to acknowledge other efforts for standardization of 410application vulnerabilities, most notable work done by AVDL TC and 411And OVAL board at Mitre Corporation, as well as pioneering work done by OWASP, including 412VulnXML whose continuation was one of the impulses of creating this WAS TC. EVDL has built 413upon earlier standardization efforts and will evolve with other standards in mind. 4147 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 415 4168 Appendix C. Notices 417OASIS takes no position regarding the validity or scope of any intellectual property or other rights 418that might be claimed to pertain to the implementation or use of the technology described in this 419document or the extent to which any license under such rights might or might not be available; 420neither does it represent that it has made any effort to identify any such rights. Information on 421OASIS's procedures with respect to rights in OASIS specifications can be found at the OASIS 422website. Copies of claims of rights made available for publication and any assurances of licenses to 423be made available, or the result of an attempt made to obtain a general license or permission for 13evdl-01-draft3806.doc Page 13
  • 14. 424the use of such proprietary rights by implementers or users of this specification, can be obtained 425from the OASIS Executive Director. 426 427OASIS invites any interested party to bring to its attention any copyrights, patents or patent 428applications, or other proprietary rights that may cover technology that may be required to 429implement this specification. Please address the information to the OASIS Executive Director. 430 431Copyright © OASIS Open 2004. All Rights Reserved. 432 433This document and translations of it may be copied and furnished to others, and derivative works 434that comment on or otherwise explain it or assist in its implementation may be prepared, copied, 435published and distributed, in whole or in part, without restriction of any kind, provided that the above 436copyright notice and this paragraph are included on all such copies and derivative works. However, 437this document itself does not be modified in any way, such as by removing the copyright notice or 438references to OASIS, except as needed for the purpose of developing OASIS specifications, in 439which case the procedures for copyrights defined in the OASIS Intellectual Property Rights 440document must be followed, or as required to translate it into languages other than English. 441 442The limited permissions granted above are perpetual and will not be revoked by OASIS or its 443successors or assigns. 444 445This document and the information contained herein is provided on an “AS IS” basis and OASIS 446DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO 447ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY 448RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 449PARTICULAR PURPOSE. 14evdl-01-draft3806.doc Page 14

×