Google Chronicle SIEM: Writing YARA-L 2.0 Detection Rules and UDM Queries
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
Google Chronicle SIEM requires a different mental model than Splunk, Sentinel, or QRadar. Chronicle is built around normalized events (UDM) and a detection language (YARA-L 2.0) designed for multi-event correlation rather than ad-hoc search. The fixed-cost pricing model and petabyte-scale infrastructure mean data ingestion economics work differently -- you can ingest everything and write retroactive detections against a year of history without per-query costs. This guide covers the practitioner fundamentals: navigating UDM field structure for detection rule writing, YARA-L 2.0 rule syntax for single-event and multi-event patterns, retrohunting for threat intelligence operationalization, reference lists for high-volume IOC matching, Chronicle forwarder deployment for log ingestion, and SOAR integration for alert response automation.
Understand UDM Event Structure Before Writing Rules
YARA-L rules reference UDM fields, not raw log fields. Understanding how Chronicle maps log source fields to the UDM schema is prerequisite to writing accurate detection rules.
Navigate the UDM field hierarchy
UDM events have a top-level structure: `metadata` (event type, ingestion timestamp, log source), `principal` (the entity initiating the action -- user, process, or IP address), `target` (the entity receiving the action -- server, file, domain), `network` (network-level fields including DNS, HTTP, TLS), `security_result` (action outcome, verdict, threat category), and `about` (additional entities involved). For a firewall block event: principal.ip is the source IP, target.ip is the destination, target.port is the destination port, security_result.action is BLOCK. Always verify field mappings using Chronicle's Search UI with raw UDM event JSON before writing a rule.
Use the Chronicle Search UI for field discovery
In Chronicle Search, run a UDM query for a log source you are building a detection for: `metadata.log_type = 'WINDOWS_SYSMON' metadata.event_type = 'PROCESS_LAUNCH'`. Inspect the raw UDM JSON of a matching event to identify the actual field names and values. Common detection fields: `principal.process.file.full_path` for the parent process, `target.process.command_line` for the child process command line, `principal.user.userid` for the user context, and `principal.hostname` for the source host. Field names in YARA-L must exactly match the UDM field names including case.
Understand event_type values for your log sources
UDM `metadata.event_type` is the primary event classification. Key event types: `NETWORK_CONNECTION` (firewall, flow logs), `USER_LOGIN` (authentication events), `PROCESS_LAUNCH` (endpoint detection), `NETWORK_DNS` (DNS query events), `FILE_CREATION` / `FILE_DELETION` (file system activity), `STATUS_UPDATE` (endpoint status, config changes). Filtering by event_type in the `events` section of a YARA-L rule narrows evaluation to only relevant log sources and reduces false positives from events that share field names but have different semantic meanings across event types.
Use UDM Search for interactive threat hunting before rule creation
Before formalizing a detection as a YARA-L rule, validate the query logic in Chronicle Search: `metadata.event_type = 'NETWORK_DNS' target.hostname = /.*pastebin.com$/ principal.asset.hostname != /.*/ `. This finds DNS lookups to pastebin.com from assets without a known hostname -- a pattern used by malware for C2 staging. Validate the query returns expected results against real data, check the false-positive rate, then convert to a YARA-L rule with the validated field names and values.
Write YARA-L 2.0 Detection Rules
YARA-L 2.0 rules are evaluated continuously against incoming events. Single-event rules match individual events; multi-event rules correlate sequences of events within a time window.
Structure a complete YARA-L 2.0 rule
A well-structured Chronicle rule: `rule detect_lateral_movement_rdp { meta: author = 'security-team' severity = 'HIGH' description = 'Detects RDP connections from non-standard internal hosts' mitre_attack_technique = 'T1021.001' events: $e.metadata.event_type = 'NETWORK_CONNECTION' $e.target.port = 3389 $e.network.ip_protocol = 'TCP' $e.principal.ip != /^10\.0\.1\./ $e.security_result.action = 'ALLOW' condition: $e }`. The meta section is required for Chronicle's rule management and MITRE mapping. The events section binds UDM fields to the event variable `$e`. The condition section triggers the alert.
Write multi-event rules with match windows
Multi-event rules correlate multiple event variables over a time window. For detecting impossible travel (logins from geographically distant IPs within 30 minutes): `rule impossible_travel { events: $e1.metadata.event_type = 'USER_LOGIN' $e1.security_result.action = 'ALLOW' $e1.principal.user.userid = $uid $e1.principal.ip_geo_artifact.location.country_or_region = $country1 $e2.metadata.event_type = 'USER_LOGIN' $e2.security_result.action = 'ALLOW' $e2.principal.user.userid = $uid $e2.principal.ip_geo_artifact.location.country_or_region != $country1 match: $uid over 30m condition: $e1 and $e2 }`. The `match: $uid over 30m` groups both events by user ID within a 30-minute window.
Use outcome variables for enriched alert context
The `outcome` section assigns variable values to alert fields for richer SOAR context: `outcome: $risk_score = 80 $src_hostname = $e.principal.hostname $dest_ip = $e.target.ip $alert_summary = strings.concat('Suspicious RDP from: ', $e.principal.ip)`. Outcome variables appear in the Chronicle alert JSON sent to SOAR, providing analysts with pre-computed context rather than requiring SOAR playbooks to re-query Chronicle for basic event details. Use outcome variables for any field that will be needed in alert triage or ticket creation.
Test rules with unit test cases before deployment
Chronicle's rule editor supports YARA-L unit tests: add a `test` section to the rule with sample UDM events that should trigger (positive cases) and events that should not trigger (negative cases). Run the test in the editor before deploying. A detection rule without test cases drifts as UDM field names change across parser updates. Maintain test cases in a git repository alongside rule files -- Chronicle supports rule export and import via the Rules API for version-controlled detection-as-code workflows.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Operationalize Threat Intelligence with Reference Lists and Retrohunting
Reference lists and retrohunting are Chronicle's most powerful threat intelligence operationalization capabilities. They enable IOC-based detection at scale and historical coverage for newly received intelligence.
Create and maintain reference lists for IOC feeds
Create dedicated reference lists for each IOC type: one for malicious IP addresses, one for malicious domains, one for file hashes. Populate via the Chronicle UI or API: `POST /v2/lists/<listname>` with a newline-delimited payload. Automate list updates from threat intelligence platforms (MISP, ThreatConnect, Google Threat Intelligence): a daily cron job that fetches new IOCs and POSTs to the Chronicle list API. YARA-L rules referencing these lists automatically benefit from updates without rule redeployment.
Write reference list detection rules
Reference list rules detect IOC matches across all ingested log sources: `rule c2_ip_match { meta: events: $e.principal.ip = $src or $e.target.ip = $dst $src in %threat_intel_ips or $dst in %threat_intel_ips condition: $e }`. This flags any event where either the source or destination IP matches your malicious IP reference list. The same pattern works for domain lists in DNS events (`$e.network.dns.questions.name in %malicious_domains`) and file hash lists in endpoint events (`$e.target.file.sha256 in %malicious_hashes`).
Execute retrohunts for newly received threat intelligence
When receiving new threat intelligence (a CISA advisory with a list of IOCs, a vendor report with C2 infrastructure), immediately: (1) add the IOCs to the relevant Chronicle reference list, (2) create a targeted YARA-L rule if the TTP requires event logic beyond IOC matching, (3) run a retrohunt on the last 12 months to check historical exposure. Retrohunt results indicate whether the IOC appeared before the intelligence was received -- a retrohunt hit suggests compromise predating detection, requiring incident response investigation of the affected assets.
Integrate Chronicle with SOAR for Alert Response Automation
Chronicle SOAR (formerly Siemplify) processes Chronicle detection alerts through automated playbooks. Connecting detections to response workflows is what converts Chronicle from a detection platform to a response platform.
Configure Chronicle detection-to-SOAR alert routing
In Chronicle Rules, set the alert severity and confidence for each rule. Rules with severity HIGH or CRITICAL automatically route to SOAR as cases. In Chronicle SOAR, create case assignment rules that route based on rule name prefix or MITRE technique ID: rules matching T1078 (Valid Accounts) route to the Identity Investigation playbook, rules matching T1190 (Exploit Public-Facing Application) route to the Web Attack playbook. Consistent rule naming conventions (prefix by MITRE tactic) make SOAR routing logic maintainable as the rule library grows.
Build SOAR playbooks that query Chronicle for context enrichment
Chronicle SOAR includes a Chronicle integration that lets playbooks query the SIEM for additional context. When a USER_LOGIN alert fires, the playbook can: (1) query Chronicle for the user's login history over the last 30 days using the Search API, (2) query Chronicle for other alerts involving the same user in the last 7 days, (3) query the assets API for the host's vulnerability scan status, (4) compile this context into a SOAR case summary. This enrichment happens in seconds and gives analysts pre-populated context before they begin triage.
The bottom line
Chronicle SIEM's value over traditional SIEMs is the combination of normalized UDM (write one rule, detect across all log sources), YARA-L multi-event correlation (brute force, lateral movement, and impossible travel patterns in a single rule), and retrohunting (apply new threat intelligence to a year of history without re-ingestion). The investment is in detection engineering: well-written YARA-L rules with proper UDM field references, test cases, and reference list integration produce a detection library that scales as data volumes grow without proportional rule maintenance cost. Start with Google's Curated Detections catalog as a baseline, then layer organization-specific rules using YARA-L patterns validated against your UDM data.
Frequently asked questions
What is UDM and how does it differ from raw log ingestion?
The Unified Data Model (UDM) is Chronicle's normalized event schema. When a raw log (Palo Alto firewall syslog, Windows Event Log, Okta authentication log) is ingested by Chronicle, a parser maps the log's native fields to UDM standard fields: source IP becomes `principal.ip`, destination port becomes `target.port`, username becomes `principal.user.userid`. A YARA-L detection rule referencing `principal.ip` matches events from any log source -- you write one rule instead of separate rules for each log format. Raw log data is also retained and searchable, but UDM normalization enables cross-source correlation.
What is the basic structure of a YARA-L 2.0 rule?
A YARA-L 2.0 rule has four sections: `meta` (rule metadata: author, severity, description, MITRE ATT&CK technique IDs), `events` (variable declarations binding UDM event fields to rule variables), `match` (optional -- groups events by entity over a time window for multi-event rules), and `condition` (boolean expression that triggers an alert when true). A minimal single-event rule: `rule detect_rdp_external { meta: events: $e.metadata.event_type = 'NETWORK_CONNECTION' $e.target.port = 3389 $e.principal.ip_geo_artifact.location.country_or_region != 'US' condition: $e }`.
How do you write a multi-event detection rule in YARA-L 2.0?
Multi-event rules use the `match` section to correlate multiple events over a time window. To detect a brute-force login pattern (5 failed logins within 10 minutes from the same IP): `rule brute_force_auth { events: $fail.metadata.event_type = 'USER_LOGIN' $fail.security_result.action = 'BLOCK' $fail.principal.ip = $src_ip match: $src_ip over 10m condition: #fail >= 5 }`. The `#fail` syntax counts the number of events matching the `$fail` variable. The `match` section groups events by the `$src_ip` variable and the `10m` window. Chronicle evaluates this across all ingested events continuously.
What is retrohunting in Chronicle and when should you use it?
Retrohunting applies a YARA-L rule to Chronicle's indexed historical data (up to 12 months) rather than only to live incoming events. Use retrohunting when: receiving a new threat intelligence IOC (malicious IP, domain, hash) and needing to check if it has appeared in the last year, releasing a new detection rule and wanting to verify it would have fired on past events, or investigating a newly discovered malware family and checking for historical indicators. To retrohunt: in Chronicle Rules, create or open a rule, click Run Retrohunt, select the date range. Retrohunt results appear in a separate view from live detections and do not trigger SOAR playbooks by default.
How do reference lists work in Chronicle for IOC matching?
Reference lists are named collections of strings (IPs, domains, hashes, usernames) that can be referenced in YARA-L rules for bulk IOC matching. Create a reference list in Chronicle: Settings > Reference Lists, upload a newline-delimited list of IOC values. Reference in a rule: `rule c2_domain_match { events: $e.network.dns.questions.name = /.*/ $e.network.dns.questions.name in %malicious_domains match: $e condition: $e }`. The `%malicious_domains` references the list by name. Lists update independently of rules -- add new IOCs to the list without modifying or redeploying the rule. This enables threat intel teams to update IOC lists daily without involving detection engineers.
How does Chronicle data ingestion work and what parsers are available?
Chronicle ingests data via three methods: Chronicle Forwarder (a lightweight agent deployed on-premises or in cloud environments that collects syslog, files, Kafka topics), Google Cloud Pub/Sub (for GCP-native log sources), and the Ingestion API (direct HTTPS POST of raw or pre-normalized log data). Chronicle includes built-in parsers for 300+ log sources (Palo Alto PAN-OS, Cisco ASA, Okta, CrowdStrike Falcon, Windows Event Logs via Sysmon, Zeek/Bro). Custom parsers use Chronicle's proprietary parser configuration language for log sources without a built-in parser. The parser converts raw log fields to UDM fields -- a correctly written parser is essential for detection rules to work against that log source.
How does Chronicle SIEM compare to Splunk SPL for detection engineering?
The fundamental difference is search paradigm: Splunk SPL is a search-and-transform pipeline (data flows through sequential pipe operations, each transformation modifying the result set). YARA-L is a declarative pattern language (you describe what pattern you want to detect, and Chronicle's engine evaluates it continuously). In SPL, multi-event correlation requires complex stats/transaction commands and is typically done on-demand. In YARA-L, multi-event correlation is a first-class language feature in the match section with built-in time windowing. Chronicle's UDM normalization also means detection rules work across all log sources without source-specific field name knowledge, whereas Splunk SPL rules typically require source-specific index and field name knowledge.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.