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

[Blake Hartstein]

Thanks Matt,
Please consider the feasibility and performance impact of protocol
parsing specified in the rules:

1) Protocol parsing rules
examples.
proto HTTP_toclient = ( tcp, from_server, established, starts_with
"HTTP", [head, body] = delimiter "\n\n" strip "\r", [@headers] = head
delimiter "\n" strip "\r" )
alias HTTP_fromserver = HTTP_toclient
proto HTTP_toserver = ( tcp, to_server, established, starts_with "GET",
[head, body] = delimiter "\n\n" strip "\r", [@headers] = head delimiter
"\n" strip "\r" )
alias HTTP_fromclient = HTTP_toserver
proto HTTP_useragent = HTTP_toserver + ( headers starts_with "User-Agent:" )

2) Rules that use defined protocols
alert HTTP_toclient "User-Agent Alert" = HTTP_useragent + ( dst $HOME )

So often I'd like to have an IDS identify the protocol before anything
else, and this type of rule seems would be a good way to do it.
I think its important to consider/import firewall rules, because
port-based signatures may be effective if other devices (firewalls)
enforce it.

Blake


Matt Jonkman wrote:
> 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
>
>