Wie Sie echte OT-Sicherheitsmaßnahmen mit IEC 62443-Risikobewertung erreichen

Zusammenfassung: Gehen Sie weit über das Abhaken einer Checkliste hinaus und streben Sie eine echte IEC 62443-Compliance an. Erfahren Sie, wie eine IEC 62443-Risikobewertung verwendet werden kann, um testbare Security Levels (SLs) für Ihre OT/ICS-Umgebung festzulegen. Dies ist ein umsetzbarer Leitfaden.

Bevor wir beginnen, vergessen Sie nicht, unseren vorherigen Beitrag „Warum OT-Sicherheitsgovernance nicht länger warten kann: Ein Aufruf zum Handeln für CISOs“ hier anzusehen. Ich bin sicher, Sie werden diesen Beitrag nützlich finden.  

Beginnen wir damit, zu verstehen, warum OT-Sicherheitsbewertungen normalerweise nicht den Erwartungen entsprechen oder sich in eine Übung verwandeln, die nur auf dem Papier gut aussieht. 

Warum Ihre OT-Risikobewertung fehlschlägt

Vor einer Woche sagte Ihnen jemand, dass Sie eine Risikobewertung für Operational Technology (OT) benötigen. Also engagieren Sie einen Anbieter für Risikobewertungen oder wenden sich an einen OEM. Sie verbringen Wochen damit, Menschen zu interviewen, Netzwerktopologien zu studieren, Desktop-Anwendungen zu überprüfen und auf Google nach „Wie man eine OT-Sicherheitsbewertung durchführt“ zu suchen.

Sie erhalten einen 18-seitigen Bericht voller "Hoher", "Mittlerer" und "Niedriger" Risiken sowie eine Liste zufälliger Lücken mit vagen Empfehlungen wie "Systeme patchen" und "Segmentierung verbessern". Der Bericht enthält umfangreiche Details zur IT-Seite, aber aus irgendeinem Grund machen die Empfehlungen und Ergebnisse auf der OT-Seite keinen Sinn.

Sie wenden sich dann an einen echten OT-Sicherheitsbewertungsanbieter wie Shieldworkz und lassen den Bericht überprüfen, und was stellen wir fest?

· Der Bericht ist nur eine Vorlage, in die zufälliges Kauderwelsch eingefügt wurde, um den Inhalt groß und umfassend erscheinen zu lassen

· Bei einer tieferen Untersuchung finden wir Vermögenswerte und Prozesse, die nicht einmal dem Kunden gehören

· Obwohl der Gutachter behauptet, einen auf IEC 62443 basierenden Bericht erstellt zu haben, gibt es dafür keine Beweise

· Der Bericht ist im Grunde für den Kunden von sehr geringem Nutzen 

Was ist also schiefgelaufen? Sie haben keine Risikobewertung durchgeführt; Sie haben lediglich eine Compliance-Checkliste abgeschlossen und den falschen Bewertungsanbieter engagiert.

Dies ist ein Szenario, das wir viele Male erleben.

In der Welt der industriellen Steuerungssysteme (ICS) ist die gesamte Übung der Risikobewertung nicht nur eine Prüfung. Es ist ein Reengineering-Prozess, der in Zeitlupe durchgeführt wird. Die IEC 62443-Serie, insbesondere IEC 62443-3-2: Sicherheitsrisikobewertung für Systemdesign, spricht darüber, die Risiken zu verstehen, die aus Systemen entstehen, und diese mit einem robusten System-, Prozess- und Netzwerkdesign zu begegnen, um eine Umgebung zu schaffen, die sich zur Verteidigung anbietet.

Die rohe Kraft der IEC 62443: Von „Risiko“ zu „Überprüfbaren Anforderungen“

Dies ist im Wesentlichen das wichtigste Konzept, das man verstehen muss: Das Ziel einer 62443-Risikobewertung besteht nicht darin, ein Kompendium von Risiken und Schwachstellen zu erstellen.

Stattdessen besteht das Ziel darin, das Ziel-Sicherheitslevel (SL-T) für verschiedene Teile Ihrer Anlage zu ermitteln und herauszufinden, was Sie daran hindert, dieses Level zu erreichen.

Stellen Sie sich das wie eine Sicherheitsinspektion wie eine Feuerinspektion eines hohen Gebäudes wie des One World Trade Centers vor. Sie sagen nicht einfach, "Das Design eines bestimmten Aspekts ist 'hoch riskant'." Sie sagen, "Dieser Aspekt muss ein Safety Integrity Level (SIL) 3 erreichen." Diese SIL-3-Bewertung geht mit spezifischen, nicht verhandelbaren und überprüfbaren ingenieurtechnischen Anforderungen einher.

IEC 62443 wendet diese Logik auch auf die Cybersicherheit an.

•    Security Level 1 (SL-1): Schützt vor unbeabsichtigter Fehlanwendung.

