headers
Ravi Chunduru | 3 Jun 2008 19:30
Picon

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 <srao <at> intoto.com> 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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Enigma | 3 Jun 2008 19:43

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
>
> ------------------------------------------------------------------------
> 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.
> ------------------------------------------------------------------------
>
(Continue reading)

Permalink | Reply | 6 comments |
headers
Dimitris Patsos | 3 Jun 2008 20:42
Picon
Favicon

RE: CVE selection for IDS/IPS signature rules

Hi,

Let me add another complexity dimension in this topic.

Few IDS/IPS vendors can correlate their vulnerability assessment tools
with their IDP products (i.e. McAfee,IBM,Tenable,and a few others). None
of them however, can link vulnerabilities with exploits and IDP
signatures as well, which makes sense since IDP detects attacks (i.e.
one or more vulnerabilities exploited in a predefined -not random-
order) not plain vulnerabilities.

The IDP community -to the best of my knowledge- is still missing a
topological-aware mechanism to produce potential attacks based on real
vulnerabilities found in systems/networks. To this extend, it is still
virtually impossible to eliminate false positives in IDP (learning mode
is a nightmare for those who tried, clearly not an option) while it's
also extremely hard to eliminate false negatives in VA tools (it would
be great if a tool could base verdict upon partially discovered signs of
attacks).

