Schwartz On Security: Secure Coding Or Bust

Secure development offers a clear return on investment and safeguard against both data breaches and "brand erosion." So why aren't more companies buying in?

According to a 2010 survey conducted by consulting firm Errata, 57% of companies say they use some secure coding techniques, and 81% are at least aware they exist. But 43% of companies use no secure development techniques at all.

Please, non-practitioners, consider the downsides of poorly designed and buggy software. For starters, it gives attackers a way to break into corporate systems and steal information, and that gets expensive. Indeed, the average data breach cost for a U.S. company hit $7.2 million in 2010, according to Ponemon Institute.

Bugs in software are a hot attack vector. All it took were a couple of batches of spoofed emails -- with an attached Excel spreadsheet that included a compromised Flash file -- to knock down EMC's RSA unit, compromising some aspect of its SecurID two-factor authentication system. How much will that cleanup cost, especially with RSA reportedly having reached out to 60,000 customers?

Not every security incident or data breach can be traced to bugs in code, or poor application design, but many can. That's because attackers favor the easy way in. And if you want an easy target, just find existing vulnerabilities in Web-connected applications. Interestingly, that was the modus operandi of the Iranian hacker who compromised Comodo digital certificates for Google, Microsoft, and Mozilla, among other Web domains, by finding a DLL file that stored a username and password. Can you say "insecure by design"?

So why aren't more companies cracking down on insecure approaches to building applications? Perhaps it's a risk versus reward issue -- save time in the development process, or worry about Web application attacks that may occur someday in the future.

Perhaps it's because we're spectacularly ill-equipped when it comes to judging risk versus reward, especially for something abstract like security, according to security guru Bruce Schneier, chief security technology officer of BT. "More people are killed every year by pigs than by sharks, which shows you how good we are at evaluating risk," he says.

If hackers are sharks, then Web application attackers are pigs -- and they're killing us. Accordingly, it's time for every company that creates code to ensure that secure development techniques are not just adopted, but required.

Where to start? Numerous secure development frameworks can help, including the Software Assurance Maturity Model (SAMM) and the Building Security In Maturity Model (BSIMM).

But according to the Errata study, Microsoft's Secure Development Lifecycle (SDL) is the most-adopted secure development framework. As with the other standards, it's free, pragmatic, and vendor-neutral. "We specify classes of tools that should be used at a particular point in time, but one thing we don't want to do is have rip and replace," David Ladd, security program manager lead at Microsoft, told me in an interview. "If an organization has already invested in a static code analysis tool and it works? Great, don't replace it."

But wait, what's secure development going to cost? "Companies adopting a 'secure at the source' strategy -- i.e. the integration of secure application development tools and practices into the software development -- realized a very strong, four-times return on their annual investments," said Ladd.

That ROI figure is based on a recent Aberdeen Group study, Security and the Software Development Lifecycle: Secure at the Source, which surveyed 150 organizations and found that about 20% "are currently using static source code analysis, dynamic source code analysis, secure software development tools, and software security testing tools," he said.

According to the Aberdeen study, the average cost to run a secure software program is $400,000 per year. But the study found that the cost of dealing with a single code-based security issue is $300,000. So if you avoid one security issue per year thanks to secure coding, then your security-savvy development techniques and tools nearly pay for themselves. Plus, think of all the data breaches -- not to mention the accompanying downtime and bad press -- you'll avoid.

All in all, doesn't clean code and a "secure by design" application development philosophy sound like a good investment?

Recommended Reading: