Common Weakness Enumeration

CWE Glossary Definition

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.

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 CWRAF, 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.