In the security tooling market, interoperability has always been painful. Every vendor has their own alert format. Your EDR speaks one schema. Your NDR speaks another. Your cloud security tool outputs something else entirely. Your SIEM ingests all of it — at the cost of a 6-month normalization project per data source.
OCSF (Open Cybersecurity Schema Framework) exists to fix this. And in 2025–2026, it's moved from promising standard to industry requirement. If your security detection tool doesn't output OCSF, enterprise SOC teams are spending real money transforming your proprietary findings before they're usable.
What OCSF Actually Is
OCSF is an open-source schema specification originally co-developed by AWS, Splunk, IBM, Palo Alto Networks, and 17 other organizations. It defines a standardized structure for security event data — with specific schemas for different event classes: authentication events, network activity, process activity, and critically for cloud security, Detection Findings (Event Class 2004).
At its core, OCSF defines a common vocabulary. Rather than one vendor calling it "severity: HIGH" and another calling it "risk_score: 8," OCSF defines a canonical `severity_id` enum (1=Informational, 2=Low, 3=Medium, 4=High, 5=Critical) that every consumer understands without transformation.
- Activity metadata: what happened, when, where, with what confidence
- Actor object: who performed the action (user, service, AI agent)
- Resource objects: what was accessed or modified
- Attack object: MITRE ATT&CK technique and tactic mapping
- Finding details: which detectors fired, with what evidence
- Analytic metadata: detection tool, rule, or model that produced the finding
Why Security Hub Changed Everything
AWS Security Hub has become the gravitational center of enterprise AWS security operations. Large organizations aggregate all their findings there — from GuardDuty, Inspector, Macie, third-party tools, and custom detectors — and use it as the single pane of glass for security posture.
In 2024, AWS adopted OCSF as the native finding format for Security Hub, replacing the older ASFF (AWS Security Finding Format) with a path toward full OCSF compatibility. This means a security detection tool that outputs OCSF can publish directly to Security Hub without custom transformation — and Security Hub findings are automatically available to Amazon Detective, EventBridge rules, and downstream SOAR platforms.
OCSF is becoming the structured data layer that AI security tools consume. If your detection tool doesn't output OCSF, your findings can't participate in automated investigation and response workflows without custom transformation.
The Transformation Tax Without OCSF
Without OCSF output, every enterprise customer pays a "transformation tax" — engineering time spent building and maintaining data pipelines to normalize your proprietary alert format into whatever their SIEM or Security Hub expects.
- Security Hub integration: custom Lambda to transform your format into ASFF/OCSF — 2-4 weeks of engineering
- Splunk ingestion: custom Technology Add-on (TA) to normalize fields — 1-3 weeks
- Cribl normalization: custom pipeline configuration — 1-2 weeks per environment
- Hunters / Stellar Cyber: custom connector — varies
- Amazon Security Lake: custom OCSF transformation — cannot use native source registration without OCSF
These aren't one-time costs. Every time your alert schema changes, every downstream transformation breaks. The maintenance burden compounds over time. Security teams evaluate vendors heavily on whether they need to maintain custom pipelines — tools with native OCSF output have a strong procurement advantage.
What Entroptics OCSF Output Looks Like
Entroptics outputs every alert as an OCSF Detection Finding (Class 2004). The structure maps naturally to the behavioral anomaly data the platform generates:
{
"class_uid": 2004,
"class_name": "Detection Finding",
"activity_id": 1,
"severity_id": 4,
"severity": "High",
"time": 1741478400000,
"metadata": {
"product": { "name": "Entroptics", "vendor_name": "Entroptics" },
"version": "1.3.0"
},
"actor": {
"user": { "name": "DataScienceRole", "type": "IAM Role" },
"idp": { "name": "AWS IAM" }
},
"resources": [{ "type": "S3 Bucket", "name": "prod-data", "uid": "arn:aws:s3:::prod-data" }],
"attacks": [{
"tactic": { "name": "Exfiltration", "uid": "TA0010" },
"technique": { "name": "Transfer Data to Cloud Account", "uid": "T1537" }
}],
"finding_info": {
"uid": "ent-alert-1741478400-abc123",
"title": "Unusual S3 access pattern: DataScienceRole",
"desc": "Role accessed 3,400 objects across 6 new prefixes at 400× baseline velocity",
"analytic": { "name": "ExfiltrationDetector + CardinalityDetector ensemble", "type": "Rule" }
}
}Every Entroptics alert includes MITRE ATT&CK technique mappings for the detectors that fired. The actor section distinguishes identity types (HUMAN, SERVICE, LAMBDA, AI_AGENT). The resources section includes the full S3 ARN context. This is what Security Hub, Splunk, and Security Lake consume natively — no transformation required.
The EventBridge Connection
Once your Entroptics findings are in OCSF and flowing through Security Hub, you unlock the EventBridge integration layer. EventBridge rules can match on OCSF finding attributes — severity, MITRE technique, actor type — and trigger automated remediation: quarantine an IAM role, invoke a Step Functions workflow, create a Jira ticket, or notify an on-call engineer via PagerDuty.
This is the "agentic SOC" architecture in practice: Entroptics detects the behavioral anomaly → OCSF finding published to Security Hub → EventBridge rule matches on severity and technique → automated playbook triggered — all without human intervention. The security analyst sees a resolved incident, not a raw alert.