RE: IDS Informer

[Brian Laing <Brian.Laing () Blade-Software com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Brian,
        Been awhile since I sent this out and I can not recreate my thought
pattern on this one.  That being said what we inject on the wire is
an actual attack, however we don't establish a connection to the
target.  Given that we do not make this connection (although the
packets as if it did are injected on the wire along with the attack),
the attack does not harm the targeted machine.  So what the IDS sees
is the actual attack it just has no effect on the machine.
        Additionally we have just release a major update to our attack
library in IDS informer.  Now all exploits have both a successful and
an unsuccessful version.  Now our customers can inject each
individually onto the wire and see how their IDS de jour handles the
different traffic.  This can also be used by IDS vendors to test
signatures that detect each as a different state.
        If you would like to chat in more detail I would be happy to have a
phone call with you or anyone else that would like to discuss our
attack library.  Additionally if you are an IDS vendor who we are not
working with we do offer direct access to our library of Exploit
code, and other information that has been found useful to the IDS
vendors we are working with.

Cheers,
Brian


- -------------------------------------------------------------------
Brian Laing
CTO
Blade Software
Cellphone: +1 650.280.2389
Telephone: +1 650 367.9376
eFax: +1 208.575.1374
Blade Software - Because Real Attacks Hurt
http://www.Blade-Software.com
- -------------------------------------------------------------------


- -----Original Message-----
From: Brian [mailto:bmc () snort org] 
Sent: Tuesday, November 19, 2002 5:26 PM
To: Brian Laing
Cc: focus-ids () securityfocus com
Subject: Re: IDS Informer

On Tue, Oct 08, 2002 at 07:41:33AM -0700, Brian Laing wrote:
> It also allows IDS Informers other features that modify a
> number of characteristics of the packets that prevent the attack
> from being successful whilst maintaining all of its characteristics
> which is why you could see failed GET requests.  This is exactly
> what is supposed to happen.  At no time should an attack ever be
> successful on a target system or service from IDS Informer.

So can you explain how this is a valid test of an IDS?  

Many IDSs claim they check the differences between an failed attack
and a 
successful one.  If you don't replay a real attack, how can you test
this capability?

- -brian

-----BEGIN PGP SIGNATURE-----
Version: PGP 7.1.1

iQA/AwUBPd1F5YcqkwDZV2C0EQK0RgCfRTx2r9RE7yvPQftWCd/D+lKL/1cAn3oo
+f5EgM2iGgXSpwzGjJGLTQd7
=lm+R
-----END PGP SIGNATURE-----