Hi Folks,
When connecting Wiz Automation Rules or Wiz Workflows to Google SecOps SIEM, I have seen several teams select the OCSF output format assuming an open schema will give them broader compatibility, only to find later that the Wiz Alerts curated rule set in Google SecOps generates zero detections. When you configure a Wiz Automation Rule or Workflow to forward Issues or Detections, choosing the Native data format sends events to the WIZ_IO log type, whereas choosing OCSF sends events to the OCSF log type (https://docs.cloud.google.com/chronicle/docs/ingestion/default-parsers/wiz-io). Switching to the Native data format (while keeping any existing OCSF rule active in parallel during cutover until you confirm WIZ_IO events are normalizing in UDM Search) opens up built in detection coverage for Wiz Detections and cleaner UDM field mappings.
Comparing how both formats normalize highlights why this happens. In my experience, when Wiz sends a new detection finding in OCSF format, the event lands under metadata.log_type = "OCSF" with metadata.product_event_type formatted from the OCSF activity ID and name ("1 - Create" for a new finding). While Wiz audit logs map action to metadata.product_event_type, when Wiz forwards a threat detection or cloud issue in the Native data format, WIZ_IO sets metadata.log_type = "WIZ_IO", populates metadata.vendor_name = "WIZ_IO", and maps trigger.source into metadata.product_event_type as "DETECTIONS" for detections and either "ISSUE" (from Wiz Automation Rules) or "RISK_ISSUES" (from Wiz Workflows, where creating a separate workflow per stream keeps each trigger template aligned with its source). You can verify how Curated Detections evaluate these fields by opening Content Hub in your console and checking the Rule Definition tab on the Wiz Alerts rule set (https://docs.cloud.google.com/chronicle/docs/secops/content_hub). Because the Wiz Alerts passthrough rules filter specifically for WIZ_IO Detections (with Critical and High rules in Precise and Medium through Informational rules in Broad), OCSF events never match those rules, and Wiz Issues forwarded in the Native data format land in SIEM for search and custom YARA L rules without firing Wiz Alerts.
Two testing and filtering quirks are also worth watching for in Wiz. Clicking the manual test button inside Wiz omits trigger.source from the sample webhook payload and WIZ_IO anchors metadata.event_timestamp to issue.created or detection.timeframe.start, so metadata.product_event_type stays empty on manual test sends and older sample findings appear under their original creation timestamp in UDM Search until a live Detection or Issue fires. Additionally, if your Wiz rule forwards resolved issue notifications alongside newly created ones, WIZ_IO still populates metadata.product_event_type and security_result.severity while setting security_result.action_details to "RESOLVED" rather than "OPEN". If you enable the Wiz Alerts curated rule set for threat detections and also want alerts on open Critical Wiz posture issues (and if your rule forwards issue updates as well, you can add a match window on metadata.product_log_id to deduplicate repeats), you can pair it with a custom YARA L rule targeting open "ISSUE" and "RISK_ISSUES" events:
rule wiz_native_critical_cloud_issue {
meta:
author = "SecOps Team"
description = "Surfaces open critical Wiz posture issues that are not covered by the Wiz Alerts passthrough rule set"
severity = "High"
events:
$w.metadata.log_type = "WIZ_IO"
($w.metadata.product_event_type = "ISSUE" or $w.metadata.product_event_type = "RISK_ISSUES")
$w.security_result.severity = "CRITICAL"
$w.security_result.action_details = "OPEN"
condition:
$w
}
One security consideration during setup is that although the Google SecOps parser guide still shows uploading a static service account JSON key with Chronicle API Editor (roles/chronicle.editor), the Google SecOps integration in Wiz also offers a keyless Wiz managed service account option that authenticates to the Chronicle API through Google Cloud IAM, so selecting that keyless Wiz managed identity on your Google SecOps project and granting a custom IAM role with the required ingestion permissions such as chronicle.logs.import (https://docs.cloud.google.com/chronicle/docs/reference/ingestion-methods) alongside any forwarder permissions Wiz requests rather than broad roles/chronicle.editor (or isolating and rotating keys on a dedicated service account if your organization requires customer managed credentials) avoids static JSON keys and limits exposure. Please keep in mind that this is a sample rule provided as an example that we will not be supporting or maintaining, so your team will want to test and maintain it for your environment.
