Die Teile 1 und 2 haben den IT-seitigen Cyber-Stack aufgebaut. Teil 3 behandelt die Disziplinen, die mit IT-Werkzeugen nicht abgedeckt werden: die Verteidigung industrieller Steuerungssysteme und operativer Technologie, die Bereitschaft für digitale Forensik zur Post-Kompromittierungs-Analyse und die Cross-Domain-Lösungen, die geeignete Daten zwischen klassifizierten Enklaven bewegen. Jede dieser Disziplinen ist spezialisiert, jede ist beschaffungsrelevant, und in jeder machen IT-geschulte Ingenieure am häufigsten Fehler. Teil 3 führt durch sie hindurch.

Die Säulen-Rahmung findet sich im Vollständigen Leitfaden zur Cybersicherheit in der Verteidigung. Die Klassifizierungsmaschinerie auf der Fusionsseite, an die dieser Teil anknüpft, findet sich in Aufbau einer Fusions-Pipeline für die Verteidigung, Teil 3; die NATO-Koalitions-Disziplin der Freigabefähigkeit ist in NATO-Interop-Implementierung, Teil 3 beschrieben.

Schritt 1: Warum ICS/OT-Verteidigung sich von IT unterscheidet

Der erste Fehler, den IT-geschulte Ingenieure bei ICS/OT machen, ist die direkte Anwendung von IT-Verteidigungsmustern. Die Muster lassen sich übertragen; die Werte nicht. ICS/OT-Verteidigung ist geprägt von strukturellen Unterschieden, die die IT-Disziplin unzureichend und manchmal sogar aktiv schädlich machen.

Die strukturellen Unterschiede:

  • Andere Protokolle. Modbus, DNP3, IEC 61850, OPC UA, BACnet — keines davon kommt in IT-Umgebungen vor. Werkzeuge, die IT-Protokolle dekodieren (HTTP, TLS, SMB, DNS), dekodieren diese nicht. ICS-spezifische Werkzeuge sind erforderlich.
  • Andere Patch-Rhythmen. Ein ICS-Controller kann jahrelang ohne Update bleiben — manchmal sogar nie. Wartungsfenster werden um operative Rhythmen herum geplant, nicht um Sicherheitskalender. „Einfach patchen" ist selten eine Option.
  • Andere Folgen. Ein IT-Ausfall kostet Verfügbarkeit. Ein ICS-Ausfall kann kinetische Folgen haben — Strom abgeschaltet, Wasserdurchfluss unterbrochen, Waffensystem deaktiviert, Logistik unterbrochen. Der Wirkungsradius prägt das Risikokalkül.
  • Andere Anbieterlandschaft. Honeywell, Siemens, Schneider Electric, Rockwell, Yokogawa — jeder mit eigenen Engineering-Konventionen, proprietären Protokollen und Anbietersupport-Verträgen. IT-Anbieterbeziehungen sind nicht übertragbar.
  • Andere Betreiber-Kultur. ICS-Betreiber haben einen ingenieurwissenschaftlichen, nicht einen IT-Security-Hintergrund. Das Sicherheitsgespräch muss technisch-ingenieurmäßig geführt werden, nicht sicherheitsingenieurmäßig. Das Vokabular unterscheidet sich.
  • Andere Scan-Richtlinien. Ein Schwachstellenscan, den ein IT-SOC für Routine hält, kann einen alten PLC vom Netz nehmen. Aktives Scannen ist die Standardvorgabe in der IT; in ICS ist es die falsche Vorgabe.

Die ausführliche ingenieurmäßige Behandlung von ICS/OT-Intrusionserkennungsmustern speziell für militärische Netze findet sich in ICS/OT-Intrusionserkennung in militärischen Netzen.

Schritt 2: Passives Monitoring als Standardvorgabe

Das ICS/OT-Verteidigungsmuster, das funktioniert: passives Monitoring als Standard, aktive Reaktion nur mit umfangreicher Betreiberkoordination.

Die Architektur des passiven Monitorings:

Erfassung über Network-Tap oder SPAN-Port. Der Erkennungssensor sieht den gesamten ICS-Netzwerkverkehr, injiziert aber niemals Pakete. Der Sensor kann den gesteuerten Prozess nicht beeinflussen.

Protokollbewusste Deep Packet Inspection. Der Sensor dekodiert Modbus, DNP3, IEC 61850, OPC UA, identifiziert die ausgeführten Operationen und erkennt Anomalien (unerwartete Befehle, fehlerhafte Pakete, ungewöhnliche Quelle-Ziel-Paare).

