SIEM-Migration: So migrierst du sicher zu Google SecOps
Eine SIEM-Migration ist ein Security-Projekt: Du migrierst nicht nur Logs, sondern auch Detection-Logik, Use Cases, Betriebsprozesse und Compliance-Nachweise. Entscheidend sind sauberes Datenmapping, Parsing und Normalisierung sowie die Übersetzung und Validierung von Regeln (z. B. aus Splunk SPL). Mit einem phasenbasierten Vorgehen, messbaren KPIs und einem Parallelbetrieb reduzierst du Ausfallrisiken.
- Starte mit Discovery: Scope, Risiken, Prioritäten, Verantwortliche.
- Migriere in Wellen: erst kritische Datenquellen und Top-Detections.
- Miss Fortschritt: Datenabdeckung, Regel-Qualität, MTTD, Cutover-Reife.
Google SecOps hilft, Log-Telemetrie zu normalisieren und Detektions-Workflows zentral zu betreiben. Den Erfolg liefert die Validierung: Tests, Vergleichsläufe und ein sauberer Cutover-Plan.
Du fragst Dich, was das konkret für Euer Setup bedeutet? Schreib uns oder sichere Dir direkt Dein kostenloses Erstgespräch.
Definition
Eine SIEM-Migration ist die kontrollierte Überführung von Log-Daten, Parsing/Normalisierung, Detection-Regeln, Use Cases und Betriebsabläufen von einem bestehenden (Legacy-)SIEM in ein Ziel-SIEM. Sie ist weder ein reiner Datenexport noch eine automatische 1:1-Übersetzung aller Regeln ohne fachliche Neubewertung.
Einleitung
Wenn du ein Legacy-SIEM ablöst, geht es um messbare Detection-Qualität: erkennt dein SOC die relevanten Angriffe weiterhin, können Analysten sauber untersuchen, und bleibt alles auditierbar? Genau deshalb ist eine SIEM migration ein Phasenprojekt mit klaren KPIs, Tests und einem kontrollierten Cutover.
Wann eine SIEM-Migration sinnvoll wird
Typische Auslöser sind steigende Log-Kosten, zu viel Aufwand für Onboarding neuer Log-Quellen, technische Limits bei Suche/Reporting oder ein SOC, das im Alarmrauschen untergeht. Eine Modernisierung lohnt sich besonders, wenn du Use Cases standardisieren willst (einheitliche Felder, gleiche Queries, konsistente Dashboards) und die Detection Response wieder planbar machen musst.
Framework in 5 Phasen (mit deliverables)
Dieses Vorgehen funktioniert unabhängig davon, ob du von Splunk, QRadar, Elastic Security oder Microsoft Sentinel kommst.
- Phase 1: Discovery & Scope. Inventory (Quellen, Logs, Use Cases, Rules, Dashboards), Compliance Requirements, Risikoregister, Prioritätenliste.
- Phase 2: Datenmapping & Telemetry-Pipeline. Mapping-Tabelle, Parser-Plan, Normalisierungsziel (z. B. CIM/ASIM-Äquivalente), Ingestion-Tests.
- Phase 3: Rules & Detections übersetzen. Regelkatalog je Welle, Übersetzungsregeln (SPL/KQL/ES|QL), Testfälle, false-positive/false-negative Review.
- Phase 4: Validierung, Parallelbetrieb, SOC-Runbooks. Vergleichsläufe, Analyst-Playbooks, RBAC/Access-Konzept, Betriebsmonitoring.
- Phase 5: Cutover & Decommission. Cutover-Plan, Rückfallplan, Abschluss-Report (Audit-fähig), Stilllegung Legacy.
Daten: Mapping, Parsing und Normalisierung (die echte Arbeit)
Die häufigste Ursache für fehlende Detections ist nicht die Regel, sondern die Datenqualität. Beim Datenmapping definierst du, wie Quellfelder (z. B. user, src_ip, event_id) in Ziel-Felder überführt werden. Parsing stellt sicher, dass Zeitstempel, Hostnames, Identitäten und Aktionen korrekt extrahiert werden. Normalisierung sorgt dafür, dass Analysten nicht pro Quelle eine neue Query-Logik lernen müssen.
Nutzen für Anwender: Analysten finden schneller Zusammenhänge, weil Authentifizierung, Netzwerk und Endpoint-Telemetrie konsistent benannt und filterbar sind. Dashboards und Queries werden wieder wiederverwendbar, statt pro Log-Quelle neu gebaut zu werden.
Regeln übersetzen: von SPL zu neuer Logik, ohne Blindflug
Bei Splunk ist oft SPL (Search Processing Language) die Basis. In anderen SIEMs ist es eine andere Query Language (z. B. KQL in Microsoft Sentinel). Eine 1:1-Übersetzung ist selten, weil Datenmodelle, Feldnamen und Aggregationen abweichen. Vorgehen: Priorisiere Rules nach Risiko (Kronjuwelen, Identität, Admin-Aktionen), definiere Mindestdaten je Rule, und baue Tests mit bekannten Events.
Optional (wenn sinnvoll): Retrieval Augmented Generation (RAG) kann bei der Dokumentation helfen, indem bestehende Rule-Beschreibungen, Tickets und Runbooks durchsuchbar werden. Das ersetzt aber keine fachliche Freigabe der Detection-Logik.
Validierung, Testing und Cutover-Plan
Eine Migration gilt erst als “grün”, wenn sie im SOC-Alltag funktioniert. Plane Tests auf drei Ebenen: Datenfluss (kommt alles an?), Detection (triggert korrekt?), Betrieb (kann das Team reagieren?). Für den Cutover brauchst du ein definiertes Wartungsfenster, klare Rollen und einen Rückfallweg.
- Testing: Replay historischer Logs, synthetische Testevents, Vergleich “alt vs. neu” für Top-Use-Cases.
- Operational: Alert-Routing, Case-Handling, Eskalationen, Zugriff (RBAC), Audit-Logging.
- Cutover: Freeze-Fenster, Checkpoints, Abbruchkriterien, Kommunikationsplan.
KPIs: So misst du Fortschritt und Erfolg
Ohne Metriken wird der Projektstatus politisch. Nutze wenige, harte KPIs:
- Abdeckung: Anteil angebundener priorisierter Log-Quellen und Use Cases je Phase.
- Qualität: validierte Rules vs. Gesamtzahl je Welle, Trend der Fehlalarme, MTTD-Vergleich.
- Stabilität: Ingestion-Fehlerquote, Parser-Fehlerraten, Zeit bis zur Wiederherstellung bei Pipeline-Ausfall.
Praxisbeispiel (mini): Warum Detections verschwinden
Ein SOC migriert eine Detection auf “unmögliche Reise” bei Logins. Im Ziel-SIEM gibt es keine Treffer, obwohl die Aktivität existiert. Ursache: Die Identity-Telemetrie wurde ingestiert, aber die Geolocation-Felder wurden beim Parsing nicht normalisiert; die Rule filtert dadurch ins Leere. Nach Fix im Mapping und einem Replay-Test sind Treffer und Investigations wieder konsistent.
Security & Compliance während der Migration
Migration ist eine Hochrisiko-Phase: Daten werden exportiert, kopiert und parallel verarbeitet. Setze daher Mindestkontrollen: verschlüsselte Übertragung, gesicherte Export-Container, least-privilege Access, nachvollziehbare Änderungen an Parsern/Rules, dokumentierte Aufbewahrung. Kläre früh die Compliance Requirements (Zweckbindung, Fristen, Audit-Nachweise) und baue den Abschluss-Report so, dass er auditsicher ist.
Wann externe Unterstützung sinnvoll wird
Externe Unterstützung lohnt sich, wenn ihr viele Log-Quellen, knappe SOC-Ressourcen oder streng regulierte Anforderungen habt. Besonders kritisch wird es, wenn Rules aus einem Legacy-SIEM (z. B. Splunk) in eine andere Query-Sprache überführt werden müssen und ihr parallel Ausfallzeiten vermeiden wollt. Dann helfen klare Wellenplanung, regelbasierte Validierung und ein belastbarer Cutover-Runbook.
Fazit
Eine SIEM-Migration ist dann erfolgreich, wenn Datenqualität, Detection und Betrieb im Zielsystem nachweislich funktionieren. Migriere in Wellen, messe Fortschritt mit KPIs und sichere den Cutover mit Tests und Rückfallplan ab. So reduzierst du Risiko, bekommst wieder verlässliche Erkennungen und entlastest dein SOC nachhaltig.
Häufige Fragen
Was kostet eine SIEM-Migration?
Kosten hängen vor allem von Datenvolumen, Anzahl/Komplexität der Log-Quellen, Rule-Bestand, Parallelbetrieb und Compliance-Aufwand ab. Ein belastbarer Scope (Inventory + Prioritäten) ist die wichtigste Voraussetzung, um Aufwand realistisch zu bewerten.
Wie lange dauert eine SIEM migration typischerweise?
Das variiert stark. Entscheidend ist nicht “alles rüber”, sondern “kritische Quellen und Top-Detections in Produktion”. Viele Teams starten mit einer ersten Welle (Pilot) und planen weitere Wellen anhand der Testergebnisse und Ressourcenverfügbarkeit.
Welche Voraussetzungen müssen vor dem Projekt stehen?
Mindestens: Inventory der Datenquellen und Use Cases, Verantwortliche für Detection-Logik, Zugriff auf Quell- und Zielsysteme, geklärte Aufbewahrung/Datenschutz, sowie ein Testkonzept (Replay, Vergleichsläufe, Abnahmekriterien).
Was sind die häufigsten Hürden?
Uneinheitliche Logs (Parsing/Normalisierung), fehlende Doku zu Rules/Dashboards, Übersetzungsaufwand zwischen Query-Sprachen (z. B. SPL zu einer anderen Query Language) und zu wenig Zeit der SOC-Analysten für Validierung. Ohne Parallelbetrieb und KPIs werden Lücken oft erst nach dem Cutover sichtbar.
