Posts in category: Google secops

Security teams collect enormous amounts of telemetry, but raw logs rarely tell an analyst whether an activity represents a genuine threat. This is where detection rules become important. In Google SecOps, YARA-L provides a way to turn security events into detection logic by describing the behavior, relationships, and conditions that should be considered suspicious.

Writing an effective YARA-L rule is not simply a matter of learning syntax. The real challenge is translating a security hypothesis into precise logic that can identify meaningful activity without overwhelming analysts with irrelevant alerts.

What Is YARA-L in Google SecOps?

YARA-L is the detection-rule language used by Google SecOps to identify patterns in security telemetry. It operates against events represented through the Unified Data Model (UDM), allowing a rule to examine individual events as well as relationships between multiple events.

A simple rule can look for a particular event and field value:

rule Suspicious_Login {
  meta:
    author = "Security Team"
    description = "Detects a failed user login"

  events:
    $e.metadata.event_type = "USER_LOGIN"
    $e.security_result.action = "FAIL"

  condition:
    $e
}

This example is intentionally simple. It demonstrates the fundamental structure of a YARA-L rule: metadata describes the detection, the events section defines the evidence, and the condition determines when that evidence is sufficient to produce a detection.

More sophisticated rules can correlate different events, group activity around entities such as users or hosts, apply time windows, perform aggregation, and generate additional outcome information.

Start With a Security Hypothesis

The best way to write a YARA-L rule is to begin without writing YARA-L.

First describe the behavior you want to detect in plain language.

For example:

Detect repeated failed authentication attempts against the same account within a short period.

This statement contains nearly everything needed to design the detection:

• The relevant behavior is authentication failure.
• Multiple events are required.
• The account is the entity connecting those events.
• A time window is necessary.
• A threshold determines when the behavior becomes interesting.

Only after these decisions have been made should they be translated into YARA-L.

This approach prevents a common detection-engineering problem: writing syntactically correct rules that do not actually represent a useful security hypothesis.

Understand the Main Parts of a Rule

A YARA-L rule can contain several sections, with meta, events, and condition forming the basic foundation.

rule Failed_Login_Burst {
  meta:
    author = "Security Team"
    description = "Detects repeated failed logins for one user"

  events:
    $e.metadata.event_type = "USER_LOGIN"
    $e.security_result.action = "FAIL"
    $user = $e.target.user.userid

  match:
    $user over 10m

  outcome:
    $failed_count = count($e.metadata.id)

  condition:
    #e >= 5
}

Each section has a different responsibility.

The meta section provides information about the rule itself. Good metadata should explain what the detection is intended to find and provide enough context for another engineer to understand its purpose.

The events section defines the evidence. This is where you identify the UDM fields and values that represent the behavior.

The match section establishes how events are grouped and over what period.

The outcome section can produce useful information from the matching activity.

The condition section determines when the evidence satisfies the detection criteria.

Keeping these responsibilities separate makes rules easier to understand and maintain.

Choose the Right UDM Fields

One of the most important parts of YARA-L detection engineering happens before the rule is written: identifying the correct UDM fields.

A detection can fail even when its logic looks perfect if it references a field that the relevant log source does not populate consistently.

For example, if a rule relies on:

$user = $e.target.user.userid

you need confidence that the relevant authentication events actually contain the account identifier in that field.

Do not assume that similarly named fields from different products have identical meaning. A username, account identifier, email address, and display name may represent different entities even though all appear to identify a person.

The safest approach is to inspect representative normalized events and determine which field consistently represents the entity you want to correlate.

Use Event Variables to Represent Evidence

Event variables represent the events that satisfy your filters.

For example:

$e.metadata.event_type = "USER_LOGIN"
$e.security_result.action = "FAIL"

Here, $e represents matching login events.

You can then extract an entity from the event:

$user = $e.target.user.userid

The $user placeholder is important because it gives the detection something around which activity can be correlated.

This becomes particularly powerful when multiple event variables are involved.

$login.target.user.userid = $user
$process.principal.user.userid = $user

The shared $user indicates that the authentication and process events concern the same account.

The key idea is to think in terms of relationships, not just individual log entries.

An individual event might be completely legitimate. The relationship between several events may be what makes the activity suspicious.

Define Correlation Around Meaningful Entities

A detection should be grouped around the entity that actually represents the behavior.

Depending on the use case, that might be:

• A user
• A host
• An IP address
• A process
• A file
• A cloud resource
• An application account

For example, repeated failed logins should generally be associated with the account being targeted. A process-based behavior might instead need to be associated with the originating host or user.

Choosing the wrong correlation key can dramatically change what the rule detects.

Consider a rule that groups failed authentication attempts only by source IP. Multiple users behind a shared proxy could become one apparent attack. Conversely, grouping only by user could combine activity from unrelated locations.

The correlation key should therefore reflect the question the detection is trying to answer.

Use Time Windows to Represent Behavior

The match section allows related activity to be evaluated within a defined period.

For example:

match:
  $user over 10m

This means the rule evaluates matching activity associated with the same user within the specified window.

The window should represent the behavior you are trying to detect.

A short burst of authentication failures is different from a pattern that develops gradually over several hours. Using an unnecessarily broad window can cause unrelated activity to appear connected, while an excessively narrow window can cause genuine behavior to be missed.

A useful design question is:

Would an analyst consider these events part of the same incident if they occurred at opposite ends of this window?

If the answer is no, the window may be too large.

Make the Condition Express the Detection Threshold

The condition section should represent the point at which evidence becomes significant.

For example:

condition:
  #e >= 5

The #e expression represents the number of matching events associated with the event variable.

This gives the rule a clean separation between evidence and decision logic.

The events section answers:

What constitutes a relevant failed login?

The match section answers:

Which failed logins belong to the same behavioral window?

The condition answers:

How much activity is required before the behavior becomes a detection?

That separation makes tuning substantially easier.

Correlate Multiple Events for Higher-Context Detections

Many useful detections cannot be expressed by looking at a single event.

Suppose the security hypothesis is that a user authentication is followed by suspicious process activity on the same endpoint.

The rule can represent the two observations separately:

events:
  $login.metadata.event_type = "USER_LOGIN"
  $login.target.user.userid = $user

  $process.metadata.event_type = "PROCESS_LAUNCH"
  $process.principal.user.userid = $user

The shared placeholder establishes a relationship between the events.

This style of detection can provide more context than a simple event filter because the signal comes from the combination of behaviors.

However, correlation should be purposeful. Adding more events does not automatically make a detection better. Every additional event should contribute meaningful evidence to the security hypothesis.

Protect Against Empty or Missing Values

Correlation logic requires particular care when fields can be absent.

For example:

$user = $e.target.user.userid

looks straightforward, but what happens when the field is missing?

A detection that unintentionally correlates events with empty values can produce misleading results.

Explicitly checking important correlation fields is therefore a useful defensive practice:

$e.target.user.userid != ""
$user = $e.target.user.userid

This is especially important when the rule depends on equality between events.

Detection engineers should always ask:

What happens when this field is missing, empty, malformed, or populated differently by another log source?

Those cases often reveal weaknesses that are invisible when testing only clean examples.

Use Reference Data for Environmental Context

Not everything belongs inside the rule itself.

Organizations often have lists of approved scanners, administrative systems, trusted infrastructure, service accounts, or other known environmental entities.

Instead of embedding those values directly into detection logic, use reference data where appropriate.

Conceptually:

$e.principal.hostname in %approved_hosts

This creates a useful separation.

The detection rule describes the behavior that is potentially suspicious, while the reference data describes the organization’s current environment.

That makes the detection easier to maintain. When infrastructure changes, the contextual data can be updated without rewriting the core behavioral logic.

Treat Exceptions as Carefully as Detection Conditions

False positives often lead engineers to add exclusions.

For example, if legitimate administrative activity repeatedly triggers a rule, it may be tempting to exclude an entire host or account.

Broad exclusions can create blind spots.

Before adding an exception, determine why the activity is legitimate and whether the exception can be narrowed.

Instead of thinking:

This host is trusted.

think:

This specific behavior from this specific administrative context is expected.

That distinction is important because attackers can operate through legitimate infrastructure, compromised administrative accounts, and otherwise trusted systems.

An exception should therefore have an owner, a reason, and a scope that is no broader than necessary.

Use Outcomes to Improve Investigation

A detection should not only tell an analyst that something happened. It should provide useful context about why it happened.

An outcome expression can calculate information from matching events.

For example:

outcome:
  $failed_count = count($e.metadata.id)

The resulting information can help an analyst understand the scale of the activity without immediately returning to the raw telemetry.

This creates a useful distinction between triggering evidence and investigative context.

The condition decides whether the detection fires. Outcomes can help explain the activity after it fires.

Test the Logic, Not Just the Syntax

A rule that saves successfully is not necessarily a good detection.

Testing should include both positive and negative scenarios.

For a repeated-login detection, test cases might include:

• A single failed login.
• Several failures within the intended window.
• Failures separated by more than the intended window.
• Events where the username is missing.
• Legitimate authentication systems that generate repeated failures.
• Different capitalization of relevant string values.
• Multiple users generating failures from the same infrastructure.

The purpose is to establish whether the rule behaves according to the original security hypothesis.

One particularly useful technique is to write the expected result for each test case before examining the rule’s result. This prevents the observed behavior from becoming the definition of what the rule was supposed to detect.

Tune False Positives by Finding Their Cause

When a detection generates too many alerts, simply increasing the threshold is often the easiest response—but not necessarily the most appropriate one.

Instead, classify why the alerts are occurring.

The cause might be:

• Legitimate automation.
• Vulnerability scanning.
• A noisy identity provider.
• Shared infrastructure.
• Incomplete normalization.
• An overly broad correlation key.
• An inappropriate time window.
• A detection condition that is too permissive.

Once the cause is understood, the rule can be adjusted at the correct layer.

This is a valuable detection-engineering principle:

Tune the assumption that is wrong, rather than weakening the entire detection.

Write Rules That Another Analyst Can Understand

A detection eventually becomes part of a larger security operation. The original author may not be available when someone needs to investigate or modify it.

Good metadata and clear variable names therefore matter.

Prefer:

$source_ip
$target_user
$process_event
$authentication_event

over names that require the reader to reverse-engineer their meaning.

The rule should also explain unusual exclusions or non-obvious logic in its metadata or comments.

A good detection is not merely executable logic. It is operational documentation.

A Practical YARA-L Design Pattern

A reusable way to approach many detections is:

Security hypothesis
        ↓
Relevant UDM events
        ↓
Required event fields
        ↓
Correlation entity
        ↓
Time window
        ↓
Detection threshold
        ↓
Investigation outcomes
        ↓
Positive/negative testing
        ↓
Production tuning

This workflow is more durable than memorizing individual YARA-L examples because it can be applied to authentication, endpoint, network, cloud, identity, and other detection scenarios.

Writing YARA-L detection rules in Google SecOps is fundamentally an exercise in detection engineering.

The syntax tells Google SecOps how to express the logic, but the quality of the detection comes from the reasoning behind that logic.

Start with a specific behavioral hypothesis. Identify the UDM events that provide evidence for it. Choose correlation entities carefully, use a time window that reflects the behavior, and make the condition represent a defensible detection threshold. Then test the rule against both expected attacks and legitimate activity.

The most valuable YARA-L rules are not necessarily the most complicated. They are the rules where every condition has a purpose, every correlation has a reason, and every alert gives an analyst enough context to understand what deserves investigation.

That is the difference between a rule that merely matches logs and a detection that contributes meaningful security signal.

A detection rule is normally designed to identify suspicious activity as it happens. But what if the rule was created today and the attacker was already inside the environment last week?

That is where a retrohunt in Google SecOps becomes useful. A retrohunt takes an existing YARA-L detection rule and evaluates it against historical security telemetry, allowing analysts to determine whether the behavior described by the rule occurred before the rule was enabled for live detection.

This makes retrohunting particularly valuable after discovering a new indicator, creating a new detection rule, investigating a security incident, or learning about a technique that may have been used before your current detection coverage existed.

What a retrohunt actually does

A retrohunt is essentially a historical execution of a detection rule.

Instead of waiting for new events to arrive, Google SecOps evaluates the rule against data already stored in the platform for a selected period. The resulting detections can then be investigated in the same general workflow used for other rule-generated findings.

The important distinction is that a retrohunt is not simply a historical keyword search. Its behavior depends on the logic of the underlying YARA-L rule.

For example, a rule might look for:

• A particular process execution.
• A suspicious authentication pattern.
• A relationship between a process and network connection.
• Multiple events associated with the same user or host.
• A sequence of activities occurring within a defined time window.

Consequently, the quality of a retrohunt depends heavily on the quality of the rule being executed.

Prepare the rule before starting

Before launching a retrohunt, inspect the rule as though you were going to deploy it for live detection.

Google SecOps uses YARA-L for detection rules. A typical rule contains an events section describing the telemetry to evaluate and a condition section defining when the rule should produce a detection. Multi-event rules can also use match to establish how events are correlated over time.

A simplified example could look like this:

rule SuspiciousPowerShellActivity {
  meta:
    author = "SOC"
    description = "Detects suspicious PowerShell execution"

  events:
    $e.metadata.event_type = "PROCESS_LAUNCH"
    $e.target.process.file.full_path = /powershell/i

  condition:
    $e
}

The exact fields should be adapted to the telemetry in your environment. A syntactically valid rule can still produce poor hunting results if the selected UDM fields are not populated consistently.

That leads to one of the most important retrohunt preparation steps: verify that the underlying telemetry existed during the period you intend to hunt.

A perfect rule cannot recover information that was never ingested or is outside your available retention period.

Check the rule’s time logic

Time windows deserve special attention when retrohunting multi-event rules.

Suppose a rule correlates two activities within a defined window. The historical search period needs to accommodate that correlation window.

Consider a rule that correlates a suspicious login with a subsequent process execution. If those events must occur within a specific period, the retrohunt range needs to be large enough for the detection engine to evaluate the relationship correctly.

This is an easy detail to overlook because the analyst may be thinking about the investigation’s calendar dates while the detection engine is thinking about event relationships and correlation windows.

The choice of windowing logic can also affect how events are grouped during evaluation. A rule designed to identify relationships between events can therefore behave differently from a simple single-event rule during historical analysis.

Navigate to the Rules Dashboard

Once the rule is ready:

• Open Detections in Google SecOps.
• Go to Rules & Detections.
• Open the Rules Dashboard.
• Locate the YARA-L rule you want to test against historical data.
• Open the rule’s options menu.
• Select YARA-L Retrohunt.

The retrohunt function is launched directly from the rule-management workflow.

This is important because the retrohunt is executed against the rule itself. You are not creating a separate detection definition simply for the historical investigation.

Select the historical search window

The retrohunt dialog allows you to specify the beginning and end of the historical period.

Choose the window based on the investigation rather than automatically choosing the largest possible period.

For example, if an investigation indicates that suspicious activity may have started around a particular date, begin with a period that encompasses that activity and its surrounding context. A focused hunt can make the resulting detections easier to interpret.

For a suspected long-running compromise, expanding the historical window can be useful because an attacker may have performed the behavior intermittently.

The key is to treat the date range as an investigative hypothesis:

Could this detection have fired if this behavior had occurred during this period?

That question is more useful than simply asking whether the rule returns anything.

Run the retrohunt

After selecting the historical range, start the retrohunt.

Google SecOps processes the rule against historical telemetry and provides progress information while the operation is running.

Do not interpret an empty result immediately as proof that the behavior never occurred.

An empty retrohunt can mean several different things:

• The behavior genuinely did not occur.
• The relevant telemetry was not ingested.
• The relevant data was outside the selected period.
• The rule uses a field that is not populated by the applicable log source.
• The rule’s exclusions removed the events.
• The activity occurred in a form different from what the rule describes.
• A multi-event correlation requirement was not satisfied.

This distinction is one of the most important aspects of responsible threat hunting.

No detection is evidence about the rule’s logic and available telemetry; it is not automatically evidence that the underlying activity never happened.

Monitor and inspect the results

After the retrohunt finishes, examine the historical detections generated by the run.

When investigating a detection, avoid stopping at the fact that the rule matched.

Instead, ask:

• Which event caused the match?
• Which entity was involved?
• What host, user, process, IP address, or other identifier connects the events?
• Did the activity occur once or repeatedly?
• Does the surrounding timeline support the detection?
• Is the matched activity expected for this system?
• Are there related events before or after the detection?
• Does the event represent an actual security concern or merely satisfy the rule’s technical conditions?

This turns a retrohunt from a binary “hit/no-hit” exercise into an investigation.

Use retrohunt results to improve the rule

One of the most useful applications of retrohunting is detection validation.

Suppose a newly written rule generates hundreds of historical matches. That does not necessarily mean hundreds of compromises occurred. It may reveal that the rule describes normal administrative activity too broadly.

Conversely, a rule returning no matches may reveal that its assumptions do not align with the organization’s telemetry.

A productive tuning cycle is:

hypothesis → rule → retrohunt → investigation → tuning → retrohunt again

The second retrohunt is especially valuable. Rather than treating the first result as the final answer, modify the rule based on what the historical data revealed and test it again.

This approach allows historical telemetry to function as a practical test dataset for detection engineering.

Pay attention to reference lists

Reference lists introduce another important consideration.

If a rule depends on a reference list, changing that list after a retrohunt does not necessarily remove detections generated by an earlier run. Historical results should therefore be interpreted in the context of the rule and supporting data that existed when the hunt was executed.

For example, an analyst might:

• Run a retrohunt.
• Discover that an item in a reference list caused unwanted matches.
• Remove the item.
• Run the updated logic again.
• Compare the new results with the earlier run.

This creates a useful before-and-after view of detection tuning.

For repeatable investigations, record the rule version and relevant reference-list state alongside your hunt notes.

Retrohunt versus ordinary search

A normal YARA-L search and a retrohunt can answer related questions, but they serve different operational purposes.

A search is useful when you want to explore telemetry interactively, test a hypothesis, or examine particular UDM fields.

A retrohunt is useful when you already have detection logic and want to evaluate that logic against historical data.

This distinction creates a useful workflow:

Search to explore → build detection logic → validate the rule → retrohunt historical data → investigate matches → tune the rule → deploy for live detection.

Using exploration before formal detection logic can reduce the risk of building rules around assumptions that do not match the organization’s actual telemetry.

A practical retrohunt checklist

Before starting the hunt, confirm:

• The rule compiles successfully.
• The rule uses the correct UDM fields.
• The relevant log sources were ingesting data during the selected period.
• The historical period covers the suspected activity.
• The time range is compatible with the rule’s correlation window when applicable.
• Reference lists and other contextual dependencies are in the expected state.
• You understand what constitutes a genuine match.
• You have a plan for investigating the resulting detections.

After the run:

