CWE Glossary Definition

The Common Weakness Risk Analysis Framework (CWRAF) provides a means for software developers and consumers to prioritize software weaknesses that are relevant for their business, mission, and deployed technologies. In certain circumstances, a software weakness can lead to an exploitable vulnerability. By providing a repeatable way to customize the Common Weakness Scoring System (CWSS), CWRAF enables people to reason and communicate about the relative importance of different weaknesses. Users can automatically generate a more targeted specification of "Top-N" lists of weaknesses that are the most critical for the software that is used in the relevant business domains, missions, and technology groups. In conjunction with other activities, CWRAF ultimately helps developers and consumers to introduce more secure software into their operational environments.

CWRAF provides a framework for scoring weaknesses in a consistent, flexible, open manner, while accommodating context for the various business domains. It is a collaborative, community-based effort that is addressing the needs of its stakeholders across government, academia, and industry. CWRAF is a part of the Common Weakness Enumeration (CWE) project, co-sponsored by the Software Assurance program in the National Cyber Security Division (NCSD) of the US Department of Homeland Security (DHS).

CWRAF:

• includes a mechanism for measuring risk of weaknesses in a way that is closely linked with the risk to the business or mission
• supports the automatic selection and prioritization of relevant weaknesses, customized to the specific needs of the business or mission
• in conjunction with the Common Weakness Scoring System (CWSS), can be used by consumers to identify the most important weaknesses for their business domains, in order to inform their acquisition and protection activities as one part of the larger process of achieving software assurance.

CWRAF and CWSS allow users to rank classes of weaknesses independent of any particular software package, in order to prioritize them relative to each other (e.g. "buffer overflows are higher priority than memory leaks"). This approach, sometimes referred to as a "Top-N list," is used by the CWE/SANS Top 25, OWASP Top Ten, and similar efforts. CWRAF and CWSS allow users to create custom Top-N lists.

• Stakeholders
• Framework Overview
  • Relationships between CWRAF, CWSS, and CWE
• Modeling the Environment: Business Domains, Technology Groups, Archetypes, and Vignettes
  • Technology Groups and Business Domains
  • Business Domains
  • Technology Groups and Archetypes
  • Vignettes
  • Business Value Context (BVC)
  • Technical Impact Scorecard
  • Vignette Examples
• Customizing CWRAF
• CWSS Scoring in CWRAF
• Technical Impact Scorecard: Linking Business Value with Weaknesses
  • Enumeration of Technical Impacts
  • Example - Technical Impact Scorecard
  • Calculating the CWSS Impact Weights using the Scorecard
  • Technical Impacts for CWE Entries
  • Example - Variation between Vignettes for Technical Impact Scorecards
  • Calculating the CWE-specific Technical Impact Subscore
• Scoring Weakness Findings using Vignettes
• Automatically Building Custom Top-N Lists
  • Considerations for Future CWRAF Versions
• Creating Your own Vignettes
• Future Activities
• Community Participation in CWRAF
• Change Log

CWRAF is designed to support stakeholder needs throughout the software lifecycle. However, the applicability of CWRAF extends beyond the design and development of software. CWRAF can be used to support Supply Chain Risk Management (SCRM) by giving software acquirers a means to define the software weaknesses that they deem most critical. CWRAF can also support the prioritization of training and education based on the unique needs of a business sector or organization.

To be most effective, CWRAF supports multiple usage scenarios by different stakeholders who all have an interest in a consistent scoring system for prioritizing software weaknesses that could introduce risks to products, systems, networks and services. Some of the primary stakeholders are listed below.

The high-level concepts in the Common Weakness Risk Analysis Framework are highlighted below. Complete technical details are provided in later sections.

(A larger picture is available.)

A business domain is a major function or service that includes the operations and interactions of a broad range of networked capabilities or organizations, such as Banking & Finance, Public Health, and e-Commerce.

Within a business domain, a vignette provides a shareable, semi-formal description of a scenario that identifies a set of connected technology groups that collectively perform a function within a business domain. For example, a vignette in the e-Commerce domain may identify a retail-based web store that uses web applications and a database for customers to purchase various products and services.

The scoring of weaknesses in an application is influenced by the business domain in which the application runs.

