"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 Part 1 of Building Rules with Your Own Threat Intel, we introduced how to build a rule using domain indicators that are stored within the entity graph. Today, we will extend our domain rule further by adding an outcome section to the existing rule demonstrating how to take contextual information from an indicator and add it to a detection. Additionally, we will modify our rule template to adapt it to IP address and file hash indicators.

In YARA-L, the outcome section of the rule can be used to provide additional context to the detection that is being triggered. Previously, we could define ten outcome variables, but this has recently been expanded to 20 outcome variables in a rule.

Outcome variables contain data that can easily be integrated into ticketing systems or a SOAR. In fact, you will see even more cool stuff leveraging the outcome section in Chronicle later this year, so make sure you are adding outcomes to your rules! How’s that for foreshadowing?

Our previous example leveraged a detection that correlated network DNS events with domains in our MISP instance. We can view the underlying events and entities (domain indicators). Here is the indicator we saw previously and its associated fields. 

We could drill into the entity to see this supporting data, but making this information available to the analyst or third party systems as part of the detection is more efficient. This is where the outcome section comes into play. As we look through the entity data, we can see some interesting information in fields like metadata.threat.description section, metadata.threat_feed_name and metadata.threat.severity_details.

Outputting the metadata.threat_feed_name to its own outcome variable is straightforward. Use the value in metadata.threat.severity_details to calculate a risk score depending upon the severity. While the metadata.threat.description has a lot of great information in it, separating some details from that field into separate outcome fields makes it easier to consume.

rule ioc_C2 {
 meta:
   author = "Chronicle"
   description = "Detect DNS events that indicate communication toward a C2 domain" 
 events:
   $dns.metadata.event_type = "NETWORK_DNS"
   $dns.network.dns.questions.name != ""
   $dns.network.dns.questions.name = $dnsQuery
   $ioc.graph.metadata.product_name = "MISP"
   $ioc.graph.metadata.entity_type = "DOMAIN_NAME"
   $ioc.graph.metadata.source_type = "ENTITY_CONTEXT"
   $ioc.graph.metadata.threat.summary = "C2 domains"
   re.capture($ioc.graph.metadata.threat.description, "additional info: (.*)") = $addInfo
   re.capture($ioc.graph.metadata.threat.description, "(.*),tlp") = $mispGalaxy
   re.capture($ioc.graph.metadata.threat.description, "(tlp.*).-") = $mispTLP
   $ioc.graph.entity.hostname = $dnsQuery 
 match:
   $dnsQuery over 5m
 outcome:
   $risk_score = max(if($ioc.graph.metadata.threat.severity_details = "High", 80, 0) + if($ioc.graph.metadata.threat.severity_details = "Medium", 50, 0) + if($ioc.graph.metadata.threat.severity_details = "Low", 30, 0))
   $threat_description = array_distinct($mispGalaxy)
   $threat_tlp = array_distinct($mispTLP)
   $threat_name = array_distinct($ioc.graph.metadata.threat.threat_feed_name)
   $threat_family = array_distinct($addInfo)
 condition:
   $dns and $ioc
}

The items in bold above are the modifications made to the original rule. Let’s start with the simplest outcome variable, $threat_name. In a multi-event rule, all outcome variables will require an aggregate function before the field, so we are going to use array_distinct to return the metadata.threat.threat_feed_name value in the detection one time, regardless of how many events are part of this detection.

Using the if statement, we assign a numeric value based on the value in metadata.threat.severity_details to create the $risk_score. Notice in our rule we are adding multiple if statements together. Because we have identified MISP Galaxy data, Traffic Light Protocol (TLP) and additional information in the metadata.threat.description field, we can use the re.capture function to extract specific information from this entity field, write each extraction to their own placeholder variable and then output them using the array_distinct aggregation into their own outcome variables. Those outcome variables are $threat_description, $threat_tlp and $threat_family.

When we test our rule, our detection looks much like it did previously, except the outcome fields are broken out to present the risk score, MISP Galaxy data, information around the APT group, the threat name, and the TLP value without having to expand our entity or reading through a bunch of concatenated values stuffed into a single field.

We spent a bit of time covering how a rule is built that correlates a domain indicator with our events. You might be thinking, what might those rules for file hashes or IP addresses look like? The recipe we follow is pretty much the same. Here is an example that correlates the target IP address field with the IP addresses from MISP. The fields in bold are the ones that changed from our domain rule.

rule ioc_ip_target {
meta:
 author = "Chronicle"
 description = "Detect network events that indicate communication from a watchlisted IP address"
events:
 $network.metadata.event_type = "NETWORK_CONNECTION"
 $network.target.ip = $ip
 $ioc.graph.metadata.product_name = "MISP"
 $ioc.graph.metadata.entity_type = "IP_ADDRESS"
 $ioc.graph.metadata.source_type = "ENTITY_CONTEXT"
 $ioc.graph.entity.ip = $ip
match:
 $ip over 5m
condition:
 $network and $ioc
}

Our UDM event type and join field will change for obvious reasons. Within the entity graph, we specify IP_ADDRESS in the metadata.entity_type field and our join will change to accommodate the location of the IP address in the entity graph which is different from the domain. That’s it!

Similarly for a file hash, our UDM event type and join field are different. Because some process launch and file creation events don’t have hashes, we added the criteria that the SHA256 hash must exist. Within the entity graph, we specify FILE in the metadata.entity_type field and our join changes to align with the field the hash is stored in.

rule ioc_sha256_hash {
 meta:
  author = "Chronicle"
 description = "Detect file/process events that indicate watchlisted hashes  are on a system"
 events:
  $process.metadata.event_type = "PROCESS_LAUNCH" or $process.metadata.event_type ="FILE_CREATION"
  $process.target.process.file.sha256 != ""
  $process.target.process.file.sha256 = $sha256
  $ioc.graph.metadata.product_name = "MISP"
  $ioc.graph.metadata.entity_type = "FILE"
  $ioc.graph.metadata.source_type = "ENTITY_CONTEXT"
  $ioc.graph.entity.file.sha256 = $sha256
match:
  $sha256 over 5m
 condition:
  $process and $ioc
}

As you can see from the three examples, the same template can be used and customized to meet your particular needs. If you need to narrow your UDM events, simply add additional criteria in the event section. If you want to focus your threat intel to a specific adversary or TTP, simply adjust the $ioc variable criteria to use additional context around the indicator from the entity graph.

I hope this provides you a good start point to build rules against your threat intel in Chronicle. In future blogs we will dig further into the entity graph and unlock more capabilities including how to use Google Cloud Threat Intelligence (GCTI) in rules.