Entwicklung von HMI/SCADA-Anwendungen unter Berücksichtigung der Cybersicherheit – Grundsätze, die das Risiko bereits in der Projektphase senken

Über die Sicherheit von HMI/SCADA-Anwendungen wird deutlich früher entschieden als erst bei der Auswahl von Schutzmechanismen. Ob ein System gegenüber Fehlbedienung, Missbrauch und unkontrollierten Änderungen des Prozesszustands robust ist, hängt vor allem von den im Projekt getroffenen Grundannahmen ab: von der Rollenaufteilung, den Vertrauensgrenzen, dem Umfang der über die Schnittstelle verfügbaren Funktionen sowie der Organisation von Service und Fernzugriff. Werden diese Punkte nur nachrangig behandelt, verfestigt die Anwendung Risiken, statt sie zu begrenzen. Deshalb muss die Auslegung von HMI/SCADA mit Blick auf die Cybersicherheit als ingenieurtechnische Aufgabe verstanden werden: Zuerst ist festzulegen, welche Operationen kritisch sind, welche Folgen sie haben können und wer sie tatsächlich ausführen darf. Erst danach sollten Bildschirme, Alarme und Bedienkomfort gestaltet werden.

Cybersicherheit beginnt im Projekt

In HMI/SCADA-Systemen ist Cybersicherheit kein Zusatz zu einer bereits fertigen Visualisierung. Sie ergibt sich aus frühen Entscheidungen: aus der Architektur der Anwendung, dem Berechtigungsmodell, der Art der Kommunikation mit der Steuerung und den Annahmen für den Service. Das ist besonders wichtig, weil die HMI/SCADA-Anwendung zugleich die Schnittstelle zwischen Mensch, Prozess und Infrastruktur bildet. Ein Planungsfehler bleibt daher nicht auf ein IT-Risiko beschränkt. Er kann sich zugleich auf die Reaktion des Bedieners, die funktionale Sicherheit, das Betriebsrisiko und die Kontinuität der Produktion auswirken.

Aus Projektsicht lautet die zentrale Frage daher nicht, welche Schutzmaßnahme am Ende noch ergänzt werden soll, sondern welche Entscheidungen bereits zu Beginn die Angriffsfläche begrenzen. Die größten Probleme entstehen meist nicht durch das Fehlen eines einzelnen Mechanismus, sondern durch ein zu hohes, in die Anwendung eingebautes Vertrauen. In der Praxis bedeutet das gemeinsame Benutzerkonten, einen weitreichenden und dauerhaft verfügbaren Servicezugang, fehlende Rollentrennung zwischen Bediener, Instandhaltung und Integrator sowie eine zu freie Kommunikation zwischen Bedienebene und Steuerung. Bei der Inbetriebnahme wirken solche Lösungen bequem, weil sie die Arbeiten beschleunigen und die Diagnose erleichtern. Später werden sie zu einem dauerhaften Merkmal der Umgebung und erhöhen das Risiko von Missbrauch, Fehlbedienung oder unkontrollierten Änderungen des Prozesszustands.

Deshalb sollte vor der Gestaltung der Bildschirme nicht nur festgelegt werden, was der Benutzer sehen soll, sondern vor allem auch, wo die Vertrauensgrenzen verlaufen, welche Operationen kritisch sind und an welchen Stellen die Schnittstelle zum Werkzeug für Fehler oder zur Umgehung von Verfahren werden kann. Diese Reihenfolge strukturiert die späteren Entscheidungen: ob das HMI ausschließlich eine Visualisierungsebene sein soll oder auch ein Ort für Konfiguration, Diagnose und Rezepturänderungen; ob Servicefunktionen dauerhaft verfügbar sein sollen oder nur nach bewusster Aktivierung; ob der Bediener ausschließlich Zugriff auf die Prozessführung haben soll oder auch auf Operationen, die Parameter und Datenhistorie verändern.

