Skip to main content

Hi #community,

Is there any option to throttle or prevent a rule with same criteria triggers for x period of time since it was last triggered. Let's say we keep receiving bruteforce for multiple user out of which one of them was targeted recently. My rule currently detects more than 3 authentication failure for one user within 10 min. The issue is every 10 min the rule will check for the activity and detects events matching criteria including the one that was already triggered.

I do not want to increase the frequency as I want the detection to be almost real time, and want to exclude the same criteria (same source and same user) for the next 1 hours since it was once triggered. This is to prevent analyst from being buried down in anlerts Below is the sample of the rules in-context.

 

 

rule google_login_bruteforce {

meta:
author = "Srijan Kafle"
description = "Detects more than 3 authentication failure in google accounts"
severity = "Medium"
created = "2023-12-13"
product = "google"
service = "login"
mitre = "Brute Force, t1110"

events:
$failure.metadata.log_type = "WORKSPACE_ACTIVITY" and $failure.metadata.product_event_type = "login_failure"
$failure.security_result.about.email = $user

match:
$user over 10m

outcome:
$risk_score = 3

condition:
#failure >= 3
}

 

 

  

There is no native suppression feature in Chronicle SIEM.  There is a roadmap item for 2024.


As to a workaround, I have helped customers and partners with a couple of options, but both do require some building work on your part:


1) Using Reference Lists with automation, i.e., a SOAR


https://medium.com/@thatsiemguy/automating-chronicle-siem-reference-list-using-chronicle-soar-78f2e77c47dd


2) Using Detection Loopback


I've yet to write this up, and this is also on the 2024 roadmap, but this involves taking Detections back into Chronicle SIEM as a custom log source, and rather you alert on repeated Detections (not alerts), e.g., in your case the failed auth attempt would be a Detection but not an alert, and then if you see X Detections for that rule and placeholder value (which you pass across as an $outcome variable) then you can alert.

Hi @cmmartin_google ,

I will have a look into the first alternative as that most matches my use cases. But how do I automatically remove the entry every 1 hour/1 day/7 days based on my retention. Is there any option for the TTL of the entry in reference list? 

Regards,
Srijan Kafle

Hi @cmmartin_google ,

Any update on the TTL of the reference list or other workaround?

Hi #community,

Has someone come across TTL fields for reference list items? 

Hello srijankafle,
I have the same problem about the lack of alert suppression/throttling feature in Chronicle SIEM. I'm not sure why this is yet to be implemented since this is a very common feature among the SIEM competitors. I think it is a much wanted feature across all Chronicle customers 🙂
Anyway, the workaround I use for the moment is to write a match section for every rule, based on the field I would use for alert throttling, over a period of 15 minutes. For example :

  match:
    $user_id over 15m

 This can reduce the volume of alerts in case of "malicious" event spikes. It induces an additional delay to the Time To Detection though.
Let me know if you could find a solution on your side, regards.

Hi @chrisd2 ,

Same here. Coming from the traditional SIEM and not seeing the feature in such big platform seems kind of off at the beginning. I am also using match to merge events together. Do you think this brings in TTD? I am not sure if it delays the detection though. 

From what I understand the delay is due to the rule run frequency, and as long as you have the match under 1h (I use 59m as a workaround) the rule frequency can be set to 10 minutes for single event rule.

I understand using reference list and using soar to add that match parameter (userid) and using rule to exclude that is a workaround as martin suggested above, but the limitation is the lack of TTL in the reference list (again another feature I miss from various SIEM I have used in the past)

Hope this is developed by Google as soon as possible. I have raised some feature request as well, if you are also able to do support ticket, please raise feature request on this.

Hi @cmmartin_google ,

Has there been any update on the throttle capability as mentioned for roadmap for 2024?

There is no native suppression feature in Chronicle SIEM.  There is a roadmap item for 2024.


As to a workaround, I have helped customers and partners with a couple of options, but both do require some building work on your part:


1) Using Reference Lists with automation, i.e., a SOAR


https://medium.com/@thatsiemguy/automating-chronicle-siem-reference-list-using-chronicle-soar-78f2e77c47dd


2) Using Detection Loopback


I've yet to write this up, and this is also on the 2024 roadmap, but this involves taking Detections back into Chronicle SIEM as a custom log source, and rather you alert on repeated Detections (not alerts), e.g., in your case the failed auth attempt would be a Detection but not an alert, and then if you see X Detections for that rule and placeholder value (which you pass across as an $outcome variable) then you can alert.


Hi Chris,

I noticed your mention of the "Detection Loopback" approach for Chronicle SIEM. Is this available yet? I’m planning to implement this for my internal tenant, and any additional clarity or guidance you could provide would be incredibly helpful.

Thanks in advance for your assistance!

Reply


Terms & ConditionsCookie settings
Privacy Policy Terms of Service Gen AI Policy Community Guidelines Cookie Settings

© 2025 Google. All rights reserved.