•    Security Level 2 (SL-2): Schützt vor "Hacktivisten" mit einfachen Werkzeugen oder einem größeren Missbrauchslevel.

•    Security Level 3 (SL-3): Schützt vor "erfahrenen Angreifern" (z.B. Industriespionage).

•    Security Level 4 (SL-4): Schützt vor "staatlichen Akteuren" mit umfangreichen Ressourcen und Fähigkeit, tiefgreifende Angriffe durchzuführen.

Ihre Risikobewertung ist die förmliche Abfolge von Tests, die Sie verwenden, um zu rechtfertigen zu sagen, "Diese Produktionslinie (Zone) muss SL-2 sein, aber dieses kritische Kessel-Sicherheitssystem (Zone) muss SL-3 sein." Alles erfordert Beweise

Sobald Sie dieses SL-T haben, haben Sie Ihren Bauplan herausgefunden. Aber wir haben mehr Dinge zu tun. Sie wenden sich einfach an IEC 62443-3-3 (System Security Requirements) und erhalten eine vollständige Liste von Anforderungen (wie "starke Passwörter erzwingen", "verschlüsselte Protokolle verwenden", "Datenflüsse einschränken"), die Ihr System erfüllen muss, um dieses spezifische Sicherheitslevel zu erreichen.

Und voila, Ihre Risikobewertung ist kein vager Bericht oder ein undefinierter Prozess mehr. Es ist eine Bauvorgabe.

Stellen Sie sich vor, der interstellare 3i Atlas würde sich in ein Mutterschiff verwandeln, das feindliche Sonden startet, würden Sie einfach herumsitzen und warten, bis sie angreifen, oder würden Sie eine Reihe vordefinierter Übungen einleiten, um die Bedrohung zu bewältigen? [Das ist nur eine Zeile, die mir beim Schreiben dieses Textes eingefallen ist]. Die Idee ist sicherzustellen, dass wir dem Aufwand ein angemessenes Maß an Aufmerksamkeit und Gedanken schenken.    

Konsequenzbasierte Zonenbildung

Heutzutage dreht sich alles um Konsequenzen.

Wie bestimmen Sie also das Ziel-SL? Sie verwenden das mächtigste (und am meisten missverstandene) Werkzeug im 62443-Standard: Zonen und Leitungen.

Dies ist die einzigartige Erkenntnis: Hören Sie auf, Ihre Zonen ausschließlich auf Basis Ihres Netzwerkschemas zu zeichnen.

Die meisten Leute machen das falsch. Sie schauen sich ein Netzwerkschema an, sehen eine Firewall und sagen, "Das ist eine Zone." Das ist ein auf Vermögenswerte basierendes Denken und es ist schwach. Zum einen könnte das Netzwerkschema selbst fehlerhaft sein oder es wurde zuletzt aktualisiert, als Oumuamua zum ersten Mal entdeckt wurde.

Eine IEC 62443-Zone ist eine Gruppierung von Vermögenswerten, die eine gemeinsame Konsequenz teilen.

Anstatt mit Vermögenswerten zu beginnen, stellen Sie Ihren Ingenieuren und Sicherheitsmanagern diese grundlegenden Fragen:

Was ist das absolut schlimmste physikalische Ereignis, das hier passieren kann?

· Mögliche Antwort: „Eine katastrophale Kesselexplosion oder ein Gasaustritt.“ (Sicherheitskonsequenz)

Was ist das schlimmste betriebliche Ereignis, das passieren kann?

· Mögliche Antwort: "Die gesamte Produktionslinie 'Batch 1' funktioniert 24 Stunden lang nicht mehr." (Verfügbarkeitskonsequenz)

Was ist die schlimmste produktbezogene Konsequenz, die eintreten kann?

· Mögliche Antwort: "Jemand stiehlt die Geheimformel unseres Produkts oder Informationen über den Prozess." (Vertraulichkeitskonsequenz)

Arbeiten Sie rückwärts von dort.

· Zone 1: Kesselsicherheit. Gruppieren Sie alle Vermögenswerte, die diese Kesselexplosion verursachen oder verhindern könnten - die Sicherheits-PLC, ihr HMI, die für deren Programmierung verwendete Engineering-Workstation und das Sensornetzwerk. Dies ist Ihre "Kesselsicherheitszone."

· Zone 2: Produktion von Batch 1. Gruppieren Sie alle PLCs, Roboter und HMIs, die diese spezifische Linie betreiben. Dies ist Ihre "Batch 1 Zone."

Es spielt keine Rolle, ob sie sich im selben VLAN oder sogar am selben physischen Switch befinden. Sie sind jetzt nach einer gemeinsamen Konsequenz gruppiert, nach der sie etikettiert sind. Sie können jetzt eine detaillierte Risikobewertung bezüglich dieser speziellen Konsequenz durchführen.

