Re: IDS vs Application Proxy Firewal

[Omar Herrera <oherrera () prodigy net mx>]

Hi Arian,

Arian J. Evans escribió:
> Omar -- you have a very nice, well-thought-out,
> post below. Yet, philosophically, I could not
> agree with you less.
>
> BAD (behavioral anomaly detection) can be approached
> as either a blacklist or a whitelist. Though, to be fair,
> the cases for whitelisting in BAD fashion are fewer,
> and since in BAD you are talking statistical inference
> or deduction, there is a fuzzy, slippery slope between
> "black" and "white" listing.
>   
True, my examples were only assuming bad detection, but white listing
through automatic software has its flaws. You are not guaranteed to get
a complete white list with an automatic tool because it can only take
into account what it sees and what it measures. So this activity is time
dependent and unless you try to guess if good or bad, you will end up
reacting anyway. White lists should have human intervention to include
as much context information to be effective, in my opinion.
> I have used BAD's for years. I "wrote" my first network
> one for my apps on top of Network Instruments
> product "Expert Observer". I even ran it by folks like
> Marty R back in the early snort days. Marty even
> said it wouldn't work :) but his objection to the approach
> (like most against BAD) was context-specific.
>
> It did work well for me. I did not stop any compromises
> from starting, however.... I caught many in progress
> in time to shut them down or mitigate the damage
> from compromise quickly, if not completely.
>
> I did this in a way that no other commercial technology
> available at the time (that I was aware of) could by
> making sure my BAD alerted me to violations of our
> implied business case/rules.
>   
Sure, using BAD is not necessarily bad :-). My argument is that white
listing might prove more effective, and I recognize that it comes at a
price (a price that some don't want or can't pay, like most individuals).
> I /emphatically/ *do not* think that whitelists work for
> many people in the app space. The inherent problem
> is that the problem is too large and volatile. Business
> rules -- while fairly finite and "white' are implemented
> in software in a very dynamic and volatile fashion.
>
> Attempting to whitelist in a static fashion fails in the
> web software world in most cases. Attempting to
> whitelist in a dynamic fashion has been shown to
> fail over and over again as well. (Auto-learning
> engines may mature to solve this some day, but
> for now...no)
>
>   
I've seen white listing schemes fail because they try to be generic. As
soon as you get specific on your business the task gets much simpler. 
The problem is that you want to provide a solution (as a
software/hardware or as a service) so that it will work for everyone you
will inevitably get into these complexities. Take for example firewall
rules; you see templates for common scenarios everywhere, yet most
companies end up putting their own rules because they need to adapt them
to their needs. That's the spirit of white listing, whether we are
talking network, application or O.S. layer. Hey, it even works at user
level, when we tell kids not to talk to anyone they don't know, rather
than telling them not to talk to suspicious people :-).
> I get the premise behind the superiority of whitelisting
> and why one might suggest this. Heck.... I have
> been down this promising path myself.
>
> The failure is that it tends to break down at the
> implementation level both with initial technical
> implementation -- and more importantly -- the
> ongoing care and feeding (operational) level
> required to keep whitelisting working.
>
> Blacklisting and signature solutions are far from
> perfect as any of us who fought through the
> IDS tuning of the 90's experienced fully. And
> yet we still used them because simple protocol
> whitelisting and enforcement was still a challenge
> then, and may still be today.
>
> Whitelisting business case of custom applications
> is exponentially more challenging.
>   
Totally agree. The tools for whitelisting need a lot of improvement.
Since we need to maintain whitelists ourselves, it would really help if
tools were created with support and deployment in mind. Black list is
easier for us, but not for the vendor, they had to put all this
infrastructure to do their analyses and deploy signatures updates as
fast as they can and with the least number of false positives and
negatives. That's the reason why black list was as success, it is
definitely more convenient for the end user and will allways be.

The question we have about this Good vs. Bad approach basically: is
blacklisting still good enough for all/some scenarios (i.e. provides a
good cost-benefit balance)?

I concur with you with application white listing. Once designed and
deployed is most painful to put filters on it and maintain them, and if
you have a mix of home made and commercial applications the task becomes
a nightmare. I still think that there should be no excuse for not trying
at least of implementing good filters at the design phase, but talking
about administration some application level firewall might help.