• Examine the matched events rather than only the detection count.
• Compare hits against known-good administrative activity.
• Look for recurring hosts, users, processes, or infrastructure.
• Expand the investigation around suspicious timestamps.
• Record false-positive patterns.
• Tune the rule where appropriate.
• Run the revised logic again when historical validation is useful.

The deeper value of retrohunting

The real value of a retrohunt is not discovering that a rule produced a detection.

It is discovering what your detection logic would have seen if it had existed earlier.

That makes retrohunting particularly powerful after incident-response discoveries. If an investigation uncovers a previously unknown command pattern, domain, process relationship, or authentication sequence, analysts can encode that observation into YARA-L and look backward through available telemetry.

It also provides a feedback mechanism for detection engineering. Historical data exposes assumptions that may remain invisible during rule development: noisy administrative processes, inconsistent logging, unexpected UDM normalization, missing fields, or correlations that are too broad or too restrictive.

Used this way, a retrohunt is more than a historical scan. It is a controlled experiment against your organization’s existing security telemetry.

The strongest outcome is therefore not simply “the rule found something.” It is a defensible understanding of what the rule can detect, what it cannot detect, which historical evidence supports the result, and what should change before the detection becomes part of ongoing monitoring.

SOC productivity is often discussed as a tooling problem: collect better telemetry, automate more playbooks, add AI, or replace a legacy SIEM. But long-term productivity is rarely determined by a single feature. It is determined by how much analyst attention the platform consumes versus how much investigation work it removes.

That distinction changes the way platforms should be evaluated.

A platform that looks inexpensive but requires constant rule tuning, integration maintenance, and manual investigation can become expensive in analyst time. Conversely, a platform with broad automation can deliver disappointing value if analysts do not trust its conclusions or still have to leave the console to complete an investigation.

For most modern SOCs, the long-term value question therefore comes down to the relationship between SIEM, SOAR, XDR, and increasingly AI-assisted SOC platforms. They overlap, but they create productivity in fundamentally different ways.

The real productivity problem is not alert volume

The traditional SOC workflow is fragmented.

An alert appears in a SIEM. The analyst opens the EDR to inspect the endpoint. Identity information comes from another console. Email evidence sits somewhere else. Threat intelligence requires another lookup. A ticketing platform records the eventual decision.

Each individual tool may work perfectly.

The analyst still loses time connecting the pieces.

This is why reducing the number of clicks is not enough. The more meaningful productivity metric is investigation distance: the amount of work required to move from an initial signal to a defensible decision.

A productive platform shortens that distance by providing:

• Relevant evidence alongside the alert
• Entity and incident correlation
• Historical context
• Guided investigation
• Reliable enrichment
• Case documentation
• Response actions
• Appropriate automation
• A clear audit trail

The important insight is that these capabilities compound. Removing one manual lookup helps once. Automatically preserving context throughout an investigation helps every time an analyst investigates.

SIEM remains valuable, but productivity is not its entire purpose

A SIEM is fundamentally a visibility, search, correlation, and security-data platform. It is particularly valuable when an organization needs broad telemetry coverage, custom detection logic, historical investigation, and centralized security evidence.

That makes SIEM difficult to eliminate from many mature environments.

However, data centralization and analyst productivity are not synonymous.

A SIEM can give an analyst access to enormous quantities of information while still requiring that analyst to determine which pieces matter. The productivity ceiling therefore depends heavily on detection engineering, normalization, correlation, tuning, and integrations.

This creates an important long-term consideration: a SIEM can become more capable while simultaneously becoming more demanding to operate.

For organizations with strong detection engineering teams, that flexibility can be an advantage. For lean SOCs, the operational burden can become part of the platform’s hidden cost.

SOAR creates value when the process is predictable

SOAR attacks a different productivity problem: repetitive work.

When analysts repeatedly perform the same sequence—enrich an indicator, query a system, create a ticket, notify an owner, or perform an approved containment action—automation can remove substantial manual effort.

The limitation is that traditional playbooks work best when the decision tree is already understood.

That creates a useful rule for evaluating SOAR:

Automate the procedure before attempting to automate the judgment.

If an organization has inconsistent investigations, poorly tuned detections, or unclear escalation criteria, adding more playbooks can simply automate an inefficient process.

SOAR therefore tends to produce its strongest long-term productivity gains when the SOC already has mature, repeatable workflows.

XDR changes the analyst’s starting point

XDR approaches productivity from another direction: instead of asking the analyst to assemble evidence from multiple security controls, it attempts to correlate security telemetry across domains before or during investigation.

The productivity benefit is particularly relevant to incidents that cross boundaries.

A suspicious identity event may become meaningful only when correlated with endpoint activity. Endpoint execution may become more concerning when associated with an unusual cloud session. An email event may matter because the same identity subsequently performs an unusual action.

Cross-domain correlation can reduce the amount of investigative stitching an analyst has to perform manually.

The trade-off is scope.

An XDR platform is generally strongest where its telemetry, integrations, and correlation capabilities are strongest. Organizations with highly heterogeneous environments need to examine how well the platform handles systems outside its preferred ecosystem.

AI is changing what “platform productivity” means

The biggest shift in the productivity equation is the emergence of AI-assisted investigation.

AI can potentially compress several activities that previously required separate analyst actions:

Alert → enrichment → correlation → investigation summary → recommended disposition → case documentation

That is materially different from simply adding an AI chatbot to a security console.

The valuable capability is not conversation. It is contextual execution.

A useful AI layer should be able to understand the incident, retrieve relevant evidence, reason over multiple security sources, explain why evidence matters, preserve provenance, and leave the human analyst in control of consequential actions.

This creates a new productivity model: AI handles large-scale processing, synthesis, pattern recognition, and flexible automation, while humans remain responsible for critical decisions, verification, and complex investigations.

That distinction matters for long-term value because an AI feature that merely generates summaries may save time, while an AI-enabled workflow that eliminates repeated investigation steps can change the economics of an entire SOC.

The hidden cost is maintenance

One of the least-discussed factors in platform value is maintenance tax.

Every security platform creates some combination of:

• Detection maintenance
• Integration maintenance
• API maintenance
• Parser and schema maintenance
• Playbook maintenance
• False-positive tuning
• Access management
• Content updates
• Analyst training

The initial deployment rarely reveals the full cost.

This is particularly important when comparing separate SIEM, SOAR, EDR, and intelligence products against a more integrated platform. The question should not simply be:

“How much does the platform cost?”

It should be:

“How much human effort does this architecture require to remain useful six months and two years after deployment?”

That is a much better long-term-value test.

A better way to measure analyst productivity

Traditional SOC metrics such as mean time to detect and mean time to respond remain useful, but they do not fully explain productivity.

A stronger measurement framework examines the analyst’s actual workflow.

Track:

Investigation touches — How many separate systems does an analyst need to consult before reaching a decision?

Context reconstruction — How often does an analyst manually assemble the incident timeline?

Evidence retrieval time — How long does it take to obtain the information needed to validate an alert?

Decision latency — How long does the analyst spend deciding whether an alert deserves escalation?

Documentation burden — How much investigation time is spent writing the case rather than investigating it?

Rework rate — How frequently must another analyst repeat the investigation because the original evidence or reasoning was not captured?

Automation exception rate — How often do automated workflows fail or require manual intervention?

These measurements reveal something that feature comparisons often miss: a platform can increase automation while failing to increase productive analyst capacity.

Long-term value comes from compounding improvements

The most valuable platform is not necessarily the one that saves the most time on a single alert.

It is the one whose benefits compound.

Imagine a platform that automatically preserves incident context, correlates related signals, enriches evidence, recommends investigation steps, and produces a case record. Every improvement feeds the next stage of the workflow.

That creates a compounding effect:

Better context → faster triage → fewer unnecessary investigations → better analyst availability → more thorough investigations → better operational data → better future automation.

This is fundamentally different from isolated automation.

A playbook that saves several manual steps provides a fixed benefit. A platform that improves the quality and structure of every investigation can improve the SOC’s operating model itself.

So which platform offers the strongest long-term value?

For SOC analyst productivity specifically, the strongest long-term value is increasingly associated with a unified security-operations platform that combines broad telemetry access, cross-domain correlation, investigation workflows, automation, and trustworthy AI assistance.

That does not mean SIEM, SOAR, or XDR individually become obsolete.

Rather, the productivity advantage comes from reducing the boundaries between them.

A modern SOC can still require a SIEM for extensive data retention and search, XDR for high-fidelity cross-domain detection and response, and SOAR for deterministic automation. The productivity problem arises when the analyst has to understand the boundaries between those products to investigate a single incident.

The platform architecture with the greatest productivity potential is therefore the one that makes those boundaries operationally invisible to the analyst.

The most important buying question

Instead of asking a vendor, “How much automation does your platform provide?”, ask:

“Show me what happens when an analyst receives a genuinely ambiguous alert.”

Then observe the workflow.

How many consoles are opened?

How many searches are performed?

Does the platform automatically discover related activity?

Can the analyst see why signals were correlated?

Can evidence be traced back to its source?

Can the analyst override an AI recommendation?

Does the case document itself as the investigation progresses?

What happens when the platform’s automation cannot reach a conclusion?

And, critically, how much engineering effort was required to make the demonstration work?

That last question exposes the difference between product capability and operational capability.

The long-term-value test

A SOC platform earns its place over the long term when it does three things simultaneously:

It reduces cognitive load. Analysts spend less time remembering where information lives and more time interpreting evidence.

It reduces operational friction. Investigation, enrichment, documentation, and response happen within one coherent workflow.

It preserves human judgment. Automation accelerates decisions without turning security-critical actions into opaque processes.

