SCADA und SPS absichern: Praxismaßnahmen ohne Produktionsstopp

Warum „einfach absichern" in der OT nicht funktioniert

Wenn du aus der IT-Welt kommst, ist Systemhärtung ein vertrautes Thema. Du installierst das neueste Betriebssystem, aktivierst die Firewall, deaktivierst unnötige Dienste, installierst einen Endpoint-Protection-Agenten und richtest automatische Updates ein. Das Ganze dauert vielleicht eine Stunde pro System und am nächsten Morgen ist alles erledigt.

In der OT-Welt funktioniert das nicht. Und zwar aus Gründen, die nicht Nachlässigkeit sind, sondern tief in der Natur dieser Systeme liegen.

Verfügbarkeit hat absolute Priorität. Eine SPS, die eine Produktionslinie steuert, darf nicht ausfallen. Nicht für fünf Minuten, nicht für eine Minute. Jeder Eingriff, der ein auch nur theoretisches Risiko für die Verfügbarkeit birgt, muss sorgfältig geplant und getestet werden.

Herstellerabhängigkeit. Die Software auf einem SCADA-Server oder einer Engineering-Workstation ist vom Maschinenhersteller zertifiziert. Wenn du einen Patch installierst, den der Hersteller nicht freigegeben hat, kann die Garantie erlöschen. Wenn du einen Dienst deaktivierst, der für die SCADA-Software nötig ist, steht die Anlage.

Echtzeit-Anforderungen. SPS-Systeme arbeiten in Zykluszeiten von Millisekunden. Ein zusätzlicher Softwareagent (Antivirus, EDR) kann diese Zykluszeit beeinflussen und damit die Steuerungsqualität verschlechtern. In sicherheitskritischen Anwendungen ist das inakzeptabel.

Lange Lebenszyklen. Eine SPS läuft 15 bis 25 Jahre. In dieser Zeit ändert sich die IT-Welt mehrfach grundlegend, aber die Steuerung in der Produktion bleibt dieselbe. Du kannst nicht erwarten, dass ein System von 2010 mit modernen Sicherheitsstandards kompatibel ist.

Das alles bedeutet nicht, dass OT-Systeme ungeschützt bleiben müssen. Es bedeutet, dass der Ansatz ein anderer sein muss als in der IT. Statt „alles auf einmal und automatisch" heißt es in der OT: „schrittweise, getestet und während geplanter Wartungsfenster".

SCADA-Server härten

SCADA-Server sind typischerweise Windows-basierte Systeme, auf denen die SCADA-Software des Herstellers läuft (WinCC, iFix, Ignition, Wonderware/AVEVA etc.). Sie sind besonders exponiert, weil sie sowohl mit den Steuerungssystemen kommunizieren als auch eine grafische Oberfläche für Bediener bereitstellen.

Betriebssystem-Härtung

Unnötige Dienste deaktivieren. Ein SCADA-Server braucht keinen Print-Spooler, keinen Bluetooth-Dienst, keinen Windows-Media-Player und keinen Remote-Desktop-Drucker. Deaktiviere alles, was nicht für den Betrieb der SCADA-Software und die Netzwerkkommunikation benötigt wird. Aber: Erstelle vorher eine Liste aller laufenden Dienste und prüfe mit dem SCADA-Hersteller, welche davon benötigt werden.

Lokale Firewall konfigurieren. Die Windows-Firewall sollte aktiv sein und nur die Ports zulassen, die die SCADA-Software und die OT-Protokolle benötigen. Typischerweise sind das: der Port für die Kommunikation mit den SPS (z.B. TCP 102 für S7comm, TCP 502 für Modbus TCP, TCP 44818 für EtherNet/IP), der Port für die Historian-Verbindung und der Port für die HMI-Clients.

Autorun deaktivieren. USB-Sticks sind ein häufiger Angriffsvektor in OT-Umgebungen (Stuxnet wurde über einen USB-Stick eingeschleust). Deaktiviere die Autorun-Funktion für alle Wechselmedien. Besser noch: Beschränke den USB-Zugriff über Gruppenrichtlinien auf autorisierte Geräte.

