NETbuilder CISO Stuart Bowell unpacks the Open Cybersecurity Schema Framework (OCSF), outlining what it is, what it’s for, and how to implement it
If you work in security operations, you’ve almost certainly heard about OCSF, the Open Cybersecurity Schema Framework. It’s backed by AWS, Splunk, CrowdStrike, Palo Alto Networks, and a long list of others, and the community now counts over 200 organizations and more than 1,100 contributors according to AWS.
The pitch is simple. Every security tool speaks its own dialect. Your firewall calls it src_ip, your EDR calls it LocalAddressIP4, your cloud logs call it something else again. OCSF gives them all one common language, so your detections, your analysts, and increasingly your AI agents only have to learn it once.
Most of the people I speak to get that. They’re sold on the why. What they’re stuck on is the how. They open the schema, see eight categories and more than 80 event classes, and quietly close the tab.
So let’s talk about the how.
First Question: Is OCSF Actually Right for You?
Before anyone writes a single mapping, it’s worth being honest about whether OCSF solves a problem you actually have. In my experience it pays off most when one or more of these is true:
- You’re changing platforms – A SIEM migration, a move to a security data lake, or running more than one SIEM. Normalizing to an open standard means you stop rebuilding parsers and detections every time the destination changes.
- You have tool sprawl – Lots of vendors, lots of formats, and analysts pivoting between consoles to piece one incident together.
- You’re looking at AI or an agentic SOC – Agents reason far better over consistent, well-structured data. Feed them five dialects and you’ll get five sets of mistakes.
- You want to own your data – Keeping your telemetry in an open format reduces lock-in to any one vendor’s data model.
And a few things to weigh up before you start:
- What you already have – If you’re happily settled on one SIEM with a mature data model like Splunk CIM or Sentinel ASIM, OCSF might be a gradual evolution rather than a big bang. That’s fine.
- Who will own it – Mappings need an owner after the project ends. If nobody has that in their job description, it’ll drift.
- Your appetite for change – This touches pipelines, detections, dashboards, and how analysts work. It’s a program, not a plugin.
The Pros and Cons, Honestly
| The Upside | The Catch |
|---|---|
|
Write a detection once and run it across every source that feeds the same class |
Mapping takes real engineering effort, and vendor log formats change under you |
|
Faster investigations, because analysts pivot on the same fields everywhere |
You’ll likely run OCSF alongside your existing data model for a while |
|
Easier SIEM migrations and multi-destination routing |
The schema evolves several times a year, so versions need managing |
|
An open, vendor-neutral format you control |
Not every field has a neat home; some data will sit in “unmapped” |
|
A solid foundation for AI-assisted triage and agentic workflows |
Packaged vendor mappings vary in depth and still need checking |
None of the cons are deal-breakers. They’re just the reason you plan this properly rather than winging it.
Don't Start With the Schema. Start With Your Detections.
This is the biggest mistake I see. Teams treat OCSF like a checklist and try to map every class to every data source. That’s boiling the ocean, and it’s how programs stall six months in with lots of normalized data that nothing actually uses.
Think of OCSF as a dictionary, not a novel. You don’t read it cover to cover. You look up the words you need.
The words you need are decided by what your SOC has to detect and investigate. So work backward:
- What threats matter most to your organization?
- Which detections and investigations cover them today, and where are the gaps?
- What data do those detections depend on?
- Which OCSF classes does that data belong in?
Do that and something useful happens. A surprisingly small number of classes turns out to cover the bulk of what your SOC cares about. That’s your starting point, and it’s a lot less daunting than 80-plus.
What to Gather Before You Start
You can do a lot of the groundwork yourself, and it’ll make any engagement faster and cheaper. Pull together:
- Your correlation rules and saved searches – This is the single most valuable thing you own. Note what data each rule uses and, ideally, which MITRE ATT&CK techniques it covers.
- A data source inventory – What you collect, how much, in what format, who owns it, and what it costs you to store.
- Your threat picture – Recent incidents, red team findings, audit actions, and regulatory drivers such as DORA or NIS2.
- Your platform roadmap – What’s changing in your SIEM, data lake, and pipeline tooling over the next 18 months or so.
- What your vendors already emit – Several major security vendors can now output OCSF natively. Check before you build.
- Retention requirements – Where raw data has to live, and for how long.
If you can put those on the table, you’re already ahead of most organizations starting this journey.
How to Start the Journey
The organizations that get this right don’t do it in one go. They do it in waves, and each wave has to prove its worth before the next one starts. At a high level, it looks like this:
- Decide. Agree why you’re doing it, where OCSF will live in your architecture (in the pipeline, the data lake, the SIEM, or all three), which version you’ll standardize on, and who owns it.
- Discover and prioritize. Use the groundwork above to pick a first wave: a handful of high-value classes and the sources that feed them.
- Design. Agree how each source maps, and how common things like users, devices, and IP addresses are represented everywhere. Consistency here is what makes correlation work later.
- Build and run side by side. Use vendor-maintained mappings where they exist, build the rest, and run OCSF alongside what you have today. Never rip and replace on day one.
- Prove it. Move your priority detections across and show they fire just as well, or better, on OCSF data. Only then retire the old way of doing things.
- Repeat and operate. Add the next wave, keep an eye on schema drift and new OCSF releases, and treat your mappings like code.
The principle running through all of it: normalized data that no detection uses isn’t progress. Every wave should end with your SOC doing something better than before.
Where NETbuilder Comes In
OCSF rarely turns up on its own. It usually shows up as part of something bigger, and that’s exactly where we spend our time.
SIEM Migrations
Moving platforms is the perfect moment to adopt OCSF, because you’re touching every pipeline and detection anyway. We help security teams plan and run migrations so the new platform starts on clean, normalized data rather than inheriting years of parser debt.
Security Data Engineering
Our engineers work hands-on with pipeline and observability platforms such as Cribl, Splunk, and CrowdStrike, which is where most OCSF normalization actually happens.
Agentic SOC
AI won’t fix bad data. Agentic workflows that gather evidence, correlate across identity, endpoint, network, and cloud, and prepare a case for an analyst only work well when the data underneath is consistent. OCSF is a big part of that foundation, and we help SOC teams move from pilot to production safely, with clear guardrails, human oversight, and audit evidence built in from day one.
We Build Capability
We also don’t believe in creating dependency. We work alongside your team and hand over the knowledge, so you own your schema, your mappings, and your detections when we’re done.
If you’ve heard about OCSF and you’re wondering where to start, or you’ve started and it’s feeling bigger than expected, let’s talk. A 30-minute conversation is usually enough to work out whether OCSF is right for you, what your first wave should look like, and what it’ll take to get there.
Learn More
Book a conversation with the NETbuilder security team. We deliver outcomes and help customers drive change, not adopt it.
