Security
Software and Technology

Siemens reclaims ~5,000 SOC analyst hours a year on Elastic Security, correlating 6 billion events a day across 300,000 endpoints and shipping detection rules in under a week

  • ~5,000 hrs
    Analyst hours reclaimed per year, redirected from data center operations to security
  • 6B/day
    Events ingested and correlated across the global estate, aggregated to ~170 cases/day
  • 1.2 PB
    Queried in support of 300,000+ endpoints and 600,000 users
  • <1 week
    Detection-rule delivery, down from a 3–4 week backlog
  • 10 min
    AutoOps deployed at the Amberg factory, reactive to proactive

Siemens runs Elastic as a common data platform across two mission-critical domains, global cyber defense and the Amberg lighthouse factory, reclaiming roughly 5,000 analyst hours a year and shifting constrained teams from operational firefighting to proactive prevention.

Summary

Siemens protects a 300,000-endpoint, 600,000-user global estate and runs one of the world's most closely watched factories, the Amberg lighthouse plant, both on Elastic. For years the cybersecurity team lost two-and-a-half to three people a year to running data-center infrastructure, while the factory's two-person Elastic team could only react to problems after users felt them. After moving its security analytics to Elastic Cloud with Elastic Security, and deploying AutoOps for its self-managed factory stack, Siemens reclaimed roughly 5,000 analyst hours a year, cut detection-rule delivery from a three-to-four-week backlog to under one week, and shifted both teams from firefighting to prevention.

1 platform, 2 mission-critical jobs

Siemens is one of the world's largest industrial companies, with more than 300,000 employees in nearly every country and a portfolio spanning electrification, automation, and digitalization. Two very different parts of that business depend on Elastic, and both arrived at the same conclusion: A constrained team should spend its time on the mission, not on keeping infrastructure alive. In the Cyber Defense Center, that shift reclaimed roughly 5,000 analyst hours a year. On the floor of the Amberg factory, it turned a two-person team from reactive to proactive.

At the corporate level, Siemens ingests 6 billion events a day, correlates them into roughly 11,000 alerts, and aggregates those into about 170 cases that reach the SOC. The team queries 1.2 petabytes in support of 300,000+ endpoints and 600,000 users. Ricardo Oliveira, head of engineering protection and automation solutions at Siemens, frames the motivation in plain operational terms.

"We decided we wanted to use our people and our time to improve security, not to manage the operation."

– Ricardo Oliveira, Head of Engineering Protection and Automation Solutions, Siemens

At the factory level, the stakes are physical. The Siemens Digital Industries plant in Amberg, Bavaria, is a lighthouse factory: a reference site Siemens uses to show industrial digitization to customers and partners worldwide, visited more than once by Angela Merkel and the Bavarian state premier. Any downtime Monday through Friday is unacceptable, and some services have to run seven days a week. Elastic is the backbone of how the team sees what the factory is doing.

8 years on Elastic, and a decision to stop running infrastructure

Siemens has used Elasticsearch for more than eight years, originally self-managed on-premises, as the data foundation for its security operations. The platform did the job, but the operating model around it did not scale. To grow capacity, the team had to buy bare-metal servers, rack them, cable them, and provision network access, and day to day, it was patching operating systems and managing hypervisors instead of doing security work.

The cloud migration had two explicit objectives: Reduce the operational load of running the data center, and increase security capability by putting Elastic Security on top of Elastic Cloud. The selection criteria were scalability, ease of management, and security, with productivity in the cloud a close fourth. Siemens evaluated Elastic against two other providers as procurement required and chose Elastic on a combination of technical parity, more attractive pricing, manageability, and the depth of the team's existing Elastic skills. Elastic Professional Services led the engagement, with partner SVA contributing Elastic expertise across the project's requirement, development, and production-readiness phases. The migration took about a year. Elastic was subsequently approved into Siemens' Charter of Trust, the trusted-vendor community Siemens convenes with other major organizations.

That same platform standard reaches into Siemens' industrial business. The Amberg factory runs a deeply heterogeneous estate: Decades-old applications on HP-UX and Intel Itanium sit alongside modern containerized services on OpenShift, connected by Microsoft SQL Server, Oracle, and PostgreSQL databases. The Elastic Stack there is itself migrating to OpenShift using the Elastic Operator. The Elastic platform Siemens uses for global security — the same one its security teams, observability teams, and AI department all build on — is the one keeping the lighthouse factory visible.

