Re: Snort and Nessus Signature

[Jason <security () brvenik com>]

I did not think that response indicated offense and I am not offended. I
though the response was a factual response based on the information I have.

Vikram Phatak wrote:
> Wow.  I did not expect that kind of response...  I offered to discuss in
> detail with Crux or anyone else interested.  Have I somehow offended you?
>
> Jason wrote:
>
> > Vikram Phatak wrote:
> >
> > > Hi Crux,
> > >
> > > It is not a simple matter to integrate Nessus & Snort since there are
> > > quite a few errors in the snort signatures, or in the supporting
> > > information for many of the snort signatures (CVE, BID, descriptions,
> > > etc.).  
> >
> >
> >
> > How so? Please provide a little more information. 
>
>
> First, if you look at the non-VRT certified signatures from Snort, or
> historically at Snort signatures in general, they do not consistently
> have references, and in many cases needed to be updated to support
> functions available in newer versions of Snort (like PCRE) that provide
> better accuracy and lower false positives.  Sourcefire recognized this -
> which is why they rewrote over 1000 signatures (may be more now) which
> can be purchased as part of their VRT Certifiied signature program.

I think it is an absolute injustice to generalize this statement to
Snort as a whole. There are many groups that produce snort rules of
varying quality but the official snort.org rulesets are not as described.

> Having said that, we have found that there can be multiple CVE entries
> for the same vulnerability, signatures that have no CVE, multiple nessus
> plugins that have the same CVE (sometimes correct, sometimes not) etc. 
> You cannot simply assume that everything is correct, and correlate
> automatically and expect to have any confidence in your results - which
> means you need to inspect every single correlation (which takes time). 

Agreed. There is a lot of room for improvement in the vuln DB space.
That there are several reference points for any one issue is
problematic. That each reference point handles them differently further
complicates this.

[...]

> > > Also, many snort signatures do not have CVE, BID references since
> > > historically they have written based upon packet captures of specific
> > > exploits,  (such as "Sasser") as opposed to vulnerabilities
> > > (LSASS), which is how CVE entries are sorted.
> >
> >
> >
> > Absolutely incorrect. LSASS is the detect method and the rules detect
> > exploitation of a vulnerability not an exploit.
>
>
>
> Um.  Please check your facts.  Sourcefire did not provide its VRT
> service until Feb/March '05, while LSASS vulnerability that the SASSER
> worm exploited came out in April/May '04.   The only signatures publicly
> available at the time were exploit signatures based upon PCAPs of the
> different worm variants...  Despite any marketing that would have you
> believe otherwise.

Here are your facts.

http://securityresponse.symantec.com/avcenter/venc/data/w32.sasser.worm.html

- Discovered on: April 30, 2004

[...]

http://www.sourcefire.com/services/advisories/sa050204.html

[...]

released on April 27, 2004, contained SID 2514 that will detect infected
hosts attempting to compromise other hosts via the LSASS vulnerability.
This rule will generate multiple events due to Sasser worm activity.

[...]

These rules were in the snort.org set before there was a worm and the
rules were quite effective in detecting the worm and variants as well as
non worm exploitation attempts.

[...]

> But to your point - assuming 100% accuracy of references and that most
> eventually point back to something that can be correllated with a Nessus
> plugin - which 70% are covered?  How do I, as an admin, know I am not
> missing something?  There needs to be some examination of effectiveness
> before simply saying "lets correlate".  Or rather, correlate - but audit
> your results.  That was the point of my prior posting.

Apologies if I got the context wrong there. The shortcomings of text
based interactions. I absolutely agree that there are challenges with
the various vuln data sources.

IMHO there are no absolutes in security so any correlation done is
ultimately additional data that can be taken into account. Even a 10%
coverage would provide better value than the current 0% coverage.

> > > We (Lucid Security) have found that it was far more efficient (and
> > > reliable) to choose the OS & Application versions that we want to
> > > protect (MSFT, Linux, Solaris, Apache, IIS, SQL, etc.) and prioritize
> > > accordingly.  We then chose the appropriate CVE entries that met the
> > > requirements of our "filter" and wrote and tested signatures based
> > > upon the vulnerability accordingly.  If there was an existing
> > > signature that met our requirements, then great! But we found that
> > > was rarely the case.  
> >
> >
> >
> > I take it you are not in the spirit of the community and as such are
> > either selling your wares and saying screw the rest of the community
> > or you are simply spreading FUD. Which is it?
> Nice.  Do you attack Ron or Marty with this kind of nonsense?  I am
> offering advice from experiences that we have gone through and you are
> asking me if I am saying "screw the community" or "spreading FUD"?  It
> is like asking, "Do you still beat your wife?"

Well do you? ;-)

I think I addressed this above. Your advice is certainly welcome. Your
results are even more welcome. _That_ would be in the spirit of the
community.

> From what I saw you indirectly challenged the quality of the community
with incorrect data while promoting your own product as superior. I
found your statements to be incorrect. No offense intended.

------------------------------------------------------------------------
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.securityfocus.com/sponsor/CoreSecurity_focus-ids_040708 
to learn more.
------------------------------------------------------------------------