PLC-Sicherheit. Schützen Sie die Controller, die sich nicht selbst schützen können.
PLC-Sicherheit bedeutet, die Controller zu schützen, die physische Prozesse steuern, indem man Identität, Segmentierung und Audit vor Geräten durchsetzt, die sich nicht selbst verteidigen können.
Zuletzt aktualisiert:
PLC-Sicherheit bedeutet, die speicherprogrammierbaren Steuerungen (PLC) zu schützen, die physische Prozesse steuern. Die meisten Controller im Feld, etwa Siemens S7, Rockwell ControlLogix und Schneider Modicon, können weder einen Benutzer authentifizieren noch ihren Datenverkehr verschlüsseln, sich patchen lassen oder einen Agenten ausführen. Deshalb sichert man eine PLC nicht auf dem Gerät ab. Man sichert sie vorgelagert ab: Ein lokaler industrieller Proxy vermittelt jede Verbindung, prüft, wer anfragt, lässt nur die Befehle zu, die jeder Benutzer braucht, hält die PLC aus dem flachen Netzwerk heraus und zeichnet die Sitzung auf. Das ist eine kompensierende Maßnahme, und sie lässt sich auf IEC 62443 und NIST 800-82 abbilden. Es geht um physische Folgen: Ein manipulierter Controller verändert einen Prozess, ein falscher Befehl bedeutet also eine stehende Linie, beschädigte Anlagen oder einen unsicheren Sollwert.
Warum PLCs schwer abzusichern sind
Eine PLC ist ein robuster Controller, gebaut, um einen Prozess zwanzig Jahre lang zu steuern, nicht, um sich in einem Netzwerk zu verteidigen. Die Baureihen in den meisten Anlagen, Siemens S7-1200 und S7-1500, Rockwell ControlLogix und CompactLogix sowie Schneider Modicon, haben vier gemeinsame Schwachstellen.
Sie lassen sich nicht patchen
Hersteller liefern selten Firmware-Updates, und einen laufenden Controller kann man nicht offline nehmen, um sie einzuspielen. Bekannte Schwachstellen bleiben jahrelang offen, viele davon in den ICS-Advisories der CISA aufgeführt. "Wir können es nicht patchen" genügt daher weder einem Auditor noch einem Cyber-Versicherer. Sie erwarten eine dokumentierte kompensierende Maßnahme, kein akzeptiertes Risiko.
Sie vertrauen standardmäßig
Die meisten PLC-Protokolle bieten ab Werk keine Authentifizierung und keine Verschlüsselung. Modbus/TCP (port 502), Siemens S7comm (port 102), EtherNet/IP CIP (44818), DNP3 (port 20000) und Profinet erlauben jedem Gerät im Netzwerk, Register zu lesen oder zu schreiben und Befehle zu senden. Sichere Varianten existieren, S7comm-plus, CIP Security und DNP3 Secure Authentication, doch sie sind optional und selten aktiviert.
Sie werden mit Standard-Zugangsdaten ausgeliefert
Standard- und fest codierte Passwörter sind verbreitet und gut dokumentiert. Die meisten werden nie geändert, weil eine Änderung eine funktionierende Integration zerstören könnte.
Ein VLAN reicht nicht mehr
PLCs, HMIs und Engineering-Workstations teilen sich oft ein flaches Netzwerk, und sie in ein VLAN zu stecken, reicht nicht mehr. Ein VLAN trennt den Datenverkehr, kontrolliert aber nicht, wer einen bestimmten Controller erreichen darf, und zeichnet nicht auf, was dort getan wurde. Portbasierte Zugangskontrolle wie 802.1X hilft, ist im Anlagenmaßstab aber aufwendig zu betreiben und zu pflegen, und ihre Logs lassen sich schwer damit verknüpfen, was ein Benutzer tatsächlich am Controller getan hat. Die Engineering-Workstation ist der Schwachpunkt, denn auf ihr läuft die Software, die die PLC programmiert (TIA Portal, Studio 5000). Das Ziel ist granularer, nachvollziehbarer Zugriff auf die Maschine selbst, pro Benutzer und pro Befehl, nicht nur eine Netzwerkzone.
Wie PLCs angegriffen werden
Die meisten PLCs führen jeden gültigen Befehl aus, den sie über ein nicht authentifiziertes Protokoll erhalten, der Angriffsweg ist also kurz. Das ist keine Theorie: Von den Unitronics-Einbrüchen 2023 bei US-Wasserversorgern, die noch Standard-Zugangsdaten verwendeten, bis zu den bis 2026 verfolgten Vorfällen finden CISA und OT-Bedrohungsforscher immer wieder Controller, die im Internet exponiert sind oder Standard-Zugangsdaten nutzen. Die folgenden Techniken sind dieselben, abgebildet auf MITRE ATT&CK for ICS.
| Taktik | Technik (ID) | Was auf einer PLC passiert |
|---|---|---|
| Initial Access | External Remote Services (T0822) | Ein Hersteller-VPN oder Jump-Host verschafft einem kompromittierten Dritten weiten Zugriff auf das OT-Netzwerk. |
| Initial Access | Internet Accessible Device (T0883) | Eine im Internet exponierte PLC wird über Shodan oder Censys gefunden und direkt erreicht. |
| Lateral Movement | Default Credentials (T0812) | Dokumentierte Standard-Passwörter lassen einen Angreifer sich am Controller anmelden. |
| Execution | Unauthorized Command Message (T0855) | Ohne Authentifizierung schreibt eine präparierte Modbus- (port 502) oder S7comm-Nachricht (port 102) Register oder verändert die Logik. |
| Execution | Program Download (T0843) | Eine kompromittierte Engineering-Workstation nutzt TIA Portal oder Studio 5000, um veränderte Logik auf den Controller zu übertragen, über denselben Weg, den ein echter Ingenieur nutzt. |
| Impair Process Control | Manipulation of Control (T0831) | Veränderte Sollwerte oder Logik treiben den Prozess in einen unsicheren Zustand: eine chemische Dosierung überhöhen, eine Leitung überdrucken oder eine Anlage über ihr Limit hinaus zwingen. |
Eine PLC absichern, ohne sie anzufassen
Die meisten PLCs lassen sich nicht direkt härten, also ergänzt man die fehlenden Kontrollen vorgelagert: Identität, minimale Rechte und eine Aufzeichnung, die das Gerät nie hatte. Genau das leistet Trout Access Gate. Es ist ein widerstandsfähiger industrieller Proxy, der lokal vor Ihren Controllern läuft und identitätsgebundenen Zugriff, Allowlisting pro Befehl, Mikrosegmentierung und lückenloses Audit durchsetzt, ohne Agenten auf der PLC und ohne Ausfallzeit bei der Einführung. Auditoren nennen das eine kompensierende Maßnahme. Keiner der sechs Schritte unten berührt den Controller.
01Einen Durchsetzungspunkt vor den Controller setzen
Trout Access Gate liegt im Pfad zur PLC und vermittelt jede Verbindung. Der Controller wird nie angefasst oder gepatcht, und der Proxy bleibt für den Prozess transparent, beeinflusst also weder das Timing der Regelschleife noch ein angebundenes Sicherheitssystem (SIS).
02Jede Verbindung über die Identität authentifizieren
Binden Sie den Zugriff an einen benannten Benutzer oder ein benanntes Gerät über Ihr Verzeichnis (Active Directory, Microsoft Entra ID), mit MFA auf der Netzwerkebene, nicht an eine geteilte IP oder ein geteiltes Passwort.
03Nur zulassen, was jeder Benutzer braucht
Begrenzen Sie den Zugriff pro Anlage, Protokoll und Befehl. Ein Ingenieur erreicht die PLCs, für die er zuständig ist; ein Hersteller erreicht eine Maschine für eine Aufgabe, zeitlich befristet.
04Die PLC aus dem flachen Netzwerk heraussegmentieren
Setzen Sie Mikrosegmentierung ein, damit eine kompromittierte Workstation den Controller nicht erreichen kann, ohne VLAN-Umbau und ohne Neuvergabe von IP-Adressen.
05Jede Sitzung aufzeichnen
Führen Sie eine manipulationssichere Aufzeichnung darüber, wer sich mit welchem Controller über welches Protokoll verbunden hat und welche Befehle ausgeführt wurden, bereit für ein Audit oder einen Vorfall.
06Den Prozess am Laufen halten, wenn die Durchsetzung ausfällt
Der Proxy liegt nun im Pfad, also bauen Sie ihn auf Verfügbarkeit aus: Betreiben Sie ihn mit Failover, damit ein einzelner Fehler den Prozess nie stoppt, und geben Sie den Bedienern einen dokumentierten Break-Glass-Weg, der selbst protokolliert wird.
Was eine kompensierende Maßnahme liefern muss
Eine Kontrolle, die keine Nachweise liefern kann, ist keine Kontrolle. Auditoren und Cyber-Versicherer akzeptieren Aufzeichnungen, keine Behauptungen. Für jeden Controller hinter dem Proxy sollten Sie Folgendes exportieren können:
- Identitätszuordnung: der benannte Benutzer oder das benannte Gerät hinter jeder Sitzung, nicht eine IP oder ein geteiltes Konto.
- Nachweis minimaler Rechte: der pro Anlage und pro Befehl zulässige Umfang, den jede Identität hatte.
- Aufzeichnungen auf Befehlsebene: welche Protokollbefehle und Registerschreibvorgänge den Controller erreichten und welche blockiert wurden.
- Manipulationssichere, zeitsynchrone Logs mit angegebener Aufbewahrungsfrist, damit eine Zeitachse eine Untersuchung übersteht.
- Abdeckung: welche Controller hinter der Durchsetzung liegen und welche nicht, verknüpft mit dem Anlageninventar.
- Nachweis der Umgehungssicherheit: Durchsetzung im Pfad, nicht Erkennung außerhalb, mit selbst protokolliertem Break-Glass-Weg.
- Die Zuordnung: jeder Punkt an die konkrete Anforderung aus IEC 62443, NIST 800-82, CMMC oder NERC CIP gebunden, die Ihr Prüfer testet. Die Nachweise bleiben lokal, nicht in einer Hersteller-Cloud.
Checkliste PLC-Sicherheit
Eine praktische Reihenfolge, um eine Flotte von Controllern abzusichern, vom Inventar bis zur Framework-Zuordnung.
| # | Aktion | Detail |
|---|---|---|
| 01 | Jede PLC inventarisieren | Erstellen Sie ein aktuelles Inventar von Controllern, HMIs und RTUs, einschließlich Altgeräten, die keinen Agenten ausführen können. Nutzen Sie passive Erkennung: Ältere CPUs können bei einem aktiven Scan ausfallen oder I/O verlieren, scannen Sie einen laufenden Controller daher niemals aktiv. |
| 02 | Internet-Exposition beseitigen | Nehmen Sie PLCs von jedem aus dem Internet erreichbaren Pfad, und stellen Sie sicher, dass keine über Shodan oder Censys exponiert ist. |
| 03 | Standard-Zugangsdaten ändern oder vorlagern | Ersetzen Sie Standard-Passwörter, wo es geht; wo nicht, setzen Sie die Authentifizierung vor dem Gerät durch. |
| 04 | Identität und MFA auf der Netzwerkebene durchsetzen | Verlangen Sie eine benannte, MFA-gestützte Authentifizierung, bevor eine Sitzung einen Controller erreicht. |
| 05 | IT von OT und PLC von PLC trennen | Mikrosegmentieren Sie, sodass laterale Bewegung zu Controllern blockiert wird, ohne Neuverkabelung. |
| 06 | Hersteller- und Fernzugriff kontrollieren | Vermitteln Sie Drittanbieter-Zugriff pro Anlage, zeitlich befristet und aufgezeichnet, und schaffen Sie dauerhafte VPN-Konten ab. |
| 07 | Sitzungen aufzeichnen und aufbewahren | Führen Sie manipulationssichere, zeitsynchrone Sitzungs-Logs, die an Identitäten gebunden sind, mit einer Aufbewahrungsfrist, die Ihrem Auditor, Regulierer oder Versicherer genügt. |
| 08 | Änderungen um den Prozess herum planen, nicht gegen ihn | Schalten Sie die Durchsetzung in einem geplanten Wartungsfenster um, lassen Sie Sicherheitssysteme (SIS) außen vor, und bestätigen Sie, dass die Linie vorher und nachher unverändert läuft. |
| 09 | Kontrollen den Frameworks zuordnen, denen Sie unterliegen | Dokumentieren Sie jede Kontrolle gegenüber IEC 62443, NIST 800-82 Rev 3 und CISA CPGs, dazu TSA-Direktiven, NERC CIP oder CMMC, wo sie zutreffen. |
PLC-Sicherheit und IEC 62443
Alt-PLCs erfüllen fast keine der grundlegenden Anforderungen von IEC 62443 aus eigener Kraft. Eine kompensierende Maßnahme vor dem Controller schließt die Lücke und liefert die Nachweise, und dieselbe Maßnahme deckt die weiteren Frameworks ab, denen ein US-Betreiber unterliegt: NIST 800-82 Rev 3, CISA CPGs und, wo zutreffend, TSA-Direktiven, NERC CIP und CMMC.
| IEC-62443-Anforderung | Die PLC-Lücke | Wie man sie schließt |
|---|---|---|
| FR 1 Identifikations- und Authentifizierungskontrolle | PLCs haben keine native Authentifizierung | Identitätsgebundener Zugriff, am Proxy durchgesetzt |
| FR 2 Nutzungskontrolle | Keine Kontrolle pro Befehl auf dem Gerät | Allowlist pro Anlage, Protokoll und Befehl |
| FR 3 Systemintegrität | Nicht authentifizierte Befehle können die Logik verändern | Nur autorisierte Befehle erreichen den Controller |
| FR 4 Datenvertraulichkeit | Alt-Protokolle senden Befehle im Klartext | Die clientseitige Sitzung verschlüsseln; Klartext auf das Segment vor dem Controller beschränken |
| FR 5 Eingeschränkter Datenfluss | Flache Netzwerke, keine Zonen oder Conduits | Mikrosegmentierung in Zonen und Conduits |
| FR 6 Zeitnahe Reaktion auf Ereignisse | Keine native Protokollierung auf dem Gerät | Manipulationssichere Sitzungsaufzeichnungen für Erkennung und Audit |
| FR 7 Ressourcenverfügbarkeit | Kein Schutz gegen Überlast oder eine defekte Integration | Durchsetzung im Pfad mit Failover und protokolliertem Break-Glass-Weg |
Was diese Woche zu tun ist
- Listen Sie jede PLC auf und wo sie im Netzwerk sitzt.
- Prüfen Sie, ob ein Controller aus dem Internet erreichbar ist.
- Finden Sie heraus, welche PLCs noch Standard- oder geteilte Zugangsdaten nutzen.
- Prüfen Sie, ob der Hersteller-Fernzugriff auf dauerhaften Konten oder offenen VPNs beruht.
- Versuchen Sie, für einen kritischen Controller zu benennen, wer ihn in den letzten 30 Tagen erreicht und welche Befehle er gesendet hat. Wenn Sie das nicht können, ist das die Lücke.
- Nehmen Sie den OT-Abschnitt Ihres Cyber-Versicherungsantrags und lesen Sie, wie er den Umgang mit nicht patchbaren Anlagen verlangt.
Fragen zur PLC-Sicherheit, beantwortet
Agenten auf der PLC, keine Ausfallzeit bei der Einführung
PLC-Sicherheit bedeutet, speicherprogrammierbare Steuerungen, also die Geräte, die physische Prozesse steuern, vor unbefugtem Zugriff und Manipulation zu schützen. Da die meisten PLCs weder authentifizieren noch verschlüsseln oder gepatcht werden können, setzen Sie PLC-Sicherheit vor dem Controller durch: identitätsgebundener Zugriff, Segmentierung und Audit auf der Netzwerkebene.
Setzen Sie eine kompensierende Maßnahme davor. Ein lokaler industrieller Proxy vermittelt jede Verbindung zum Controller: Er authentifiziert den Benutzer, lässt nur die benötigten Befehle zu, segmentiert die PLC aus dem flachen Netzwerk heraus und zeichnet die Sitzung auf. Die PLC wird nie verändert und bleibt online.
Nicht auf der PLC selbst, da die meisten Controller das nicht unterstützen. Stattdessen setzen Sie MFA auf der Netzwerkebene durch: Ein Benutzer authentifiziert sich mit MFA gegen Ihr Verzeichnis, bevor eine Sitzung den Controller erreicht. Das Ergebnis ist MFA-geschützter PLC-Zugriff, ohne das Gerät zu ändern.
Scannen Sie vorsichtig. Ältere Controller können bei einem aktiven Portscan ausfallen, I/O verlieren oder nicht mehr antworten, daher sollte die Erkennung in einer laufenden Anlage passiv sein: Lesen Sie den Verkehr, der ohnehin auf der Leitung liegt, statt das Gerät abzutasten. Beschränken Sie aktive Tests auf ein Wartungsfenster an einem Ersatz- oder Offline-Gerät.
Standard-Zugangsdaten, Internet-Exposition, nicht authentifizierte Protokolle, ungepatchte Firmware, flache Netzwerke, kompromittierte Engineering-Workstations und Hersteller-Laptops sowie unkontrollierter Hersteller-Fernzugriff. Jedes davon lässt einen Angreifer einen Controller erreichen und Befehle absetzen oder neue Logik übertragen, die er ohne Rückfrage ausführt.
Versicherer erwarten sie zunehmend. Cyber-Versicherungsanträge fragen, wie Sie mit nicht patchbaren OT-Anlagen, MFA und Segmentierung umgehen, und "wir können es nicht patchen" ohne Kontrolle ist ein Warnsignal bei der Verlängerung und ein Streitpunkt im Schadensfall. Eine kompensierende Maßnahme, die Identität, minimale Rechte und Segmentierung vor dem Controller durchsetzt und Sitzungsnachweise liefert, beantwortet den Fragebogen und den Schadensfall.
Für jeden Controller: die benannte Identität hinter jeder Sitzung, den pro Anlage und pro Befehl zulässigen Umfang, die Befehle, die das Gerät erreichten, manipulationssichere, zeitsynchrone Logs mit einer Aufbewahrungsfrist, die Abdeckung, welche Controller geschützt sind, sowie eine Zuordnung jedes Punkts zu der Anforderung aus IEC 62443, NIST 800-82, CMMC oder NERC CIP, die Ihr Prüfer testet. Die Nachweise werden lokal exportiert, nicht aus einer Hersteller-Cloud.
IEC 62443 verlangt Identifikation und Authentifizierung, Nutzungskontrolle, Systemintegrität, Zonierung und Ereignisprotokollierung. Alt-PLCs erfüllen nichts davon nativ, daher erfüllen Betreiber die Anforderungen mit einer kompensierenden Maßnahme, die sie vor dem Controller durchsetzt und die Zuordnung dokumentiert.
Ja, denn sie verlangen dasselbe in anderen Worten: identitätsgebundener Zugriff, minimale Rechte, Segmentierung und Protokollierung vor Anlagen, die das nicht selbst können. Ein einziger Durchsetzungspunkt vor dem Controller liefert die Nachweise für IEC 62443, NIST 800-82 Rev 3, CISA CPGs, TSA-Direktiven, NERC CIP und CMMC.
Inventarisieren Sie jeden Controller, prüfen Sie auf Internet-Exposition und Standard-Zugangsdaten, verifizieren Sie Segmentierung und identitätsbasierten Zugriff, bestätigen Sie, dass Hersteller-Zugriff vermittelt und aufgezeichnet wird, und ordnen Sie jede Kontrolle IEC 62443 oder NIST 800-82 zu. Die Checkliste auf dieser Seite führt Sie durch.