In a recent TechTarget article, Gartner Analyst Ramon Krikken is cited talking about Web Application Firewalls (WAFs), Database Audit and Protection (DAP) and XML gateways as a lower cost ‘solution’ to the application security problem plaguing us today. He cites some nice work by WhiteHat Security on how bad the situation is, and basically says we should all give up on fixing software because it will take too long and cost too much. The claim that the solution is a WAF makes me want to cry. WAFs have their place, as we will discuss, but that is just a small part of the story.
While he is doing a service by raising the issue, he has a lot of work to do to understand the issues. To start with, he talks about the lack of research, and while we need more, there has been more than he is aware of and I will cite just some below.
Mr. Krikken’s approach mirrors the security immature organizations typical learning curve. This is something Security Innovation has discussed in our Application Security Maturity model from our research. Security often starts off with an overwhelming number of problems found by a scanner and generally an organization will throw its hands up or seek an alternative to dealing with the list. This is not unexpected. Imagine a magical bug finder scanning five years of untested development all at once and giving the software organization the results all at once. This is what happens with Static and Dynamic Security Analysis Tools (DAST, SAST) – years of development which ignored security being hit all at once. It should not be a surprise, but it often comes as one. Ultimately, as our Application Security Maturity model research shows, what happens is a curve somewhat similar in shape to something Gartner should know about – their Hype Cycle.
After finding a bunch of security problems, ignoring them or trying external solutions, eventually the organization creeps back up the maturity curve to use a combination of approaches to address the problems in ways that are now well known. We’ve been through this before at the system level. IT and Security used to not work well together on patching and system configuration, and security tried Firewalls, IDS and IPS to solve the security problem of servers getting owned by malware and hackers. Finally, IT and Security realized that they had to work together and we are in a vastly different place with patching and secure configuration maturity. This is why the bad guys have moved to the next porous layer – the application. Yes, the situation at the application is bad now as Mr. Krikken points out, but the answer is not to give up and try a band-aid that won’t work. We’ve been down that road.
The rapid proliferation of mobile apps is cited, and then WAFs and XML gateways are called for in the article. Of course, WAFs and XML gateways do not address many mobile application security issues to begin with, so this doesn’t make much sense. Of course he also calls for using the framework and platform security features, which is part of the building security in model which he is claiming will not work – again, a contradiction. Then he asks for a device which is ‘faster, cheaper, and ultimately just as effective’ like a WAF to avoid the ‘unending cycle of developing, testing, and implementing software patches.’ Wendy Nather of 451 Group did a great job on 'effective’ so I’ll jump in on the rest.
Research was done by Aberdeen and Forrester starting in 2010 on this topic which I discussed in a two part blog series on Application Security ROI (gotta get back to that) which shows that building security in is actually the most cost effective approach. This is not a surprise either, as it’s well known that the earlier in the development cycle a bug is found or prevented, the cheaper it is. Security issues to developers are often just a special class of bugs. Bad requirements multiply into bad designs which multiply into bad implementations. A process which addresses the problem as early as possible can fix one requirement or design problem early which could spawn a plethora of security findings in QA or a scan after deployment.
As pointed out by Aberdeen there are three classic approaches to application security vulnerabilities. Secure at the Source (also called Building Security In by Mr. Krikken), Find and Fix, and Protect in Play. Mr.Krikken conflates the first two into one, which results in many of his misunderstandings. When a company goes up the security maturity ladder and begins to build security in, they get off the cycle of testing and patching, because they avoid many more of the problems in the first place. There’s your faster and cheaper. No extra box on the wire, no coding WAF rules, less audit findings, less scanner findings – faster and cheaper all around.
The three approaches have their place. Protect in Play, like with a WAF is necessary for legacy or third party applications where no source is available and no patch is forthcoming. It is also good as a temporary solution to keep a critical app up while Find and Fix is happening. But in the long run, when a company can get there (and it will take time and practice), secure at the source is better with application security just like it’s better with system patching and configuration.
That would have been a good ending, but there are two other things in the article that need to be addressed. Oddly, the argument against WAFs is what it means for PCI compliance. PCI specifically calls out WAFs as one of the two approaches it allows. See PCI DSS item 6.6. So even in the knock on using WAFs in the article is wrong.
Secondly, and this is a myth that really needs busting, is the performance hit from building security in. First of all, no matter how bad it could be, compared to proxying everything through a WAF choke point (even if that were possible, again see Wendy’s post), doing things at the source is going to be vastly better from a performance point of view. In addition, unless you are talking about things like encryption (which is either necessary or not regardless of performance) building security in consists of good coding practices which only have a minor impact on performance. It’s like arguing against checking for error results from function calls because of the performance hit. Sure, it takes a few instructions, but for quality purposes, it is necessary and in reality doesn’t cost much.
Security Innovation has real world experience in this area and we offer lots of educational information on secure software development. When a company is ready, secure at the source (or building security in or secure SDLC) works. It takes an investment to get there, but companies like Security Innovation can help, and it’s proven that it saves time and money. Many leading organizations, large and small, waterfall and agile, lean and, well everybody is lean these days, have found that using a secure SDLC helps build software securely from the beginning, and decide where find and fix and protect in play fit, this making intelligent, cost saving, compliance creating, problem avoiding, mature application security decisions. And that’s no WAFing matter.
