Re: [Emerging-Sigs] GPL rules - who maintains them? Nobody?

[Jason Brvenik <jason () sourcefire com>]

On Sat, Mar 19, 2011 at 10:41 AM, Matthew Jonkman
<jonkman () emergingthreatspro com> wrote:
> I would like uniformity. I think we would agree on most of the changes in the gpl rules between ET and VRT. But there 
> will be issues I suspect:
>
> 1. Speed of updates. ET Open and Pro rulesets update about daily. You submit something it's
> changed in 24 hours and published. VRT is weekly at best (still astounds me that people
> accept that... would AV updates be ok that slow? Why IDS?). I don't think this community will
> work well with a week or longer update cycle, especially if we're waiting for approval from vrt
> to make a change in a gpl sig. We just operate differently, and I don't see easy collaboration
> there. If we make a change on our schedule and vrt disagrees a week later we have
> unnecessary overhead and flipflop.

We do operate differently, for good reason. Our customers demand
stability and effectiveness.
Because our customers demand stability and effectiveness doesn't mean
you can't create a new rule and run with it, referencing the old is
perfectly acceptable.

For clarification, we generally publish Tuesdays and Thursdays but if
there is cause will publish out of cycle.

> 2. We've been hashing over collaboration between vrt and SF and ET for what, 7 years now?
> Every time it's come down to SF saying no, we can't do that because it's not in our
> commercial interest. I frankly just don't believe it will be any different this time (try number
> 62). I know you're sincere about wanting to collaborate Joel and Jason, but I just don't
> believe anything can come of it from above. We all get along great at the personal level, the
> VRT team and the ET team and communities are both great people at the top of their games
> that help each other when needed. But when the approval process of SF comes into play it
> always gets stopped. So we're best off with informal agreements as we've been doing for
> years.

If that were true the snort engine would have gone the path of nessus ages ago.

> 3. Lets be clear here. The ET ruleset is NOT here for VRT to pick the best of and consume
> making VRT some kind of uber-ruleset and then we'll drop whatever VRT consumes out of the
> ET ruleset. The ET ruleset is NOT a secondary or sub-par ruleset. This ruleset stands on it's
> own, it's independent, and frankly it's better than VRT because of the community that runs it
> and the speed at which we cover malware. OSSRC may have been appropriate 5 years ago,
> but those days are gone. So lets talk on an equal playing field or not at all.

Reference from my other mail why this wouldn't happen. Ultimately I
think the problem is perspective, IPS is NOT anti-malware, our
technologies can be used for it but that is not the right way to solve
the problem.

If you really want to start to solve that problem have a look at our
latest acquisition, Immunet (It is free BTW) -
http://www.immunet.com/main/index.html

Immunet convicts malware at a rate well beyond the ability of the
fastest community by the nature of it's design.

> 4. The ET Open ruleset will continue to flourish as the community stays involved and keeps
> making it great, and we keep taking and pushing the intel they share in a timely manner. It'll
> also flourish as the ET Pro ruleset remains a commercial success to support the open ruleset
> which also gives folks one place to get all the mainstream vulns plus the malware without
> duplication. So at the end of the day we are competitive. Closer collaboration will very likely
> not sit well with the SF management team. So why are we pretending it might?

That isn't the issue at all. The few users we have that want malware
capability in the IPS are referred to ET, this arrangement works great
if you ask me.

We believe Immunet is a better approach all together, please have a
look at how we do it in a much faster and more effective manner -
http://www.immunet.com/main/index.html

> 5. We have many more versions of the rules available, including Suricata and many more
> back versions of Snort. So if there is a master set of the rules to be maintained it should be
> here, not at VRT. VRT can then pull the limited versions they publish. That makes perfect
> logical sense, so lets talk about that. We will take whatever changes VRt proposes and
> integrate them within 24 hours, and it'll still be within the update cycle of vrt. And you'll have
> many more versions available to you should you choose to quit end of life-ing active products.

I don't think this is germane to the conversation about ET not
duplicating rules mastered elsewhere. We should have a separate
conversation about publishing rules for old engines if you want to get
into the topic in depth. I understand that some users can't upgrade
but running an engine that is 6 years old is a disservice and
publishing rules for it is also wrought with ills.

> I realize I've come off a bit dick-ish the last couple days. Perhaps I'm ovulating. But the above
> is how I see things, and I don't believe this time will be different with sourcefire. ("Please
> come back baby, I swear won't hit you... again..."  ) I'm just not buying it.

lol, I think you are a bit upset with Sourcefire, that is ok, but
don't let that keep you from listening to your users.

> Let this be VERY clear: I am not impuning the character or community spirit of Joel or Jason
> or any of the VRT guys. You're all great guys and I enjoy working with you all. But you work
> for the largest security vendor in the space who's only goal is to get more market share to
> jack up the share price while everyone prepares to cash out, or get yourselves bought by one
> of the big 5. Having a larger and faster moving ruleset doesn't get that market share (A long
> list of cve's covered does, so malware isn't a priority) so I am dubious there will be any
> movement here.

Thanks! I didn't know we were the largest, I thought that designation
went to Cisco.

> But at the end of the day I'm just one guy in the ET community, and this community does
> what this community as a whole wants. So I've laid out my thoughts on collaboration, and I
> don't believe it'll work unless we maintain that repository since we produce more versions and
> platforms.
>
> Thoughts? This is the decision of the ET community, so please weigh in! I'm sure some will
> disagree and lambaste me (Paul, where are ya?) but I want to hear it all. We'll decide what to
> do together.
>
> Matt
>
>
> On Mar 18, 2011, at 7:50 PM, evilghost () packetmail net wrote:
>
> > * PGP Signed by an unverified key: 3/18/11 at 7:50:50 PM
> >
> > On 03/18/11 18:45, Jason Brvenik wrote:
> > > Define "them" please
> > >
> > > Is your assertion that users don't need to run VRT and ET Rules sets?
> >
> > He's talking about GPL duplication across both the VRT and ET sets, there's no
> > point to run true duplicated rules, matter of fact it results in SID collision
> > and breakage.
> >
> > So, if ET is making changes to these GPL rules, hopefully they'll be committed
> > into the VRT set (if they're not deprecated) so that there is uniformity across
> > both rule sets.
> >
> > --
> > It has been said that "hate" is a powerful emotion, perhaps that's why I'm so
> > strong.
> >
> > -evilghost
> >
> > * evilghost () packetmail net <evilghost () packetmail net>
> > * 0xEEEB1387 - Unverified(L)
>
>
> ----------------------------------------------------
> 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

------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
_______________________________________________
Snort-users mailing list
Snort-users () lists sourceforge net
Go to this URL to change user options or unsubscribe:
https://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
http://www.geocrawler.com/redir-sf.php3?list=snort-users