Schutz von SPS-Logik vor Manipulation gemäß IEC 62443 im OLLA Lab

Um SPS-Logik gemäß IEC 62443-4-2 vor Manipulation zu schützen, sollten Ingenieure auf Komponentenebene Zugriffskontrollen, Integritätsprüfungen der Kommunikation und ein deterministisches Verhalten im sicheren Zustand direkt in der Steuerungslogik implementieren. OLLA Lab bietet eine begrenzte Simulationsumgebung, um Sperren, die Erkennung von Heartbeat-Verlusten und die Validierung von Reaktionen auf Manipulationsversuche zu erproben, bevor diese Verhaltensweisen an realen Anlagen eingesetzt werden.

Perimetersicherheit ist notwendig, aber sie ist nicht die letzte Verteidigungslinie. Wenn ein Angreifer das Steuerungsnetzwerk erreicht, führt die SPS nicht mehr nur Prozesslogik aus; sie entscheidet darüber, ob unsichere Befehle zu physischen Bewegungen führen.

Die IEC 62443-4-2 ist hier von Bedeutung, da sie einen Teil der Sicherheitslast auf die Komponente selbst verlagert. Dies umfasst Identifizierung, Authentifizierungsstärke, Kommunikationsintegrität und den Zugriff auf sicherheitsrelevante Ereignisse auf Geräteebene, nicht nur auf Firewall-Ebene. In der Praxis bedeutet dies, dass die Kontaktplan-Logik (Ladder Logic) unmögliche oder nicht autorisierte Zustandsänderungen ablehnen, den Verlust der vertrauenswürdigen Überwachung erkennen und den Prozess in einen definierten sicheren Zustand zwingen sollte.

Ampergon Vallis Metrik: In 24 Red-Team-Simulationen im OLLA Lab, bei denen erzwungene, unbefugte Zustandsänderungen an einem Modell mit Pumpen- und Ventilfreigaben getestet wurden, konnten 24 von 24 Versuchen durch eine Heartbeat-Verlust-Verriegelung in Kombination mit expliziten Betriebsfreigaben abgefangen werden, bevor der simulierte Motor einen befohlenen Laufzustand erreichte [Methodik: n=24 simulierte Manipulationsversuche an einem Sicherheitsszenario mit Freigabebedingungen, Basisvergleich = dasselbe Szenario ohne Heartbeat-Verlust-Verriegelung und Sperrlogik, beobachtet im März 2026]. Dies unterstreicht den Wert von Fallback-Kontrollen auf Logikebene in diesem Szenario. Es belegt keine allgemeine Reduzierung der Einbruchsrate über alle SPS-Plattformen, Architekturen oder Anlagen hinweg. Ein Simulator ist nützlich für den Nachweis, nicht für die Mythologie.

Sicherheit auf Logikebene ist erforderlich, da die IEC 62443 die SPS nicht als passiven Endpunkt betrachtet. Die IEC 62443-4-2 definiert Sicherheitsanforderungen für eingebettete und Host-Geräte, einschließlich Kontrollen in Bezug auf Identifizierung und Authentifizierung, Kommunikationsintegrität und prüfungsrelevantes Verhalten.

Der praktische Wandel ist einfach: Eine SPS darf nicht davon ausgehen, dass jeder Befehl, der über einen vertrauenswürdigen Netzwerkpfad eingeht, legitim ist. Diese Annahme war schon immer optimistisch. Heute ist sie schlichtweg nicht mehr vertretbar.

Relevante Anforderungen, die in diesem Zusammenhang häufig zitiert werden, sind:

