"We've seen a big increase in the number of people who know that Web application security is important," said Jeremiah Grossman, chief technology officer and founder of WhiteHat Security Inc. in Santa Clara, Calif. and co-founder of the Web Application Security Consortium. "Those who are new to Web application security are looking for baby steps: What is Web application security? How does it impact my business? What are the top five things to do to protect myself?"
Samir Kapuria, principal security strategist at Symantec Corp. in Cupertino, Calif., said when it comes to application security, organizations should consider first the journey -- design and development -- and then the destination -- deployment and production. "Within each phase there are key elements an organization can address regarding security so it is built into the application," he said.
Grossman agrees that both the journey and the destination phases require security strategies. "You have to have a good solid design; it's hard to go back and change the foundation," he said. "But one thing that's lost out there is there is emphasis on a secure software development lifecycle, but you don't see enough security in the production environment. It goes without saying that hackers are targeting production systems."
So what steps can organizations take to lock down their Web applications, from the beginning of the journey all the way through to the destination? To start with, Kapuria recommends strategies at each "layer" or phase of the software development lifecycle.
1. Requirements "Traditionally, developers look at this phase to define functionality. It's also important at this phase to define the information security goals and strategy from a security perspective. You're outlining areas of analysis and known security issues with that type of application," Kapuria said.
For example, an application that contains nonpublic information may require encryption. "That needs to be thought through up front in the requirements phase," he said.
2. Design "From a security perspective, you start doing threat modeling, input data types, security use cases and security architecture," Kapuria said. "At this point in time, it's more of a manual process that requires experience and understanding of the threat landscape."
Kapuria said knowing the threats determines the way the way an application is developed and what processes are employed. "You establish practices around embedding security within those processes and training people [in those] good practices."
3. Development "Coding standards were developed for functionality; now they need to be developed around security," Kapuria said.
What's helpful, Kapuria said, is to have a centralized security model that can be reused. "At this phase, what organizations find useful is a secure build configuration and known vulnerabilities libraries."
4. Testing "At this stage you assess the security of the application in the development or staging environment," Kapuria said. "You do bug tracking and validation."
5. Deployment At this stage an organization should implement security management procedures, monitoring requirements and security upgrades procedures. "You need to account for those things so can't inherit risks that have evolved over the life cycle; new patches tend to be key," Kapuria said.
6. Operations Crucial at this stage are logs, security incident reporting and change control and management, Kapuria said.
Grossman has some additional tips:
- Make people aware of Web application security and its importance.
- Do vulnerability assessments.
- Use the vulnerability assessments to measure the effectiveness of your security.
- Implement strong input validation. "If you did nothing else on security, this is the one thing you need to do," Grossman stressed.
- Implement a Web application firewall.
There are tools available to help with a layered security strategy for applications, such as automated source code scanners and vulnerability scanners. "One of the major issues with software developers is when they make a security mistake, they don't know it's a security mistake," said Brian Chess, chief scientist at Fortify Software in Palo Alto, Calif. That's why the first tool Fortify rolled out was for source code analysis, he said.
However, tools have their limitations, Kapuria said. "The challenge with applications, and the magic of application, is that people can code the same functionality in an array of manners. Because there is no one consistent way to code the same functionality, the types of attacks vary as well. When you're looking at the tools space, most create a lot of false positives. You can't necessarily automate everything a person or consultant or malicious person could do. [Security] is still a people-oriented solution."
WhiteHat's vulnerability assessment and management service is a case in point. WhiteHat uses an automated Web application scanner, but then it uses human knowledge to weed out false positives from real issues, Grossman said.
Defense in depth also has its limitations, Chess said. "Sometimes people will hide behind 'defense in depth' as a reason to not measure the effectiveness of the security practices. They'll say, 'I know what I've done isn't perfect, but with defense in depth -- there's somebody behind me.' It's a bit of a safety-net mentality."
This article originally appeared on SearchSoftwareQualithy.com.