Asset-Erkennung aus passiver Beobachtung. Der Sensor identifiziert ICS-Assets anhand ihres Netzwerkverhaltens — Hersteller, Modell, Firmware-Version, Rolle — ohne aktives Sondieren. Das Asset-Inventar aus Teil 1 wird mit den Funden angereichert.

Verhaltens-Baselining. Über Wochen der Beobachtung baut der Sensor eine Baseline normalen ICS-Verhaltens auf. Abweichungen (Befehle zu unerwarteten Zeiten, Sequenzen, die nicht in der Baseline enthalten sind, Verkehr zu Assets, die nicht kommunizieren sollten) werden zu Alarmen.

Betreibergesteuerte Reaktion. Wenn der Sensor eine Anomalie erkennt, besteht die Reaktion darin, das Betriebsteam zu alarmieren, nicht eine automatisierte Aktion auszulösen. ICS-Betreiber haben den Kontext, um zu beurteilen, ob die Anomalie bösartig oder operativ ist.

Anbieterprodukte, die dieses Muster umsetzen: Dragos Platform, Claroty xDome, Nozomi Vantage, Tenable OT Security. Jedes hat seine eigenen Stärken bei der Protokoll-Dekodierung; die Beschaffung in der Verteidigung bewertet sie entsprechend der spezifischen OT-Umgebung.

Schritt 3: ICS/OT-spezifische Bedrohungsaufklärung

ICS/OT-Bedrohungsaufklärung ist eine eigene Disziplin. Generische IT-CTI-Feeds (in Teil 1 behandelt) verpassen ICS-spezifische TTPs: Techniken aus der Stuxnet-Familie, Industroyer-Varianten, TRITON, PIPEDREAM. Die dedizierten ICS-CTI-Quellen:

Dragos WorldView. Branchenführende ICS-Bedrohungsaufklärung. Deckt nationalstaatliche ICS-Akteure (ELECTRUM, XENOTIME, ALLANITE, andere) mit TTPs und Erkennungsinhalten ab.

CISA ICS-CERT-Hinweise. Öffentlich-sektorale ICS-Hinweise der U.S. Cybersecurity and Infrastructure Security Agency. Frei zugänglich, gut kuratiert.

NATO- und nationale CSIRTs. ICS-relevante Hinweise von NCIRC, BSI, ANSSI und Äquivalenten — insbesondere in Zeiten erhöhter Bedrohung.

Anbieter-Sicherheitshinweise. Jeder ICS-Anbieter veröffentlicht eigene. Abonnieren; in die CTI-Pipeline integrieren; Patch-Verpflichtungen nachverfolgen.

Die ICS-CTI fließt getrennt von der IT-CTI in die OT-spezifische Erkennungsschicht. Eine Vermischung verwässert das Signal — die meisten IT-CTI sind für OT irrelevant, und die OT-Umgebungen können das IT-Volumen nicht verarbeiten.

Schritt 4: Bereitschaft für digitale Forensik

Erkennung ohne Post-Kompromittierungs-Analyse ist nur eine halbe Fähigkeit. Programme für Cybersicherheit in der Verteidigung brauchen Bereitschaft für digitale Forensik — die ingenieurmäßigen Investitionen, die es ermöglichen zu rekonstruieren, was nach einer Kompromittierung geschehen ist.

Die Komponenten der Forensik-Bereitschaft:

Log-Aggregation mit langer Aufbewahrung. Nationalstaatliche Kampagnen verweilen monatelang. Ein SOC, das 30 Tage Logs aufbewahrt, kann eine 18-monatige Kampagne nicht rekonstruieren. Das Aufbewahrungsbudget unterstützt die Untersuchungszeiträume; gestaffelte Speicherung steuert die Kosten. Die Pipeline-Architektur aus Teil 2 muss dies berücksichtigen.

Tiefe Paketaufzeichnung, wo es die Bedrohungslage rechtfertigt. Selektive Full-Packet-Capture für Hochrisiko-Segmente. Der Speicherbedarf ist erheblich; der Wert ist unersetzlich, wenn eine Kompromittierung eine Rekonstruktion auf Netzebene erfordert.

Endpunkt-Telemetrie mit ausreichender Tiefe. Sysmon, EDR-Anbieter-Agent, Kommandozeilen-Auditing, Prozessbaum-Erfassung. Oberflächentelemetrie reicht für nationalstaatliche Untersuchungen nicht aus; Tiefe ist entscheidend.

