App Developers Need to Redouble Security Efforts

By Esther Schindler  |  Posted 2004-09-30 Email Print this article Print
 
 
 
 
 
 
 

WEBINAR: Event Date: Tues, December 5, 2017 at 1:00 p.m. ET/10:00 a.m. PT

How Real-World Numbers Make the Case for SSDs in the Data Center REGISTER >

Development and QA teams have to address security issues early in the process, but that's always a hard sell to management. Here's one statistic that may make a difference: According to Gartner, 75 percent of hacks happen at the application level.

PHOENIX—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 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 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 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.

It's 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 wouldn't be a bad idea to consider security defects in their code.

For insights on security coverage around the Web, check out eWEEK.com Security Center Editor Larry Seltzer's Weblog.

There needs to be someone in the organization who's 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 isn't 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 that's 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 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 wide open. They'll 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 won't do anything with it" isn't enough. "You can't just sign an NDA and expect that data won't 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 don't 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.com's Security Center for the latest security news, reviews and analysis.

Be sure to add our eWEEK.com developer and Web services news feed to your RSS newsreader or My Yahoo page

 
 
 
 
Esther Schindler has been writing about software development tools and trends since the mid-90s, and about the effect of technology on our lives for far longer. She has optimized compilers, written end-user applications, designed QA processes, and owned a computer retail and consulting business. She lives in Scottsdale, Arizona, with a husband, two cats, and a well-known tropism for anything chocolate.
 
 
 
 
 
























 
 
 
 
 
 

Submit a Comment

Loading Comments...
























 
 
 
 
 
 
 
 
 
Thanks for your registration, follow us on our social networks to keep up-to-date