New group calls for holding vendors liable for buggy software
The group released draft language it advises companies to incorporate into procurement contracts between user organizations and software development firms; SANS Institute, Mitre also release 2010 list of Top 25 programming errors
A loose consortium of security experts from more than thirty organizations called on enterprises to exert more pressure on their software vendors to ensure that they use secure code development practices. The group, led by the SANS Institute and Mitre Corp., later today is slated to release later draft language for use in procurement contracts between user organizations and software development firms.
Computerworld’s Jaikumar Vijayan writes that the document provides user companies with a list of specific terms and conditions that should be included in procurement contracts to ensure that vendors are adhering to a strict set of software development security standards. In sum, the draft contract would leave development firms liable for software defects.
“Nearly every attack is enabled by [programming] mistakes that provide a handhold for attackers,” said Alan Paller, director of research at SANS, a security training and certification group based Bethesda, Maryland. “The only way programming errors can be eradicated is by making software development organizations legally liable for the errors.” he said.
SANS and Mitre, a Bedford, Massachusetts-based non-profit, federally funded technology research and development organization, are also releasing their second annual CWE/SANS Top 25 list of the most common programming errors currently being made by software developers. The authors say the errors on the list are responsible nearly every major type of cyber attack, including the recent intrusions at Google, and numerous utilities and government agencies.
The list was compiled with help from security analysts at numerous organizations including the National Security Agency, the U.S. Department of Homeland Security’s National Cyber Security Division, Purdue University, EMC Corp., Symantec Corp., and Microsoft Corp.
The Top 25 programming errors found this year are virtually the same as those on the 2009 Top 25 list.
Vijayan writes that according to the latest list, the most common programming errors continue to be SQL injection errors, cross-site scripting flaws and buffer overflow vulnerabilities All three issues have been well understood for a long time now and have consistently been identified as the most common coding errors on various lists.
Other top vulnerabilities included in this year’s list include cross site request forgery flaws, weak access control and authentication mechanisms, overly permissive default settings and a lack of encryption support.
The Top 25 list comes out just days after Trustwave, a provider of security auditing services for major companies, released a report showing that most security breaches continue to be caused by well-known flaws rather than new ones.
Trustwave’s report was based on an analysis of data gathered from more than 1,900 penetration tests and over 200 data breach investigations conducted on behalf of clients such as credit card firms American Express, MasterCard, Discover and Visa and several retailers. The Trustwave study found that the top three paths used hackers to gain access to corporate networks in 2009 were via remote access applications, trusted internal network connections and SQL injection attacks — all well studied issues.
The notion of holding third-party software developers liable for such errors is not new. Generally it is a good idea to ensure that procurement contracts include language spelling out the security expectations for a project, said Gary McGraw, chief technology officer at Cigital, a Washington, D.C. security consulting firm. Rather than tying the procurement language to a generalized list of top programming errors, such as the one released today, companies should customize it to their particular environments, he said.
Companies should compile a list of the most common vulnerabilities in their own environments and use that as a basis for the language in their procurement contracts, he said. “The notion of controlling your vendors to make sure they are following software security is a very good notion. But it need to tailored to your environment,” he said.