Die praktischen Kosten solcher Versäumnisse zeigen sich meist erst dann, wenn die Anwendung bereits mit Rezepturen, Alarmen, Berichtswesen, Archivierung und Verfahren der Instandhaltung verknüpft ist. Dann ist selbst eine scheinbar einfache Korrektur, etwa die Trennung von Konten, die Änderung des Freigabewegs für eine kritische Operation oder die Beschränkung des Fernzugriffs auf einen gelegentlichen Modus, keine reine Änderung an den Bildschirmen mehr. Sie erfordert eine Überarbeitung der Logik, erneute Tests der Alarmbehandlung, die Klärung von Verantwortlichkeiten und oft auch organisatorische Änderungen im Werk.

In der Praxis ist ein Arbeitsmodell der Benutzerrollen und ihrer Berechtigungen für kritische Operationen, eine Liste der Funktionen, die den Prozesszustand, die Konfiguration oder Rezepturen verändern, sowie ein Verzeichnis externer Verbindungen für Service, Berichtswesen, übergeordnete Systeme und Fernzugriff meist der sinnvollste Ausgangspunkt. Erst auf dieser Grundlage lassen sich die Architektur von Zonen und Verbindungen sinnvoll auslegen und die spätere Risikobeurteilung vorbereiten. Ein solcher Ansatz entspricht sowohl der ingenieurtechnischen Praxis als auch den Anforderungen an klare Verantwortlichkeiten, Funktionstrennung und die Kontrolle der Kommunikation in industriellen Umgebungen.

Wo Kosten und Risiko tatsächlich steigen

Die größten Kosten und Risiken in einer HMI/SCADA-Anwendung ergeben sich nicht allein aus der Tatsache, dass Systeme miteinander verbunden sind, sondern aus den prozessbezogenen und organisatorischen Folgen der einzelnen Anwendungsfunktionen. Besonders kritisch sind die Stellen, an denen Sollwerte schnell geändert, Umgehungen eingerichtet, Alarme quittiert oder stummgeschaltet, Rezepturen geändert oder manuelle Steuerungen ohne vollständigen technologischen Kontext ausgeführt werden können. Lässt das Projekt solche Operationen im Routinebetrieb direkt über den Produktionsbildschirm zu, steigt das Risiko, weil bereits eine einzelne Benutzerentscheidung oder eine einzelne übernommene Sitzung den Prozesszustand unmittelbar verändern kann.

Das bedeutet, dass der Katalog kritischer Operationen als Bestandteil der Sicherheitsarchitektur zu behandeln ist und nicht nur als Frage der Ergonomie der Benutzeroberfläche. Dasselbe gilt für die Nachvollziehbarkeit von Handlungen. Gemeinsame Logins, von einer Schicht gemeinsam genutzte Konten, fehlende Trennung von Berechtigungen für Lesen, Steuern, Konfiguration und Administration sowie eine unzureichende Ereignisprotokollierung führen dazu, dass sich nach einem Vorfall nur schwer belastbar feststellen lässt, ob es sich um einen Fehler, eine Umgehung von Verfahren, einen Missbrauch des Servicezugangs oder eine unbefugte Handlung handelte. Das Problem beschränkt sich nicht auf die reine Ursachenaufklärung. Ohne eine verlässliche Spur der Benutzeraktivitäten lässt sich auch die Wirksamkeit von Verfahren nicht bewerten, Berechtigungen nicht sinnvoll verwalten und betriebliche Entscheidungen weder gegenüber internen Audits noch gegenüber Kundenanforderungen oder den geltenden Sicherheitsrichtlinien belastbar vertreten. In der Praxis geht es hier um die Nachvollziehbarkeit von Handlungen und die Rückverfolgbarkeitskette und nicht nur um die bloße Aufzeichnung von Ereignissen.

Ein weiterer sehr kostspieliger Konstruktionsfehler ist die Übernahme umfangreicher Service- und Diagnosebildschirme in die Produktionsumgebung, die ursprünglich für die Inbetriebnahme oder zur Unterstützung des Integrators erstellt wurden. Solche Ansichten bieten häufig weitreichenden Zugriff auf interne Variablen, das Forcieren von Zuständen, das Löschen von Sperren und die Änderung von Parametern, obwohl sie im Normalbetrieb allenfalls gelegentlich benötigt werden. Wenn sie nicht durch zusätzliche Einschränkungen abgesichert werden, werden sie zum kürzesten Weg für Eingriffe in den Prozess außerhalb des regulären Bedienpfads. Eine sinnvolle Lösung besteht darin, die für die Instandhaltung erforderliche Diagnose von Funktionen zu trennen, die Eingriffe in die Funktionslogik ermöglichen, und gesondert zu entscheiden, ob die Diagnose des Maschinenherstellers lokal, remote oder nur unter bestimmten Bedingungen verfügbar sein soll – nach bewusster Aktivierung und mit vollständiger Sitzungsprotokollierung.

