Cenzic 232 Patent
Paid Advertising
web application security lab

Comparing/Contrasting Network and Application Security

There’s an absolutely brilliant retort to one of Jeremiah’s post that was written by ntp about how we have lost sight of how the network security battle was (mostly) won. I was actually stunned that someone bothered to write all that down (it’s quite a read, I’m warning you). But I think he articulated a point that has up until now been very poorly thought through. Yes, we won the network security war. Our perimeters are mostly safe not because of Firewalls but because of all the access controls, protections at the server level, protections we’ve forced on the clients, etc… In fact I know a number of companies that have completely gotten rid of firewalls because they are both a single point of failure and they have rate limits that properly configured servers behind F5’s or SQUID boxes don’t.

And now with the advent of JavaScript port scanners we have broken the concept of firewalls again - yet here we are, talking about how to improve WAFs so they can be our new firewalls. For some reason people tend to think that if we try again it will work this time. IPSs were a cool idea… active rule based firewalls, and you could make the argument that IPSs are really no different than WAFs (even that they are one in the same). But that’s not how we won the war. IPSs were a nice afterthought that came about long after we had solved most of our problems at the individual servers themselves. Firewalls were mostly a convenient way to segment traffic at that point.

Anyway, before I dig myself too deeply (because I know this is a contentious topic) I’m going to ask that you read his comments. Prepare yourself for a ride - it’s a long one.

4 Responses to “Comparing/Contrasting Network and Application Security”

  1. ntp Says:

    “…firewalls because they are both a single point of failure…”

    I saw that quote and had to make this joke:

    Firewalls only FAIL CLOSED when they are the root cause of downtime.

    Seriously though, thanks for the feedback and recognition. I think firewalls can be further validated if they are monitored for policy violations using differential firewall analysis. I would like anybody to admit that they know of at least one organization both relies on firewalls for much of their security and also that does DFA.

    Also - how many firewalls in organizations have “exceptions”? Some are managed exceptions; some are temporary. But some get put in place and stay that way for years until somebody notices the “allow from any udp source port 123 to any” rule.

    I’ve always wondered the difference between an IPS and a firewall. It’s all marketing, isn’t it?

    Remember when the firewall marketing game started putting Common Criteria and other certifications on their products? I have always wondered how interesting it is that vendors get third-parties involved in “certifying” their products without actually testing anything, let alone doing an assessment.

    Again, by “assessment” I don’t mean a checklist that you or your vendor fills out alone in a dark room… I speak only of generation fuzzing and massive batteries of code-coverage tests. If you are going to trust a program like a “web-vulnerability” scanner, or a hardware device such as a WAF - why not have the same validation routines put through them that you probably require on your own applications that they intend to protect?

    In network security, every device or software proxy (e.g. regular tcp proxy, xss-proxy, DLL/shared-library injection, hooking, et al) in the application path is a potential target for abuse. How is web application security any different?

  2. ChrisP Says:

    The vast majority of enterprises simply cannot get rid of firewalls for the simple fact that it would put them in a major bind with regards to regulatory compliance such as PCI.

    The difference between a FW and IPS is not just marketing - most firewalls don’t base their permit or drop decisions on signatures, it’s usually much simpler as it’s based on a L4 rule (permit any tcp port 80). Application inspection is typically limited to protocol conformance, which isn’t where the attacks are performed. An IPS is essentially a regex box - in theory, it can catch “anything” as long as 1) you are proficient in regexes 2) you are willing to cope with the incurred performance hit.

    IPS are less popular than FW because of the amount of log they generate (false positives) and the fear of false negatives. If nobody is going to sift through the logs, the IPS is pretty much useless.

  3. Jeremiah Blatz Says:

    I think ntp missed the point, and you are further off. Web app firewalls aren’t *the* answer, and they’re not a good substitute for secure web apps. What they can be (if they worked well) are:
    * An easy path to basic remediation of insecure web apps
    * Defense in depth

    A well-designed web app firewall is a pure whitelist device. For each web page, here ane the allowable inputs and their allowable values. Since it’s designed as a security device, it can make hard things (”basic html with no script”) easy. Imagine if myspace had one of these! Having a central place to validate all input is fantastic, especially if it can generate on-demand documentation for developers to review. Most web apps do not have anything like this, and are not tractable to rearchitect in order to support this.

    All the wailing and moaning about how having an effective app firewall is no easier that just securing your damn web app ignores some very significant points:
    * A web app firewall is (well, can and should be) a simpler device than a web app.
    * There only need to be 4-10 web app firewalls, there are millions of web apps
    This means that a web app firewall is both easier to secure than a web app (I’m cheating and including the web server infrastructure in “web app”), and will receive much more attention from security folks than the average web site.

    As for your argument about “here are some companies that don’t even user firewalls,” I call straw man. First off, these companies don’t deploy any firewall devices anywhere in the organization? At all? Secondly, these are not the common case. Most companies don’t have the performance issues, and most companies don’t have the expertise to properly harden even a few hosts reliably. For that 99%, firewalls are a cost-effective mitigation. Would every web app benefit from a web app firewall? Clearly not, but depending on who you ask, 70-90% of them could get something out of one.

    Web app firewalls are not *the* answer. They can’t protect you from logic errors, they require lots of configuration in order to work right, they impose significant performance penalties. However, they (if they work), can be a much more cost-effective way to mitigate XSS/SQL Injection/XSRF/buffer overflow/path traversal/etc. vulns in your app than rewriting it, and can provide some much needed depth of defense to web apps written by organizations that have a little security competence.

  4. RSnake Says:

    Whoah there tex. Hahah… Okay, first of all I had a long conversation with Jeremiah last night on the phone and we talked about this. I told him up front that I am in full agreement that WAFs provide a short term patch, but you still have to go in and fix it by hand in the long run anyway. He agrees. Relax. I’m not saying they don’t provide value, but I am saying that they aren’t a panacea and we need to set our expectations appropriately.

    At the end of the day, I have yet to see a WAF I couldn’t get around (even ones that are integrated into the application itself). Regex suffers from tons of logic faults. Read up on the turing halting problem or look at the XSS cheat sheet for evidence of this. I’ve literally bypassed every regex I’ve ever seen that attempts to stop XSS alone - let alone any of the other attacks. So while it’s not the answer, it’s not even particularly good at what it’s supposed to be answering, unless you know exactly the single thing you are trying to stop (which by that point is probably too late anyway in the case of server exploits).

    Secondly, you can call straw man all you like, but it’s true (having personally worked for two companies that don’t use firewalls in front of their web applications). And no, I wasn’t talking about intranets, I was talking about web applications (hence the title of the blog). I do try to stay on topic. :)

    And since we are on the topic, how many WAFs have you seen built to stop/modify egress traffic? If the QA environment has the same holes, or the WAF is deployed outside the corporate firewall, I can still get the people on the intranet or the application itself if it makes outbound connections to execute the commands on my behalf. I will agree that it is a small stop gap in the time period between when the issue is found and the hole is patched.

    So yes, I’m agreeing with you, they have _some_ value (just as I will agree that trust marketing, token authentication or just about any other flawed security concept has some small value). Would I deploy in front of an business application that had a million requests a day? No sir. Unlike Anti Virus which has a minor effect on performance of a single laptop, WAFs have degradation on performance for your entire production environment and add a single point of failure (and another potential target). Until WAFs get smarter, faster and actually reduce risk instead of add risk, I’ll be staying clear.

    However - and you can quote me on this one - there are better ways to build WAFs that have not yet been constructed.