Firewalls einsetzen, ohne den ICS-Datenverkehr zu unterbrechen

Einleitung

Die Integration von Firewalls in Industrial Control Systems (ICS) stellt IT-Sicherheitsexperten vor erhebliche Herausforderungen. Es gilt, robuste Sicherheitsmaßnahmen mit der Anforderung nach unterbrechungsfreiem ICS-Datenverkehr in Einklang zu bringen. Fehler können zu Betriebsunterbrechungen und erheblichen Ausfallzeiten führen. Dieser Artikel beschreibt wirksame Strategien für den Firewall-Einsatz, ohne den kritischen ICS-Datenfluss zu beeinträchtigen – mit Blick auf Netzwerktransparenz und Sicherheit.

Die Herausforderungen verstehen

Vor der Betrachtung von Einsatzstrategien ist es wichtig, die besonderen Herausforderungen in ICS-Umgebungen zu kennen:

• Echtzeitbetrieb: ICS-Systeme steuern häufig Echtzeitprozesse, bei denen Verzögerungen die Sicherheit und Effizienz beeinträchtigen können.
• Protokollvielfalt: Viele ICS-Umgebungen nutzen eine Mischung aus Legacy- und modernen Protokollen, was Kompatibilitätsprobleme verursacht.
• Verfügbarkeit vor Sicherheit: Historisch bedingt stand in ICS-Umgebungen die Betriebszeit und Verfügbarkeit vor strengen Sicherheitsmaßnahmen.
• Netzwerktransparenz: Eine umfassende Sichtbarkeit des Netzwerkverkehrs ist für die Überwachung und Absicherung von ICS-Umgebungen unerlässlich.

Wichtige Überlegungen zum Firewall-Einsatz in ICS

1. Umfassendes Netzwerk-Mapping

Ein gründliches Verständnis der Netzwerktopologie ist entscheidend. Dazu gehört:

• Identifikation kritischer Assets: Alle kritischen Assets und ihre Kommunikationswege erfassen.
• Protokollidentifikation: Alle verwendeten Protokolle dokumentieren, einschließlich Legacy-Protokollen, die besondere Behandlung erfordern.
• Verkehrsmuster: Normale Verkehrsmuster verstehen, um legitimen von potenziell schädlichem Datenverkehr zu unterscheiden.

2. Die richtige Firewall wählen

Die Wahl der geeigneten Firewall-Technologie ist entscheidend. Folgende Aspekte sind zu berücksichtigen:

• Protokollbewusste Firewalls: Firewalls bevorzugen, die Deep Packet Inspection unterstützen und industrielle Protokolle wie Modbus, DNP3 und OPC UA erkennen. Zu beachten ist, dass Deep Packet Inspection nur funktioniert, solange diese Protokolle im Klartext übertragen werden. Sobald OT Verschlüsselung einsetzt, verliert eine Firewall diese Sichtbarkeit – ein Proxy, der die Sitzung terminiert, behält sie hingegen (dazu mehr weiter unten).
• Skalierbarkeit und Leistung: Die Firewall muss das Datenvolumen ohne Latenzzunahme bewältigen können.
• Integrationsfähigkeit: Die Firewall sollte sich nahtlos in bestehende ICS-Sicherheitstools und -Frameworks integrieren lassen.

3. Strategische Firewall-Platzierung

Eine durchdachte Firewall-Platzierung kann die Sicherheit deutlich verbessern, ohne den Datenfluss zu beeinträchtigen:

• Perimeterschutz: Firewalls am Netzwerkperimeter einsetzen, um ein- und ausgehenden Datenverkehr zu filtern.
• Interne Segmentierung: Firewalls nutzen, um sichere Zonen im Netzwerk zu schaffen und sensible Bereiche vor unbefugtem Zugriff zu schützen.
• Redundanz und Failover: Redundante Pfade und Failover-Mechanismen implementieren, um die Konnektivität bei Firewall-Wartung oder -Ausfall aufrechtzuerhalten.

Proxy oder Firewall: Zwei Wege zur Kontrolle von OT-Datenverkehr

Eine Firewall und ein Proxy lösen verwandte Probleme auf unterschiedliche Weise – im OT-Bereich ist dieser Unterschied bedeutsam. Eine Firewall trifft eine Zulassungs- oder Ablehnungsentscheidung für ein Paket, das zwischen zwei Punkten weitergeleitet wird, basierend auf Quelle, Ziel, Port und – bei Deep Packet Inspection auf Legacy-Protokollen ohne Verschlüsselung – dem Protokoll. Das Paket gelangt dabei direkt vom Client zum Asset. Ein Proxy terminiert die Verbindung, autorisiert die vollständige Sitzung und öffnet anschließend eine separate Verbindung zum Asset. Nichts erreicht das Gerät, bevor der Proxy dies entschieden hat.

Dieser zusätzliche Schritt macht einen Proxy in industriellen Umgebungen so wertvoll:

