Software development life cycle lacks app security practices

The software development life cycle has a gaping hole in it: application security. As networks have become more secure, attacks against applications have greatly increased, and many professionals don't know how to incorporate security into their SDLC.

What we are doing right now is not working, Ryan Berg warned his audience at the Software Testing and Performance conference last week in Cambridge, Mass. Berg, director of Advanced Technologies at Ounce Labs, offered frank, practical advice to his listeners on integrating security into their development processes.

Software vulnerabilities on the rise
New, reported software vulnerabilities are steadily increasing, from just 417 in 1999 to nearly 6,000 in 2005. The reason for that, says Berg, is "because we must increasingly provide access to our applications and data via the Internet." And malicious users can easily find vulnerabilities using Google and other tools.

To stem the tide, organisations "need to become proactive instead of reactive when it comes to security," he said. "There needs to be a shift from the 'prove to me that my application is exploitable' mentality to one which embraces defense in depth."

Addressing the security of applications is as much an organisational shift as it is a technical one.  Ryan Berg director of Advanced TechnologiesOunce Labs

With pressure to create innovative, complicated applications rather than secure ones, it's hardly surprising that software vulnerabilities are increasing.

All about the applications
"It used to be all about the network," Berg said, "now it's all about the applications." Many in the IT industry have heard this before, but it may need to be repeated another three or four thousand times before organisations begin churning out applications that are secure from the start, he said.

"IT in many cases is still focused on perimeter security, and more recently on authentication and authorisation ... because these are things over which they traditionally had control," Berg said.

Many IT professionals want to secure their applications, but they haven't done so because they don't know how. Unlike network security, application security lacks a playbook to which professionals can refer. Application security requires a rethinking of the security problem, he said.

Berg notes that "more sophisticated IT organisations are using penetration testing, but this is often too late."

There is also more pressure on the industry to pay attention to application security. With at least 70% to 80% of Web sites sporting a serious vulnerability, insecure applications are making headlines. (See sidebar.)

Newsflash: Applications are insecure Popular social networking sites have been beset by XSS exploits. Online banking sites, despite their best efforts, are still considered insecure by some and are subject to content spoofing and other scams. E-commerce sites can have their prices changed by malicious users exploiting SQL injection vulnerabilities. Not to mention the dangers legitimate customers face when stolen cookies may lead to stolen identities. It's no surprise, then, that customers are shopping and banking less online. Unfortunately, Web application attacks are seen by many as the biggest threat to enterprise security.

More than avoiding negative press, organisations need to worry about government regulations. Sarbanes-Oxley, CISP-PCI, HIPAA and ISO 17799 are just a few of the regulations affecting application security.

A new approach
Application security needs improvement, Berg stressed. And that will require the cooperation of many people within an organisation. "Addressing the security of applications is as much an organisational shift as it is a technical one," he said.

"We as an industry need to recognise that this is not a developer problem," noted Berg. Too much of the responsibility for security is laid at the feet of developers, and too little information is given to developers to aid them. "You can't blame developers for what was done insecurely if you don't give them the knowledge and tools to do it securely in the first place," he said.

"A concentrated effort to define a set of core coding best practices that are communicated, implemented, and then tested against will have an immediate, significant impact on the security of projects in development," Berg added. "This is a development problem and requires a solution that expands the SDLC all the way back to requirements."

Development management, corporate security, audit and compliance, quality assurance and software development all need to work to secure applications, Berg said. Security must be baked into virtually every aspect of the design process, and it should be implemented as often as is practical.

If that sounds impossible, Berg offers some practical and applicable objectives for IT professionals. He urges improving upon existing development processes, not creating new ones. And using models as a base will make adoption easier. He emphasised three different models -- independent, distributed and centralised. Each model has its own advantages and disadvantages and organisations should carefully consider which one is most beneficial to them. For more on these models, including detailed diagrams, see Berg's white paper, Secure at the Source.

Obstacles to application security
There are a number of misconceptions that prevent IT professionals from integrating security into the SDLC. Berg has a response to each of these.

For example, instead of resigning to the idea that security and development are too disparate to work together, Berg advises that support from management and mutual goals will smooth the course. Another discouraging belief held by many is that time constraints and the push to release as soon as possible won't allow for security testing.

Time constraints are a major concern for some in the security industry. Even behemoth Microsoft, when developing Windows Server 2003, stopped production for two months in order to concentrate on security. But Microsoft can do that. For smaller companies, Berg maintains that incorporating security is efficient in the long-term, and this sentiment is echoed by other experts. By reducing maintenance and patch costs, Berg added, companies ultimately save time and money.

The final obstacle that Berg dismisses is "[P]eer review sufficiently addresses security issues." It does not, although it can be a quality measure, he said.

Incorporating security into the SDLC is essential to application security. However, this concept is alluded to far more often than it is implemented, Berg said. He a practical way to begin the process.

A solution is needed that "requires more cross-functional involvement," he said. "QA needs to incorporate security testing along with use and abuse testing." This includes a use case that "models the hacker." Audit and compliance need to clearly state what the requirements are.

Incorporating application security How to integrate security into your SDLC Steps you can take now to begin building in software security Application security more of a priority, but practices still lag

Finally, management must be engaged in the endeavor. Management must "be involved to make sure all the groups are interacting," Berg said, and they must "apply the additional resources, training and tools where appropriate."

To accomplish those goals, organisations need a comprehensive plan that can be tracked, he added. "I recommend the organisations start small: identify a cross-functional team of stakeholders, build a set of standards using well-defined industry best practices, and identify a project for implementation," Berg advised. "Then build from there."