CWE Glossary Definition

When a security analysis of a software application is performed, such as when using an automated code auditing tool, developers often face hundreds or thousands of individual bug reports for weaknesses that are discovered in their code. In certain circumstances, a software weakness can lead to an exploitable vulnerability. For example, a buffer overflow vulnerability might arise from a weakness in which the programmer does not properly validate the length of an input buffer. This weakness only contributes to a vulnerability if the input can be influenced by a malicious party, and if that malicious input can copied to an output buffer that is smaller than the input.

Due to the high volume of reported weaknesses, developers are forced into a situation in which they must prioritize which issues they should investigate and fix first. Similarly, when assessing design and architecture choices and their weaknesses, there needs to be a method for prioritizing them relative to each other and with the other issues of the application. Finally, software consumers want to know what they should worry about the most, and what to ask for to get a more secure product from their vendors and suppliers.

Further complicating the problem, the importance of a weakness may vary depending on business or mission needs, the kinds of technologies in use, and the threat environment.

In short, people need to be able to reason and communicate about the relative importance of different weaknesses. While various scoring methods are used today, they are either ad hoc or inappropriate for application to the still-imprecise evaluation of software security.

The Common Weakness Scoring System (CWSS) provides a mechanism 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. CWSS 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).

CWSS:

• provides a common framework for prioritizing security errors ("weaknesses") that are discovered in software applications
• provides a quantitative measurement of the unfixed weaknesses that are present within a software application
• can be used by developers to prioritize unfixed weaknesses within their own software
• in conjunction with the Common Weakness Risk Analysis Framework (CWRAF), 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.

• Stakeholders
• CWSS Design Considerations
• Scoring Methods within CWSS
• CWSS 0.6 Scoring for Targeted Software
  • Scoring
  • CWSS Metric Groups
• Supporting Uncertainty and Flexibility Within Factors
• Base Finding Metric Group
  • Technical Impact (TI)
  • Acquired Privilege (AP)
  • Acquired Privilege Layer (AL)
  • Internal Control Effectiveness (IC)
  • Finding Confidence (FC)
• Attack Surface Metric Group
  • Required Privilege (RP)
  • Required Privilege Layer (RL)
  • Access Vector (AV)
  • Authentication Strength (AS)
  • Authentication Instances (AI)
  • Level of Interaction (IN)
  • Deployment Scope (SC)
• Environmental Metric Group
  • Business Impact (BI)
  • Likelihood of Discovery (DI)
  • Likelihood of Exploit (EX)
  • External Control Effectiveness (EC)
  • Remediation Effort (RE)
  • Prevalence (P)
• CWSS Score Formula
  • Base Finding Subscore
  • Attack Surface Subscore
  • Environmental Subscore
  • Additional Features of the Formula
• CWSS Vectors, Scoring, and Score Portability
  • Example 1: Business-critical application
  • Example 2: Wiki with limited business criticality
  • Other Approaches to CWSS Score Portability
• Considerations for CWSS beyond 0.6
  • Current Limitations of the Scoring Method
  • Community Review and Validation of Factors
  • Additional CWSS Factors
  • Constituency-focused Scoring
  • Impact of CWSS and CWE Changes to Factors and Subscores
• Future Activities
• Community Participation in CWSS
• Appendix A: CVSS
  • CVSS in a Software Assurance Context
  • Adaptations of CVSS
  • Comparison of CWSS Factors with CVSS
  • Other Differences between CVSS and CWSS
• Appendix B: Other Scoring Methods
  • 2008 CWSS Kickoff Meeting
  • 2010 SANS/CWE Top 25
  • 2010 OWASP Top Ten
  • Other Models
• Appendix C: Generalized Scoring Approaches
  • Prevalence Assessment
• Appendix D: Aggregated Scoring Methods: Measuring Weakness Surface
• Change Log

To be most effective, CWSS 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.

For CWSS to be most effective to its stakeholders, several aspects of the problem area must be considered when designing the framework and metrics. Some of these considerations might not be resolved until several revisions of CWSS have been released and tested.

• CWSS scoring will need to account for incomplete information throughout much of the lifecycle of a reported weakness. For example, scoring may be necessary before the weakness is even known to contribute to a vulnerability, e.g. in the initial output from an automated code scanning tool. Second, the entity (human or machine) assigning the initial CWSS score might not have complete information available, e.g. the expected operating environment. Finally, some factors in the CWSS score might rely on trend information (such as frequency of occurrence) that is only estimated due to lack of sufficient statistical data. For example, the 2010 CWE Top 25 relied on survey results, because very few sources had prevalence data at the same level of detail as the weaknesses being considered for the list. Incomplete information is a challenge for CVSS scoring, and it is expected to be even more important for CWSS.
• It is assumed that portions of CWSS scores can be automatically generated. For example, some factors may be dependent on the type of weakness being scored; potentially, the resulting subscores could be derived from CWE data. As another example, a web script might only be accessible by an administrator, so all weaknesses may be interpreted in light of this required privilege.
• CWSS should be scalable. Some usage scenarios may require the scoring of thousands of weaknesses, such as defect reports from an automated code scanning tool. When such a high volume is encountered, there are too many issues to analyze manually. As a result, automated scoring must be supported.
• The potential CWSS stakeholders, their needs, and associated use cases should be analyzed to understand their individual requirements. This might require support for multiple scoring techniques or methods.
• Associated metrics must balance usability with completeness, i.e., they cannot be too complex.
• Environmental conditions and business/mission priorities should impact how scores are generated and interpreted.
• CWSS should be automatable and flexible wherever possible, but support human input as well.

