Zurück zur Übersicht

    OT-Fernzugriff: Warum das VPN längst zur Angriffsfläche geworden ist

    Laut BeyondTrust nutzte über die Hälfte der Ransomware-Vorfälle des Jahres 2024 einen Remote-Dienst als Eintrittspunkt — eine VPN-Appliance, einen RDP-Server. In OT-Umgebungen sind es dieselben Tunnel und Jump-Hosts, die den Betrieb am Laufen halten und den Angreifern die erste Tür öffnen.

    Veröffentlicht am von NEOSEC Intel Redaktion
    otnis2kritisremote-accessransomware

    Der stille Angriffspfad ins Werk

    Jede industrielle Umgebung hat sie: dauerhaft offene Tunnel, gealterte Jump-Hosts, Wartungszugänge von Dienstleistern, die nie ablaufen. Angelegt, um den Betrieb am Laufen zu halten. Heute die erste Adresse, an der Angreifer klopfen.

    Das Problem ist nicht das Verschlüsselungsprotokoll. Das Problem ist die Semantik klassischer VPN- und RDP-Zugänge: Einmal aufgebaut, weist die Sitzung dem Gegenüber keine konkrete Aufgabe zu — sie öffnet das Netz. Laterale Bewegung wird möglich, Zugangsdaten werden geteilt, aufgezeichnet wird nichts. Solange die Verbindung steht, ist der Wartungsdienstleister Teil des Werksnetzes.

    Für KRITIS-Betreiber unter NIS2 ist das kein akademisches Risiko. Ein kompromittierter VPN-Endpunkt in der IT wird binnen Stunden zum Sprungbrett Richtung Produktion — vorbei an der Purdue-Trennung, die genau das verhindern sollte.

    Wie groß dieser Anteil ist, hängt davon ab, wen man fragt. BeyondTrust nennt für 2024 einen Anteil von über 50 Prozent der Ransomware-Vorfälle mit einem Remote-Dienst als Eintrittspunkt und eine Zunahme von rund 60 Prozent bei Ransomware-Gruppen mit OT-Ausrichtung. Das sind Herstellerzahlen aus einem Produktumfeld, das genau dieses Problem adressiert — die Größenordnung deckt sich mit anderen Vorfallsauswertungen, die Prozentwerte sollte man nicht auf die Nachkommastelle nehmen.

    Was den klassischen Tunnel ablöst

    Die architektonische Antwort ist kein besseres VPN. Sie ist der Wechsel vom Netzwerk-Layer zum Anwendungs-Layer — unabhängig davon, mit welchem Produkt man ihn umsetzt:

    • Sitzungsabbruch in der DMZ, nicht im OT-Netz. Ein gehärteter Vermittler steht davor, eingehende Firewall-Ports bleiben zu, Verkehr fließt nie direkt zwischen den Purdue-Ebenen.
    • Identität statt IP-Adresse. Jede Verbindung hängt an einem benannten Menschen oder Dienstleister, nicht an einem Netzsegment. Die Autorisierung erfolgt bedarfsbezogen und befristet, idealerweise gekoppelt an das vorhandene Ticketsystem. Nach Abschluss der Aufgabe bleibt kein Zugriff bestehen.
    • Zugangsdaten aus dem Tresor. Anmeldedaten für SPS, HMI und Engineering-Arbeitsplätze werden zu Sitzungsbeginn eingespielt, anschließend rotiert und dem Dienstleister nie im Klartext gezeigt.
    • Legacy-Protokolle gekapselt. Auch nicht routbare oder proprietäre OT-Protokolle laufen durch einen verschlüsselten Kanal, ohne dass das Netz umgebaut werden muss.

    Der Unterschied ist strukturell, nicht graduell: Aus einem generischen Netzzugang wird ein spezifischer, auditierbarer, befristeter Anwendungszugang.

    Was das für den deutschen Mittelstand heißt

    Die meisten Fertiger betreiben Siemens SIMATIC, Phoenix-Contact-Komponenten, Schneider Modicon oder Rockwell. Für all diese Produktfamilien laufen monatlich neue Advisories auf — nachvollziehbar in unserem OT-Filter. Ein erheblicher Teil davon betrifft Fernzugriffs-Komponenten.

    Solange der Zugang zu diesen Systemen über einen dauerhaften Tunnel oder einen geteilten Jump-Host läuft, ist nicht die Frage, ob ein Angreifer den ersten Sprung schafft, sondern wann — und was ihm danach zur Verfügung steht.

    Ein Vermittler auf Anwendungsebene ist dabei nur die halbe Antwort. Die andere Hälfte ist ein durchgesetzter Prozess: keine dauerhaften Dienstleisterkonten, keine geteilten Service-Passwörter, kein Wartungsfenster ohne Ticket. Diese organisatorische Seite ist der Punkt, an dem im NIS2-Audit genauer hingesehen wird — nicht die Produktfrage, sondern der tatsächlich gelebte Zugangsprozess.

    Reality-Check für die eigene Umgebung

    Drei Fragen, die jeder Betreiber einmal sauber beantwortet haben sollte:

    1. Wie viele dauerhaft aktive Verbindungen aus Dienstleisternetzen sind gerade offen, und was können sie im OT-Netz erreichen?
    2. Wie viele geteilte Servicekonten existieren für SPS, HMI oder Engineering-Arbeitsplätze — und wann wurde deren Passwort zuletzt gewechselt?
    3. Können Sie rückwirkend belegen, welche Person welche Tätigkeit an welchem Gerät zu welcher Uhrzeit ausgeführt hat?

    Fällt eine dieser Antworten unangenehm aus, ist der Tunnel im Netz weniger Betriebsmittel als offene Tür.