QUESTION & ANSWER

Software buyers forcing changes in application security

By Colleen Frye, News Writer 08 Mar 2006 | SearchAppSecurity.com

Software quality news and advice Digg This!     StumbleUpon     Del.icio.us

Dr. Herbert H. Thompson, chief security strategist, Security Innovation Inc.

Back in April you said we are in the infancy of application security. What are the main drivers of this emerging segment of security?
Dr. Herbert H. Thompson: One of the biggest drivers has been legislation. Although very few enforced laws or standards speak to application security directly, companies are now beginning to look at "security" more holistically. The California disclosure law (California Senate Bill 1386) was the beginning of a wave of disclosure legislation that requires companies to notify customers if their personally identifiable information has been compromised.

Think of the difference in business risk. In the past if a customer database was breached, many companies would take quiet action internally; now those companies are being forced to broadcast that breach to the rest of the world. You've just turned the corner on risk from a few engineering hours of quiet internal work to potentially millions of dollars in losses in reputation damage and stock value. This is especially true of industries like financial services whose stock-in-trade is trust. Those companies have been forced to take a hard look at where risk is coming from, and in many cases, they've found some of the biggest risk lays in the applications that they buy and build.

In addition to the disclosure issue, laws and standards like Sarbanes-Oxley and others have had a massive impact on IT security as a whole. They have forced people to again reevaluate where their biggest IT risks are. In many cases, those questions have highlighted the need for application security. [Sarbanes-Oxley] audits, for example, have changed the arguments about why we need to care about security from "something bad my happen to us in the future" to "the auditors will show up and do an assessment." This "impending event" of an audit means that insecurity has real consequences: If the company fails the audit, in many cases, real and tangible penalties exist. While a lot of these enforced standards are open to interpretation -- and in some cases don't address "real" security directly -- they have at least served to bring awareness to software security risk.

[Financial services] companies have been forced to take a hard look at where risk is coming from, and in many cases they've found some of the biggest risk lays in the applications they buy and build. Dr. Herbert H. Thompson Chief security strategist, Security Innovation Inc.

Another driver that's worth mentioning for application security, especially for vendors, is that the security expectation of customers for software are changing. Microsoft introduced its Secure Development Lifecycle. HP, Motorola, Cisco, Oracle and most of the other large vendors are working to improve the security quality of the applications they produce. Add this to the fact that customers are starting to ask more piercing questions to vendors about the security of their development and post-deployment/patching processes, and you've got serious impetus for change.

As a result of all of these drivers, we've witnessed the emergence of the more security-savvy buyer of software. Enterprise customers are starting to ask questions about the security processes of potential vendors, and those answers are having a big impact on purchase decisions.

What needs to happen to move from infancy to adolescence -- both in terms of tools and people/mindset?
Thompson: I would argue that the practice of software engineering in general is in its early adolescence. For security to catch up, though, there are a few critical things we need.

First, security has to be integrated throughout the software development lifecycle from requirements all the way to deployment. Right now, in many development organizations, security is treated as something that's bolted on to the process or, in some cases, security isn't considered at all. Making secure development mainstream requires that the tools we use to build software support secure software development: security requirements gathering, abuse cases development and secure coding.

Second, we need metrics around software security. In many organizations if it isn't measurable, it doesn't exist. It's hard to make security a key factor in development processes and purchase decisions if it can't be assessed in some meaningful way. We need to be able to make some sort of reasonable statement about security "improving" or "worsening" based on changes to the development process. As opposed to other qualities of software like performance, though, security doesn't have some definite value that we can benchmark and measure directly. We can, however, gain traction around best practices for secure software development. This will, at the very least, give consumers some baseline to judge both applications and vendors against so that they can make more security-savvy decisions.

Last year, some of the world's largest software vendors and enterprise consumers came together with analysts and industry luminaries to form AppSIC, the Application Security Industry Consortium, whose focus is on developing business metrics for application security. I think this will be a key driver for moving application security forward.

Some of the largest ISVs, such as Microsoft, have been working to make security part of the software development life cycle. Do you see corporate developers doing so as well?
Thompson: Microsoft and others have certainly raised the bar, and we're seeing change in the corporate development culture as well, but progress has been slower. Probably the biggest uptake has been in the industries that face some of the most visible risks, like financial services. Development organizations in these companies are becoming increasingly aware of the risks they inherit from the software they build and are coming to terms with the limitations of network and other bolt-on defenses to protect them.

-----------------------------------------
Dr. Herbert H. Thompson is chief security strategist at Security Innovation Inc., a provider of assessment and training services in Wilmington, Mass., and world-renown expert in application security. He has co-authored or edited 12 books, including How to Break Software Security (Addison Wesley, May 2003), and The Software Vulnerability Guide (Programming Series) (Charles River Media, June 2005). Thompson is chair of the Application Security Industry Consortium Inc. (AppSIC), an association working to establish cross-industry application security guidance and metrics. He also co-wrote the cybercrime novel The Mezonic Agenda: Hacking the Presidency (Syngress, October 2004).

Tags: Building security into the SDLC (Software development life cycle),  VIEW ALL TAGS

Digg This!     StumbleUpon     Del.icio.us