CWSS scoring is performed within the context of a vignette, which defines:

• a description of a system (or system-of-systems) that implement a business function using "technical archetypes" from various Technology Groups, such as web applications, industrial control systems, etc.
• a Business Value Context (BVC), which identifies the primary security concerns for deployed software that is covered by the vignette. The BVC describes potential harm that could occur to the business or mission if any weaknesses can be successfully exploited by an attacker, such as compliance failure, loss of reputation, or ecological disaster.
• a Technical Impact Scorecard, which lists the potential low-level effects of weakness exploitation (e.g., code execution or system crash) and ranks or prioritizes these impacts based on how they affect the performance of the business function being identified by the vignette.

Using the Business Value Context and the Technical Impact Scorecard, CWRAF provides vignette-specific input to the Common Weakness Scoring System (CWSS), which can then be used to prioritize which weaknesses are of greatest concern and ideally must be addressed first.

Relationships between CWRAF, CWSS, and CWE

The following image summarizes the relationships between CWRAF, CWSS, and CWE:

(A larger picture is available.)

Each business or enterprise has different priorities, threat environments, and risk tolerance. This makes the development and application of a standardized scoring mechanism difficult, because the assumptions of the mechanism may not match those of the enterprise that is applying the scoring.

CWRAF attempts to minimize this difficulty by allowing users to model environment-specific considerations within the framework. These considerations are then reflected in the formulas that produce customized CWSS scores, which can then be used to identify which weaknesses are most important.

The environment-specific modeling dimension of CWRAF consists of the following major concepts:

Technology Groups and Business Domains

The following table highlights the kinds of technology groups and business domains that are being investigated using CWRAF. Note that a vignette can cross multiple domains (e.g., the use of end-point computing devices in Shipping & Transportation, Public Health, Homeland Security, etc.) A vignette can also utilize multiple technology groups within a single domain such as Energy, in which the Smart Grid uses many different groups.

An up-to-date version of this matrix highlights which vignettes have been defined and are under active development.

Note: CWRAF users are not restricted to using such large-scale domains and technology groups. CWRAF can be customized with user-defined domains, technology groups, and vignettes.

(A larger picture is available.)

Business Domains

Within CWRAF, a business domain typically covers a major industry or sector that includes the operations, processes, and interfaces for a broad range of connected organizations, capabilities, or services that are enabled or controlled by software and require some degree of resilience and security in transactions and operations. Information and communication technologies (ICT) cut across all domains.

Following is an example list of business domains. This list is being actively reviewed and modified. The full, up-to-date list of domains is provided in more detail on a separate page.

Technology Groups and Archetypes

Within CWRAF, a "technical archetype" is a class of technical capability, system (or system-of-systems), or architecture that is commonly used to support the mission of an organization. Examples include a web application, web server connected to a database; Service-Oriented Architecture; Real-time, Embedded Device; end-point computing devices (such as a Smartphone); process control system (such as SCADA); etc. A technical archetype may be used within different business domains. For example, SCADA systems are used in Energy, Chemical, and other domains; and many industries manage their information using database-connected web servers.

Technical archetypes can be used in multiple business domains, and certain archetypes may inherit certain classes of weaknesses. For example, a web-based archetype may always have cross-site scripting (XSS) as a concern. However, an archetype may have varying importance depending on the business context. For example, a database archetype that contains a retail customer's financial information and order history may have different security concerns than a database that contains sports statistics that are intended to be read by anyone.

Note that the definitions and usage of archetypes are still under review, and this concept may change in future versions of this paper. They do not play an explicit role in CWRAF 0.8, although this may change in future versions.

Following is an example list of archetypes categorized by their technology group. This list is being actively reviewed and modified. The full, up-to-date list is provided in more detail on a separate page.

Vignettes

A vignette provides a shareable, formalized way to define a particular environment within a business domain. It includes the role that software archetypes play within that environment, and an organization's priorities with respect to software security. It identifies essential resources and capabilities, as well as their importance relative to security principles such as confidentiality, integrity, and availability. For example, in an e-commerce context, 99.999% uptime may be a strong business requirement that drives the interpretation of the severity of discovered weaknesses.