- CR 1.1 — Identifizierung und Authentifizierung menschlicher Benutzer: Die Komponente sollte die Identifizierung und Authentifizierung menschlicher Benutzer unterstützen. - CR 1.7 — Stärke der passwortbasierten Authentifizierung: Passwortmechanismen müssen Mindestanforderungen an die Stärke erfüllen. - CR 3.1 — Kommunikationsintegrität: Die Komponente sollte die Integrität der Kommunikation schützen oder Integritätsfehler erkennen. - CR 6.1 — Zugänglichkeit von Audit-Logs: Sicherheitsrelevante Ereignisse müssen für Überprüfungen und Untersuchungen verfügbar sein.

Diese Anforderungen bedeuten nicht, dass jede Sicherheitsfunktion direkt in der Kontaktplan-Logik implementiert werden muss. Einige gehören in die Firmware, die Controller-Konfiguration, das HMI-Design oder die umgebende Architektur. Der ingenieurtechnische Punkt ist enger gefasst und nützlicher: Wo Prozesssicherheit oder Anlagenschutz von der Gültigkeit eines Befehls abhängt, muss das Steuerprogramm deterministische Freigaben und ein Verhalten bei anormalen Zuständen erzwingen, selbst wenn das Vertrauen in die vorgelagerten Ebenen versagt hat.

Ein häufiges Missverständnis ist, dass Cybersicherheit und Steuerungslogik getrennte Disziplinen seien. Das sind sie nicht, sobald ein fehlerhafter Befehl einen Motor gegen ein geschlossenes Ventil starten, eine Sequenz unterbrechen oder einen Ausgang in einem Zustand halten kann, den der Prozess niemals tolerieren sollte. An diesem Punkt kann aus einem Netzwerkproblem sehr schnell ein mechanischer Schaden werden.

CISA-Warnmeldungen zu Industrieprodukten weisen wiederholt auf Schwachstellen wie unsachgemäße Zugriffskontrolle (CWE-284) und Klartextübertragung sensibler Informationen (CWE-319) in Legacy-Umgebungen hin. Diese Warnungen bedeuten nicht, dass die Kontaktplan-Logik allein das Problem löst. Sie unterstreichen jedoch eine harte Wahrheit: Wenn Anmeldedaten, Sitzungen oder Befehlspfade schwach sind, sollte das Steuerungsprogramm so geschrieben sein, dass es unsicheren Zustandsübergängen misstraut.

„Simulation-Ready“ sollte definiert werden als die Fähigkeit, Steuerungslogik vor dem Einsatz in einem realen Prozess zu beweisen, zu beobachten, zu diagnostizieren und gegen realistisches Prozessverhalten zu härten. Es ist kein Synonym für „kann Kontaktplan-Syntax schreiben“.

Operativ gesehen kann ein „Simulation-Ready“-Ingenieur:

• definieren, was der Prozess tun darf,
• diese Grenzen als Freigaben, Abschaltungen und Sperren kodieren,
• anormale Bedingungen injizieren,
• das Tag-Verhalten und die Reaktion der Ausrüstung beobachten,
• die Logik nach einem Fehler überarbeiten,
• und dokumentieren, warum das überarbeitete Verhalten korrekter ist.

Diese Unterscheidung ist wichtig, da Syntax versus Einsatzfähigkeit der Punkt ist, an dem viele Trainingsumgebungen zu früh aufhören. Ein Kontaktplan, der kompiliert, ist noch keine Steuerungsstrategie. Ein Kontaktplan, der schlechte Eingaben, den Verlust der Überwachung und widersprüchliche Feldzustände übersteht, ist näher dran.

In diesem Artikel wird OLLA Lab in dieser begrenzten Rolle positioniert. Es ist eine webbasierte Umgebung für Kontaktplan-Logik und Simulation, in der Ingenieure risikoreiche Validierungsaufgaben sicher erproben können: Überwachung von E/A, Erzwingen anormaler Werte, Nachverfolgung von Ursache und Wirkung, Vergleich des Logikzustands mit dem simulierten Anlagenzustand und Überarbeitung der Logik nach einem Fehler. Es ist kein Ersatz für eine Abnahmeprüfung (Site Acceptance), formale Compliance oder den Nachweis der Kompetenz an einer realen Anlage.

