Why cant we create if an logsource is not reporting as an alert ?

[rahul7514]

Hi All

We have done creating alerts using GCP with email notification .

But still can some one tell me the reasons why i cannot create an Yara L rule for host (asset.namespace) not reporting alert ? 

I have been asked this question many time and i have been just telling google suggests to use GCP monitoring based alerts for this. 

@jstoner / @David-French 

[raybrian]

You are right, using GCP monitoring-based alerts is generally the recommended approach for detecting when a host stops reporting. However, let's delve into the reasons behind this recommendation and why creating a Yara-L rule for this scenario can be problematic.

Challenges of Detecting Host Non-Reporting with Yara-L:

1. Absence of Data: The core issue is the absence of data. When a host stops reporting, there are no events to trigger a Yara-L rule. Yara-L rules rely on the presence of data to match conditions. The very nature of a host not reporting means there is a lack of events from that host, making it impossible for a Yara-L rule to fire.

2. Time Window Constraints: Yara-L rules operate within defined time windows (specified in the match section). To detect a non-reporting host, the time window would need to be continuously extended until the host reports again. This could lead to significant processing overhead and delays in detection, especially if the host remains offline for an extended period.

3. False Positives: Transient network issues, temporary outages, or scheduled maintenance activities can cause a host to stop reporting for legitimate reasons. A Yara-L rule might trigger false positives in such scenarios, generating unnecessary alerts.

4. State Management: Detecting a non-reporting host requires maintaining state information about the expected reporting frequency of each host. Yara-L rules are stateless, making it difficult to track the last reported time for each host and reliably determine when a host has stopped reporting beyond its expected interval.

Why GCP Monitoring Alerts are Better Suited:

• Active Monitoring: GCP Monitoring actively polls and checks the status of hosts, collecting metrics related to their availability, health, and performance. This proactive approach ensures that non-reporting hosts are detected promptly.

• Heartbeat Mechanisms: Monitoring systems often rely on heartbeat signals sent by hosts at regular intervals. If a host fails to send a heartbeat within the expected timeframe, an alert is triggered, indicating a potential issue.

• Customizable Thresholds: GCP Monitoring allows for customizable thresholds and alert conditions. You can define specific criteria for different types of hosts, adjusting the sensitivity of the alerts based on the criticality of the host and its expected reporting frequency.

• Integration with Alerting and Incident Management: GCP Monitoring integrates seamlessly with other GCP services like Cloud Logging, Error Reporting, and Pub/Sub, enabling automated alerting, incident creation, and escalation workflows.

In Conclusion:

While it's technically possible to attempt detecting non-reporting hosts with Yara-L using very long time windows and creative rule logic, it's not the ideal solution due to the inherent challenges mentioned above. GCP Monitoring, with its active monitoring capabilities, heartbeat mechanisms, customizable thresholds, and alerting integrations, is a much more effective and reliable approach for detecting and responding to host non-reporting scenarios.