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