By Gray Loftin, VP of Solutions Architects, Ocient
First, what this post is not: it is not an argument to replace your SIEM. The SIEM stays where it is: the place your analysts work, your detections fire, and your alerts land. What we are describing sits underneath it: a data layer that holds far more history at full resolution than a SIEM economically can, extends what the SIEM can see when an investigation needs to reach past its hot window, and feeds normalized results back up into it. The SIEM gets a longer memory and a wider reach, not a replacement.
With that framing set: security data platforms are almost universally security-only. They ingest logs, alerts, and telemetry, and they answer security questions. That scoping feels natural until you consider the questions security teams at large institutions actually want to ask, and notice how many of them have one foot outside the security dataset.
Questions we hear that cross the boundary
These are composites of real questions raised in our conversations with financial-institution teams (we will publish validated, anonymized findings as we complete that work):
- Fraud: “This account cluster shows coordinated transaction behavior. What does their network and authentication activity look like over the same period: same devices, same source ranges, same session timing?”
- Insider risk: “Flag data-egress anomalies, but score them against HR context we already have: role changes, departure notices, access-review status.”
- Network operations and security, same table: “The same flow data drives our capacity planning and our threat hunting. Why do we pipeline it into two systems with two retention policies and two query languages?”
- Third-party risk: “Join our vendor inventory against two years of outbound traffic: which suppliers do we actually exchange data with, at what volumes, and did that change before or after the contract said it should?”
These questions aren’t exotic. All of them are joins: security telemetry on one side, business or operational data on the other. What makes them hard in practice is architectural: the security data lives in a security tool that cannot ingest a fraud ledger, and the business data lives in a warehouse that cannot hold carrier-scale flow history. The join happens in a spreadsheet, quarterly, if it happens at all.
What does it take to unify security telemetry and business data in one platform?
Three things: one copy of the data instead of parallel pipelines, a shared SQL interface so security, fraud, and operations teams can all query it, and enough scale headroom to hold telemetry at full resolution without a separate warehouse for the business tables. Split any of the three across systems and the fusion questions above fall back into a spreadsheet.
The case for a general-purpose layer underneath
Our position is that the layer holding your highest-volume security telemetry should be a general-purpose analytics platform, not a security appliance. The consequences are practical:
- One copy, many workloads. Flow and DNS history ingested once serves the SOC, the fraud team, and network operations. The alternative is parallel pipelines with divergent retention and fidelity, and the cross-domain questions above fall into the gap between them.
- Standard SQL as the interface. When the security dataset is queryable in ANSI SQL, usage is no longer limited to people who know a proprietary query language. Fraud analysts, data scientists, and BI tools arrive with their existing skills. The reverse also holds: detection engineers get window functions, joins, and the whole relational toolkit instead of a DSL’s subset.
- Business context enriches detection, not just triage. A data-egress alert scored with knowledge of role change and departure date is a different-quality signal than the same alert scored on bytes alone. Enrichment at query time, against tables that live in the same platform, is a join, not an integration project.
- Deployment follows the data’s sensitivity. The moment business data (customer accounts, HR context, transaction ledgers) joins the security dataset, the question of where that combined dataset runs and who can reach it stops being a footnote. This is where much of the current platform market exits the conversation for a regulated institution, because the prevailing security-analytics architectures are cloud-only by design. Depending on who is asking, the requirement gets called data sovereignty, third-party risk, cloud concentration risk, or AI data governance, but underneath the different labels it is one requirement: the fused dataset has to run on infrastructure the institution controls. OcientAIQ is hardware- and model-agnostic and deploys inside the institution’s own data centers, private cloud, or air-gapped environment, rather than asking the institution to bring its data to us. Everything that runs against the fused data runs on infrastructure they already own, with full visibility and traceability, which is what satisfies each of those framings at once.
- The economics follow the consolidation. We lead with capability because that is how the institutions we talk to evaluate: a step-change in what their teams can ask is worth paying for; a discount on the status quo is not. But the consolidation effect is real (one platform, one copy of the data, one skill set instead of parallel stacks), and because OcientAIQ is priced on fixed capacity rather than metered per query, running the fusion joins above repeatedly does not generate a new invoice line each time.
What this looks like concretely
A real-life example from the pattern we deploy: security telemetry (flows, DNS, authentication events) and business reference data (customer accounts, vendor inventory, HR context) as tables in one petabyte-scale platform, sharing entity keys.
Correlate authentication logs with transaction data to investigate coordinated fraud
By joining authentication events, transaction records, and network flow data in one query, on shared entity keys like account ID, device ID, and session ID, instead of exporting from three systems and reconciling by hand. The investigation becomes a three-way join over months of history, returning interactively, illustrated below:
SELECT t.account_id, t.amount, t.txn_time,
a.device_id, a.auth_method, a.auth_time,
f.src_ip, f.dst_ip, f.bytes_out
FROM transactions t
JOIN auth_events a ON t.account_id = a.account_id
JOIN network_flows f ON a.device_id = f.device_id
WHERE t.txn_time BETWEEN a.auth_time AND a.auth_time + INTERVAL '10' MINUTE
AND t.account_id IN (/* flagged cluster */); Combine vendor and third-party risk data with outbound network traffic
As a GROUP BY over the flow table joined to the vendor inventory table on IP range or hostname, run across however much flow history you’ve retained. The result is a per-vendor summary of connection volume and direction, so the security team can flag any vendor whose traffic pattern shifted before or after a contract was signed.
Analysts can iterate at conversation speed on both questions, because at that point it is just SQL against data that never left the building. That speed depends on one more property: Joining business tables against security telemetry only works if the platform holds the security telemetry at full resolution in the first place, and network metadata is the workload that breaks general-purpose warehouses, at volumes reaching hundreds of millions of events per hour on large networks. OcientAIQ runs that workload and the business joins on the same platform, which is the point: security is the entry point, the workload with the most acute data-volume pain. It does not have to be the boundary. We have written separately about what changes once a team gets full-resolution history and interactive query on tap for questions that have nothing to do with security: “What petabyte scale actually unlocks.“
Curious what this looks like against your own security and business data? Contact us.