Cybersicherheit der Energienetze nach IEC 62443

Den meisten Sicherheitsverantwortlichen für industrielle Systeme ist die Normenfamilie der IEC 62443 eine alte Bekannte. Seit über zehn Jahren gilt sie wortwörtlich als DER Standard für industrielle Cybersicherheit. Der Standard gilt als sogenannter “horizontaler Standard”. Er bildet somit sektorübergreifend die Basis für industrielle Cybersicherheit, auf der durch Branchenexperten sektorspezifische Anforderungen hinzugefügt werden (können).

[Hinweis: Der Standard IEC 62443 spricht in Bezug auf die industrielle IT bzw. die Netzleit-, Fernwirk- und Steuerungstechnik von IACS (Industrial Automation and Control Systems). Der Einfachheit halber verwenden wir in diesem Beitrag den international gängigen Begriff der Operational Technology oder OT]

Den Fokus richtig setzen

Für Energieversorgungsunternehmen haben vor allem die Kapitel 3-1 bis 3-3 Gewicht, die sich mit der Systemsicherheit ihrer Kritischen Infrastruktur befassen:

• 3-1: Security technologies for industrial automation and control systems (IACS) (Sicherheitstechnologien für industrielle Automatisierungs- und Steuerungssysteme)
• 3-2: Security risk assessment and system design (Sicherheitsrisiko-Bewertung und Systemdesign)
• 3-3: System security requirements and security levels (Anforderungen an die Systemsicherheit und Sicherheitslevel)

Kapitel 3-1 ist mit dem Bearbeitungsstand 2009 zwar mittlerweile in die Jahre gekommen. Kapitel 3-2 und 3-3 bleiben mit ihrer Veröffentlichung in den Jahren 2020 und 2013 jedoch weiterhin aktuell. Beide Kapitel konzentrieren sich eher auf konzeptionelle Anforderungen, die – bis auf einige Detailformulierungen im Kleingedruckten – technologieneutral bleiben.

Die beiden Kapitel bilden damit die Basis einer durchgängigen OT-Sicherheitsstrategie, an denen sich Energieversorgungsunternehmen orientieren sollten, um ihre OT-Netze wirkungsvoll und zuverlässig gegen Cyberangriffe und Störungen schützen zu können.

Abb. 1: Nach der Erstumsetzung des Standards entwickeln sich sowohl die OT als auch die Bedrohungslandschaft weiter und sorgen für ein veraltetes Sicherheitsniveau, das kontinuierlich überprüft und aktualisiert werden muss.

Der entscheidende Faktor bei Anwendung der IEC 62443 ist, die Umsetzung nicht als Einmalprojekt, sondern als kontinuierlichen Prozess zu begreifen. Cybersicherheit war schon immer Sprint und Marathon zugleich. Die einmalige Umsetzung des IEC 62443 Standards ist nicht das Endziel für OT-Sicherheit. Sie ist der Beginn einer kontinuierlichen Neubewertung und Verbesserung der Risikolage und Systemeffizienz (Abb. 1). Insofern folgt OT-Sicherheit im Sinne von IEC 62443 einem klassischen PDCA-Zyklus (Plan, Do, Check, Act), der auch aus den Normen ISO 9001 oder ISO 27001 ff bekannt ist.

IEC62443-3-2 Risikoanalyse: Sichtbarkeit und Wissen schaffen

Es ergibt wenig Sinn zu versuchen, die in Kapitel IEC 62443-3-3 definierten technischen Anforderungen zu implementieren, ohne zuvor eine vollständige Sicherheitsrisikobewertung nach Kapitel IEC 62443-3-2 “Security risk assessment for system design” durchgeführt zu haben. Andernfalls entsteht ein riskanter Flickenteppich ohne klare Fokussierung und Berücksichtigung der wirklich vorhandenen Sicherheitsrisiken.

Das ultimative Ziel der Sicherheitsrisikobewertung besteht darin, ein vollständiges Verständnis der OT-Struktur und potenziellen Risiken zu erlangen. In unseren Rhebo Industrial Security Assessments, die wir standardmäßig vor der Integration unseres Angriffserkennungssystems für OT bei unseren Kunden durchführen, sind viele Sicherheitsverantwortliche überrascht, welche Schwachstellen und Kommunikationsvorgänge sich in ihrer OT finden. In der Regel ist es das erste Mal, dass sie die Blackbox ihrer OT öffnen und einen Überblick über das Innenleben erlangen.

Ein OT-Monitoring unterstützt bereits in diesem ersten Schritt maßgeblich, um alle wichtigen Informationen für die Risikobewertung und anschließende Entscheidungsfindung einzuholen:

• Netzwerkkarte mit allen Assets (Hardware und Software) (Abb. 2),
• Informationen und Eigenschaften der Assets (Abb. 2),
• Bestehende Schwachstellen (z. B. durch veraltete Firmware, OS),
• Bestehende Sicherheitsrisiken (z. B. durch Verbindungen zu und vom Internet, ungewollte Verbindungen von Assets, Klartext-Passwörtern, veralteten oder obsoleten Protokollen),
• Auffälligkeiten in der Kommunikation,
• Struktur der Kommunikationspfade,
• Fehlkonfigurationen.

Abb. 2: Netzwerkkarte mit Detailinformationen und Verbindungsübersicht in Rhebo Industrial Protector