Ebenso ist die Integration mit Datenbanken, Reporting, Fernunterstützung und Bürosystemen zu behandeln. Jede solche Verbindung erhöht den Bedienkomfort, vergrößert aber zugleich die Zahl der Abhängigkeiten, die zum Einfallstor, zur Störquelle oder zur Ursache unklarer Verantwortlichkeiten werden können. Der Ausfall eines vermittelnden Dienstes, eine fehlerhafte Zeitsynchronisation, ein unkontrollierter Datenaustausch mit dem übergeordneten System oder ein offener Servicekanal können nicht nur die Verfügbarkeit von Berichten beeinträchtigen, sondern auch die Entscheidungen des Bedieners beeinflussen.

Daher lohnt es sich, bereits im Entwurf nicht nur die Verfügbarkeit von Bildschirmen zu bewerten, sondern auch einfachere und nützlichere Kennzahlen: die Anzahl kritischer Operationen, die über das produktive HMI möglich sind, die Anzahl aktiver externer Verbindungen, die Anzahl privilegierter Konten sowie den Umfang der Ereignisse, die vom Audit-Trail erfasst werden. Eine solche Überprüfung strukturiert später die Ereignisprotokollierung, die Kontrolle von Parameteränderungen und die Regeln für den Fernzugriff.

Besondere Aufmerksamkeit erfordert das Alarmmanagement. In diesem Bereich verdeckt eine scheinbare Vollständigkeit oft den tatsächlichen Mangel an Kontrolle. Schlecht konzipierte Alarme und Ereignishistorien überlasten den Bediener nicht nur, sondern nehmen ihm auch die Fähigkeit, kritische Signale von technischem Rauschen zu unterscheiden. Wenn sich ein Alarm ohne Begründung leicht stummschalten, ohne Bezug zur Ursache quittieren oder in der Masse diagnostischer Meldungen verlieren lässt, unterstützt die Anwendung die Prozesssicherheit nicht mehr. Deshalb sollten Alarmprioritäten aus den tatsächlichen Auswirkungen auf Menschen, Maschine und Produktqualität abgeleitet werden und mit den Regeln zur Protokollierung von Quittierungen, Umgehungen und Sollwertänderungen verknüpft bleiben. Genau an diesem Punkt hört die Risikobeurteilung auf, ein formales Dokument zu sein, und beginnt, die Benutzeroberfläche zu prägen.

Wie man so konstruiert, dass die Folgen von Fehlern und Missbrauch begrenzt werden

Der Ausgangspunkt ist einfach: Eine HMI/SCADA-Anwendung darf nicht davon ausgehen, dass jeder Benutzer jederzeit korrekt und im richtigen Prozesskontext handelt. Das Projekt muss mit der Trennung der Funktionen beginnen und nicht mit dem Zeichnen von Bildschirmen. Das Team sollte zuerst festlegen, was der Bediener nur sehen darf, was er quittieren kann, was er im normalen Arbeitsablauf ändern darf und welche Handlungen in den Servicemodus verlagert, mit einer zusätzlichen Autorisierung versehen oder vollständig in ein separates Werkzeug oder eine eigene Station ausgelagert werden müssen.

Eine solche Entscheidung ordnet die gesamte Zugriffsarchitektur: Rollen, Berechtigungsumfang, Art der Protokollierung von Handlungen und Bedingungen für die Fernunterstützung. In der Praxis bewährt sich eine Rollenmatrix auf Basis tatsächlicher Aufgaben, die zwischen Bediener, Schichtführer, Instandhaltung, Verfahrenstechniker, Integrator und Administrator unterscheidet. Das ist keine Formalität. Wenn Servicefunktionen auf demselben Bildschirm und unter demselben Konto verbleiben wie die Prozessbedienung, schafft die Anwendung selbst einen Weg für Fehler, Verfahrensumgehungen oder den Missbrauch von Berechtigungen.