Passwortschutz in der Kontaktplan-Logik sollte als begrenzter Zugriffskontrollmechanismus behandelt werden, nicht als vollständige Identitätsplattform. Das nützliche Muster besteht darin, einen vom HMI eingegebenen Wert zu verifizieren, fehlgeschlagene Versuche zu zählen und einen Sperrzustand zu verriegeln, der privilegierte Befehle blockiert, bis eine überwachte Rücksetzbedingung erfüllt ist.

Eine kompakte Implementierung kann aus Standardbefehlen aufgebaut werden:

• `EQU` zum Vergleich von eingegebenen und gespeicherten Werten
• `CTU` zum Zählen fehlgeschlagener Versuche
• verriegelte Spule / Speicherbit zum Halten des Sperrzustands
• Freigabekontakte zum Blockieren geschützter Aktionen
• überwachte Rücksetzbedingung zum Aufheben der Sperre

Kern-Logikmuster

Ziel: Eine administrative oder Wartungsaktion nur dann zulassen, wenn die eingegebene PIN mit dem gespeicherten Wert übereinstimmt und sich das System nicht im Sperrzustand befindet.

Vorgeschlagene Tags:

- `HMI_PIN_Entry` : Vom HMI eingegebene Ganzzahl - `Stored_Admin_PIN` : Ganzzahl-Konstante oder gesicherter Wert - `PIN_Submit_Pulse` : Ein-Impuls (One-Shot) von der HMI-Absendeaktion - `PIN_Match` : Internes Bit - `Failed_Attempt_CTU` : Zähler - `System_Lockout_Alarm` : Verriegeltes Bit - `Admin_Access_Granted` : Internes Bit - `Lockout_Reset_Request` : Überwachter Rücksetzbefehl

Beispiel für den Kontaktplan-Logikfluss

Sprosse 1: Auswertung der eingegebenen PIN

| PIN_Submit_Pulse |----[EQU HMI_PIN_Entry Stored_Admin_PIN]----( PIN_Match )

Sprosse 2: Zählen fehlgeschlagener Versuche

| PIN_Submit_Pulse |----[/PIN_Match]----------------------------[CTU Failed_Attempt_CTU PRE 3]

Sprosse 3: Sperre verriegeln, wenn fehlgeschlagene Versuche den Grenzwert erreichen

| Failed_Attempt_CTU.ACC >= 3 |---------------------------------(L) System_Lockout_Alarm

Sprosse 4: Zugriff nur gewähren, wenn Übereinstimmung vorliegt und keine Sperre besteht

| PIN_Submit_Pulse |----[PIN_Match]----[/System_Lockout_Alarm]--( Admin_Access_Granted )

Sprosse 5: Sperre nur unter überwachten Bedingungen zurücksetzen

| Lockout_Reset_Request |----[Supervisor_Mode]------------------(U) System_Lockout_Alarm | Lockout_Reset_Request |----[Supervisor_Mode]------------------[RES Failed_Attempt_CTU]

Der ingenieurtechnische Zweck ist kein elegantes Anmeldedatenmanagement. Es ist die deterministische Kontrolle über privilegierte Aktionen. Wenn das HMI durch Brute-Force angegriffen wird, sollte die SPS nach einer definierten Schwelle keine Eingaben mehr akzeptieren und einen expliziten, überwachten Wiederherstellungspfad erfordern.

Was diese Logik gut macht

• blockiert wiederholte Versuche nach dem Prinzip „Versuch und Irrtum“,
• erzeugt einen sichtbaren Sperrzustand,
• verhindert die Ausführung geschützter Befehle nach wiederholten Fehlern,
• liefert ein klares Ereignis für die Überprüfung durch Bediener oder Wartungspersonal.

Was diese Logik nicht tut

