At Soeldner Consult, we have been part of building up many landing zones and app modernizations in the Google Cloud in the last few years.
Besides the functionality of the applications, having good security operations process in place is a fundamental pillar for the cloud. In the last years, Google also did tremendous investments in security – as with Chronicle as a SIEM/SOAR tool
Chronicle is now fully absorbed into Google Cloud, transitioning from an independent Alphabet cybersecurity startup into the cornerstone of Google’s enterprise security portfolio. Today, the platform has evolved and rebranded into Google Security Operations (Google SecOps).
When comparing modern security operations platforms, Google Security Operations offers a disruptive, modern architecture that addresses the two biggest pain points of its traditional competitors: scaling costs and search speed:
- Google Security Operations eliminates the industry’s dreaded „data tax“ by decoupling ingestion volume from licensing costs. Built on Google’s global search infrastructure, it allows security teams to analyze petabytes of historical logs instantly at a predictable, flat rate. Enhanced by native Mandiant threat intelligence and Google Gemini AI, it focuses on hyper-fast detection and automated response without forcing companies to filter out data just to save money.
- Microsoft Sentinel offers strong integration for Azure-heavy environments, but its consumption-based pricing model can lead to unpredictable, skyrocketing monthly bills as log volumes grow.
- Splunk remains powerful for legacy customization, but it is notoriously resource-heavy, expensive to scale, and demands significant engineering overhead just to keep the platform running.
The Verdict: While Sentinel ties you to a specific cloud and Splunk drains budgets with data management overhead, Google Security Operations delivers unlimited, petabyte-scale analytics and world-class threat hunting at a fraction of the total cost of ownership.
In order to motivate Google SecOps let’s begin with a small scenario:
Monday morning, 8:00 AM. A SOC analyst opens his laptop. Over 600 new alerts have been piling up since Friday evening. No major incident was reported over the weekend and yet he’s now working through hundreds of notifications. Firewall alerts, login anomalies, IDS hits, cloud events. Everything looks slightly suspicious, but nothing looks clearly malicious.
This is not an edge case. This is everyday life for a lot of Analyst in Security Operations Centers.
The problem isn’t too many attacks
When SOC teams are overwhelmed, it’s rarely because too many real threats are coming in. The problem is the noise. The majority of alerts that land in a SOC every day are false positives. Notifications that were technically triggered correctly, but don’t represent an actual threat. A user failing to log in four times. A monitoring script that detects unusual network behavior. An automated deployment job running at night that happens to match a detection signature.
The result is that analysts spend a big chunk of their day investigating things that turn out to be nothing. And somewhere in between, the real incidents are buried.
The official termin in the industry is Alert Fatigue — and it’s more common than most organizations would like to admit. It’s the point where an analyst has worked through so many meaningless alerts, that they start losing recognition and focus on the ones that actually matter.
Multi tools, Multi logins, Multi logs no shared context
What makes this worse is that in most enterprise environments, the security tooling landscape has grown over years mostly piece by piece. A SIEM here, an EDR solution there, firewall logs in a separate console, cloud events somewhere in the GCP; AWS or Azure interface, and a ticketing system on top of that.
In customer projects, we’ve seen setups where analysts were switching between more than eight different tools every single day. Each with its own login, its own interface, its own logic. No shared context between them.
What does that look in practice:
An alert flags a suspicious IP. To find out if it’s relevant, the analyst checks a second tool for the host behind it, a third tool for known vulnerabilities on that host, and a fourth tool to see if the user on that system has shown unusual behavior recently. Four manual steps for only a single first assessment. Repeated for every alert in the queue.
The issue isn’t just the time this takes. Working across multiple tabs under time pressure increases the chance of missing details that could point to an IoC.
In security those are exactly the details that matter. Not because the analyst isn’t doing their job right, but because the setup he is working with makes it, makes it rather uncomfortable for him than efficient.
MTTD and MTTR
Two metrics matter most in a SOC:
Mean Time to Detect (MTTD): How long it takes to identify that an attack is actually happening and Mean Time to Respond (MTTR): How long it takes to contain the incident after detection.
In a well-set-up environment, both of these can be driven down significantly. In a separated tool landscape, where analysts have to manually piece things together before they can even decide if an alert is worth escalating, MTTD and MTTR stay high by default.
That has real consequences. The longer an attacker goes undetected, the deeper they can dig in. Lateral movement, privilege escalation, data exfiltration: One of this happens instantly. It takes time. Time that a slow detection process hands over for free.
Most alerts that get lost in the noise are harmless. But not all of them. And those are the ones that count.
Why a classic SIEM doesn’t solve this
A lot of organizations have invested in SIEMs hoping to fix exactly these problems. SIEMs do their part they collect logs, normalize them to some degree, and enable rule-based detection.
But they hit their limits as environments grow. More log sources, more events, more rules to maintain. Without a unified data model, every source speaks its own language. Without a native response component, everything stays manual. And without a detection engine that continuously processes incoming data in the background, detection is always reactive – Someone has to go looking.
The result is an environment that looks secured on paper but stays slow and error-prone in practice.
Google SecOps – what matters
There are a couple of concepts important to Google Security Operations Center.
If you know the headache of dealing with logs from dozens of different vendors. Each tool speaks its own language, making cross-platform threat tracking a nightmare. Enter the Unified Data Model (UDM)—the architectural backbone of Google SecOps that is changing how security teams handle data.
What exactly is UDM? At its core, UDM is a universal translator for your security telemetry. It takes raw, unstructured logs from completely different sources—like firewalls, EDR tools, and cloud platforms—and normalizes them into a single, consistent, vendor-agnostic schema.
Why is this a game-changer? Here are the key benefits:
- The End of Manual Field Mapping: Have you ever tried to write a query looking for a source IP, only to realize that one vendor calls it src_ip, another calls it client-ip, and a third uses source-address? UDM automatically maps these disparate terms into a single, standardized field like principal.ip. This allows analysts to search effortlessly across all security tools without having to learn multiple vendor-specific terminologies.
- Zero Query Breakage & Drastically Reduced Maintenance: In traditional SIEM setups, if an external vendor updates their log format, your custom detection queries break. Because Google SecOps normalizes data directly at ingestion into the UDM, your underlying search logic and dashboards remain completely stable. This significantly reduces the maintenance overhead for your engineering team.
- Seamless Cross-Source Correlation: UDM forms the critical foundation for all downstream systems, including Google’s powerful YARA-L detection engine. Because all data speaks the exact same language, security teams can easily build complex, multi-stage correlation rules that connect the dots between an initial phishing email, an endpoint alert, and a suspicious network connection.
- Accelerated Investigations: By normalizing data, UDM empowers advanced capabilities like unified searches and rapid correlations. Analysts no longer have to manually piece together evidence from different tabs or tools; instead, they can pivot faster and see the full attack path in seconds.
In short, UDM removes the operational friction of data parsing and normalization. It lets your SOC stop wrangling messy logs and get back to what they do best: hunting threats.
Next is Gemini AI. Gemini AI accelerates UDM data analysis in Google SecOps through these core features:
- Natural Language Queries: Analysts can use everyday language to search their data, which Gemini automatically translates into the correct UDM query syntax.
- Rule and Playbook Generation: Users can instantly generate YARA-L detection rules and edit automated response playbooks using simple text prompts.
- Autonomous Alert Triage: The Triage and Investigation Agent (TIN) functions as an autonomous Tier-1 analyst by evaluating alerts, enriching them with context, and determining if they are true or false positives.
- Case Summaries and Recommendations: A dedicated Gemini widget aggregates case data to provide clear threat summaries alongside actionable suggestions to resolve the issue
Next is YARA-L: In simple terms, YARA-L acts as the core „language“ used to communicate with Google SecOps. You can think of it as the instruction manual that tells the system exactly what bad behavior to watch out for.
Its main roles in the platform are:
- Powering Searches and Dashboards: Whenever a security team searches through massive amounts of data or builds visual dashboards to monitor the network, YARA-L is the engine running behind the scenes to fetch and organize that information.
- Setting Up Security Alarms: It is used to create automated threat detection rules. You use YARA-L to instruct Google SecOps to continuously scan incoming data and trigger an alert if a specific, suspicious pattern appears.
- Connecting the Dots: Instead of just flagging isolated events, YARA-L helps the system act like a detective. It links different puzzle pieces together—such as a user logging in and then immediately performing an unusual file download—to uncover complex, multi-step attacks.
In addition, Google SecOps uses Playbooks to automate and standardize incident responses, delivering immediate business value by significantly reducing Mean Time to Respond (MTTR) and lowering operational costs.
- No-Code Automation: Security teams can easily build response workflows using a visual drag-and-drop interface without requiring custom coding.
- Instant Context & Triage: Playbooks automatically gather data from internal logs and external threat intelligence to quickly filter out noise and assess threats.
- Rapid Remediation: The platform can autonomously execute containment actions across your environment, such as blocking firewall ports, isolating endpoints, or disabling compromised accounts.
- Human-in-the-Loop: Workflows can operate fully autonomously or pause to require an analyst’s approval before executing high-impact actions.
The Business Value: By eliminating repetitive manual tasks, Playbooks drastically improve analyst efficiency, ensure consistent and error-free responses, and free up your security team to focus on high-priority threats and strategic initiatives
Summary: What actually needs to change
Based on what we’ve seen in projects, four things make the real difference:
- A unified data model
So analysts can search and correlate across everything without translating between formats. - Automatic correlation
Context needs to come to the analyst, not the other way around. - A continuous detection engine
With well-maintained rules that runs permanently in the background, not only when someone triggers it manually. - Automated response workflows
That handle the first-response steps and let analysts focus where their expertise is actually needed.
That’s the approach we took with Google SecOps. In the next parts of this series, we’ll get into the technical details.