Tuesday's Tip of the Week

July 28, 2026 YARA-L Rule Structure Every YARA-L rule follows five sections: meta (author, severity, MITRE mapping), events (UDM field conditions), match (grouping variable and time window), outcome (alert payload), and condition (firing threshold). YARA-L uses standard UDM fields and evaluates them continuously.Your First Rule: Brute Force Login Detection rule detect_brute_force_login { meta: author = "SecOps Team" description = "Detects multiple failed login attempts from a single source" severity = "MEDIUM" mitre_attack = "T1110" events: $login.metadata.event_type = "USER_LOGIN" $login.security_result.action = "BLOCK" $login.principal.ip = $source_ip $login.target.user.userid = $target_user match: $source_ip over 15m outcome: $failed_count = count($login) $targeted_users = count_distinct($target_user) $user_list = array_distinct($target_user) condition: $login and $failed_count >= 10}Section-by-Section Breakdown meta: Descriptive fields

July 21, 2026 Why Service Accounts Are High-Value Targets Service accounts are the keys to your cloud kingdom. Unlike human accounts, they rarely have MFA, they often hold broad permissions, and their activity is easy to overlook because "that is just automation." Attackers know this. A compromised service account gives persistent, privileged access without triggering the usual user-behavior alerts. Using UDM Search, we can hunt for the telltale signs. Query 1: Service Account Logins from Unexpected IPs Service accounts typically authenticate from a small set of known compute resources. Logins from outside that range deserve investigation. The query is formatted below: metadata.event_type = "USER_LOGIN" AND metadata.log_type = "GCP_CLOUDAUDIT" AND principal.user.email_addresses = /gserviceaccount\.com/ AND NOT net.ip_in_range_cidr(principal.ip, "10.0.0.0/8") This query finds any GCP service account authenticating from an IP outside your internal `10.0.0.0/8` range. Replace the CIDR wit

July 14, 2026 UDM Search Syntax UDM Search is the ad-hoc query interface in Google SecOps. Specify field-value pairs joined with AND, OR, and NOT.Key rules:Fields use dot notation: metadata.event_type, principal.ip, target.user.userid String values go in double quotes: metadata.event_type = "USER_LOGIN" Combine with AND / OR, negate with NOT Regex uses forward slashes: target.process.file.full_path = /mimikatz/ No $ variables, no match:, no outcome:, no condition: blocks. Those belong to YARA-L detection rules.Example 1: Find All Failed Loginsmetadata.event_type = "USER_LOGIN" AND security_result.action = "BLOCK"This returns failed logins from all ingested sources. Add AND target.user.userid = "jsmith" to scope to a single user. Example 2: Find Network Connections to Specific CIDRs’metadata.event_type = "NETWORK_CONNECTION" AND network.direction = "OUTBOUND"To check connections against a CIDR range, use the net.ip_in_range_cidr() function:metadata.event_type = "NETWORK_CONNECTION" AND

June 30, 2026Why Parsers Matter Every log source that flows into Google SecOps must be transformed from its raw format into UDM before it becomes searchable, huntable, or detectable. When a log source has no parser, or the default parser misses critical fields, those fields simply do not exist in UDM. Your detection rules cannot match on data that was never mapped. Your UDM Search queries return nothing. The raw data is technically stored, but it is invisible to your detection program until a parser maps it correctly. How CBN Parsers Work Chronicle uses Code-Based Normalizer (CBN) parsers. Each parser handles a specific log source and follows a consistent workflow:Ingest raw log: The parser receives a raw log entry (JSON, syslog, CSV, XML, or other format). Extract fields: The parser uses extraction logic (Grok patterns, regex, JSON path expressions) to pull individual values from the raw log. Map to UDM: Each extracted value is mapped to the appropriate UDM field. A source IP becomes 

June 23, 2026“Feeds, BindPlane, and Cloud Connectors: How Data Enters SecOps” Why Ingestion Matters Detection rules only work if the right data is flowing. A perfect brute force rule is useless if authentication logs never arrive. Path 1: Google Cloud Connector The simplest path for GCP-native sources. Provides direct integration for GCP audit logs and Cloud Logging. Configured in SecOps Settings > Feeds. For GCP audit logs, no separate log sink is required.Common log types: GCP_CLOUDAUDIT (Admin Activity, Data Access, System Event audit logs) and GCP_CLOUD_LOGGING (application logs, VPC Flow Logs, firewall logs). Path 2: BindPlane Agent For on-premises and self-managed sources that cannot push to a cloud API. The legacy Chronicle forwarder is end of life, and BindPlane is the supported replacement. The BindPlane agent is an OpenTelemetry-based collector that accepts syslog (TCP/UDP), CEF, LEEF, raw log files, and Windows Event Logs, then sends to SecOps over an encrypted channel. I

June 16, 2026UDM: One Schema to Hunt Them All Why Normalization Matters Every security tool speaks its own language. Windows Event Logs call it "LogonType," Okta calls it "eventType," and GCP calls it "methodName." Hunting across all three means memorizing three schemas, writing three queries, and maintaining three sets of detection logic. Google SecOps solves this with the Unified Data Model (UDM), a single normalized schema that every log source maps into on ingestion.When a Windows logon event (Event ID 4624), a GCP IAM authentication, and an Okta user.session.start all arrive in SecOps, they are each normalized to metadata.event_type = "USER_LOGIN". One query catches all three. The UDM Noun Groups Every UDM event is structured around noun groups. Each group describes a different participant or aspect of the event.Noun Group What It Describes Example Fields metadata Event classification and timing metadata.event_type, metadata.log_type, metadata.product_event_type, metadata