This article can also be found in the Premium Editorial Download "Information Security magazine: Captive to SOX compliance? A compliance guide for managers."
Download it now to read this article plus other related content.
It may be a tough sell, but security at the application level may be your company's--and customers'--best bet.
Thanks to compliance, you've finally gotten the C-suite's attention and perhaps even more funding for perimeter defense, vulnerability tools and strong authentication. And now we're telling you that you must go back and ask for more money to ensure that the applications built today are secure.
Sounds like a tough sell, huh? First off, the developers within your organization probably don't even report into your department. Worse yet, their goals are seemingly at cross-purposes with your objectives: They're tasked with adding features and functionality that ultimately bolster the bottom line. Your department is an expense where results are hard to quantify.
Sure, secure coding sounds like an obvious must-have on paper. Who wouldn't want their applications coded in such a manner that could reduce the likelihood of hacks like SQL injections and buffer overflows? Who wouldn't want that peace of mind?
But the reality is much different. Corporate execs don't view security as something that needs to be considered in the development phase. Rather, it's an afterthought.
At the same time, the sheer volume of existing legacy applications in any large corporations makes this process seem a bit daunting. Source code scanning tools offer to help in this process, but the tools offer so many false positives that the process seems all but
Lastly, the lack of metrics to show the business value of such a task has left few businesses embracing the tactic.
Despite all these setbacks, the climate is changing for secure coding. The reason: Security is a non-negotiable expectation for customers.
According to Herbert Thompson, chief strategist for Security Innovations, every major software vendor has embraced secure coding within the last 18 to 24 months. True, it's an easier sell for them; secure software is their bread and butter. And, quantifying the investment is easier to do: They can calculate the amount of man hours, help desk hours and development time involved in rolling out a patch.
But there are still other factors that lead to this trend. Gartner estimates 75 percent of hacks occur at the application level--that's one stat that may give you pause. What's more, high-profile application attacks on mainstream companies, such as T-Mobile, have others considering this method to protect their own applications.
Meanwhile the companies who have embraced secure coding, like the software development firms, are starting to empirically understand the business value of secure coding. They are seeing a reduction in vulnerabilities and can map that reduction to a cost.
But other large non-tech firms have also started to dip their toe in the secure coding waters. Many have started to build security gates and check points into their process. Still others have embraced security testing. (For more on creating a process that melds security into the development process, read "Secure from the Start.")
But these are the early adopters. If secure coding is to be universally embraced, metrics must be defined and integrated into existing business metrics. The new Application Security Industry Consortium (AppSIC) is beginning work on methodologies and metrics that businesses can use to help them assess their own software development process for security. Once those types of tools are in place, secure coding will start to gain traction.
It won't be such a hard sell and the benefits will add up.
This was first published in March 2006