CERT Seeks Secure Coding Input

When you're looking to lock down applications, securing the underlying code has to be one of your cornerstones.

To that end, the Computer Emergency Response Team's (CERT) Secure Coding Initiative (SCI) late next month will give developers their first peek at work underway on standards for secure software development.

Robert Seacord, senior vulnerability analyst at CERT who heads up SCI, says once complete, the standards will provide developers with a set of rules for creating safer and less error-prone software. Most security flaws are caused by programming errors, Seacord says, which leave OSes and applications vulnerable to attack. (See Secure Coding Catches Fire.) CERT's standards efforts are centered around the widely used C and C++ programming languages, and the goal is for developers to adopt these standards internally, he says.

"We're focusing on common programming errors that developers can make. These are the sort of errors you put into code and can lead to exploitable vulnerabilities," Seacord says. One of the most common exploits caused by programmer error is buffer overflow, he says.

CERT's not the first to tackle secure coding. Many software companies have their own internal coding standards, and there are some best practices guidelines available, such as those available via the BuildSecurityIn Website (a program sponsored by the Department of Homeland Security), and from the National Institute of Standards, as well as at least one military set and several books. "None of these provides a prescriptive set of secure coding standards that can be uniformly applied in the development of a software system," Seacord says.

Tom Ptacek, researcher with Matasano Security, says there are already plenty of sources of information on secure programming. He's skeptical of the impact of CERT's standards. "And what does standardization actually mean? What is scarier to say about a program -- that it is nonstandard or that it is insecure?" Ptacek says. "The code we deal with is already insecure. Sophisticated buyers know in their gut that this is true. So why do they care if it's nonstandard to boot?"

CERT, meanwhile, has had a front-row seat in the vulnerability war, which prompted the organization to step up with some best practices for developers. Vulnerability reports and attacks continue to climb, according to CERT's latest numbers, with 3,997 vulnerabilities for the second quarter of this year alone, versus a total of 5,990 for all of 2005.

"Instead of working reactively, we are trying to work with software developers to prevent the introduction of vulnerable software," Seacord says. "Overall, there's a lot of code out there that's still in really poor shape."

Seacord says CERT will launch a Wiki with the secure coding standards work it's done so far -- which is only about 20 percent complete. CERT is also working with ISO/IEC WG14, which will provide the SCI with agenda time at their meetings as well as technical-review support to help solidify the standards. ISO has no plans to publish them as their own standards, Seacord says, although if it makes sense to eventually have the standards adopted within a recognized standards body to move it along, CERT may do so.

How can CERT push adoption of its standards if it can't enforce them? Seacord says CERT wants to get developers involved in the standards process so they'll have a stake in it. "We're hoping to get all of this information vetted by the community before we try to cast the standards in concrete," he says. "That's why we're starting up a Wiki to support threads, discussion groups, and to allow people to submit things. If the community gets involved in the development of the rules, there will be a natural path to the adoption."

Seacord says he wouldn't mind if that means starting all over again with new input from developers. "I am hoping that the quality of the product will improve each time we rework and rewrite the rules." CERT's secure coding standards won't, however, address security features vendors may add to their software, he says.

CERT already offers developers a proof-of-concept implementation of a managed string library that helps prevent buffer overflow problems in code and other programming errors.

So what will enterprises that someday purchase a new generation of CERT standards-based software get? "They should have higher-quality software that's more secure," Seacord says. And larger companies won't have as many major breaches, like those reported in the press of late.

Still, since the CERT standards will raise the security bar for software, it's likely smart hackers will still find a way to jump it, Seacord says. "It's a tough game because you're dealing with an intelligent hacker," he says. "They have had the advantage because of the lack of emphasis we've had on security. But I think it's possible to develop secure systems -- you just have to develop the software with security in mind."

— Kelly Jackson Higgins, Senior Editor, Dark Reading