Monitoring for Unexpected Rule Changes in Google Security Operations (2 of 2)

[David-French]

Welcome to part two where we’re learning how to monitor for changes to rules in Google Security Operations (SecOps). In part one, I walked through how to ingest Google Cloud logs into Google SecOps and create a YARA-L rule that alerts when any rules are modified or deleted.

For the benefit of security operations teams or administrators that prefer to do this kind of monitoring outside of Google SecOps, this post demonstrates how to detect rule changes by using Google Cloud Monitoring. One possible reason for adopting this approach is to detect if the rule that we configured in part one is modified or disabled (i.e., the security team wouldn’t be alerted to unexpected changes to their detection content).

Detecting Rule Changes Using Google Cloud Monitoring

Alerting policies can be configured in Google Cloud Monitoring to notify you when specific conditions are found in Cloud Audit Logs. By running the query below in Logs Explorer and clicking the “Create alert” button, we can create a new alerting policy based on the query. This query was explained in part one and I’ve included some comments to explain its logic.

resource.type="audited_resource"
resource.labels.service="chronicle.googleapis.com"
protoPayload.methodName=(
  -- Attempts to create a rule
  "google.cloud.chronicle.v1alpha.RuleService.CreateRule" OR
  -- Attempts to create a new version of a rule
  "google.cloud.chronicle.v1alpha.RuleService.UpdateRule" OR
  -- Attempts to update the deployment state of a rule (enable, disable, archive, run frequency, etc)
  "google.cloud.chronicle.v1alpha.RuleService.UpdateRuleDeployment" OR
  -- Attempts to delete a rule
  "google.cloud.chronicle.v1alpha.RuleService.DeleteRule"
)
-- Match on successful rule modification or deletion events
protoPayload.authorizationInfo.granted="true"

Creating an alerting policy from Logs Explorer

The next step is to fill out the various fields for the logs-based alert policy including a name for the policy and brief documentation to explain its purpose for the benefit of anyone viewing the alerts it generates.

Configuring a logs-based alerting policy to alert on changes to rules in Google SecOps

To finish configuring the alerting policy, I set its notification frequency and select the channels where the notifications should be sent when it fires. Notifications can be sent to various channels including email, Google Chat, Slack, and webhooks.

Testing the Alerting Policy

After creating the new alerting policy in the Google Cloud console, I modified a YARA-L rule in Google SecOps and clicked Save.

Modifying a rule in Google SecOps’ rules editor

Within a few seconds of modifying the rule in Google SecOps, I received an email notifying me of this event. Clicking the link in the email takes us to the Google Cloud Console where we can review the event(s) that triggered the alerting policy.

Email notification after modifying a rule in Google SecOps

Filtering Out Expected Behavior

It’s highly unlikely that your security operations team wants to receive an alert every time a rule is modified in Google SecOps. If you’ve implemented a Detection-as-Code pipeline, you probably have a specific service/user account that deploys changes to your rules in Google SecOps. If your team should only be making changes to detection content via your Detection-as-Code workflow, you may want to receive a notification when changes are being made outside of that process.

In my pipeline, I have a specific service account that deploys changes to my rules in Google SecOps. I’ve updated the query that we created in Logs Explorer earlier to filter rule modification activity from the service account. This ensures that I’ll receive a notification if someone is modifying rules in Google SecOps and might be trying to circumvent the team’s process to test, review, and approve changes before they’re deployed.

Filtering rule modification activity for a specific service account

Restoring a Rule to a Previous Version

One of the neat features in Google SecOps’ rules editor is that the version history for rules is maintained. If your team detects an unexpected change to a rule in Google SecOps, it’s easy to revert the rule to a previous version. An example of this is shown in the image below.

Reviewing the version history for a rule in Google SecOps

Wrap Up

That brings us to the end of this series on how to monitor for unexpected changes to your rules in Google SecOps. In part one, we looked at how to implement this monitoring by creating a rule in Google SecOps. In today’s post, I walked through how to configure a Cloud Monitoring Alerting policy that detects rule changes and how to revert to a previous version of a rule in SecOps if needed.

Please feel free to reach out in the Google Cloud Security Community with any questions or content you’d like to see.