HINWEIS: Dieser Artikel richtet sich nicht nur an Unternehmen, die bereits gehackt wurden... Die IEC 62443 ist ein generischer Standard, der in kritischen Sektoren wie der Fertigung, dem Energiesektor, dem Transportwesen, dem Gesundheitswesen und vielen anderen als anwendbar gilt.
Dieser Artikel ist die fünfte Folge einer achtteiligen Serie, die einige der besten Praktiken behandelt, die von jeder Organisation implementiert werden sollten, die den Stand der Technik bei der Cybersicherheit für Industrie- und Automatisierungssteuerungssysteme erreichen will. In diesem Zusammenhang wird Security Hardening als ein Schlüsselthema betrachtet, um letztendlich zu beweisen, dass eine Defense-in-Depth-Strategie von Integratoren verfolgt und umgesetzt wird. Die Aktivitäten, die zu diesem Thema gehören, werden hauptsächlich von den achten Praktiken der ISA/IEC6244-4-1 adressiert, die den Sicherheitsrichtlinien gewidmet sind, sowie von dem Teil ISA/IEC62443-2-4, der die Anforderungen an Integrations- und Wartungsdienstleister beschreibt.
Aus Sicht der ISA/IEC62443 umfassen die Praktiken zur Sicherheitshärtung alle Aktivitäten, die mit der Härtung eines Produkts in den Phasen nach der Entwicklung zusammenhängen (z. B. Installation, Wartung...). Ausnahmen bilden der sichere Betrieb und die sichere Entsorgung, die durch spezifische Praktiken beschrieben werden, nämlich SG-5 (ISA/IEC62443-4-1, Abschnitt 12.6) und SG-4 (ISA/IEC62443-4-1, Abschnitt 12.5). Ein konformer Secure Development Lifecycle einer Organisation sollte daher solche Aspekte durch die Erstellung einer entsprechenden Dokumentation für Produktanwender / Integratoren über den Weg zur sicheren Integration, Nutzung und Handhabung eines Produkts integrieren.
Diese Anforderung erkennt an, dass die Sicherheitsrichtlinien und -anforderungen für Kundenstandorte oft unterschiedlich sind. Daher sind Anweisungen für die sichere Integration des Produkts in den Kundenstandort, die entsprechende Konfiguration und die Aufrechterhaltung der Sicherheit erforderlich. Formal beschreibt eine spezifische Anforderung diese Aktivitäten wie folgt:
Wie bereits in den vorangegangenen Episoden dieser Blogserie erwähnt, ist eine Defense-in-Depth-Strategie der Schlüssel zum Umgang mit Cyber-Sicherheit und zur Reduzierung von Cyber-Risiken. Es gibt keine kugelsicheren Lösungen, daher gilt die Multiplikation von Abwehrtechniken und Barrieren als der beste Ansatz zur Minimierung von Cyber-Bedrohungen entlang der gesamten Lieferkette, von der sicheren Entwicklung einzelner Komponenten bis hin zum sicheren Betrieb kompletter und komplexer Lösungen und Systeme. In diesem Zusammenhang stellen Richtlinien zur Sicherheitshärtung eine der wichtigsten Dokumentationen dar, die von Komponenten-/Systemlieferanten bereitgestellt werden müssen, um eine sichere Integration und Wartung von Produkten zu gewährleisten.
Security Hardening als gemeinsames Thema für OT und IT
In der Tat ist die Sicherheitshärtung ein bekanntes Thema für IT-Systeme, wird aber als noch wichtiger für OT-Ziele angesehen, wo die potenziellen Folgen von Cyberangriffen in der Regel kritischer sind. Die Implementierung von Härtungstechniken kann sich von IT zu OT unterscheiden, aber die Ansätze sind ähnlich und das letztendliche Ziel ist dasselbe: Die Sicherheitsfähigkeiten eines Ziels in einer gegebenen Umgebung auf die effizienteste Weise auszunutzen, um die verbleibende Angriffsfläche zu reduzieren und eine einigermaßen sichere Haltung zu erreichen.
Sicherheitshärtungstechniken sollten für jede Komponente/Subsystem eines kompletten "Systems" oder einer Lösung in Betracht gezogen werden. Basierend auf diesen Überlegungen aus mehreren Quellen liegt es in der Verantwortung der Integratoren und/oder Anwender, die von den Produktanbietern beschriebenen Best Practices in der spezifischen Umgebung zu befolgen. Dieses Prinzip ist der Grund, warum SG-3 von ISA/IEC62443 von den Produktanbietern verlangt, eine Dokumentation bereitzustellen, die Richtlinien für diesen Zweck enthält.
Typischerweise spezifizieren diese Richtlinien die Prozesse, die von Integratoren und/oder Anwendern bei der Integration eines bestimmten Targets in eine Umgebung zu befolgen sind, indem sie mehrere kritische Aspekte berücksichtigen, wie z. B.:
- Schnittstellen zu anderen Subsystemen oder Komponenten
- Produkt-Konfigurationen
- Verwendung von sicherheitsrelevanten Tools zur Interaktion mit dem Produkt
- Aktivitäten zur Sicherheitswartung (z. B. Handhabung von Updates/Patches)
- Benachrichtigungen über Vorfälle
Lassen Sie uns ein Beispiel verwenden...
Wenn wir an die Herstellung einer industriellen Steuerung denken, die als SPS (Speicherprogrammierbare Steuerung) betrachtet wird, was bedeutet dann die Richtlinie zur Sicherheitshärtung im Zusammenhang mit diesem Produkt?
Was die Komponente selbst betrifft, so würde sie unter der Terminologie ISA/IEC62443-4-2 als eingebettetes Gerät betrachtet werden. Eine SPS ist ein Gerät, das typischerweise auf den unteren Ebenen des Automatisierungssystems angesiedelt ist (z. B. Ebene 1 und 2 der Purdue Enterprise Reference Architecture, wie in ANSI/ISA-95.00 beschrieben, siehe Abbildung unten). SPSen verwenden in der Regel robuste Hardware, um den Betrieb in industriellen Umgebungen zu ermöglichen, und basieren in der Regel auf kommerziellen Echtzeitbetriebssystemen (RTOS). Zunehmend erhalten auch intelligente Sensoren und Aktoren eine Form der Prozesssteuerungsfähigkeit. SPSen und intelligente Sensoren/Aktoren werden so programmiert, dass sie eine Steuerlogik auf der Grundlage von Eingaben aus dem Prozess ausführen (die von Instrumenten wie herkömmlichen Temperatursensoren, Drucksensoren und Vibrationssensoren stammen). Der Ausgang der Steuerlogik wird zur Steuerung des industriellen Prozesses (durch Aktoren wie Ventile, Pumpen) verwendet. Die Programmierung erfolgt in der Regel mit einer Engineering-Software, die üblicherweise auf Host-Geräten (z. B. Laptops oder PC-Workstations) läuft.
Im Folgenden finden Sie einige Beispiele für Themen, die von den SPS-Herstellern zur Verfügung gestellt werden müssen, damit Produktintegratoren und/oder Anwender das Produkt in einer bestimmten Umgebung härten können, basierend auf den zuvor genannten Top-Level-Aspekten:
- Schnittstellen zu anderen Subsystemen oder Komponenten
- Wie kann das Produkt sicher in ein Gesamtsystem integriert werden, unter Verwendung relevanter API's und Protokolle?
- Was sind die Anforderungen/Annahmen des Produktlieferanten in Bezug auf andere abhängige Subsysteme (z. B. Authentifizierungsserver, die für die Handhabung von AAA-Funktionen auf Produkten eingesetzt und referenziert werden müssen)?
- Produkt-Konfigurationen
- Welche Funktionen unterstützen die Asset-Identifikation und Inventarisierung auf Systemebene?
- Was sind die Annahmen zu physikalischen Schutzmaßnahmen?
- Was sind die allgemeinen Beiträge zur Defense-in-Depth-Strategie des Produkts?
- Verwendung von sicherheitsrelevanten Tools zur Interaktion mit dem Produkt
- Wie lauten die Instruktionsempfehlungen der Lieferanten des Produkts hinsichtlich der Verwendung von Werkzeugen für die Verwaltung, Überwachung und andere zusammenhängende Tätigkeiten?
- Aktivitäten zur Sicherheitswartung (z. B. Handhabung von Updates/Patches)
- Welche Prozesse müssen von Endanwendern/Integratoren befolgt werden, um über Updates/Patches informiert zu werden?
- Wie kann man ein Update/Patch sicher bereitstellen?
- Wie kann man im Falle eines Deployment-Fehlers sichere Rollback-Funktionen ausführen?
- Benachrichtigungen über Vorfälle
- Kommunikationskanal mit Zulieferern (z. B. Kontaktstellen, Werkzeuge, Vorlagen), könnte als außerhalb des Anwendungsbereichs der Härtungstechnik betrachtet werden, aber von anderen ISA/IEC62443-4-1-Anforderungen angesprochen werden?
- Prozess für Benachrichtigungen über Vorfälle / sicherheitsrelevante Probleme und Berichterstattung?
Diese Aufzählung ist nicht abschließend, soll Ihnen aber helfen, über die Bedeutung einer solchen Dokumentation im Hinblick auf das Cybersicherheitsmanagement eines Produkts über dessen gesamte Lebensdauer nachzudenken.
Wie sieht es mit Zertifizierungen aus?
Es ist wichtig, sich der Tatsache bewusst zu sein, dass, wenn ein sicheres Produkt in eine Lösung ohne eine spezifische Richtlinie zur Sicherheitshärtung integriert wird, die Sicherheitsfähigkeiten des Produkts nicht richtig ausgenutzt werden und daher zu Schwachstellen auf Systemebene führen können. Diese Überlegung ist der Hauptgrund, warum die Produktzertifizierung nach ISA/IEC62443-4-2 auch einige Nachweise über den Aufbau des SDLC und damit die Basis für die Einhaltung der ISA/IEC62443-4-1 verlangt. Eine vollständige SDLC-Zertifizierung nach IEC 62443-4-1 ist vor einer Produktzertifizierung nach IEC 62443-4-2 nicht erforderlich, jedoch soll eine Teilmenge der SDLC-Praktiken im Rahmen der Produktzertifizierung ohnehin auditiert werden.
Sie wird in der IEC 62443-4-2 durch die sogenannten Common Cyber Security Constraints (IEC 62443-4-2, Abschnitt 4.5, CCSC-4) kristallisiert, die fordern, dass "alle sicheren Komponenten gemäß den in der IEC 62443-4-1 beschriebenen sicheren Produktentwicklungsprozessen entwickelt und unterstützt werden müssen".
Der beste Ansatz, der von Organisationen auf dem Weg zur IEC62443-Zertifizierung verfolgt werden könnte, wäre derzeit der folgende:
- Bewerten Sie Ihre aktuelle Situation anhand von standardisierten Anforderungen durch eine Lückenanalyse
- SDLC-Zertifizierung nach IEC 62443-4-1 zur Erlangung einer organisatorischen Anerkennung gegenüber dem State-of-the-Art für sichere Entwicklung
- Produktzertifizierungen nach IEC 62443-4-2, um letztendlich Produkte anbieten zu können, die dem Stand der Technik für technische Sicherheitsfähigkeiten entsprechen.
Dieser Ansatz würde es Ihnen ermöglichen, die Kosten für Produktzertifizierungen zu reduzieren, indem Sie zunächst Ihre Entwicklungsprozesse zertifizieren und eine Anerkennung auf Organisationsebene erhalten und dann bereits mit den ersten Produktanforderungen konform gehen
Fazit
Auch wenn die Einhaltung der 62443 nicht das ultimative Ziel ist, sollten Praktiken im Zusammenhang mit der Sicherheitshärtung als eine der wichtigsten Aktivitäten und Dokumentationen betrachtet werden, die Produktanwendern und Integratoren zur Verfügung gestellt werden müssen, um vollständige Cybersicherheitskreisläufe auf allen Ebenen des InVeKoS-Ökosystems (inkl. Asset-Eigentümern, Dienstleistern, Systemlieferanten, Komponentenlieferanten) zu gewährleisten.
Wenn Sie Fragen zu Security Hardening Praktiken, Dokumentationen und/oder anderen Zertifizierungskriterien haben, zögern Sie bitte nicht, unseren Cyber Security Spezialisten zu kontaktieren: Kilian Marty