Chain of Custody (Beweiskette) ab der Erfassung. Forensische Beweise müssen rechtlicher und Akkreditierungsprüfung standhalten. Erfassungsverfahren, Hash-Verifizierung bei jeder Übergabe, Dokumentation der Beweiskette. Ohne Beweiskette erfasste Evidenz ist operativ interessant, aber rechtlich unbrauchbar.

Forensische Analyse-Umgebung. Isoliertes Analysenetzwerk, geprüftes Toolset (Volatility, Autopsy, die SANS-DFIR-Suite), geschulte Analysten. Die Umgebung wird im Voraus bereitgestellt, nicht erst während des Vorfalls aufgebaut.

Reproduzierbare Analyse-Pipelines. Wiederholbare Analysen (Speicher-Forensik, Malware-Sandboxing, Indikator-Extraktion) werden skriptbasiert und versionskontrolliert umgesetzt. Manuelle Analysen skalieren nicht und überleben den Wechsel von Analysten nicht.

Die ausführliche Behandlung der Forensik im militärischen Cyber-Bereich findet sich in Digitale Forensik für militärische Cyber-Operationen.

Schritt 5: Cross-Domain-Lösungen

Verteidigungsnetze sind keine einzelnen Enklaven. Daten bewegen sich legitim zwischen Klassifizierungsstufen — ein nicht klassifizierter Bedrohungs-Intel-Feed in ein SECRET-SOC, eine auf Freigabefähigkeit geprüfte Vorfallszusammenfassung hinunter zu einem Koalitionspartner, OSINT, gesammelt in einem niedrig klassifizierten Netz und weitergeleitet an hoch klassifizierte Analysten. Diese Bewegungen erfolgen über Cross-Domain-Lösungen (CDS).

Die CDS-Landschaft:

Einweg-Datendioden. Hardware-erzwungene unidirektionale Verbindungen. Daten fließen nur in die genehmigte Richtung (typischerweise high-to-low für freigabefähige Produkte, low-to-high für die Aufnahme öffentlicher Informationen). Owl Cyber Defense, Forcepoint, Garrison sind gängige Anbieter.

Cross-Domain-Transfer-Guards. Software-Hardware-Kombinationen, die Daten zwischen Klassifizierungsstufen inspizieren, bereinigen und weitergeben. Flexibler als Dioden (bidirektional möglich), aber mit höherem Akkreditierungsaufwand.

Manuelle Prüfungs-Workflows. Wo Automatisierung nicht sicher entscheiden kann, genehmigen menschliche Prüfer spezifische Datenbewegungen. Die Plattform präsentiert den Kandidaten, erfasst die menschliche Entscheidung mit Zuschreibung und propagiert den genehmigten Transfer mit Audit-Trail.

Die ingenieurmäßige Integration:

  • Der Cyber-Stack integriert sich mit der CDS-Infrastruktur, ersetzt sie aber nie. CDS werden von akkreditierten Anbietern mit Zustimmung der nationalen Sicherheitsbehörden bereitgestellt; ein Eigenbau ist selten gerechtfertigt.
  • Audit-Protokollierung pro Transfer. Jeder Cross-Domain-Transfer wird mit Zuschreibung, Begründung und Inhaltsreferenz protokolliert. Das Audit-Log ist Akkreditierungs-Evidenz.
  • Klassifizierungs-Verifizierung an der Grenze. Daten, die in das CDS eintreten, werden auf angemessene Labels überprüft (STANAG 4774 gemäß Teil 3 der NATO-Interop-Serie); ausgehende Daten werden erneut verifiziert.
  • Bandbreiten- und Latenz-Erwartungen. CDS fügen Latenz hinzu. Operative Workflows nehmen die Latenz hin, statt gegen sie zu kämpfen.

Wichtige Erkenntnis: ICS/OT-Verteidigung und Cross-Domain-Lösungen sind die beiden Bereiche, in denen IT-Cyber-Ingenieure in Verteidigungskontexten am vorhersehbarsten versagen. Der Grund ist in beiden derselbe: Muster aus der kommerziellen IT lassen sich nicht sauber übertragen, und Ingenieure, die sie trotzdem anwenden, produzieren Plattformen, die entweder die Akkreditierung verfehlen, den Betrieb oder beides. Die Disziplin, beides als eigenständige Fachgebiete zu behandeln, ist strukturell.