Before: Time spent on operations, problems found after the fact

Before the cloud migration, the security team's time went to the infrastructure rather than the mission. Roughly two-and-a-half to three people a year went to patching, hypervisor management, and the slow physical work of scaling on-premises hardware. Scaling meant a purchase order, a rack, and cabling, not a configuration change. Correlating telemetry across siloed data pools to detect attacks that spanned multiple systems was slow, and standing up a new detection rule meant joining a backlog of three to four weeks.

At Amberg, the constraint was attention. Two administrators split a single day a week each on Elastic, on top of building custom applications; running identity management, Linux, and databases; and advising other teams on security. With that little time, the team could not watch the stack closely enough to tune it. Problems surfaced only once they had already landed: Storage filled up, a query slowed the cluster, or a user emailed to say an application was behaving oddly. There was no systematic way to know which queries were the worst offenders or whether index growth was real demand or a misconfigured application writing junk logs.

Neither of these is a failure of the platform. They are the natural consequence of scale, heterogeneity, and a team stretched thin.

Architecture: 1 data layer, 2 operating contexts

Global security on Elastic Cloud. Telemetry from network logs, endpoint detection and response, and cloud infrastructure flows into a single unified data layer on Elastic Cloud, ingested through Logstash. The platform takes in 6 billion events a day and supports queries across 1.2 petabytes. Correlation produces roughly 11,000 alerts a day, which are aggregated into cases, about 170 of which reach SOC analysts for human judgment. Elastic's machine learning learns normal behavior and flags deviations, so the team is not writing a static rule for every conceivable threat, which keeps false positives down. Kibana provides the analyst-facing dashboards.

The factory on a self-managed stack with AutoOps. All factory machines sit on a dedicated, secured shop-floor network, isolated for security and monitored with Packetbeat. Elastic Agent collects logs and metrics from factory machines, Windows and Linux servers, and databases, and all OpenShift workload logs ship into Elastic, giving one central operational view regardless of where an application runs. Newer applications are instrumented with Elastic APM, and Elastic tracks Service Level Objectives (SLOs) for them, which is why the health of Elastic is directly tied to the availability of the business applications built on top of it. In addition, the team deployed AutoOps for its self-managed deployment using the Kubernetes path, which took about 10 minutes given the existing OpenShift footprint.

Technical highlights

  • Global security runs on Elastic Cloud (Elastic-managed); the Amberg factory runs a customer-managed Elastic Stack, now moving onto its existing OpenShift via the Elastic Operator (ECK)
  • 6 billion events per day ingested; 1.2 petabytes queryable; ~11,000 alerts/day aggregated to ~170 cases/day
  • Logstash ingestion; Kibana dashboards and visualizations; Elastic Security detection and rule creation
  • Elastic machine learning for anomaly detection and false-positive reduction
  • Packetbeat for isolated shop-floor network monitoring; Elastic Agent for logs and metrics across machines, servers, and databases
  • Elastic APM and SLO tracking for newer containerized applications
  • Kibana-powered business applications: an indoor factory viewer with clickable live sensor data, and a real-time dashboard of every AGV's location, status, error state, and Wi-Fi signal
  • AutoOps on the self-managed stack, deployed via Kubernetes in ~10 minutes

What the platform changed

Correlation and ML-driven detection

The original bottleneck was not data volume but the inability to correlate it. Analysts had to stitch context together across siloed sources by hand, which slowed every investigation. On the unified Elastic data layer, correlation runs across the whole estate, and machine learning flags behavioral deviations rather than relying solely on hand-written rules, which reduces false positives and lets analysts spend their attention on the cases that matter.

Faster detection engineering

Standing up a new detection used to mean a three to four week backlog. The team now delivers detection rules in under a week and has seen a measurable reduction in mean time to detect That speed matters directly for compliance: Under tightening regulation such as NIS2, Siemens must be able to investigate, document, and report security events inside a 24-hour window, and faster detection and investigation make that reporting achievable.

AutoOps: From reactive to proactive at the factory

