CWE (Common Weakness Enumeration)(*1) aims to provide a common base to identify the type of software weakness (vulnerability).
Leading the effort with support from the U.S. government, MITRE(*2) had been working on a specification since 1999 and published the first draft in March 2006. More than 40 vendors and research entities have joined hands to improve and expand the specification since then and the version 1.0 of CWE was published on September 9, 2008.
CWE gives a hierarchically structured list of weakness types to help identifying software vulnerabilities that come in a wide variety, such as SQL injection, cross-site scripting and buffer overflow. The use of CWE will enable software developers and security experts to:
Have a common language to discuss software vulnerability in architecture, design and code.
Use as a standard measuring rule for security tools, such as a vulnerability scanning tool, to enhance software security.
Use as a common foundation to understand, mitigate and prevent vulnerability.
CWE has been adopted by NIST(*3) for NVD(*4), OWASP(*5) for Top Ten Project(*6) and other security vendors.
This overview is based on CWE Version 1.5, released by MITRE. For more information, please refer to MITRE CWE List.
CWE organizes a wide variety of weakness types in a hierarchical structure and gives a unique identifier (CWE-ID) to each type. The weakness types at higher levels in the structure gives a more abstract and broader concept, while those at deeper level gives a more concrete concept or represent an actual CWE entity.
There are four structural classifications in CWE: View, Category, Weakness and Compound Element. Currently, 22 weakness types are classified as View, 105 as Category, 638 as Weakness and 12 as Compound Element. In total, 777 CWE entries are defined and organized in the list.
Each View entry represents a perspective with which one may use CWE and organizes weakness types from the perspective. For example, NIST has handpicked 19 weakness types from CWE based on the vulnerabilities published on NVD and lists them on its Web site (CWE Cross Section Mapped into by NVD). The View that consists of those 19 weakness types is being given the CWE-ID of CWE-635, Weaknesses Used by NVD.
Likewise, CWE-699 is the View organized from the perspective of developers, CWE-1000 from that of researchers, CWE-658 from that of C and CWE-660 from that of Java.
Each Category entry, given a “grouping” capability, represents a collection of weakness types that share a common characteristic.
For instance, CWE-310 is a group of weakness types with cryptographic issues and CWE-355 with user interface issues.
Each Weakness entry represents an actual CWE entity and is subsequently classified using three attributes: Class, Base and Variant.
The Class attribute suggests the most abstract type of weakness of the three. CWE-362, Race Condition, is an example of this type.
The Base attribute suggests a more specific type of weakness that is independent of specific technology or resource. CWE-567, Unsynchronized Access To Shared Data, is an example of this type.
The Variant attribute suggests a specific type of weakness that is dependent of particular resource, technology or context. CWE-488, Data Leak Between Sessions, is an example of this type.
Each Compound Element entry represents an aggregation of related weakness types with a composite nature and is subsequently classified using two attributes: Composite and Chain.
The Composite attribute suggests a case where a weakness emerges in combination of another weakness. CWE-352, Cross-Site Request Forgery, is an example of this type.
The Chain attribute suggests a case where a weakness results in another weakness. CWE-680, Integer Overflow to Buffer Overflow, is an example of this type.
2.Elements of CWE
The CWE List is organized by CWE-ID and each CWE entry is provided with various information. To name a few, the CWE elements include Description, Likelihood of Exploit, Common Consequences, Potential Mitigations, Demonstrative Examples and Observed Example.
Users could use the CWE List as reference to identity, mitigate and prevent vulnerabilities.
3.JVN iPedia declared CWE-Compatible
JVN iPedia began to support CWE as a trial on September 10, 2008(*7). IPA had worked on a few remaining requirements to make a CWE compatibility declaration and declared it CWE-Compatible on October 3, 2008.
The official list of organizations participating in the CWE Compatibility and Effectiveness Program is available on Mitre’s CWE web site.
MyJVN began to support CWE on October 23, 2008(*8).
The four mandatory requirements – “CWE Searchability”, “CWE Output”, “CWE Documentation” and “Mapping Accuracy” – for phase 1 are fulfilled by the functions illustrated in Table 1.
Table 1. Requirement Correspondence Status of JVN iPedia and MyJVN
JVN iPedia, MyJVN
By using the search function in JVN iPedia, the vulnerability countermeasure information database, users are able to conduct a search using CWE identifiers as the keyword.
CWE identifiers are displayed in the “References” section within each vulnerability countermeasure information pages.
CWE identifier is displayed in the “Advisory, related information” section of the detailed information window of each vulnerability countermeasure information.
JVN iPedia, MyJVN
This material document will become the documentation necessary to describe and demonstrate CWE, CWE association and methods used to satisfy the compatibility requirements.
JVN iPedia, MyJVN
By setting a JVN iPedia ID in the sec:identifier field of JVNDBRSS, which is used to specify the identifier of the security information, and storing the JVN ID and CWE identifier in the sec:reference field, which are used to specify the URL of the related security information, it is possible to demonstrate the correspondence of the JVN iPedia ID with the CWE identifier.
IPA will revise the weakness types, analyzing the vulnerabilities published on JVN iPedia, and consider expanding them to include the deeper level of weakness types to support frequently-reported vulnerabilities.
4.Weakness Types Used by JVN iPedia
Table 2 is a list of weakness types to be used by JVN iPedia.
From #20 to #23 are weakness types not classifiable by CWE-635, #20 corresponds to a CWE other than CWE-635, #21 is not classifiable by CWE, #22 needs more information to determine and #23 is about design problem.
The software uses external input to construct a pathname that should be within a restricted directory, but it does not properly sanitize special elements that can resolve to a location that is outside of that directory.
The software constructs all or part of an OS command using externally-influenced input from an upstream component, but it does not sanitize or incorrectly sanitizes special elements that could modify the intended OS command when it is sent to a downstream component.
The software constructs all or part of an SQL command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended SQL command when it is sent to a downstream component.
The software constructs all or part of a code segment using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the syntax or behavior of the intended code segment.
#9 Improper Restriction of Operations within the Bounds of a Memory Buffer (Buffer Errors)
Weaknesses in this category are related to the design and implementation of data confidentiality and integrity. Frequently these deal with the use of encoding techniques, encryption libraries, and hashing algorithms. The weaknesses in this category could lead to a degradation of the quality data if they are not addressed.
The program contains a code sequence that can run concurrently with other code, and the code sequence requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another code sequence that is operating concurrently.
(*2)MITRE Corporation: A not-for-profit organization that provides information technology support and R&D development to the U.S. government.
(*3)NIST: National Institute of Standards and Technology. A federal agency that develops and promotes measurement, standards and technology.
(*4)NVD: National Vulnerability Database. A vulnerability database run by NIST.
(*5)OWASP: Open Web Application Security Project. An open, not-for-profit community dedicated to enhancing software security by developing open source software to secure Web applications and Web sites and promoting software security.