lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 9 Oct 2009 17:16:35 +0530
From: srujan <srujan82@...il.com>
To: Valdis.Kletnieks@...edu
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: Attack pattern selection criteria for IPS
	products

I agree with your word let "customer network admin selects it". But Tipping
Point, Juniper, Cisco and Snort will have a wide range of customers, and
maintaining different signature set for different Orgs is a big headache.

All these guys are maintaining 95% to 99% detection coverage at NSS testing.
That's why i asked about the selection criteria.

On Fri, Oct 9, 2009 at 1:36 AM, <Valdis.Kletnieks@...edu> wrote:

> On Fri, 09 Oct 2009 00:47:24 +0530, srujan said:
>
> > What is the vulnerability selection criteria of Tipping Point, Juniper
> IPS
> > products.
> >
> > Is it covering each and every CVE ID or is it selecting particular kind
> of
> > attacks. If so what is selection criteria (cvss score or severity level
> or
> > most publicly exploited)
>
> If the answer isn't "customer network admin selects it", the products are
> broken and brain damaged.  Different sites have different security stances,
> and different opinions regarding the trade-off between the added security
> benefit and the throughput and latency hits you take.
>
> Even within a site, the trade-offs may vary.  I have some machines that
> are actually air-gapped, some that are heavily firewalled, and some that
> are lightly firewalled - and there's probably some Snort sensors and
> honeypots
> too.. ;)
>
> If you're asking for "what pre-canned detection rules they come with", it's
> probably "all the known vulns that we can figure out how to write a Snort
> rule that doesn't suck resources". :)
>
> OK, maybe they don't use Snort - but the same problems of filter
> expressiveness, whether/how to do a regexp, and so on, are faced by all
> IDS/IPS
> systems.  If you need to do a regexp backref, it's going to either not be
> part
> of the available toolset, or it's going to suck at line rate on high speed
> interfaces.  Matching '\((134|934){3,5})\(foo|bar)(more ugly)(\1|\2)' is
> going
> to suck whether it's Snort or silicon.
>
>

Content of type "text/html" skipped

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