Common Weakness Enumeration

CWE Glossary Definition

Future CWRAF Versions

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.

Planned Future CWRAF Activities

The majority of the development and refinement of CWRAF will occur during 2011-2012. Current and past activities include:

• Engaging communities of interest for creating new vignettes and refining the existing vignettes, including prioritization of technical impacts.
• Using 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.

Community Participation in CWRAF

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.