"Defense in depth" is a longtime security mantra, and the principle behind a layered security strategy at the network. But according to leading security experts, it is just as applicable to the latest battlefront -- application security.
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
While most organizations have deployed a layered approach to tackle security issues at the infrastructure level -- utilizing intrusion detection and prevention, firewalls, antivirus, antispyware and antispam -- a layered security approach for Web applications is a relatively new tack for many companies.
"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 life cycle, but you don't see enough security in the production environment. It goes without saying that hackers are targeting production systems."
And while there are vulnerabilities that do make it to production from development, not all production vulnerabilities existed in the development environment, Grossman said. "For instance," he said, "say there's a log file or password file leftover on the Web site. That didn't exist in development; it happened in the push cycle. You have to make sure your production system is locked down."
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 SDLC.
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 SearchAppSecurity.com.