AppLocker oder Software Restriction Policies. Definiere eine Whitelist der Programme, die auf dem SCADA-Server ausgeführt werden dürfen. Alles andere wird blockiert. Das ist einer der wirksamsten Schutzmechanismen gegen Malware und erfordert kein ständig aktualisiertes Antivirenprogramm.

SCADA-Software härten

Benutzerkonten einrichten. Viele SCADA-Systeme werden mit einem einzigen Benutzerkonto betrieben, oft mit Administratorrechten. Richte separate Konten ein: ein Bediener-Konto mit eingeschränkten Rechten für den Normalbetrieb, ein Engineering-Konto für Konfigurationsänderungen und ein Admin-Konto für Systemverwaltung. Das Admin-Konto wird nur verwendet, wenn es wirklich nötig ist.

Standard-Passwörter ändern. Das klingt trivial, wird aber in der Praxis erstaunlich oft vernachlässigt. Ändere die Passwörter für: SCADA-Benutzerkonten, Datenbank-Zugänge (viele SCADA-Systeme nutzen SQL Server oder PostgreSQL), OPC-Server-Konfiguration, Web-Interfaces (falls vorhanden).

Audit-Logging aktivieren. SCADA-Systeme haben typischerweise eine Audit-Trail-Funktion, die Änderungen an Konfiguration und Parametern protokolliert. Aktiviere sie und leite die Logs an einen zentralen Syslog-Server weiter (der außerhalb des SCADA-Systems steht, damit ein Angreifer die Logs nicht manipulieren kann).

Nicht benötigte Module deaktivieren. SCADA-Plattformen sind modular. Deaktiviere Module, die du nicht benötigst: Web-Server, Reporting-Module, Remote-Access-Funktionen, Scripting-Engines.

SPS absichern

Die Absicherung von SPS-Systemen ist anspruchsvoller als die von SCADA-Servern, weil die Möglichkeiten begrenzter sind. SPS sind eingebettete Systeme mit proprietärer Firmware und eingeschränkten Sicherheitsfunktionen. Trotzdem gibt es wirksame Maßnahmen.

Zugangskontrollen

Passwortschutz für Programmierung. Moderne SPS bieten die Möglichkeit, den Zugriff auf das Steuerungsprogramm mit einem Passwort zu schützen. Aktiviere diese Funktion. Auch wenn der Schutz nicht so stark ist wie bei IT-Systemen (einige Hersteller speichern Passwörter nur als einfache Hashes), stellt er eine zusätzliche Hürde dar.

Betriebsartenschalter nutzen. Viele SPS haben einen physischen Betriebsartenschalter (RUN, STOP, PROGRAM). Stelle den Schalter im Normalbetrieb auf RUN. In dieser Stellung kann das Steuerungsprogramm nicht verändert werden. Ein Angreifer, der nur Netzwerkzugang hat, kann die Stellung des physischen Schalters nicht ändern.

Zugriffsschutz über IP-Whitelisting. Einige moderne SPS erlauben es, den Zugriff auf bestimmte IP-Adressen zu beschränken. Nur die Engineering-Workstation und der SCADA-Server sollten mit der SPS kommunizieren dürfen. Konfiguriere diese Einschränkung auf der SPS selbst (nicht nur auf der Firewall), um einen Defense-in-Depth-Ansatz zu erreichen.

Firmware-Management

Firmware-Versionen dokumentieren. Erfasse für jede SPS die aktuelle Firmware-Version und das Datum des letzten Updates. Prüfe regelmäßig (mindestens quartalsweise), ob der Hersteller neue Firmware-Versionen veröffentlicht hat, und bewerte, ob ein Update nötig ist.

Firmware-Updates planen. Updates sollten nur während geplanter Wartungsfenster eingespielt werden. Vorher: Backup des aktuellen Steuerungsprogramms erstellen, Firmware-Release-Notes lesen, prüfen ob bekannte Probleme mit deiner Konfiguration existieren, den Hersteller-Support kontaktieren falls Unsicherheiten bestehen.

Integrität prüfen. Manche SPS unterstützen die Überprüfung der Programmintegrität (Checksummen). Nutze diese Funktion, um sicherzustellen, dass das Steuerungsprogramm nicht manipuliert wurde. Vergleiche die Checksumme regelmäßig mit dem dokumentierten Sollwert.

SPS-Programme sichern

Regelmäßige Backups. Erstelle regelmäßige Backups aller SPS-Programme. Bewahre sie an einem sicheren Ort auf (nicht auf der Engineering-Workstation, die im selben Netzwerk steht). Im Idealfall: Offline-Backup auf einem dedizierten Speichermedium, das im Tresor liegt.

Versionierung. Nutze ein Versionskontrollsystem für SPS-Programme. Einige Engineering-Tools (wie TIA Portal von Siemens) bieten integrierte Versionierungsfunktionen. Alternativ kannst du die Projektdateien manuell in einem Versionskontrollsystem wie Git verwalten.

Wiederherstellungs-Test. Ein Backup, das nie getestet wurde, ist kein Backup. Teste mindestens einmal jährlich, ob du eine SPS aus dem Backup wiederherstellen kannst. Am besten mit einer Reserve-SPS in einer Testumgebung, nicht im laufenden Betrieb.

Wartungszugänge absichern

Wartungszugänge sind einer der kritischsten Punkte in der OT-Sicherheit. Sie sind notwendig (Maschinenhersteller und Systemintegratoren müssen Zugriff haben), aber sie sind auch einer der häufigsten Angriffsvektoren.

Zentralisierung über Jump-Server

Alle Remote-Zugänge zu OT-Systemen laufen über einen dedizierten Jump-Server (auch Bastion Host genannt) in der Industrial DMZ. Der Jump-Server bietet:

• Zentrale Authentifizierung mit individuellen Benutzerkonten
• Multi-Faktor-Authentifizierung (Passwort plus Token oder Zertifikat)
• Vollständige Protokollierung aller Sitzungen (idealerweise Session Recording)
• Zeitliche Beschränkung der Zugänge (Zugang wird vor dem Wartungsfenster freigeschaltet und danach automatisch gesperrt)
• Netzwerkzugriff nur auf die spezifischen Systeme, die gewartet werden müssen (nicht auf das gesamte OT-Netzwerk)

Lieferanten-Management

Für jeden externen Wartungsdienstleister dokumentierst du:

• Welche Systeme darf er erreichen?
• Welche Aktivitäten sind genehmigt?
• Wer ist der interne Ansprechpartner?
• Wie wird der Zugang freigeschaltet und gesperrt?
• Wie werden die Sitzungen protokolliert und überprüft?

Dieses Lieferanten-Management sollte in dein ISMS integriert sein. NIS2 fordert explizit die Absicherung der Lieferkette, und Wartungszugänge sind ein wesentlicher Bestandteil davon.

USB-Geräte und mobile Speichermedien

In vielen OT-Umgebungen werden Updates und Konfigurationen über USB-Sticks übertragen (weil die Systeme keine Netzwerkverbindung haben oder haben sollten). Definiere einen Prozess für den sicheren Umgang mit USB-Medien:

• Nur freigegebene USB-Sticks verwenden (beschriftet, inventarisiert)
• USB-Sticks vor der Verwendung an OT-Systemen an einem dedizierten Scan-Terminal auf Malware prüfen
• Transfer-Log führen: Wer hat wann welche Dateien auf welches System übertragen?
• USB-Sticks nach Gebrauch sicher löschen

Monitoring: Sehen, was im OT-Netzwerk passiert

Ohne Monitoring bist du blind. Du weißt nicht, wer auf deine Steuerungssysteme zugreift, welche Kommunikation stattfindet und ob etwas Ungewöhnliches passiert. Wie bei der Logging- und Monitoring-Strategie in der IT ist auch in der OT strukturiertes Monitoring die Grundlage für jede wirksame Incident Detection.

Passives Netzwerk-Monitoring

Der sicherste Ansatz für OT-Monitoring ist passives Netzwerk-Monitoring. Dabei wird der Netzwerkverkehr über einen Mirror-Port (SPAN-Port) am Switch mitgelesen und von einem dedizierten Analysesystem ausgewertet. Das Analysesystem sendet keine Pakete ins OT-Netzwerk und beeinflusst die Steuerungssysteme nicht.

Spezialisierte OT-Monitoring-Lösungen wie Nozomi Networks, Claroty, Dragos oder Microsoft Defender for IoT können:

• Asset Discovery: Automatisch alle Geräte im OT-Netzwerk identifizieren (IP, MAC, Hersteller, Firmware-Version, Protokolle)
• Kommunikationsmatrix: Visualisieren, welches System mit welchem System kommuniziert und über welche Protokolle
• Anomalie-Erkennung: Abweichungen vom normalen Kommunikationsmuster erkennen (neues Gerät, unbekanntes Protokoll, ungewöhnliche Kommunikation)
• Schwachstellen-Mapping: Bekannte Schwachstellen (CVEs) den identifizierten Geräten und Firmware-Versionen zuordnen
• Industrieprotokoll-Analyse: OT-spezifische Protokolle (Modbus, S7comm, Profinet, EtherNet/IP) auf der Anwendungsschicht analysieren und verdächtige Befehle erkennen

Was du überwachen solltest

Auch ohne spezialisierte OT-Monitoring-Software kannst du grundlegendes Monitoring umsetzen:

Firewall-Logs an den Zonenübergängen. Jede Firewall zwischen IT und OT, zwischen DMZ und OT und zwischen verschiedenen OT-Zonen sollte Logs erzeugen. Insbesondere geblockte Verbindungsversuche sind interessant: Sie zeigen, ob jemand versucht, die Segmentierung zu umgehen.

Authentifizierungslogs. Fehlgeschlagene Login-Versuche auf SCADA-Servern, Engineering-Workstations und Jump-Servern protokollieren und alertieren.

Konfigurationsänderungen. Jede Änderung an SPS-Programmen, SCADA-Konfigurationen oder Netzwerkgeräten muss protokolliert werden. Änderungen außerhalb geplanter Wartungsfenster sind immer ein Alarmsignal.

Netzwerk-Baselines. Erfasse über einen Zeitraum von einigen Wochen, welche Kommunikationsmuster in deinem OT-Netzwerk normal sind. Welche IP-Adressen kommunizieren miteinander? Über welche Ports? In welchem Umfang? Abweichungen von dieser Baseline können auf einen Vorfall hindeuten.

Maßnahmen nach Priorität

Nicht alle Maßnahmen müssen sofort umgesetzt werden. Hier eine priorisierte Reihenfolge:

Priorität 1: Sofort (ohne Wartungsfenster möglich)

Priorität 2: Nächstes Wartungsfenster

Priorität 3: Geplant (3-6 Monate)

Priorität 4: Langfristig (6-12 Monate)

Incident Response für OT-Vorfälle

Die Absicherung von SCADA und SPS ist die eine Seite. Die andere Seite ist die Frage: Was tust du, wenn trotz aller Maßnahmen ein Vorfall eintritt?

OT-spezifische Incident-Response-Herausforderungen

In der IT ist die Standardreaktion auf eine Kompromittierung: System isolieren, analysieren, bereinigen, wieder in Betrieb nehmen. In der OT kann der erste Schritt (isolieren) bereits den größeren Schaden verursachen als der Angriff selbst.

Deshalb brauchst du einen OT-spezifischen Incident-Response-Plan, der folgende Fragen vorab klärt:

Wer entscheidet über die Abschaltung? Wenn ein SCADA-Server kompromittiert ist, muss jemand die Entscheidung treffen, ob die betroffene Produktionslinie heruntergefahren wird oder ob sie unter erhöhter manueller Überwachung weiterläuft. Diese Entscheidung sollte nicht im Moment des Vorfalls zum ersten Mal diskutiert werden. Definiere vorab die Entscheidungskriterien und die Entscheidungsträger.

Wie funktioniert der manuelle Betrieb? Viele Produktionsanlagen können in einem eingeschränkten manuellen Modus weiterlaufen, wenn die Automatisierung ausfällt. Die Bediener müssen wissen, wie sie den manuellen Betrieb aufnehmen und welche Grenzen dabei gelten. Dokumentiere die Verfahren für den manuellen Notbetrieb und übe sie regelmäßig.

Wo sind die Offline-Backups? Wenn der SCADA-Server verschlüsselt ist und das Netzwerk-Backup ebenfalls kompromittiert wurde, brauchst du ein Offline-Backup der SPS-Programme und SCADA-Konfigurationen. Wo liegt es? Wer hat Zugriff? Ist es aktuell?

Wer kann die Wiederherstellung durchführen? Die Wiederherstellung eines SCADA-Systems oder die Neuprogrammierung einer SPS erfordert Spezialkenntnisse. Wenn dein einziger Automatisierungstechniker gerade im Urlaub ist, hast du ein Problem. Dokumentiere die Recovery-Steps so detailliert, dass auch ein qualifizierter Facharbeiter ohne spezifische Systemkenntnis die Wiederherstellung durchführen kann. Und halte die Kontaktdaten des Maschinenherstellers und des Systemintegrators aktuell.

Tabletop-Übungen für OT-Szenarien

Mindestens einmal jährlich solltest du eine Tabletop-Übung mit einem OT-spezifischen Szenario durchführen. Daran teilnehmen sollten: IT-Security, Produktionsleitung, Instandhaltung, Geschäftsleitung und idealerweise der Maschinenhersteller oder Systemintegrator.

Ein gutes Übungsszenario: „Montagmorgen, 06:30 Uhr. Der Bediener der Schicht meldet, dass alle HMI-Panels in Halle 2 nur noch einen schwarzen Bildschirm zeigen. Die Maschinen laufen noch, aber die Bediener haben keine Übersicht über den Prozess. Der SCADA-Server ist nicht erreichbar. Gleichzeitig meldet die IT, dass mehrere Server im Rechenzentrum verschlüsselt wurden."

Solche Übungen decken Lücken auf, die im Normalbetrieb unsichtbar sind: fehlende Kontaktdaten, unklare Zuständigkeiten, veraltete Recovery-Dokumentation, nicht getestete Backup-Medien. Im Artikel Tabletop-Übung planen findest du eine Anleitung für die Durchführung.

Der regulatorische Rahmen

Die Absicherung von SCADA und SPS ist nicht nur technisch sinnvoll, sondern wird zunehmend regulatorisch gefordert:

NIS2 verlangt ein umfassendes Risikomanagement für alle Netz- und Informationssysteme, das schließt OT-Systeme explizit ein. Die geforderten Maßnahmen (Patch-Management, Zugangskontrolle, Incident Detection, Backup, Supply Chain Security) gelten auch für SCADA und SPS.

Die EU-Maschinenverordnung 2023/1230 fordert ab 2027, dass Maschinen mit digitalen Elementen gegen unbefugte Zugriffe geschützt sein müssen. Sicherheitsfunktionen (Not-Halt, Schutzeinrichtungen, Drucküberwachung) dürfen durch digitale Angriffe nicht beeinträchtigt werden können. Das hat direkte Auswirkungen auf die Absicherung der SPS, die diese Sicherheitsfunktionen ausführt.

IEC 62443 liefert den detailliertesten technischen Rahmen für die Absicherung von industriellen Automatisierungssystemen. Wenn du eine strukturierte Vorgehensweise suchst, ist dieser Standard die beste Orientierung.

Für die Praxis bedeutet das: Die Absicherung von SCADA und SPS ist keine Kür mehr, sondern Pflicht. Und jede Maßnahme, die du jetzt umsetzt und dokumentierst, hilft dir bei der nächsten Prüfung nachzuweisen, dass du das Thema ernst nimmst. In ISMS Lite lassen sich SCADA- und SPS-Systeme mit Firmware-Versionen, Härtungsmaßnahmen und Recovery-Anleitungen strukturiert erfassen.

Weiterführende Artikel

• OT-Sicherheit im Mittelstand: Warum die Produktionssteuerung ins ISMS gehört
• Purdue-Modell erklärt: Netzwerkzonen in der Produktion
• Patch-Management in der OT: Wenn du nicht einfach updaten kannst
• Risikobewertung für OT-Systeme: Andere Prioritäten als in der IT
• IT/OT-Konvergenz: Risiken an der Schnittstelle zwischen Büro und Produktion