hi Suat,
one possible solution for addressing this task is to combine the EventGroup
rule with contexts. Since EventGroup rule allows matching unordered event
groups (e.g., events A, B and C can appear in any order), the purpose of
contexts is to force specific event matching order. The example given below
processes events EVENT_A, EVENT_B and EVENT_C, and for the sake of
simplicity, these events are matched with SubStr patterns. Also, for
simplifying cleanup procedure, the example rule sets up only one context
EVCONT for event correlation, and employs context aliases EVCONT_A and
EVCONT_B for indicating that events A and B have already been observed
(deleting EVCONT would automatically remove both alias names). Since three
events need to be processed, the rule type has been set to EventGroup3:
type=EventGroup3
init=create EVCONT
end=delete EVCONT
slide=reset 0; delete EVCONT
ptype=SubStr
pattern=EVENT_A
context=!EVCONT_A
count=alias EVCONT EVCONT_A
ptype2=SubStr
pattern2=EVENT_B
context2=EVCONT_A && !EVCONT_B
count2=alias EVCONT EVCONT_B
ptype3=SubStr
pattern3=EVENT_C
context3=EVCONT_A && EVCONT_B
desc=sequence A, B and C observed
action=write - %s; reset 0; delete EVCONT
window=600
When the above rule starts an event correlation operation, the operation
creates the context EVCONT (see the 'init' field), and when the operation
ends, EVCONT is deleted (see the 'end' field). Also, the window of the
operation is not sliding and when not all events have been observed by the
end of the 600 second window, the operation terminates itself with 'reset'
action and deletes the EVCONT context (see the 'slide' field). As mentioned
before, the EVCONT context has two alias names -- EVCONT_A indicates that
event A has already been observed, while EVCONT_B manifests the fact that
event B has been seen. The above rule has three patterns ('pattern',
'pattern2' and 'pattern3' fields) and normally, a match against any of
these patterns would start the event correlation operation. However, due to
'context2' and 'context3' fields, events B and C will not match this rule
initially, and only event A can match the rule in the beginning (because
unlike 'context2' and 'context3' fields, the boolean expression in the
'context' field evaluates true). When event A appears, the event
correlation operation is started, and after the event has been processed,
the operation also creates EVCONT_A alias name (see the 'count' field).
Note that the creation of this alias name means that event A no longer
matches this rule (since the boolean expression provided by 'context' field
now evaluates false), but event B is now matching (since boolean expression
in 'context2' field now evaluates true). In other words, the rule is now
expecting to see event B. Similarly, after event B has been observed, the
creation of the alias name EVCONT_B makes the rule to expect event C (see
'count2' and 'context3' fields). Finally, when event C appears, the string
"sequence A, B and C observed" is written to standard output, and the event
correlation operation will terminate itself with 'reset' action and delete
EVCONT context.
The above solution has one drawback -- when several instances of the same
event can appear in the sequence, some sequences might pass unnoticed. For
example, consider the following scenario of four events with timestamps:
12:00:00 event A
12:00:30 event A
12:05:00 event B
12:10:05 event C
The above solution would start an event correlation operation at 12:00:00
which would fail to see the expected sequence by 12:10:00 and thus
terminate. On the other hand, there is a valid sequence in the event stream
that starts from 12:00:30. If you want to handle advanced cases with
repeated events in sequences, a more complex solution is needed.
kind regards,
risto
Kontakt Suat Toksöz (<stok...@gmail.com>) kirjutas kuupäeval N, 6. august
2020 kell 10:19:
> Thanks for the answer. I am looking for window based detection, simple it
> is going to be something like SIEM log correlation. Within 10 min event A,B
> and C must occur and this three event must be in order (first A, then B
> last C)
>
> Thanks
> Suat Toksoz
>
> On Wed, Aug 5, 2020 at 11:58 PM Risto Vaarandi <risto.vaara...@gmail.com>
> wrote:
>
>> hi Suat,
>>
>> are you interested in some rule examples about detecting event sequences,
>> or are you investigating opportunities for creating a new rule type for
>> matching sequences of events? Many event sequences can be handled by
>> combining existing rules and contexts, so a new rule type might not be
>> needed for the task that you have. To clarify the task a little bit, should
>> the solution apply a sliding window based detection if the entire sequence
>> has not been observed within 10 minutes, or is it not important and
>> incomplete sequence after 10 minutes (say, A and B are present but C is
>> missing) terminates the event correlation scheme?
>>
>> kind regards,
>> risto
>>
>> Kontakt Suat Toksöz (<stok...@gmail.com>) kirjutas kuupäeval K, 5.
>> august 2020 kell 15:52:
>>
>>> hi all,
>>>
>>> is it possible to have multiple (3,4..) correlation rule on SEC?
>>>
>>> For example, If event *A* happens then event *B* happens then event *C*
>>> happens and all events happen within 10 min.
>>>
>>> --
>>>
>>> Best regards,
>>>
>>> *Suat Toksoz*
>>> _______________________________________________
>>> Simple-evcorr-users mailing list
>>> Simple-evcorr-users@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
>>>
>>
>
> --
>
> Best regards,
>
> *Suat Toksoz*
>
_______________________________________________
Simple-evcorr-users mailing list
Simple-evcorr-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
