Re: CVE selection for IDS/IPS signature rules

thank you all for responses.

There are some tools such as Karalon, Mu and others.  i gather from
different tests performed by network world and other certification
agencies, these tools are used to test the effectiveness of IDS/IPS
devices.  if the criteria being followed is not complemented by these
test tools, then there could be differences in the test results.  I
wonder what is the criteria of test case selection by these tool
vendors and certification agencies.  any comments?

Ravi

On Mon, Jun 2, 2008 at 11:33 AM, Srinivasa Addepalli <[email protected]> wrote:
>
> You got very good answers from Ron. I try to give some specifics.
>
> 1. Generic signatures
>
> There are close to 10000 XSS and SQL injection vulnerabilities (based on
> search in www.osvdb.org).  Some IPS/IDS vendors, including us, don't create
> signatures for each one of them.  We are able to cover them using 200+
> signatures which are generic in nature.
>
> IPS systems having intelligent application detection may cover many buffer
> overflow attacks using few signatures. For example,  we see many HTTP URL,
> HTTP request header/response header field, SMTP/FTP/IMAP/NNTP command buffer
> overflow attacks. Many of them can be detected with few signatures without
> having to develop rules for each CVE.
>
> 2. Signature deletion to improve IPS/IDS performance.  This is one of the
> reasons you could see some discrepancy between CVE IDs and signatures.
>
> Some vendors tend to delete very old signatures.  Deciding which signatures
> to delete is a painful process. Some easier decisions are ones specific to
> executing the local applications via malformed java script of pages related
> to popular web sites. Once these web sites fix the issue, there is no need
> for these signatures.
>
> 3. Vulnerabilities which can only be exploited after authentication.  Some
> vendors tend to give lower priority for these vulnerabilities.
>
> 4. Vulnerabilities related to services which are typically accessed by other
> machines within same network (within one administrative domain).  Some
> examples are LDAP and RADIUS servers. These are typically accessed by other
> servers within the network, that is, these services are not exposed to wider
> network.  Again some vendors tend to give lower priority for these
> vulnerabilities.
>
> 5. Client side attacks requiring deeper data inspection:  For network
> IDS/IPS, it becomes very difficult to develop signatures (requiring deeper
> data inspection) which can detect without any false positives and negatives.
> File based attacks is one example, where when the file is opened, client
> application either crashes or malfunctions. Difficulty of signature
> development arise from different methods to get the files (email, http
> etc..) and encoding mechanisms used. Due to these difficulties, you might
> not see signatures for some of these attacks. (One example: CVE-2008-0105)
>
> 6. Lack of information on vulnerabilities:  Yet times, you see some time
> difference between disclosure and signature due to this.
>
> Srini
>
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On
> Behalf Of Ron Gula
> Sent: Thursday, May 29, 2008 11:36 AM
> To: Focus IDS
> Subject: Re: CVE selection for IDS/IPS signature rules
>
> Ravi Chunduru wrote:
>> Hi,
>>
>> There are over 30000 CVE vulnerability reports.  Many IDS/IPS devices
>> have around 4000-5000 signature rules. My guess is that these
>> signatures may cover (detect)around 4000-7000 attacks.  23000 to 26000
>> CVEs, that is, significant number of CVEs are not covered by IDS/IPS
>> devices.
>>
>> I am guessing that there is reason for this. IDS/IPS vendors may be
>> selecting few CVEs for developing signatures. What is the selection
>> criteria followed in industry? One criteria, I know is that Network
>> IDS/IPS devices don't need to worry about attacks that can only be
>> mounted on the local machine, that is,  NIDS/NIPS devices only need to
>> worry about detection of attacks mounted remotely. Are there any other
>> considerations?
>>
>> Thanks
>> Ravi
>
>
> Hi Ravi,
>
> There are several reasons, probably more.
>
> Some NIDS vendors try to code for generic exploit vectors and not
> specific vulnerabilities. Some try to do both.
>
> Many of the CVEs not covered are for products that have come and
> gone, are very old, don't work over TCP/IP and so on.
>
> Some CVE entries focus on weak encryption and denial of service
> attacks which can be difficult to see with NIDS technology.
>
> Ron Gula
> Tenable Network Security
> http://www.nessus.org
>
>
>
>
>
>
>
>
>
> ------------------------------------------------------------------------
> 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.coresecurity.com/index.php5?module=Form&action=impact&campaign=in
> tro_sfw
> 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.coresecurity.com/index.php5?module=Form&action=impact&campaign=intro_sfw 
to learn more.
------------------------------------------------------------------------