Aufbau eines Cybersicherheits-Stacks für die Verteidigung, Teil 2: SIEM/SOAR für klassifizierte Enklaven

Teil 1 hat das Aufklärungsfundament gelegt. Teil 2 implementiert die Operations-Schicht, die diese Aufklärung konsumiert: SIEM aggregiert und korreliert Telemetrie, SOAR automatisiert die Reaktion, beide verdrahtet in die Netz-Topologie der klassifizierten Enklaven, die Cybersicherheit in der Verteidigung definiert. Kommerzielle SIEM- und SOAR-Produkte existieren; sie für den Verteidigungseinsatz zu engineeren, ist der Bereich, in dem die meisten Programme den Arbeitsaufwand unterschätzen. Teil 2 zeigt, wie diese Arbeit tatsächlich aussieht.

Die Rahmung auf Pillar-Ebene findet sich in Der vollständige Leitfaden zu Cybersicherheits-Software in der Verteidigung; die tieferen Engineering-Details zu SIEM/SOAR in SIEM und SOAR für militärische Integration.

Schritt 1: Bereitstellungsarchitektur pro Enklave

Die folgenreichste architektonische Einzelentscheidung: Betreiben Sie nicht eine SIEM-Instanz über mehrere Klassifizierungsstufen hinweg. Jede klassifizierte Enklave betreibt ihren eigenen SIEM/SOAR-Stack mit eigenem Datenspeicher, eigenen Detection-Content-Regeln und eigenem Audit-Log. Die Stacks sind physisch getrennt; Datenbewegungen zwischen ihnen laufen über akkreditierte Cross-Domain-Lösungen, niemals über geteilte Infrastruktur.

Die Begründung ist strukturell: SIEM-Daten sind eine Klassifizierungs-Obermenge ihrer Quellen. Ein SIEM, das SECRET-Netzwerk-Logs aggregiert, enthält SECRET-klassifizierte Inhalte; eine Zusammenführung dieses Speichers mit UNCLASSIFIED-Verwaltungs-Logs würde versehentlich die Klassifizierung des Verwaltungs-Speichers durch den Aggregations-Effekt des SIEM anheben. Isolation pro Enklave verhindert dies.

Das Bereitstellungsmuster für das laufende Beispiel:

• UNCLASSIFIED-SIEM — Verwaltungsnetze, internet-exponierte Assets, Lieferantenmanagement. Vom Anbieter bereitgestelltes SaaS kann hier akzeptabel sein.
• NATO-RESTRICTED-SIEM — Koalitions-Missionsnetze, FMN-angebundene Infrastruktur. Selbst gehostet auf akkreditierter Infrastruktur; Anbieter-SaaS selten akzeptabel.
• NATO-SECRET-SIEM — operative klassifizierte Netze. Selbst gehostet; vom Internet air-gapped; Updates über kontrollierte Kanäle.
• National klassifiziertes SIEM — nationale Systeme höherer Klassifizierung. Einzelquellen-Anbieter mit nationaler Akkreditierung; maßgeschneiderte Bereitstellung.

Enklavenübergreifende Aufklärungs-Weitergabe läuft über CTI-Propagierung (Mechanismus aus Teil 1) und über kontrollierte Zusammenfassungsberichte — nicht über geteilte SIEM-Dashboards.

Schritt 2: Die Log-Aggregations-Pipeline

SIEM ist strukturell eine Log-Pipeline mit darübergelegter Erkennung. Ist die Pipeline richtig, wird Erkennung handhabbar; ist sie falsch, dominieren die Pipeline-Kosten alles andere.

Die Pipeline-Stufen:

Sammlung. Agenten auf Endpunkten (Sysmon unter Windows, auditd unter Linux, EDR-Anbieter-Agenten), Netzwerk-Sensoren (NDR-Produkte, IDS-Appliances, NetFlow-Kollektoren), Anwendungs-Logs (Custom-Format und Syslog), Cloud-Control-Plane-Logs (sofern Cloud im Geltungsbereich liegt), OT-Telemetrie (Teil 3 dieser Serie).