Schritt 6: Netzsegmentierung zwischen IT und OT

Das Purdue-Modell ist die kanonische Referenz für die IT-OT-Netzsegmentierung. Verteidigungsumgebungen erweitern es häufig um eine klassifizierungsbewusste Segmentierung. Das Muster, das funktioniert:

Level 0-1 (Prozess und Sensorik). Die eigentliche physische Steuerung — PLCs, RTUs, Sensoren, Aktoren. Isoliert von der IT. Keine direkte IT-seitige Konnektivität.

Level 2 (Supervisory Control). Lokale HMIs und Engineering-Workstations. Mit Level 0-1 verbunden; minimal nach oben verbunden.

Level 3 (Site Operations). Betriebsdatenbanken, Batch-Management, Steuerungsserver. Hier leben die ICS-Level-Systeme.

Level 3.5 (DMZ). Der Übergang zwischen OT und IT. Die gesamte IT-OT-Kommunikation läuft hier durch, mit expliziten Datenfluss-Richtlinien und Erkennung.

Level 4-5 (Enterprise IT). Standard-IT-Umgebung. Hier arbeitet das SIEM/SOAR aus Teil 2 überwiegend.

Verteidigungs-Erweiterungen fügen eine zu den Purdue-Ebenen orthogonale Segmentierung nach Klassifizierungsstufen hinzu: ein nicht klassifiziertes OT-Netz für die Anlageninfrastruktur, ein NATO-RESTRICTED-OT-Netz für Koalitionsübungs-Infrastruktur, ein national klassifiziertes OT-Netz für die OT von Waffenplattformen. Jedes davon ist eine eigene segmentierte Umgebung mit eigenen Cross-Domain-Lösungen, wo Daten fließen müssen.

Schritt 7: Koordination der Incident Response für ICS/OT

Wenn ein ICS-Vorfall eintritt, ist die Reaktion mehrparteilich. Die IT-seitige Incident Response übernimmt die IT-Komponenten; OT-Betreiber kümmern sich um die operativen Komponenten; Sicherheitsingenieure beurteilen das Risiko des physischen Prozesses; Rechtsabteilung übernimmt die regulatorische Meldung (die für ICS in einigen Rechtsräumen spezifische Fristen hat); die Führung koordiniert die öffentliche Kommunikation.

Die ingenieurmäßigen Investitionen, die diese Koordination unterstützen:

Vorab etablierte Playbooks. ICS-spezifische Vorfalls-Playbooks, regelmäßig geübt, mit benannten Rollen und Kommunikationspfaden. Das Playbook liegt im Repository, ist versionskontrolliert und wird jährlich überprüft.

Tabletop-Übungen. Jährliche oder halbjährliche Übungen, die ICS-Vorfalls-Szenarien durchgehen. Sie decken Lücken in Playbooks, Kommunikationspfaden und technischen Fähigkeiten auf. Die ausführliche C2-Test-Disziplin, die diese Praxis prägt, findet sich in Test missions­kritischer C2-Systeme.

Team-übergreifendes Training. IT-SOC-Analysten, die nie OT-Umgebungen sehen, können nicht effektiv auf OT-Vorfälle reagieren. Cross-Training, OT-Umgebungs-Einweisung, gemeinsame Übungen.

Anbieter-Eskalationspfade. Vorab etablierte Supportbeziehungen mit den ICS-Anbietern. Während eines Vorfalls ist nicht der richtige Zeitpunkt zu entdecken, dass die Supportbeziehung rein vertraglich ist.

Wie es weitergeht

Teil 3 hat die spezialisierten Schichten behandelt. ICS/OT-Verteidigung mit passivem Monitoring als Standardvorgabe, dedizierte OT-Bedrohungsaufklärung, Forensik-Bereitschaft mit langer Aufbewahrung und Beweiskette, Cross-Domain-Lösungen für enklavenübergreifende Datenflüsse, Netzsegmentierung nach Purdue-Modell, Koordination der Incident Response für ICS.

Teil 4 schließt die Serie mit den Engineering-Pipeline- und Architektur-Disziplinen ab: DevSecOps, das Akkreditierungs-Evidenz als Nebenprodukt erzeugt, Zero-Trust-Militärnetze, SBOM und Lieferketten-Integrität, Ausrichtung an ISO 27001 und AQAP-2110 sowie die kontinuierliche Compliance-Haltung, die den Cyber-Stack über operative Lebenszyklen von 15 bis 20 Jahren akkreditiert hält.