Noch vor wenigen Jahren war das Thema Security im Bereich der Operational Technology (OT) im Vergleich zur klassischen IT kaum relevant. Dies änderte sich schlagartig, als erste – damals staatlich durchgeführte – Angriffe bekannt wurden. Heute sind Angriffe auf die OT bereits an der Tagesordnung.[1]
Im Folgenden sind die Grundlagen beschrieben, wie OT-Netzwerke auch im Falle einer Kompromittierung des Office-Netzwerks abgesichert werden können.
Entwicklung vom Nischenthema hin zum relevanten Risiko
Als Vorläufer von Angriffen auf die OT lässt sich Stuxnet nennen, der jedoch aufgrund des notwendigen Entwicklungsaufwands zu keiner grösseren Steigerung des Sicherheitsbewusstseins bei den Zuständigen im OT-Bereich führte. Durch die Anzahl an benötigten Zero-Day-Exploits und den Umfang des Know-hows, das für die Erstellung einer solchen Malware erforderlich war, sah sich kaum jemand als potenzielles Opfer.
Fünf Jahre später, 2015, wurden in der Ukraine erfolgreiche Angriffe auf das Stromnetz bekannt, die Stromausfälle für eine Vielzahl von Endkunden zur Folge hatten.[2]
Dieser Fall war ein Game-Changer. Mithilfe vergleichsweise simpler Angriffe wurden grosse Teile des Stromnetzes für mehrere Stunden lahmgelegt. Durch Phishing in Verbindung mit der anschliessenden Ausnutzung gängiger OT-Schwachstellen wie Standardpasswörter, stark veraltete Softwareversionen mit bekannten Sicherheitslücken etc. (siehe Oneconsult Blog OWASP IoT Top 10 – Teil 1) konnten die Angreifer ohne grössere Hindernisse die Steuerungsanlagen manipulieren.
Dadurch wurden selbstverständlich auch Kriminelle auf dieses Angriffsziel aufmerksam. Die in etwa zur gleichen Zeit zunehmenden Ransomware-Angriffe (z.B. mit dem prominentesten Vertreter Emotet) hatten nun neben der IT auch die OT als Ziel[4]. Da die Wiederherstellung eines OT-Netzwerks deutlich aufwendiger ist als die behelfsmässige Instandsetzung der klassischen Office-IT, sind vermutlich viele Unternehmen eher bereit, bei einem Ransomware-Angriff den Lösegeldforderungen nachzukommen, wenn auch die OT betroffen ist. Der erhöhte Aufwand bei der Wiederherstellung hat verschiedene Ursachen. So sind häufig sehr viele OT-Geräte im Einsatz, verglichen mit einer meist überschaubaren Anzahl an Servern in der Office-IT. Auch gestaltet sich der Zugriff relativ schwierig. Bei einer mit Malware befallenen Anlage ist der Zugriff auf den Steuerungs-PC oft nicht einfach. Auch wird hier meist eine bestimmte vorinstallierte Software o.ä. benötigt. Durch die lange Lebensdauer der Anlagen ist es jedoch unwahrscheinlich, dass der Hersteller ein Wiederherstellungs-Image anbietet.
Mithilfe geeigneter Massnahmen kann eine Kompromittierung des OT-Netzes verhindert oder zumindest abgeschwächt werden. Dieser Artikel behandelt technische Aspekte – Prozesse zum Beispiel zur Wartung von Systemen oder zur Schulung von Mitarbeitenden werden nicht gesondert erwähnt.
Erster Schritt – Korrekte Trennung von OT und IT
Das Ausgangsszenario in diesem Artikel geht von einer klassischen Office-IT und einer OT-Infrastruktur mit ihrer gesamten Komplexität aus. Ressourcen zur möglichen Absicherung von IT-Netzwerken sind beispielsweise unter [5] zu finden.
Im Bereich der OT sind andere Angriffsszenarien relevant. Hat sich ein Angreifer erst einmal einen ersten Zugang zum OT-Netzwerk verschafft, hat er in der Regel leichtes Spiel. Hersteller von Produktionsanlagen bzw. den zugehörigen Steuerungen bieten nur in Ausnahmefällen über die teilweise Jahrzehnte lange Lebensdauer Updates für die Systeme an. In fast allen Fällen lassen sich Angriffe auf stark veraltete Betriebssysteme oder Programme mittels automatisierter Tools mit nur wenigen Klicks durchführen – technisches Verständnis ist entgegen vielen Angriffen in der Office-Welt somit nur bedingt notwendig. Wie lässt sich also eine Umgebung schützen, die intern so gut wie keine Verteidigungsmassnahmen aufweist?
Anhand des häufigsten Angriffsszenarios – eine Ausbreitung des Angriffs von der klassischen IT hin zur üblicherweise schlecht abgesicherten OT – wird direkt der gängigste und wichtigste Schritt ersichtlich, wie eine Produktionsumgebung gegen Angriffe abgesichert werden kann. Um ein Übergreifen von Malware auf die OT zu verhindern, müssen die Produktionsnetzwerke von den Office-Netzwerken getrennt werden. Dazu wird eine Demilitarized Zone (DMZ) verwendet. Eine solche DMZ findet sich normalerweise bereits zwischen Office-Netzwerken und dem Internet, das gleiche Prinzip kann intern nochmals angewendet werden. Statt beispielsweise Telemetriedaten der Produktionsanlagen direkt von einem System im Office-Netzwerk abzurufen, würde ein Server in der DMZ die Daten entgegennehmen, und das System im Office-Netz könnte nur auf diesen Industrial-DMZ-Server (IDMZ) zugreifen. Die Firewallregeln geben im Idealfall nur das für die Telemetriedaten benötigte Protokoll (z.B. SFTP) für die Kommunikation aus dem jeweiligen Netzwerksegment hin zum Server in der DMZ frei. Ansonsten sollte eine «Deny-by-Default»-Policy angewendet werden, d.h. sämtlicher nicht explizit freigeschalteter Zugriff sollte standardmässig blockiert werden. Eine Kommunikation aus dem Office-Netz hin zum OT-Netz ist nicht mehr möglich.
Hier entsteht jedoch auch ein weiterer möglicher Angriffspunkt: Da bereits durch kleine Ungenauigkeiten bei der Firewallkonfiguration die Netzwerksegmentierung zunichte gemacht werden kann, ist besondere Vorsicht geboten. Eine ungenau gesetzte Firewallregel führt im schlimmsten Fall dazu, dass der gesamte Aufwand der Einrichtung einer DMZ umsonst war. Für einen Angreifer bedeutet das minimalen Mehraufwand – er muss nur herausfinden, welches IT-System mit welchem OT-System fälschlicherweise noch kommunizieren kann. Eine einzige Verbindung reicht aus, um dem Angreifer das Tor zur OT zu öffnen.
Bewährte Prozesse wie das 4-Augen-Prinzip beim Setzen bzw. Verändern der Firewallregeln und regelmässige Audits können Abhilfe schaffen und die Wahrscheinlichkeit einer Fehlkonfiguration stark vermindern.
Die Implementierung einer internen DMZ stellt somit den ersten und wichtigsten Schritt für den Schutz der OT dar.
Absicherung von Lieferantenzugängen
Hierbei kann und sollte man es nicht belassen. Da es eine Vielzahl an Angriffsvektoren auf die OT gibt und der Weg über die Office-IT nur einer davon ist, deckt die Implementierung einer IDMZ nur einen der Vektoren ab. Ein weiterer häufig genutzter Angriffspunkt sind Lieferanten- bzw. Herstellerzugänge. Oft kommt es vor, dass der Hersteller eines Produktes Zugriff auf das Gerät über eine VPN-Verbindung fordert, meist um Wartungsaufgaben durchführen oder Telemetriedaten auslesen zu können. Der nächste Punkt in der Absicherung von Produktionsnetzwerken ist die Netzwerksegmentierung. Schafft es nun ein Angreifer, das Netzwerk des Lieferanten zu kompromittieren, ist ein solcher VPN-Zugang ein willkommener Türöffner. Nach der Kompromittierung des Lieferanten werden Angreifern dadurch ohne Zusatzaufwand weitere potenzielle Erpressungsopfer sozusagen auf dem Silbertablett serviert. Durch den direkten Zugang sind keine zusätzlichen Sicherheitsvorkehrungen zu erwarten.
Der beste Weg ist, Lieferanten keinen Fernzugriff zu gewähren. Ist dies aus vertraglichen Gründen nicht möglich, sollte der Lieferantenzugang vollständig vom restlichen Netzwerk getrennt werden. Dadurch hat der Lieferant ausschliesslich auf die Geräte Zugriff, die auch von diesem Lieferanten gewartet werden. Wird also eine eigene Subzone verwendet, kann dadurch auch im Falle einer Kompromittierung des Lieferanten verhindert werden, dass weitere Geräte oder Netzwerke übernommen werden. Hier werden auch die Grenzen dieses Systems deutlich: Selbst mit bester Segmentierung des Lieferantenzugangs kann nicht verhindert werden, dass ein Angreifer die jeweilige Anlage übernimmt. Besonders bei der Wartung oder bei einer potenziellen Fehlerbehebung dieser Anlagen sollte somit davon ausgegangen werden, dass bereits Schadcode auf der Anlage ausgeführt wird. Bei einer Verbindung mit Diagnosesystemen bzw. USB-Sticks für Updates o.ä. sollte dies in den jeweiligen Policies und Richtlinien berücksichtigt werden. So kann verhindert werden, dass ein USB-Stick, der für ein Update auf einer Anlage mit Herstellerzugang genutzt wird, dort infiziert wird, und anschliessend wieder in der restlichen Umgebung verwendet wird.
Auch in der OT unerlässlich: Backups
Oft ein leidiges Thema, denn trotz des hohen Aufwands bei der Anschaffung und beim Betrieb von Backup-Systemen wird ihr Nutzen meist nur im Notfall ersichtlich. Fällt die Entscheidung auf eine einfache Lösung, z.B. ein Backup-Server im OT-Netzwerk, wird der Backup-Server bei einer Malwareinfektion ebenfalls verschlüsselt bzw. kompromittiert. Abhilfe schaffen hier WORM-Medien (Write Once Read Many) oder Offline-Backups. Nach dem Beschreiben mit dem jeweiligen Softwarestand können die Medien nachträglich nicht mehr verändert werden. Als Offline-Backup können verschiedene Systeme verwendet werden. Die einfachste Lösung stellen Festplatten dar, auf die der Softwarestand regelmässig übertragen wird. Dies hat jedoch den Nachteil, dass die Speichermedien bei der Durchführung der Backups wieder mit dem Netzwerk verbunden werden müssen, wodurch auch das Backup mit Malware infiziert werden kann.
Gleichermassen zu beachten sind die Aufbewahrungsfristen von Backups, da sich auch Malware weiterentwickelt. Wird die Malware sofort nach einer initialen Infektion aktiv, stehen die Chancen gut, dass ein Backup erfolgreich eingespielt werden kann. Aus diesem Grund bleibt aktuellere Malware oft für längere Zeit (zum Teil mehrere Monate) inaktiv, wodurch die Wahrscheinlichkeit kompromittierter Backups deutlich steigt. Nach der Wiederherstellung der Backups wurde dann nichts gewonnen, die Malware ist weiterhin im System. Entsprechend sollte beurteilt werden, wie lange die Backups aufbewahrt werden.
Ein weiterer zu berücksichtigender Punkt bei Backups kann Parameter wie Temperaturbereiche oder verschiedene Messgrössen von Steueranlagen betreffen. Wird die Steuersoftware bzw. die Serverstruktur zwar erfolgreich aus einem Backup wiederhergestellt, aber die genauen Einstellungen bzw. Parameter sind nicht griffbereit, verzögert sich ein erfolgreicher Wiederanlauf der Produktion zusätzlich. Ist dieser Aspekt in der betrachteten Umgebung relevant, sollten diese Werte ebenfalls in der Backup-Planung bedacht werden.
Zudem wird in der Praxis oft beobachtet, dass im Falle eines Sicherheitsvorfalls zwar Backups vorliegen, sich der Prozess der Wiederherstellung aber dennoch über Wochen zieht. Dies kann falsch konfigurierten Backups geschuldet sein oder an mangelnder Erfahrung mit dem Wiedereinspielen von Backups liegen. Aus diesem Grund sollten regelmässige Recovery-Tests fester Bestandteil des Backup-Prozesses sein. So wird sichergestellt, dass die Backups korrekt funktionieren und das nötige Know-how vorhanden ist, um im Notfall rasch handeln zu können.
Fazit
Die hier vorgestellten Punkte zeigen ein Grundgerüst der OT-Sicherheit auf. Je nach Anwendungsfall bzw. abhängig von den zu schützenden Ressourcen kann dies bereits ausreichen. Bei Branchen oder Anlagen mit deutlich höherem Schutzbedarf sollten die Schutzmassnahmen noch weit darüber hinaus gehen.
Dieses Grundgerüst kann – bei sauberer Implementierung und regelmässiger Wartung und Auditierung – aber das Übergreifen eines erfolgreichen Angriffs auf die Office-IT auf die OT verhindern oder aber abschwächen. Entgegen der Anfangsinvestition zur sauberen Trennung der Netzwerke stehen Fälle, in denen ganze Anlagen unbrauchbar werden, da ihre Steuersysteme durch Ransomware verschlüsselt sind und eine Wiederherstellung mangels verfügbarer Firmware nicht mehr möglich ist.
Eine genaue Einschätzung, welche Massnahmen sinnvoll sind, ist stark vom jeweiligen Fall abhängig. Wenn Sie Beratung, Unterstützung oder Empfehlungen zur Absicherung Ihrer OT-Umgebung benötigen, kontaktieren Sie jederzeit gerne das Oneconsult-Team.
Autor
Seit August 2018 ist Jakob Kunzmann bei der Oneconsult als Penetration Tester angestellt und wurde per August 2021 zum Team Leader Penetration Testing befördert. Er ist Offensive Security Certified Professional (OSCP), zertifizierter OSSTMM Professional Security Tester (OPST) und Certified Red Team Operator (CRTO).
