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

[Matthew Jonkman <jonkman () emergingthreatspro com>]

On Mar 19, 2011, at 12:44 PM, Jason Brvenik wrote:
> 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.

Ha! Insults aside, I don't understand what you're saying there.


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

Cool. Didn't know it was a set thing.

> > 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.

Still don't understand. It is true, you've been here no? Nothing we've tried as far as collaboration was ever allowed. 
Or successful.

> > 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.

That's sounds very "not my job" to me. If it's a problem, and you can help fix it, why don't you?

But that's just philosophy. We have different ones, they're both ok, depends on your environment. If your AV is 100% 
then you probably don't need IDS to lend a hand. 


> 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.

Ya, they're a good company and looks like great tech. Not really relevant though, and it's windows only. IDS I think is 
still necessary to pick up the slack. I doubt immunet would even say they're 100%.

> > 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.

I suppose. Haven't seen a referral yet though. I just can't imagine a customer where malware isn't a problem though...

> 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

Ya, it is good stuff. 


> > 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 think it is germane, because we're talking about where the master rules might be held if we were to collaborate. I 
don't think it's appropriate for them to held by an entity that'll not be maintaining the old versions. That's all. 

And ya, running an old engine isn't smart, but some folks haven't a choice, and some folks are running other engines 
that use the old versions, and some folks run Suricata. So there is a definite need for older versions. Just because 
it's not idea if you are running old snort doesn't mean there isn't a need for the old versions.

> > 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.

:) No not sourcefire. Sourcefire's policies send us a lot of commercial subscribers. You're our best marketing tool. :)

Annoyed I think of late at the overtures for collaboration. It's the same old thing over and over and it is getting in 
the way of the ET Open rulesets development. 
> Thanks! I didn't know we were the largest, I thought that designation
> went to Cisco.

I'm trying to call you largest market share. But if you want to be number 2 that's fine. :)

Matt

> > 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:
> >
> > > > Old 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
> _______________________________________________
> Emerging-sigs mailing list
> Emerging-sigs () emergingthreats net
> http://lists.emergingthreats.net/mailman/listinfo/emerging-sigs
>
> Support Emerging Threats! Subscribe to Emerging Threats Pro http://www.emergingthreatspro.com
> The ONLY place to get complete premium rulesets for Snort 2.4.0 through Current!
> >



----------------------------------------------------
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