Ein gutes HMI/SCADA begrenzt die Möglichkeit, eine gefährliche Operation versehentlich auszuführen, ohne routinemäßige Tätigkeiten unnötig zu verlangsamen. Dafür ist ein klarer Arbeitskontext erforderlich: Der Benutzer muss sehen, an welchem Objekt er arbeitet, in welchem Zustand sich der Prozess befindet, ob er lokal oder remote arbeitet und ob sich das System im Automatik-, Hand- oder Servicemodus befindet. Bestätigungen müssen dem Risiko angemessen sein und dürfen nicht für alle Handlungen gleich ausfallen. Dort, wo die Folgen eines Fehlers reversibel und begrenzt sind, reicht in der Regel eine einzelne Autorisierung aus. Kritische Operationen erfordern zusätzliche Kontrolle: eine zweite Bestätigung, eine erneute Authentifizierung, eine Abhängigkeit vom Prozesszustand oder den physischen Wechsel zu einer getrennten Benutzeroberfläche.

Wichtig sind auch bedingte Sperren. Wenn die Anwendung eine Sollwertänderung, das Forcieren eines Signals oder den Wechsel in den Handbetrieb unabhängig vom Anlagenzustand zulässt, wird das Risiko vom Entwurf auf den Bediener verlagert. Gerade hier zeigt sich, dass eine gute Gestaltung der Bedienoberfläche nicht nur der einfachen Handhabung dient, sondern die Folgen von Fehlern durch integrierte Barrieren begrenzen muss. In vielen Fällen liegt diese Denkweise nahe an dem, wie Poka-Yoke in Produktionslinien funktioniert.

Ein mehrstufiges Zugriffskonzept sollte auch regeln, wie Berechtigungen zeitlich genutzt werden. Personenbezogene Konten sind überall dort erforderlich, wo die Nachvollziehbarkeit von Handlungen erwartet wird. Ein gemeinsames Konto nimmt die Möglichkeit, festzustellen, wer die Entscheidung tatsächlich getroffen hat. Das Minimalprinzip bei Berechtigungen bedeutet, dass der Benutzer nur die Funktionen erhält, die er für seine aktuelle Arbeit benötigt; eine Erweiterung der Rechte erfolgt nur zeitlich befristet und unter kontrollierten Bedingungen. Das gilt insbesondere für die Instandhaltung, den Integrator und den Remote-Support des Herstellers. Ein dauerhaft offener Servicezugang ist nur scheinbar bequem, weil er die natürliche Vertrauensgrenze zwischen Betrieb und Service aufhebt. Sicherer ist ein Modell mit bedarfsgesteuertem Zugriff, zeitlicher Begrenzung, Zuordnung zu einer konkreten Person und Dokumentation in der Ereignishistorie. Dieser Ansatz passt gut zum Least-Privilege-Prinzip und zur Zugriffssegmentierung.

Im gleichen Sinne ist zu entscheiden, ob Servicefunktionen über das Arbeits-HMI verfügbar sein sollen oder ausschließlich über eine separate Station, und ob Wechselmedien sowie ein lokaler Datenimport oder -export über das Bedienpanel zugelassen werden. Diese Entscheidungen sind nicht nebensächlich. Von ihnen hängt ab, ob die Wartbarkeit des Systems kontrolliert sichergestellt wird oder über provisorische Umgehungslösungen erfolgt.

Aus Sicht eines Vorfalls oder einer betrieblichen Auseinandersetzung reicht die Oberfläche allein nicht aus. Die Anwendung muss Informationen hinterlassen, mit denen sich der Entscheidungsweg rekonstruieren lässt. Ereignishistorie, Systemprotokolle und Änderungsaufzeichnungen sollten gemeinsam nicht nur die Frage beantworten, was passiert ist, sondern auch, wer wann, von welchem Ort aus und in welchem Prozesszustand eine Operation ausgeführt hat. Der minimale Umfang an Ereignissen, der in der Regel protokolliert werden sollte, umfasst Anmeldungen, Berechtigungsänderungen, Parameteränderungen, den Wechsel in den Handbetrieb, die Quittierung eines Alarms sowie den Import einer Konfiguration. Entscheidend ist die Verknüpfung des Eintrags mit dem technologischen Kontext, denn die bloße Information über eine Änderung ist ohne den Zustand des Objekts oft wertlos.

