RE: IDS evaluations procedures

From: Nathan Davidson (ndavidso_at_globix.com)
Date: 07/16/05

  • Next message: Andrew Plato: "RE: Host-Based Intrusion Detection/Prevention. Which will you select? (Requirements within)" 
    Date: Sat, 16 Jul 2005 12:42:14 -0400
To: "Adam Powers" <apowers@lancope.com>, <THolman@toplayer.com>, <David.Sames@sparta.com>, <focus-ids@securityfocus.com>

    I think you are missing the point - by blocking the traffic we need take no further action. If you allow invalid traffic into the network you still need to inspect it further to see if it is malicious too!

     

    I understand what you are saying about signature accuracy, but it just isn’t relevant. By reducing the number of packets that you inspect you can reduce the number of alerts – especially false positives.

     

    Example:

     

    10,000 PPS (packets per sec) of HTTP traffic flows into a network.

    100 PPS of these are malicious. An inline IPS discards all HTTP packets not containing www.xyz.com as a host header, this filters out all non-targeted worm nonsense – lets say 90% of the malicious traffic.

    We are now left with only 10% of the of malicious traffic = 10PPS

     

    To make things easier to compare let us say that the IPS and IDS have the SAME signatures/policy and they both identify all of the malicious traffic:

     

    The IPS will create 10 alerts/sec

     

    The IDS will create 100 alerts/sec

     

     

    Summary: IPS (in-line) and IDS units with the same signature policy will have the same number of false positives per 1000 packets inspected. However, by pre-pending a blocking filter the IPS will have fewer packets to inspect and therefore create fewer false positive alerts.

     

    Bottom line: I don’t care about the false positives that I never see!

     
     

            -----Original Message-----
            From: Adam Powers [mailto:apowers@lancope.com]
            Sent: Sat 16/07/2005 14:57
            To: Nathan Davidson; THolman@toplayer.com; David.Sames@sparta.com; focus-ids@securityfocus.com
            Cc:
            Subject: Re: IDS evaluations procedures
            
            

            But white-listing or filtering of the kind you speak is available in most
            all commercial and even open source non-inline solutions.
            
            Take snort for instance.
            
            We could use a "pass" action to ignore all HTTP traffic that does NOT have a
            specific host-header or we could use the "activate" action to dynamically
            apply rules to packets that DO have a specific host-header thus satisfying
            the requirement you specify below WITHOUT the need for an inline technology.
            
            Don't get me wrong, I'm not doubting the usefulness of filtering out
            malicious traffic, just the fact that the rate of false positives is somehow
            different when a technology is inline. IMHO, it's more a function of how the
            detection engine is configured than anything else.
            
            
            
            On 7/16/05 7:29 AM, "Nathan Davidson" <ndavidso@globix.com> wrote:
            
    > Hi Adam,
    >
    >
    >
    > I am sure Tim can answer this one very well, but over the last 12 months I
    > have spent a lot of time working with IPS in an IDS orientated company. So I
    > thought I share my experiences.
    >
    >
    >
    > When we deploy an in-line IPS solution we define a number of parameters in the
    > policy that should be present in ALL valid requests (White-listing). I use
    > this to filter out all traffic that I know must be malicious. From my
    > experience this is up to 95% of worm/scan traffic. We then apply IDS style
    > signatures based on known attack vectors (Black-listing) but only on the
    > remaining 5% of traffic. Thus we should have up to 95% less false positives
    > (and generally we do). Additional benefits can be gained by dropping all
    > subsequent packets from an abusing source IP address.
    >
    >
    >
    > An example would be to use an IPS to force all HTTP requests to have the host
    > header www.xyz.com (your sites URL) this will stop a significant proportion of
    > HTTP noise before signature matching.
    >
    >
    >
    > Conversely with IDS you just don¹t have the ability to white list traffic in
    > this way, I guess you could RST any request that didn¹t match the URL but I
    > think fragmented buffer overflows and the like could sneak through - so it¹s
    > risky.
    >
    >
    >
    > As you alluded to, the IPS signatures tend to be less aggressive than those on
    > the IDS which I think reflects the much higher penalty of false positives on
    > an in-line blocking device. For this reason I do still deploy NIDS/HIDS on the
    > inside to collect forensic data, with the added benefit of having a second
    > manufacturers signatures.
    >
    >
    >
    >
    >
    > Internet
    >
    > I
    >
    > IPS
    >
    > I
    >
    > Firewall
    >
    > I
    >
    > I
    >
    > Switch=== NIDS
    >
    > I
    >
    > I
    >
    > HIDS
    >
    > Server
    >
    >
    >
    >
    >
    > Hope that helps
    >
    >
    >
    > Nathan Davidson
    >
    > Senior Architect
    >
    > Globix Corp.
    >
    > London
    >
    >
    >
    > -----Original Message-----
    > From: Adam Powers [mailto:apowers@lancope.com]
    > Sent: Wed 13/07/2005 19:00
    > To: THolman@toplayer.com; David.Sames@sparta.com; focus-ids@securityfocus.com
    > Cc:
    > Subject: Re: IDS evaluations procedures
    >
    > Tim, I hate to stir up this whole can of worms (pun alert) and yes I know
    > this is off topic but can you please qualify this seemingly non sequitur
    > statement?
    >
    > "All IDS devices are subject to large numbers of false positives, which is
    > why if you're making a new investment you should consider IPS technology, as
    > this gives you a far lower TCO and real-world protection against zero-day
    > threats."
    >
    > How so?
    >
    > I really struggle with this whole "because it's inline it must be more
    > accurate" thing. Sure, if I turn off a bunch of sigs on the IPS that are
    > less reliable, accuracy will increase. But why not do the same thing on the
    > non-inline IDS?
    >
    > Is there something magical about being inline that makes the system less
    > prone to false positives? If so, what?
    >
    > ----------
    >
    > David, addressing your original question... (which, incidentally, was about
    > INTERNAL attack traffic, not Internet Storm Center quality stuff that's
    > randomly hitting the outside of your firewall), we'll need a few extra data
    > points.
    >
    > 1. What are you testing for? Traffic-based anomalies? Application level RFC
    > violations and anomalies? Relational-modeling anomalies?
    > Behavioral-anomalies?
    >
    > 2. What collection mechanism is employed? NetFlow? sFlow? Ethernet Frames?
    > Other?
    >
    > 3. Are you only interested in classic "attacks" (fire up Nessus, see what
    > happens) or other anomalies such as malfunctioning applications,
    > policy-driven anomalies, etc?
    >
    >
    >
    >
    >
    > On 7/13/05 3:33 AM, "THolman@toplayer.com" <THolman@toplayer.com> wrote:
    >
    >> Hi Dave,
    >>
    >> Take a peek at the Internet Storm Centre @ SANS -
    >>
    >> http://isc.sans.org/
    >>
    >> Gives you a good idea about what's going on.
    >> Which IDS devices are you looking at? All IDS devices are subject to large
    >> numbers of false positives, which is why if you're making a new investment
    >> you should consider IPS technology, as this gives you a far lower TCO and
    >> real-world protection against zero-day threats. It also saves you having to
    >> buy lots of IDS sensors, seeming a large proportion of the load will be
    >> absorbed and taken care of by the IPS.
    >> Just my 2 cents.. ;)
    >>
    >> Cheers,
    >>
    >> Tim
    >>
    >> -----Original Message-----
    >> From: Sames, David [mailto:David.Sames@sparta.com]
    >> Sent: 13 July 2005 04:54
    >> To: THolman@toplayer.com
    >> Subject: RE: IDS evaluations procedures
    >>
    >> Thanks for the info - those are exactly the kinds of characteristics I
    >> need to consider - at this point, I'm not evaluating a product per se -
    >> I'm evaluating some claims by some of our researchers :-) FP's are what
    >> I'm most concerned about. I'll check things out to see if I can get more
    >> stats - and of attempt to produce some data sets that may look like
    >> "anomalies" but are really traffic spikes and shouldn't be flagged.
    >>
    >>>>
    >>
    >> To specifically answer your question, look at current attack weather
    >> reports
    >> - you'll see approximately 15-20% of perimeter traffic is in fact worms
    >> trying to propagate. Any evaluation should be designed with this in
    >> mind.
    >> ..but more importantly, make sure you're evaluating something that will
    >> do
    >> the job in hand and doesn't lead you up the garden path with inaccurate
    >> marketing collateral! :)
    >> <<<
    >>
    >> That's exactly what I was looking for !
    >>
    >> Regards,
    >>
    >> Dave
    >>
    >> --------------------------------------------------------------------------
    >> 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.securityfocus.com/sponsor/CoreSecurity_focus-ids_040708
    >> to learn more.
    >> --------------------------------------------------------------------------
    >>
    >
    >
    >
    > --------------------------------------------------------------------------
    > 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.securityfocus.com/sponsor/CoreSecurity_focus-ids_040708
    > to learn more.
    > --------------------------------------------------------------------------
    >
    >
    >
            
            
            --
            
            Adam Powers
            Director of Technology
            Lancope, Inc.
            c. 678.725.1028
            f. 770.225.6501
            e. apowers@lancope.com
            
            StealthWatch by Lancope - Security Through Network Intelligence
            
            
            

  • Next message: Andrew Plato: "RE: Host-Based Intrusion Detection/Prevention. Which will you select? (Requirements within)"

    Relevant Pages

    • Re: Cisco VPN Client config on 515
      ... destination IPs etc) but this is my protected network. ... nothing inbetween will filter the packets, ... at your PIX interface if they are addressed to any of your public IPs. ...
      (comp.dcom.sys.cisco)
    • RE: IPS (was: [fw-wiz] Sources for Extranet Designs?)
      ... it merely does string-matchings on the packets alone. ... Network IPS: ... A software shim (firewall) that sits between the kernel and the application. ... deployed deep inside a network. ...
      (Firewall-Wizards)
    • RE: newbie quetsions
      ... When defining an IPS policy, you would define valid assets within your ... network. ... You would then define an Acceptable Usage Policy (AUP) for each of these ... have passed these basic tests - so, are HTTP packets RFC compliant? ...
      (Focus-IDS)
    • Re: Ethernet issue: works one way but not another
      ... packets transmitted, 5 packets received, 0% packet loss ... (This is when connected directly to internet through ... FBSD, I have been working with BSDI at the isp I work for for the last ... As for my network topology, I have an internal network that goes ...
      (freebsd-questions)
    • Re: Update: UDP 770 Potential Worm
      ... > the network immediately after the 'attack', ... were no packets indicating some form of replication. ... I noticed that the UDP ... > of the UDP datagrams is the IP address of the proxy? ...
      (Incidents)