RE: Intrusion Prevention requirements document

["Tony Haywood" <thaywood () karalon com>]

IDS Informer like Traffic IQ Pro is an advanced packet replay tool and can
be used to validate inline and passive intrusion detection/prevention
systems.

In both instances the applications have no concept of the device being
tested and therefore has no understanding on the outcome of the attack, it
is just generating the traffic, the only information it has is if any of the
packets are failed to be delivered.

A successful attack within both applications is based on whether or not all
of the packets in the traffic files were received by the opposing network
card.  The difference between the successful and unsuccessful traffic files
themselves is, as you correctly pointed out, based on whether the particular
attack/exploit was successful.  In many cases it is important for an IDS/IDP
to know the difference.  Taking a simple example such as the DNS Zone
Transfers - escalation procedures may require remediation work if an IP
other than a secondary DNS was able to transfer zone details.  In this case
the successful file would be used.   If on the other hand you wanted to
ensure that all unsuccessful attempts were logged but not acted upon then
you would use the unsuccessful event.  In both cases an IDS/IDP should be
able to differentiate between the two and alert accordingly.

Your second point in relation to attack detection and false positives is
interesting.  It is well known that network based intrusion
detection/prevention systems can be produce a high degree of false positives
and unfortunately IDS Informer can add to that as it will attempt to replay
the remainder of an attack even though it has already been detected and
blocked.  Traffic IQ Pro does not have this problem and will not cause
additional false positives.

The second part of your question is more of a theological debate however.
> From a standpoint of "all attacks should be detected and blocked prior to
execution" I would expect an IDS to detect the attack prior to it reaching a
point that could cause a compromise to my internal/protected systems
although this is not always possible.  In some cases though it is best to
let the attack take its natural course for evidential purposes.  For me, if
an attack succeeds then its too late, the damage has been done.

It is worth pointing out that in many cases it is not possible to detect an
attack at the point of inception as there is not enough information
available to make an accurate determination.

There is a bug in IDS Informer that prevents it from displaying the correct
information in certain scenarios.  This can lead to different information
being displayed for an audit and packet level report of the same event.

Traffic IQ Pro does not exhibit this flaw.  Using Traffic IQ Pro it is
possible to run an audit level report for multiple files to determine which
succeed and which fail.  Then typically a packet level report would be run
on the ones that failed to determine at which point they failed to see if
the detection point is acceptable.   For instance, blocking an attack at
packet 47 when the attack can be run in 46 is not very useful.


Regards

Tony

-----Original Message-----
From: Sanjay Rawat [mailto:sanjayr () intoto com] 
Sent: 08 November 2005 04:42
To: thaywood () karalon com; focus-ids () securityfocus com
Cc: pen-test () securityfocus com
Subject: RE: Intrusion Prevention requirements document

Hi:
to tell the truth, I was thinking to post a query regarding IDS informer. I 
worked with IDS informer and observed some points.
1. I m still not clear on "how IDS informer decides that attack was not 
detected?"
2. On false positives, we observe that so called U traffic, corresponding 
to an attack, mainly differs in the response part. in this case, if an 
IDS/IPS detects the attack, it flags it as false positive. but it should be 
noted that attack is launched against a target. Now, i m confused on one 
thing- for an IDS/IPS, what should be the modus of operandi? should it 
detect an attack on the very moment it is launched, or it should wait for 
the response from the target to see if it is really successful? In the 
second case, though FP may be reduced, but for an IPS, it can be  dangerous 
thing.
3. sometime, packet level auditing and connection level auditing differs, 
as far as the final results are concerned.
please impart your expert views

regards
Sanjay
At 02:23 AM 11/5/2005, Tony Haywood wrote:
> One of the ways that you could test safely is by using something like
> Traffic IQ Pro or a similar product. It is a stateful traffic replay tool
> and can be used to test any inline or packet monitoring device.
>
> The product uses two network cards and so the library of over 700 normal
and
> threat traffic files can be replayed statefully without the need to connect
> to a live target system. This allows for live production systems to be
> testing for the correct configuration really quickly and easily.
>
> I have been involved in working in this area for a number of years now and
> my previous company was Blade Software where I developed IDS Informer and
> Firewall Informer to provide similar testing capabilities.
>
> Information on Traffic IQ Pro is available below should you want to take a
> look.
> http://www.karalon.com/Karalon/TrafficIQ/TrafficIQ.htm
>
> Working with testing labs and a number of security and networking vendors
> has enabled Traffic IQ Pro to be a really useful tool for anyone who wants
> to check the configuration of their firewalls, IPS, IDS, routers, switches
> etc and see how those devices perform under different scenarios.
>
> Tony
>
> Tony Haywood
> www.karalon.com
>
>
> -----Original Message-----
> From: vendortrebuchet () comcast net [mailto:vendortrebuchet () comcast net]
> Sent: 29 October 2005 20:40
> To: focus-ids () securityfocus com
> Subject: Re: Intrusion Prevention requirements document
>
> Another question for everyone,
> When you brought in each vendor for evaluation, did you configure a test
> network for them or did you use your production network?  My 1st concern is
> keeping my job :o)  If I test in production, I could impact production
> traffic.  If I don't test in production, how can I best ensure that I won't
> have problems with custom applictions, older IP stacks which could be an
> issue if RFC compliance checks are done, etc.
> The vendor answer is always, "don't turn on blocking and just monitor."  Is
> that a reality?   I'd like some testimonials to this and some real life
> instances of what has been done from unbiased sources.
>
> Thanks,
>
> VT
>
>
> > All,
> >
> > I work on a team that manages signature and behavioral based intrusion
> > detection systems today.  We have been tasked with reviewing IPS (or
> > whatever vendor name acronym you prefer) in '06.  Our normal process
> > is to put together a base requirements document to weed out vendors in
> > the first round through a paper excercise and then bring in the best
> > we can identify.  My question is, has anyone developed a matrix that
> > identifies key qualifiers in an IPS solution (e.g. in-line, fails
> > open/closed, reporting features, etc.).  If so, could you provide links
or
> the documents?
> > If not, what categories are most significant to consider in your
> > expert opinions?  What reasons did you choose the solution you have?
> > What would you consider if you had to choose over again, etc?
> >
> > Thanks in advance for your responses.
> >
> > VT



----------------------------------------------------------------------------
--
Audit your website security with Acunetix Web Vulnerability Scanner: 

Hackers are concentrating their efforts on attacking applications on your 
website. Up to 75% of cyber attacks are launched on shopping carts, forms, 
login pages, dynamic content etc. Firewalls, SSL and locked-down servers are

futile against web application hacking. Check your website for
vulnerabilities 
to SQL injection, Cross site scripting and other web attacks before hackers
do! 
Download Trial at:

http://www.securityfocus.com/sponsor/pen-test_050831
----------------------------------------------------------------------------
---





------------------------------------------------------------------------
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.
------------------------------------------------------------------------