Different from their lower layer cousins, I see many people using
application firewalls primarily as a black list device, using predefined
detection signatures for XSS, SQL injection and the like, but many
application level firewalls can also be used with white lists. You could
define filters for inputs and outputs here, of both home made and
commercial applications.

I wouldn't use white lists for every application also. For example, I'll
put filters for a home made Web application that is critical for
business but not for the office package deployed in every workstation,
simply because I don't have all the knowledge to do it and it might not
be worth the effort.

> I think Blacklisting wins here though the pragmatic
> simplicity that it is all we can reasonably afford
> to implement and keep working today.
>
> I will fully admit I could be wrong here, and if
> blacklists prove unable to provide reasonable
> compensating control for software defects and
> a measurable level of protection from common
> attacks -- I'll eat my words in a few years. Right
> now (2008) we are already seeing the first
> automated-bot-driven and mass-scale attacks
> against webapps and every one of them would
> have been trivial to defeat with blacklists.
>
> > From here I cannot predict what the future
> will hold.
>
> Not all working with this problem agree with
> me of course.
>   
We will probably need to wait and see. We have to see if black listing
is still cost effective for different scenarios. For me it looks like
for some it is not (e.g. protecting custom made applications and dealing
with custom malware). But white lists have problems on their own as
well. Even if we know that they might be more effective in some cases,
maybe the time, resources and effort tu put them is to much for some
scenarios (I also think this is the case for protecting commercial
applications, as well as individuals and small businesses in general).

Blacklist does seem more pragmatic, at least for the end users (but
someone has to create those lists anyway). There was a point during the
mass propagation worms and now with specific targeted attacks with
custom malware where some thought that vendors might not be able to hold
the pace of criminals, mass propagation and fast creation of variants of
attacks was one of the reasons, lack of information was the other (e.g.
0-days - you can't black list that which you don't know yet).
> This is a vigorous running debate on the WASC
> lists, the OWASP lists, and even the SC-L (secure
> coding list).
>
> Ironically, given the end of your post, it is the
> hardcore software-security technologists that
> I think are driving the whitelisting argument,
> and I think that their recommendations fail due
> to lack of business pragmatism on their part. :)
>
> The app/software space problem is exponentially
> more complex. However, I have trouble deciding
> if it is different in *kind* or *degree* from the
> network IDS/IPS/NBAD space.
>
> I do hope those of us in webapp detection and
> protection land don't go re-inventing the wheel,
> and all the IDS/IPS guys sit on the sidelines
> laughing at us. Maybe they'll join in with us on
> the software IDS/firewall problem soon...
>
> Cheers,
>
>   
In the end I don't believe that either of them will win over the other.
I think that each will find specific environments for which they are
better suited and provide the best cost-benefit balance for users. The
application issue is a big one indeed and my favourite for custom made
applications is white listing :-). I don't see vendors taking the time
to create signatures for our home made applications. Anomaly detection
might help but I believe it will be allways incomplete due to lack of
context information, with a critical application such as e-banking or
flight control in an airport I wouldn't take my chances (vendors won't
be held liable if something happens, but as personnel in charge of
security we could be).

Also, I see people with different opinions from all sort of backgrounds.
I like the white list approach because I work more on the business side,
with regulations and control procedures. I haven't seen people more
involved in software development too enthusiastic about the white list
approach, because in involves time and resources for them, and this is a
big problem. They don't get enough time to finish functionality many
times, let alone implement security controls, so automated solutions
with black lists and anomaly detection are better liked by them, since
they are apparently cheaper and don't affect development times so much.
But the cause of the problem is not solved. White listing requires
resources, time and effort, but also forces you to try solve the main
problem (you need to document what you want, what you need, what you
approve) that's what I like.

But time will tell... :-)

Cheers,

Omar Herrera

------------------------------------------------------------------------
Test Your IDS

Is your IDS deployed correctly?
Find out quickly and easily by testing it 
with real-world attacks from CORE IMPACT.
Go to http://www.coresecurity.com/index.php5?module=Form&action=impact&campaign=intro_sfw 
to learn more.
------------------------------------------------------------------------