Web Application Firewalls, Professional Certifications, Website Trust Logos, and Compliance Regulations are contentious topics that spark spirited debates by those for and against their existence. For years I’ve studied thoughtful arguments voiced by many people about why they disagree with these things (solutions?) often with logic that is hard to discount. What’s interesting is the vast majority of the time it’s only the current implementation by particular security vendors that are opposed. We all know many vendors abuse customers with over promising marketing, under delivering products, selling/doing/saying anything for a buck, etc. This reality will never go away, we can only expose the behavior, and this is also very different from saying that the concept behind the solutions shouldn’t exist at all or be offered by someone capable of doing better.
For example, three years ago like basically everyone in the webappsec at the time, I was a staunch WAF opponent. The WAF concept made no sense to me because why would anyone go through the pain of implementing such a device when they could simply fix the code and be done forever? That is until one day while compiling Sentinel vulnerability statistics and the volumes being identified revealed a problem so massive, pent up by over a decade of egregiously insecure Web code, that it obviously could not be solved with available fix-the-code resources (time/cost/skill) anytime soon. IT Security personnel also shared their pain of having no authority over development groups, no juice with the business to fix vulnerabilities over adding new features, and limited options to protect websites in which they were responsible for. Malicious exploitation seemed to be the only thing that genuinely stimulated action.
IT Security clearly needed an operational solution. The only answer to the aforementioned problem was the promise of a WAF. Whether not they functioned as advertised became immaterial, the bottom-line was we needed WAFs to work! Seriously, it's insane to think its possible to mitigate millions of vulnerabilities across millions of websites, even if you could find them (the vulns or the sites). Seeing the writing on the wall I invested myself in WAF technology changing my conceptual opinion to implementation and set out to see what WhiteHat could contribute. That eventually led to the (VA+WAF) solution where vulnerabilities found through our assessment process could be imported as customized rules into a WAF. This provides a viable option to mitigate now, and remediate the source of the problem in the time and manner that made business sense ... to them.
As always I’m curious to know what other think and how they characterize their opinions according the following solutions. If you disagree with them, is it on the basis of Concept or Implementation (and why)?
Web Application Firewalls - ?
Professional Certifications - ?
Website Trust Logos - ?
Compliance Regulations - ?
9 comments:
Web Application Firewalls - As far as possible in a non-perfect world, I am good with both the concept and the implementation of web application firewalls. As long as you know what they are good for and understand that the remediation of ANY web application flaw is in the code then WAF is a solid solution.
Professional Certifications - As the holder of multiple certifications I have to agree with the concept and but disagree with the implementation as I know several people who have intense workshopped and got certs as well without any specific real world experience. The certification is a great way to open the door, but if you can't walk the walk and talk the talk in an interview (and the interviewer should know this) then it is a waste... unfortunately the can't walk the walk/talk the talk usually isn't discovered until after the paper certified employee can't perform as expected.
Website Trust Logos - Cannot agree with the concept or the implementation. Security (as required for a website trust logo) is a measurement of an exact moment in time and 20 seconds later can be null and void. A logo on the site doesn't show expiration, validation or anything...
Compliance Regulations - I love the concept but struggle (as most do) with the implementation. Getting past the 'checkbox' mentality in compliance regulation is difficult and staying in 'checkbox' mentality should be considered criminal.
A bunch of naysaying by me I know... but really, unless your company is behind you 100% it is difficult to match up what you want in one of these solutions with what you get when put in place.
...but that's just my opinion
WAFs - Im in agreement, but also believe they can feasibly do much more then they do now. All in good time.
Certs - Once again, I'm with you. Probably the reason why I've not obtained one, well except being a Certified ASS ;), nor given them much weight to candidates over work experience. Still, there is room for really good ones to cut down lists of applicants.
Logos - Up until recently, I disagreed with the concept as well. Now, I'm of the mind that there must be SOME way for an end-user to gauge the security of the site their doing business with. I don't see any other reasonable way except a trusted third-party logo, if only done so with integrity -- there's the rub.
- Compliance. What can I say, I agree. :)
WAF is a bad concept.
Application hardening and application monitoring are good concepts. WAFs (and VA+WAF) usually don't implement either of these, which is why they are epic fail.
Scanning the source code with the SRE configuration generator from the Microsoft Anti-XSS library Codeplex project is not a WAF, right? Or is it?
Mod-security monitoring "missing output encoding issues" on the outbound (the same ones that the SRE configuration generator fixes above) is not firewalling -- that's application IDS, right?
What does VA+WAF do? What does WAF do? Prevent web server issues, sure, I'll give that (but regular IPS can do this...). Web servers are not web applications, though, so really this is a misnomer.
We can block CSRF with Mod-security or Microsoft's AntiCSRF IHTTPModule. We can block parameter tampering (et al) with GDS Security's SPF. We can prevent data-flow issues in the application with dynamic taint tracking using CORE GRASP. But we cannot, and probably will not be able to solve more complex control-flow issues that focus at the domain logic of applications. Are these really WAFs? Do they meet the criteria necessary to fully protect an application?
I would say that these (AntiCSRF, SPF, GRASP) are exploitation countermeasures, much like SafeSEH, ASLR, or DEP. They do miss things and have their own vulnerabilities (although we'd like them to fail-closed). But these vulns are nowhere near as severe as a XSS in the security reports from a commercial WAF offering. Or the unpatched Linux OS vuln on a network appliance WAF.
We all know that it's really the application that is the problem, and when there are ways of automating context-aware escaping with a templating system... it's sad to hear that developers are allowed to make mistakes. It's code generated for them! You can't make mistakes when there are process and tools that prevent you from making them. Let's invest the time and resources we'd spend on WAFs and dedicate that time to learning about and implementing strong process, controls, and powerful tools in the software lifecycle.
WAFs - Conceptually ok, but i disagree with many(most) implementations. In my opinion, they are way to easily made into a crutch by developers, and an easy out by management because they are the magic box in front of an application that is supposed to solve everyone's problems. If the WAF is protecting us, then is this vulnerability really that big of an issue? - ugh!
Professional Certifications - Again, they are ok conceptually, but many implementations are flawed and fall far short of adequately determining the true experience of the applicant. In their defense (due to my holding two), I believe they can be useful and helpful in interviews if the interviewer really knows the area they are interviewing for.
Trust Logos - My gut says no to both. Anything can be taken/forged/etc. off the internet. That really goes without saying. In so much as this, there is no guarantee that seeing a trust logo on a website means anything. They could have copied the code from another site, or completely fabricated the entire thing. I don't believe there is any way that a site can prove to its customers that it does business securely on the internet. At the end of the day, I think it comes down to trust.
Compliance Regulations - I like the concept, but think they at most should be used as a starting point and nothing more. Under no circumstances do I think they should be used as a comprehensive list of everything that should be done to secure a site/application. Nothing can do this except careful thought and persistence by those that understand the architecture and operation of the application. At the end of the day, my biggest peeve with regards to this topic is that the regulations are used as a measure of securedness - usually by those that have no idea of what they are trying to secure or how to properly secure it in the first place. This among all things is the most dangerous.
Just my $0.02.
Web Application Firewalls - I think the concept makes sense, but implementation is spotty. I know it is viewed as the easier option versus code reviews. But WAFs still take time and work from developers to properly configure. So, not only are WAF products implemented oddly (love the looks when you tell someone a WAF is on but has no rules out-of-box), but they're implemented in organizations poorly, too. "What, you can't just turn it on and it protects against stuff?" An inevitable victim of marketing and sales, driven faster than normal due to compliance clauses, if you ask me.
Professional Certifications - Certs are an inevitable thing and not really a fight worth spending time and effort on. For anyone that wants to, I would point out the huge differences between something like a Cisco cert and an ethical hacker cert. Cisco certs don't exist to drive profit for Cisco. Certs from training/cert houses are their revenue stream. Nonetheless, HR/public does key off them sometimes and they help demonstrate some level of interest or even expertise...
Website Trust Logos - If you spend absolutely no time thinking about them, they're fine. But spend even 10 seconds thinking about them and they're still, point-in-time marks on a web page that have little more meaning than a "w3c compliant!" badge or "get ie8" button from 1996. Third-party validated stuff (like Network Solutions SSL verification buttons) are a step up, but come on...no one ultimately cares and they make sites look silly. It just extends the trust factor; users need to trust the provider (e.g. do you trust McAfee with their HackerSafe logo? No...)
Compliance Regulations - This will have to depend on how they're used. The concept is sound; we need summaries for management and something to achieve as a baseline, etc. Implementation will never match up to the concept, but if we accept that from the start, then at least implementation can be satisfactory enough to make a difference. So, ultimately I am happy with this. Then again, it's like going to a low-budget Siegal movie and knowing to expect entertaining garbage; it fits the need if you're framed correctly.
Is compliance going to save us and being compliant lead to ultimately security? Simply asking the question illustrates someone with a poor frame of the problem, since nothing will give ultimate security. Those people will be waiting their entire careers for the perfect compliance...
WAFs - as long as they are being used as one layer in a multi-layered defense strategy, then I can agree with both the concept and the implementation. It's when someone takes bad code, throws up a WAF and thinks they are ok that I disagree with.
Pro Certs - I mostly agree with @corio on this one. They are mostly useful for non-tech people to believe you know what you are talking about. It's funny how many people havent taken me seriously on a vulnerability until AFTER i've told them I'm SANS certified. ::sigh::
Website Trust Logo's - The concept is good (IMO) but the implementation so far has been horrendous.
@Matt, LonerVamp, and gilzow - Great stuff! Thanks much for sharing. See this is what I'm finding most interesting. When people voice shortcomings in these particular solutions, it's on the implementation side rather than concept.
This I find promising and a good opportunity to make significant improvements. Simply not enough hours in a day. :)
Jeremiah, wouldn't it be cool if we could get one weekend without another WAF debate... I must be biased but IMHO discussing ASS certifications is more fun (and somehow relevant).
Full disclosure: I'm working for a company that (also) develops WAF solutions. I'm an advocate of WAF+VA and WAF+DAM as well.
Here's my personal perspective. I apologize for getting personal but I believe that historical background is beneficial. There must be some benefit for the gray hair.. (kids can learn about the old man http://www.youtube.com/watch?v=y5x1l1GAxRk):
In 1996, while I was working for an ISP and a hoster (one of the few AIX-run ISP. Who can it be :-), we used code review, CGI wrappers and modified every piece of code to make it more secure (I'm writing "we" but the real credit goes to other members on our team). At any rate, in those days I believed that application security should be achieved with code review and fixing the issues, wrappers, proper chowning etc. Over time, it became clear that fixing the code is not good enough: sometimes you do not own the application, do not have the time to fix it, can’t afford to hire the right people etc.
Fast forward few years and here we are at the dot com bubble era and I find myself involved with some of the first WAF solutions (Sanctum, Gilian, Kavado, Magnifire just to name a few). Those solutions solved a real business problem (but not ALL problems related to web application security) but the companies had other challenges to solve and real life implementations of 2002+ were different than 2000-, when the products were first designed. If you experienced a WAF before 2006-2005, check out the current solutions.
Fast forward and we are at 2009:
1.Web applications are the #1 method to connect users, organizations and deliver solutions.
2. Organizations are being pushed to deliver solutions faster, react to market changes faster or vanish.
3. Organizations are being hacked (if you believe the wired story about the “analyzer” he got ~ $10m for few sql injections…)
4. Identifying code issues and then fixing it and then testing and verifying still takes time.
5. Starting SDLC processes still takes time and money. ROI: months to years.
So, it turned out that when a WAF is deployed and configured properly it will provide a very efficient and cost effective solution to mitigate web application risks.
When it is integrated into the development process, the benefits are even higher.
Sure, it will not solve EVERY vulnerability but when it is used it will:
1. Secure your applications to mitigate risk while code is developed.
2. Solve 3rd party packages issues.
3. Provide great reporting and control
As @gilzow wrote, WAF should be part of a multi-layered defense strategy.
Yes. this include code review and fixing the code.
Have a great weekend...
-- Sharon
(BTW, check http://blog.imperva.com/2008/11/dynamic-profiling-part-i.html ) it talks about our technology implementation.
WAF - To add to Vamp's point, in my experience WAF implementation can be a result of a knee-jerk response. Developers aware of coined phrases such as SQLi and XSS can be completely unaware of how the actual attack works and how to defend against it. Take in turn the typical security group who with their CISSP and Security+ are the interface between their Lead Developer(s) and the third party tester. Both these groups, one proven to be unqualified and the other edging towards shaky, are the only two entities responsible for the configuration of the WAF. Anyone see a problem?
I can say I have seen this scenario more than once. Bottom line, everyone finds faith in the foxhole.
Post a Comment