[Discussion] OISF to Support Barnyard2 Development!

Matthew Jonkman jonkman at emergingthreatspro.com
Wed Jun 29 10:44:51 UTC 2011 

I think this is a great idea for a number of things. Even if you're not a site that wants an event not alerted if the victim isn't vulnerable, this could be used as a way to tag alerts with a note that the victim is reported to be vulnerable and prioritize the event apprproiately, or vice versa if not vulnerable.

 (reference the myriad discussions we've had on the ET lists about whether you should react when there is hostile intent, vs hostile success).

The Qualys folks are very cooperative, and i'm sure would be interested in some kind of involvement. They've got a really interesting new project in the works called Iron Bee, and open source WAF. 

How much interest is there to do this at this level? If you're wanting this functionality would you be better off going with an existing correlation engine, or should we go down this road here?

Matt


On Jun 28, 2011, at 10:34 PM, Robert Vineyard wrote:

> Kevin - indeed, good news all around - thanks for the heads-up, I've
> added the Snort blog to my RSS reader so I won't miss stuff like that in
> the future :-)
> 
> I apologize in advance for the long-winded post... the interesting bits
> are near the bottom if you'd prefer to skip over the next few paragraphs.
> 
> So... while we're talking about retooling Barnyard2, it occurred to me
> that an old open-source project developed and semi-supported by Qualys
> might be a prime candidate for integration into the Barnyard2 output
> framework:
> 
> http://quidscor.sourceforge.net/
> 
> I've reviewed their code and the related papers they presented at
> BlackHat back in 2003, and I have been in contact with our Qualys
> support engineer who confirmed that the license the code was released
> under permits forks and derivative works. I wouldn't call it
> GPL-compatible, but it's fairly close to the BSD-style licenses.
> 
> Not to put too fine a point on it, but QuIDScor is easily the beginnings
> of a SIEM in a box, minus the log-mining features :-) Today it's
> vendor-specific (Qualys), but the code seems extensible enough that it
> could be easily adapted to work with other vulnerability assessment
> tools such as Nessus / OpenVAS.
> 
> To me, one of the "holy grails" of implementing a SIEM-type solution
> involves end-to-end mapping all the way from the IDS and firewalls at
> the border down to any available data about the targeted host on an
> internal network. The QuIDScor code does just that, is written in C with
> minimal external dependencies, and appears to be fast enough to keep up
> with Snort (and Suricata?).
> 
> Wouldn't it be cool to offer that level of situational awareness in an
> open-source framework? Projects like Prelude and OSSIM are on the right
> track, but building comprehensive IDS alert --> Vulnerability Assessment
> data mapping into the core of the IDS log processor (i.e. Barnyard2)
> sounds to me like a much more efficient way of doing things than
> performing correlation after the fact.
> 
> Barnyard2 already knows about the Snort / Suricata SIDs and any URL
> references they might link to. In many cases, these URLs and/or the data
> they point to contain globally unique identifiers such as CVE numbers
> and Bugtraq ID's. From there, using QuIDScor or a similar methodology,
> one could fully automate this transformation:
> 
> IDS Alert SID --> CVE / Bugtraq ID --> Vulnerability Assessment data
> 
> If all of these datasets are available, this mapping would make it
> possible to very quickly eliminate huge volumes of false-positive alerts.
> 
> Perhaps my objective would be more clear with an example:
> 
> An exploit comes in from the outside and is flagged by our border IDS
> (in this case Snort, but Suricata could serve the same purpose). This
> traffic passes through our firewalls and eventually reaches its intended
> destination. If I know from my IDS rules that this exploit corresponds
> to a particular CVE or Bugtraq ID, and I know from my Vulnerability
> Assessment data that this host is not vulnerable to said exploit as
> defined in the matching CVE / Bugtraq ID, then I have just eliminated a
> false positive.
> 
> The obvious case would be something like an Windows IIS exploit targeted
> against an Apache web server running on Linux. or vice-versa - either of
> which co9uld be rapidly and automatically filtered out if those
> additional data points were readily available for cross-referencing.
> 
> --
> Robert Vineyard, CISSP, RHCE
> Senior Information Security Engineer
> Georgia Tech Office of Information Technology
> 404.385.6900 (office/cell) / 404.894.9548 (fax)
> 
> On 06/28/2011 11:04 AM, Kevin Ross wrote:
>> Perhaps some collaboration is needed
>> http://blog.snort.org/2011/06/snorts-output-methods.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+Snort+%28Snort%29
>> <http://blog.snort.org/2011/06/snorts-output-methods.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+Snort+%28Snort%29>
>> 
>> On 28 June 2011 15:53, Robert Vineyard <robert.vineyard at oit.gatech.edu
>> <mailto:robert.vineyard at oit.gatech.edu>> wrote:
>> 
>>    Matt, that is excellent news :-)
>> 
>>    This may be wishful thinking, but I don't suppose a database schema
>>    refresh might be in the cards would it? (perhaps to accommodate IPv6
>>    addresses)
>> 
>>    --
>>    Robert Vineyard, CISSP, RHCE
>>    Senior Information Security Engineer
>>    Georgia Tech Office of Information Technology
>>    404.385.6900 (office/cell) / 404.894.9548 (fax)
>> 
>> 
>>    On 06/28/2011 07:02 AM, Matthew Jonkman wrote:
>>> The Open Information Security Foundation (OISF) will provide
>>    support to Ian Firns (aka "firnsy"), one of the official Barnyard2
>>    maintainers at SecurixLive, to help get a few milestones completed
>>    within the Barnyard2 roadmap. Most significantly a Snortsam Output
>>    Plugin will be completed to allow both Snort and Suricata users to
>>    more easily plug in to Snortsam for distributed blocking and
>>    response using Frank Knobbe's Snortsam project. This will make using
>>    Snortsam much easier as it will no longer require patching Snort or
>>    Suricata on each upgrade.
>>> 
>>> Barnyard is a critical piece of Suricata as well as Snort, so this
>>    support is beneficial to the community as a whole!
>>> 
>>> Matt
>>> 
>>> ----------------------------------------------------
>>> Matthew Jonkman
>>> Emergingthreats.net
>>> Emerging Threats Pro
>>> Open Information Security Foundation (OISF)
>>> Phone 765-807-8630 x110
>>> Fax 312-264-0205
>>> http://www.emergingthreatspro.com
>>> http://www.openinfosecfoundation.org
>>> ----------------------------------------------------
>>> 
>>> PGP: http://www.jonkmans.com/mattjonkman.asc
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> Discussion mailing list
>>> Discussion at openinfosecfoundation.org
>>    <mailto:Discussion at openinfosecfoundation.org>
>>> http://lists.openinfosecfoundation.org/mailman/listinfo/discussion
>>    _______________________________________________
>>    Discussion mailing list
>>    Discussion at openinfosecfoundation.org
>>    <mailto:Discussion at openinfosecfoundation.org>
>>    http://lists.openinfosecfoundation.org/mailman/listinfo/discussion
>> 
>> 
> _______________________________________________
> Discussion mailing list
> Discussion at openinfosecfoundation.org
> http://lists.openinfosecfoundation.org/mailman/listinfo/discussion


----------------------------------------------------
Matthew Jonkman
Emergingthreats.net
Emerging Threats Pro
Open Information Security Foundation (OISF)
Phone 765-807-8630 x110
Fax 312-264-0205
http://www.emergingthreatspro.com
http://www.openinfosecfoundation.org
----------------------------------------------------

PGP: http://www.jonkmans.com/mattjonkman.asc

More information about the Discussion mailing list