[Oisf-wg-ruleslanguage] YAML

[Jules Pagna Disso]

all,

I like the idea of not having to repeat the same rule header. We should have
a way of referencing theses rules header to the rest of the rule body.
We should also probably think about a rules format that can be easily used
with a parallel IDS framework. Snort will need to be pimp up for that. Some
vendors use this methods as it help speed up the detection.

Jules

2009/8/7 Bill Scherr IV <bschnzl at cotse.net>

> Matt (et al)...
>
>   The rules are constructed as they are to provide granularity to the rule
> set.  The default rule set is just
> that, default.  Any security practitioner should be aware of the state of
> the default, and reasons that
> things SHOULD be delivered wide open.
>
>   Perhaps a bit on default would be useful here.  For one, bare install
> media that works on any platform
> is easier to check for back doors.  Calls Home (like 'Doze Genuine
> Advantage, and autoupdate a la
> YUM, etc.) carry information that I need to contain, and now its out of my
> control.  It doesn't matter how
> much I trust whom, my control is compromised on these platforms.
>
>   The operative concept here is ownership.  The producers own the code I
> use.  I just license the use for
> my own purposes.  That is fine.  But my production is mine, and NO VENDOR
> should have access to
> anything that I do after I leave their place of business with their product
> that I just paid for, in any fashion.
> That is a base principal of private property.  When you do not object to a
> "EULA" you participate in this
> errosion of all of our rights.  The price of liberty is eternal vigilance,
> etc.  So much for a lesson on default
> delivery states...
>
>   The IDS analyst needs to be able to tweak pin holes to eliminate known
> false positives, known
> ineffective events, ligitimate services that may trigger an alert, etc. ad
> nauseum.  I agree that there may
> be opportunities for YAML elsewhere in this application.  My concern is
> that the current config language
> seems optimized for this application.  That application needs more speed
> and efficiency.  It does not
> need to be bogged down by a binary containing rules and code that are never
> used.  Rather than
> imposing a predefined standard, and patching on an entirely new language,
> how about we just offer
> ideas for tweaking to the folks that are hard at work producing the fastest
> updated, least resource
> intensive, and most examinable IDS around.
>
> My 2¢.
>
> B.
>
> Circa 9:25, 7 Aug 2009, a note, claiming source Matt C <oisf-wg-
> ruleslanguage at openinfosecfoundation.org>, was sent to me:
>
> Date sent:      Fri, 7 Aug 2009 09:25:46 -0400
> From:   Matt C <mbc8434 at gmail.com>
> To:     oisf-wg-ruleslanguage at openinfosecfoundation.org
> Subject:        Re: [Oisf-wg-ruleslanguage] YAML
> Send reply to:  Rules language and obfuscation discussion
> {link snip}
>
> > In the rules language I think this could be very useful:
> >
> > http://en.wikipedia.org/wiki/YAML#Relational_trees
> >
> > Basically you define one rule, and then subsequent rules could reference
> the
> > base rule, only providing changes.  Say for example 500 snort rules all
> have
> > the same header, "alert tcp $EXTERNAL_NET any -> $HOME_NET any".  Why
> > specify that on every single rule?  Why not specify the header on one
> rule,
> > and then reference that rule from all of the other rules?
> >
> > Matt C
> >
>
>
> Bill Scherr IV, GSEC, GCIA
> Principal Security Engineer
> EWA Information and Infrastructure Technologies
> bscherr at iit-tek.com
> bscherr at ewa.com
> 703-478-7608
>
> _______________________________________________
> Oisf-wg-ruleslanguage mailing list
> Oisf-wg-ruleslanguage at openinfosecfoundation.org
>
> http://lists.openinfosecfoundation.org/mailman/listinfo/oisf-wg-ruleslanguage
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openinfosecfoundation.org/pipermail/oisf-wg-ruleslanguage/attachments/20090807/41ccfcf8/attachment-0002.html>