LinkedIn
Twitter
Today we are going to turn our attention toward building detections for risk analytics. Previously, we had built YARA-L rules that could be aggregated over time periods ranging from one minute to two days. However, there are use cases that require detections that span a longer period of time.
To address these use cases, Google SecOps has added functionality called metrics through its addition of Risk Analytics to the platform. Metrics provide a method to aggregate historical data that can then be applied in a YARA-L rule.
Metrics span different data sets including network, authentication and endpoint data. Google SecOps includes support for metrics that pertain to Authentication Attempts, DNS Bytes Outbound, DNS Queries, File Executions, and HTTP Queries, as well as Network Bytes. In this blog, we will focus on network bytes but in follow-on blogs, we will use other metric sets in our examples.
The Network Bytes metric is broken into three sub metrics; metrics.network_bytes_inbound, metrics.network_bytes_outbound, and metrics.network_bytes_total. The inbound metric is based on the field network.received_bytes containing values that are non-zero. The outbound metric is similar except it is bound by non-zero values in network.sent_bytes. Finally, the total metric creates a sum where the values for network.sent_bytes or network.received_bytes in the same event are not zero.
These high level metrics are just the starting point to slice and dice this data in a number of ways. The capability to refine the data as it pertains to a user or an asset, to calculate a first seen or event count metric as well as provide an average or a maximum value resides within the metric function. The metric function is always found within the outcome section of a YARA-L rule. Here is an example of the stand-alone function.
$max_bytes_window = max(metrics.network_bytes_outbound(
period:1d, window:30d,
metric:value_sum,
agg:max,
principal.asset.ip:$ip
))All metrics functions follow this same layout and in subsequent blogs, we will tackle additional variations of this. To the left of the equal sign is the outcome variable named $max_bytes_window. To the right of the equal sign is the aggregation function of max. It’s important to understand that this aggregation function exists in the rule because ALL multi-event rules have aggregate functions, like count, max, array and more associated with all outcome variables that contain UDM fields, so this is nothing new. The use of the metric starts within the parenthesis.
This example uses the network_bytes_outbound metric. Once we’ve defined which metric is being used, another parenthesis contains the options specific to our calculation. The first two options are related to time. In this metric, period:1d, window:30d means that the data is being bucketed on a daily basis across a window of 30 days. An additional option for metrics within the past day is available and is called with the following notation; period:1h, window:today. These hourly metrics require the use of daily metrics in the same rule.
After the time period and window is the metric. Our example has a metric of value_sum, which generates a sum of the bytes in the events within the period specified. It’s worth noting that value_sum is only used with metrics that contain bytes in them. Agg (short for aggregation) is next and contains max, that is the largest value for a period within the 30 day window.
Finally, the metric function is grouped by the values in principal.asset.ip as represented by the placeholder variable $ip. As we step back and look at rules more broadly, we will see this placeholder variable in the events section of the rule as well as in the outcome section. Depending on the metric, specific UDM fields are allowed to be grouped by so it’s always best to check the documentation.
With that, let’s build a simple rule that allows us to view the output of our metric function. The events section focuses our detection on network connection events that have a network.sent_bytes value greater than 0. We chose to put this in the criteria because we are using the outbound metric which is only gathering events with that same criteria for sent bytes. Finally, we limited our rule to a single principal.ip value for simplicity. A placeholder variable of $ip is defined here and will be used in the match variable section as we aggregate our detections over one day.
rule metric_examples_network {
meta:
author = "Google Cloud Security"
events:
$net.metadata.event_type = "NETWORK_CONNECTION"
$net.network.sent_bytes > 0
$net.principal.ip = $ip
$net.principal.ip = "10.128.0.21"
match:
$ip over 1d
outcome:
$max_byte_count_window = max(metrics.network_bytes_outbound(
period:1d, window:30d,
metric:value_sum,
agg:max,
principal.asset.ip: $ip
))
condition:
$net
}The outcome section calculates our metric as we’ve discussed, but this is also where our placeholder variable of $ip emerges and is used to group our metric data by that ip address, in this case the principal.asset.ip of 10.128.0.21. If we had an entire subnet range in our event section, then each calculation would be associated with each principal.asset.ip that was contained in the placeholder variable. Finally, our condition is the event variable. We aren’t doing more with our metric in this example, that’ll come later!
When we test our rule for the last seven days, we get a detection for our IP address for each day. Our outcome variable of max_byte_count_window is in the red box. This detection as currently written isn’t security relevant, but we now have our first metric created in a rule and the concepts we covered today are going be reinforced as we dig deeper into additional options that metrics provide!