Getting to know Chronicle SIEM: YARA-L basics

YARA-L is a language used to create rules for searching through your enterprise log data (hence the “L”) as it is ingested into Chronicle. The YARA-L syntax is derived from the YARA language developed by VirusTotal.

The language works in conjunction with the Chronicle Detection Engine and enables you to detect threats in both historical and real-time events across large volumes of data.

In this article, we’ll focus on how YARA-L detection rules are constructed.

Follow along in the video below.

Detection engineers need a method to build rules that will alert them when suspicious or malicious behavior is taking place. 

Chronicle uses YARA-L to build these rules, leveraging the unified data model (UDM) - the schema that Chronicle stores event data in. 

Detection rule construction

All rules contain three required sections: meta, events, and condition

jstoner_0-1695074614098.pngThere are also optional sections that can provide you more benefits, including match, outcome, and options

Example rule

Follow along in the video starting at 1:04 to see an example rule in action.

The meta section describes the rule. While users often keep this section brief, adding values like author, severity, description, and priority can be surfaced when reviewing the rule and used in alerts, which can provide valuable context. Based on our example, we can see that this rule is for Windows events, addresses a MITRE ATT&CK technique of OS credential dumping, and uses data sets like Microsoft Sysmon and Microsoft Windows events. 

The events section contains fields and values of interest that we want to observe. Functions, joins, and other comparisons can occur here as well. This is similar to a WHERE clause in a SQL statement. For this rule, we’re looking for the value, “PROCESS_LAUNCH” in our metadata.event_type field and the string, “mimikatz” in the target.process.command_line field. 

The last mandatory section includes event variables that are needed to be met for the rule to trigger. In our example, there’s only one condition, so there’s only one variable, which is part of the $process variable we used in events. 

We have two optional sections in this rule. Match aggregates values over a time window and will be used extensively with rules that rely on more than one event to trigger. They’re aggregated over a time window that the rule writer defines.

Finally, we have the outcome section. This section provides the ability to add additional context and scoring to a triggered rule. These values can be leveraged within Chronicle for dashboarding and alerting, as well as into a SOAR or ticketing system.

Additional resources

Contributors
Version history
Last update:
‎09-18-2023 03:06 PM
Updated by: