Wie man SPS in Fabriken gegen Cyber-Bedrohungen absichert?

Verstehen der Angriffsfläche moderner SPS und DCS

Programmierbare Steuerungen und verteilte Steuerungssysteme bilden das Nervensystem der industriellen Automatisierung. Im Gegensatz zu IT-Servern in Unternehmen priorisieren diese Geräte deterministische Zeitsteuerung und hohe Verfügbarkeit über Sicherheitsfunktionen. Daher fehlen den meisten Steuerungen grundlegende Schutzmaßnahmen wie verschlüsselte Kommunikation, Integritätsprüfungen oder rollenbasierte Zugriffskontrolle. Wenn Produktionsnetzwerke mit der Unternehmens-IT oder Cloud-Plattformen verbunden sind, vergrößert sich die Angriffsfläche erheblich. Ein einziger ungeschützter Ethernet-Port an einer SPS kann eine gesamte Fertigungslinie für Fernangriffe öffnen.

Tiefenanalyse: Protokollebene-Schwachstellen, die Ingenieure kennen müssen

Industrielle Protokolle wurden vor Jahrzehnten für Einfachheit und Geschwindigkeit entwickelt. Sicherheit war nie ein Designziel. Das Verständnis dieser technischen Schwachstellen hilft Ingenieuren, geeignete kompensierende Maßnahmen auszuwählen.

Modbus TCP: Keine Authentifizierung, keine Verschlüsselung

Modbus TCP verwendet Funktionscodes 01-06 für Lese- und Schreiboperationen. Jedes Gerät, das Port 502 erreichen kann, kann beliebige Schreibbefehle senden. Es gibt kein Sitzungs-Konzept, keine Benutzeridentität und keine Integritätsprüfung der Nachrichten. Ein Angreifer mit Netzwerkzugang kann einen Motor stoppen, ein Ventil öffnen oder einen Sollwert ändern, ohne Authentifizierungsprotokolle zu hinterlassen. Der einzige Schutz ist die Isolation auf Netzwerkebene oder Anwendungsschicht-Gateways, die Funktionscodes filtern.

Profinet und EtherNet/IP: Anfällig für Injektionsangriffe

Diese Echtzeitprotokolle basieren auf zyklischem Datenaustausch. Sie validieren nicht die Quelle der IO-Daten. Ein bösartiges Gerät, das sich als IO-Controller ausgibt, kann falsche Sensordaten einspeisen. Umgekehrt kann ein Angreifer ein Sicherheitstelegramm fälschen und Notabschaltungen auslösen. Ohne Segmentierung oder Deep Packet Inspection bleiben diese Angriffe unentdeckt.

OPC Classic: Abhängigkeit von DCOM-Sicherheitslücken

Viele ältere DCS-Systeme verwenden OPC DA (Data Access), das auf Microsoft DCOM basiert. DCOM hat eine lange Geschichte von Schwachstellen für Remote-Code-Ausführung. Außerdem unterstützt OPC Classic keine native Verschlüsselung. Angreifer, die einen OPC-Server kompromittieren, können beliebige Prozess-Tags lesen oder schreiben. Die Migration zu OPC UA mit aktivierter Sicherheit wird empfohlen.

Technischer Härtungsleitfaden: Schritt-für-Schritt für Feldeinsatztechniker

Die folgenden Verfahren setzen voraus, dass Sie physischen oder sicheren Fernzugriff auf die Steuerung haben. Führen Sie diese Änderungen immer während eines geplanten Wartungsfensters durch und überprüfen Sie anschließend die Funktion.

Schritt 1: Durchführung eines Sicherheits-Basislinien-Audits

Verbinden Sie sich mit jeder SPS über Engineering-Software. Erfassen Sie Folgendes: Firmware-Version, aktivierte Protokolle (HTTP, FTP, SNMP, Telnet), offene TCP/UDP-Ports, konfigurierte Benutzerkonten und Datum der letzten Passwortänderung. Verwenden Sie eine Tabelle, um Abweichungen von Ihrem Sicherheitsstandard zu verfolgen. Prüfen Sie bei Siemens S7-Steuerungen das konfigurierte Zugriffslevel in den Hardwareeigenschaften. Bei Rockwell-Steuerungen überprüfen Sie die Steuerungsschutz-Einstellungen in Studio 5000.