AI makes the third requirement particularly important. As autonomous capabilities become more sophisticated, trust, evidence traceability, and human approval mechanisms become productivity features—not merely governance features.

The ultimate measure of long-term value is therefore not the number of features a SOC platform contains.

It is how much high-quality investigative capacity it creates without proportionally increasing operational complexity.

For organizations evaluating platforms today, that is the distinction worth carrying into every proof of concept: don’t measure how impressive the console looks. Measure how much of the analyst’s investigation the platform genuinely carries, how reliably it does so, and how much maintenance is required to keep that productivity intact.

Google SecOps is both a SIEM and a SOAR platform. More accurately, it is a unified security operations platform that combines SIEM, SOAR, threat intelligence, case management, and AI-assisted security workflows.

This distinction matters because Google SecOps is not simply a SIEM product with a few automation features attached, nor is it merely a SOAR product that happens to process security alerts. Its broader purpose is to connect security monitoring, threat detection, investigation, and response within a single security operations environment.

The short answer

If you are asking:

Is Google SecOps a SIEM?
Yes. It provides security telemetry ingestion, normalization, correlation, detection, investigation, search, alerting, and security analytics.

Is Google SecOps a SOAR?
Yes. It provides case management, playbooks, integrations, orchestration, automated actions, and response workflows.

So what is Google SecOps actually?
The most accurate description is that Google SecOps is a unified security operations platform containing both SIEM and SOAR capabilities.

That distinction is important when comparing Google SecOps with other security operations technologies.

Why Google SecOps is a SIEM

The SIEM component of Google SecOps is responsible for collecting and analyzing security telemetry and turning it into information security teams can investigate.

Security data can originate from endpoints, networks, cloud environments, applications, identity systems, firewalls, security appliances, and other sources. Google SecOps brings this information into a common security-data structure so that events from different technologies can be analyzed together.

The SIEM capabilities include:

• Security telemetry collection
• Log ingestion and normalization
• Security event search
• Event correlation
• Threat detection
• Alert generation
• Historical investigation
• Threat hunting
• Security analytics
• Investigation of users, devices, IP addresses, domains, and other entities

This is fundamentally the role of a SIEM.

A simplified representation is:

Telemetry → normalization → detection → alert → investigation

The SIEM side provides the evidence and analytical foundation that allows security analysts to determine what happened, when it happened, and whether different events are connected.

Why Google SecOps is also a SOAR

The SOAR component becomes important after a security event has been detected.

Detection is only one part of incident response. Once an alert has been generated, an analyst may need to investigate the indicator, gather additional information, contact another team, create a ticket, block malicious infrastructure, disable an account, isolate an endpoint, or perform another remediation action.

SOAR is designed to automate and coordinate these activities.

Google SecOps can use playbooks to create repeatable workflows. A playbook can contain multiple actions and decision points, allowing security teams to automate routine processes instead of performing every step manually.

A simplified SOAR workflow looks like:

Alert → case → enrichment → investigation → decision → response → documentation

This is clearly SOAR functionality.

The difference between the SIEM and SOAR capabilities

Although modern security platforms increasingly combine these technologies, SIEM and SOAR have different primary purposes.

Capability	SIEM	SOAR
Collect security telemetry	Core function	Not the primary function
Normalize security events	Core function	Not the primary function
Search security data	Core function	Supports investigations
Detect threats	Core function	Usually responds to detections
Correlate events	Core function	Works with cases and workflows
Investigate activity	Core function	Supports response investigations
Manage incidents	Supports investigation	Core function
Build playbooks	Not a primary function	Core function
Automate response	Limited/indirect	Core function
Orchestrate security tools	Limited	Core function
Execute remediation	Not the primary role	Core function

The two technologies therefore answer different questions.

SIEM asks:
“What is happening in my environment, and does the activity indicate a threat?”

SOAR asks:
“What should we do about this security event, and which parts of the response can be automated?”

Google SecOps brings both questions into the same operational environment.

What makes Google SecOps more than a traditional SIEM

Calling Google SecOps a SIEM is technically correct, but it does not describe the entire platform.

A traditional SIEM-centered architecture often looks like:

Log sources → SIEM → detection → alert → analyst

A security operations platform can extend this process:

Security telemetry → detection → investigation → case → automated response → remediation

That additional response layer is important because security teams increasingly need to reduce the amount of repetitive manual work performed by analysts.

For example, consider a suspicious login.

The SIEM functionality can identify the unusual authentication event, correlate it with other activity, and provide the analyst with relevant security information.

The SOAR functionality can then take the investigation further by enriching the event, checking associated indicators, creating a case, notifying the appropriate team, or initiating an approved response workflow.

The result is a more connected security operations process.

Google SecOps is not limited to Google Cloud

Another common misconception is that Google SecOps is primarily intended for organizations that run their infrastructure on Google Cloud.

That is not an accurate way to understand the platform.

Security operations environments are normally heterogeneous. An organization may have infrastructure spread across multiple cloud providers, on-premises data centers, endpoints, SaaS applications, identity platforms, network devices, and security products from different vendors.

Google SecOps is designed to work with security telemetry from these different environments.

This is significant because the SIEM function is concerned with analyzing an organization’s security data rather than simply monitoring one cloud provider.

The same principle applies to SOAR. Response automation can involve multiple security and IT technologies rather than being restricted to a single vendor’s ecosystem.

Where threat intelligence fits

Another reason the question “SIEM or SOAR?” can be misleading is that Google SecOps extends beyond these two categories.

Threat intelligence provides additional context that can help analysts understand whether an indicator, domain, IP address, file hash, or other artifact has security significance.

This creates a broader workflow:

Security event → detection → threat intelligence → investigation → response

The practical benefit is that an analyst does not necessarily have to treat every alert as an isolated event.

Threat intelligence can provide additional context around an entity and help connect an observed event with known malicious infrastructure, campaigns, techniques, or other relevant information.

This makes threat intelligence an important layer between raw security telemetry and incident response.

Where AI fits into Google SecOps

Google SecOps also incorporates AI-assisted capabilities into security operations.

AI can assist analysts with activities such as searching security data using natural language, understanding investigations, summarizing cases, developing detections, and creating or working with response workflows.

However, the presence of AI does not change the fundamental classification of Google SecOps.

It is still a platform built around security operations, with SIEM and SOAR capabilities forming important parts of the architecture.

A useful way to think about the different layers is:

SIEM = understand the security data

Threat intelligence = add security context

SOAR = automate and coordinate response

AI = assist analysts across these activities

This model provides a clearer picture of what Google SecOps is designed to accomplish.

An important point: SIEM and SOAR do not have to be used in isolation

One interesting aspect of Google SecOps is that its SOAR capabilities can work with alerts originating from other security technologies.

This means organizations do not necessarily have to view Google SecOps as an all-or-nothing replacement for an existing security operations environment.

A possible architecture could look like:

Existing SIEM → Google SecOps SOAR → automated response

Alternatively, an organization could use:

Google SecOps SIEM → Google SecOps SOAR → response

This flexibility can be relevant during security-platform migrations.

For example, an organization might initially use Google SecOps for response automation while continuing to operate an existing SIEM. Over time, it could decide whether additional security analytics and telemetry should also move into Google SecOps.

Is Google SecOps primarily a SIEM?

Google SecOps has strong SIEM capabilities and can serve as an organization’s central security analytics and detection platform.

Its SIEM functionality covers the fundamental activities expected from a modern security information and event management system: collecting security data, normalizing it, searching it, correlating events, detecting threats, and supporting investigations.

However, describing it solely as a SIEM leaves out an important part of its functionality.

The platform also provides SOAR capabilities for managing cases, building playbooks, integrating security tools, and automating response activities.

Therefore, “SIEM” is an accurate category for Google SecOps, but it is not a complete description of the platform.

Is Google SecOps a SIEM, SOAR, or both?

The most precise answer is:

Google SecOps is a unified security operations platform that combines SIEM and SOAR capabilities.

The SIEM side focuses on collecting and analyzing security telemetry, detecting threats, and supporting investigations.

The SOAR side focuses on case management, playbooks, orchestration, integrations, and automated response.

Around these core capabilities are additional functions such as threat intelligence and AI-assisted security operations.

The deeper point is that the distinction between SIEM and SOAR is becoming less rigid in modern security operations.

A SIEM that only generates alerts still leaves security analysts with substantial manual work. A SOAR platform without strong detection and investigation capabilities has less context with which to automate meaningful responses.

Google SecOps connects these stages:

Collect → detect → investigate → understand → respond → remediate

That is why calling Google SecOps only a SIEM or only a SOAR gives an incomplete picture.

The better description is a unified security operations platform with integrated SIEM and SOAR capabilities.

If you have encountered both Google Chronicle and Google Security Operations (Google SecOps), you may wonder whether they are two separate cybersecurity products or simply different names for the same platform.

The short answer is: Google Chronicle evolved into Google SecOps.

Google Security Operations is the current name for the security-operations platform that was previously known as Chronicle Security Operations. The change was primarily a product and brand transition rather than Google abandoning Chronicle and replacing it with an unrelated security platform.

However, the terminology can still be confusing because the word Chronicle continues to appear in parts of the platform’s technical ecosystem. Security professionals may therefore encounter “Chronicle,” “Google SecOps,” “Google SecOps SIEM,” “Google SecOps SOAR,” and “Chronicle API” while working with what is essentially the same broader security-operations ecosystem.

Understanding that history makes the terminology much easier to follow.

What was Google Chronicle?

Chronicle began as Google’s security analytics platform, with a strong focus on helping security teams collect, search, analyze, and investigate large volumes of security telemetry.