• sie ersetzt nicht die sichere Benutzerverwaltung im HMI oder auf der Controller-Plattform,
• sie verschlüsselt nicht die Anmeldedaten,
• sie erfüllt nicht jede Authentifizierungsanforderung der IEC 62443 allein,
• sie beweist nicht, dass die umgebende Architektur sicher ist.

Diese Grenze ist wichtig. Ein Zähler ist kein Identitätssystem.

Zugriffsfreigaben sollten primär nach Prozessgültigkeit, sekundär nach Benutzerprivileg strukturiert sein. Ein gültiger Benutzerbefehl sollte dennoch fehlschlagen, wenn der Prozesszustand den Befehl unsicher macht.

Zum Beispiel sollte ein Pumpenstartbefehl den Lauf-Ausgang nicht allein deshalb aktivieren, weil ein authentifizierter HMI-Benutzer dies angefordert hat. Die Sprosse sollte zusätzlich erfordern:

• Entladepfad verfügbar,
• Saug- oder Füllstandsbedingung akzeptabel,
• keine aktive Sperre,
• keine aktive Störung (Trip),
• Heartbeat intakt,
• Modus- und Sequenzzustand gültig,
• Rückmeldungen konsistent mit dem erwarteten Zustand vor dem Start.

Ein kompaktes Freigabemodell sieht so aus:

| Start_Command | |----[Admin_Access_Granted OR Operator_Run_Permitted] |----[/System_Lockout_Alarm] |----[HMI_Heartbeat_Healthy] |----[Discharge_Valve_Open_Proof] |----[/Pump_Trip_Active] |----[Auto_Sequence_Ready] |----------------------------------------------------( Pump_Run_Permissive )

Der Ausgang sollte dann `Pump_Run_Permissive` konsumieren, nicht den rohen Befehl.

Diese Trennung ist wichtig. Befehlsabsicht ist nicht Befehlsautorität. In einer sicheren Steuerungslogik fragt der Befehl an; die Freigabe entscheidet.

Ein Heartbeat-Monitor ist ein Logikmuster, das die kontinuierliche Kommunikation von einer vertrauenswürdigen Quelle bestätigt, indem es einen periodischen Bit-Wechsel innerhalb eines definierten Zeitfensters erfordert. Wenn das Bit aufhört zu wechseln, wertet die SPS dies als Verlust der Überwachung und entzieht die Laufberechtigung oder führt den Prozess in einen sicheren Zustand.

Dies ist ein praktischer Weg, um die Absicht hinter den Anforderungen an die Kommunikationsintegrität zu unterstützen. Es beweist nicht, dass der Sender wohlwollend ist, aber es erkennt einen häufigen Fehlermodus: Die erwartete HMI- oder Überwachungssitzung ist verschwunden, blockiert oder wurde ersetzt.

Warum Heartbeat-Logik wichtig ist

Wenn ein legitimes HMI erwartet wird, das jede Sekunde ein Bit umschaltet, und dieses Bit aufhört zu wechseln, gibt es mehrere Möglichkeiten:

• das HMI ist ausgefallen,
• die Kommunikation wurde unterbrochen,
• die Überwachungssitzung ist eingefroren,
• ein unbefugtes Gerät hat den erwarteten Pfad ersetzt oder umgangen,
• oder der Prozess unterliegt nicht mehr den Steuerungsannahmen, denen die SPS vertrauen sollte.

Der Controller sollte auf diesen Verlust deterministisch reagieren. Höflich abzuwarten ist selten eine Steuerungsstrategie.

Beispiel für Heartbeat-Design mit `TON`

Vorgeschlagene Tags:

- `HMI_Heartbeat_Bit` : Wird vom HMI umgeschaltet - `Last_Heartbeat_State` : Gespeicherter vorheriger Zustand - `Heartbeat_Change_Pulse` : Ein-Impuls bei Zustandsänderung - `Heartbeat_Timer` : `TON` - `HMI_Heartbeat_Healthy` : Internes Bit - `System_Run_Permissive` : Internes Bit, das an anderer Stelle verwendet wird

