hi Eli,
if you have a large rule set that is stored into one file, you can start
with grouping rules by application/source types that produce messages. For
example, if you have rules for entirely different applications like sshd
and Oracle, it usually makes sense to store rules for such applications
into separate files. While that would make rules more manageable, sec would
still apply rules from all files against any input event (e.g., Oracle
events would still be processed by sshd rules which introduces unnecessary
computational overhead). In order to avoid that, one can make the rule base
hierarchical by assigning labels to rule files with Options-rules, and
employing Jump-rules for directing an input message to rule file(s) with
relevant label(s).
For example, one can set up a top-level rule file called main.sec which
contains Jump-rules for all application types like the one below:
type=Jump
ptype=RegExp
pattern=sshd\[\d+\]:
cfset=sshd-rules security-rules
This rule will match all messages containing the substring "sshd[PID]:" and
direct them to rule files with labels "sshd-rules" and "security-rules". In
addition to top-level rule files that match and route *all* incoming
messages, there are number of second-level rule files which contain rules
for specific applications. For example, one could have a rule file sshd.sec
which starts with the following Options-rule:
type=Options
joincfset=sshd-rules
procallin=no
...here come rest of sshd rules...
Note that "procallin" field has been set to "no" which means that rules
from this file will process only the messages received from Jump rules,
ignoring any other input.
Such hierarchical scheme would also make it easy to share the same rule
file between multiple applications, since each rule file can have more than
one label and each label can be assigned to more than one rule file.
Therefore, if you have a more generic rule file that is relevant for
several applications, you can assign several application-specific labels to
it, so that messages from more than one application get routed to this rule
file.
If you are interested in more detailed examples, SEC documentation provides
one for sshd and iptables messages:
http://simple-evcorr.github.io/man.html#lbBE
I have used such hierarchical arrangement a lot for my production rule
bases, and it has helped to make the rule bases a lot more scalable and
manageable.
hope this helps,
risto
2018-04-03 21:57 GMT+03:00 Kagan, Eli <eli.ka...@dxc.com>:
> Hi there,
>
>
>
> I have two questions that I think are related.
>
> 1. What’s the best way to split a large rule set into multiple
> files?
>
> 2. What’s the best way to reuse rules that are used by multiple
> rulesets?
>
>
>
> Thanks,
>
> Eli
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Simple-evcorr-users mailing list
> Simple-evcorr-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
>
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Simple-evcorr-users mailing list
Simple-evcorr-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
