Secure Coding Catches Fire

If you build security in from the get-go, will the malware still come?

Of course. But proponents of secure software coding say attacks and exploits won't be as widespread or prevalent if developers build security into their operating systems, applications, and network device software from the ground up.

Applications are increasingly becoming the targets of attacks and often represent the weakest link in the security chain. It gets dicier when these apps are as prevalent as systems management agent software, for instance, which Matasano Security's recent research has shown to be a security nightmare. (See Demons Lurk in Management Software.)

"The only way you're going to solve this problem is teaching people who write the software to do a better job," says Gary McGraw, CTO for Cigital (and a member of Dark Reading's editorial advisory board).

The two most common problems in coding that cause security troubles down the line are bugs in the code and design flaws, or how the software components are put together, McGraw says.

Much of that could be caught up front if developers consistently used static analysis tools, for instance, he adds.

"Time and time again, security software, written by security professionals, is found vulnerable to a dizzying array of attacks," says Tom Ptacek, a researcher with Matasano Security. "If security domain experts can't get it right consistently, what hope do normal developers have, working under tight schedules with a myriad of other customer demands?"

Interestingly, despite all its very public security woes, Microsoft has been a leader in the secure coding space, with its Trustworthy Computing initiative to shore up its coding practices, security experts say. "The security research community is increasingly recognizing Microsoft's success here," Ptacek says.

Cigital's McGraw says all of the major banks, too, are doing the same with their application development behind the scenes, as well as many other undisclosed commercial software developers.

And initiatives like the Department of Homeland Security's "Build Security In" initiative, in conjunction with the Software Engineering Institute, the Computer Emergency Response Team (CERT), and other organizations, is aimed at securing software before it ships. The idea is to reduce the number of vulnerability reports and attacks security experts like CERT see on a daily and hourly basis by getting commercial and enterprise software developers to adopt best practices, tools, and other security assurance guidelines they need in order to write code that's inherently as safe as it can be.

The security problems in software stem from what McGraw calls "the trinity of trouble" -- all code developed is on the Internet; programming languages have become more complex; and extensible code like Java can make things dicey when you don't know where it came from but you have to run it, he says.

"There's more code and more bugs," McGraw says.

There's at least one application that's living proof of the secure coding concept. The Internet email server qmail, according to Matasano's Ptacek, has never had a real vulnerability reported and it's seven years old. "That's an amazing accomplishment," he says. "But it's probably the exception that proves the rule" that software can be built with security from the ground up.

And today, developers are starting to deploy static analysis tools to review their code before it goes out, according to McGraw, as well as performing architectural risk analysis. Much of that is due to increasing legal pressures, he says, "and if you're not doing code review today, you are negligent."

Aside from the BuildItIn initiative, there are several resources out there for companies looking to secure their software development cycle. Secure Software has a best practices model called Comprehensive Lightweight Application Security Process (CLASP), which companies like Depository Trust & Clearing Corp. are adopting in-house, says Jodi Wadhwa, marketing manager for Secure Software.

But secure coding has a long way to go. You can't build safer apps overnight, so it will remain a work in progress for the long haul. "All of these intiatives help," says David Pensak, CTO and founder of application security startup V.i. Laboratories. "The amount of code I still see that isn't using the simplest error-checking to make sure input parameters are in the right range" is unbelievable, he notes.

— Kelly Jackson Higgins, Senior Editor, Dark Reading