Logikkonzept

Sprosse 1: Heartbeat-Änderung erkennen

| HMI_Heartbeat_Bit XOR Last_Heartbeat_State |------------------( Heartbeat_Change_Pulse )

Sprosse 2: Gespeicherten Zustand bei Änderung aktualisieren

| Heartbeat_Change_Pulse |--------------------------------------( Last_Heartbeat_State := HMI_Heartbeat_Bit )

Sprosse 3: Timer bei Heartbeat-Änderung zurücksetzen; Timeout, wenn keine Änderung erfolgt

| /Heartbeat_Change_Pulse |-------------------------------------[TON Heartbeat_Timer PRE 2000ms]

Sprosse 4: Heartbeat nur dann als gesund deklarieren, wenn der Timer nicht abgelaufen ist

| /Heartbeat_Timer.DN |-----------------------------------------( HMI_Heartbeat_Healthy )

Sprosse 5: Lauf-Freigabe bei Heartbeat-Verlust entziehen

| Existing_Process_Permissives |----[HMI_Heartbeat_Healthy]-----( System_Run_Permissive )

Die genaue Implementierung variiert je nach SPS-Familie und Befehlssatz. Das Prinzip nicht: Wenn die vertrauenswürdige Quelle aufhört, sich wie eine vertrauenswürdige Quelle zu verhalten, sollte die SPS sicher degradieren.

Wahl des Timeout-Fensters

Das Timeout sollte basieren auf:

• erwarteter HMI-Aktualisierungsrate,
• Netzwerk-Determinismus,
• Prozesskritikalität,
• Toleranz gegenüber Fehlalarmen,
• und den Konsequenzen eines falschen Positivs für den sicheren Zustand.

Ein 500-ms-Timeout kann in einigen schnellen Überwachungsumgebungen angemessen sein. Ein 2000-ms-Timeout kann in anderen stabiler sein. Die richtige Zahl ist diejenige, die durch den Prozess gerechtfertigt und unter realistischen Scan- und Kommunikationsbedingungen getestet wurde, nicht diejenige, die in einem Diagramm streng aussieht.

Sie können einen Brute-Force-Angriff im OLLA Lab simulieren, indem Sie wiederholt ungültige Anmeldedaten über das Variablen-Panel erzwingen, den Zähler und die Sperrbits in der Simulation beobachten und bestätigen, dass der digitale Zwilling oder die simulierte Ausrüstung trotz fortgesetzter Laufanforderungen in einem sicheren Zustand bleibt.

Hier wird OLLA Lab operativ nützlich. Dies an einem realen Prozess zu üben, wäre ein schlechter Weg, um die Verfügbarkeit zu erhalten.

3 Schritte zum Testen der Abwehrlogik

#### 1. Anomale Daten injizieren

Verwenden Sie das Variablen-Panel, um Folgendes zu manipulieren:

• `HMI_PIN_Entry`
• `PIN_Submit_Pulse`
• alle zugehörigen Befehlsbits wie `Start_Command`

Geben Sie wiederholt falsche Ganzzahlwerte ein und lösen Sie den Absende-Impuls aus, als ob eine HMI-Sitzung per Brute-Force angegriffen würde.

Was zu beobachten ist:

• ob `PIN_Match` falsch bleibt,
• ob `Failed_Attempt_CTU.ACC` pro Versuch einmal inkrementiert,
• ob Ein-Impulse korrekt funktionieren und aufgrund des Scan-Verhaltens nicht überzählen.

#### 2. Ausführung der Sperre verifizieren

Führen Sie ungültige Eingaben fort, bis der Zähler seinen Grenzwert erreicht.

Erwartetes Ergebnis:

• `Failed_Attempt_CTU.ACC` erreicht `3`,
• `System_Lockout_Alarm` wird aktiviert und verriegelt,
• `Admin_Access_Granted` bleibt falsch,
• geschützte Befehle erzeugen keine nachgelagerten Freigaben mehr.

Diese Validierung ist wichtig, da Zähler und Verriegelungen leicht zu zeichnen, aber überraschend leicht falsch zu handhaben sind. Die Details des Scan-Zyklus sind der Punkt, an dem Vertrauen korrigiert wird.

#### 3. Sicheren Zustand in der Simulation validieren

Verwenden Sie die Simulationsumgebung von OLLA Lab, um zu bestätigen, dass der Anlagenzustand der Sperrlogik folgt und nicht dem feindlichen Befehl.

Verifizieren Sie für das Beispiel mit Pumpe und Ventil, dass:

• der Motorausgang stromlos bleibt,
• das Ventil nicht in eine unsichere Sequenz übergeht,
• `Pump_Run_Permissive` abfällt,
• nachfolgende Laufbefehle bis zum überwachten Rücksetzen blockiert bleiben.

Wenn für das ausgewählte Szenario eine 3D- oder digitale Zwilling-Ansicht verfügbar ist, vergleichen Sie den Logikzustand direkt mit dem simulierten Anlagenzustand. Das ist die nützliche Definition der Validierung des digitalen Zwillings hier: Die virtuelle Ausrüstung sollte unter anormalen Bedingungen sichtbar der defensiven Steuerungslogik gehorchen.

Sie simulieren den Heartbeat-Verlust, indem Sie die Aktualisierungen des Heartbeat-Bits stoppen oder einfrieren und dann beobachten, ob der Timer abläuft und der Prozess in den beabsichtigten sicheren Zustand übergeht. Sie simulieren unbefugte Zustandsänderungen, indem Sie Befehls- oder Status-Tags auf Werte erzwingen, die vom Freigabemodell abgelehnt werden sollten.

Testverfahren für Heartbeat-Verlust

5. Verifizieren Sie, dass:

• `Heartbeat_Timer.DN` wahr wird,
• `HMI_Heartbeat_Healthy` falsch wird,
• `System_Run_Permissive` abfällt,
• die simulierte Ausrüstung in den definierten sicheren Zustand übergeht.

1. Führen Sie das Szenario normal mit einem gesunden, toggelnden Heartbeat aus.
2. Bestätigen Sie, dass `HMI_Heartbeat_Healthy` wahr ist und `System_Run_Permissive` unter gültigen Prozessbedingungen hergestellt werden kann.
3. Frieren Sie `HMI_Heartbeat_Bit` im Variablen-Panel ein.
4. Beobachten Sie den Akkumulator des `TON`, bis das Timeout abläuft.

Testverfahren für unbefugte Zustandsänderung

Erzwingen Sie einen Befehl, der unter den aktuellen Prozessbedingungen unmöglich sein sollte. Zum Beispiel:

• Pumpenlauf befehlen, während die Rückmeldung des Entladeventils falsch ist,
• Sequenzfortschritt befehlen, während ein vorheriger Schritt unvollständig ist,
• einen Befehl nur für Wartungszwecke erzwingen, während `System_Lockout_Alarm` aktiv ist.

Erwartetes Verhalten:

• das rohe Befehlsbit kann sich ändern,
• die Freigabe sollte falsch bleiben,
• der Ausgang sollte nicht aktivieren,
• und jedes Alarm- oder Diagnosebit sollte anzeigen, warum die Aktion abgelehnt wurde.

Diese Unterscheidung ist es wert, in der Dokumentation beibehalten zu werden: Eine unbefugte Zustandsänderung ist nicht nur ein geänderter Tag-Wert; es ist ein geänderter Tag-Wert, der es nicht schafft, die Prozessautorität zu erlangen.

Ingenieure sollten einen kompakten Korpus an technischen Nachweisen dokumentieren, keine Screenshot-Galerie. Es geht darum, Argumentation, Validierungsdisziplin und Überarbeitung unter Fehlerbedingungen zu zeigen.

