"New to Chronicle" is a deep-dive series by Google Cloud Principal Security Strategist John Stoner which provides practical guidance for security teams that are either new to SIEM or replacing their SIEM with Chronicle. You can view the entire series here.

In this New to Chronicle blog, we’ve spent a good bit of time demonstrating numerous capabilities within Chronicle. This month, I thought it might be helpful to apply some of these concepts to questions I’ve heard from users. I’ve broken these questions into two installments. Here is the first.

How can I create an alert name that outputs the name of the rule triggered and a field value to identify the impacted entity?

Depending on how you work with alerts, you may want a value, like “Event Log Cleared - win-server.mydomain.com”, that contains both a brief rule description followed by a value that points to the impacted user or asset or other entity. While Chronicle outputs in its Alerts & IOC page a field with the rule name, Event Log Cleared, and a field with the match variables in it, hostname: win-server.mydomain.com, having a single field to output to a ticketing system or other external tool may require this.

Chronicle can generate this single alert field by using the strings.concat function along with an outcome variable. Below is a snippet of a community rule that triggers when a Windows event log is cleared. We aren’t going to focus on all of the different permutations for this event, but the code snippet below can be pasted into the rule editor and compiled. 

rule windows_event_log_cleared {
  meta:
  events:
    $process.metadata.event_type = "SYSTEM_AUDIT_LOG_WIPE"
    $process.metadata.vendor_name = "Microsoft"
    $process.principal.hostname = $hostname
    strings.concat("Event Log Cleared - ", $process.principal.hostname) = $alert
  match:
    $hostname over 5m
  outcome:
    $alert_name = array_distinct($alert)
  condition:
    $process
}

Within the event section, we have defined a placeholder variable called $alert. This placeholder will hold the value of the concatenation of the constant we’ve defined as Event Log Cleared - and the value in the field $process.principal.hostname. 

Once we have the placeholder field defined, we can apply it in the outcome section of the rule. In our example, we define the outcome variable as $alert_name and because our rule contains a match section, we need to prepend the aggregation function array_distinct to our placeholder variable $alert so that we get a single outcome variable, no matter how many events are part of the detection.

We can test our rule and when we add the alert_name field to our view, we can see that the hostname has been appended to the defined constant for the rule. That alert name can be viewed in the detection and used in systems that this detection is forwarded to. 

Should variables come before or after my criteria when I write a rule?

This question is frequently asked. If you are a frequent reader of this blog, you may notice that I tend to put my criteria in the events section followed by the placeholder variable. Don’t believe me? Scroll back up and see the previous example. However, just because I do it that way, doesn’t mean you have to. Here is that same rule, but this time, our placeholder variables are to the left of the equal sign. Notice in the top left corner of the rule editor, we have a green check which means that this rule successfully compiled, therefore it is syntactically correct.

It is worth pointing out that in the outcome section, the outcome variables must be on the left side of the equal sign, but in the event section, there is no similar constraint.

Can I adjust the risk level of a rule based on the time a detection occurred?

Great question. We discussed the use of time functions a few months ago and mentioned that we could trigger a rule based on the time the event occurred and how it could be used to ignore specific events that are admin tasks scheduled to execute at a specific time. The following example will adjust the risk score depending on the day of the week the underlying events occurred.

outcome:
  $risk_score = max(if(timestamp.get_day_of_week($process.metadata.event_timestamp.seconds) = 1, 30) +
if(timestamp.get_day_of_week($process.metadata.event_timestamp.seconds) > 1 and
timestamp.get_day_of_week($process.metadata.event_timestamp.seconds) < 7, 15) +
if(timestamp.get_day_of_week($process.metadata.event_timestamp.seconds) = 7, 30))

The function timestamp.get_day_of_week will convert a time field to an integer with 1 being Sunday and 7 being Saturday. With this function, we can build a risk score that states if the supporting events occur on Sunday or Saturday, assign a risk_score of 30 and if the event occurs on Monday through Friday, assign a risk_score of 15.

Here we can see that our risk_score has a value of 15 in our detection because June 23, 2023 was a Friday. Additional date functions are available, including timestamp.get_hour(), to increment risk for other suspicious timeframes you desire.

I hope these tips have been helpful, next time we will have a few more items from our user mailbag that I hope will help you with your rule writing!