Normalisierung. Heterogene Quellformate auf ein gemeinsames Schema normalisiert. Elastic Common Schema (ECS), OCSF, anbieterspezifische Schemata — eines wählen und konsequent ausrichten. Schema-Diskrepanzen sind im Produktivbetrieb eine wiederkehrende Quelle übersehener Erkennungen.

Anreicherung. Kontext hinzufügen, der dem Rohdaten-Log fehlt: Asset-Klassifizierung aus dem Inventar (Teil 1), CTI-Tags aus der Aufklärungs-Pipeline, Benutzerattribut-Kontext aus Identitätssystemen, Geolokation, Bedrohungsakteurs-Zuordnung.

Routing. Ereignisse fließen in den Hot-Tier des SIEM zur Live-Korrelation, in Langzeit-Cold-Storage für forensische Aufbewahrung und selektiv in den SOAR zur Playbook-Auslösung. Routing-Regeln sind explizite Policy.

Aufbewahrung. Cybersicherheit in der Verteidigung hat lange Aufbewahrungsanforderungen — nationalstaatliche Kampagnen verweilen Monate oder Jahre. Die Pipeline unterstützt gestaffelte Aufbewahrung: hot (Live-Korrelation), warm (jüngste forensische Abfragen), cold (Langzeit-Archivierung). Aufbewahrungsbudgets sind Programmentscheidungen; Unterbudgetierung erzwingt verfrühte Datenlöschung.

Schritt 3: Detection Content as Code

Out-of-the-box-Erkennungsregeln eines SIEM fangen Massenbedrohungen ab. Verteidigungstaugliche Erkennung fängt nationalstaatliche Bedrohungen ab. Die Lücke ist Detection Content: Regeln, zugeschnitten auf das Asset-Inventar, das Bedrohungsmodell und die CTI-Pipeline.

Die Disziplin von Detection Content as Code:

Sigma rules als Quellformat. Sigma ist das anbieterneutrale Detection-Regel-Format; in Sigma geschriebene Regeln werden in Splunk, Elastic, Sentinel, QRadar und andere konvertiert. In Sigma zu schreiben hält die Erkennung portabel; anbieterspezifisches Tuning erfolgt beim Deployment.

Regeln pro Asset und pro Bedrohungsakteur. Eine generische „PowerShell encoded command"-Erkennung fängt Rauschen ab. „PowerShell encoded command auf einem NATO-SECRET-Host von einem Benutzer, der nicht in der Engineering-OU ist" ist Signal. Das Asset-Inventar und das Bedrohungsmodell informieren die Spezifität der Regel.

CI-Tests gegen aufgezeichnete Ereignisdaten. Erkennungsregeln werden in der CI unit-getestet. Aufgezeichnete Ereignis-Traces aus früheren Vorfällen und Red-Team-Übungen dienen als Ground Truth. Eine Regeländerung, die den aufgezeichneten Vorfall nicht mehr erkennt, ist eine Regression, die den Merge blockiert.

MITRE ATT&CK-Mapping. Jede Regel mappt auf eine oder mehrere ATT&CK-Techniken. Das Mapping ermöglicht Coverage-Analyse (welche Techniken gut abgedeckt sind, wo blinde Flecken liegen) und beschaffungstaugliches Reporting über die Verteidigungslage der Plattform.

False-Positive-Management. Regeln erzeugen Alarme. Alarme erzeugen SOC-Last. Die Disziplin des FP-Tunings — Messung der FP-Rate pro Regel, Verfeinerung von Regeln zur Rauschreduktion, Stilllegung nicht abstimmbarer Regeln — ist strukturell. SOCs, die in FPs ertrinken, verfehlen die TPs.

Schritt 4: SOAR-Playbook-Engineering