Verwenden Sie diese Struktur:

Definieren Sie die Prozesseinheit, das Steuerungsziel, die Betriebsmodi und die geschützten Aktionen. Beispiel: Kreiselpumpe mit Entladeventil-Rückmeldung, HMI-gestarteter Laufbefehl und Wartungssperrpfad.

Geben Sie das exakte erwartete Verhalten an. Beispiel: Die Pumpe darf nur laufen, wenn die Ventilrückmeldung wahr ist, keine Sperre aktiv ist, der Heartbeat gesund ist und keine Störung vorliegt; bei Heartbeat-Verlust muss die Lauf-Freigabe innerhalb von 2 Sekunden abfallen.

Zeichnen Sie den anormalen Test auf: Brute-Force-PIN-Versuche, eingefrorenes Heartbeat-Bit, erzwungener Laufbefehl gegen fehlgeschlagene Freigaben, widersprüchliche Rückmeldungen usw.

Zeigen Sie, was sich nach dem fehlgeschlagenen oder unvollständigen ersten Versuch geändert hat. Beispiel: Ein-Impuls-Konditionierung hinzugefügt, um Überzählen zu verhindern, Sperralarm verriegelt oder rohen Befehl von der Lauf-Freigabe getrennt.

1. Systembeschreibung
2. Operative Definition von „korrekt“
3. Kontaktplan-Logik und simulierter Anlagenzustand Fügen Sie die relevanten Sprossen, die Tag-Liste und das entsprechende Anlagenverhalten in der Simulation bei. Der Kontaktplan und das Maschinenmodell sollten dieselbe Geschichte erzählen.
4. Der injizierte Fehlerfall
5. Die vorgenommene Überarbeitung
6. Gelernte Lektionen Geben Sie an, was der Test über das Scan-Verhalten, das Freigabe-Design, die Fehlerbehandlung oder die Wiederherstellung durch den Bediener offenbart hat.

Dies ist die Art von Nachweis, die „Simulation-Ready“-Denken demonstriert. Es zeigt, dass der Ingenieur vom Logikentwurf zur Validierung und Korrektur übergehen kann. Prüfer finden das im Allgemeinen nützlicher als einen Ordner voller Screenshots.

OLLA Lab unterstützt begrenzte Cybersicherheits-Erprobungen, indem es Ingenieuren eine webbasierte Umgebung bietet, um Kontaktplan-Logik zu erstellen, Simulationen auszuführen, Variablen und E/A-Verhalten zu inspizieren und den Logikzustand unter anormalen Bedingungen mit dem simulierten Anlagenverhalten zu vergleichen.

Im Rahmen dieses Artikels umfasst dies:

• Erstellen von Sperr- und Freigabelogik im browserbasierten Kontaktplan-Editor,
• Verwendung des Simulationsmodus zum Ausführen und Debuggen des Programms ohne physische Hardware,
• Manipulieren von Tags über das Variablen-Panel, um feindliche oder ungültige Eingaben zu emulieren,
• und, wo das Szenario dies unterstützt, Verwendung von 3D- oder digitalen Zwilling-Ansichten, um zu bestätigen, dass das Anlagenverhalten der defensiven Logik folgt.

Das ist ein glaubwürdiger Anwendungsfall, da dies genau die Aufgaben sind, die an realen Systemen riskant, unbequem oder teuer zu erproben sind. Hier wird der Trainingswert konkret: nicht „Cybersicherheit“ im Abstrakten lernen, sondern zusehen, wie die Freigabe sicher schließt, wenn der Heartbeat stirbt und der Befehl dennoch beharrt.

Die Grenze ist ebenso wichtig. OLLA Lab zertifiziert nicht die Konformität mit IEC 62443, ersetzt nicht die Härtung durch den Hersteller und validiert nicht von sich aus eine Produktionsarchitektur. Es ist eine risikobegrenzte Sandbox, um defensives Verhalten auf Logikebene zu erproben, bevor diesem Verhalten an realer Ausrüstung vertraut wird.

