Detection Component

Each logical operation in the detection component is a dictionary with an op field. Complex logical evaluation is done by using two special op values: and and or. These will take a rules parameter that is a list of other logical operations to perform.

 Here is a basic example of a rule that says: When we receive a STARTING_UP event from a linux sensor, and this sensor has the tag test_tag, match.

op: and rules: - op: is linux event: STARTING_UP - op: is tagged tag: test_tag
The event: SOME_EVENT_NAME pattern can be used in all logical nodes to filter the type of event being evaluated. You can also use an "events": [ "EVENT_ONE", "EVENT_THREE"] to filter for the event being one of the types in the list. When a detection is generated through the report action (see below) it gets fed back into D&R rules with an event_type of _DETECTIONNAME. This can be used to compose higher order detections.
 events: - EVENT_ONE - EVENT_THREE

report


report reports the match as a detection. This means that the content of this event will be bubbled up to the Detection Output stream. Think of it as an alert. It takes a name parameter that will be used as a detection category and a publish parameter that, if set to false means the report won't be published to the Output stream.

This last distinction about the publish parameter is important because the detections created by the report action get feed back into the D&R rules so that more complex rules may handle more complex evaluations of those. Setting the publish to false means that this detection is only really used as an intermediary and should not be reported in and of itself. When fed back, the event_type is set to _DETECTIONNAME.

To create a named report event from a response action you would add the following.

- action: report name: MYDETECTIONNAME

A detection rule for this report action would look like this.

rules: - op: is name: _MYDETECTIONNAME path: routing/event_type