In trying to advocate for the implementation of software development security best practices, I've hit a roadblock: The top development manager says that because we have a Web application firewall (WAF) in place, it'll serve as a catch-all against any Web app security flaws our developers fail to catch. Can you help give me some good counterarguments as to why we shouldn't simply rely on the WAF to protect us from bad coding practices?
Ask a question
SearchSecurity.com expert Michael Cobb is standing by to answer your questions about enterprise application security and platform security. Submit your question via email at firstname.lastname@example.org.
Your manager may have seen that requirement 6.6 of the PCI Data Security Standard (PCI DSS) offers two options to protect Web applications against known attacks. The first is a review of all Web application code developed in-house; the second is to deploy a WAF positioned between the Web application and the client. You should point out to him that the Information Supplement goes on to say, "Proper implementation of both options would provide the best multilayered defense." In the modern threat climate, there is a strong case for both deploying a WAF and allocating time and resources for improving software development security practices.
While a WAF provides an important line of defense against known and some types of unknown attacks, no single technology can be relied upon as a cure-all. A WAF, for example, won't protect enterprises against application logic flaws, which can easily occur given the complexities of Web 2.0 applications that run a lot of dynamic code, or underlying network and operating system-level vulnerabilities. There are ongoing costs, too. WAFs have extensive logging capabilities, and administrators need log analyzers to make the most of this additional information.
This is where the benefits of secure coding and code reviews kick in. By solving the problem at the code level, the number and severity of any security-related design and coding defects is reduced, thus improving the overall security of the application dramatically. Although future code revisions still need to be reviewed, applications developed using secure development practices shouldn't require the same level of ongoing care and maintenance as those reliant solely on a firewall for protection.
Probably the best argument you can make in this case is to mention the success that Microsoft has experienced in improving the security of its products since introducing its Security Development Lifecycle (SDL). The SDL has helped set the standard for the whole software industry, with other companies, including Cisco and Adobe, adopting it or building their secure development practices based on it. Microsoft measures its success in various ways, including the number of vulnerabilities identified in a product a year after its release. Forty-five percent fewer vulnerabilities were reported a year after the launch of Windows Vista, the first Microsoft operating system to be developed using the SDL, than pre-SDL Windows XP; SQL Server 2005 had 91% fewer vulnerabilities than the pre-SDL SQL Server 2000.
By having better internal software development security best practices, enterprises will not be so reliant on WAFs to successfully stop attacks against their applications. Coding with security in mind makes an application more robust, reduces its attack surface and increases its ability to withstand attack. A WAF is never going to prevent every vulnerability from being exploited, so fewer coding vulnerabilities makes an application a less attractive target for would-be attackers.
If management is still not convinced, then a dramatic demonstration of the need for secure application development would be to attack your own application. The safest method of demonstration would be to run the application in a virtual test lab and use a tool such as Metasploit to attack it. If a vulnerability is discovered, a proof-of-concept payload can be used to show how an attacker can set up a reverse shell or other backdoor into the application and system on which it runs. This would clearly show how a vulnerability in your application could be exploited despite the presence of a firewall.
This was first published in November 2012