Google SecOps Formerly Chronicle. Two things make it different from every SIEM you have used: UDM, a strict normalised schema everything is parsed into, and YARA-L 2.0, a rule language built for time-windowed correlation rather than SQL-with-extras. Learn those two and the rest of the platform is navigation.

SecOps ingests security telemetry, parses it into a single schema, indexes it against an entity graph, and runs detection rules continuously over both live and historical data. Retention is typically a year at a flat capacity price rather than per-GB-per-day, which changes behaviour: you stop rationing what you send and stop deleting history to save money.

Every source is tagged with a log type (e.g. WINEVTLOG, AWS_CLOUDTRAIL, OKTA, NETSKOPE_ALERT, GMAIL_LOGS). The log type selects the parser, so getting it wrong is the usual reason fields arrive empty.

UDM describes every event with the same grammar. Learn these six top-level objects and you can read any event from any product.

Read it as a sentence: principal did event_type to target, with security_result as the outcome. "User jdoe on host LAPTOP-01 (principal) performed NETWORK_DNS for cdn-metrics.io (target/network), result ALLOW."

Alongside events, SecOps maintains entities — assets, users, resources — assembled from context sources (asset inventory, IdP directory, EDR, vulnerability data). This is why clicking a hostname gives you an owner, an OS, recent alerts and prevalence rather than a bare string.

• Asset context — is this a server, a laptop, whose is it, which site?
• User context — department, manager, groups, employment status. Enables rules like "privileged group change involving an account marked as departed".
• Threat intelligence — Google's own feeds and Mandiant intelligence applied to observed indicators.
• Prevalence — how common is this domain or hash across your environment and globally. Rarity is a first-class signal here rather than something you compute manually.

Entities are referenced in YARA-L via the entity keyword in a graph join, letting a rule ask "was the involved user, at the time of the event, in the finance group?" — context most SIEMs force you to hard-code into lists.

// operators
=  !=            equality
> < >= <=        numeric comparison
/regex/          regular expression match  (add nocase)
and or not ( )   composition

Worked searches

// failed logins for one user across every product
metadata.event_type = "USER_LOGIN"
and principal.user.userid = "jdoe@example.com"
and security_result.action = "BLOCK"

// DNS lookups with long, high-entropy labels — tunnelling candidates
metadata.event_type = "NETWORK_DNS"
and network.dns.questions.name = /^[a-z0-9]{25,}\./ nocase

// encoded PowerShell anywhere in the estate
metadata.event_type = "PROCESS_LAUNCH"
and principal.process.command_line = /-enc|frombase64string|downloadstring/ nocase

// proxy uploads to personal cloud storage over a size threshold
metadata.event_type = "NETWORK_HTTP"
and network.http.method = "POST"
and target.url = /dropbox|drive\.google|wetransfer/ nocase
and network.sent_bytes > 10000000

// AWS: role assumption from outside known egress ranges
metadata.log_type = "AWS_CLOUDTRAIL"
and metadata.product_event_type = "AssumeRole"
and not principal.ip in cidr ["203.0.113.0/24"]

// aggregate: which hosts contacted a domain, and how often
metadata.event_type = "NETWORK_DNS"
and network.dns.questions.name = "cdn-metrics.io"
group by principal.hostname

Two habits that speed everything up: search by event_type first to cut the corpus before adding conditions; and when a search returns nothing, check the field is actually populated for that log type before assuming the behaviour did not occur.

Reference lists are named collections — strings, regex patterns or CIDR ranges — usable in both searches and rules. They are the correct home for anything that changes independently of detection logic.

// in a rule or search
not $e.principal.ip in cidr %corporate_egress_ranges
$e.principal.process.file.full_path in %approved_admin_tools
$e.target.domain in %known_bad_domains

Good candidates: corporate egress and POP ranges, approved admin tooling paths, service-account names, break-glass accounts, executive accounts for high-touch rules, and vendor domains. Bad candidate: anything that encodes the logic of the detection rather than its data — that belongs in the rule so it is visible in review.

YARA-L borrows its shape from YARA but operates over time-ordered events rather than file contents. Every rule has the same skeleton:

rule suspicious_encoded_powershell {

  meta:
    author      = "secops"
    description = "Encoded PowerShell launched by an Office application"
    severity    = "HIGH"
    mitre_attack_tactic    = "Execution"
    mitre_attack_technique = "T1059.001"
    reference   = "internal-runbook-042"
    version     = "1.1"

  events:
    $e.metadata.event_type = "PROCESS_LAUNCH"
    $e.principal.process.parent_process.file.full_path = /winword|excel|outlook/ nocase
    $e.principal.process.command_line = /-enc |-e |frombase64string/ nocase
    $host = $e.principal.hostname          // placeholder for grouping

  outcome:
    $risk_score = max(85)
    $user       = array_distinct($e.principal.user.userid)

  condition:
    $e
}

Variables beginning with $ and bound to event fields are event variables ( $e ); those bound to a value used for grouping are placeholders ( $host, $user ). A placeholder appearing in match means "correlate events that share this value".

Single-event: no match section; the condition is simply $e. One matching event, one detection. Good for unambiguous behaviour.

Multi-event: a match section declares the join key and window. This is how you express "the same host did A then B within ten minutes".

rule phish_to_takeover_chain {

  meta:
    description = "Web click to newly-seen domain followed by a login from a new ASN"
    severity    = "CRITICAL"

  events:
    // A: user browses to a newly registered domain (Netskope/proxy)
    $click.metadata.event_type = "NETWORK_HTTP"
    $click.security_result.category_details = /Newly Registered/ nocase
    $click.principal.user.userid = $user

    // B: successful login for the same user from an unexpected ASN
    $login.metadata.event_type = "USER_LOGIN"
    $login.security_result.action = "ALLOW"
    $login.principal.user.userid = $user
    not $login.principal.ip in cidr %corporate_egress_ranges

  match:
    $user over 30m

  outcome:
    $risk_score = max(95)
    $domains    = array_distinct($click.target.domain)

  condition:
    $click and $login
}

Counting and thresholds

  condition:
    #failed >= 10 and $success        // 10+ failures then a success
    #e > 50                            // event count threshold
    $a and not $b                      // A happened, B did not

#var is the count of events bound to that variable within the match window — the mechanism behind brute-force, spray and beaconing rules. Note also the not $b form: absence of an expected event (no EDR alert after a proxy block, no MFA event after a login) is often the most interesting condition you can write.

  outcome:
    $risk_score = max(
        if($e.principal.user.userid in %executives, 90, 50)
    )
    $event_count   = count($e.metadata.id)
    $unique_hosts  = count_distinct($e.principal.hostname)
    $commands      = array_distinct($e.principal.process.command_line)
    $total_bytes   = sum($e.network.sent_bytes)

Functions available include max, min, sum, count, count_distinct, array_distinct, and conditional if() expressions. Two reasons to invest here:

• Outcome values appear in the alert, so the analyst sees the command lines or byte totals without running a second search.
• $risk_score drives prioritisation and can be raised contextually — the same behaviour on an executive or an admin account scoring higher than on a test machine.

• Curated detection sets — rule packs maintained by Google covering cloud threats, Windows threats, and applied threat intelligence. Enable by set, tune by exclusion; you cannot edit them directly, so persistent noise is managed with rule exclusions and reference lists.
• IoC matching — observed domains, IPs and hashes checked against Google and Mandiant intelligence, surfacing as separate matches rather than rule detections.
• Risk Analytics — aggregated risk per entity from contributing detections, giving you "which user or host is worst right now" instead of a flat alert queue.

Treat curated content as a floor, not a ceiling. It cannot know your naming conventions, your admin tooling, your business processes or which of your users handle payments — and that context is precisely what makes a detection high-fidelity. Your own rules should encode the things only you know.

• Unparsed or partially-parsed sources — the field your rule depends on is empty for one product. Test per source, not per rule.
• Silent feed failure — build a detection that alerts when a critical log type stops arriving. Nothing else will tell you.
• Timestamp problems — sources with wrong clocks or timezone handling break correlation windows quietly.
• Missing telemetry entirely — no rule compensates for command-line auditing being disabled, or an unmanaged device with no agent.
• Parser drift — a vendor changes their log format and fields silently move. Periodically re-validate sample events for key sources.
• Alert fatigue — a detection nobody triages is not a control. Measure closure reasons, not alert counts.