Vignettes allow CWRAF to support diverse audiences who may have different requirements for how to prioritize weaknesses. CWSS scoring occurs within the context of a vignette.

Business Value Context (BVC)

An important part of a vignette is the Business Value Context (BVC). The BVC contains two main parts:

• (1) a general description of the security-relevant archetypes, assets, and interfaces that are of concern to the business domain
• (2) the security priorities of the business domain with respect to the potential outcomes that could occur if those archetypes are successfully attacked.

Technical Impact Scorecard

A Technical Impact Scorecard connects the business concerns in the BVC with the possible technical impacts that could happen if an attacker can successfully exploit the weakness, such as code execution, reading of sensitive application data, or a software crash. For each potential technical impact, the scorecard assigns a subscore and provides a rationale for the assignment of the subscore. When a CWSS score is calculated for a weakness, the data from the Technical Impact Scorecard is used to influence the score to reflect the requirements as described in the BVC.

Vignette Examples

A selection of example vignettes is presented below. These vignettes were selected to represent diverse communities and use cases. Note that these vignettes are subject to change or removal based on community review. A more extensive, up-to-date list of vignettes is provided on a separate page.

Note that the Technical Impact Scorecard is omitted from this example for the sake of brevity; more details are available in a later section.

In addition to a summary, each vignette is annotated with additional, lower-level details that can be used to describe how the technical aspects of weaknesses relate to the business or mission-level requirements. These details are discussed in another section.

Disclaimer: these vignettes are in the early stages of development and are intended primarily to demonstrate the concept. They are subject to review and feedback, and they may be modified. An up-to-date list of vignettes is on a separate page.

Organizations can customize CWRAF to define their own domains, vignettes, etc. For example, an e-Commerce company could use Domains to divide a software package into different processes, then use vignettes to identify the most important functional components:

(A larger picture is available.)

The Common Weakness Scoring System (CWSS) provides a mechanism for scoring weaknesses in a consistent, flexible, open manner, which accommodating context for the various business domains or vignettes. It is independent of CWRAF. However, CWRAF takes advantage of CWSS' flexibility in order to define vignette-specific ways of customizing CWSS scores.

A vignette provides a mechanism for calculating CWSS scores that reflect the context for prioritization, as encoded within the Technical Impact Scorecard of the vignette.

Enumeration of Technical Impacts

Each weakness, if successfully exploited, can lead to one or more potential Technical Impacts:

• Modify data
• Read data
• DoS: unreliable execution
• DoS: resource consumption
• Execute unauthorized code or commands
• Gain privileges / assume identity
• Bypass protection mechanism
• Hide activities

Note that some of these items are abstractions of the technical impact enumeration used in CWE 2.0, which includes values such as Modify memory, Read application data, memory consumption, etc. Such values are overly specific with limited flexibility, which was addressed in CWSS and CWRAF 0.4 by using layers.

Within CWRAF and CWSS, the successful exploitation of a weakness could have varying impacts at four different "layers":

• System - The entity has access to, or control of, a system or physical host.
• Application - The entity has access to an affected application.
• Network - The entity has access to/from the network.
• Enterprise - The entity has access to a critical piece of enterprise infrastructure, such as a router, DNS, etc.

The user then evaluates all possible combinations of Technical Impact and Impact Layer (32 possibilities in CWSS 0.8) and captures the analysis within the Technical Impact Scorecard, which contains the following information:

Example - Technical Impact Scorecard

The following table shows a subset of Technical Impacts, along with hypothetical subscore evaluation, which might be used in a vignette for a Web-based e-commerce site (the "Web-based Retail Provider" vignette).

Calculating the CWSS Impact Weights using the Scorecard

For each weakness (or weakness finding) or interest, the weakness is scored as follows:

• 1) For each relevant CWE entry, extract its potential Technical Impacts. These are specified within the Common_Consequences element.
• 2) For each Technical Impact that is listed in the relevant CWE entry:
• 3) If the Layer is known (e.g., it is a specific weakness finding in a particular software package), then look for the line item that has the same Layer and Technical Impact, and use its Importance rating.
• 4) If the Layer is unknown (e.g., if a weakness is being given a general score), then search all line items that have the same Technical Impact, and use the maximum subscore of all the items, regardless of the layer being used.
• 5) calculate the CWSS Impact factor using the subscore from step 4 (i.e, use Quantified weighting instead of the pre-defined values for the Impact)

