Hiding problems is not

prevention">
A warning, however, came from a separate conversation eWEEK Labs had with Network Engines Amaral, whose experience suggests that developers may have a dysfunctional idea of what it means to "prevent" a security problem. Its not prevention, he said, when developers adopt practices that hide problems rather than kill them.
For example, developers use S-HTTP (Secure HTTP) "to ease deployment, to avoid creating added work, and use a protocol thats generally not inspected," Amaral said. "Theyve leveraged an exploit."

Early last month, though, three application firewall vendorsTeros Inc., NetContinuum Inc. and Imperva Inc.threw down a challenge to other security vendors to submit their products to independent testing by International Computer Security Association Labs (a division of TruSecure Corp.) to determine their effectiveness against application-level attacks. Theres considerable room for confusion in this space, and eWEEK Labs tends to eye with approval anything that condenses the vapor of marketspeak into the substance of proven capability.

Old-code growth rings
Another serious threat to dynamically evolving applications is the long-lived presence of code remnants, each perhaps the contribution of a different generation of development team and technique.
"One line of code can make an application vulnerable," said Denims Cornell.
"[In] a bank portal that was ready to go into production, there were three or four pages in an obscure subdirectory that had SQL statements that would admit actual code. We saw them using stored procedures and figured that theyd be mostly OK, but when we ran the tool, we found obscure pages that werent high-value targets but that had very serious flaws," he said.
"Even if theres 40,000 lines of code and you just change one, it could create a SQL injection opening," said Denims Dickson. "Conventional quality assurance approaches wont catch that."
Denim employs an application-level vulnerability scanner, ScanDo, from Kavado Inc., to automate its end-to-end analysis of complex systems. Cornell acknowledged the conventional wisdom that "its 100 times cheaper to catch a mistake at design time" but said that with Web applications, often its not possible to say that a vulnerability exists until the entire system is running front to back.
An automated scanner also helps developers avoid the blind spot that comes from knowing what an application is supposed to do and what kinds of input it expects to receive. "Most of these hacks are definitely unexpected behavior," said Jeannine Bartlett, Kavados vice president of strategy.
Most developers dont make adequate use of the Common Vulnerabilities and Exposures data at www.cve.mitre.org. "I was speaking to a group the other night," said Gary Miliefsky, CEO of PredatorWatch Inc., in North Chelmsford, Mass., "and I said, Raise your hand if you know what a CVE is. No one raised their hand. A developer needs to know when a product is opening a port or using any other resource what vulnerabilities its opening."
Network Engines Amaral offered another perspective on why there will almost always be a need to seek out rotten code in even the latest release of an application. "Id bet that 50 percent of all the leading applications had their origin in a startup company at one time or another. Its a new idea, and your goal is to build share, and you write software without appreciating its deficiencies."
Throwing away the "startup code" may feel like throwing away the startup capital, but sometimes it may be a necessary step on the way to offering customers and clients a truly secure application foundation.
Technology Editor Peter Coffee can be reached at peter_coffee@ziffdavis.com.SecurityDeveloping An Applications ViewAccept nonzero risk

All nontrivial applications grant access to assets

Web-enabled applications have large attack surface and small opportunity for code review

Security must be built in at the level of development practice, not added as a network-level embellishmentAgree on terms and goals

Peter Coffee is Director of Platform Research at salesforce.com, where he serves as a liaison with the developer community to define the opportunity and clarify developersÃÃÃ technical requirements on the companyÃÃÃs evolving Apex Platform. Peter previously spent 18 years with eWEEK (formerly PC Week), the national news magazine of enterprise technology practice, where he reviewed software development tools and methods and wrote regular columns on emerging technologies and professional community issues.Before he began writing full-time in 1989, Peter spent eleven years in technical and management positions at Exxon and The Aerospace Corporation, including management of the latter companyÃÃÃs first desktop computing planning team and applied research in applications of artificial intelligence techniques. He holds an engineering degree from MIT and an MBA from Pepperdine University, he has held teaching appointments in computer science, business analytics and information systems management at Pepperdine, UCLA, and Chapman College.