The idea behind Chronicle was different from the traditional approach of treating security logs primarily as an expensive archive. Google’s infrastructure allowed security telemetry to be retained and searched at very large scale, giving analysts the ability to investigate activity across an organization’s environment.

Over time, Chronicle developed into much more than a security analytics product.

Google added capabilities around detection, investigation, threat intelligence, automation, and security orchestration. The platform therefore gradually moved from being primarily associated with SIEM functionality toward becoming a broader security-operations environment.

That evolution eventually led to the Google SecOps name.

What is Google SecOps?

Google SecOps is Google’s cloud-based security operations platform.

It brings together capabilities that security teams need to move through the threat-detection and incident-response lifecycle.

At a high level, the platform can be thought of as covering four connected activities:

• Collecting security data from different sources
• Detecting potentially malicious activity
• Investigating alerts and related events
• Responding to threats through workflows and automation

This is important because a modern security operations center rarely works with a SIEM in isolation.

An analyst might begin with an alert, search historical activity, investigate the affected user or device, examine related indicators, enrich the investigation with threat intelligence, create or update a case, and then initiate a response workflow.

Google SecOps is designed to bring these activities into a more connected operational experience.

So, is Chronicle the same as Google SecOps?

For most practical purposes, Chronicle and Google SecOps refer to the same product lineage, not two competing products.

The terminology depends on when and where you encountered it.

If someone says they worked with “Google Chronicle,” they may be referring to the security platform under its previous branding.

If someone says they work with “Google SecOps,” they are generally referring to the platform under its current branding.

This is particularly important when reading older cybersecurity job descriptions, implementation documents, training material, or internal security documentation. A document written before the rebranding may consistently use “Chronicle” even though the technology it describes is now presented as Google SecOps.

The distinction is therefore largely historical and contextual.

Why does the word Chronicle still appear?

This is one of the reasons the rebranding can be confusing.

Changing a product’s marketing name does not necessarily mean every technical identifier associated with the product changes at the same time.

The Chronicle name continues to appear in technical areas of the Google SecOps ecosystem, including API terminology and certain integrations.

This creates an unusual situation in which a security engineer can work inside Google SecOps while simultaneously encountering technical references to Chronicle.

That does not necessarily mean there are two separate products.

It is similar to how a company can rename a product while retaining existing technical infrastructure, APIs, namespaces, documentation structures, or integration names built around the previous identity.

For someone learning the platform, this is an important distinction: product branding and technical naming are not always identical.

What happened to Chronicle SIEM?

Chronicle SIEM became Google SecOps SIEM.

The SIEM portion of the platform is responsible for security analytics activities such as collecting and processing telemetry, searching events, identifying suspicious behavior, creating detections, and supporting investigations.

One particularly important concept is the Unified Data Model, commonly referred to as UDM.

Security environments generate telemetry from many different technologies. Firewalls, endpoints, identity systems, cloud services, applications, network devices, and other security controls can all produce information in different formats.

A common data model gives security analysts and detection engineers a consistent structure with which to work.

This matters because detection logic becomes less dependent on the individual formatting quirks of every security product sending data into the platform.

What happened to Chronicle SOAR?

Chronicle SOAR became Google SecOps SOAR.

SOAR stands for Security Orchestration, Automation and Response.

While SIEM functionality is heavily concerned with finding and investigating suspicious activity, SOAR is focused on coordinating what happens in response.

For example, a security team might have a workflow that performs several actions after a particular type of alert:

• Gather additional information about the affected account
• Enrich an indicator with available intelligence
• Open or update a case
• Notify an analyst
• Request approval for a response action
• Perform a predefined containment step
• Record the actions taken during the investigation

The exact workflow depends on an organization’s environment and security policies.

The important point is that Google SecOps incorporates both the analytical and response sides of security operations, rather than being simply another name for a traditional SIEM.

Chronicle was more than just a SIEM

This is perhaps the biggest misconception caused by the old name.

When people hear “Chronicle,” they often associate it exclusively with SIEM.

That made sense historically because Chronicle became well known for security analytics and large-scale telemetry search.

But the platform expanded considerably.

The broader Google SecOps environment combines security analytics with capabilities for investigation, case management, threat intelligence, orchestration, and automated response.

This is why describing Google SecOps simply as “Google’s SIEM” can be incomplete.

A more accurate description is that Google SecOps is a security operations platform that includes SIEM capabilities.

Google Chronicle vs Google SecOps: the practical difference

For someone evaluating the terminology, the following distinction is useful:

Term	Practical meaning
Google Chronicle	Former branding associated with Google’s security-operations technology
Chronicle Security Operations	Previous name for the broader security-operations platform
Google Security Operations	Current name of the platform
Google SecOps	Short form of Google Security Operations
Chronicle SIEM	Previous name associated with the SIEM component
Google SecOps SIEM	Current name of the SIEM capability
Chronicle SOAR	Previous name associated with the SOAR component
Google SecOps SOAR	Current name of the SOAR capability
Chronicle API	Technical terminology that continues to appear within the platform ecosystem

The table highlights an important point: a reference to Chronicle does not automatically indicate an obsolete or separate product.

The context matters.

Does switching from Chronicle to Google SecOps require learning a completely different product?

Not necessarily.

For someone who already understands Chronicle, the transition to Google SecOps is primarily a matter of understanding the current product structure, terminology, interface, capabilities, and newer functionality.

The underlying concepts remain highly relevant.

Someone familiar with Chronicle’s security analytics capabilities will recognize concepts surrounding:

• Security telemetry
• UDM
• Detection engineering
• Threat hunting
• Event investigation
• Security alerts
• Cases
• Threat intelligence
• SOAR
• Playbooks
• Integrations
• Automated response

What has changed is the broader way these capabilities are positioned and integrated within Google’s security portfolio.

Therefore, a security professional who lists Google Chronicle on an older résumé and another who lists Google SecOps on a newer résumé may, depending on the dates and specific technologies involved, have experience with closely related capabilities.

Why the distinction matters for cybersecurity teams

The naming issue is not merely cosmetic.

Organizations often have years of security documentation, detection rules, automation scripts, integrations, training material, and employee knowledge built around a product name.

When the product is rebranded, that historical vocabulary does not disappear overnight.

A security engineer might therefore encounter an internal document that says “Chronicle,” a current console that says “Google SecOps,” and an API reference containing “Chronicle.”

Without understanding the product’s history, this can look like three different technologies.

In reality, these names can represent different layers of the same evolving platform.

This is especially relevant when organizations migrate older integrations or automation. Technical identifiers can have much longer lifespans than marketing terminology.

Google SecOps is the name to use today

If you are writing new technical documentation, preparing training material, describing your current security stack, or discussing the platform with someone unfamiliar with its history, Google Security Operations or Google SecOps is the clearest current terminology.

“Chronicle” remains useful when discussing the product’s history or technical components that retain the Chronicle name.

A concise way to explain the relationship is:

Google Chronicle is the former identity of Google’s security-operations platform, while Google SecOps is its current product identity.

Google Chronicle and Google SecOps should not generally be treated as two separate Google security platforms.

Chronicle evolved into Google Security Operations, and the platform is now commonly called Google SecOps.

The confusing part is that the Chronicle name continues to appear in technical terminology and parts of the platform’s ecosystem. That does not necessarily indicate a separate product.

The evolution can therefore be understood as:

Chronicle → Chronicle Security Operations → Google Security Operations → Google SecOps

At the capability level, the platform also evolved from a product strongly associated with security analytics and SIEM into a broader environment covering SIEM, SOAR, threat intelligence, investigation, case management, and security response automation.

So, if you encounter an older article discussing Chronicle and a newer document discussing Google SecOps, you should not automatically assume they are describing unrelated technologies. In many cases, they are describing different stages or components of the same Google security-operations platform.

For current terminology, Google SecOps is the name to use. For historical or technical context, Chronicle remains a relevant term.
:::{“fallbackMarkdown”:””,”reference”:{“matched_text”:” “,”prefix”:null,”start_idx”:12621,”end_idx”:12621,”safe_urls”:[],”refs”:[],”alt”:””,”prompt_text”:null,”type”:”sources_footnote”,”sources”:[],”has_images”:false},”showLoginRequiredCard”:false}

Bindplane is primarily used in Google Security Operations (Google SecOps) as a telemetry collection and management layer that gets security data from an organization’s infrastructure into the security platform.

That description sounds simple, but it misses an important part of Bindplane’s role. It is not merely a tool that forwards logs from servers and devices. It can act as the controlled pipeline between an organization’s raw telemetry and the data that Google SecOps ultimately uses for detection, investigation, and threat hunting.

In practical terms, Bindplane helps organizations collect, process, standardize, filter, route, and monitor telemetry before it becomes part of their Google SecOps environment.

This becomes particularly useful when an organization has security data spread across on-premises infrastructure, cloud workloads, endpoints, applications, network devices, and other systems.

Where Bindplane Fits Into Google SecOps

A useful way to visualize the relationship is:

Data sources → Bindplane → processed telemetry → Google SecOps → security analysis

Google SecOps is the security analytics platform. Bindplane sits primarily on the telemetry-ingestion side of that architecture.

For example, an organization may have Windows event logs, Linux logs, firewall events, authentication records, application telemetry, and cloud infrastructure logs. These sources do not necessarily produce information in the same format or with the same operational requirements.

Bindplane provides a common collection and processing layer that can bring these different sources into a more consistent ingestion architecture.

This separation is valuable because the SIEM does not have to be responsible for every data-collection decision occurring throughout the organization’s infrastructure.

