The Common Weakness Enumeration Initiative

The Common Weakness Enumeration (CWE) is an extension of the Common Vulnerabilities and Exposures (CVE) list compiled by MITRE, a federally-funded, non-profit organization that manages research and development centers supporting government agencies like Homeland Security. MITRE was founded in 1958 and feeds the National Vulnerability Database (NVD) its listing of CVEs. The CVE list is built by assigning a potential security vulnerability with an identifier. Then that vulnerability is assigned a number from the MITRE-managed CVE Numbering Authority before it is publicly published. The CVE list launched in 1999 and evolved to the CWE over half a decade later to include the more specific categorizations of weaknesses that make up those vulnerabilities so companies can better understand what software weaknesses may exploit their computer systems.

The CWE and its Importance

CWE is an enumeration (list) of software architecture, design, or code weaknesses. Weaknesses are defined as flaws, bugs, faults, or other errors, that create vulnerabilities that can be exploited by both internal and external forces. Weaknesses can be found in software implementation, code, design, and architecture.

The CWE list began as a community-based initiative in 2005 to serve as a common baseline for concisely describing software weaknesses. Once the weaknesses are identified, companies can implement measurable security tools to identify, mitigate and prevent exploitation of their computer systems, arguably the life-blood of any 21st-century enterprise. This becomes especially important as more companies migrate to cloud computing.

Although CWE serves as a common standard for software weakness identification, according to the NVD, “CWE is not currently part of the Security Content Automation Protocol (SCAP). NVD is using CWE as a classification mechanism that differentiates CVEs by the type of vulnerability they represent.” Simply put, many governmental and private company entities rely on the CWE for “across-the-board” uniform information, but it is not utilized on all lists and protocols.

It is necessary and important that the CWE list use standardized language and identification to provide consistent and accurate data–much like any ISO-type standardization. CWE operates on that same principle to make its information accessible worldwide. Access to the CWE is free and is available with no worldwide constraint to everyone from researchers to developers to home PC enthusiasts.

Current CWE Information

The current CWE list version is 2.11 with 705 listed CWEs. The weakness list changes as the CWE community maintains the list. The CWE community initiative currently engages 50 to 60 companies and their representatives or researchers that use their knowledge, interests, and expertise to develop the list and its definitions of specific weakness types. This ensures that each weakness is as completely defined as possible.

Some common CWE weakness definitions include:

• improper input validation
• broken or risky algorithm (code)
• structure and validity issues
• cross-site scripting
• information exposure and insufficient data verification
• user interface and authentication errors

Some definitions note thousands of vulnerability reports, while others have single or few reports. As weaknesses are eliminated, they can fall off the list. However, past lists are archived so anyone can find prior information on specific weaknesses.

Navigating the CWE information is made easier by the use of its 3-tiered approach to its informational hierarchy. Still, to the home computer user, the site may seem teeming with information and somewhat overwhelming. But once you understand its structured process, you will begin to navigate more easily.

A Brief Overview of the CWE Process

The CWE strives for simplicity and unification among various software metrics. Its purpose is to provide a taxonomy and structure that leverages information among worldwide audiences. Like companies that engage ISO standards and certification, security tools and service providers can utilize the “CWE Compatibility” designation to show that they have their own CWE needs to be covered. According to CWE, the list and classification trees are constructed “for maximum comprehensive coverage across appropriate conceptual, business, and technical domains.” In other words, the process endeavors to bring diverse, real-world solutions to known software weaknesses to mitigate enterprise and government software system exploitation.

The approach to that initiative operates on three levels:

Tier 1: examines broad classes of information specifically for discussion by researchers, academics, vendors, and enterprise management persons–notably using a high-level development and research view

Tier 2: more concise definitions designed for IT teams, software developers, legal personnel and security experts

Tier 3: the free CWE list in its entirety for anyone interested in its information, including tool vendors and other researchers

CWE employs several tools to help address software issues, including a common weakness scoring system, a common weakness risk analysis framework, the CWE/SANS Top 25 Most Dangerous Software and CWE Coverage Claims Representation. Because its process is necessarily hierarchical and structured, the CWE directly impacts both government and business entities providing transitional mapping opportunities among various software lists. Every CWE update has a .pdf that provides the information on current weaknesses and how to use symbols to flow through the hierarchy of data.

The CWE Hierarchy

The CWE must observe a structured hierarchy to keep its database searchable, simplified, and functional. The list uses specific symbols to represent its hierarchical structure:

• View
• Category
• Weakness by Class
• Weakness by Base
• Weakness by Variant
• Compound Element (Composite)
• Compound Element (Named Chain)
• Deprecated Weaknesses

These symbols can be seen here. The structure begins at the root of the weakness and branches out into the specifics that further flow into testing, code structure, and whether the weakness is malicious or intentional. It further branches into data handling, security features, and process controls. By following the hierarchy, you can quickly find how the weaknesses are being handled and how they might affect your computer system so that you do not duplicate effort or needless dip into your operational budget.

The Bottom Line: Compatibility and Security

Companies utilizing the CWE must look at both software and hardware architecture, compatibility with the enterprise’s current system, and the software’s scalability before deciding to buy it. Knowing what weaknesses there are before buying the software saves company and government entities time and money while mitigating security risks.

Can your software be exploited despite the efforts of the CWE community initiative? Nothing is failsafe. However, the benefits outweigh the risks, according to MITRE. Software weaknesses are already identified, many times early in their lifecycle. Those weaknesses can then be fixed earlier than later, further reducing risk in future iterations.