Re: [WEB SECURITY] Query: Are Firewalls obsolete in an Enterprise Web Service Environment?

["Arian J. Evans" <arian.evans@xxxxxxxxxxxxxx>]

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

Have a question? Search The Web Security Mailing List Archives: 
http://www.webappsec.org/lists/websecurity/

Subscribe via RSS: 
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]