IEC62443-3-3 Sicherheitssystem: Grundschutz sicherstellen und kontinuierlich prüfen

Mit dem Wissen aus der Risikobewertung kann das Sicherheitssystem für die OT gezielt und fokussiert aufgebaut werden. Das Kapitel IEC62443-3-3 gibt dafür eine Vielzahl Empfehlungen, die in 7 Grundanforderungen (FR) mit insgesamt 51 Standardanforderungen (SR) gruppiert sind.

Zwar empfiehlt es sich, alle SR zu berücksichtigen. Jedoch lehrt die Praxis, dass SR aufgrund betrieblicher Anforderungen (z. B. an Echtzeitprozesse oder Arbeitsschutzmechanismen) oder infrastruktureller Gegebenheiten (z. B. Legacy-Systeme und bestimmte Abhängigkeiten) manchmal nicht oder nur unvollständig umgesetzt werden können. Hinzu kommt, dass die wenigsten OT-Komponenten mit Cybersicherheit im Hinterkopf entwickelt wurden. Sie sind in der Regel “insecure by design”. Aufgrund der Lebenszyklen industrieller Infrastrukturen von 15-25 Jahren wird sich das auf absehbare Zeit nicht ändern. Und in diesem Zeitraum wachsen und ändern sich die Angriffstechniken und Cybergefahren um ein vielfaches.

Kurz: Es bleiben - oft nicht zu vernachlässigende - Restrisiken bestehen (Abb. 3).

In Anerkennung der Tatsache, dass es keine 100-prozentige Sicherheit in der Cybersicherheit gibt, plädieren u.a. das National Institute of Standards and Technology (NIST) und das deutsche Bundesamt für Sicherheit in der Informationstechnik (BSI) seit langem für Defense-in-Depth. Dieser Ansatz »umfasst die Kombination mehrerer heterogener Sicherheitstechnologien für die gängigen Angriffsvektoren, um sicherzustellen, dass Angriffe, die von einer Technologie übersehen werden, von einer anderen erkannt werden«^[1].

Abb. 3: Es gibt keine 100-prozentige Sicherheit in der OT, weshalb Sicherheitsbeauftragte stets über sicherheitsrelevante Vorgänge im OT-Netz informiert sein sollten, wie hier mit der Inbox des Rhebo Industrial Protector.

OT-Monitoring mit Anomalieerkennung bildet genau dieses zweite Level der Gefahrenabwehr. Es unterstützt maßgeblich die Umsetzung, Verbesserung und Wirksamkeit der Grundanforderungen. Abb. 4 aus dem Whitepaper “IEC 62443 Anforderungen im Licht heutiger OT-Risiken Erkenntnisse aus OT-Monitoring-Projekten” analysiert das exemplarisch für die SR 1 bis 3.

Abb. 4: OT-Monitoring und Anomalieerkennung unterstützen maßgeblich beim Sicherstellen von OT-Sichtbarkeit und der Wirksamkeit der implementierten Abwehrmaßnahmen.

IEC 62443 auf dem Weg zur gesetzlichen Pflicht

Einige Zeichen weisen aktuell in die Richtung, dass der Standard in der EU in Zukunft eine noch größere, rechtlich relevante Rolle spielen wird, wie die Cybersicherheitsexpertin Sarah Fluchs jüngst aus dem Nähkästchen plauderte. Im Rahmen der Standardharmonisierung für den kommenden Cyber Resilience Act (CRA) wurde demnach auch das CLC/TC 65X Technical Committee beauftragt, Vorschläge zu erarbeiten, welche Standards als zur Umsetzung der Gesetzgebung maßgeblich sein sollen. Wie Fluchs schreibt, ist das TC 65X der Link des IEC-Komitees TC 65 zur europäischen Standardisierungsinstitution CENELEC. “Und TC 65 ist verantwortlich für eine Reihe internationaler Standards, von denen Sie wahrscheinlich schon gehört haben: ISA/IEC 62443”.^[2]

Der CRA zielt vor allem auf alle herstellenden Unternehmen, die Komponenten mit digitalen Schnittstellen oder Anwendungen im europäischen Markt verkaufen wollen, also das CE-Kennzeichen für den Vertrieb benötigen. Daher wird der Fokus auf den Kapiteln 4-1 “Secure product development lifecycle requirements” und 4-2 “Technical security requirements for IACS components” liegen, die explizit Cybersicherheitsvorgaben für IACS-Komponenten definieren.

Die NIS2 hat bereits einige grundlegende Aspekte aus der IEC 62443 übernommen. Mit der Anwendung im Rahmen des CRA wird der Standard somit gesamtwirtschaftlich für jedes Unternehmen zur Pflicht, das industriell eingesetzte Hardware oder Software mit Sicherheits- oder zentraler Systemfunktion vertreibt. Das wird auch für die Unternehmen Auswirkungen haben, die solche Produkte in ihren Netzen einsetzen, wie wir in Teil 1 unseres NIS 2 Blogs beleuchtet haben.

Download Whitepaper IEC 62443

^[1] z. B. NIST SP 800-171, NIST SP 800-172, NISTIR 8183

^[2] https://fluchsfriction.medium.com/what-cybersecurity-standards-will-products-in-the-eu-soon-have-to-meet-590854ba3c8c

‍