Google SecOps Silent Host Monitoring Is not working as Expected

Hi,
The issue comes from the fact that your silent threshold is 5 minutes, but the rule runs only every 1 hour with a 60-minute match window.

That means the rule may:

• trigger in a window where you still see some logs, and

• miss a later window where the host is actually silent.

For a 5-minute inactivity check, the run frequency should be 5–10 minutes, not 1 hour. Once you lower the run frequency, the alert timing should match the real log gaps much better.

There was updated guidance on this feature recently released:

https://cloud.google.com/chronicle/docs/ingestion/silent-host-monitoring

1.  Introduction of a Latency Buffer: 

The documentation for the "Detect silent hosts by hostname" example rule now explicitly states that a 25-minute (1,500 seconds) buffer has been added. This buffer accounts for potential data indexing and query latency, ensuring that a host is deemed "truly silent" for more than 20 minutes before an alert is considered.

2.  Updated Detection Rule Logic (`shm_using_hostname`):
    *   The `outcome` section of the rule has been refined with new variables (`$current_time`, `$max_time`, `$max_time_date`, `$diff_seconds`) for more precise timestamp handling and calculation of the time difference.
    *   The `condition` for triggering an alert has been changed. Previously, it alerted if no events were received for more than 10 minutes (`$max_diff > 600`). The new condition now checks if the host has been silent for **more than 45 minutes** (`$diff_seconds > 2700`), which directly implements the 20-minute silence period plus the new 25-minute latency buffer.

Hi ​@cmmartin_google 

When we tried copying the YARA-L from the above-mentioned document, it showed an error.
 

Oh dear.  Thank you for bringing that up, and I’ll raise that back to folks to fix the example, but it should have been something like:

rule shm_using_hostname {
 meta:

 events:
   $event.metadata.event_timestamp.seconds > timestamp.current_seconds() - 1200
   // $identifier_hash = hash.sha256(strings.concat($event.principal.ip[0], $event.principal.hostname, $event.principal.mac[0]))
   $silent_hostname = $event.principal.hostname
 match:
   $silent_hostname over 10m
 outcome:
  $current_time = timestamp.current_seconds()
  $max_time = max($event.metadata.event_timestamp.seconds)
  $max_time_date = timestamp.get_timestamp($max_time)
  $diff_seconds = $current_time - $max_time
 condition:
  $event and $diff_seconds > 2700
}

Hi ​@cmmartin_google ,

Should I use the same logic for detecting when logs are not received for 24 hours or every 2 hours? Will it work.

And will it work for API and feeds ingestion as well if no logs are coming from the source.

Hi ​@cmmartin_google ,

Could you please share an update on this.

Thanks

I didn’t write these rules and am not immediately familiar with them I'm afraid, so I can’t provide a meaningful comment on them.  An observation, I would think the line 5 item would need to be greater than line 16 as otherwise I don’t see how the rule could fire, e.g., your lookback must be greater than the condition value.  For longer periods, I guess you would just need adjust those accordingly.

A YL2 rule would work irrespective of the ingestion mechanism.  

Hi ​@cmmartin_google ,

Really appreciate your response. We already tried (the line 5 item would need to be greater than line 16), but it didn’t work.

Kindly keep us informed of any future feature enhancements or rule updates.

Thanks