Ein gutes Beispiel ist für viele Implementierungen typisch: Die Änderung eines Alarmschwellwerts durch den Verfahrenstechniker kann zulässig sein, aber nur nach dem Wechsel in den vorgesehenen Modus, mit Erfassung von Benutzer, Station, Zeitpunkt, altem und neuem Wert sowie der Bestätigung, dass sich das Objekt nicht in einem kritischen Zustand befand. Eine solche Spur ist sowohl für die Sicherheit als auch für das Änderungsmanagement in industriellen Anwendungen von Bedeutung.

Die letzte Ebene ist die Wartbarkeit ohne Umgehung von Schutzmaßnahmen. Wenn für ein Update, die Wiederherstellung einer Konfiguration oder die Diagnose die Zugriffskontrolle deaktiviert, ein gemeinsames Passwort verwendet oder ohne Audit-Trail gearbeitet werden muss, liegt das Problem im Entwurf und nicht in der Disziplin des Personals. Für Änderungen sollte in der Anwendung ein definierter Ablauf vorgesehen sein: Antrag, Bewertung der Auswirkungen, Test, Implementierung, Bestätigung und Rückfallplan. Außerdem sollte sie die Betriebsumgebung zumindest logisch von der Serviceumgebung trennen und dort, wo es begründet ist, auch organisatorisch und technisch. Konfigurationssicherungen müssen kontrolliert erstellt und wiederhergestellt werden können, ohne ad hoc einen Export „für alle Fälle“ über das Panel auszuführen. Dieser Ansatz ist mit dem Prinzip minimaler Rechte in OT sowie mit den Anforderungen an Zugriffskontrolle, Nachvollziehbarkeit von Handlungen und Änderungsmanagement vereinbar; sein Umfang ist jedoch immer auf die Systemarchitektur und die festgelegte Aufgabenverteilung zu beziehen.

Umsetzung in der Praxis und Bezug zu den Anforderungen

Den größten Nutzen bringt es nicht, am Ende des Projekts weitere Schutzmechanismen hinzuzufügen, sondern die Anwendung vor der Abnahme oder Modernisierung strukturiert zu überprüfen. Das ist der Zeitpunkt, an dem sich die Arbeitsweise des Systems noch vergleichsweise kostengünstig korrigieren lässt, statt später fehlerhafte Annahmen mit zusätzlichen Verfahren zu überdecken. Eine solche Überprüfung sollte ein gemischtes Team durchführen: Projekt, Instandhaltung, Betrieb, Automatisierungstechniker und die für Sicherheit verantwortlichen Personen.

Gegenstand der Bewertung ist nicht nur die technische Konfiguration, sondern auch, ob die Anwendung Rollen tatsächlich trennt, kritische Operationen schützt, den Fernzugriff auf begründete Fälle beschränkt, eine klare Alarmbearbeitung sicherstellt, die Änderungshistorie bewahrt und Sicherungen sowie Notfallverfahren ohne Umgehung von Schutzmaßnahmen ermöglicht. Genau aus einer solchen Überprüfung sollte die Liste für FAT/SAT sowie die Anforderungen hervorgehen, die in die Abnahme, den Serviceplan und die As-built-Dokumentation aufgenommen werden.

Dieser Ansatz verlagert den Schwerpunkt weg von der Diskussion über reine Schutzmaßnahmen hin zu Konstruktionsentscheidungen, die später das Verhalten von Menschen und Anlagen bestimmen. Wenn bereits in der Projektphase nicht festgelegt wird, wer Rezepturparameter ändern darf, wer den Servicemodus freigibt, wie Eingriffe des Integrators dokumentiert werden und unter welchen Bedingungen ein Zugriff von außerhalb des Werks zulässig ist, wird das System nach der Inbetriebnahme auf Ausnahmen und mündlichen Absprachen beruhen.

