BEWÄLTIGUNG VON RISIKEN IN DER SOFTWARE-LIEFERKETTE MIT IEC 62443 UND SBOM
Die Zeit drängt: 68% der Unternehmen sind mit dem neuen Cyber Resilience Act noch nicht vertraut
Dieses Whitepaper richtet sich an Sicherheitsteams von Anlagenbesitzern und Produktlieferanten industrieller Automatisierungs- und Steuerungssysteme (IACS).
.avif)
ZUSAMMENFASSUNG
Komponenten, die in einer IACS-Umgebung verwendet werden, müssen erhöhte Sicherheitsanforderungen erfüllen und gleichzeitig wichtige Funktionen und Dienste beibehalten. Die Normenreihe IEC 62443 bietet mit Teil 4-1 einen umfassenden Rahmen für Produktlieferanten, um einen sicheren Produktentwicklungszyklus aufzubauen. Der in diesem Framework enthaltene Defense-in-Depth-Ansatz kann zwar die Auswirkungen von Sicherheitslücken abschwächen, einige Sicherheitslücken müssen jedoch während des gesamten Produktlebenszyklus behoben werden.
SBOMs tragen dazu bei, die Sichtbarkeit der gesamten Lieferkette zu erhöhen und die Sicherheitslage der IACS-Lieferanten und -Betreiber zu stärken, indem sie eine risikobasierte Patch-Strategie ermöglichen, wenn neue Sicherheitslücken auftauchen. In dem Whitepaper wird erörtert, wie die IEC 62443-4-x zur Minderung dieser Risiken vorschlägt und wie der Softwareentwicklungsprozess ausgereift werden muss, um diese Schutzmaßnahmen zu berücksichtigen. Schließlich ist zur Reduzierung der Markteinführungszeit, der Kosten und der Ressourcen aufgrund des manuellen Aufwands ein hohes Maß an Automatisierung bei der Generierung von SBOMs und der Durchführung von Sicherheitsanalysen zur Bewältigung sicherheitsrelevanter Probleme gemäß IEC 62443-4-1 erforderlich.
ANGRIFFE AUF IACS NEHMEN ZU
Cyberangriffe auf industrielle Automatisierungs- und Steuerungssysteme (IACS) nehmen zu.1 In der Vergangenheit waren IT- und IoT-Systeme überwiegend das Ziel von Cyberkriminellen. Dieselben Bedrohungen, wie Ransomware-Angriffe und die Zusammenführung von Geräten zu riesigen Botnetzen, betreffen jedoch zunehmend auch IACS und OT. Der Grund dafür ist einfach: Bevor IACS intelligent und vernetzt wurden, wurden sie meist in Air-Gap-Umgebungen betrieben, waren nicht mit dem Internet verbunden und meistens nicht einmal mit lokalen Unternehmensnetzwerken verbunden.
DIE VERNETZUNG DER IACS NIMMT ZU, EBENSO WIE IHRE CYBER-RESILIENZ
Um IACS-Komponenten zu steuern oder Änderungen an ihrer Konfiguration vorzunehmen, müsste ein Techniker physisch mit der Maschine interagieren. Mit der zunehmenden Digitalisierung ändert sich dies rasant. IACS-Umgebungen sind mit internen Netzwerken und dem Internet verbunden, um Daten in andere Geschäftsprozesse einzuspeisen und die Konfiguration und Verwaltung aus der Ferne zu ermöglichen.
Während eine verbesserte Konnektivität im Allgemeinen die Produktivität erhöht und die Verwaltung von IACS-Umgebungen erleichtert, gehen diese Fortschritte mit einem erhöhten Cyberrisiko einher: Die Bedrohungslandschaft verändert sich. Es ist nicht mehr möglich, sich ausschließlich auf die Sicherheitskontrollen der Umgebung und des Perimeters zu verlassen.
Daher müssen dieselben Sicherheitsprinzipien, die für IT-Systeme gelten, an die industrielle Welt angepasst werden. Tiefgreifende Verteidigung, Sicherheit durch Design und Zero-Trust müssen angewendet werden, um die Widerstandsfähigkeit der IACS gegenüber Cyberangriffen zu erhöhen und gleichzeitig wichtige Funktionen und Dienste aufrechtzuerhalten. Während sich herkömmliche IT-Sicherheit hauptsächlich mit der Vertraulichkeit von Daten befasst, muss eine IACS-Sicherheitslösung die Integrität und Verfügbarkeit der physischen Ressourcen schützen, die für den kontrollierten Prozess unerlässlich sind.
Produktsicherheits-lebenszyklus für industrielle Automatisierungs- und Steuerungssysteme
IEC 62443 BIETET ANLEITUNGEN ZUR ERSTELLUNG VON CYBERRESISTENTEN IACS
Diese erhöhte Risikosituation führt zu erhöhten Sicherheitsanforderungen für Anlagenbesitzer und Betreiber von IACS. Um den gestiegenen Sicherheitsanforderungen im Zusammenhang mit IACS gerecht zu werden, arbeitete die International Electrotechnical Commission (IEC) seit 2009 an einer Reihe von Standards, die sich mit der Cybersicherheit der Betriebstechnologie in Automatisierungs- und Steuerungssystemen befassen: der IEC 62443. Wie in Abbildung 1 dargestellt (Geltungsbereich der IEC 62443). IEC 62443 besteht aus 13 Teilen und richtet sich an alle Rollen komplexer Industrieumgebungen: Anlagenbesitzer, Systemintegrator und Produktlieferant (die Anbieter von IACS-Komponenten, die seien eingebettete Geräte, Netzwerkkomponenten und Host-Geräte). Im Mittelpunkt aller Teile steht die Unterstützung tiefgreifender Verteidigungsstrategien sowie der Prinzipien von Security by Design für industrielle Umgebungen. Durch die Einhaltung umfassender Schutzmaßnahmen ist das Vertrauen in die Netzwerk- und Perimetersicherheit unzureichend. Die Geräte selbst müssen Cyberangriffen standhalten.
Die Teile IEC 62443-4-1 und IEC 62443-4-2 befassen sich mit Sicherheitsanforderungen für Geräte. Während sich IEC 62443-4-2 auf die Produktsicherheit selbst konzentriert, definiert IEC 62443-4-1 Anforderungen an die Lebenszyklusprozesse der Produktentwicklung. Dies stellt sicher, dass ein sicheres Produkt nicht das Ergebnis glücklicher Umstände ist, sondern wiederholbar, transparent und messbar ist, wenn angemessene Sicherheitskontrollen vorhanden sind.
DIE MINDERUNG VON LIEFERKETTENRISIKEN IST EINE KERNANFORDERUNG VON IEC 62443
Abbildung 2 zeigt die 8 Praktiken für Produktentwicklungsprozesse, die in IEC 62443-4-1 definiert sind.
Die Praktiken stellen Anforderungen an alle Phasen des Produktentwicklungszyklus, um während der Entwicklung eine umfassende und sichere Abwehr zu unterstützen und sicherzustellen, aber auch, dass alle Prozesse zur Bewältigung sicherheitsrelevanter Probleme während des gesamten Produktlebenszyklus eingerichtet sind. Eine zentrale Anforderung von IEC 62443-4-1 ist das Risikomanagement in der Lieferkette.
SICHERHEITSKONTROLLEN MÜSSEN AUCH DIE LIEFERKETTE ABDECKEN
In modernen Anwendungen bestehen 80%-90% der Codebasis aus Softwarekomponenten von Drittanbietern — sowohl Open Source als auch proprietär. Diese reichen von Kryptobibliotheken, die zum Schutz vertraulicher Informationen verwendet werden, bis hin zu Closed-Source-SDKs zur Steuerung von Hardwaremodulen von Drittanbietern, die im IACS enthalten sind. Da ein Großteil der Codebasis nicht unter der direkten Kontrolle des Anbieters steht, wird ein erheblicher Teil des Risikos und der Gefährdung eines IACS von Softwarekomponenten von Drittanbietern übernommen.
RISIKEN DURCH DRITTE BLEIBEN VERBORGEN
Zu den Risiken gehörten: Mangelnde Transparenz: Direkte Abhängigkeiten und Einschlüsse von Komponenten von Drittanbietern sind zwar oft bekannt, aber die Lieferkette endet selten dort. Komponenten von Drittanbietern sind in der Regel auf weitere Abhängigkeiten angewiesen, die wiederum wiederum Abhängigkeiten aufweisen. Die gesamte Lieferkette transparent zu machen, ist noch schwieriger, wenn der Quellcode der betroffenen Komponenten nicht verfügbar ist.
SOFTWARE VON DRITTANBIETERN KANN DAS THREAD-LEVEL ERHÖHEN
Erhöhen Sie die Thread-Ebene: Die Entwicklungspraktiken sowie die Sicherheitsmaßnahmen von Anbietern von Open-Source-Komponenten von Drittanbietern und kommerziellen Standard-Softwarekomponenten (COTS) werden selten überprüft. Dies führt zu Szenarien, in denen ein erheblicher Teil des Endprodukts nicht den Sicherheitsanforderungen der Anbieter entspricht, was das Sicherheitsniveau der gesamten IACS-Umgebung beeinträchtigt.
ANGREIFER KONZENTRIEREN SICH ZUNEHMEND AUF DIE LIEFERKETTE
Angriffe auf die Lieferkette: Lieferketten sind als lukrativer Einstiegspunkt in die Infrastruktur ihrer Ziele in den Fokus von Cyberkriminellen gerückt. Bedrohungsakteure haben begonnen, aktiv Hintertüren in Open-Source-Komponenten einzubauen und Schadsoftware über Open-Source-Repositorys zu verbreiten. Die Schwere der Risiken in der Lieferkette rechtfertigt strenge Maßnahmen zur Eindämmung. Die IEC 62443-4-1 erkennt diese Herausforderungen an und behandelt Lieferkettenrisiken in drei der acht Praktiken aus verschiedenen Blickwinkeln.
SICHERHEITSANFORDERUNGEN DEFINIEREN UND SICHERHEITSPROBLEME BEHEBEN
Praxis 1 — Das Sicherheitsmanagement (SM) enthält Sicherheitsanforderungen für extern bereitgestellte Komponenten (SM-9) und zur Bewertung und Behebung sicherheitsrelevanter Probleme (SM-11). Es muss ein Prozess eingerichtet werden, um Drittanbieter zu identifizieren und die damit verbundenen Risiken von Komponenten von Drittanbietern zu bewerten. Dabei muss deren Rolle bei der Sicherheitsgestaltung und der umfassenden Verteidigungsstrategie des Produkts berücksichtigt werden. Darüber hinaus muss sichergestellt werden, dass alle sicherheitsrelevanten Probleme — einschließlich solcher Probleme, die durch Abhängigkeiten von Drittanbietern verursacht werden — vor der Veröffentlichung behoben werden.
SOFTWARE VON DRITTANBIETERN AUF SICHERHEITSLÜCKEN TESTEN
Praxis 5 — Sicherheitsverifizierungs- und Validierungstests (SVV) beinhalten Anforderungen für Schwachstellentests (SVV-3). Schwachstellentests sind für das gesamte Produkt erforderlich, einschließlich aller Abhängigkeiten von Drittanbietern. Daher muss im Rahmen dieser Anforderung auch Code von Drittanbietern auf bekannte Sicherheitslücken und Konfigurationsprobleme getestet werden.
UMGANG MIT NEU AUFTRETENDEN BEDROHUNGEN
Praxis 6 — Das Management sicherheitsrelevanter Probleme (DM) definiert die Anforderungen für den Empfang von Benachrichtigungen (DM-1), die Überprüfung (DM-2) und die Bewertung sicherheitsrelevanter Probleme (DM-3). Dazu gehört auch die Überwachung von Komponenten von Drittanbietern, die in das IACS integriert sind, im Hinblick auf sicherheitsrelevante Ereignisse, um eine zeitnahe Folgenabschätzung und Behebung zu ermöglichen.
.avif)
INTEGRIEREN SIE AUTOMATISIERTE SBOM IN PROZESSE, AUTOMATISIEREN SIE DIE SBOM-GENERIERUNG UND VERKNÜPFEN SIE SIE MIT BEKANNTEN SICHERHEITSLÜCKEN
Der folgende Abschnitt befasst sich eingehender mit diesen Aspekten des Lieferkettenrisikos und zeigt, wie die Analyse der Zusammensetzung binärer Software erheblich dazu beitragen kann, die von IEC 62443-4-1 geforderten Schutzmaßnahmen zu automatisieren und gleichzeitig den manuellen Aufwand zu reduzieren, der mit der Erfüllung dieser Anforderungen verbunden ist.
Die Software Composition Analysis (SCA) beschreibt den automatisierten Prozess zur Bestimmung der Softwarekomponenten (Open Source und COTS), die in einem Endprodukt enthalten sind. Das Ergebnis einer SCA ist eine SBOM. Da nicht garantiert werden kann, dass der Quellcode für alle Softwarekomponenten verfügbar ist, die von Drittanbietern entlang der Lieferkette bereitgestellt werden, kann SCA sich oft nur auf kompilierte Binärdarstellungen einer Softwarekomponente verlassen.
SM-9: Sicherheitsanforderungen für extern bereitgestellte Komponenten Durch die Einbeziehung binärer SCA in den Prozess zur Identifizierung und Bewältigung von Sicherheitsrisiken im Zusammenhang mit Komponenten von Drittanbietern, die im Produkt verwendet werden, kann die Erstellung eines Inventars von Softwarekomponenten von Drittanbietern automatisiert werden. Dies wird durch die Dekonstruktion der binären Firmware erreicht, um sicherzustellen, dass alle Softwarekomponenten, die letztendlich den Benutzern von IACS zur Verfügung gestellt werden, identifiziert werden können. Statische und dynamische Methoden können verwendet werden, um eine SBOM zu erstellen, indem Softwarekomponenten, zugehörige Versionen sowie angewendete Patches identifiziert werden. Basierend auf diesen Informationen können bekannte Sicherheitslücken, die diese Softwarekomponenten betreffen, identifiziert und weiter untersucht werden.
SM-11: Bewertung und Behebung sicherheitsrelevanter Probleme Die Implementierung eines automatisierten Security Quality Gates mit binärem SCA als Teil des Veröffentlichungsprozesses unterstützt den Prozess der Überprüfung, dass ein Produkt oder ein Produkt-Upgrade erst veröffentlicht wird, wenn die sicherheitsrelevanten Probleme behoben wurden. Um solche Probleme so früh wie möglich im Softwareentwicklungsprozess zu erkennen, muss dieses Security Quality Gate in den Entwicklungsprozess integriert werden. Da Release-Pipelines automatisch ausfallen, wenn die identifizierten Sicherheitsprobleme die zuvor akzeptierten Risikostufen überschreiten, die für die vorgesehenen Anwendungsfälle und den Sicherheitskontext angemessen sind, kann sichergestellt werden, dass sicherheitsrelevante Probleme, die von Drittanbietersoftware herrühren, so früh wie möglich behoben werden.
SVV-3: Schwachstellentests Die Durchführung binärer SCA für alle ausführbaren Dateien zur Identifizierung bekannter Sicherheitslücken in den Softwarekomponenten und Bibliotheken des Produkts wird ausdrücklich als Anforderung im Rahmen des Schwachstellentests erwähnt. Darüber hinaus kann die Erweiterung von SCA durch die Automatisierung der Analyse der Systemkonfiguration, um falsch konfigurierte und unzureichend abgesicherte Dienste aufzudecken und die Compilereinstellungen zu untersuchen, um unsichere Konfigurationen zu vermeiden, die Sicherheitslücken fördern, den manuellen Aufwand erheblich reduzieren und einen Vorsprung bei nachfolgenden Penetrationstests bieten.
DM-1, DM-2, DM-3 Empfang von Benachrichtigungen, Überprüfung und Bewertung sicherheitsrelevanter Probleme
Sicherheit ist nicht nur eine einmalige Anstrengung. Es ist ein Prozess und erfordert eine kontinuierliche Wartung. Die regelmäßige Überprüfung der SBOM einer Firmware auf neu veröffentlichte Sicherheitslücken, geht proaktiv auf diese Anforderung ein und unterstützt die Überprüfung und Bewertung von Phasen sicherheitsrelevanter Probleme, indem die Anwendbarkeit für das Produkt validiert und die Auswirkungen bestimmt werden.
Die Tabelle fasst die Lieferkettenrisiken zusammen, die Anforderungen, die IEC 62443-4-1 an die Softwareentwicklungsprozesse von IACS-Anbietern stellt, um diese Risiken zu mindern, und wie die Automatisierung von ONEKEY für die Firmware-Sicherheitsanalyse die Einhaltung dieser Anforderungen unterstützt.
Keine Abkürzung zur IEC 62443-Konformität!
Strenge Sicherheitspraktiken, wie sie in IEC 62443-4-1 gefordert werden, erhöhen den Aufwand für bestehende Entwicklungszyklen erheblich.
Dennoch sind sie eine Notwendigkeit, um den heutigen erhöhten Sicherheitsanforderungen und der ständig wachsenden Bedrohungslandschaft gerecht zu werden. Leider gibt es im Allgemeinen keine Abkürzung für die Implementierung von IEC 62443 und der damit verbundenen Konformität.
Es stehen verschiedene Tools zur Verfügung, um Dokumentation, Prozesse und Cybersicherheit zu verbessern. Um Ihre IEC 62443-Implementierung zu vereinfachen und zu unterstützen, bietet ONEKEY Expertenrat und Beratungsressourcen zur Unterstützung von Produktlieferanten.
Schauen Sie sich die wichtigsten Erkenntnisse auf der nächsten Seite an und erfahren Sie, wie Sie Ihren Aufwand bei der Implementierung und Aufrechterhaltung der Einhaltung der IEC 62443 erheblich reduzieren können.
ONEKEY 360: Beratung und Automatisierung
Zusätzlich zur Reduzierung des manuellen Aufwands durch Hinzufügen automatisierter ONEKEY steuert die in IEC 62443-4-1 vorgeschriebenen Prozesse und unterstützt Produktlieferanten bei der Einführung von IEC 62443-4-1 mit Lückenanalysen und Implementierungsunterstützung.
ONEKEY bietet auch IEC 62443-4-1-konforme Managed Services zur Durchführung von Sicherheitsüberprüfungen und Validierungstests an, die die Anforderungen von Praxis 5 erfüllen, und zur Verwaltung sicherheitsrelevanter Probleme, wie in Praxis 6 gefordert, und unterstützt bei der Validierung, Triage und Folgenabschätzung gemeldeter Sicherheitslücken.
Die technischen Experten und Sicherheitsforscher von ONEKEY stehen auch zur Verfügung, um Lücken in der Konformität eines Produkts mit IEC 62443-4-2 zu identifizieren und Penetrationstests und Schwachstellenanalysen für IACS-Anwendungen, eingebettete Geräte, Netzwerkkomponenten und Host-Geräte durchzuführen.
WICHTIGE ERKENNTNISSE
- Das Ziel von IEC 62443-4-1 ist es, eine Umgebung und grundlegende Bedingungen für die sichere Entwicklung von Produkten zu schaffen.
- IEC 62443-4-2 hat dagegen konkrete Sicherheitsanforderungen für ICAS-Geräte mit der Möglichkeit einer Gerätezertifizierung.
- Da die Angriffe auf IACS zunehmen, steigt die Nachfrage nach cyber-resistenten IACS. IEC 62443-4-1 bietet das Instrumentarium für die Herstellung solcher cyberresistenter IACS-Komponenten, insbesondere aus der Sicht des Supply-Chain-Risikos.
- Um den erhöhten Sicherheits- und Compliance-Anforderungen gerecht zu werden und Risiken in der Lieferkette zu begegnen, ist die Implementierung automatisierter Sicherheits- und Compliance-Kontrollen, d. h. eine ganzheitliche binäre Softwareanalyse, erforderlich.
- Mit ihren automatisierten Sicherheitsprüfungen deckt die ONEKEY Product Security & Compliance Platform automatisch Verstöße gegen die funktionalen Anforderungen der IEC 62443-4-2 auf, wie z. B. die Stärke der kennwortbasierten Authentifizierung, die Stärke der auf öffentlichen Schlüsseln basierenden Authentifizierung oder die Verwendung unsicherer kryptografischer Funktionen und vieles mehr.
Bereit zur automatisierung ihrer Cybersicherheit & Compliance?
Machen Sie Cybersicherheit und Compliance mit ONEKEY effizient und effektiv.