Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Attacks/Breaches

2/19/2010
09:40 AM
Connect Directly
Twitter
RSS
E-Mail
50%
50%

Proposal Would Hold Software Developers Accountable For Security Bugs

SANS releases Top 25 list of the most dangerous programming errors; joins with Mitre, others, to push for contract language that makes custom app developers liable for vulnerabilities

SANS' newly released Top 25 list of common programming flaws came with a little legal muscle, too, with representatives from SANs, Mitre, the U.S. Department of Homeland Security, the National Security Agency, and other organizations pushing for custom software developers to be held liable for insecure code they write.

Experts from more than 30 U.S. and international organizations, including OWASP, Microsoft, Apple, EMC, Oracle, McAfee, and Symantec, contributed to the CWE/SANS Top 25 list. And procurement experts from some of the organizations are recommending standard contract language for procurements that would ensure buyers aren't held liable for software that contains security flaws. "Wherever a commercial entity or government agency asks someone to write software for them, there is now a way they can begin to make the suppliers of that software accountable for [security] problems," says Alan Paller, director of research for the SANS Institute.

Paller says the contract language would be based in part on a draft in the works by the State of New York (PDF) that refers to the SANS Top 25 and would make the state's custom-software vendors contractually bound to provide apps that are free of those bugs. Paller says although there is "no formal agreement on the language" among the group at this point, it's focused on the section of New York's proposed contract language that reads: "the Vendor shall, at a minimum, conduct a threat assessment and analysis of vulnerability information, including the current list of SANS 25 Most Dangerous Programming Errors; provide the Purchaser with a written report as soon as possible after a vulnerability, threat, or risk has been identified."

He says some final tweaking of the language would ideally add a warranty for correcting secure-coding errors "at vendor expense."

Such a legal arrangement would not only protect customers of the software, Paller says, but also provide developers with a "safe harbor" of sorts. "What do I have to do to supply software that's safe enough so I don't get into legal problems with the customer?" he explains.

Joe Jarzombeck, director for software assurance for the national cybersecurity division at DHS, says any contract language would be voluntary. "There is no unified mandate," Jarzombeck says. And the Common Weaknesses Enumeration (CWE)/SANS Top 25 list is now being adopted by tool vendors as well, he notes.

"The [list is not to] say, 'Here's how to be 100 percent secure,' but to more definitive in the specific risks," he says.

For the buyer, making the vendor liable for security bugs would help protect its organization from potential breaches exploiting those flaws as well as prevent the vendor from charging them extra to fix them. And for developers, it's a "minimum standard of due care," SANS' Paller says.

But Gary McGraw, CTO of Cigital, whose company was involved with the project, says he predicts such an effort would yield "zero lawsuits" and would instead lead to more expensive software. "The liability angle is not the right idea," McGraw says. "The market is working right now. Sure, software is still busted. But companies are really making marked progress. As long as that's working, I don't see why you should invoke the liability hammer."

SANS' annual list had been criticized by security experts as more of a laundry list rather than offering a solution, but this year the list came with so-called "focus profiles" that broke the programming errors into groups based on categories of weaknesses and also provided mitigation information. The list is in order of priority this year, with failure to preserve Web page structure (think cross-site scripting) as No. 1, and race condition mistakes as No. 25, notes Robert Martin, lead for compatibility and outreach at Mitre.

The Top 25 encompasses programming mishaps that are the root cause of most major cyberattacks, including the breaches at Google, power companies, military systems, and attacks on small businesses and home users, its creators say.

Even with the upgrades to the Top 25, McGraw says it's ineffective: "It's still a popularity list and not based on actual bug data from any real company," he says.

Meanwhile, OWASP, which is working on its final Top 10 list of Web application security risks, was "mapped" to this list as well, says Chris Wysopal, CTO of Veracode, who was among the participants in the Top 25.

Wysopal says large organizations in finance, government, or that run applications associated with "life or limb" applications are already including language in their large software contracts that hold their vendors accountable for clean software.

But the legal implications of secure coding contracts remain unclear. "I don't see an organization being held accountable when they submit their software for testing, get a clean bill of health, and later a defect is found that was missed," Wysopal says. "We know the state-of-the-art is not 100 percent."

Cigital's McGraw says software developers don't need to be forced to do the right thing: "They need to know what the right thing is," he says. "It's more important to teach them how to do it right than how to avoid a thousand bugs."

And many developers aren't even aware of secure coding issues at all, which the Rugged Software Development initiative, launched last week, aims to remedy by reaching out to the masses about secure development practices. Joshua Corman, research director for the enterprise security practice at The 451 Group and a co-founder of Rugged, says Rugged hopes to inform and steer developers toward secure coding efforts, such as the Top 25.

"This is very complementary to Rugged," Corman says of the SANS Top 25 list. "We would serve as a catalyst or on-ramp to help people learn of the Top 25."

Thus far, efforts to preach secure coding to developers haven't worked, he says. "What we want is people to care about security and developing rugged code," Corman says.

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Edge-DRsplash-10-edge-articles
I Smell a RAT! New Cybersecurity Threats for the Crypto Industry
David Trepp, Partner, IT Assurance with accounting and advisory firm BPM LLP,  7/9/2021
News
Attacks on Kaseya Servers Led to Ransomware in Less Than 2 Hours
Robert Lemos, Contributing Writer,  7/7/2021
Commentary
It's in the Game (but It Shouldn't Be)
Tal Memran, Cybersecurity Expert, CYE,  7/9/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Enterprise Cybersecurity Plans in a Post-Pandemic World
Download the Enterprise Cybersecurity Plans in a Post-Pandemic World report to understand how security leaders are maintaining pace with pandemic-related challenges, and where there is room for improvement.
Flash Poll
How Enterprises are Developing Secure Applications
How Enterprises are Developing Secure Applications
Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2021-39339
PUBLISHED: 2021-09-22
The Telefication WordPress plugin is vulnerable to Open Proxy and Server-Side Request Forgery via the ~/bypass.php file due to a user-supplied URL request value that gets called by a curl requests. This affects versions up to, and including, 1.8.0.
CVE-2021-38153
PUBLISHED: 2021-09-22
Some components in Apache Kafka use `Arrays.equals` to validate a password or key, which is vulnerable to timing attacks that make brute force attacks for such credentials more likely to be successful. Users should upgrade to 2.8.1 or higher, or 3.0.0 or higher where this vulnerability has been fixe...
CVE-2021-31819
PUBLISHED: 2021-09-22
In Halibut versions prior to 4.4.7 there is a deserialisation vulnerability that could allow remote code execution on systems that already trust each other based on certificate verification.
CVE-2021-38112
PUBLISHED: 2021-09-22
In the Amazon AWS WorkSpaces client before 3.1.9 on Windows, argument injection in the workspaces:// URI handler can lead to remote code execution because of the Chromium Embedded Framework (CEF) --gpu-launcher argument.
CVE-2021-41382
PUBLISHED: 2021-09-22
Plastic SCM before 10.0.16.5622 mishandles the WebAdmin server management interface.