Aus demselben Grund sollte geklärt werden, ob die Bewertung der Anwendung im Rahmen einer Maschinen- oder Linienmodernisierung oder als eigenständige OT-Überprüfung erfolgt. Der erste Ansatz verknüpft die Sicherheit besser mit der Prozessfunktion, der zweite erleichtert es, Abhängigkeiten zwischen Systemen sowie die Verteilung der Verantwortung für Konten, Berechtigungen und die Protokollierung von Aktivitäten zu erkennen. Das ist auch der natürliche Ort für eine erste Risikoanalyse: die Identifikation kritischer Vorgänge, von Vertrauensgrenzen und der Folgen von Bedienfehlern oder Missbrauch. In der Praxis ist dabei auch eine Risikoanalyse im Projekt hilfreich.

• Rollen und Art der Benutzeranmeldung,
• kritische Vorgänge und Regeln für deren Bestätigung,
• Fernzugriff und Servicefunktionen,
• Alarme, Änderungsprotokollierung und Nachvollziehbarkeit von Aktionen,
• Sicherungen, Wiederherstellung und Notfallverfahren.

Ein gutes Ergebnis im Werk ist nur selten die Folge der gleichzeitigen Einführung vieler Werkzeuge. Meist ist es wichtiger, einige systemische Risiken zu beseitigen, die über Jahre als praktikabel galten. Die Modernisierung einer HMI/SCADA-Anwendung kann mit der Abschaffung gemeinsamer Konten beginnen, mit der Trennung von Service- und Bedienfunktionen, der Beschränkung externer Verbindungen auf kontrollierte Pfade sowie der Einführung einer Änderungsverfolgung von Parametern mit Zuordnung zu einer konkreten Person oder Rolle. Eine solche Änderung muss die Arbeit der Instandhaltung oder des Integrators nicht verschlechtern, sofern Servicemodus, Autorisierungsregeln und ein nachvollziehbarer Ablauf von Änderungen von Anfang an vorgesehen wurden.

Im Betrieb sollte man anschließend nicht ein abstraktes Sicherheitsniveau messen, sondern operativ nutzbare Kennzahlen: die Anzahl gemeinsam genutzter Konten, die noch im System vorhanden sind, den Umfang des aktiven Fernzugriffs, die Vollständigkeit der Änderungsprotokolle, die Zeit zur Wiederherstellung der Konfiguration sowie die Zahl der Eingriffe, die außerhalb des formalen Verfahrens durchgeführt werden. Solche Kennzahlen ermöglichen die Beurteilung, ob das Projekt das Risiko tatsächlich reduziert hat oder es nur in die tägliche Praxis verlagert wurde.

Unter den polnischen und unionsrechtlichen Rahmenbedingungen lässt sich ein Ansatz, bei dem die Cybersicherheit von HMI/SCADA ausschließlich Sache der IT-Abteilung ist, immer schwerer rechtfertigen. Die Verantwortung verteilt sich auf Projektierung, Betrieb, Instandhaltung, Lieferanten und Integratoren, und Branchen- sowie Vertragsanforderungen sind erst dann von Bedeutung, wenn die Organisation Konkretes nachweisen kann: welche Konstruktionsentscheidungen getroffen wurden, wie Berechtigungen vergeben werden, wie die Nachverfolgbarkeit von Aktivitäten aussieht und wer Änderungen kontrolliert. Bloße Verweise auf Normen, Richtlinien oder Vertragsklauseln ersetzen nicht den Nachweis, dass die Anwendung so konzipiert und abgenommen wurde, dass ein sicherer Betrieb möglich ist.

Die wichtigste Schlussfolgerung ist praktischer Natur. Der günstigste und wirksamste Zeitpunkt zur Risikobegrenzung bleibt die Projektierung und Abnahme der Anwendung. Dann lassen sich mit dem geringsten Aufwand Vertrauensgrenzen, Rollen, Zugriffsbedingungen, die Nachverfolgbarkeit von Aktivitäten und die Vorgehensweise bei Änderungen festlegen. Wenn diese Anforderungen in überprüfbare Kriterien gegenüber dem Lieferanten und dem Integrator übersetzt werden, ist HMI/SCADA nicht länger eine bequeme, aber zu vertrauensselige Schnittstelle, sondern wird zu einem Werkzeug für den sicheren Betrieb des Prozesses.