Compare event to previous similar event - YARA-L rule

[Cyber_Chief1999]

Hi,

Does anyone have any experience with creating a YARA-L rule that looks for a particular event such as a vulnerability detected on a particular host but if that same vulnerability is detected in an event on the same host again within 24 hours, then to ignore and not generate an alert. So only just alert on unique events over a 24 hour period.

Thanks

[JeremyLand]

@Cyber_Chief1999 - Adding a 'match' section of your rule will give you this capability.

https://cloud.google.com/chronicle/docs/detection/yara-l-2-0-syntax#match_section_syntax

In the events section you'll need to assign variables for any of the fields you want match on ($cve_id and $hostname jump to mind but others may be better for your use case) then the declare the match and timeframe

  match:
    $hostname,$cve_id over 24h

This will ensure if multiple events with matching hostname and cve take place in 24 hours they will only trigger a single alert.

[Cyber_Chief1999]

Hi Jeremy Land.

Thanks for the feedback. Yes, i have tried with the match rule, however the caveat is the time window is limited to 48 hours and will amalgamate all detections within that period into a single alert. But anything beyond that is not possible, which is the limitation as you will get duplicate alerts potentially. What i want to do is ignore any matching detection over a longer period of time. But i guess thats not possible, given the 48h limitation.

Thanks

[JeremyLand]

@Cyber_Chief1999 Ok I think I have a better idea what you are looking for now.  

Your best option is probably to rely on the timestamp field that @jpetitg mentioned - asset.vulnerabilities.first_found and filter out anything that isn't new.  This does rely on your vuln scanner tracking that initial discovery and passing it in the event. Similar example here: https://cloud.google.com/chronicle/docs/detection/yara-l-2-0-syntax#example_1_13

If you aren't getting that first_found field you can get a similar result by setting a longer match window and adding a condition at the end of your rule to trigger if only 1 event exists in the match timeframe.

 condition:
  #e = 1

In the scenario with daily scans and a match window set greater than 24 hours any detection after the very first would contain more than 1 event and would not fire an alert.

The downsides to this method is that it will consume from your multi-event rule quota, and that it will trigger false alerts if you have a disruption in the scan source. You can partially mitigate false positives by setting the match window to the max 48 hours, which will give more leeway but if you had a scan fail one day and complete 5 minutes later than usual the next day you would end up with events 48:05 apart and trigger alerts for all the vulnerabilities on that system again.

[jpetitg]

Hi,

In term of vulnerability, what would be the use case to extend over a great period of time?

If the issue is having every day or 2 days an alert for this asset because vulnerability is not yet patched and your solution sends logs every day for every scan, maybe there is a field mentionning if it is a new vulnerability or an existing one (already scanned before). If it is the case maybe you want to use this field in your YARA-L rule.

Maybe you can take a look at the risk score and the entity graph if it can suit your need. With a first alert that will increase the risk score for this particular entity (hostname) and have in condition the use of the risk score to not trigger if it was already high from a previous alert.

However I would not recommend the latter as it can possibly blind you from potential true positive alerts if not well configured.