Das Risiko, dass die "Kesselsicherheitszone" ausfällt, ist katastrophal. Ihre Risikobewertung wird mit ziemlicher Sicherheit ein hohes Ziel-Sicherheitslevel wie SL-3 verlangen. Die "Batch 1 Zone" könnte ein kostspieliger betrieblicher Ausfall sein, aber nicht katastrophal, sodass ihre Risikobewertung möglicherweise auf SL-2 landet.

Sie haben gerade Risiko verwendet, um eine praktische, vertretbare und segmentierte Sicherheitsarchitektur zu schaffen.

Ein umsetzbarer 5-Schritte-Plan für eine IEC 62443-3-2-basierte Risikobewertung

Halten Sie bis hierher Schritt?

Bereit, eine solche Bewertung für Ihre Infrastruktur wirklich durchzuführen? Hier ist ein umsetzbarer, schrittweiser Prozess.

Schritt 1: Versammeln Sie Ihre "Avengers"

Sie können dies nicht nur mit IT tun. Sie benötigen ein Kernteam aus:

•    OT/Engineering: Die Leute, die den Prozess gebaut und gewartet haben. Sie kennen die physikalischen Konsequenzen.

•    IT/Cybersicherheit: Die Leute, die Bedrohungen, Schwachstellen und Netzwerkinfrastruktur verstehen.

•    Sicherheit: Die Leute, die bereits die physikalischen Risikoabschätzungen (z.B. HAZOP) durchgeführt haben und die realen Gefahren verstehen.

Schritt 2: Hochstufige RA (Konsequenzen definieren)

Bringen Sie dieses Team in einen Raum. Vergessen Sie Technik für eine Stunde. Brainstormen und dokumentieren Sie die schlimmsten physischen, betrieblichen und geschäftlichen Konsequenzen für Ihre Anlage. Dies ist Ihr "Impact"-Kriterium. Das ist das "Was" das Sie schützen.

Schritt 3: Untergliederung (Zeichnen Sie Ihre tatsächlichen Zonen)

Nun ziehen Sie die Prozessschemata (P&IDs) und Netzwerkschema heraus. Basierend auf den Konsequenzen aus Schritt 2 beginnen Sie, Vermögenswerte zu gruppieren.

•    "All diese Geräte sind Teil des 'Abwasserbehandlungs'-Prozesses. Wenn sie ausfallen, haben wir einen Umweltschaden." -> Dies ist eine Zone.

•    "Diese beiden PLCs kommunizieren über dieses spezifische Kabel, um die 'Batch 1'-Linie zu steuern." -> Dies ist eine Leitung.

Sie bauen ein Modell Ihrer Anlage basierend auf Konsequenz und Kommunikation.

Schritt 4: Detaillierte RA (Bestimmen Sie Ihre Ziel-SLs)

Für jede Zone und jede Leitung, die Sie gerade definiert haben, führen Sie nun die „klassische“ Risikobewertung durch.

◦       Bedrohungen identifizieren: Wer könnte dies angreifen? (z.B. Insider, Hacktivist)

◦       Schwachstellen identifizieren: Was sind die Schwächen? (z.B. Ungepatcht, Standardpasswörter)

◦       Wahrscheinlichkeit bestimmen: Wie wahrscheinlich ist dieser Angriff?

◦       Konsequenz bestimmen: Das haben Sie bereits getan! (z.B. Kesselexplosion)

Jetzt tragen Sie dies in eine Risikomatrix ein. Die Risikotoleranz Ihres Unternehmens wird Ihnen sagen, was akzeptabel ist. Wenn das Risiko unakzeptabel hoch ist, müssen Sie es reduzieren. Wie? Indem Sie ein Ziel-Sicherheitslevel (SL-T) zuordnen. Sie sagen formell, "Um das Risiko einer Kesselexplosion auf ein akzeptables Niveau zu reduzieren, muss diese Zone auf SL-3 entwickelt werden."

Schritt 5: Die Lückenanalyse (AKA Projektplan)

Okay, wir haben den letzten Schritt erreicht. Für jede Zone haben Sie ein Ziel (SL-T). Jetzt messen Sie, was Sie derzeit haben (Ihr erreichtes Sicherheitslevel oder SL-A).

•    Zone: RTUs

•    Ziel (SL-T): SL-3

•    Erreicht (SL-A): SL-1

Die wahrgenommene Lücke zwischen SL-T 3 und SL-A 1 ist nichts anderes als Ihr Projektplan. Sie gehen zu IEC 62443-3-3, ziehen alle Anforderungen für SL-3 und Sie haben jetzt einen priorisierten, risikobasierten und ingenieurtechnisch getriebenen Fahrplan, um Ihre Anlage zu sichern.

Wenn Sie all das tun können, dann sind Sie nicht länger nur "bewertend". Sie betreiben tatsächlich Sicherheitsengineering.

Lassen Sie uns mehr diskutieren.

Erfahren Sie mehr über unsere OT NDR-Lösung.