People sometimes ask me how effective and where to apply a software security tool so I thought I would publish a few ideas on the subject. First, there are so silver bullet solutions for application security; tools play a role, but most tools have a greater impact if used earlier in the software development lifecycle. That is, if you use a static analysis tool in the software construction phase, running a dynamic analysis tool in the verification phase should tell you that you did a pretty good job fixing known problems. And testing your application in the deployment phase will provide some additional assurance that you are somewhat protected against emerging risks. But every time your application requires maintenance, it goes back to the construction phase, and should go through the same software assurance process before being re-deployed. If you have public-facing applications, legacy applications, and applications that have already had security issues, i.e., compromises, then maybe a Web application firewall should be part of your arsenal, but it does not address the root cause of the problem. A Web application firewall is a tourniquet for an application that has existing security issues or is high risk and can not defend itself. If the application was designed securely, built securely, and maintained securely, then it should be self-defending, and therefore, not require a Web application firewall.
Next, how about a legacy application that does not implement proper authentication or validation. Sure, you could integrate a security API like ESAPI, but what about using a framework that already has those capabilities built-in and instructing the developers on the best practices for using them? The best practices and mechanisms to build secure software should be part of the core software development frameworks and libraries and implemented as part of a standard software engineering process. Also, an organization should specify which frameworks are acceptable. If a framework does not provide capabilities to build secure software, it should not be used. Let’s go one step further and take applications that come under regulations like FISMA or PCI. All Web applications that are Moderate or High baseline should use a managed language such as .NET or Java and any additional frameworks or APIs should provide the developer with the tools to secure the applications. Oftentimes, automated static analysis tools only understand common software development frameworks and libraries. If you use bleeding edge or unsupported frameworks, or interpreted languages, your application may not be understood by automated static analysis tools, and can only be properly secured by a security-knowledgeable developer or application security expert. That is a poor model for continuous monitoring and maintenance.
Application security tools should be used by those people who best understand the application and how to write code. When an information security professional, who does not have a software development background, runs a Web application vulnerability scanner and turns up a ton of potential vulnerabilities, he/she has a hard time determining which results are false positives or true positives. Likewise, if a static analysis tool turns up several hits on an application’s source code, the best person to interpret the results is the software developer who wrote the application and has been trained in application security. The domain expertise is with the developers – the tools should be driven down to the developer level. Just like IDEs have plugins for unit testing, they should have plugins for static analysis, and that includes security. That is why compilers have flags for common errors, including security problems; so that the developers know that they must fix the problems in order to pass GO. More on this later.
