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.
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).
Also, there is no mechanism for validating the OS & Applications that
are important to you have complete coverage, unless you begin with the
OS & Applications, pick the related CVE (or other DB) entries and then
find the nessus plugin and snort signatures.
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.
Please see http://seclists.org/lists/bugtraq/2004/May/0016.html
alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"W32/Sasser.worm.a
[NAI])"; content:"|BC 3B 74 0B 50 8B 3D E8 46 A7 3D 09 85 B8 F8 CD 76 40
DE 7C 5B 5C D7 2A A8 E8 58 75 62 96 25 24|"; classtype:misc-
activity;rev:1;)
alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"W32/Sasser.worm.b
[NAI])"; content:"|58 BC 0C FF 59 57 32 31 BD EC 34 64 6E D6 E3 8D 65 04
68 58 62 79 DF D8 2C 25 6A B5 28 BA 13 74|"; classtype:misc-
activity;rev:1;)
While there may have been some cases where vulnerability based
signatures were written by the open source community, it was not the
norm, since in order to write a vulnerability based signature, you (very
often) need to disassemble / debug binaries of both the original
software and the patch in order to diff the two and examine how the
applications can be misused. This is time consuming and difficult. If
on an average week there are 10-20 vulnerabilities (that you care about)
announced, it is not possible to provide timely and accurate signatures
without coordination. I am not saying this cannot be done via the
open-source community, I am saying historically, it has not been done.
Also I feel that it is unrealistic to believe that a service (not
software) that is time sensitive and time consuming can be performed
effectively day after day, week after week by anybody other than an
organized group because of the coordination required.
So, having said all of that, I know that Lucid Security's
signatures/rules are vulnerability based, but many organizations
signatures frequently are not, especially historically - which is
important when you are trying to correlate historical data. I know this
is true because Lucid Security decided to write vulnerability based
signatures for many historical vulnerabilities since it was the only way
to correlate the data with any confidence. And the expense we incurred
to provide this kind of solution was not insignificant.
And there is no publicly available DB that I know of that
correlates exploits to vulnerabilities.
So - In many cases, you will need to determine which vulnerability a
specific exploit was written to take advantage of, and work your way
back from there.
bugtraq reference: 1565
references: 1441
arachNIDS references: 432
McAfee reference: 9
nessus reference: 676
url reference: 971
any reference: 2713
Total number of rules 3910
Bugtraq coverage: 40%
cve coverage: 36%
arachNIDS coverage: 11%
McAfee coverage: 2%
Nessus coverage: 17%
url coverage: 25%
Percentage coverage any reference: 70%
I was not talking about signatures in the sentences you quoted - I was
referring to a lack of exploit to vulnerability DB.
(OS & App version has the following: CAN-2004-0894
<http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0894>
Vulnerability -->Exploits)
Also, I am not saying the information does not exist. I am saying that
it is disjointed and requires a lot of work to examine and prune, etc.
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.
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?"
-Vik
--
Vikram Phatak
CTO, Lucid Security
http://www.lucidsecurity.com
------------------------------------------------------------------------
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.
------------------------------------------------------------------------
