Re: After getting the alerts generated by IDS how we distinguish true positive.false positive and false negative.

[Todd Haverkos <infosec () haverkos com>]

"Ahmad, Md. Mustaque" <md-mustaque.ahmad () hp com> writes:

> Hi All,
>
> After getting the alerts generated by IDS how we distinguish true
> positive.false positive and false negative. 
>
> And What we do with True Positive alerts. How we export alerts from
> database (Steps).

This is quite a general question, and probably best for a list other
than this one, as it doesn't really fall in the scope of penetration
testing.  While I'm not an IPS/IDS focused sort, one approach defines
the role of an intrusion analyst is to prioritize alerts into:

    - things they need to investigate more/track, 
    - things that require immediate action, and 
    - things that aren't worth worrying about.  

If it's a false positive for an attack to which your environment is
not vulnerable (e.g. the biggest baddest Solaris exploit has been
launched against your environment that doesn't have a single Sun
product), then it's probably a signature you'd be advised to disable
from alerting in your IDS solution, for instance.  In such a case, you
don't care if it's a false or true positive since even if it's a "real"
attack, there wouldn't be an impact against your environment, so
there's nothing clear you'd do with that info anyway. 

True positive attacks to which your environment is known vulnerable
should likely trigger some incident response procedures.  If it's a
confirmed attack, and you know you're vulnerable, you've now got
infected servers to deal with.  For that determination, however, you
need to have a handle on what your environment is vulnerable to.
That's where enterprise wide vuln scanning for inventory and attack
posture purposes is part of the puzzle. 

False negatives are troublesome.  The good news is that there's
nothing for an IDS watcher to do about them... as they aren't going to
show up on the console.  However, if somehow you become aware of a
false negative that you've observed yourself, coding up your own user
rule to look for the attack in parallel with asking your IDS vendor
for a fix would be two possible reactions.

As for exporting alerts, it's quite difficult for anyone to say
without knowing which IDS and database you're dealing with.  But
again, that's probably a better question for your vendor, or a forum
specific to the product or tool you're using. 

Overall though, while IDS is useful for creating an audit trail when
an incident occurs, it's a reactive mode of operation unlikely to
protect you against much.  For one, they're pretty easy to blind with
tools like snot and sneeze.  Even in the best case, you can't do
anything until after an attack occurs.  

Inline IPS (_prevention_) is what should be considered for some actual
protection against the attacks--particularly ones for which a patch
lag exists.  There are lots of vendors in the IPS, some far more
clueful than others.  The IPS's to avoid are the ones that like to
simply lock out IP's from which attacks are seen, as it's great way to
create a DoS with some spoofed traffic.  An attacker spoofing traffic
claiming to be from DNS root servers is one insidious attack these can
fall prey to, for instance.  The better ones will drop the malicious
portions of the traffic regardless of source IP.  I'm of course
partial to one leader in the space, IBM ISS and their Proventia line
of IPS goodies:
   http://www.iss.net/products/product_sections/Intrusion_Prevention.html

Best Regards, 
--
Todd Haverkos, LPT MsCompE
http://haverkos.com/

------------------------------------------------------------------------
This list is sponsored by: Cenzic

Top 5 Common Mistakes in 
Securing Web Applications
Get 45 Min Video and PPT Slides

www.cenzic.com/landing/securityfocus/hackinar
------------------------------------------------------------------------