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,
>