Most enterprise developers can recite various software architecture layers as though it's the easy question on the computer science final exam: operating system, application server, Web server, database server, application, network. Providing security at each of these levels is important, and traditionally accountability lies with the network and production staff. However, a few new statistics, offered today at the Gartner Application Development Summit in Phoenix, Arizona, stress new security efforts that development and QA teams must make during the application development life cycle.

According to a presentation given by Theresa Lanowitz, Gartner Research Director, the problems of network and physical security within IT have largely been solved, leaving the application layer the most vulnerable. Today, claims Lanowitz, "75% of hacks happen at the application." As a result, companies who don't take responsibility for security issues during the development process are significantly more likely to experience a catastrophic event.

Doing so would have a marked impact on IT costs. Gartner predicts that if 50% of software vulnerabilities were removed prior to production use for purchased and internally developed software, enterprise configuration management costs and incident response costs each would be reduced by 75%.

It's one thing to say that enterprise application development and quality assurance groups need to become more proficient in security at the application layer. But going about that process is more than suggesting to programmers, during the Monday morning team meeting, that it wouldn't be a bad idea to consider security defects in their code.

There needs to be someone in the organization who's responsible for security issues, says Lanowitz. Some enterprises, particularly financial and government agencies, are creating the role of Application Security Architect as a peer to application architect or development manager, and adding security testing as a pillar of QA along with functional and load testing. By 2006, Gartner claims, 80% of application development teams will have a person or team responsible for application security.

Creating a person who gets paid to fret about security vulnerabilities isn't for the purpose of establishing a Corporate Worry-Wart. Face it: developers spend their time thinking about features and functionality. The primary role of testing teams is function and load testing. The focus of the tools that vendors provide is on productivity, because that's what developers say they want. Someone has to have, as a primary concern, the risks that the company faces, and to express them to the staff and to management: "Here are our vulnerabilities, and here's what level of threat we have."

While your users are swift to tell you about the features your applications need, nobody's going to tell you about the security holes you left gaping open. They'll just exploit them. Real application security, stresses Lanowitz, is built into all phases of the application development process.

Here's just one example to demonstrate the need for security consciousness-raising: building secure test data. When developers or QA personnel need to bang on the software, from where are they getting the test data in your organization? Simply asking the DBA for a dataset, and signing a non-disclosure agreement (NDA) that promises "We won't do anything with it" isn't enough. "You can't just sign an NDA and expect that data won't get out," says Lanowitz.

One thing that will help, happily, is better tools to address security needs. By the first half of 2007, you can expect to see most development tools integrating security needs. Recent acquisitions bear this out, Lanowitz points out, such as Watchfire's acquisition of Sanctum, and Symantec's acquisition of @Stake. But don't expect too much of them, too soon. "This is an early market," she cautions. "We as customers must communicate with vendors to get the tools we need."