In a new and revised format, SANS along with MITRE has published the latest list of the highest risk software security vulnerabilities; the revision to the list is based on the CWE, CWSS and CWRAF security standards. The announcement leverages and highlights these new standards and collaboration efforts among the security community (including corporate, non-profit and government entities). As this announcement publicizes some new standards efforts that many of us will undoubtedly hear a lot about in the coming months, I thought it made sense to leverage the CWE/SANS Top 25 Most Dangerous Software Errors list to put these other standards in context.
First, let’s summarize the standards.
Before diving into these other standards, it’s perhaps best to start with the CVE list. The Common Vulnerabilities and Exposures (CVE) List was started by the MITRE Corporation, a non-profit think tank, in 1999. The CVE List is free (http://cve.mitre.org) and publicly available and creates a standardized set of identifiers for common vulnerabilities and exposures. The List provides common identifiers so automated tools, such as vulnerability scanners and patch management systems can exchange vulnerability data using unique identifiers. You can think of the CVE List as the master set of security vulnerabilities. CVE numbers have become the interoperability standard amongst security vendors.
Where the CWE list is a complete list of individual vulnerabilities, the Common Weakness Enumeration (CWE) provides a categorical view describing classifications of risk. The CWE List can be thought of as a taxonomy of vulnerability categories such that unique vulnerabilities in various software systems can be categorized. As such there are many more unique software vulnerabilities than categories that classify them. For example, the CVE List has almost 50,000 entries while the CWE List has only 870.
The CWSS provides a consistent method by which vulnerabilities can be scored. This would potentially address, for example, (at least in theory) a big problem with automated vulnerability scanners: they tend to create reams of output without any context as to what is important in a given environment. Given that every environment is unique, its difficult for automated software processes to programmatically determine the relevance of a particular instance of a vulnerability. The CWSS would provide a repeatable approach to determine the relevance of risk as well as provide a way to quantifiably measure unaddressed vulnerabilities.
The CWRAF provides a method for organizations to customize the application of the CWSS to account for their particular business and technology environments. So as the CWSS provides a repeatable process to score vulnerabilities, the CWRAF provides a repeatable way for organizations to apply the CWSS to their own unique business environments.
So what’s all this got to do with the CWE/SANS Top 25?
Well, perhaps nothing. The list itself is a prioritized list of the top 25 security weaknesses in software as a function of prevalence, probability of exploitation, and importance. The list is a great resource for any IT or security professional that wants to focus their efforts on the most important issues. Considering that every organization has security risk (an often plenty of it) and IT resources are limited, keeping focused on the important issues is incredibly important in a structured risk management program. But what about CVE, CWE, CWSS, CWRAF….? So it’s not the CWE/SANS Top 25 list that has to do with these standards, its more that this alphabet soup of standards is how the Top 25 list was created. SANS worked with MITRE along with security experts worldwide to compile the list. While experts in the field often work with individual CVE identifiers, the TOP 25 list is based on CWE categories. The list is prioritized based on the scores that were calculated based on the CWSS. Specific industries and organizations could customize the scoring using the CWRAF.
Below is the current CWE/SANS Top 25 Most Dangerous Software Errors list. Notice how CWE categories are referenced as opposed to CVE numbers or ad hoc categories, and the CWSS score is used for prioritization.
- 93.8 CWE-89 Improper Neutralization of Special Elements used in an SQL Command (‘SQL Injection’)
- 83.3 CWE-78 Improper Neutralization of Special Elements used in an OS Command (‘OS Command Injection’)
- 79.0 CWE-120 Buffer Copy without Checking Size of Input (‘Classic Buffer Overflow’)
- 77.7 CWE-79 Improper Neutralization of Input During Web Page Generation (‘Cross-site Scripting’)
- 76.9 CWE-306 Missing Authentication for Critical Function
- 76.8 CWE-862 Missing Authorization
- 75.0 CWE-798 Use of Hard-coded Credentials
- 75.0 CWE-311 Missing Encryption of Sensitive Data
- 74.0 CWE-434 Unrestricted Upload of File with Dangerous Type
- 73.8 CWE-807 Reliance on Untrusted Inputs in a Security Decision
- 73.1 CWE-250 Execution with Unnecessary Privileges
- 70.1 CWE-352 Cross-Site Request Forgery (CSRF)
- 69.3 CWE-22 Improper Limitation of a Pathname to a Restricted Directory (‘Path Traversal’)
- 68.5 CWE-494 Download of Code Without Integrity Check
- 67.8 CWE-863 Incorrect Authorization
- 66.0 CWE-829 Inclusion of Functionality from Untrusted Control Sphere
- 65.5 CWE-732 Incorrect Permission Assignment for Critical Resource
- 64.6 CWE-676 Use of Potentially Dangerous Function
- 64.1 CWE-327 Use of a Broken or Risky Cryptographic Algorithm
- 62.4 CWE-131 Incorrect Calculation of Buffer Size
- 61.5 CWE-307 Improper Restriction of Excessive Authentication Attempts
- 61.1 CWE-601 URL Redirection to Untrusted Site (‘Open Redirect’)
- 61.0 CWE-134 Uncontrolled Format String
- 60.3 CWE-190 Integer Overflow or Wraparound
- 59.9 CWE-759 Use of a One-Way Hash without a Salt
Overall, we applaud this effort; both the list and the accompanying standards. Any effort that prioritizes risk and provides a systematic and repeatable process to do so is a big boost for enterprise security. In the short term, the value of these methodologies will surely be a function of the capabilities and dedication of those that use them (the garbage in – garbage out rule will still apply), but any methodology that adds some structure to security risk analysis is a worthy effort.