Case Studies

Security data engineering case studies from MSSPs and enterprises

How SOC teams across the GCC, India and ASEAN cut SIEM costs, improved detection, controlled AI token spend and kept years of telemetry searchable with security data pipelines, detection engineering and tiered storage.

SIEM cost reductionStreaming detectionSchema driftAI observabilityFalse positive reductionTiered storageSecurity data lakeCribl migrationDataBahn migrationSplunk log collectionSIEM ingestion cost

At a glance

Eighteen engagements, eighteen measurable outcomes

Every engagement is vendor-neutral and scoped around a measurable result. Select a case study to read the challenge, approach and results.

SIEM Cost Reduction · Enterprise

~45%

less SIEM ingestion

Cutting SIEM ingestion 45% for a GCC retail bank without losing a single detection

Read case study →

Detection Engineering · MSSP

<1 min

event to alert, down from 20+ minutes

Sub-minute threat detection with in-pipeline streaming detections for an India-based MSSP

Read case study →

AI Observability · Enterprise

~55%

fewer tokens per triaged alert

Migrating an India-based MSSP from DataBahn to an open-core security data pipeline

Read case study →

DataBahn Migration · MSSP

Full audit trail

for every pipeline change, per tenant

Migrating a Singapore MSSP from DataBahn to an open-core security data pipeline

Read case study →

Splunk Log Collection · MSSP

~40%

less Splunk ingestion

Replacing Splunk log collection with an open-core security data pipeline for a Saudi MSSP

Read case study →

Splunk Log Collection · MSSP

~45%

lower Splunk Cloud ingestion

Replacing Splunk log collection with an open-core security data pipeline for an India-based MSSP

Read case study →

Splunk Log Collection · MSSP

3 SIEMs

fed from one collection layer

Replacing Splunk log collection with an open-core security data pipeline for a Singapore MSSP

Read case study →

SIEM Ingestion Cost · MSSP

~50%

lower SIEM ingestion cost per tenant

Cutting SIEM ingestion cost per tenant by 50% for a Malaysian MSSP

Read case study →

SIEM Ingestion Cost · MSSP

~40%

lower SIEM ingestion across tenants

Reducing SIEM ingestion cost 40% across the tenant base for a Singapore MSSP

Read case study →

Client names and identifying details are anonymised. These are representative engagements; figures are rounded and results vary by environment.

SIEM Cost Reduction case study

Cutting SIEM ingestion 45% for a GCC retail bank without losing a single detection

The challenge

SIEM ingestion had grown roughly 35% in a year, and the next licence tier was due at renewal. Firewall allow-traffic, verbose Windows events and DNS made up most of the volume but fed very few of the bank's active detections. The CISO needed the cost under control without weakening the evidence regulators expect.

What we did

Source-by-source value audit: mapped every field the active rules and dashboards actually use
Detection-safe filtering, field pruning and summarisation of high-volume, low-value events in a security data pipeline
Full-fidelity copy of all raw logs routed to low-cost object storage for compliance and investigations
Replayed the detection test suite before and after every change to prove nothing broke

Results

~45%reduction in daily SIEM ingestion

0detections lost, validated by rule replay

1 tierlower licence at renewal

Detection Engineering case study

Sub-minute threat detection with in-pipeline streaming detections for an India-based MSSP

The challenge

Priority detections ran as scheduled SIEM searches every 15 to 20 minutes, on top of ingestion and indexing lag. On tenants with delayed or batched ingestion, an IOC hit or a ransomware precursor could take hours to surface. Every tenant SIEM also needed its own version of each rule, so the Detection Engineering Lead was maintaining the same logic several times over.

What we did

Split the detection library into time-critical rules (IOC matches, known-bad command lines, threshold bursts, impossible travel) and long-window correlation
Ran the time-critical rules as streaming detections inside the security data pipeline, on normalised OCSF events as they arrive
Kept long-window correlation and behavioural analytics in each tenant's SIEM, with pipeline findings enriched and forwarded to SIEM and SOAR
Wrote rules once in Sigma and tested them against replayed attack data in CI before rollout to every tenant

Results

<1 minevent to alert for priority detections, from 20+ minutes

Secondsnot hours, on tenants with delayed SIEM ingestion

1 rule setfor every tenant, whatever the SIEM

AI Observability case study

AI observability and LLM token cost control for a Singapore fintech's SOC

The challenge

The company had rolled out internal LLM assistants and an AI-assisted alert triage workflow. Security had little visibility into who was sending what to the models, and token spend on triage rose in step with alert volume because full raw events, including duplicates and irrelevant fields, were passed into every prompt.

What we did

Collected AI gateway and application logs (user, model, token counts, policy decisions) through the pipeline into the SIEM and data lake
Built detections for prompt-injection patterns, sensitive-data exposure and unusual usage per user or service
Trimmed, deduplicated and summarised alert context in the pipeline before it reached the LLM
Masked PII before prompts left the environment and set per-team token budgets with alerting

Results

~55%fewer tokens per triaged alert

100%of AI gateway traffic visible to the SOC

Per teamtoken budgets with alerting

False Positive Reduction case study

Reducing false positive alerts by 60% for a UAE-based MDR provider

The challenge

Analysts were working thousands of alerts a day and most closed as benign. A small number of noisy rules generated the bulk of the queue, response SLAs were slipping on night shifts and analyst attrition was rising. The SOC Manager needed less noise without cutting coverage that customers paid for.

What we did

Analysed 90 days of closed alerts to rank rules by volume and true-positive rate
Re-engineered the noisiest rules with thresholds, context and exclusions that expire and are reviewed
Added pipeline enrichment for asset criticality, known scanners and approved change windows
Introduced alert deduplication and risk-based grouping so related signals arrive as one case

Results

~60%fewer alerts per day

~2xhigher true-positive rate

Back on SLAfor priority incidents

Tiered Storage case study

Tiered storage for 12-month log retention at a Qatar energy-sector enterprise

The challenge

Policy required at least 12 months of searchable logs plus longer archival, all kept in-country. Holding everything in the SIEM's hot storage meant constant hardware expansion and slow searches. The SIEM Engineer was spending more time managing disk than improving detections.

What we did

Defined a hot, warm and cold model: 90 days in the SIEM, 12 months searchable, multi-year archive
Routed data by retention need from the pipeline, written once in compressed open formats
Built the warm tier on in-country object storage with a fast query engine for investigations
Documented rehydration runbooks so archived data can be restored for audits and incidents

Results

~70%smaller SIEM hot storage footprint

12 monthssearchable, kept in-country

Hoursto restore archived data, not days

Schema Drift case study

Catching log schema drift before it breaks detections for an India-based MSSP

The challenge

Firmware updates and SaaS API changes altered log formats without notice: renamed fields, new nested JSON, changed timestamp formats. Parsers kept running, but key fields arrived empty, so detections silently stopped firing while dashboards still looked healthy. The SOC Manager usually found out from a customer escalation or a quarterly review, sometimes weeks later.

What we did

Baselined every source per tenant: expected fields, data types, fill rates and volume
Added drift monitoring in the pipeline that alerts on new, missing or renamed fields, type changes and spikes in parse failures or empty values
Mapped each field to the detections that depend on it, so every drift alert names the rules at risk
Quarantined unparsed events instead of dropping them and replayed them once the parser was fixed
Version-controlled parsers with sample-based tests, so one fix ships to every affected tenant

Results

Minutesto detect schema drift, previously weeks

0events lost during parser fixes

Per ruleimpact shown on every drift alert

Security Data Lake case study

A multi-tenant security data lake for a Malaysian MSSP's threat-hunting service

The challenge

Financial-services customers wanted a year or more of retention and the ability to hunt across it. Extending SIEM retention per tenant would have wiped out the margin, and retro-hunting for new indicators meant restoring archives one customer at a time.

What we did

Built a multi-tenant security data lake on ClickHouse, with all tenant data normalised to OCSF
Applied per-tenant partitioning, access control and cost attribution
Created reusable hunting queries mapped to MITRE ATT&CK and an indicator retro-hunt workflow
Kept the SIEM focused on 30 to 90 days of real-time detection

Results

12+ monthshunt-ready retention per tenant

Minutesfor a cross-tenant indicator retro-hunt

New tierof extended-retention service sold

Cribl Migration case study

Migrating a Saudi MSSP from Cribl to an open-core security data platform

The challenge

Pipeline licensing scaled with ingest volume and worker count, so every new government and banking tenant raised cost faster than contract value. Pipeline logic lived in hundreds of GUI-built routes and packs that only two engineers fully understood, and newly onboarded NCA-regulated tenants required the whole data path, control plane included, to stay inside the Kingdom.

What we did

Inventoried every Cribl source, route, pipeline and pack per tenant and ranked them by volume and by the detections they feed
Rebuilt the logic as version-controlled pipeline definitions on a self-hosted open-core security data platform in the MSSP's Riyadh data centre
Ran old and new pipelines in parallel on mirrored traffic and diffed their output event by event before each cutover
Migrated tenants in waves ordered by risk, with a documented rollback path held open for every wave

Results

~50%lower annual pipeline licence cost

0events lost across cutover waves, validated by output diff

In-Kingdomdata path and control plane, fully self-hosted

Cribl Migration case study

Migrating an India-based MSSP from Cribl to an open-core security data platform

The challenge

Rupee-priced SOC contracts left no room for a dollar-denominated, volume-based pipeline licence that grew at every renewal. CERT-In's 180-day retention requirement meant keeping full-fidelity copies of every tenant's logs in India, which made volume-based pricing more expensive still. Edge agents on customer sites also had to be replaced without a visit to each one.

What we did

Mapped every Cribl Stream pipeline and Edge fleet configuration to its tenant, source and destination
Converted parsers and reduction logic to OCSF-normalised pipelines on the open-core platform, kept in Git with sample-based tests
Replaced Edge collection with lightweight collectors pushed through the MSSP's existing remote-management tooling, with no site visits
Routed a full-fidelity copy of every tenant's raw logs to in-country object storage for 180-day retention

Results

~40%lower total pipeline cost, licence plus infrastructure

6 weeksto migrate every tenant

180 daysof raw logs retained in India for CERT-In

Cribl Migration case study

Migrating a Singapore MSSP from Cribl to an open-core security data platform

The challenge

Serving tenants in four countries meant running a separate pipeline deployment per country for data residency, each with its own licence and its own drift in configuration. MAS-regulated financial tenants also wanted evidence of exactly what was filtered out of their SIEM data and why, which was hard to produce from GUI-configured routes.

What we did

Consolidated four regional Cribl deployments into a single pipeline codebase deployed per country, so data stays local but logic is maintained once
Rebuilt routes and reduction rules on the open-core platform, with every filter documented and tied to a change ticket
Generated per-tenant reports of volume received, filtered, summarised and forwarded as audit evidence for MAS TRM reviews
Ran parallel pipelines with output diffing and cut over one country at a time

Results

~45%lower pipeline spend across four countries

1 codebasedeployed per country, data kept in-country

Per tenantfiltering evidence ready for audits

DataBahn Migration case study

Migrating a Saudi MSSP from DataBahn to an open-core security data pipeline

The challenge

Energy and government tenants asked where pipeline configuration and telemetry metadata were processed, and a SaaS-managed control plane was hard to defend under NCA controls and sector data-residency rules. Automatically applied volume-reduction rules were difficult to explain to tenant auditors, and several OT sources passed through generic parsers that dropped fields the detections needed.

What we did

Exported every DataBahn source, parser and reduction rule and documented what each one actually did to the data
Rebuilt them as transparent, version-controlled rules on a self-hosted open-core security data pipeline, entirely in-Kingdom
Wrote dedicated parsers for OT and ICS sources that had been going through generic parsing
Ran both pipelines in parallel and compared SIEM-bound volume and detection hits per tenant before cutover

Results

In-Kingdomdata path and control plane, fully self-hosted

Every rulereadable and signed off by tenant auditors

0detections lost, validated by parallel run

DataBahn Migration case study

Migrating an India-based MSSP from DataBahn to an open-core security data pipeline

The challenge

Volume-based pipeline pricing was squeezing margins on fixed-price SOC contracts, and the MSSP wanted to own the data-engineering capability it sells rather than rent it. Under the DPDP Act, tenants were also asking for personal data to be masked before logs left India for cloud SIEM regions.

What we did

Audited reduction outcomes per source to separate genuine savings from savings that had cost detection coverage
Rebuilt parsing, enrichment and reduction on an open-core security data pipeline, normalised to OCSF and kept in Git
Added in-pipeline PII masking and tokenisation before data left India for cloud SIEM regions
Packaged the pipeline as a reusable onboarding template, so a new tenant goes live from configuration alone

Results

~40%lower pipeline running cost

~25%further SIEM ingestion reduction from per-tenant tuning

Daysto onboard a new tenant, previously weeks

DataBahn Migration case study

Migrating a Singapore MSSP from DataBahn to an open-core security data pipeline

The challenge

Critical information infrastructure tenants under CCoP 2.0 and MAS-regulated tenants wanted assurance that no security-relevant log was dropped by automated reduction, and evidence of every change to collection logic. The MSSP could not produce a per-rule change history or replay data through an earlier version of the pipeline.

What we did

Reconstructed every reduction and routing decision as explicit, peer-reviewed rules on the open-core security data pipeline
Put pipeline configuration under Git with review and change tickets, giving a full history per tenant
Added a full-fidelity raw copy to object storage so any reduction can be reversed by replay
Validated detection parity by replaying 30 days of attack and benign samples through the old and new pipelines

Results

0detections lost, validated by 30-day replay

Full historyof pipeline changes per tenant

On demandreplay of any day of raw data

Splunk Log Collection case study

Replacing Splunk log collection with an open-core security data pipeline for a Saudi MSSP

The challenge

Every tenant had its own heavy-forwarder tier, and every forwarder sent raw data straight into Splunk licence. Tenants moving to Sentinel needed a second collection stack built from scratch, and forwarder upgrades and deployment-server sprawl consumed a large share of engineering time.

What we did

Replaced the heavy-forwarder tier with open-core pipeline nodes that receive from existing universal forwarders, syslog and Windows Event Forwarding
Preserved Splunk sourcetype, index and host metadata so existing apps, searches and dashboards ran unchanged
Filtered and summarised low-value events before delivery to Splunk over HEC, with a full raw copy to in-Kingdom object storage
Added routing to Sentinel and other SIEMs from the same pipeline, so a tenant's SIEM change no longer means new collection

Results

~40%less daily Splunk ingestion

~60%fewer forwarder hosts to run and patch

1 layerof collection for every tenant SIEM

Splunk Log Collection case study

Replacing Splunk log collection with an open-core security data pipeline for an India-based MSSP

The challenge

Splunk Cloud tenants paid for every gigabyte forwarded, but the universal forwarders could only filter coarsely, so firewall and Windows noise went through untouched. CERT-In retention was met with a separate second copy of the logs, and one deployment server managing thousands of agents had become a single point of failure.

What we did

Pointed universal forwarders at open-core pipeline nodes in each region, a configuration change with no agent reinstall
Replaced agents on network devices and Linux servers with direct syslog and lightweight collectors where that was simpler
Applied detection-safe filtering, field pruning and deduplication before Splunk Cloud, keeping every CIM field the rules use
Wrote 180-day full-fidelity copies to in-country object storage for CERT-In from the same stream

Results

~45%lower Splunk Cloud ingestion

0agent reinstalls needed for cutover

180 daysCERT-In retention without a second collection stack

Splunk Log Collection case study

Replacing Splunk log collection with an open-core security data pipeline for a Singapore MSSP

The challenge

Tenants were spread across three SIEMs and two clouds, and the MSSP ran a Splunk-specific forwarder stack alongside separate cloud connectors for everything else. Cloud logs such as CloudTrail, Azure activity and VPC flow logs reached Splunk through add-ons that were hard to scale, and cross-region data transfer charges kept rising.

What we did

Replaced heavy forwarders and Splunk cloud add-ons with an open-core pipeline that pulls cloud logs natively and receives from universal forwarders
Normalised every source to OCSF once, then delivered Splunk-formatted data to Splunk and native formats to Sentinel and Google SecOps
Filtered and compressed data in-region before shipping it, cutting cross-region transfer
Moved collection configuration into Git with per-tenant templates for new onboardings

Results

3 SIEMsfed from one collection layer

~35%lower combined SIEM ingestion

~50%lower cross-region data transfer

SIEM Ingestion Cost case study

Cutting SIEM ingestion cost per tenant by 50% for a Malaysian MSSP

The challenge

SIEM ingestion was billed per gigabyte but sold to tenants as a fixed monthly fee, so every tenant whose firewalls or endpoints grew chattier eroded margin. A handful of tenants had become loss-making, and NCII tenants under the Cyber Security Act 2024 and banks under BNM RMiT needed retention that could not simply be cut.

What we did

Measured ingestion per tenant, per source and per detection to see exactly which data the margin was paying for
Applied detection-safe filtering, field pruning and summarisation per tenant profile in the security data pipeline
Routed full-fidelity raw logs to low-cost object storage for regulatory retention and investigations
Built per-tenant cost dashboards and volume alerts so account managers see drift before the invoice does

Results

~50%lower SIEM ingestion cost per tenant

0loss-making tenants after rollout

0detections lost, validated by rule replay

SIEM Ingestion Cost case study

Reducing SIEM ingestion cost 40% across the tenant base for a Singapore MSSP

The challenge

The MSSP was approaching its next SIEM commitment tier and wanted to price new tenants more competitively, but had no per-tenant view of which sources drove cost. Tenants sat on different SIEMs with different pricing models, so savings work had to be done once in the pipeline, not separately per platform.

What we did

Built one per-tenant, per-source volume and cost model covering every SIEM in the estate
Defined reduction profiles by source type (firewall, Windows, DNS, proxy, cloud) applied in the pipeline whatever the destination SIEM
Sent compliance-only data straight to a searchable low-cost tier, keeping it out of the SIEM entirely
Replayed each tenant's detection test suite before and after every change and shared the results with the tenant

Results

~40%lower SIEM ingestion across the tenant base

1 tierof SIEM commitment avoided at renewal

~20%lower price on new tenant proposals

Have a similar challenge?

A focused 45-minute discovery call on your log sources, volumes, SIEM and detection goals. We will tell you honestly whether the outcomes above are realistic for your environment.

Book a discovery call Explore solutions