PHOENIX—Most enterprise developers can recite various software architecture layers as though its 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 Wednesday at the Gartner Application Development Summit here, stress new security efforts that development and quality assurance teams must make during the application development life cycle.
According to Theresa Lanowitz, Gartner Inc. 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 percent of hacks happen at the application.” As a result, companies that dont 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 percent 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 percent.
Its one thing to say that enterprise application development and QA 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 wouldnt be a bad idea to consider security defects in their code.
There needs to be someone in the organization whos responsible for security issues, Lanowitz said. 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 percent of application development teams will have a person or team responsible for application security.
Creating a position for a person who gets paid to fret about security vulnerabilities isnt for the purpose of establishing a corporate worrywart. 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 thats what developers say they want. Someone has to have as their primary concern the risks that the company faces and to express to the staff and to management: “Here are our vulnerabilities, and heres what level of threat we have.”
While your users are swift to tell you about the features your applications need, nobodys going to tell you about the security holes you left wide open. Theyll just exploit them. Real application security, stressed Lanowitz, is built into all phases of the application development process.
Building secure test data is one example of the need to raise security consciousness. 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 an NDA (non-disclosure agreement) that promises “We wont do anything with it” isnt enough. “You cant just sign an NDA and expect that data wont get out,” Lanowitz said.
One thing that will help, happily, is better tools to address security needs. By the first half of 2007, expect to see most development tools integrating security needs. Recent acquisitions bear this out, Lanowitz pointed out, such as Watchfire Inc.s acquisition of Sanctum Inc., and Symantec Corp.s acquisition of @Stake Inc. But dont expect too much of them too soon. “This is an early market,” she cautioned. “We as customers must communicate with vendors to get the tools we need.”
Check out eWEEK.coms Security Center for the latest security news, reviews and analysis.