The approach is roughly as follows:

(A larger picture is available.)

Using this method, a vignette defines the criteria for establishing the relative importance of weaknesses relative to their Technical Impact, e.g. whether the weakness can allow an attacker to read application data, execute code, or cause a software crash.

Since there are more than 800 entries in CWE, it would be resource-intensive for analysts to evaluate each CWE for a vignette. The list of technical impacts is much smaller (8 as of CWRAF 0.8, which are abstractions of 16 impacts as identified in CWE 1.12). So it is easier and faster for a human analyst to evaluate. In addition, it does not require detailed technical understanding of each weakness.

Note that the importance ratings are allowed to be 0. In many cases, the presence of a 0 rating in a Technical Impact Scorecard is probably an error. However, there may be some BVCs in which a particular impact has no security relevance at all. For example, a product might be single-user only, so the concept of "gaining privileges" at the System layer may not be relevant. Alternately, all data on the product may be intended to be readable by any user or outsider, rendering a 0 subscore for "read data" at the Application layer. While these scenarios may be rare, it seems reasonable to support them in CWRAF.

Technical Impacts for CWE Entries

Note that this list is likely to change in future CWE versions.

CWE-89 (SQL Injection) has three technical impacts as listed in the Common_Consequences element of the CWE entry:

• Read application data
• Modify application data
• Bypass protection mechanism

For CWE-120 (Classic Buffer Overflow), the listed technical impacts are:

• Execute unauthorized code or commands
• DoS: crash / exit / restart

Example - Variation between Vignettes for Technical Impact Scorecards

The following table demonstrates how Importance ratings can differ between different vignettes and business value contexts.

Assume that these Importance ratings are being assessed at the System layer.

Calculating the CWE-specific Technical Impact Subscore

Once the technical impact scorecard is filled in for a particular vignette, each CWE entry is described in light of the entry's technical impacts, as obtained from the Common_Consequences element. Note that this process can be automated.

In CWSS 0.3, the highest subscore is used as the Impact subscore for the CWSS score of any finding for the given CWE entry.

Note: a detailed breakdown of technical impacts for all Top 25 CWE entries is available on a separate web page.

One important use case for CWSS is to support the automatic scoring of findings that are generated from an automated code scanner or other tool. CWSS is independent of CWRAF; its Impact factor defines discrete values such as "High" and "Low."

However, vignettes can be used to customize CWSS scores that are generated for tool findings. The Impact factor can be quantified using methods that have been previously described.

(A larger picture is available.)

Using CWRAF, an organization can pre-select which CWE entries are of greatest interest - i.e., creating a custom Top-N list. For example, a vignette that is centered around a product search capability for an e-Commerce web site might be composed of a database, web client and server, and a mobile application.

A set of relevant CWE entries could be selected as follows:

The process of creating a custom Top-N list involves several steps.

Manual steps:

• 1) Select or manually define an appropriate vignette, including its Technical Impact Scorecard.
• 2) Select the set of relevant CWE entries (see previous image). This could be partially automated, or use a selection from elsewhere (e.g., the Top 25).
• 3) Identify which CWSS factors should be treated as Not Applicable (e.g., Remediation Cost)

Automatic steps:

• 4) for each relevant CWE entry, extract its potential Technical Impacts.
• 5) use the vignette's Technical Impact Scorecard to evaluate each Technical Impact that is part of the relevant CWE entry. Select the maximum available subscore, regardless of the affected layer.
• 6) calculate the CWSS Impact factor using the maximum available subscore (i.e, use Quantified weighting instead of the pre-defined values for the Impact)
• 7) perform the full CWSS calculation to obtain a general score for the CWE entry (using the "Not Applicable" factors from step 3)
• 8) Rank all relevant CWE entries according to their CWSS scores

The previous approach can be simplified as:

(A larger picture is available.)

Considerations for Future CWRAF Versions

In future versions of CWRAF, alternate methods of producing Impact subscores may be considered. For example, while buffer overflows can often be exploited for crashes or code execution, this is not always the case. As a result, it may be more informative to capture the "average" Impact.

