Every security leader running more than one cloud eventually hits the same wall. You have GuardDuty findings in one place, Defender alerts in another, a CSPM tool spitting out its own posture findings, an EDR console with its own worldview, and a SIEM that promised to unify all of it for a per-gigabyte price that now keeps you up at night. So someone proposes the obvious fix: buy another aggregator. A new pane of glass that sits on top of the other panes of glass.
I want to push back on that instinct, because I've watched it fail enough times to name the pattern. The problem you have is not that you're missing a tool. The problem is that every tool speaks a different dialect, and you keep paying vendors to translate. Dashboard sprawl is a schema problem wearing a tooling costume. And you can solve a schema problem without signing another order form.
The real mechanic: normalize the data, not the dashboards
Here's what's actually happening under the hood. A GuardDuty finding, a Defender incident, and a CSPM misconfiguration are all conceptually the same shape — there's a thing that happened, to a resource, at a time, with a severity, attributable to an actor. But each vendor names those fields differently, nests them differently, and scores severity on its own scale. When your analyst pivots from one console to another, the translation tax gets paid by a human brain at two in the morning. When you buy an aggregator, you're paying that vendor to write and maintain the same translation layer — and now you're locked into their normalization, on their roadmap, at their renewal price.
The Open Cybersecurity Schema Framework exists precisely to kill that tax. OCSF is an open, vendor-neutral standard for how a security event should be structured — a common vocabulary that a growing roster of vendors and cloud providers already emit or ingest natively. Amazon Security Lake is the AWS-native expression of the same idea: it pulls security data from across accounts and regions, normalizes it into OCSF, and lands it in Parquet on S3 that you own. The unlock isn't the console. It's that once your findings are OCSF in your own lake, the "single pane of glass" becomes a query, not a purchase. Any analytics engine that reads OCSF — Athena, OpenSearch, your existing SIEM, a notebook — becomes a pane of glass over the same normalized truth.
That is the reframe I keep coming back to: own the normalized data layer, and dashboards become interchangeable commodities on top of it. Vendors stop being the gatekeepers of your visibility and go back to being interchangeable readers of your data. That's the right power dynamic for a security org that intends to be around for a while.
A maturity roadmap, not a rip-and-replace
Nobody should hear "standardize on OCSF" and go blow up their stack on a Friday. This is a roadmap, and it rewards being staged. Here's roughly how I'd sequence it.
- Stage 0 — Inventory the dialects. List every system producing findings and how you currently consume them. You'll be unsettled by how many overlapping consoles you're paying for, and that inventory is your business case before you write a line of config.
- Stage 1 — Land one source in the lake. Stand up Security Lake, point your highest-volume native source at it, and prove you can query OCSF data you own. One source, one region, one working Athena query. That's the whole goal.
- Stage 2 — Converge the multicloud feeds. Bring in the other clouds and the third parties — many emit OCSF directly now, and the ones that don't can be mapped at ingest. The point is that the schema is the integration contract, so adding a source is a mapping exercise, not a new platform.
- Stage 3 — Move detection and reporting onto the normalized layer. Write cross-cloud detections once, against OCSF fields, instead of maintaining N near-duplicate rules per vendor dialect. Build your exec and audit views off the same lake.
- Stage 4 — Rationalize. Now — and only now — go turn off the redundant aggregation you were paying for. This is the stage where the project pays for itself, and it's the stage everyone wants to do first. Do it last, on evidence.
The discipline is in the ordering. You earn the right to cancel a tool by first proving the normalized layer covers what that tool was doing. Reverse the order and you create a visibility gap and a political fight at the same time.
Why this matters more in regulated work
I run security and DevOps for a fintech that serves more than 1,500 financial institutions, and the consolidation case there isn't just operational tidiness — it's audit posture. When an examiner or a partner's due-diligence team asks "show me how you detect lateral movement across your clouds," the worst possible answer is "well, it depends which console, let me pull up three of them." The strong answer is one query against one normalized store with a retention story you control. OCSF gives you that narrative because the data is consistent, portable, and not trapped behind a vendor's export limits. Provable beats claimed, and a single normalized lake is a lot easier to prove than a wall of dashboards.
There's also a quieter benefit: data gravity stops working against you. When your security data lives in open formats in your own object storage, swapping the analytics layer is a migration you can actually do. That optionality is worth more over a five-year horizon than any single feature on any single aggregator's roadmap.
So here's the challenge. The next time someone walks into your architecture review proposing a new tool to "finally give us one pane of glass," ask one question first: what schema is our data in, and do we own it? If the honest answer is "whatever each vendor decided," then you don't have a tooling problem you can buy your way out of. You have a normalization project you've been avoiding — and the good news is the standard already exists, the AWS-native plumbing already exists, and the only thing standing between you and a real single pane of glass is the decision to own your data instead of renting someone else's translation of it.