• Verdeckung (Cloaking): Das Asset wird niemals direkt exponiert. Clients verbinden sich mit dem Proxy, sodass PLC, HMI oder Historian für Scanner und Angreifer im Netzwerk unsichtbar bleiben.
• Tiefere Sichtbarkeit: Da der Proxy die Sitzung terminiert, sieht er den vollständigen Austausch auf Anwendungsebene – Befehle und Nutzdaten, nicht nur Paketheader. Anders als die Deep Packet Inspection einer Firewall, die bei verschlüsseltem Datenverkehr blind wird, behält ein Proxy diese Sichtbarkeit, weil er Endpunkt der Sitzung ist und kein passiver Mithörer.
• Identitätsdurchsetzung: Der Proxy authentifiziert den Benutzer, bevor die Sitzung das Asset überhaupt erreicht – mit netzwerkbasiertem MFA und benutzerspezifischem Zugriff, auch für Geräte ohne Benutzerkontenverwaltung.
• Verschlüsselung: Der Proxy kann Klartext-Legacy-Protokolle wie Modbus und DNP3 zwischen Client und Proxy in TLS einbetten und sie dann nativ an das Asset weiterleiten. Das Gerät selbst muss keine Verschlüsselung unterstützen.

Der Grund dafür ist einfach: Ein Proxy ermöglicht den Einsatz von Sicherheitsmaßnahmen auf Assets, die diese nicht selbst bereitstellen können. Die meisten OT-Geräte können keinen Agenten ausführen, kein MFA erzwingen und kein TLS sprechen. Ein Proxy liefert diese Kontrollen an der Grenze vor dem Gerät, sodass ein Legacy-Controller Identität, Verschlüsselung und Auditierung erhält – ohne eine einzige Änderung am Asset.

Deshalb ist eine Firewall das falsche primäre Werkzeug für OT. Firewalls sind in der allgemeinen IT sinnvoll, wo Endpunkte sich selbst schützen können und Verschlüsselung bereits Standard ist. OT ist das Gegenteil: flache Netzwerke, Klartextprotokolle und Assets, die keine einzige eigene Sicherheitskontrolle bereitstellen können. Dort ist ein Proxy die bessere Wahl für Sichtbarkeit, Kontrolle und Schutz.

Trouts Access Gate ist das Gerät, das dies in der Praxis im großen Maßstab umsetzt. Es betreibt OT-Proxys im gesamten Werk und stellt die Dienste bereit, die diese Assets für einen sicheren Betrieb benötigen – DNS, Zeitsynchronisation, Fernzugriff und Dateifreigabe –, sodass Geräte, die nie für eine sichere Netzwerkanbindung ausgelegt wurden, sich verbinden können, ohne jemals exponiert zu sein.

Best Practices für minimale Betriebsunterbrechungen

1. Risikoanalyse durchführen

Vor dem Einsatz eine umfassende Risikoanalyse durchführen, um potenzielle Schwachstellen zu identifizieren und Prioritäten für die Firewall-Implementierung festzulegen. Dies entspricht den NIST 800-171- und CMMC-Anforderungen für das Risikomanagement.

2. Pilottests

Firewalls in einer Testumgebung einsetzen, um ihre Auswirkungen auf den ICS-Datenverkehr zu bewerten. Dabei überwachen:

• Latenzeffekte: Sicherstellen, dass der Echtzeitbetrieb nicht beeinträchtigt wird.
• Kompatibilitätsprobleme: Protokollverarbeitung und Interoperabilität mit bestehenden Systemen prüfen.

3. Schrittweise Einführung

Firewalls phasenweise einführen, um Unterbrechungen zu minimieren:

1. Mit unkritischen Bereichen beginnen: Den Einsatz in weniger kritischen Netzwerkbereichen starten.
2. Überwachen und anpassen: Die Netzwerkleistung kontinuierlich überwachen und notwendige Anpassungen vornehmen.
3. Einsatz ausweiten: Die Firewall-Abdeckung schrittweise auf kritischere Bereiche ausdehnen.

4. Kontinuierliche Überwachung und Protokollierung

• Echtzeitüberwachung: Netzwerküberwachungstools einsetzen, um Sichtbarkeit über Verkehrsmuster zu behalten und Anomalien zu erkennen.
• Log-Management: Robuste Protokollierungsmechanismen implementieren, um Firewall-Aktivitäten zu verfolgen und die Einhaltung von Standards wie NIS2 und CMMC zu unterstützen.

Netzwerktransparenz aufrechterhalten

Netzwerktransparenz ist für einen effektiven Firewall-Einsatz unerlässlich. Folgende Mittel sind zu erwägen:

• NetFlow-Analyse: Liefert Einblicke in Datenverkehrsflüsse und hilft, ungewöhnliche Muster zu identifizieren.
• Deep Packet Inspection: Ermöglicht die detaillierte Untersuchung von Paketinhalten und stellt sicher, dass nur legitimer Datenverkehr zugelassen wird.

Fazit

Beginnen Sie mit einer passiven Überwachungsbereitstellung – erfassen Sie eine vollständige Woche Datenverkehr auf dem Segment, auf dem Sie die Firewall einsetzen möchten. Nutzen Sie diese Aufzeichnung, um Ihre Allowlist-Regeln zu erstellen. Setzen Sie die Firewall zunächst im reinen Überwachungsmodus ein, überprüfen Sie, dass kein legitimer Datenverkehr blockiert würde, und wechseln Sie dann in den Durchsetzungsmodus. Diese Vorgehensweise beseitigt die häufigste Ursache für firewall-bedingte ICS-Ausfälle: Regeln, die Datenverkehr blockieren, dessen Existenz nicht bekannt war.