In YARA-L every field needs to be mapped. For a rule that only is looking at a single event, this may seem like overkill but as we get into rules that contain multiple events (or entities), we need a way to identify that event1 pertains to process launch events and event2 is network http events and entity1 is a safebrowsing entity and so forth.
The $event or $entity in the example above are referred to as event variables. These are seen all over rules and are sometimes shortened to $e and $u in the documentation. I personally prefer using something more descriptive, ie $process or $network as these event variables can also be seen in the detection and make it simpler to read and see which events pertain to the process portion of a detect versus the network portion, for example.
Here is a short video I put together on YARA-L variables as well:
https://www.googlecloudcommunity.com/gc/Chronicle-Best-Practices/Getting-to-know-Chronicle-SIEM-YARA-L-rule-variables/ta-p/635481
Hope this helps!
In YARA-L every field needs to be mapped. For a rule that only is looking at a single event, this may seem like overkill but as we get into rules that contain multiple events (or entities), we need a way to identify that event1 pertains to process launch events and event2 is network http events and entity1 is a safebrowsing entity and so forth.
The $event or $entity in the example above are referred to as event variables. These are seen all over rules and are sometimes shortened to $e and $u in the documentation. I personally prefer using something more descriptive, ie $process or $network as these event variables can also be seen in the detection and make it simpler to read and see which events pertain to the process portion of a detect versus the network portion, for example.
Here is a short video I put together on YARA-L variables as well:
https://www.googlecloudcommunity.com/gc/Chronicle-Best-Practices/Getting-to-know-Chronicle-SIEM-YARA-L-rule-variables/ta-p/635481
Hope this helps!
Thank you for pointing me to that excellent post.
A quick follow up. What does the following mean:
"event variables are used to organize like criteria together"
What does it mean to say: organize like criteria together
Is there a different way to say this.
In the example below, in a single same data set, Microsoft Windows Event Logs. However, there are 2 types of events I am looking for, failed logins and successful logins. The failed logins have their own set of criteria, that is, user_login event type, security_result.action of block and product_event_type of 4625. The success criteria has some similar values and some different values.
However, I am left with a bucket of events that match the fail criteria and a different bucket of events that match the success criteria. By using the event variables of $fail and $success, I can characterize each and then use placeholder variables like the ones seen in line 4 and 5 and 13 and 14 to join. I can also use statements like the one in line 9 to say that the failed events need to occur before the successful events by comparing the timestamps of the success and failed events.
Hope that helps
events:
$fail.metadata.event_type = "USER_LOGIN"
$fail.metadata.vendor_name = "Microsoft"
$fail.principal.hostname = $hostname
$fail.target.user.userid = $user
$fail.security_result.action = "BLOCK"
$fail.metadata.product_event_type = "4625"
$fail.metadata.event_timestamp.seconds < $success.metadata.event_timestamp.seconds
$success.metadata.event_type = "USER_LOGIN"
$success.metadata.vendor_name = "Microsoft"
$success.target.user.userid = $user
$success.principal.hostname = $hostname
$success.security_result.action = "ALLOW"
$success.metadata.product_event_type = "4624"
Thank you. The "Getting to Know Chronicle" series is amazing!