Schritt 2: Steuerungskonfiguration härten

Deaktivieren Sie alle nicht genutzten Protokollstapel. Schalten Sie bei einer typischen SPS Webserver, FTP, SNMP und alle proprietären Wartungsports aus. Deaktivieren Sie für Ethernet-Ports die automatische Aushandlung nicht genutzter Dienste. Ändern Sie die Standard-Rack/Slot-Adressen, wenn das Protokoll eine Enumeration erlaubt. Bei Rockwell Logix-Steuerungen setzen Sie die nicht genutzten Ports auf „Deaktiviert“ und aktivieren Sie den „Systemschutz“ mit einem eindeutigen Schlüssel.

Schritt 3: Starke Zugriffskontrolle implementieren

Erstellen Sie individuelle Benutzerkonten für jeden Ingenieur. Vermeiden Sie die Verwendung des Standardkontos „admin“ oder „engineer“. Für Systeme mit rollenbasierter Zugriffskontrolle definieren Sie mindestens drei Rollen: Bediener (nur lesen), Techniker (lesen plus manuelle Befehle) und Ingenieur (voller Programmzugriff). Legen Sie Passwortkomplexitätsregeln fest: mindestens 12 Zeichen, Großbuchstaben, Kleinbuchstaben, Zahlen und Symbole. Ändern Sie Standardpasswörter vor dem Anschluss der SPS an ein Netzwerk.

Schritt 4: Netzwerkschutzmaßnahmen anwenden

Platzieren Sie jede SPS hinter einer industriellen Firewall, die den Protokollinhalt überprüft. Erstellen Sie Firewall-Regeln, die nur bestimmte Quell-IP-Adressen für jede Art von Datenverkehr zulassen. Erlauben Sie beispielsweise HMI-zu-SPS-Datenverkehr auf Protokollport 44818 (EtherNet/IP), blockieren Sie jedoch Programmier-Software-Datenverkehr (Port 2222) außer von einer dedizierten Engineering-Workstation. Verwenden Sie VLANs, um Sicherheits-SPS von Standardsteuerungs-SPS zu trennen. Implementieren Sie 802.1X-Port-Authentifizierung an Switch-Ports, um die Verbindung von unerwünschten Geräten zu verhindern.

Schritt 5: Sicherer Firmware-Update-Workflow einrichten

Aktualisieren Sie die Firmware niemals direkt von der Website des Herstellers über das Internet. Laden Sie die Firmware-Binärdatei auf einem vertrauenswürdigen, offline betriebenen Computer herunter. Überprüfen Sie die digitale Signatur der Datei. Testen Sie das Update an einer identischen Steuerung in einer Laborumgebung für mindestens 40 Stunden simulierten Betrieb. Dokumentieren Sie das Rücksetzverfahren für den Fall, dass das Update fehlschlägt. Führen Sie Updates nur während geplanter Ausfallzeiten durch, niemals während eines laufenden Prozesses.

Schritt 6: Protokollierung und Alarmierung konfigurieren

Aktivieren Sie die Syslog-Weiterleitung, wenn die SPS dies unterstützt. Für Steuerungen ohne native Protokollierung verwenden Sie einen Netzwerktap, um den Datenverkehr zu überwachen und Warnungen für bestimmte Ereignisse zu generieren: Programmdownload, Moduswechsel von Lauf- zu Programmiermodus, erzwungene E/A oder wiederholte fehlgeschlagene Anmeldeversuche. Leiten Sie Protokolle an ein zentrales SIEM mit OT-spezifischen Korrelationsregeln weiter. Legen Sie Alarmstufen so fest, dass eine Programmänderung außerhalb der Betriebszeiten eine sofortige Untersuchung auslöst.

Fortgeschrittene technische Anleitung: Sichere PLC-Programmierpraktiken