In addition, a weakness may have a secondary impact that is more important to the business value context than any of its immediate impacts. For example, SQL injection allows modification of queries which then modify or read data, but in some cases it could be used to execute code (by modifying the SQL logic to invoke database functions or write files) or bypass authentication (if the associated SQL query logic can be modified to always return "true"). Currently, CWE does not distinguish between immediate and secondary impacts, and most of the associated CWE data concentrates on the primary impacts.

There is a risk to including secondary impacts. Many technical impacts are closely interrelated, having both transitive and commutative properties. For example, the ability to read a file could lead to gaining privileges if the file contains authentication credentials; on the reverse, gaining privileges will often give the attacker access to otherwise-restricted files. Or, the ability to execute code could allow an attacker to modify files; the ability to modify an executable file could allow an attacker to execute code. Because these kinds of relationships exist, extending the model to include secondary impacts would cause most weaknesses to have all possible technical impacts, which would remove the ability of the Impact subscore to distinguish between vulnerabilities. This is a hard problem for risk modeling within the information security industry, not just for CWSS and CWRAF.

On the Common Weakness Risk Analysis Framework (CWRAF) web site we have approximately 20

Vignettes and Technical Scorecards, but anyone can create their own Vignette and its accompanying Technical Scorecard so they to can identify which CWEs are most significant to their business and applications. This page will help guide you through that process.

One of the items found in these sample Vignettes is the Archetypes. A list of the currently defined Archetypes that are available for use in describing Vignettes is provided below. If there are new Archetypes you need just identify them and send them to cwe@mitre.org and we can add them to the list.

These Archetypes are used as the context for describing the technical elements utilized by the application described in the Vignette.

There are two tables for each Vignette: "Vignette Definition" and "Technical Impact Scorecard".

Creating a Vignette Definition basically comes down to filling in the Vignette Definition table. Below is an example Vignette Definition table with a specific Vignette for a Web-Based Retail Provider described. The Vignette Definition is meant to talk about what business issues are of concern for the application. Is the application dealing with PII? Credit card (PCI-relavent) data? How bad is each of the 8 Technical Impacts given what the application is doing for a business (in the business's operational context).

The Technical Impact Scorecard is the mechanism that allows for the creating the ranked list of the items under a vignette. Creating a Technical Impact Scorecard for a Vignette starts with the fact that each CWE can result in one or more types of failures or technical impacts.

The vignette is a context for scoring the 8 Technical Impacts at the 4 levels (application, system, network, and enterprise) that are then mapped into the CWEs that result in the specific Technical Impacts.

So assigning weights (1-10) to the 8 Technical Impacts by determining how "bad" these impacts are for a specific business case (which is captured by the vignette) is the first step, as denoted by the words "Once the technical impact scorecard is filled in for a particular vignette" that starts the "Calculating the CWE-specific Technical Impact Subscore" section.

So in the first table of this "Calculating the CWE-specific Technical Impact Subscore" section, the values in the "Technical Impacts and Importance Subscores" column come from the above vignette technical impact scoring effort and is being mapped to the Technical Impacts that the various CWEs have. The list of Technical Impacts that each CWE has is a part of the CWE data in CWE itself. Look for the "Common Consequences" field of a CWE and the "Technical Impact" portion and you will see (look at http://cwe.mitre.org/data/slices/900.html - the 2011 Top 25 CWE list - for examples).

The majority of the development and refinement of the first major version of CWRAF will occur during 2011. Current plans include:

• Engage communities of interest for creating new vignettes and refining the existing vignettes, including prioritization of technical impacts.
• Use a generalized, adapted version of CWSS and vignette selection within the 2011 Top 25, and the associated pocket guide for mitigating the Top 25.
• Define a data exchange representation for CWSS scores and vectors, e.g. XML/XSD.

Currently, members of the software assurance community can participate in the development of CWRAF in the following ways:

• Provide feedback on this document.
• Suggest and refine new vignettes, business domains, and BVCs. Review the definitions and associated weakness-oriented technical analyses for vignettes that have already been defined.
• Define specific use cases for CWRAF