News
Coalition Agrees on Top 25 Software Security Errors
A coalition of government, academic and private-sector security organizations have announced a list of the top 25 programming errors that are responsible for the majority of security vulnerabilities plaguing applications.
The list, available online, represents a consensus on the most significant errors. It's aimed at helping the IT community improve software security and reliability. The list can be used by universities to bolster their programming curricula. Vendors and developers can use it as a standard for proper coding. It can also serve as a specification when acquiring software.
The initiative was managed by the SANS Institute and Mitre Corp., with support from the National Security Agency and the Homeland Security Department's National Cyber Security Division.
Konrad Vesey of NSA's Information Assurance Directorate said that the list will help shift the reactive posture of system administrators toward software security, and put more of the responsibility on software developers.
"When consumers see that most vulnerabilities are caused by a mere twenty-five weaknesses, a new standard for due diligence in product development is likely to emerge," Vesey said. "The vocabulary of software security is expanded from what the vendor tested against to what the vendor built in."
Contributors to the program include major software and security companies, along with universities, independent organizations and individuals, as well as U.S. and foreign government agencies.
The errors included in the list are not newly discovered. They are drawn from the Common Weakness Enumeration (CWE) database, a standardized listing of more than 700 recognized programming weaknesses that is maintained by Mitre with support from DHS.
A weakness is an error or condition in software code that, under certain circumstances, can create a vulnerability that can be exploited maliciously. Automated tools exist to look for many of these weaknesses, but finding and eliminating them is not a simple task.
"No tool can correctly determine in every conceivable case whether or not a piece of code has a vulnerability," the National Institute of Standards and Technology wrote in Special Publication 500-268 when it developed specifications for source code analysis tools. "A weakness may result in a vulnerability in one environment, but not in another."
There also are mathematical and practical limits to the ability of algorithms to detect weaknesses in software, and not all weaknesses result in vulnerabilities.
NIST specified a list of 21 source-code weaknesses from the CWE database that source code analysis tools should be able to identify. There is little overlap between that list and the top 25 list released on Monday by SANS and Mitre. Only three weaknesses appear on both lists.
The list's developers plan to keep the list updated on a regular basis. They expect that it will be used as a standard for evaluating coding and software development.
For instance, software customers could use the list to require that solutions be certified free of typical errors. Testing and analysis tools used by programmers and customers could be designed to focus on the errors. Employers could require an understanding of the list's errors by their programmers and application developers.
The top 25 errors fall into three categories: insecure interaction between components (nine errors); risky resource management (nine errors); and porous defenses (seven errors). The errors, along with their CWE identification, are listed below.
Insecure Interaction Between Components:
- Improper Input Validation (CWE-20)
- Improper Encoding or Escaping of Output (CWE-116)
- Failure to Preserve SQL Query Structure, or SQL Injection (CWE-89)
- Failure to Preserve Web Page Structure, or Cross-site Scripting (CWE-79)
- Failure to Preserve OS Command Structure, or OS Command Injection (CWE-78)
- Cleartext Transmission of Sensitive Information (CWE-319)
- Cross-site Request Forgery (CWE-352)
- Race Condition (CWE-362)
- Error Message Information Leak (CWE-209)
Risky Resource Management:
- Failure to Constrain Operations Within the Bounds of a Memory Buffer (CWE-119)
- External Control of Critical State Data (CWE-642)
- External Control of File Name or Path (CWE-73)
- Untrusted Search Path (CWE-426)
- Failure to Control Generation of Code, or Code Injection (CWE-94)
- Download of Code Without Integrity Check (CWE-494)
- Improper Resource Shutdown or Release (CWE-404)
- Improper Initialization (CWE-665)
- Incorrect Calculation (CWE-682)
Porous Defenses:
- Improper Access Control (CWE-285)
- Use of a Broken or Risky Cryptographic Algorithm (CWE-327)
- Hard-coded Password (CWE-259)
- Insecure Permission Assignment for Critical Resource (CWE-732)
- Use of Insufficiently Random Values (CWE-330)
- Execution with Unnecessary Privileges (CWE-250)
- Client-side Enforcement of Server-Side Security (CWE-602)
About the Author
William Jackson is the senior writer for Government Computer News (GCN.com).