Sicherheit sollte bis in die Logik selbst reichen. Diese Programmiertechniken fügen eine mehrschichtige Verteidigung innerhalb der Steuerung hinzu.

• Prüfsummenverifikation implementieren: Berechnen Sie beim Start eine zyklische Redundanzprüfung kritischer Logikblöcke. Speichern Sie den bekannten guten Wert im retentiven Speicher. Bei einer Prüfsummenabweichung wird ein sicherer Zustand ausgelöst und die Bediener alarmiert.
• Watchdog-Timer für Kommunikationsverlust verwenden: Für jede Remote-IO- oder HMI-Kommunikation einen Watchdog-Timer setzen. Wenn die erwartete zyklische Nachricht nicht innerhalb des Timeouts eintrifft, werden Ausgänge auf vordefinierte sichere Positionen gesetzt. Dies verhindert, dass veraltete oder gefälschte Daten gefährliche Bewegungen verursachen.
• Alle HMI-Eingaben in der SPS validieren: Verlassen Sie sich niemals darauf, dass ein HMI gültige Werte sendet. Prüfen Sie in der SPS-Logik, dass analoge Sollwerte innerhalb sicherer Minimal- und Maximalbereiche bleiben. Für diskrete Befehle verifizieren Sie, dass die Reihenfolge gültig ist. Lehnen Sie alle außerhalb des Bereichs oder der Reihenfolge liegenden Befehle ab.
• Sicherheitslogik von Standardlogik trennen: Verwenden Sie dedizierte Sicherheits-SPS oder sicherheitszertifizierte IO für Not-Aus- und Schutzfunktionen. Standard-SPS dürfen keinen Schreibzugriff auf Sicherheitsausgänge haben. Diese Isolation stellt sicher, dass selbst eine vollständig kompromittierte Standard-SPS Sicherheitsfunktionen nicht außer Kraft setzen kann.

Technischer Praxisfall: Automobilwerk sichert 320 SPS ab

Eine große Automobilantriebsanlage mit 320 SPS (Siemens S7-1200 und S7-1500) war wiederholten unautorisierten Zugriffen durch kompromittierte Laptops von Auftragnehmern ausgesetzt. Das Anlagenteam implementierte ein systematisches Sicherheitsprogramm mit folgenden technischen Maßnahmen.

• Inventur durchgeführt und 47 SPS mit noch aktiven Standardpasswörtern entdeckt.
• Alle Standardzugangsdaten geändert und Passwortablauf auf 90 Tage konfiguriert.
• Webserver und FTP auf allen Steuerungen über TIA Portal Stapelbetrieb deaktiviert.
• Netzwerksegmentierung implementiert: fünf OT-Zonen durch Siemens Scalance Firewalls getrennt.
• Strenge Firewall-Regeln erstellt: Nur Profinet IO-Verkehr (Ports 34962-34964) zwischen SPS und Remote IO zulassen; nur S7-Kommunikation (Port 102) von bestimmten HMIs und SCADA erlauben; allen anderen Verkehr blockieren.
• Firmware aller 320 SPS von Version 2.6 auf 3.0 nach Labortests aktualisiert.
• Syslog-Weiterleitung an ein zentrales SIEM mit Alarmen für Programmdownload-Ereignisse aktiviert.

Gemessene Ergebnisse nach 90 Tagen: Unautorisierte Anmeldeversuche sanken von 487 auf 39 pro Monat (92 % Reduktion). Produktionsausfälle durch cyberbedingte Vorfälle fielen von 6 Ereignissen auf 0. Die Zeit zur Erkennung anomaler Programmdownloads verringerte sich von 14 Stunden auf 12 Minuten. Die Gesamtkosten des Projekts betrugen 180.000 $, wodurch ein potenzieller Ransomware-Angriff verhindert wurde, der geschätzte Kosten von 4,2 Millionen $ pro Ausfallwoche verursacht hätte.

Technischer Fall: Wasseraufbereitungsanlage mindert Modbus-Injektion

Eine kommunale Wasseraufbereitungsanlage betrieb 85 SPS mit Modbus TCP in einem flachen Netzwerk. Bediener beobachteten intermittierende Ventilbetätigungen und Pumpenstart-Ereignisse ohne Befehl vom HMI. Die Untersuchung ergab ein unautorisiertes Gerät im Netzwerk, das Funktionscode 05 (Einzelspule schreiben) und Funktionscode 16 (Mehrere Register schreiben) injizierte.

Das Engineering-Team setzte folgende technische Gegenmaßnahmen um:

• Installierte eine industrielle Firewall (Tofino) im transparenten Modus zwischen dem Hauptswitch und dem SPS-Subnetz.
• Erstellte eine Whitelist erlaubter Modbus-Transaktionen: nur Leseanfragen (Funktionscodes 01,02,03,04) von HMI- und SCADA-IP-Adressen.
• Erlaubte Schreibanfragen (Funktionscodes 05,06,15,16) nur von einer dedizierten Engineering-Workstation-IP und nur während festgelegter Wartungsfenster mittels zeitbasierter ACL.
• Aktivierte Deep Packet Inspection, um zu überprüfen, dass Registeradressen innerhalb der konfigurierten Bereiche blieben.

Ergebnisse: Im ersten Monat blockierte die Firewall 1.200 bösartige Modbus-Funktionscodes. Unautorisierte Schreibbefehle an kritischen Pumpen-SPS wurden vollständig gestoppt. Die Bediener gewannen volles Vertrauen in die Steuerungsintegrität zurück. Die Lösung kostete 25.000 $, wodurch potenzielle Umweltstrafen und Serviceunterbrechungen vermieden wurden.

Leitfaden für Ingenieure zur sicheren Konfiguration des Fernzugriffs

Fernwartung für SPS ist betrieblich notwendig, aber technisch riskant. Folgen Sie diesem genauen Konfigurationsmuster.

• Setzen Sie einen dedizierten OT-VPN-Konzentrator ein: Verwenden Sie ein Firewall-Gerät, das IPsec oder OpenVPN unterstützt. Platzieren Sie es in einer DMZ zwischen IT und OT. Verwenden Sie nicht das Unternehmens-IT-VPN für OT-Zugriffe.
• Konfigurieren Sie MFA für jeden Benutzer: Fordern Sie sowohl ein Zertifikat oder Hardware-Token als auch ein Passwort. Integrieren Sie dies in ein OT-spezifisches LDAP-Verzeichnis.
• Implementieren Sie zeit- und quellbasierte Einschränkungen: Erlauben Sie den Fernzugriff nur während vorab genehmigter Zeiten und von bestimmten öffentlichen IP-Adressen des Dienstleisterbüros.
• Verwenden Sie einen Jump Host mit Sitzungsaufzeichnung: Fordern Sie Remote-Benutzer auf, sich zuerst mit einem gesicherten Windows-Rechner innerhalb der OT-Zone zu verbinden. Alle SPS-Programmiersoftware läuft nur auf diesem Jump Host. Zeichnen Sie vollständige Video- und Tastaturprotokolle auf.
• Einmalige Anmeldeinformationen durchsetzen: Erzeugen Sie für jede Sitzung einzigartige VPN-Passwörter. Widerrufen Sie diese automatisch nach 8 Stunden. Wechseln Sie lokale Admin-Anmeldeinformationen des Jump Hosts nach jedem Besuch eines Dienstleisters.

Fehlerbehebung bei häufigen Problemen bei der Implementierung von SPS-Sicherheit

Ingenieure stoßen häufig auf spezifische Probleme bei der Anwendung von Sicherheitskontrollen. Hier sind technische Lösungen.

• Problem: Nach Änderung des Standardpassworts kann die Engineering-Software nicht online gehen.
  Lösung: Löschen Sie die gespeicherten Anmeldeinformationen im Registry-Editor der Engineering-Workstation oder im Credential Manager. Einige Plattformen (Rockwell) erfordern einen Neustart der SPS, damit das neue Passwort in allen Sitzungen wirksam wird.