At Amberg, AutoOps changed where the first signal comes from. It used to come from a user; now it usually comes from the platform. AutoOps surfaces the worst-performing queries directly, so the team can target optimization where it counts instead of watching every query by hand. It gives early warning when index growth deviates from the norm, letting the team distinguish genuine data growth from a misbehaving application writing unnecessary logs, before storage fills up rather than after. When an anomaly ties to a specific index or application, the team can reach out to the application owner proactively, often before any user notices a problem. That early warning posture is what keeps a lighthouse factory dependable.

"If the factory experiences any downtime we are in trouble. The factory has to run — and everything else comes under that. Full stop. We need the technology that achieves that without any compromise."

– Wolfram Haussig, IT Solution Expert, Siemens Amberg

The operating model in practice

There is no single dramatic incident at the center of this story, and that is the point. In the SOC, analysts no longer assemble context by hand across disconnected pools; they review roughly 170 prepared cases a day, decide whether each is a real problem, and escalate the ones that are. The routine data crunching that used to consume the team is now automated, and the hours that work returns are spent on threat hunting, incident-response strategy, and refining detection logic.

At Amberg, the equivalent shift is the absence of a complaint email. The two-person team acts on an AutoOps signal before performance degrades, traces a storage anomaly to its source instead of scaling hardware to absorb it, and contacts a development team before the issue ever reaches a user. The value shows up as problems users never experienced.

"We have effectively given our team 5,000 hours back every year, time we now invest in staying ahead of adversaries rather than catching up with logs."

– Ricardo Oliveira, Head Engineering Protection and Automation Solutions, Siemens

Before and after


BeforeAfter
Where the team's time went~2.5–3 people/year on data-center operations; factory team reacting to problems after users hit them~5,000 hours/year redirected to security; factory team acting on signals before users notice
Scaling capacityBuy, rack, and cable bare-metal serversScale on Elastic Cloud as a configuration change
Detection engineeringThree to four week backlog per ruleNew detection rules in under a week
Problem discoveryComplaint email, failed login, slow queryPlatform surfaces the signal first (correlation, ML, AutoOps)
Investigation flowManual correlation across siloed data poolsCorrelated cases reviewed across a unified data layer
Analyst and admin roleTriage, patching, infrastructure maintenanceThreat hunting, response strategy, proactive prevention

Early adoption context

AutoOps is new for Siemens, and Siemens Amberg is an early adopter. The team deployed it in about 10 minutes and began getting value immediately, using it alongside Elastic's standard monitoring rather than as a replacement. They are clear that hard numeric metrics for the factory stack are not available, in part because Elastic is classified internally as a monitoring tool rather than a production application, so it is not measured with the same rigor as the factory-facing systems. Their assessment is that the value is already real, and that they expect the product to mature further as they keep using it (reported as an honest early adopter view, not a finished benchmark).

What comes next?

Siemens is extending Elastic in both directions. On the security side, the team is moving toward AI-assisted operations: using Elastic AI Agent to help junior analysts interpret complex alerts and suggest next steps; drawing on Elastic Attack Discovery for faster, explainable detection insights; and exploring agentic workflows to respond to incidents more quickly. Because every AI-surfaced verdict can be inspected and verified, analysts stay in the position of judgment rather than trusting a black box. The roadmap also includes expanding ingestion to cover more operational technology data, so industrial control systems get the same scrutiny as the IT estate, and Siemens has asked Elastic to strengthen case management for aggregating related alerts. At Amberg, the team plans to continue with AutoOps as its self-managed footprint moves to OpenShift.

Your organization may not be ingesting 6 billion events a day or running a lighthouse factory today, but the same principle applies whether you are protecting a few hundred endpoints or 300,000 of them: A platform that lets a constrained team spend its time on the mission, not on the machinery, changes what that team can do. For Siemens, a company spanning electrification, automation, and digitalization in nearly every country, Elastic is the common data foundation under both its global cyber defense and its most visible factory.

"Cloud journeys are not easy, but with Elastic's support we got there in about a year. I do not think we could have done that with another provider in that time."

– Ricardo Oliveira, Head Engineering Protection and Automation Solutions, Siemens

See how Elastic unifies security and observability on one data platform or start now with a free trial.