A few years ago I was in a client meeting with a senior security engineer — someone with over a decade of experience, certifications on the wall, and a title that put them in charge of guiding the client's security operations.
The client asked a technical question about their SIEM configuration. Something specific — how a particular data source was being normalized, why certain events weren't triggering rules.
The engineer's answer: "I'm just a security engineer. I don't do that."
I've thought about that moment a lot since then. Not because the engineer was incompetent — they weren't. But because that answer revealed something real about how the industry has defined what a security engineer is supposed to know. And what they're allowed not to know.
· · ·
The blue team knowledge problem
Before going further: this article is not about red teams. Red teams have their own issues — but on the spectrum of technical depth, the offensive side of security has historically demanded more. You can't fake your way through a penetration test the same way you can fade into the background of a SOC.
What I want to talk about is the blue team — and specifically, the detection and response side of security operations. The people running SIEMs, writing detection rules, triaging alerts, and advising clients on what their telemetry means.
The career path that leads to this role has a problem: there isn't one.
The security engineers who understand SIEMs best are the ones who arrived there after years of working in networking, then firewalls, then endpoint security, then log analysis. Each layer built intuition for the previous one. They understand why a rule fires because they understand what the underlying event means — because they've seen that traffic at the packet level.
But that path is long and increasingly rare. Today, many blue team engineers arrive at a SIEM without having spent serious time with any of the layers beneath it. No networking. No firewall policy work. No EDR tuning. No antispam configuration. They were hired as security analysts, trained on the tool, and handed a queue.
The result is engineers who treat the SIEM as a black box — inputs go in, alerts come out, and the space between is someone else's problem.
This isn't a personal failure. It's a structural one. The industry scaled faster than it could train the people filling the roles. And the tools adapted to that reality — or tried to.
· · ·
Where Google SecOps came from
Google Chronicle — the technology that became Google SecOps — was not born inside a security operations center. It was born inside Alphabet, built by people whose mental model of a user was a software engineer with API access, not an analyst working a twelve-hour shift.
That origin matters. The product reflects the assumptions of its creators. And the assumption baked into Google SecOps, from the beginning, was that serious users would interact with the API.
The GUI was the simplified version. The real power was always one layer down — in the Python SDK, in the REST endpoints, in the query language that most analysts never learn to write from scratch.
This is not unusual in enterprise software. What makes it notable in a SIEM is the specific mismatch: security operations is one of the few domains where the primary users are almost universally non-developers.
Splunk built its dominance partly by understanding this. The SPL query language is learnable by analysts who have never written a line of Python. The search bar is front and center. The GUI exposes most of what the platform can do.
Chronicle's GUI was, for a long time, an afterthought. The API was the product. The UI was a window into it.
· · ·
A basic example of a non-basic problem
Let me give you a concrete example — one that isn't exotic or edge-case. One that comes up in normal, everyday security operations work.
How many detection rules do you have in your Chronicle instance? How many are currently active? How many have alerting disabled? Which ones haven't triggered in the last 90 days?
These are not advanced questions. They are the first questions any auditor, any compliance review, any quarterly security report will ask. They are baseline operational hygiene.
In the Chronicle UI, you cannot answer them with a single action.
You can view the rules list. You can click into individual rules. But there is no export button, no filter by alerting status, no summary view that shows you the state of your detection coverage at a glance.
To get that information, you write a Python script against the API. You call list_rules(). You call list_rule_deployments(). You join the results. You format the output. You have your answer.
That workflow is fine if you're a developer. It is a real barrier if you're a security analyst who has spent their career in GUIs.
And this is not an isolated gap. The SIEM is central to almost every security audit. Auditors want to know what log sources are ingested, at what volume, from how many hosts. They want rule coverage mapped to threat frameworks. They want evidence that the detections are actually running and alerting.
All of that information exists in Chronicle. Most of it requires the API to extract.
· · ·
The gap nobody designed
Here is the hypothesis I keep coming back to: nobody thought about the other side.
The engineers who built Google SecOps were solving an infrastructure problem — how do you ingest and query petabytes of security telemetry at speed? They solved it well. The architecture is genuinely impressive.
But they weren't thinking about the analyst who needs to generate a compliance report on Friday afternoon. They weren't designing for the engineer who has never written an API call and doesn't plan to start.
And on the other side: the security operations industry wasn't thinking about the tool. Training programs teach analysts to use specific UIs. Certifications test knowledge of concepts and frameworks. Almost none of them teach the underlying APIs of the platforms people actually operate.
The people who are actually getting value from the full Chronicle stack — bulk rule management, programmatic feed control, API-driven detection workflows — are a small overlap: security engineers who also know how to code, or developers who also understand detection logic.
That is a small group. And in Latin America, where the security talent pipeline is thinner and the gap between senior and junior engineers is wider, it is an even smaller one.
· · ·
Things are improving. Slowly.
To be fair: Google has been moving on this. The Chronicle UI has gotten meaningfully better over the past two years. Natural language search via Gemini is a real step toward closing the developer-analyst gap. The documentation has improved.
But the pace is slow relative to the scale of the problem. And the solutions being built by the community — including some excellent open-source projects — often replicate the same assumption: that the user is comfortable running Python scripts from a terminal.
That assumption leaves out most of the people who actually operate these systems.
The tool is not going to fix itself fast enough. The skill gap is not going to close by itself. Something has to sit in the middle.
· · ·
Why this matters
This is not a complaint about Google. Building enterprise security infrastructure is hard, and Chronicle does things no other SIEM on the market does at scale.
This is a structural observation about an industry that is still figuring out who its practitioners are — and a product that was built before that question was fully answered.
The engineer who said "I'm just a security engineer" wasn't making an excuse. They were telling the truth as the industry had defined it. The problem is that the definition is too narrow for the tools we're now asking people to operate.
I create a skill for claude code to fill this gap. : https://github.com/gromerosec/google-secops-claude-skill
— gromero-sec | Detection Engineering | https://github.com/gromerosec/google-secops-claude-skill
