It's a problem at many organizations today: developers are so narrowly focused on quickly building feature-rich applications that security becomes an afterthought.
The task of securing those applications is often left to others -- traditionally, systems administrators who can wield firewalls, intrusion-detection software and other weapons at the network perimeter after the applications have been deployed.
"The industry has been treating security as a perimeter issue -- keep the bad guys out of the castle, and everything is fine," says James Whittacker, co-founder of Security Innovation, a company that provides security assessment and testing services. "The bad guys get in, or they are already in [because] they are employees at our company. The lion's share of the burden falls on application developers to make sure it's not their application that is the entry point for a breach."
Yet few organizations have standardized efforts to address security inside the perimeter, says Ron Exler, director of research operations at Robert Frances Group.
Finding a fix
According to research firm Gartner, although many companies have made significant investments in tools to secure production applications, fixing security flaws prior to production can generate significant cost savings. If 50 percent of vulnerabilities were removed before production of purchased and internally developed software, enterprise configuration management costs and incident-response costs could be reduced by 75 percent each, Gartner says.
To do it right, companies need to write a business application profile and a user application profile as part of the development process, Exler says. A business application profile details what an application does and its various components. A user application profile lays out the likely users of the application and how they will be using it.
"Security definitely ties into both the application and the users," Exler says. "As you are developing, you need to be cognizant of how the application is going to be used and the flow of it."
After the profiles are completed, IT security people can be brought in to analyze the security scenarios of these profiles. "You can see the potential weaknesses in the application, in the user workflow, and then you can see where you can build protections," Exler says.
The testing and quality assurance phases also should include a focus on security. An application that doesn't meet security requirements should be considered defective, just like an application that has errors or bugs that result in performance problems, Exler says.
But even more important is to change the "code and go" mindset of developers. "If security needs to be raised in importance in the application development process, it should be part of the developer's performance plan, just like showing up on time or writing code with fewer errors," Exler says.
Finally, companies should also be scrutinizing the security practices of their IT vendors. Exler suggests that companies add compliance with security requirements as part of service-level agreements.
Rigorous review
A healthcare organization has already ramped up efforts to infuse the company's application life cycle with preemptive security efforts.
Beginning with the technical design and review phase for new applications, the company evaluates for security risks and builds steps into the design and documentation that are aimed at eliminating potential holes, says Frank Enfanto, vice president of operations delivery and information security at the organization. For example, it might use domain modelling or add permission- or role-based access to secure code, he says.
"We try to ensure we are consistent from project to project. That gives us a certain level of guidelines for developers to use," Enfanto says. "We also provide developers with certain coding standards that help mitigate general security risks."
The healthcare company conducts negative application testing to try to find security flaws that could allow unauthorized access to an application once it's deployed. The organization also scans its applications with intrusion-detection technology to identify potential security holes in the code, but those types of tools are immature and return a lot of false positives, according to Enfanto.
"Our approach is not to just tell the coders to do this and test it and assume we are OK," Enfanto says. "Whatever you are doing in development and design, you are doing it in a pristine and clean environment. It is not the real world until it is deployed."
Test it or toss it
At Pentair, a water treatment and storage product company, vendors are required to submit their Web application or hosting products to be scanned for security vulnerabilities by SPI Dynamics' WebInspect tool.
"If they don't allow us to run the tool and find the vulnerabilities, I am not interested in allowing them to host my data," says Paul Samadani, Pentair's director of corporate IT. "We've been able to eliminate products or tell vendors they have to go back and fix a product that had issues."
The tool was designed to identify vulnerabilities within the Web application level at all phases of the application life cycle, including development, quality assurance, production and auditing.
For internal development, Pentair uses WebInspect to check any changes to code or new code developed for Web applications. In addition, the company has customized the product to ensure compliance with internal security policies.
The cost-benefit analysis for these tools is similar to that for buying perimeter tools, according to companies that have made the leap to building security protection into their applications.
"You can recover the cost of the technology on one mistake that you find," Samadani says. "Within seconds, someone will find that vulnerability, and you won't even know about it until the information is gone. The cost, if all your intellectual property leaks out, is tremendous."