[Oisf-wg-ruleslanguage] OISF Rules Syntax Working Group Kickoff

[Matt Jonkman]

First off thanks to everyone for joining the working group list. Please
feel free to contribute ideas, discuss, contradict, and brainstorm.

We do not have a group lead here, volunteers appreciated! The group
lead's responsibility will be to steer the conversation if it gets off
on a tangent or too deep into the weeds, and to summarize the
recommendations of the group.

We want to get a recommendation from the group within 2 weeks, so we'll
call it August 12th the report date. We'll send those recommendations to
the main mailing lists for further comment.

You have wiki space to use for notes, etc. Robert will have overall
control of that space but everyone is more than welcome to add and edit.

http://doc.emergingthreats.net/bin/view/Main/RulesSyntaxWG

The core questions for this group (as stated on the wiki page) are:
----------------

    *  What might a new rules language look like? What would make more
sense in an engine that uses reputation and scoring more than absolutes?

For Snort Syntax Support:

    * How to handle the problems associated with adding directives to
support new functionality and divergence/compatibility.
    * Which Snort syntax directives are used frequently enough to be
implemented in the new engine for backwards compatibility

    * Should this new engine support obfuscating rules about undisclosed
vulnerabilities

While this functionality is not ideal in an open source security
community, it may be necessary to enable the use of data from sources
that do not allow disclosure of rule content for certain periods of time.

    * What languages to support as external scripts that can feed
information back to a rule (i.e. a function for a rule to call). Perl,
Ruby, Python? All?


Please begin discussion and asking questions. I have a lot to say here
and a lot of thought put into it, but will refrain from expounding my
own opinion until people get a chance to weigh in. One thing I'll say
though, it is a primary goal of this project to support the Snort Syntax
as completely as possible in order to not force rewriting of the
existing rules, and to allow companies already selling snort signatures
to continue to do so through this engine. However, we will likely need
either a new language to support the new features in this engine, or a
significant superset of commands added to snort. We don't want to force
a divergence or compatibility issue. Therein lies the crux of the issue
to be solved here.

Thanks for your thoughts, please let them rip!

Matt

-- 
--------------------------------------------
Matthew Jonkman
Emerging Threats
Phone 765-429-0398
Fax 312-264-0205
http://www.emergingthreats.net
--------------------------------------------

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