Every security leader running more than one cloud eventually hits the same wall. 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've watched that instinct fail enough times to name the pattern. You are not missing a tool. 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.
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 conceptually the same shape: 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 pay 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 rather than a purchase. Any analytics engine that reads OCSF becomes a pane of glass over the same normalized truth: Athena, OpenSearch, your existing SIEM, a notebook.
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 readers of your data. That's the right power dynamic for a security org that intends to be around for a while.
Sequence it in five stages
Nobody should hear "standardize on OCSF" and go blow up their stack on a Friday. This is a roadmap, and it rewards staging. Here's 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 is audit posture, not just operational tidiness. 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.
Ask one question in the next architecture review
The next time someone walks in 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," you don't have a tooling problem you can buy your way out of. You have a normalization project you've been avoiding. 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.