Font Size Change

HOMEIT SecurityMeasures for Information Security VulnerabilitiesIPA/ISEC:Vulnerabilities:CWE (Common Weakness Enumeration) Overview

PRINT PAGE

IT Security

IPA/ISEC:Vulnerabilities:CWE (Common Weakness Enumeration) Overview

A list of software weakness types to provide a common language for identifying the type of vulnerability

Last updated : August 5, 2009
IT Security Center
Information-technology Promotion Agency, Japan
>> JAPANESE

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:

  1. Have a common language to discuss software vulnerability in architecture, design and code.
  2. Use as a standard measuring rule for security tools, such as a vulnerability scanning tool, to enhance software security.
  3. 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.

1.CWE Structure

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.

(1)View

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.

(2)Category

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.

(3)Weakness

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.

(4)Compound Element

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.
http://cwe.mitre.org/compatible/organizations.html

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

Requirement
Capability
Fulfillment Method

CWE
Searchability

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
Output

JVN iPedia

CWE identifiers are displayed in the “References” section within each vulnerability countermeasure information pages.

MyJVN

CWE identifier is displayed in the “Advisory, related information” section of the detailed information window of each vulnerability countermeasure information.

CWE
Documentation

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.

Mapping
Accuracy

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.

 

Figure 1 shows a hierarchical structure of weakness types to be used by JVN iPedia. It is based on Development View with Abstractions Highlighted, which is a graph that depicts the hierarchical structure of a View organized from the perspective of developers.

The yellow-colored ones are to be used by JVN iPedia. For the overall hierarchical structure of the CWE List, please refer to PDFs with Graphical Depictions of CWE (1.5).

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.

Figure1. Weakness Used by JVN iPedia

Figure1. Hierarchical Structure of Weakness Types Used by JVN iPedia

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.

Table 2. Weakness Types Used by JVN iPedia

#

CWE-ID

Name

Description

1

CWE-16

Configuration Weaknesses in this category are typically introduced during the configuration of the software.

2

CWE-20

Improper Input Validation The product does not validate or incorrectly validates input that can affect the control flow or data flow of a program.

3

CWE-22

Path Traversal 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.

4

CWE-59

Link Following The software attempts to access a file based on the filename, but it does not properly prevent that filename from identifying a link or shortcut that resolves to an unintended resource.

5

CWE-78

OS Command Injection 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.

6

CWE-79

Cross-site scripting (XSS) The software does not sufficiently validate, filter, escape, and encode user-controllable input before it is placed in output that is used as a web page that is served to other users.

7

CWE-89

SQL Injection The software constructs all or part of an SQL command using externally-influenced input from an upstream component, but it does not sanitize or incorrectly sanitizes special elements that could modify the intended SQL command when it is sent to a downstream component.

8

CWE-94

Code Injection The product does not sufficiently filter code (control-plane) syntax from user-controlled input (data plane) when that input is used within code that the product generates.

9

CWE-119

Failure to Constrain Operations within the Bounds of a Memory Buffer (Buffer Errors) The software may potentially allow operations, such as reading or writing, to be performed at addresses not intended by the developer.

10

CWE-134

Uncontrolled Format String The software uses externally-controlled format strings in printf-style functions, which can lead to buffer overflows or data representation problems.

11

CWE-189

Numeric Errors Weaknesses in this category are related to improper calculation or conversion of numbers.

12

CWE-200

Information Exposure (Information Disclosure/
Information Leak)
An information exposure is the intentional or unintentional disclosure of information to an actor that is not explicitly authorized to have access to that information.

13

CWE-255

Credentials Management Weaknesses in this category are related to the management of credentials.

14

CWE-264

Permissions, Privileges, and Access Controls Weaknesses in this category are related to the management of permissions, privileges, and other security features that are used to perform access control.

15

CWE-287

Improper Authentication When an actor claims to have a given identity, the software does not prove or insufficiently proves that the claim is correct.

16

CWE-310

Cryptographic Issues Weaknesses in this category are related to the use of cryptography.

17

CWE-352

Cross-Site Request Forgery (CSRF) The web application does not, or can not, sufficiently verify whether a well-formed, valid, consistent request was intentionally provided by the user who submitted the request.

18

CWE-362

Race Condition The code requires that certain state should not be modified between two operations, but a timing window exists in which the state can be modified by an unexpected actor or process.

19

CWE-399

Resource Management Errors Weaknesses in this category are related to improper management of system resources.

20

CWE-Other

No Mapping JVN iPedia is only using a subset of CWE for mapping instead of the entire CWE, and the weakness type is not covered by that subset.

21

CWE-nocwe

No Mapping The weakness type is not covered in the version of CWE that was used for mapping.

22

CWE-noinfo

No Mapping There is insufficient information about the issue to classify it; details are unknown or unspecified.

23

CWE-
DesignError

No Mapping A vulnerability is characterized as a “Design error” if there exists no errors in the implementation or configuration of a system, but the initial design causes a vulnerability to exist.

Footnote

(*1)CWE: Common Weakness Enumeration.
http://cwe.mitre.org/index.html

(*2)MITRE Corporation: A not-for-profit organization that provides information technology support and R&D development to the U.S. government.
http://www.mitre.org/

(*3)NIST: National Institute of Standards and Technology. A federal agency that develops and promotes measurement, standards and technology.
http://www.nist.gov/

(*4)NVD: National Vulnerability Database. A vulnerability database run by NIST.
http://nvd.nist.gov/

(*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.
http://www.owasp.org/

(*6)OWASP Top Ten Project: A security awareness promotion with which OWASP picks top ten of the most critical Web application security vulnerabilities.
http://www.owasp.org/index.php/OWASP_TOP_TEN_PROJECT

(*7)JVN iPedia Upgraded to New Version.
http://www.ipa.go.jp/security/english/vuln/200809_JVN_iPedia_en.html

(*8)Filtered Vulnerability Countermeasure Information Tool “MyJVN” Now Available.
http://www.ipa.go.jp/security/english/vuln/200810_MyJVN_en.html

Filtered Vulnerability Countermeasure Information Tool “MyJVN” English Version Released.
http://www.ipa.go.jp/security/english/vuln/200901_myjvn_english_en.html

Reference

Contact

IT Security Center,
Information-technology Promotion Agency, Japan (ISEC/IPA)
E-mail:

Last Updated

Aug 5, 2009
Adopt CWE 1.5
Jun 3, 2009
Adopt CWE 1.4
Sep 10, 2008
Release