I guess we'll have to agree to disagree.
On Mar 27, 2008, at 5:43 PM, Arian J. Evans wrote:
So basically all we have left is "reducing attack surface by IP restrictions?" And we don't even need a firewall for that. I do that in my webserver.
I said in my first reply that firewalls were useful for:
+ Port and protocol pairing + IP restrictions
and I'll add
+ Nice centralized management GUI for that stuff
You could add rate limitation, but most real world firewall deployments don't have enough memory to handle many IPS and anti-DDoS functions.
In the real world I see very little web software with IP restrictions.
In the real world firewalls don't seem to be useful at protecting sensitive information in our vulnerable software.
It sure doesn't seem to be helping much with protecting cardholder data either.
So, I think we are agreeing on what firewalls can be used for.
Yet I'm still saying that compared to all the very real threats we're facing, the attacks that we are undergoing, and the software weaknesses that are being exploited....that's just not really that relevant or useful.
And all I'm hearing in response are the mindless platitudes of "Defense in Depth" and "Reduced Attack Surface".
Um, okay, sure.
-- -- Arian Evans, software security stuff
reformed hacker turned animal rights activist to meet hot chicks concerned with those tasty animals
On Thu, Mar 27, 2008 at 2:30 PM, Justin Thomas <justin@xxxxxxxxxxxxxxxxxx> wrote:"Can someone put forth some meaningful statement about how your
network firewalls somehow protect your applications fromthe WASC 24 or
Mitre CWE or Phishing or web service-specific attacks?"
I'll bite.
By limiting basic exposure. If a service exists to facilitate a
partner connection, for example, only that partner should be permitted
through the perimeter (or, perhaps, partner) firewall (by their
network addresses) to access the servers and network ports on which
that service is exposed.
On Thu, Mar 27, 2008 at 1:34 PM, Arian J. Evans
<arian.evans@xxxxxxxxxxxxxx> wrote:
Well, let me re-iterate lest your points be confused for my statements. I'm not sure whom you were responding to, but I want my points to be clear:
1. I said the perimeter is dead. And it is. Sorry, but you're just wrong. I could write ten paragraphs or you could go visit salesforce.com, successfactors.com and docs.google.com, and see if any of your "large enterprise's" data is in them.
2. I never said WAFs are useless. I said the exact opposite. I said the vendors' marketing messages are the problem. I also said the vendors aren't doing much to address semantic issues (aside from marketing drivel), which are very important in our web apps (but less in web services).
3. I never said web services change everything. But I do think their use-case changes a lot.
All your CORBA apps ran over a flat internal network, maybe a WAN. And they ran un- encrypted. Same with all your other headless apps or message queue systems.
The controls were all server side, if there were any controls.
Web services change two paradigms:
3.1 The contention methods you use to connect them (e.g. PUBLIC not private internet and encryption)
3.2 Data constraints and validation: Most "web apps" put their data control somewhere around the presentation layer or close in MVC.
Once you glue a bunch of web apps together via web services, and everyone on the planet is doing this today, half of your data controls in your application no longer work as designed.
Seriously. The perimeter is dead. Get over it.
There hasn't been a SQL Slammer worm in OVER FIVE YEARS. Wake up. It's Phishers and SQL Injection bots, and you aren't dealing with either one of those via your "perimeters".
I have asked repeatedly, and I'll ask again:
Can someone put forth some meaningful statement about how your network firewalls somehow protect your applications from the WASC 24 or Mitre CWE or Phishing or web service-specific attacks?
I'm still waiting for some useful examples, beyond ipchains config to rate-limit in case the "hackers" decide to DoS your web service some day (which, incidentally, in 10 years of responding to incidents, I've only seen used against online gambling sites).
I will even humor syntax arguements about how your IPS or "AI" can detect and remove ASCII Char(127) or a "UNION SELECT * FROM *" from a querystring. Or whatever "thing" it does to protect you.
If not, case closed, thread dead.
-ae
On Thu, Mar 27, 2008 at 10:44 AM, Rafal M. Los <rafal@xxxxxxxxxxxxxxxx > wrote:Arian, all,
I've been working in "extremely large enterprises" for at least 5 years, going on forever, and I can see where the idea that "the perimeter is a myth" can be perceived. While I understand how you may think that, the thought is still wrong.
Let's take as fact that malicious activity as a whole has evolved over the past 10 years in a manner that makes "network access control" an order of magnitude less important. Since just about everyone can agree on that, I'll take my argument from that beachhead and move on, addressing specific points.
1) The perimeter is "dead" First, let me say that I disagree that the perimeter is a thing of the past. While the perimeter has certainly become "blurry" in some cases, this generality isn't a case where it happened by necessity, rather, by accident. I've been through enough integrations where the border between "us" and "them" has all but dissolved to know that this isn't by design. It just happens sometimes when we architect carelessly, or just let things happen. I will argue that this is a bad thing, and should be addressed by a proper review from your enterprise architecture group, involving your security folks, obviously. The perimeter, while it has become fuzzy in some places needs to be maintained for the overall health of a business. Access to resources should be limited, and controlled, and without firewalls in the enterprise this becomes more disparate and difficult. The problem most architects see with firewalls is that they are effectively the bouncer at the door to the bar, and this assumes the bar has only one entrance/exit - or that all entrances/exits (egress/ingress points) have a bouncer (or firewall in this case) at those points. The problem comes in places like highly meshed networks where access into a segment happens from many places, or "network segments" are virtual rather than physical entities. While technology and today's business tends to drive us in IT to dissolve borders in the name of productivity and usability - it doesn't mean we should be giving in to those drivers in exchange for our own common sense.
2) WAFs (although mis-named) are useless Web Application Firewalls (although I personally feel they should be called Web Application Gateways) are wonderful when implemented properly. While they definitely do NOT substitute for good coding practice (I can talk about this point all night long) it still helps you filter out those high-probability, easy-to-execute attacks classified as "low hanging fruit". There are at least 2 WAF vendors that I have personally reviewed and can talk about at length if anyone's interested, although I don't want to promote any particular vendor here. WAFs should do the following two things: 1) understand the application flow & parameters and 2) filter out "bad" things (signature/regexp based detection). A combination of the two will certainly help eliminate a good portion of the web vulnerabilities out there. Having reviewed over 500 applications in my time, I can honestly say that the 80/20 principle applies. 20% of the vulnerabilities cause 80% of the damage. Those, I strongly feel, are the things that we can as security professionals identify and remediate via automated methods and tools. The other 80% of vulnerabilities are the ones that are logic-flaw based, requiring the attacker to really understand things like process flow, business logic in order to cause issues. Unfortunately, those vulnerabilities will never be detected by any automated tool - simply because it requires the power of the human mind and the understanding of a warm body to identify those attacks. The problem with those attacks is that they typically take extensive time to identify and exploit - thus the reason why attackers opt for scanners and automated tools like SQL injectors to find and exploit the easy holes. I go back to one of my favorite cartoons in IT... there is a bear chasing 2 hikers and one of them stops to tie his shoe. The other hiker is screaming at him that the bear will catch him, and that they must outrun the bear... the hiker tying his show smiles and says "I don't have to outrun the bear, I just have to outrun you!" This is the world of business folks - the low hanging fruit is what will be exploited. If you don't understand the ideas of acceptable risk, and "good enough" - you're in trouble. So sliding back to my point... while WAFs may not be the magic silver bullet, and conceding that there are a lot of really dumb implementations out there (CheckPoint's AI, and many others) WAFs are useful and should be used in conjunction with secure code development practices and tools. Does this mean that the "firewall" is dead, no. It means that while a firewall has its place, it's clearly not at the application layer, and doesn't serve much more purpose at the higher-level points in OSI mode.
3) Web Services somehow makes everything "different" I swear if I hear one more person tell me that "Web Services has fundamentally changed everything" I'm going to scream. This simply isn't the case. We've had web services for years, but we've simply not called it that before. How many of us have had to deal with headless applications which act as data-processing engines via HTTP? I know I have. Web services hitting the market simply tells us that we have to look at our architectures and re-evaluate some of the things we've been doing, and apply those lessons-learned from serving pages to the "Web" to yet another slightly different method of doing so. Let me admit that fundamentally, web services are slightly different than a web server, in that there are re-usable components, an ESB, and lots of things all happening in the same "security zone". This doesn't fundamentally change the game, though, in my humble view. A firewall outside at the perimeter can still keep the usual barrage of crap from consuming your valuable resources on the Web Service. That being said, if you have a web service that's open to the world - a firewall isn't really going to help THAT web service be more protected, outside of keeping the rest of the ports on that machine (real or virtual) from being accessed from the outside or hostile world. Firewalls have their uses in every aspect of our businesses, keeping segments separate and acting as the big-mesh screen that pulls out the obvious and the unwelcome at a ip/port/protocol layer. But just like with web servers, once you've figured out that some web server is vulnerable on port 80 to an attack, the firewall will let you poke at that defect all day long without the use of a more intelligent device behind the firewall.
In summary - firewalls are far from dead and useless, the perimeter is alive and well (or at least it should be) and if you're arguing otherwise I say to you - "You've given in to the pressures that the business has put on IT to "just make it happen, worry about the security later".
This is my opinion, and I'm sticking to it.
Cheers all.
Rafal (Ralph) M. Los IT Security - Response | Mitigation | Strategy
E-mail: rafal@xxxxxxxxxxxxxxxx Direct: +1 (847) 426-2621 Mobile: +1 (404) 606-6056 - gPGP: 0xFFC63B33 - Blog: http://preachsecurity.blogspot.com - Web: http://www.ishackingyou.com - LinkedIn:http://www.linkedin.com/in/rmlos
Arian J. Evans wrote:William --
Bang. Dead. Done. Network firewalls are obsolete, or better said -- they have less value today than they did in 1995-2003, especially for the purposes of protecting your software.
Apparently others are not thinking correctly about this yet.
The perimeter has been dead for a long time. I used to tell people this back around 2001 when I was helping glue web services and asynchronous message queues together for financial institutions. People didn't get it while their precious data was flapping in the wind the whole time.
Network firewalls have a valid use as an access control mechanism, for port and protocol pairing, and IP filtering, but that's it.
Networks have little to do with applications, and network security
has little to do with application security, though it exists almost
entirely because of it. (Necessary, but not sufficient.)
The firewall vendors have desperately tried to add junk features
to play in this space -- let's take Checkpoint's "AI"...."Application
Intelligence". I could argue most of the features are junk, but
let's say, for the sake of amusement, that Checkpoint actually
has some "application intelligence".
It won't ever seen the interesting traffic. Not only does it lack the notion of session and state, but it is a syntactical device trying to solve a semantic problem. Never gonna work.
Even more so -- any interesting sessions are SSL encrypted, and no network devices are able to inspect that traffic. (true, this could be solved with minimal implementation, but out in the real world -- no one terminates SSL except on their webservers or load balancers. Seriously.)
Let's discuss web application firewalls. They aren't firewalls.
They are intermediary proxies trying to syntactically scrub traffic, and largely they all fail due to poor implementation, poor design/interface, or lack of good data.
"Software Security" is one part syntax problem, and one large part semantic problem. Nothing with the word "firewall" in it today understands the semantic web.
The WAFs could, and hopefully we can get them to do so once they let go of their insane marketing messages.
Incidentally -- I think this will change soon though. A couple of WAF vendors already "get it", and a few more are coming to market that will (hopefully) give us what we all need from web application "firewalls".
But they won't be a "firewall", despite the fact we'll probably still call them that.
--
The world has already had plenty of free network penetration tests. SQL Slammer was a great one, for example.
With recent SQL Inject bots/massive scripted attacks, the software world is starting to get them too.
SQL injection is a syntax problem, so we COULD solve that with a little (or a lot) of perimeter data scrubbing aka a firewall, but there are many classes of weaknesses that require a semantic notion of use-case or infered understanding of the software to "protect".
The problem here is that the perimeter is dead, so it's damn near impossible to "firewall" off an entire piece of software and make money with it too.
I think the WAFs (web app "firewalls") will evolve to be protocol aware IPS devices e.g.-apply "virtual patches" to known issues.
Possibly, some day, somebody will take all the lessons we learned from NBADs and apply them to software use-case and then we'll have a really smart, business-enabling WAF that is semantic in nature, and possibly statistical with regards to syntax issues.
But today, most are still poorly marketed as "firewalls" that magically "learn" your software and "firewall" it off somehow. They can't and they don't, and they've missed that firewalls are dead anyway.
So yes: all of the perimeter network widgets marketed as Firewalls/IDS/IPS are pretty much dead and useless for the currently evolving threat landscape.
If the WAFs evolve into known weak attack-vector blockers, or use-case enforcers, they will probably make a great network widget solution, but they really won't be anything like a network "firewall".
Network Firewalls are great at detecting and blocking things like nmap scans.
If you want to detect or to block those nmap scans, by all means, have at it.
But, but, who cares.
I believe I heard PCI or VISA say most cardholder data is lost through SQL Injection.
I'd love for IBM's managed services to publish some attack and compromise statistics (or anyone with a large amount of measured network traffic).
But, until someone releases some really hard data, I'm going to go with what we read in the news that is causing companies real issues, and it's almost never anything that a firewall can do much about.
It's usually rogue wireless, or too high of a privilege level in the software, or a flaw in some piece of software that someone bad had access to.
Firewall or not.
Thanks for the great question. Cheers,
-- -- Arian Evans, software security stuff
reformed hacker turned animal rights activist to meet hot chicks concerned with those tasty animals
---------------------------------------------------------------------------- Join us on IRC: irc.freenode.net #webappsec