...
- Referencing fields in the enriched JSON
- Simple boolean operations: and, not, or
- Determining whether a field exists (via
exists
) - The ability to have parenthesis to make order of operations explicit
- A fixed set of functions which take strings and return boolean. Currently:
IN_SUBNET(ip, cidr1, cidr2, ...)
IS_EMPTY(str)
STARTS_WITH(str, prefix)
ENDS_WITH(str, suffix)
REGEXP_MATCH(str, pattern)
- A fixed set of string to string transformation functions. Currently:
TO_LOWER
TO_UPPER
TRIM
Consider, for example, the following JSON message:
...
- The value of the
src_ip_addr
field is in the192.168.0.0/24
subnet - The value of the
src_ip_addr
field is10.0.0.1
or10.0.0.2
- The field
is_local
exists
Threat Triage Configuration
Now that we have the ability to define conditions, for each sensor we need to associate these conditions to scores. Since this is a per-sensor configuration, this fits nicely within the sensor enrichment configuration held in zookeeper. This configuration fits well within the threatIntel
section of the configuration like so:
{
...
,"threatIntel" : {
...
, "triageConfig" : {
"riskLevelRules" : {
"condition1" : level1
, "condition2" : level2
...
}
,"aggregator" : "MAX"
}
}
}
riskLevelRules
correspond to the set of condition to numeric level mappings that define the threat triage for this particular sensor. aggregator
is an aggregation function that takes all non-zero scores representing the matching queries from riskLevelRules
and aggregates them into a single score. The current supported aggregation functions are
MAX
: The max of all of the associated values for matching queriesMIN
: The min of all of the associated values for matching queriesMEAN
: The mean of all of the associated values for matching queriesPOSITIVE_MEAN
: The mean of the positive associated values for the matching queries.
Example
So, where we left off in part 4 was a working threat intelligence enrichment. Now, let's see if we can triage those threats for the squid data flowing through. In particular,