The stakeholder community is collaborating with MITRE to investigate several different scoring methods that might need to be supported within the CWSS framework.

The current focus for CWSS is on the Targeted scoring method and a framework for context-adjusted scoring. Methods for aggregated scoring will follow. Generalized scoring is being developed separately, primarily as part of the 2011 Top 25 and CWRAF.

In CWSS 0.6, the score for each reported weakness (finding) is calculated using 18 different factors in three metrics groups.

Scoring

In CWSS 0.6, the score for a weakness, or a weakness bug report ("finding") is calculated using 18 different factors, across three metric groups:

• the Base Finding group, which captures the inherent risk of the weakness, confidence in the accuracy of the finding, and strength of controls.
• the Attack Surface group, which captures the barriers that an attacker must cross in order to exploit the weakness.
• the Environmental group, which includes factors that may be specific to a particular operational context, such as business impact, likelihood of exploit, and existence of external controls.

(A larger picture is available.)

CWSS Metric Groups

CWSS can be used in cases where there is little information at first, but the quality of information can improve over time. It is anticipated that in many use-cases, the CWSS score for an individual weakness finding may change frequently, as more information is discovered. Different entities may evaluate separate factors at different points in time.

As such, every CWSS factor effectively has "environmental" or "temporal" characteristics, so it is not particularly useful to adopt the same types of metric groups as are used in CVSS.

Most factors have three values in common:

The Base Finding metric group consists of the following factors:

• Technical Impact (TI)
• Acquired Privilege (AP)
• Acquired Privilege Layer (AL)
• Internal Control Effectiveness (IC)
• Finding Confidence (FC)

The combination of values from Technical Impact, Acquired Privilege, and Acquired Privilege Layer gives the user some expressive power. For example, the user can characterize "High" Technical Impact with "Administrator" privilege at the "Application" layer.

Technical Impact (TI)

Technical Impact is the potential result that can be produced by the weakness, assuming that the weakness can be successfully reached and exploited. This is expressed in terms that are more fine-grained than confidentiality, integrity, and availability.

If this set of values is not precise enough, CWSS users can use their own Quantified methods to derive a subscore. One such method involves using the Common Weakness Risk Analysis Framework (CWRAF) to define a vignette and a Technical Impact Scorecard. The Impact weight is calculated using vignette-specific Importance ratings for different technical impacts that could arise from exploitation of the weakness, such as modification of sensitive data, gaining privileges, resource consumption, etc.

Acquired Privilege (AP)

The Acquired Privilege identifies the type of privileges that are obtained by an entity who can successfully exploit the weakness. In some cases, the acquired privileges may be the same as the required privileges, which implies either (1) "horizontal" privilege escalation (e.g. from one unprivileged user to another), or (2) privilege escalation within a sandbox, such as an FTP-only user who can escape to the shell.

Notice that the values are the same as those for Required Privilege, but the weights are different.

The aconym "RUGNAP" can serve as a mnemonic for remembering the key values ("Regular User", "Guest", "None", "Admin", "Partially-Privileged").

Note that this factor can not be quantified.

Acquired Privilege Layer (AL)

The Acquired Privilege Layer identifies the operational layer to which the entity gains access if the weakness can be successfully exploited.

A mnemonic for this factor is "SANE" (System, Application, Network, Enterprise).

Note that this factor can not be quantified.

Internal Control Effectiveness (IC)

An Internal Control is a control, protection mechanism, or mitigation that has been explicitly built into the software (whether through architecture, design, or implementation). Internal Control Effectiveness measures the ability of the control to render the weakness unable to be exploited by an attacker. For example, an input validation routine that restricts input length to 15 characters might be moderately effective against XSS attacks by reducing the size of the XSS exploit that can be attempted.

Note that this factor can not be quantified.

Finding Confidence (FC)

Finding Confidence is the confidence that the reported issue:

• (1) is a weakness, and
• (2) can be triggered or utilized by an attacker.

The Attack Surface metric group consistes of the following factors:

• Required Privilege (RP)
• Required Privilege Layer (RL)
• Access Vector (AV)
• Authentication Strength (AS)
• Authentication Instances (AI)
• Level of Interaction (IN)
• Deployment Scope (SC)

Required Privilege (RP)

The Required Privilege identifies the type of privileges required for an entity to reach the code/functionality that contains the weakness.

The aconym "