What seems of interest and what I've been working on this for the last
couple of years is to integrate post-incident capabilities (e.g. info
from SIEMs) along with vulnerability scoring (like Mitre's CVSS) into
IDP/VA tools. 

This would allow for quite flexible configuration scenarios in IDP,
since vulnerabilities are discovered (VA tool) and (semi)automatically
scored (CVSS), verified (SIEM information) while a smaller set of
signatures (IDP) can detect and block attacks since they can break the
predefined order of vulnerability exploit.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Srinivasa Addepalli | 2 Jun 2008 20:33

RE: CVE selection for IDS/IPS signature rules


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
(Continue reading)

Permalink | Reply | 1 comment |
headers
Leon Ward | 3 Jun 2008 20:40
Picon

Re: CVE selection for IDS/IPS signature rules

A quick comment on the below point:

> 2. Keep in mind that CVE is Common **Vulnerability* *and Exposures,
>     so it covers any vulnerability where IDS/IPS are generally
>     exploit-centric.  How are you going to detect if a vulnerability
>     is exploited if there is no publicly known exploit?  How do you
>     find something when you don't know what it looks like?

All leading IPS venders provide (or at least claim to provide) a  
vulnerability based detection capability.
The *idea* behind this is simple. Model the protocol and all the  
required triggering conditions for the vulnerability to be exploited,  
and it doesn't matter what exploit-code is being used.

<Disclaimer : I work for Sourcefire>

Snort has had this capability for years. For those interested a VRT  
(Sourcefire's Vulnerability Research Team) white paper is available  
that details this process with examples.

-Leon

On 3 Jun 2008, at 18:43, Enigma wrote:

> 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
(Continue reading)

Permalink | Reply | 2 comments |
headers
Jose Nazario | 3 Jun 2008 22:24
Favicon

Re: CVE selection for IDS/IPS signature rules

an earlier comment from ron gula touched on how some vulns are remote etc. 
as of a few days ago, here's some quick numbers around the "range" element 
(where the attack can be mounted from) from the NVD, which annotates CVE 
entries. note that some attacks can have multipe range attributes.

nvd=# SELECT range_type, count(range_type) from range group by range_type;
   range_type   | count
---------------+-------
  local         |  5368
  remote        | 19697
  user_init     |  3121
  network       |  6929
  local_network |   114
(5 rows)

data from http://nvd.nist.gov/, imported into a local SQL database for
use.

________
jose nazario, ph.d.		    http://monkey.org/~jose/

------------------------------------------------------------------------
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.
------------------------------------------------------------------------
(Continue reading)

Permalink | Reply | 0 comments |
headers
Enigma | 3 Jun 2008 21:00

Re: CVE selection for IDS/IPS signature rules

Leon Ward wrote:
> A quick comment on the below point:
>
>> 2. Keep in mind that CVE is Common **Vulnerability* *and Exposures,
>>     so it covers any vulnerability where IDS/IPS are generally
>>     exploit-centric.  How are you going to detect if a vulnerability
>>     is exploited if there is no publicly known exploit?  How do you
>>     find something when you don't know what it looks like?
>
> All leading IPS venders provide (or at least claim to provide) a 
> vulnerability based detection capability.
> The *idea* behind this is simple. Model the protocol and all the 
> required triggering conditions for the vulnerability to be exploited, 
> and it doesn't matter what exploit-code is being used.
>
> <Disclaimer : I work for Sourcefire>
>
> Snort has had this capability for years. For those interested a VRT 
> (Sourcefire's Vulnerability Research Team) white paper is available 
> that details this process with examples.
>
> -Leon
>
>
> On 3 Jun 2008, at 18:43, Enigma wrote:
>
>> Ravi Chunduru wrote:
>>> Hi,
>>>
>>> There are over 30000 CVE vulnerability reports.  Many IDS/IPS devices
(Continue reading)

Permalink | Reply | 1 comment |
headers
Joel Esler | 5 Jun 2008 17:09
Picon

Re: CVE selection for IDS/IPS signature rules


On Jun 3, 2008, at 3:00 PM, Enigma wrote:

> This is a little off topic.  Not knocking Sourcefire or VRT (3D is  
> great and I use the VRT sigs all the time) but I have found these  
> type of signatures to have the highest rate of false positives.   
> Don't get me wrong, these are useful when there isn't anything else  
> but signatures developed from public or at least seen-in-the-wild  
> exploits are much more accurate.

I know that Sourcefire has a great false positive reporting method for  
rules.  Pcap's are needed.

--
Joel Esler
  joel.esler <at> mac.com
  http://blog.joelesler.net
[m]

------------------------------------------------------------------------
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.
------------------------------------------------------------------------
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ravi Chunduru | 5 Jun 2008 03:42
Picon

ActiveX programs

i am not familiar with windows technologies much.  Please correct if I
am wrong.
my understanding is that once activex programs are installed, these
functions can be activated by
javascript in browser context.  They don't have origin policy concept
as provided by browsers for
applets.  Because of this, users when they get attracted to malicious
website, users might inadvertently
provide control of their machine (or execute some commands), if the
java script in the pages access vulnerable
function of already installed activex programs.

today i saw one CVE disclosure :  CVE-2008-0953:  HP Online Support
ActiveX Multiple Vulnerabilities.
there is very good POC at
http://www.csis.dk/dk/forside/CSIS-RI-0003.pdf.  I found this in
full-disclosure mailing list.
In that document, there is snort rule, which is checking for a specific clsid.

My question is on false positives.  Won't it give false positive, if
user is going to HP support site?
IMO, the rule should check for 'Host' field for  in addition to clsid.
'Host field value should not have '*hp.com".  since host and clsid
information comes in two
different directions (client to server in case of Host and service to
client in case of clsid),  it may require two rules with state
tracking.

Am I making sense?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Sanjay R | 4 Jun 2008 19:54
Picon

Re: IPS/IDS behavior with ISIC/UDPSIC/TCPSIC/ICMPSIC traffic

On Sat, May 24, 2008 at 11:40 AM, Ravi Chunduru
<ravi.is.chunduru <at> gmail.com> wrote:
> Hi,
>
> What do you mean by "attacks must be detected at much earlier stages
> when creating a NETWORK"?

Sanjay>> at the time of creating Botnet i.e detecting the infection of
individual system.

> If you seem to indicate that it is responsibility of victim company to
> get more bandwidth, then  it would be still lot smaller than the
> bandwidth botnets have or patriotic activists have (combined
> ofcourse).

sanjay>> NO, i did not mean this. its clear now, i suppose.

>
> Ravi
>
>
> On Mon, May 19, 2008 at 8:00 AM, Sanjay R <2sanjayr <at> gmail.com> wrote:
>> Hi..i think the mail was not delivered to the group. so i m resending.
>> pardon for duplication to some.
>>
>> -sanjay
>>
>> On Sun, May 18, 2008 at 2:03 PM, Sanjay R <2sanjayr <at> gmail.com> wrote:
>>> hi Ravi:
>>> I am not aware of whether NSS has or not the DDOS attacks in its list,
(Continue reading)

Permalink | Reply | 0 comments |

Gmane