• Problem: Firewall blockiert legitimen IO-Datenverkehr nach Segmentierung.
  Lösung: Verwenden Sie Port-Mirroring, um den Datenverkehr während eines Produktionslaufs aufzuzeichnen. Analysieren Sie die Paketaufzeichnung, um alle erforderlichen Quell-/Zielpaare und Protokollports zu identifizieren. Erstellen Sie Zulassungsregeln basierend auf diesem beobachteten Datenverkehr und wechseln Sie dann in den Blockiermodus.
• Problem: Firmware-Update schlägt fehl und SPS geht in den Stopp-Modus.
  Lösung: Bestätigen Sie vor jedem Update, dass die neue Firmware-Version die genaue Hardware-Revision unterstützt. Verwenden Sie das Wiederherstellungstool des Herstellers (z. B. Siemens SIMATIC Field PG), um zur vorherigen Firmware zurückzukehren. Bewahren Sie immer eine Sicherung der Original-Firmware-Binärdatei auf einem offline USB-Stick auf.

Häufig gestellte Fragen von Feldeinsatzingenieuren

Wie kann ich überprüfen, ob eine SPS manipuliert wurde?

Vergleichen Sie die aktuell laufende Logik mit einem bekannten, guten Backup, das offline gespeichert ist. Verwenden Sie Vergleichstools innerhalb der Engineering-Software (z. B. „Online/Offline vergleichen“ im TIA Portal oder „Logik vergleichen“ in Studio 5000). Prüfen Sie das Datum und die Uhrzeit des letzten Programmdownloads. Überprüfen Sie das interne Protokoll der SPS, falls verfügbar. Für kritische Anwendungen implementieren Sie eine Laufzeit-Prüfsummenverifikation innerhalb der Logik.

Wie teste ich Firewall-Regeln am sichersten, ohne die Produktion zu stören?

Setzen Sie die Firewall in den transparenten Bridge-Modus mit nur Protokollierung für die erste Woche ein. Zeichnen Sie den gesamten Datenverkehr auf, der blockiert würde. Überprüfen Sie die Protokolle, um Fehlalarme zu identifizieren. Wechseln Sie dann während eines Wartungsfensters in den Blockiermodus. Verwenden Sie ein Paar Firewalls im Failover-Betrieb, sodass eine umgangen werden kann, falls ein kritischer Kommunikationspfad versehentlich blockiert wird.

Kann ich einen Standard-IT-Schwachstellenscanner in SPS-Netzwerken verwenden?

Nein. Aktive Scanner, die fehlerhafte Pakete senden oder Standardanmeldungen versuchen, können veraltete SPS zum Absturz bringen. Verwenden Sie passive OT-Überwachungstools, die den vorhandenen Datenverkehr analysieren, ohne Sonden zu erzeugen. Falls aktives Scannen notwendig ist, verwenden Sie herstellerspezifische Tools (z. B. Rockwell Safety Assurance Tool oder Siemens Sinema Remote Connect), die die Einschränkungen industrieller Protokolle verstehen.

Abschließende technische Empfehlungen für Steuerungsingenieure

Sicherheit für SPS und DCS ist in der modernen Industrieautomation keine Option, sondern Pflicht. Beginnen Sie mit einer einzelnen Produktionszelle als Pilotprojekt. Implementieren Sie Passworthärtung, Port-Sperrung und Netzwerksegmentierung. Messen Sie die Reduzierung anomaler Ereignisse. Erweitern Sie schrittweise auf die gesamte Anlage. Dokumentieren Sie jede Konfigurationsänderung in einer versionskontrollierten Sicherheitsbasislinie. Weisen Sie jedem Steuergerät einen bestimmten Ingenieur als Verantwortlichen zu. Behandeln Sie Sicherheit als kontinuierliche Ingenieursdisziplin, nicht als einmalige Compliance-Maßnahme. Fabriken, die diese technischen Praktiken integrieren, reduzieren sowohl Cyberrisiken als auch ungeplante Ausfallzeiten.