SOAR (Security Orchestration, Automation, and Response) automatisiert die Reaktion auf erkannte Ereignisse. Ein Playbook ist ein versionierter, getesteter, prüfbarer Workflow, den der SOAR bei einem Alarm ausführt.

Die Playbook-Disziplin:

Versioniert in der Source-Control. Playbooks sind Code — YAML, JSON, anbieterspezifische DSLs. Sie liegen im Repository neben den Erkennungsregeln, werden vor dem Deployment geprüft und durchlaufen denselben Change-Control-Prozess wie Anwendungscode.

In der CI getestet. Aufgezeichnete Vorfall-Traces dienen als Testinputs. Ein Playbook, das gegen den aufgezeichneten Trace nicht mehr korrekt ausgeführt wird, blockiert den Merge.

Human-Confirmation-Gates für folgenreiche Aktionen. SOAR kann einen Host isolieren, ein Benutzerkonto deaktivieren, einen Netzwerkbereich blockieren, einen Prozess beenden. Jede dieser Aktionen hat operative Folgen. Das Playbook legt die vorgeschlagene Aktion offen und verlangt explizite menschliche Bestätigung; die Entscheidung wird protokolliert.

Audit-Trail bei jeder automatisierten Aktion. Auch Aktionen, die ohne menschliche Prüfung abgeschlossen werden (Alarm-Anreicherung, Ticket-Erstellung, Threat-Intelligence-Lookup), werden protokolliert. Der Audit-Trail ist die Beweisgrundlage für die Nachbereitung.

Rollback-Pfade. Eine SOAR-Aktion, die falsch war — falscher Host isoliert, falscher Benutzer deaktiviert — muss umkehrbar sein. Das Playbook-Engineering berücksichtigt dies von Anfang an; eine nachträgliche Reversibilität ist pro Aktion maßgeschneiderte Arbeit.

Schritt 5: CERT-übergreifende Integration

Cybersicherheit in der Verteidigung existiert in einer Community. Nationale CERTs (CISA, BSI, ANSSI, CCN-CERT), militärspezifische CSIRTs (US-CERT, NCSC, JCDC), Koalitions-CSIRTs (NATO NCIRC), Partner-CSIRTs. Die Plattform integriert sich bidirektional mit dieser Community.

Die Integrationsmuster:

Inbound-Aufklärungs-Konsum. CERT-Advisories fließen in die CTI-Pipeline (Teil 1) und lösen Aktualisierungen von Erkennungsregeln aus. Zeitkritische Advisories (aktive Schwachstellen-Ausnutzung, laufende Kampagnen-Attribution) erhalten priorisierte Bearbeitung.

Outbound-Vorfallmeldung. Bestätigte Vorfälle — insbesondere solche mit nationalstaatlichen TTPs oder koalitionsrelevanten Indikatoren — fließen ausgehend an das zuständige CERT über STIX/TAXII oder formelle Vorfallmeldungs-Kanäle. Die Meldung respektiert die Klassifizierung: NATO-SECRET-Vorfälle gehen an NCIRC, nicht an einen kommerziellen Anbieter.

Gemeinsames Hunting. Periodische Threat-Hunting-Kollaborationen mit Partner-CERTs — Abfragen über mehrere nationale Umgebungen hinweg, auf der Suche nach gegnerischen TTPs, die nur in der Aggregation sichtbar werden. Gemeinsames Hunting ist operativ wertvoll und politisch komplex; der Audit-Trail der Plattform unterstützt die rechtliche und policy-bezogene Prüfung.

Übungsteilnahme. Locked Shields, Cyber Coalition, Crossed Swords — NATO- und Partner-Cyber-Übungen, die die CERT-übergreifende Koordination testen. Teilnahme ist beschaffungstauglicher Fähigkeitsnachweis.

Schritt 6: Performance- und Skalierungsziele

SIEM/SOAR-Zielwerte, die operative Plattformen von Prototypen unterscheiden:

• Log-Aufnahme dauerhaft auf operativer Rate (typischerweise 50K–500K Ereignisse/Sekunde bei einem nationalen Verteidigungseinsatz) mit Surge-Handling bei 5× Baseline.
• Erkennungs-Latenz unter 60 Sekunden von Ereignis-Eingang bis Alarmerzeugung für zeitkritische Regeln; unter 5 Minuten für korrelationslastige Regeln.
• Playbook-Ausführungs-Latenz unter 30 Sekunden für die menschliche Prüfungs-Übergabe; volle Playbook-Vollendung innerhalb von Minuten für automatisierte Pfade.
• Speicheraufbewahrung in Jahren gemessen für hochklassifizierte Umgebungen; gestaffelt zur Kostensteuerung.
• Abfrageleistung unter 30 Sekunden für typische Analystenabfragen auf Hot-Daten; unter 5 Minuten für Cold-Data-Abfragen.
• Verfügbarkeit bei 99,9 %+ für Hot-Tier-Komponenten; degradierter Betrieb akzeptabel bei Cold-Tier-Ausfällen.

Das Verfehlen dieser Zielwerte ist meist Folge architektonischer Abkürzungen (unterdimensionierte Ingestion, fehlgeroutete Indizes, naive Abfragemuster). Programme, die explizit gegen diese Zielwerte prototypisieren, fangen die Abkürzungen vor dem operativen Einsatz ab.

Schritt 7: Anbieterauswahl für den Verteidigungseinsatz

Die Liste verteidigungstauglicher SIEM/SOAR-Anbieter ist kleiner als die kommerzielle Liste. Die Kriterien:

Akkreditierungs-Historie. Anbieter mit vorheriger Akkreditierung in NATO- oder Mitgliedsstaaten-Klassifizierungsnetzen verfügen über Nachweise, die Akkreditierungs-Prüfer glaubwürdig finden. Ein Kaltstart mit einem nicht akkreditierten Anbieter fügt 12–24 Monate zur Bereitstellung hinzu.

Air-Gapped-Einsetzbarkeit. Das Deployment des Anbieters muss in Umgebungen ohne Internet-Egress für Updates, Threat-Intel-Feeds oder Telemetrie funktionieren. Cloud-only-Produkte sind für höhere Klassifizierungen ausgeschlossen.

ITAR-freie Positionierung für europäische Programme. Siehe ITAR-freie Verteidigungssoftware für die Kriterien. Europäische Einsätze bevorzugen zunehmend ITAR-freie Anbieter.

Portabilität des Detection Content. Sigma-Unterstützung (oder vergleichbares anbieterneutrales Format) hält die Detection-Content-Basis der Plattform über Anbieterwechsel hinweg portabel. Anbieter-Lock-in beim Detection Content ist ein strategisches Risiko.

Offene APIs. SIEM/SOAR integriert sich mit allem anderen im Cyber-Stack — CTI-Plattform, EDR, Netzwerk-Sensoren, Identitätssysteme, Ticketing. Offene APIs sind nicht verhandelbar.

Die detaillierten Anbieterauswahlkriterien für Verteidigungssoftware allgemein finden sich in Wie man einen Anbieter für Verteidigungssoftware auswählt.

Was als Nächstes kommt

Teil 2 hat die Operations-Schicht aufgebaut. SIEM/SOAR-Architektur pro Enklave, Log-Aggregations-Pipeline, Detection Content as Code, SOAR-Playbook-Disziplin, CERT-übergreifende Integration, Performance-Ziele, Anbieterauswahl. Der Stack erkennt und reagiert nun in Skalierung innerhalb der Architektur klassifizierter Enklaven.

Teil 3 behandelt die spezialisierten Schichten: ICS/OT-Verteidigung für die Operations-Technology, die IT-taugliches Tooling nicht abdeckt, digitale Forensik-Bereitschaft für die Post-Kompromittierungs-Analyse und die Cross-Domain-Lösungen, die geeignete Daten zwischen Enklaven verschieben und ungeeignete Flüsse verhindern.