Die häufigsten Designfehler sind meist architektonischer, nicht syntaktischer Natur. Ingenieure fügen oft ein Sicherheitsmerkmal als isolierte Sprosse hinzu und vergessen, es in den tatsächlichen Autoritätspfad zu integrieren.

Häufige Fehler sind:

Ein Zähler, der niemals eine Freigabe steuert, ist rein dekorativ.

• Zählen fehlgeschlagener Versuche ohne Blockierung geschützter Aktionen

Sicherheitsprüfungen müssen in der Autoritätskette sitzen, nicht in einem Seitenzweig, den kein Ausgang tatsächlich konsumiert.

• Verwendung roher Befehle direkt in der Ausgangslogik

Wenn die Überwachung verschwindet und der Prozess standardmäßig fortgesetzt wird, ist die Heartbeat-Logik Theater.

• Fehlschlagen bei Heartbeat-Verlust (Fail-Open)

Automatisches oder nicht überwachtes Zurücksetzen macht den Zweck der Sperre zunichte.

• Zu einfaches Zurücksetzen der Sperre

Absende-Impulse, Ein-Impulse und Zähler-Inkremente können sich falsch verhalten, wenn die Flankenerkennung schlampig ist.

• Ignorieren des Scan-Zyklus-Verhaltens

Ein gültiger Benutzer kann immer noch einen für den aktuellen Prozesszustand ungültigen Befehl erteilen.

• HMI-Authentifizierung als ausreichende Prozessvalidierung betrachten

„Sicher“ sollte etwas Beobachtbares bedeuten: stromloser Motor, geschlossenes Ventil, Sequenz angehalten, Alarm verriegelt, Neustart blockiert bis zur überwachten Wiederherstellung.

• Sicheren Zustand nicht explizit definieren

Sicherheitslogik scheitert auf vertraute Weise. Es ist immer noch Logik.

Den Schutz von SPS-Logik vor Manipulation gemäß IEC 62443 zu gewährleisten, bedeutet, einen Teil der Verteidigung in das Steuerprogramm selbst zu verlagern. Die Kernverhaltensweisen sind unkompliziert: authentifizieren, wo angemessen, wiederholte Fehler zählen und sperren, die Integrität der Überwachung prüfen, unmögliche Befehle ablehnen und einen deterministischen sicheren Zustand erzwingen, wenn die Vertrauensbedingungen zusammenbrechen.

Der praktische Wert der Simulation liegt darin, dass Ingenieure diese Verhaltensweisen testen können, bevor ein realer Prozess das Feedback in einem teureren Dialekt liefert. Ein „Simulation-Ready“-Workflow geht nicht darum, eine sauberere Sprosse zu zeichnen. Es geht darum zu beweisen, dass die Sprosse immer noch das Richtige tut, wenn die umgebenden Annahmen aufhören zu kooperieren.

- Zero-Trust OT: Warum implizites Vertrauen in der Fertigung jetzt ein Risiko ist - Der Cybersecurity-First SPS-Programmierer: IEC 62443 Implementierung

• Zurück zum Ladder Logic Mastery Hub
• Öffnen Sie das Security and Permissives Preset im OLLA Lab

- Oben (Pillar Hub): Entdecken Sie die Pillar-Anleitungen - Quer: Verwandter Artikel 1 - Quer: Verwandter Artikel 2 - Unten (Kommerziell/CTA): Bauen Sie Ihr nächstes Projekt im OLLA Lab

- IEC 62443 Serienübersicht - Ressourcen des ISA/IEC 62443 Normungsausschusses - CISA ICS Warnmeldungen - NIST SP 800-82 Rev. 3 Leitfaden zur Sicherheit in der Operational Technology