How a Global Automotive Supplier Reduced SIEM Cost Volatility with a Hybrid SOC

The Challenge

From the outset, the organisation was not debating whether to run a SOC.
The real question was how to design an operating model that could scale globally without breaking under cost, regulatory, or operational pressure.
Several constraints shaped the problem:

• Automotive supply-chain requirements, including TISAX and OEM-driven security expectations
• NIS2 obligations, both direct and inherited through customers
• Data protection and residency laws, particularly for China
• Rapid telemetry growth, reaching approximately 90 GB/day across all regions
• Dual-use telemetry requirements, supporting both security investigations and IT incident analysis
• Strong pressure to control SIEM cost, without sacrificing visibility or investigative depth

The Initial Baseline: Sentinel-Only SOC
The first architecture evaluated was a Sentinel-only SOC:

All regional telemetry ingested directly into Microsoft Sentinel

Data routed into:

• Analytics tier for real-time detection and correlation
• Data Lake tier for longer-term, lower-cost retention
• Azure Monitor ingestion controls (filtering and transformations) used to reduce noise before analytics

This model had clear advantages: fast to deploy, architecturally simple, fully integrated with the Microsoft security ecosystem.

However, several structural limitations became apparent:

• Cost and investigation depth were tightly coupled to Sentinel’s consumption-based pricing
• Retention and query behaviour in the Analytics tier directly impacted ongoing cost
• Sentinel proved inefficient as a primary investigation platform for large volumes of raw telemetry
• Maintaining consistent investigative capability across regions, especially with legal and network constraints, was difficult

At scale, Sentinel could function either as:

• a global coordination and compliance layer, or
• a deep, long-term investigation platform

Trying to force it to be both was neither economically nor operationally sustainable.

---

The Solution

Selected Architecture

Hybrid SOC: ELK as the investigation platform, Sentinel as the global control plane (Variant 2B-lite)

The organisation selected Variant 2B-lite, a hybrid SOC model that deliberately separates:

• Telemetry depth and retention
• Global coordination, escalation, and regulatory visibility

This was a design choice driven by clarity of responsibility, not vendor preference.

Regional Data Collection and Transport

Each region (EU, Latin America, Indonesia, China) deployed lightweight log forwarders close to data sources, collecting telemetry from:

• Windows and Linux systems
• Active Directory and identity infrastructure
• EDR platforms
• Firewalls, VPNs, and core network components
• Selected manufacturing-adjacent systems

At the regional level, processing was intentionally minimal:

• ECS-aligned normalisation
• Masking of sensitive fields (PII)
• Disk-based buffering to absorb temporary network outages

Telemetry was transmitted to the EU over TLS/mTLS via IPSec VPN, ensuring confidentiality and integrity in transit.

Central ELK Platform: Full-Fidelity Telemetry and Investigations

A central Elastic Stack (ELK) platform acts as the system of record for all telemetry:

• Scalable ELK cluster hosted in a Kubernetes environment
• Dedicated ingest nodes for parsing and enrichment

Storage tiering via Index Lifecycle Management (ILM):

• Hot tier (30–60 days)
  • Active investigations
• Warm tier (3–6 months)
  • Retrospective analysis
• Long-term archive (≥12 months) in external object storage
  • TISAX assessments
  • NIS2 incident traceability
  • Post-incident forensic reconstruction
  • All logs from all onboarded systems are retained in ELK regardless of severity.

This enables:

• Deep security investigations
• Cross-system correlation
• IT incident root-cause analysis
• Reliable reconstruction of multi-stage attacks

No data is dropped simply because it is “too expensive to keep".

Microsoft Sentinel: Global SOC Coordination and Compliance Layer

Microsoft Sentinel is not used as the primary telemetry repository.

Instead, it functions as the global SOC control plane, responsible for:

• Global incident visibility
• Cross-regional coordination
• Orchestration and response workflows
• Compliance-aligned reporting
• Executive-level dashboards

Sentinel receives only high-value security signals, including:

• Critical and high-severity events forwarded from ELK
• Incidents requiring cross-regional coordination
• Telemetry required for regulatory visibility (e.g. NIS2)
• Native Microsoft 365 and Defender signals (ingested directly)

Integration is implemented via:

• Azure Log Ingestion API, or
• Event Hub–based pipelines

As a result, Sentinel ingestion was reduced to approximately 20–30% of total telemetry, while preserving its strategic and regulatory value.

---

The Results

Why Variant 2B-lite Worked

The selected model succeeded because it enforced a clear separation of concerns:

• ELK handles:

• Telemetry volume
• Retention
• Investigations

Sentinel handles:

• Coordination
• Escalation
• Compliance and reporting

Additional benefits included:

• Preserved investigative depth
  • No loss of raw data due to cost-driven filtering or premature summarisation
• Centralised evidence integrity
  • Even if a regional environment — including China — were compromised, full telemetry already existed centrally
• Regulatory alignment
  • Sentinel provides a controlled compliance surface without forcing all telemetry into a premium analytics tier
• Operational simplicity
  • One central ELK platform with lightweight regional collectors proved significantly easier to operate than federated SIEM models

Cost Perspective (Illustrative Ranges)

Key Risks and Mitigations

• Regulatory exposure related to China
  • Mitigated through PII masking, legal review, and security-driven justification for cross-border telemetry transfer
• Network dependency
  • Reduced through local buffering and resilient transport design
• Central ELK concentration risk
  • Addressed via backups, snapshots, and disaster-recovery planning

Takeaway

This case reinforces a core principle of sustainable SOC design:

SIEM TCO optimisation is not about choosing a cheaper platform.
It is about assigning the right roles to platforms so that risk, telemetry, and decision-making scale together.In this operating model:

• ELK provides depth, history, and investigative power
• Sentinel provides global coordination, escalation, and regulatory confidence

For this organisation, Variant 2B-lite proved to be the most defensible and scalable balance between the two.