Its Core Purpose Is Telemetry Collection

The most fundamental purpose of Bindplane is collecting telemetry from systems and sending it to Google SecOps.

Collectors can operate close to the systems producing the data. This is particularly useful for environments where infrastructure is distributed across multiple networks or locations.

Instead of requiring every individual system to communicate directly with the security platform, organizations can design collection architectures around collectors and, where appropriate, intermediate gateways.

This can make the overall ingestion environment easier to reason about.

The important distinction is that Bindplane handles the movement and preparation of telemetry, while Google SecOps provides the security-focused capabilities that make that telemetry useful.

Bindplane Helps Turn Raw Logs Into Usable Security Data

Simply getting a log into a SIEM does not necessarily mean the log is useful.

A raw event might contain the right information but still have problems such as inconsistent fields, unnecessary attributes, duplicate records, irrelevant events, or sensitive information that should not be forwarded.

This is where Bindplane becomes more than a conventional log forwarder.

Telemetry can be processed before it reaches Google SecOps. Depending on the architecture and configuration, organizations can filter information, transform records, route data differently, and perform other processing operations.

That creates an important architectural boundary:

Raw telemetry does not have to enter the SIEM exactly as it was generated.

Instead, an organization can establish rules for what should enter the security environment and in what form.

Standardization Is a Major Part of the Value

Different products rarely generate logs in exactly the same way.

A firewall, operating system, identity provider, database, and custom application may all describe similar security concepts using different fields and structures.

For security analytics, consistency matters.

Bindplane can participate in the standardization process that prepares telemetry for Google SecOps. This helps the platform recognize incoming information appropriately and apply the relevant parsing and ingestion behavior.

The significance of this is easy to underestimate.

A security team might successfully collect millions of events, but if those events are poorly identified or inconsistently structured, the resulting security visibility can be much less useful than the raw event count suggests.

Bindplane therefore helps bridge the gap between:

“The organization has logs”

and

“The security platform can understand and use those logs.”

It Provides Centralized Management for Collectors

Another important use of Bindplane appears when the number of collectors grows.

Managing a single telemetry collector is relatively straightforward. Managing a large distributed fleet is a different problem.

Without centralized management, administrators may end up maintaining configurations separately across numerous systems. Over time, small differences can appear between collectors. One system may have a newer configuration, another may use different processing rules, and another may have an incorrectly configured destination.

Bindplane provides centralized management for collectors, allowing teams to treat telemetry collection as a managed fleet rather than as a collection of unrelated installations.

This is particularly useful for organizations operating hybrid environments.

The collector infrastructure can become something that security and infrastructure teams can monitor, configure, and maintain systematically.

Bindplane Can Help Control What Reaches the SIEM

One of the most useful ways to think about Bindplane is as a policy enforcement point for telemetry.

Not every event produced by an infrastructure component is necessarily valuable to a security analyst.

A system may generate enormous amounts of routine operational information while only a fraction of that information has meaningful security value.

Sending everything upstream can create unnecessary ingestion, storage, processing, and investigation overhead.

With processing at the collection layer, organizations can make decisions about telemetry before it enters Google SecOps.

For example, a pipeline can potentially remove irrelevant information, reduce duplication, transform fields, or route different categories of data to different destinations.

This creates a more deliberate approach to security-data management.

Instead of asking only:

“Can we collect this?”

security teams can also ask:

“What exactly should we collect, what should we change, and where should it go?”

That is a much more mature telemetry strategy.

Data Reduction Can Be Important in Large Environments

Large organizations often face a counterintuitive problem: having too much security data can be almost as difficult as having too little.

Excessive telemetry can make it harder to identify meaningful events, consume unnecessary resources, and complicate operational management.

Bindplane can be used as part of a data-reduction strategy by processing telemetry before it reaches the security analytics environment.

The objective should not simply be to reduce data as aggressively as possible.

The real objective is to reduce low-value data while preserving information required for detection, investigation, compliance, and threat hunting.

That distinction is critical.

Deleting information simply because it is voluminous can create blind spots. Good telemetry engineering instead asks what information provides security value and what information can safely be removed or transformed.

Sensitive Information Can Be Addressed Before Ingestion

Security logs can sometimes contain information that was never intended to become broadly available inside a security analytics environment.

Depending on the data source, logs might contain personal information, identifiers, application details, or other sensitive fields.

Bindplane can provide processing capabilities that allow organizations to address certain sensitive information before sending telemetry onward.

This introduces another useful principle: data protection can happen before SIEM ingestion rather than only after the data has already entered the platform.

For organizations with strict data-governance requirements, that can be an important part of designing the ingestion pipeline.

The exact processing approach depends on the organization’s security, privacy, regulatory, and investigative requirements.

It Helps With Hybrid Infrastructure

Modern organizations rarely have all their infrastructure in one place.

A typical Google SecOps deployment might need visibility across data centers, employee endpoints, cloud environments, branch offices, network infrastructure, containers, and SaaS-related systems.

Bindplane’s collector-based architecture is suited to this type of distributed environment because collection can occur where the telemetry is generated while management can remain centralized.

This is especially useful when organizations do not want to redesign their entire infrastructure simply to make security telemetry available to the SIEM.

The collection layer can adapt to the existing environment instead of forcing every data source to follow an identical network architecture.

Monitoring the Pipeline Is Part of Security

There is an important operational issue that is frequently overlooked: a security platform is only as useful as the telemetry it is actually receiving.

If a firewall stops sending logs, an endpoint collector fails, or a configuration change breaks an ingestion pipeline, the resulting problem might not immediately look like a security incident.

It can instead appear as missing visibility.

That makes collector health and telemetry flow an important part of the security architecture itself.

Bindplane can provide visibility into collector operations and telemetry flow, helping teams identify problems within the collection infrastructure.

This creates an interesting feedback loop:

Google SecOps monitors the organization’s security environment, while Bindplane helps monitor part of the infrastructure that supplies Google SecOps with its security data.

That distinction matters during troubleshooting.

If a detection suddenly stops producing expected results, the problem may not necessarily be the detection rule. The relevant telemetry may have stopped arriving upstream.

Bindplane Is Not the SIEM

A common misunderstanding is treating Bindplane as though it were an alternative to Google SecOps.

It is not.

Bindplane’s primary role is associated with telemetry collection, processing, routing, and collector management.

Google SecOps is where that telemetry can ultimately support security operations such as searching, detection, investigation, threat hunting, and related analytical workflows.

The two therefore solve different parts of the security-data problem.

A simple analogy is to think of Bindplane as part of the transport and preparation system, while Google SecOps is the security-analysis environment.

The distinction becomes particularly important when planning architecture or troubleshooting ingestion.

Why Bindplane Matters More as Environments Grow

Bindplane’s value is often more apparent in a large environment than in a small one.

With a handful of data sources, administrators may be able to manage ingestion manually without much difficulty.

As the environment expands, however, the organization starts dealing with questions such as:

• How are collectors configured consistently?
• How do we process different telemetry sources?
• How do we prevent unnecessary data from reaching the SIEM?
• How do we monitor collector health?
• How do we standardize ingestion?
• How do we handle telemetry from multiple locations?
• How do we modify collection rules without manually changing every system?

These are operational questions rather than purely security-analysis questions.

Bindplane addresses this layer of the problem.

The Deeper Role of Bindplane in a Google SecOps Architecture

The most useful way to understand Bindplane is not as “software that sends logs to Google SecOps.”

It is better understood as a telemetry control layer.

It provides a place where an organization can establish how security data moves from its infrastructure into the security platform.

That means its value can extend across several areas at once:

Collection: getting telemetry from distributed systems.

Processing: modifying or filtering telemetry before ingestion.

Standardization: helping incoming data conform to the expectations of the security platform.

Routing: determining where different telemetry should go.

Governance: controlling what information is forwarded and how sensitive data is handled.

Fleet management: managing collectors from a centralized operational perspective.

Observability: monitoring whether the telemetry pipeline itself is functioning properly.

Taken together, these capabilities make Bindplane an important component of the ingestion architecture surrounding Google SecOps.

Bindplane is primarily used with Google SecOps to collect and manage security telemetry and prepare that telemetry for ingestion into the security platform.

Its importance goes beyond simply forwarding logs.

The strongest architectural benefit is the control it provides between the systems generating telemetry and the platform analyzing that telemetry. Organizations can use that layer to standardize data, filter unnecessary events, transform information, route telemetry, protect sensitive fields, manage collectors, and monitor the health of the ingestion pipeline.

The result is a more deliberate flow of security information:

Infrastructure generates telemetry → Bindplane collects and processes it → Google SecOps receives usable security data → analysts and detection systems use that data for security operations.

In that sense, Bindplane is best viewed as the managed telemetry foundation around Google SecOps, rather than as another SIEM or merely another log-forwarding agent.

Security operations teams deal with enormous amounts of data from endpoint security tools, firewalls, identity systems, email security platforms, threat intelligence feeds, cloud environments, and other security technologies. The challenge is not simply collecting this information. The bigger challenge is understanding what the data represents and connecting related pieces of information quickly enough to investigate and respond to threats.

This is where ontology plays an important role in Google SecOps SOAR.

In Google SecOps SOAR, ontology provides a structured way to represent security information, including entities, events, relationships, and their associated attributes. It helps transform information arriving from different security products into a consistent structure that analysts, investigations, and automated playbooks can work with.

Put simply, ontology gives security data meaning and structure so that it can be used for investigation and automation.

What does ontology mean in Google SecOps SOAR?

Ontology can sound like an abstract or theoretical concept, but its role in a SOAR platform is highly practical.

Security products do not necessarily describe the same object in the same way. One product might identify a source as src_ip, another might use sourceAddress, while another might simply call it IP. Similar differences occur with usernames, domains, hosts, hashes, applications, and other security objects.

Ontology provides a common model for understanding these objects.

Instead of treating every piece of information as an isolated field, Google SecOps SOAR can interpret it as a meaningful security entity.

For example, an alert might contain:

• A username associated with suspicious activity
• A source IP address
• An affected endpoint
• A malicious domain
• A file hash
• An application involved in the activity

Ontology helps identify what these values represent and how they relate to the security event.

This structure is important because the value of security information often comes from its relationships rather than from the individual values themselves.

Ontology turns raw alerts into structured security information

One of the fundamental functions of ontology is converting information contained in alerts and events into structured objects that the SOAR platform can use.

Consider a simple authentication alert.

The raw event may contain a username, source IP address, destination system, timestamp, authentication method, and event details.

Viewed as raw data, these are simply fields.

Through ontology, they can be represented as different security entities and connected to the event that generated them.

The result is a more meaningful representation of the incident.

This allows analysts and automation to work with concepts such as:

• Users
• IP addresses
• Hosts
• Domains
• Files
• Applications
• Malware indicators
• Vulnerabilities
• Other security-relevant entities

The important distinction is that the platform is no longer dealing exclusively with raw strings and fields. It is working with objects that have a defined security meaning.

The role of entities in the ontology

Entities are one of the most important components of the Google SecOps SOAR ontology.

An entity represents a security object that can be extracted from an event or alert.

For example, an IP address appearing in an alert can become an IP entity. A username can become a user entity. A domain can become a domain entity.

Once represented as an entity, the object can participate in investigations and automation.

This becomes particularly valuable when the same entity appears repeatedly.

Suppose an IP address appears in alerts from several different security products. Instead of viewing each occurrence as completely independent, analysts can investigate the IP as a security object associated with multiple observations.

The same principle applies to users, hosts, domains, file hashes, and other entities.

This creates continuity between individual alerts and the broader security environment.

Ontology creates relationships between security objects

Cybersecurity incidents rarely involve only one object.

A phishing attack could involve a user, an email address, a malicious domain, an IP address, a URL, and a compromised endpoint.

A malware incident could involve a file hash, a host, a user account, a command, an external IP address, and a malicious domain.

Ontology helps represent these relationships.

Rather than seeing the incident as a collection of unrelated values, analysts can examine how the entities are connected.

This relationship-based approach can provide additional investigative context.

For example, an analyst investigating a suspicious IP address may discover that it has appeared in several alerts involving different hosts and users. That context can be more useful than the IP address alone.

The ontology therefore helps move investigations from individual indicators toward connected security context.

Ontology and alert investigation

A major benefit of structured entities is that they can make investigations more contextual.

Without entity-based modeling, an analyst may need to manually search through alerts to determine whether a particular username, IP address, domain, or hash has appeared elsewhere.

With entities and relationships available within the SOAR environment, analysts can investigate an object and examine the security information associated with it.

This can help answer questions such as:

• Where has this entity appeared before?
• Which alerts are associated with it?
• Which users or hosts are connected to it?
• What other entities are related to it?
• Has the entity already been investigated?
• Is additional enrichment available?

The result is a more connected investigation experience.

Ontology supports alert correlation

Another important function of ontology is supporting relationships between alerts.

Security tools frequently generate multiple alerts about activity that may ultimately belong to the same incident.

For example, an identity platform might detect suspicious authentication, an endpoint platform might detect unusual process activity, and a network security product might detect communication with a suspicious IP address.

Individually, these alerts may appear unrelated.

However, if they contain common entities or related objects, those relationships can help connect them.

Ontology provides the structure needed to identify and work with these common entities.

This supports a shift from an alert-centric approach to a more incident-centric approach.

Instead of investigating every alert as a separate problem, analysts can examine the entities and relationships that connect multiple observations.

Ontology’s role in SOAR automation

Ontology becomes even more important when security operations move from investigation to automated response.

A SOAR playbook needs to know what information it is acting upon.

For example, a playbook might need to investigate an IP address, enrich a domain, analyze a file hash, retrieve information about a user, or perform an action against a host.

If the platform understands the type of entity involved, the playbook can use that information as an input for subsequent actions.

This allows automation to become more precise.

Instead of telling a playbook to process an arbitrary field containing a string, the workflow can operate on a recognized security entity.

That distinction is especially important when alerts contain many different types of information.

Ontology improves the precision of playbooks

Consider a playbook designed to enrich suspicious IP addresses with threat intelligence.

An alert may contain several IP addresses, including source addresses, destination addresses, internal infrastructure, and other network information.

A properly structured ontology allows the automation workflow to distinguish between different entity types and apply conditions to the relevant objects.

The playbook can then perform enrichment or response actions based on the entity and its attributes.

This makes automation easier to reason about and maintain.

It also helps reduce unnecessary actions against information that does not meet the playbook’s intended criteria.

Ontology and entity selection

Entity selection is another important concept in Google SecOps SOAR.

A case may contain many entities, and not every entity should necessarily be processed by every playbook.

For example, a case could contain multiple IP addresses, users, hosts, domains, and file hashes.

A playbook might need to select only specific entities that meet certain conditions.

Ontology provides the foundation for this selection because the platform understands what each entity represents and can use its properties when determining what should happen next.

This allows workflows to become conditional rather than simply executing the same action against every piece of data.

Ontology and case management

Cases bring together information associated with a security investigation.

Because entities can appear across multiple alerts, they can provide useful context at the case level.

For example, several alerts may contain the same user account or IP address. Recognizing that common entity can help analysts understand that the alerts may be connected.

Entity information can also help prevent unnecessary repetition during automated processing.

If the same entity occurs multiple times within a case, automation does not necessarily need to perform an identical enrichment operation for every occurrence.

This can make playbooks more efficient and reduce redundant processing.

Ontology increases information gain

One of the most useful ways to understand ontology is through the concept of information gain.

Ontology does not necessarily create new security data by itself. Instead, it increases the usefulness of information that already exists by adding structure and relationships.

Imagine an alert simply reports:

User A connected to IP B.

That provides limited context.

Now imagine the security platform can associate User A with several related alerts, connect IP B with previous activity, identify the affected host, associate the activity with a domain, and expose relationships among these objects.

The original information has not necessarily changed.

What has changed is the context surrounding the information.

That additional context can help an analyst determine whether an event is isolated, part of a larger pattern, or connected to an existing investigation.

This is where ontology contributes meaningful information gain to security operations.

Why accurate ontology mapping matters

The effectiveness of ontology depends heavily on how accurately incoming data is mapped.

If an IP address is incorrectly interpreted as another type of object, automation may not behave as expected.

If an important field is not mapped to the appropriate entity, analysts may lose valuable context.

Poor ontology configuration can therefore affect:

• Alert correlation
• Entity enrichment
• Investigation workflows
• Case management
• Threat hunting
• Playbook execution
• Automated response

For this reason, ontology should not be treated as merely a visual configuration feature.

It is part of the underlying data architecture of a SOAR implementation.

Ontology and security automation at scale

The value of ontology becomes increasingly apparent as a SOC grows.

A small environment may allow analysts to manually connect information across alerts. In a large environment with thousands of alerts and numerous security integrations, manual correlation becomes increasingly difficult.

A structured ontology allows the platform to handle security information in a more consistent way.

It provides a common foundation across different integrations and helps automation understand the objects being processed.

This consistency is particularly important when organizations use multiple security products from different vendors.

Best practices for using ontology in Google SecOps SOAR

Organizations implementing Google SecOps SOAR should approach ontology as part of their broader security engineering strategy.

Start by identifying the most important data sources and the entities they produce.

Validate how fields from those sources are mapped into the ontology.

Test mappings with representative alerts rather than assuming that an integration is producing the expected entities.

Review how those entities appear during investigations and cases.

Finally, test the playbooks that depend on those entities. A mapping that appears correct at the ingestion stage may still produce unexpected results when used by an automation workflow.

Regular validation is especially important when integrations, alert formats, or internal security processes change.

The bigger picture

Ontology sits at an important point in the Google SecOps SOAR architecture.

Security integrations bring information into the platform. Ontology provides a structured model for that information. Entities represent the important security objects. Relationships connect those objects. Cases provide an investigation context, while playbooks use structured information to perform automated actions.

This makes ontology more than a technical abstraction.

It is one of the mechanisms that allows a SOAR platform to move from simply receiving security alerts to understanding and acting on the information contained in those alerts.

The primary function of ontology in Google SecOps SOAR is to provide a structured representation of security information so that alerts, entities, relationships, investigations, and automated workflows can work together.

It helps the platform understand whether a value represents an IP address, user, host, domain, file, application, or another security object. It also provides the relationships that allow those objects to be connected across alerts and cases.

For security analysts, this can mean richer investigative context.

For automation engineers, it provides structured inputs for playbooks.

For SOC teams, it creates a foundation for correlating security information and turning isolated observations into connected security intelligence.

In simple terms:

Connectors bring security data into Google SecOps SOAR. Ontology gives that data structure and meaning. Entities provide reusable security context. Relationships connect the context. Playbooks use it to automate investigation and response.

That is the core function of ontology—and why it is an important part of building effective security operations automation.

Security operations teams work with enormous amounts of telemetry every day. Google SecOps provides structured search capabilities that help analysts investigate security events across different data sources.

In many investigations, analysts can rely on the Unified Data Model (UDM) to search normalized security data. However, there are situations where the information an analyst needs may exist only in the original log.

This is where Raw Log Search in Google SecOps becomes particularly useful.

Raw Log Search allows security analysts to examine the original log data and search for information that may not be available through normalized UDM fields. It can be valuable for threat hunting, incident investigation, troubleshooting parsing issues, and validating what a security product actually reported.

What is Raw Log Search in Google SecOps?

Google SecOps processes incoming security logs and converts relevant information into a structured format known as the Unified Data Model.

UDM makes security investigations easier because similar information from different products can be represented using standardized fields.

For example, an IP address, hostname, username, or network connection can be searched using structured fields rather than searching the entire text of a log.

However, not every piece of information from an original log is necessarily available as a UDM field.

A vendor-specific attribute, command-line argument, filename, registry value, application message, or other piece of text may remain visible only in the original log.

Raw Log Search allows an analyst to search that original information.

In simple terms:

UDM Search: Search structured security information.

Raw Log Search: Search the original log message.

Both approaches are useful, but they serve different purposes.

When should you use Raw Log Search?

Raw Log Search is particularly helpful when you know or suspect that a specific piece of information exists in the original telemetry.

Common examples include:

• Usernames
• Filenames
• Command-line arguments
• Registry keys
• Domains
• URLs
• IP addresses
• Hashes
• Vendor-specific fields
• Application messages
• HTTP-related information
• Data from logs that have not been parsed correctly

For example, imagine that an endpoint log contains a suspicious command-line argument, but you cannot find that value in the expected UDM field.

Instead of assuming that the information was not collected, you can search the raw logs.

This helps answer an important investigation question:

Was the information never ingested, or was it ingested but not normalized into the expected UDM field?

That distinction can be extremely useful during security investigations.

How to perform a basic raw-log search

In the Google SecOps investigation interface, you can use the raw search syntax to look for a specific string.

A basic query looks like this:

raw = "example.com"

This searches the available raw log data for the specified value.

You can replace the example with an investigation artifact such as a hostname, domain, username, filename, IP address, or other distinctive value.

For example:

raw = "suspicious-domain.com"

Or:

raw = "powershell.exe"

The results allow the analyst to examine the original log information associated with the search term.

The most effective searches usually start with a distinctive artifact rather than a very generic keyword.

Searching for something highly specific can reduce noise and make the investigation easier to follow.

Searching raw logs with regular expressions

Sometimes you are not looking for one exact value.

You may instead want to identify a pattern.

Google SecOps supports regular expressions for raw-log searches.

For example:

raw = /AB*C/

Regular expressions can be useful when several log entries share a recognizable structure but do not contain exactly the same text.

They can help with investigations involving patterns in hostnames, filenames, identifiers, application messages, or other log content.

However, regular expressions should be used carefully. An overly broad pattern can return a large number of unrelated results and make an investigation unnecessarily difficult.

A good approach is to begin with a relatively specific pattern and expand it only when necessary.

Searching unparsed logs

One of the most useful applications of Raw Log Search is investigating logs that have not been successfully parsed.

When a log is properly parsed, important information can be represented as structured UDM fields.

When parsing fails, however, the original data may still be present even though the expected structured event is unavailable.

You can use a raw-log query together with the parsing status to investigate this situation.

For example:

raw = /.+/ parsed = false

This can help identify raw logs that have not been parsed.

You can then investigate whether the affected logs are coming from a particular security product or log source.

This is particularly valuable for security engineering teams because an apparent lack of searchable information does not always mean that the underlying telemetry is missing.

The information may simply not have been normalized.

Filtering raw logs by log source

Large environments can generate an enormous amount of security telemetry.

A search for a common term across every log source may produce too many results.

Filtering the investigation by log source can make the search much more useful.

For example:

raw = "failed login" log_source IN ["OKTA"]

The exact log-source name depends on the telemetry configured in your Google SecOps environment.

Source filtering is especially useful when the same keyword can occur in multiple products.

For example, the phrase “authentication failure” could appear in identity-provider logs, endpoint logs, VPN logs, operating-system logs, and application logs.

Restricting the search to the relevant source helps analysts focus on the evidence that matters to the investigation.

Raw Logs vs UDM Search

Raw Log Search and UDM Search should not be viewed as competing methods.

They complement each other.

UDM Search is generally more appropriate when the information you need is already represented in a structured field.

For example:

principal.ip = "192.0.2.10"

A structured query provides a precise way to search a known field.

Raw Log Search becomes more useful when you need to investigate the original message itself.

Consider a security event containing a command line.

The command may be present in the original endpoint log but not available in the UDM field you expected.

A raw search can help determine whether the command-line information exists in the original telemetry.

This creates a useful investigation workflow:

Start with UDM → Identify a gap → Search the raw log → Compare the results → Continue the investigation.

Investigating parsing and normalization gaps

Raw Log Search can also help security teams improve their telemetry quality.

Suppose an analyst expects to find a particular value in a UDM field but receives no results.

There are several possibilities.

The value may not have been generated by the source system. The log may not have been ingested. The information may exist in a different field. Or the information may exist in the raw message but have not been normalized correctly.

Raw-log investigation helps distinguish between these possibilities.

For example, suppose an endpoint generates a log containing:

User: administrator
Command: powershell.exe -enc <value>
Host: workstation-01

If the expected command-line field does not contain the PowerShell information, an analyst can search the raw log for:

raw = "powershell.exe"

If the original message appears in the results, the investigation can move toward understanding the parsing or normalization behavior.

This makes Raw Log Search useful not only to SOC analysts but also to detection engineers and security platform administrators.

Searching for suspicious indicators

Raw logs can be particularly useful during threat hunting.

An analyst may receive an indicator such as:

• A suspicious domain
• An IP address
• A file name
• A hash
• A command-line fragment
• A registry path
• A user account
• A specific application message

The analyst can search the raw telemetry for that artifact.

For example:

raw = "suspicious-domain.com"

After identifying matching entries, the analyst can examine the surrounding event information and determine which system generated the log.

The investigation can then move from the raw evidence toward related events, entities, users, hosts, and network activity.

This helps transform a simple indicator search into a broader investigation.

Narrow your searches whenever possible

One of the most common mistakes when searching raw logs is starting with an excessively broad query.

Searching for a common term such as:

raw = "error"

could potentially produce a huge number of results.

Instead, begin with a more distinctive value.

For example:

raw = "powershell.exe -enc"

or:

raw = "specific-hostname"

You can then refine the search using additional filters and a narrower investigation time range.

A focused search generally makes it easier to identify relevant activity and reduces unnecessary noise.

Understanding the investigation context

A raw-log match should not automatically be treated as evidence of malicious activity.

A string appearing in a log simply means that the value exists in the telemetry.

For example, finding:

raw = "powershell.exe"

does not by itself prove that PowerShell was used maliciously.

The analyst should examine the surrounding context.

Questions worth asking include:

• Which host generated the event?
• Which user was involved?
• When did the activity occur?
• What process generated the event?
• What command was executed?
• Was the activity expected?
• Were there related network connections?
• Did similar events occur on other systems?
• Does the activity correspond with known administrative behavior?

Raw logs provide evidence, but the surrounding context is what helps an analyst interpret that evidence correctly.

Using Raw Log Search as part of threat hunting

Threat hunting often involves searching for evidence that may not correspond to a predefined detection rule.

Raw Log Search can help hunters investigate unusual artifacts across collected telemetry.

A practical workflow is to begin with a hypothesis.

For example:

“I want to determine whether a particular command-line pattern appears in endpoint telemetry.”

The analyst can search for the pattern in raw logs and then examine matching events.

If relevant activity is found, the analyst can pivot into UDM-based investigation to identify affected assets, users, timestamps, and related events.

This combination of raw and structured searching can provide a more complete view of an investigation.

Documenting findings from raw logs

Raw-log evidence can also be valuable when documenting security investigations.

When recording findings, analysts should capture the relevant information needed to reproduce or understand the investigation.

This can include:

• The search term
• Relevant time range
• Log source
• Affected host or user
• Important raw-log content
• Associated UDM event
• Investigation findings
• Actions taken

Maintaining clear investigation notes helps other analysts understand how a conclusion was reached and makes future investigations easier.

Organizations should also apply their internal security, privacy, access-control, and data-retention requirements when handling raw security logs.

Best practices for Raw Log Search

A few practical habits can make raw-log investigations more effective.

Start specific. Search for a distinctive indicator before trying broad keywords.

Use UDM when appropriate. If the information is already available in a structured field, use UDM Search for efficient investigation.

Use raw logs to validate assumptions. When expected data is missing, check whether it exists in the original telemetry.

Filter by source. Narrowing the search to the relevant log source can significantly reduce noise.

Use an appropriate time range. Investigating the period relevant to the incident makes results easier to interpret.

Investigate context. A raw-log match is not automatically suspicious. Examine the surrounding activity.

Look for parsing gaps. If valuable information exists in raw logs but not in UDM, investigate whether parsing or normalization needs attention.

Raw Log Search is an important capability for security analysts working with Google SecOps.

UDM provides the structured foundation for efficient security investigations, while raw logs provide visibility into the original telemetry behind those events.

The two approaches work best together.

Use UDM Search when you need structured security information. Use Raw Log Search when you need to inspect the original message, investigate unparsed data, search for information that was not normalized, or determine why expected information is missing.

For threat hunters, SOC analysts, detection engineers, and security administrators, understanding this distinction can make investigations more systematic and help uncover information that might otherwise remain hidden inside the original security telemetry.