Skip to main content
Question

Audit logs from SOAR

  • April 1, 2026
  • 1 reply
  • 10 views

keso
Forum|alt.badge.img+7

Being playbooks so critical, there should be a way to alert when they are created/updated/deleted (CUD). There was a way, at least of checking Create and Update by creating an alert in GCP and searching for 

 

protoPayload.methodName =~ "malachite.*?(?:Create|Update)Rule"

 

But that’s not the case anymore. The log was simple removed. The answer of a support case was -Sorry, that’s not supported, here is a feature request-. The logs do exist in SecOps, but there is no way to run a playbook on them or send alerts when they have been CUD. Again, for being so critical and powerful, in the sense that playbooks have the power to do things, they should be a way to know when they have been CUD. 

 

More than one year ago I highlighted the same situation:

 

Asking to see if I might be missing something. Is there a way to alert when a playbook was CUD? 

1 reply

dnehoda
Staff
Forum|alt.badge.img+16
  • Staff
  • April 1, 2026

The move from the legacy Malachite logs (which were often tied to the underlying infrastructure) to the unified Google SecOps model has indeed shifted where these events land. As of early 2026, here is the current state of auditing Playbook CUD (Create, Update, Delete) events and how you can work around the "unsupported" gap.

1. The "Vanishing" Log Explanation

The protoPayload.methodName =~ "malachite.*" logs were part of the legacy backend. As Google has unified SIEM and SOAR into a single "SecOps" interface, many of those internal API calls have been abstracted. Support is technically correct that there isn't a direct 1:1 replacement in the standard cloudaudit.googleapis.com/activity log for every SOAR-specific UI action yet.

2. Where the Logs Live Now (The "Namespace" Shift)

While Admin Activity logs for SIEM (Rules, Feeds) are now standard under the chronicle.googleapis.com service name, SOAR (Playbook) audit logs are often routed through a different path.

Check your Google Cloud Logging for this specific resource type:

  • Resource Type: generic_node (or sometimes audited_resource)

  • Namespace: chronicle-soar

  • Log Name: Many of these are now written as textPayload rather than protoPayload because the SOAR engine still operates on a slightly different logging schema than the core GCP services.

Try this query in the GCP Logs Explorer:

SQL

 

resource.labels.namespace_name="chronicle-soar"
AND textPayload =~ "(Create|Update|Delete) playbook"

3. The "Detection Rule" Workaround

If the logs exist in SecOps (as you mentioned) but you can't run a Playbook on them because they aren't "Alerts," you can bridge the gap using a YARA-L Detection Rule.

Google SecOps ingests its own audit logs into the metadata.vendor_name = "Google Cloud Platform" or metadata.product_name = "Google Cloud Audit Logs" category.

  1. Create a YARA-L rule that searches for these specific CUD events in the UDM.

  2. Set the rule to Alert.

  3. Once the rule fires an alert, that alert can trigger a Playbook (e.g., a "Playbook Change Notification" playbook) that sends a Slack/Email/SOC ticket.