What do you like best about Google Security Operations?
Search speed over long time ranges is the feature that reorganized how I work. I can run a UDM search across months of normalized events and get results back while the equivalent query on our previous SIEM would still be scheduling itself. That changes analyst behavior in a way that is hard to overstate. When a search over ninety days costs nothing extra and returns in seconds, people stop rationing their curiosity. I ask the second and third question during an investigation instead of deciding whether the first one was worth the wait, and the quality of our triage improved for exactly that reason.
The Unified Data Model is the part that took me longest to appreciate and now feels non-negotiable. Every log source, whether it is a firewall, an EDR agent, Workspace audit logs, or a cloud audit trail, lands as the same normalized event structure. A detection I write against principal and target fields works across sources without me caring what the raw log looked like. The first weeks were disorienting because I kept reaching for raw log field names out of habit, but once the UDM mental model clicks, writing one rule instead of five per vendor is the payoff, and it keeps paying every time we onboard a new source.
YARA-L 2.0 as the detection language deserves specific praise. Multi-event correlation is a first-class construct rather than a bolt-on, so expressing something like a login from a new geography followed by a mass file download within a window is a single readable rule, not a chain of saved searches glued together. The rule editor supports unit tests, meaning I can attach sample events that should fire and sample events that should not, and validate detection logic before it ever touches production alerting. Coming from environments where testing a rule meant deploying it and waiting, this is a genuinely better engineering workflow. The newer multi-stage queries with joins let me correlate events against aggregated statistics computed in earlier stages, which covers the risk-analytics style detections that used to require exporting data somewhere else.
Retrohunting is the capability I did not have before and now use weekly. When a fresh indicator lands, from a Mandiant report or from our own incident, I run the new detection logic backwards across the full retention window and know within minutes whether that IOC ever touched us. The before-state on other platforms was either "we only keep 30 days hot, so we cannot answer that" or a painful restore from cold storage. Here the twelve months of retention is the default, and the answer to "were we hit before we knew about this" is a query, not a project.
The economics are worth naming as a feature. Licensing is not metered per query or per gigabyte searched, so the cost model does not punish investigation. We ingest sources that we previously filtered out purely to save money on the old platform, DNS logs being the obvious example, and having them turned out to matter in two real investigations. Deciding what telemetry to keep based on security value rather than storage bills is how this was always supposed to work.
On the SOAR side, a few things earn their keep daily:
- Playbook building is drag and drop against a large integration catalog, and reusable playbook blocks mean our enrichment steps are written once and shared across playbooks
- Version control with rollback on playbooks, so an edit that breaks something at 5pm on Friday is reversible instead of an incident of its own
- Run analytics per playbook, which is how we found the enrichment step that was silently timing out and inflating our response times
- Case management sits in the same console as the SIEM data, so pivoting from an alert into the underlying events does not mean switching tools
The Gemini integration is more useful than I expected and I went in skeptical. Natural language to UDM query works well enough that junior analysts produce serviceable searches on day two instead of week three, and the generated query is shown and editable, so it teaches the syntax rather than hiding it. It also generates YARA-L rule drafts from a search I have refined, which does not replace detection engineering but removes the blank-page step. Case summaries are decent. I still edit them before anything goes to a stakeholder, but starting from a draft beats starting from a timeline of forty events.
Threat intelligence enrichment through the Mandiant and VirusTotal side of the house is quietly one of the stronger arguments for the platform. Indicators in our events come pre-scored with context I trust, and the applied intelligence prioritization does a reasonable job of surfacing the alerts where a known-bad indicator intersects our environment. Less time spent copy-pasting hashes into external lookup tabs is time that goes back into actual analysis.
Dashboards got meaningfully better over our time on the platform. The newer native dashboards run on the same YARA-L query engine as search, so a query I refined during an investigation becomes a dashboard panel without translation into a second syntax. We run a SOC overview board for the daily standup and an ingestion board for the platform owner, and both were built by analysts rather than by a reporting specialist, which tells you what the barrier to entry actually is.
Curated detections round it out. Google ships and maintains rule sets mapped against MITRE tactics, the coverage view shows where our detection logic actually lands on the matrix, and the content packs have grown noticeably over the time we have run it. I treat the curated rules as a floor rather than a ceiling, but as a floor they are solid, and the MITRE coverage snapshot is what I bring to quarterly reviews when someone asks what we can and cannot see. Review collected by and hosted on G2.com.
What do you dislike about Google Security Operations?
The learning curve is real and I would plan for it honestly rather than hope around it. Analysts arriving from Splunk or Sentinel have to unlearn the raw-log reflex and internalize UDM before they are productive, and YARA-L reads like nothing they have used before. Our ramp was roughly six weeks before the team stopped fighting the platform, and that was with the SPL-to-YARA-L transition guide, which helps and exists for a reason. My working fix was to build an internal cheat sheet of our twenty most common investigation queries and treat it as the onboarding document. New joiners copy, run, and modify from there, which shortcuts most of the syntax pain. Budget the ramp time up front and it is manageable. Pretend it is not there and the first month gets loud.
Parser coverage is the operational friction we hit most. The mainstream sources normalize cleanly, but bring in a niche appliance or an in-house application and you are writing or adjusting a custom parser, and when a vendor changes their log format upstream, fields can silently stop populating until someone notices a detection has gone quiet. The platform has been adding parser documentation and the ingestion health dashboard helps, but we still ended up writing our own YARA-L rules that alert when expected log types drop in volume, which is a workaround for monitoring the monitor. Silent degradation of a log source is the failure mode I worry about, and I would like the product to be more aggressive about surfacing it by default.
Documentation is broad but unevenly stitched together. The Chronicle-era docs, the newer SecOps docs, and the community posts describe overlapping features at different points in their evolution, and more than once I followed a documented path that no longer matched the current UI. The community forum and the release notes are actually the most reliable sources for what the product does today, which is not where documentation should live. It has been improving release by release, but the gap between how fast the platform ships and how fast the docs consolidate is still visible.
Two smaller ones. Exporting case data for reporting outside the platform is clunkier than it should be, and we ended up scripting against the API for the monthly numbers our management wants rather than getting them from the console. And while the SOAR integration catalog is large, the depth of individual integrations varies, so a few of ours needed custom actions written in the IDE where I expected the out-of-the-box connector to cover it.
Pricing deserves a flag for smaller teams. The packaging makes sense at our scale, and the predictability is genuinely a strength, but the entry point is not casual money, and a five-person security function evaluating this should size the commitment carefully against what they will actually operationalize in year one. Review collected by and hosted on G2.com.
