RE: Thinking about Security rules...

["Sean Convery" <sean () cisco com>]

Inline...

> -----Original Message-----
> From: Peter Kristolaitis [mailto:jester () nt net]
> Sent: Thursday, May 09, 2002 7:05 AM
> To: Rhino Bond; vuln-dev
> Subject: Re: Thinking about Security rules...
>
>
>
> > At my current contract we are trying to
> > come up with a set of rules that is "all inclusive"
> > (as much as possible).  Granted a Security Policy is
> > part of it, so are firewall rules, so might be the
> > rules for the IDS.
>
> One important thing to add to this list is an incident response
> plan.  All
> the policies and rules in the world won't do you any good if you
> don't have
> a set course of action for dealing with security breaches (or other
> disasters).  For example, do you quarantine the affected system(s) for
> investigation, or do you just rebuild from the last clean backup?
Agreed, incident response is important, I'd add to the list an
understanding of why you have technology there in the first place.  For
example, you mention you have a FW and an IDS system that are working
together to detect and stop intruders.  Are these the only technologies /
best-practices you have in place or are there others (basic router ACLs,
timely patching on hosts, rate limiting on your WAN links, etc.)?  The
tricky thing about rules like that is when you get down to writing them
they tend to be fairly specific to the system under attack and the method
by which you attack.  The set of rules for a system under DoS will be
different than the rules when an attacker tries a buffer overflow on that
same system.  This is why having a complete understanding of the different
technologies and best-practices you have at your disposal is a good way to
understand where your defense is thin vs. deep.  Here's a couple links
that may help:

Attack Modeling for infosec and survivability:
http://www.cert.org/archive/pdf/01tn001.pdf

This is a systematic way to create a ruleset from the attackers
perspective which should guide your own security deployment.  This isn't a
bad way to "test" a security policy after it has been written, or to think
about the likely attacks as you are writing it.

"Defense-in-Breadth" Information Security Mag Column:
http://www.infosecuritymag.com/2002/feb/columns_executive.shtml

Key thing to remember about the second article is in order to achieve the
amplification of effectiveness he mentions, you need different
technologies protecting you in complimentary ways.  (i.e. 2 stateful
firewalls in series isn't nearly as nice as a stateful firewall coupled
with an IDS.)

> > When I asked for further
> > clarification on this topic, I was told, "you know
> > something like "fuzzy-logic" that states IF "A" then
> > "Z" (for example a hacker is hacking away at the
> > firewall), BUT if the hacker breaks through the
> > firewall, then We need to jump to IDS rules, so now
> > it's IF B then Y, and if the hacker get's into the
> > corporate piggy bank and steals money, then it's IF C
> > then X...
>
> Hmm... My first impression here is that the person who said this has no
> idea what "fuzzy logic" actually is.  The example you've given is
> 'cascading' boolean logic, not fuzzy logic.  Might want to
> clarify whether
> they want fuzzy logic detection algorithms, or simple boolean
> decisions here.
> My second thought is why separate all the functions?  Basically, why
wait
> until an attacker has penetrated the firewall before activating IDS?  I
> would personally run them concurrently, for an added chance of attack
> detection (different detection methods, as well as the added redundancy
> which means that an attacker has to totally disable both systems at the
> same time to completely avoid detection).  One thing about complex
> systems:  Redundancy is A Good Thing(tm).
> The other thing here... how would you know that an attacker has
> succesfully
> penetrated the firewall without IDS running first?  If the attack is
done
> properly, the firewall wouldn't know that it's been penetrated, and
would
> thus be unable to start the next step (IDS rules).
Just to add a quick note on IDS placement: Most of the customers I deal
with that have IDS in front of their firewall are just overwhelmed with
alarms.  The amount of "script-kiddie" traffic that is generated makes it
almost pointless to see who is "knocking at your door". If you have the
staff to do it, or if you want to use it as a way to do delta analysis on
the effectiveness of your firewall, great. Most people don't manage a
single IDS system correctly, let alone one that will be alarming
constantly.

If I only had a single place to put an IDS, I would stick it as close to
the hosts that I was trying to protect as possible.  This usually means
that the attack has already passed through the firewall, and now it is
right near the hosts.  Since it is so close to the hosts, you get the
ability to tune the sensor pretty tightly based on your topology and
traffic types.  For example:  If you are only letting web traffic into the
segment you are watching, tune every other alarm type ridiculously high
because if you are all of a sudden seeing telnet traffic on that segment,
chances are something has gone horribly wrong with your firewall. :)

Thanks,

Sean

> Just my thoughts...
>          Peter Kristolaitis

Attachment: smime.p7s
Description: