Siemens betreibt Elastic als gemeinsame Datenplattform für zwei geschäftskritische Bereiche: die globale Cyberverteidigung und das als Leuchtturm geltende Werk in Amberg. Damit lassen sich jährlich rund 5.000 Analystenstunden einsparen und die ohnehin schon knappen Ressourcen der Teams von operativen Ad-Hoc-Maßnahmen auf die proaktive Prävention verlagern.
Zusammenfassung
Siemens schützt eine globale Infrastruktur mit 300.000 Endpoints und 600.000 Nutzern und betreibt eines der weltweit am stärksten beachteten Werke: das als Leuchtturmfabrik ausgezeichnete Werk in Amberg – beides mit Elastic. Jahrelang musste das Cybersicherheitsteam zweieinhalb bis drei Personen pro Jahr für die Verwaltung der Rechenzentrumsinfrastruktur abstellen, während das zweiköpfige Elastic-Team der Fabrik auf Probleme erst reagieren konnte, nachdem Nutzer sie bemerkt hatten. Mit der Verlagerung der Security Analytics zu Elastic Cloud mit Elastic Security und einer AutoOps-Bereitstellung für den hausintern verwalteten Werks-Stack jedoch ließen sich etwa 5.000 Analystenstunden pro Jahr einsparen, die Lieferzeit für Erkennungsregeln von einem Rückstand von drei, vier Wochen auf unter eine Woche reduzieren und beide Teams von der Ad-Hoc-Fehlerbehebung auf die Prävention verlagern.
Eine Plattform, zwei unternehmenskritische Aufgaben
Siemens ist eines der weltweit größten Industrieunternehmen mit mehr als 300.000 Beschäftigten in fast allen Ländern und einem Portfolio, das Elektrifizierung, Automatisierung und Digitalisierung umfasst. Zwei sehr unterschiedliche Bereiche dieses Geschäfts sind von Elastic abhängig, und in beiden kam man zum selben Schluss: Ein Team mit begrenzten Ressourcen sollte seine Zeit für die Geschäftsziele verwenden und nicht zum Aufrechterhalten der Infrastruktur. Im Cyber Defense Center wurden durch diese Umstellung jährlich rund 5.000 Analystenstunden eingespart. In der Werkshalle in Amberg gelang es, ein Zweierteam von reaktiv auf proaktiv umzustellen.
Auf Unternehmensebene erfasst Siemens täglich 6 Milliarden Ereignisse, korreliert sie zu etwa 11.000 Warnungen und aggregiert diese zu etwa 170 Tickets, die das SOC erreichen. Das Team greift auf 1,2 Petabytes an Daten zu, um mehr als 300.000 Endpunkte und 600.000 Nutzer zu unterstützen. Ricardo Oliveira, Leiter der Abteilung für technischen Schutz und Automatisierungslösungen bei Siemens, beschreibt die Motivation in einfachen Worten.
„Wir haben beschlossen, unsere Mitarbeiter und unsere Zeit für die Verbesserung der Sicherheit einzusetzen, nicht für die Betriebsverwaltung.“
Auf Werksebene sind die Risiken greifbar. Siemens Digital Industries in Amberg, Bayern, ist eine Leuchtturmfabrik: ein Referenzstandort, den Siemens nutzt, um Kunden und Partnern weltweit industrielle Digitalisierung zu zeigen, und der mehr als einmal von Angela Merkel und dem bayerischen Ministerpräsidenten besucht wurde. Ausfallzeiten von Montag bis Freitag sind absolut inakzeptabel, und einige Dienste müssen sieben Tage die Woche laufen. Elastic bildet die Grundlage dafür, wie das Team sieht, was im Werk geschieht.
Acht Jahre mit Elastic und die Entscheidung, keine Infrastruktur mehr zu betreiben
Siemens nutzt Elasticsearch seit mehr als acht Jahren, ursprünglich selbstverwaltet als On-Prem-Lösung, als Datengrundlage für seine Sicherheitsoperationen. Die Plattform erfüllte ihren Zweck, aber das dazugehörige Betriebsmodell ließ sich nicht skalieren. Um die Kapazität zu erhöhen, musste das Team Bare-Metal-Server kaufen, diese aufbauen, verkabeln und einen Netzwerkzugang herstellen. Der Alltag bestand daraus, Betriebssysteme zu patchen und Hypervisoren zu verwalten, statt Sicherheitsarbeit zu leisten.
Die Cloud-Migration hatte zwei ausdrückliche Ziele: die Verringerung der operativen Belastung durch den Betrieb des Rechenzentrums, und die Erhöhung der Sicherheitskapazität durch den Einsatz von Elastic Security auf Elastic Cloud. Die Auswahlkriterien waren Skalierbarkeit, einfache Verwaltung und Sicherheit, mit der Produktivität in der Cloud an vierter Stelle. Siemens bewertete Elastic im Rahmen der Beschaffungsanforderungen gegenüber zwei anderen Anbietern und entschied sich aufgrund einer Kombination aus technischer Gleichwertigkeit, attraktiveren Preisen, einfacherer Verwaltbarkeit und des Umfangs der bereits vorhandenen Elastic-Kenntnisse des Teams für Elastic. Elastic Professional Services leitete das Engagement, wobei der Partner SVA in den Phasen Anforderung, Entwicklung und Produktionsbereitschaft des Projekts die Elastic-Expertise beisteuerte. Die Migration dauerte etwa ein Jahr. Elastic wurde anschließend in die Charter of Trust von Siemens aufgenommen, die vertrauenswürdige Anbieter-Community, die Siemens mit anderen großen Unternehmen unterhält.
Derselbe Plattformstandard findet auch im Industriegeschäft von Siemens Anwendung. Das Werk Amberg betreibt einen stark heterogenen Betrieb: Jahrzehnte-alte Anwendungen auf HP-UX und Intel Itanium stehen neben modernen containerisierten Diensten auf OpenShift, die über Microsoft SQL Server, Oracle und PostgreSQL-Datenbanken verbunden sind. Der Elastic Stack dort migriert selbst mit dem Elastic Operator zu OpenShift. Die Elastic-Plattform, die Siemens für die globale Sicherheit nutzt – dieselbe, auf der alle Sicherheitsteams, Beobachtungsteams und die KI-Abteilung aufbauen –, sorgt dafür, dass die Leuchtturmfabrik sichtbar bleibt.
Vorher: Zeitaufwand für Betriebsbelange, Probleme wurden nachträglich entdeckt
Vor der Migration in die Cloud verbrachte das Sicherheitsteam seine Zeit eher mit der Infrastruktur als mit der eigentlichen Unternehmensmission. Etwa zweieinhalb bis drei Personen pro Jahr widmeten sich dem Patchen, der Hypervisor-Verwaltung und der langsamen physischen Arbeit des Skalierens von On-Prem-Hardware. Skalieren bedeutete eine Bestellung, ein Rack und Verkabelung, jedoch keine Konfigurationsänderung. Die Korrelation von Telemetriedaten über isolierte Datenpools hinweg zum Erkennen von Angriffen, die sich über mehrere Systeme erstreckten, war langsam und die Einrichtung einer neuen Erkennungsregel bedeutete eine Wartezeit von drei bis vier Wochen.
In Amberg fehlte die Zeit für Aufmerksamkeit. Zwei Administratoren teilten sich einen Tag pro Woche in die Arbeit mit Elastic, neben dem Aufbau von benutzerdefinierten Anwendungen; sie betrieben Identitätsmanagement, Linux und Datenbanken, und berieten andere Teams in Sachen Sicherheit. Mit so wenig Zeit konnte das Team den Stack nicht genau genug beobachten, um ihn zu optimieren. Probleme tauchten erst auf, nachdem sie bereits eingetreten waren: Der Speicher füllte sich, eine Abfrage verlangsamte den Cluster, oder ein Nutzer schickte eine E-Mail, um mitzuteilen, dass sich eine Anwendung seltsam verhielt. Es gab keine systematische Methode, um herauszufinden, welche Abfragen die Hauptverursacher waren oder ob das Indexwachstum auf tatsächliche Nachfrage oder auf eine falsch konfigurierte Anwendung zurückzuführen war, die unnütze Logdateien erzeugte.
Keines von alldem war ein Versagen der Plattform. Es war die natürliche Folge von Größe, Heterogenität und einem überlasteten Team.
Architektur: 1 Datenschicht, 2 Betriebskontexte
Globale Sicherheit auf Elastic Cloud. Telemetriedaten aus Netzwerklogs, Endpoint-Erkennung und -Reaktion sowie cloudbasierte Infrastruktur fließen in eine einzige, einheitliche Datenschicht auf Elastic Cloud, die über Logstash aufgenommen wird. Die Plattform nimmt täglich 6 Milliarden Ereignisse auf und unterstützt Abfragen über 1,2 Petabyte. Die Korrelation erzeugt etwa 11.000 Warnmeldungen pro Tag, die zu Tickets zusammengefasst werden, von denen etwa 170 zur menschlichen Beurteilung an SOC-Analysten weitergeleitet werden. Das Machine Learning von Elastic lernt normales Verhalten und kennzeichnet Abweichungen, sodass das Team keine statische Regel für jede denkbare Bedrohung aufstellen muss, was Fehlalarme minimiert. Kibana stellt die Analysten-Dashboards bereit.
Die Fabrik auf einem selbstverwalteten Stack mit AutoOps. Alle Werksmaschinen befinden sich in einem dedizierten, gesicherten Produktionsnetzwerk, das aus Sicherheitsgründen isoliert und mit Packetbeat überwacht wird. Elastic Agent sammelt Protokolle und Kennzahlen aus Werksmaschinen, Windows- und Linux-Servern sowie Datenbanken, und alle OpenShift-Workload-Logs werden an Elastic gesendet, was eine zentrale operative Übersicht bietet, unabhängig davon, wo eine Anwendung läuft. Neuere Anwendungen werden mit Elastic APM instrumentiert, und Elastic überwacht die Service Level Objectives (SLOs) für diese Anwendungen. Daher ist die Funktionsfähigkeit von Elastic direkt mit der Verfügbarkeit der darauf aufbauenden Geschäftsanwendungen verknüpft. Zusätzlich implementierte das Team mittels Kubernetes AutoOps für seine selbstverwaltete Bereitstellung, was angesichts des bestehenden OpenShift-Umfangs etwa 10 Minuten dauerte.
Technische Highlights
- Globale Sicherheit läuft auf Elastic Cloud (von Elastic verwaltet); das Werk Amberg betreibt einen kundenverwalteten Elastic Stack, der nun über den Elastic Operator (ECK) auf das vorhandene OpenShift wechselt
- 6 Milliarden Ereignisse pro Tag erfasst, 1,2 Petabyte abfragbar, ca. 11.000 Warnungen pro Tag aggregiert zu rund 170 Tickets pro Tag
- Logstash-Ingestion, Kibana-Dashboards und Visualisierungen, Elastic Security-Erkennung und Regelerstellung
- Elastic Machine Learning für Anomalieerkennung und die Reduzierung von Fehlalarmen
- Packetbeat für die isolierte Netzwerküberwachung in Produktionsumgebungen, Elastic Agent für Protokolle und Metriken über Maschinen, Server und Datenbanken hinweg
- Elastic APM und SLO-Tracking für neuere containerisierte Anwendungen
- Kibana-gestützte Geschäftsanwendungen: eine Indoor-Fabrikansicht mit anklickbaren Live-Sensordaten und ein Echtzeit-Dashboard für den Standort, Status, Fehlerzustand und das Wi-Fi-Signal jedes AGVs
- AutoOps auf dem selbstverwalteten Stack, bereitgestellt über Kubernetes in ca. 10 Minuten
Was die Plattform verändert hat
Korrelation und ML-gestützte Erkennung
Der ursprüngliche Engpass war nicht das Datenvolumen, sondern die Unfähigkeit, es zu korrelieren. Analysten mussten den Kontext aus isolierten Quellen von Hand zusammentragen, was jede Untersuchung verlangsamte. Auf der einheitlichen Elastic-Datenebene wird die Korrelation über das gesamte Datenumfeld hinweg durchgeführt, und Machine Learning kennzeichnet Verhaltensabweichungen, anstatt sich ausschließlich auf handgeschriebene Regeln zu verlassen. Dies reduziert Fehlalarme und ermöglicht den Analysten, ihre Aufmerksamkeit auf die wirklich wichtigen Tickets zu richten.
Schnellere Erkennungstechnik
Die Einrichtung einer neuen Erkennung bedeutete früher einen Bearbeitungsrückstand von drei bis vier Wochen. Das Team liefert nun Erkennungsregeln in weniger als einer Woche und konnte die mittlere Erkennungszeit messbar reduzieren. Diese Geschwindigkeit ist für die Einhaltung der Vorschriften von direkter Bedeutung. Im Rahmen strengerer Vorschriften wie NIS2 muss Siemens in der Lage sein, Sicherheitsereignisse innerhalb von 24 Stunden zu untersuchen, zu dokumentieren und zu melden, und eine schnellere Erkennung und Untersuchung machen diese Berichterstattung möglich.
AutoOps: Von reaktiv zu proaktiv im Werk
In Amberg hat AutoOps den Ort geändert, von dem das erste Signal kommt. Früher kam es von einem Nutzer, jetzt kommt es in der Regel von der Plattform. AutoOps zeigt die am schlechtesten performenden Abfragen direkt an, sodass das Team die Optimierung dort ansetzen kann, wo es zählt, anstatt jede Abfrage von Hand zu überwachen. Es gibt eine Frühwarnung ab, wenn das Indexwachstum vom Durchschnitt abweicht, sodass das Team echtes Datenwachstum von einer fehlerhaften, unnötige Protokolle schreibenden Anwendung unterscheiden kann, bevor der Speicher voll ist, und nicht erst danach. Wenn eine Anomalie mit einem bestimmten Index oder einer Anwendung verknüpft ist, kann das Team proaktiv den Anwendungsbesitzer kontaktieren, oft bevor ein Nutzer ein Problem bemerkt. Diese Frühwarnhaltung ist das, was eine Leuchtturmfabrik zuverlässig hält.
„Wenn es im Werk zu Ausfallzeiten kommt, geraten wir in Schwierigkeiten. Die Fabrik muss laufen – alles andere ist zweitrangig. Punkt. Wir brauchen eine Technologie, die das ohne Wenn und Aber ermöglicht.“
Das Betriebsmodell in der Praxis
Es gibt keinen einzelnen dramatischen Vorfall in dieser Geschichte, und das ist der springende Punkt. Im SOC stellen Analysten den Kontext nicht mehr von Hand über getrennte Pools hinweg zusammen; sie prüfen täglich etwa 170 vorbereitete Tickets, entscheiden, welche davon echte Probleme sind, und eskalieren die, die es sind. Die routinemäßige Datenverarbeitung, die das Team früher Zeit kostete, ist jetzt automatisiert, und die dadurch gewonnenen Stunden werden für Bedrohungsjagd, Incident-Response-Strategie und die Verfeinerung der Erkennungslogik genutzt.
Bei Amberg entspricht dies dem Fehlen einer Beschwerde-E-Mail. Das Zwei-Personen-Team reagiert auf ein AutoOps-Signal, bevor die Leistung nachlässt, verfolgt eine Speicheranomalie bis zu ihrer Quelle zurück, anstatt Hardware zu skalieren, um sie zu absorbieren, und kontaktiert ein Entwicklungsteam, bevor das Problem überhaupt einen Nutzer erreicht. Der Wert wird als Probleme angezeigt, die Nutzer nie hatten.
„Wir haben unserem Team effektiv 5.000 Stunden pro Jahr zurückgegeben, Zeit, die wir jetzt investieren, um unseren Gegnern einen Schritt voraus zu sein, anstatt Logs aufzuarbeiten.“
Vorher und danach
| Vorher | Nachher | |
|---|---|---|
| Wohin die Zeit des Teams floss | ~2,5–3 Personen pro Jahr für den Rechenzentrumsbetrieb; das Werksteam reagiert auf Probleme, nachdem Nutzer auf diese gestoßen sind | ~5.000 Stunden/Jahr in die Sicherheit umgeleitet; das Werksteam reagiert auf Signale, bevor die Nutzer etwas merken |
| Kapazitässkalierung | Kauf, Aufbau und Verkabelung von Bare-Metal-Servern | Skalierung auf Elastic Cloud als Konfigurationsänderung |
| Erkennungstechnik | Drei bis vier Wochen Rückstand pro Regel | Neue Erkennungsregeln in weniger als einer Woche |
| Problemerkennung | Beschwerde-E-Mail, fehlgeschlagener Login, langsame Abfrage | Die Plattform zeigt das Signal zuerst (Korrelation, ML, AutoOps) |
| Untersuchungsablauf | Manuelle Korrelation zwischen isolierten Datenpools | Korrelierte Tickets, die auf einer einheitlichen Datenebene überprüft werden |
| Analysten- und Verwaltungsrolle | Triage, Patching, Infrastrukturwartung | Bedrohungssuche, Reaktionsstrategie, proaktive Prävention |
Kontext der frühen Übernahme
AutoOps ist neu für Siemens, und Siemens Amberg gehört zu den ersten Anwendern. Das Team implementierte es in etwa 10 Minuten und konnte sofort einen Nutzen daraus ziehen, indem es AutoOps parallel zum Elastic Standard-Monitoring statt als Ersatz nutzte. Es ist klar, dass harte numerische Kennzahlen für den Werks-Stack nicht verfügbar sind, unter anderem weil Elastic intern als Überwachungstool und nicht als Produktionsanwendung eingestuft und daher nicht mit der gleichen Strenge gemessen wird wie die werksseitigen Systeme. Man geht davon aus, dass der Wert bereits real ist, und erwartet, dass das Produkt während der weiteren Nutzung weiter reifen wird (Bericht aus ehrlicher Sicht eines frühen Anwenders, keine fertige Benchmark).
Wie geht es weiter?
Siemens erweitert Elastic in beide Richtungen. Im Bereich der Sicherheit geht das Team in Richtung KI-gestützter Operationen: Mithilfe des Elastic AI Agent unterstützt es jüngere Analysten bei der Interpretation komplexer Warnmeldungen und schlägt nächste Schritte vor, es greift auf Elastic Attack Discovery zurück, um schnellere und nachvollziehbare Einblicke zur Erkennung zu gewinnen, und es werden agentenbasierte Workflows erforscht, um schneller auf Vorfälle reagieren zu können. Da jedes von der KI generierte Ergebnis überprüft und verifiziert werden kann, behalten die Analysten die Urteilsfähigkeit und müssen nicht einer Blackbox vertrauen. Die Roadmap beinhaltet außerdem eine Ausweitung der Ingestion, um mehr Daten aus operativen Technologien abzudecken, sodass industrielle Steuerungssysteme die gleiche Prüfung wie der IT-Bereich erhalten. Siemens hat Elastic gebeten, das Ticketmanagement für die Aggregation verwandter Warnungen zu stärken. In Amberg plant das Team, AutoOps auch weiterhin zu nutzen, während die selbstverwaltete Infrastruktur auf OpenShift umgestellt wird.
Ihr Unternehmen verarbeitet heute vielleicht nicht 6 Milliarden Ereignisse pro Tag oder betreibt ein Leuchtturmwerk, aber egal ob Sie ein paar hundert oder 300.000 Endpoints schützen – es gilt das gleiche Prinzip: Eine Plattform, die es einem Team mit begrenzten Ressourcen ermöglicht, seine Zeit für Geschäftsziele und nicht für die Technik zu verwenden, verändert die Möglichkeiten dieses Teams. Für Siemens, ein Unternehmen, das Elektrifizierung, Automatisierung und Digitalisierung in nahezu jedem Land anbietet, ist Elastic die gemeinsame Datengrundlage sowohl für die globale Cyberabwehr als auch für seine meistbeachtete Fabrik.
„Der Weg in die Cloud ist nicht einfach, aber mit der Unterstützung von Elastic haben wir es in etwa einem Jahr geschafft. Ich glaube nicht, dass wir das in dieser Zeit mit einem anderen Anbieter hätten schaffen können.“
Erfahren Sie, wie Elastic Sicherheit und Beobachtbarkeit auf einer Datenplattform vereint oder starten Sie jetzt mit einer kostenlosen Testversion.