DISCAIMER: Dieser Artikel ist nicht nur für Organisationen gedacht, die bereits gehackt wurden... Die IEC 62443 ist ein generischer Standard, der in kritischen Sektoren wie der Fertigung, der Energie, dem Transportwesen, dem Gesundheitswesen und vielen anderen als anwendbar gilt.
Dieser Artikel ist die erste Folge einer Serie von 8 Artikeln, die sich mit den wichtigsten Praktiken befasst, die von jeder Organisation implementiert werden sollten, die den Stand der Technik im Bereich der Cybersicherheit für industrielle und automatisierte Steuerungssysteme erfüllen möchte. Basierend auf einer pragmatischen Herangehensweise an den Normteil IEC 62443-4-1, der die Anforderungen an einen sicheren Entwicklungslebenszyklus definiert, gibt Ihnen dieser Artikel eine Anleitung, wie Sie solche Aktivitäten in Ihren aktuellen Organisationsprozessen handhaben können.
Um systematisch sichere Produkte zu entwickeln, muss die Sicherheit über den gesamten Software-Lebenszyklus hinweg betont werden, so dass die Ergebnisse "secure by design" sind. Daher muss jede Phase eines gängigen Software-Lebenszyklus mit Sicherheitspraktiken angereichert werden. Dies führt zu einem sicheren Entwicklungslebenszyklus, wie unten dargestellt. In dieser ersten Folge konzentrieren wir uns auf die Praxis, die für die Definition von Sicherheitsvorgaben erforderlich ist: Die Bedrohungsanalyse
Die Praxis der Bedrohungsanalyse besteht aus einem Prozess, der von einer Organisation implementiert werden muss, um die folgenden, aus der IEC 62443-4-1 entnommenen Anforderungen zu erfüllen:
- Ein Bedrohungsmodell mit den Architekturelementen des Systems, den Assets, dem Sicherheitskontext, den Angriffsvektoren und den Vertrauensgrenzen muss spezifiziert werden.
- Die Bedrohungen müssen identifiziert werden, einschließlich der Bewertung ihres unverminderten und verbleibenden Risikos.
- Es sind Gegenmaßnahmen zu definieren, die zu den Komponentenanforderungen (CRs) und deren Erweiterungen (CR-REs) beitragen.
- Die Rückverfolgbarkeit der Arbeitsprodukte, von den Bedrohungen bis zu den Anforderungen an Gegenmaßnahmen und den Testfällen, muss gewährleistet sein.
Einige zusätzliche Anforderungen können formalisiert werden, um einen effizienten Ansatz für die Bedrohungsanalyse zu gewährleisten:
- Der Prozess der Bedrohungsanalyse soll in den bestehenden Entwicklungsprozess (z.B. V-Modell oder andere) und das agile Vorgehen integriert werden.
- Der Aufwand für die Bedrohungsanalyse während der Produktentwicklung soll so gering wie möglich (sinnvoll und überschaubar) sein.
- Der Prozess der Bedrohungsanalyse muss von allen Beteiligten akzeptiert werden.
- Die Beteiligten sollten durch Software-Tools unterstützt werden, um ein einheitliches Vorgehen zu gewährleisten und Fehler zu vermeiden
Mit den Ergebnissen einer solchen Analyse kann ein sicheres Design erstellt werden, das die identifizierten Bedrohungen mit geeigneten Gegenmaßnahmen auf Architekturebene gezielt angeht. Dieses letzte Thema wird Gegenstand der nächsten Folge (Ep.2) sein. Im Folgenden finden Sie eine Beschreibung des 5-Schritte-Ansatzes:
Schritt 1 - Kontextspezifikation
In diesem ersten Schritt werden die Systemarchitektur und ihr Sicherheitskontext in einem Bedrohungsmodell spezifiziert. Die Systemarchitektur wird in Form eines Datenflussdiagramms spezifiziert, das die mit der Systemumgebung interagierenden Komponenten, ihre Assets, ihren Interaktionspfad und die verwendeten Kommunikationstechnologien enthält. Darüber hinaus werden Vertrauensgrenzen spezifiziert, um verschiedene Vertrauenszonen zu identifizieren. Um dieses Bedrohungsmodell zu erstellen, können verschiedene Tools die Verwaltung der Informationen auf strukturierte Weise unterstützen. Microsoft stellt beispielsweise ein Threat Modeling Tool (MS-TMT) zur Verfügung, das kostenlos erhältlich ist. Es unterstützt die Bedrohungsanalyse, indem es sogenannte Bedrohungsmodellvorlagen bereitstellt, die verwendbare Typen von Modellelementen definieren.
Schritt 2 - Identifizierung und Bewertung von Bedrohungen
In diesem zweiten Schritt müssen Bedrohungen für das in Schritt 1 spezifizierte System identifiziert und auf der Grundlage einer vordefinierten Methodik analysiert werden, die je nach Systemkontext und Anwendungsbereichen unterschiedlich sein kann. Die STRIDE-Methodik ist ein Beispiel unter vielen. Sie definiert einen Ansatz, der die Identifizierung von Bedrohungen in Bezug auf die folgenden Aspekte ermöglicht: Spoofing, Manipulation, Repudiation, Information Disclosure, Denial-of-Service und Elevation of Privileges. Tools können Ihre Prozesse unterstützen, indem sie die Generierung von Bedrohungen basierend auf der Systemdefinition automatisieren.
Für die Risikobewertung bestimmen Organisationen den Schweregrad der Bedrohung anhand von standardisierten oder selbst definierten Stufen. Zusätzlich bestimmen sie die Bedrohungswahrscheinlichkeit durch die Kombination von vier zusätzlichen Metriken, die aus der IEC 62443-Sicherheitsstufendefinition und zum Beispiel aus dem bekannten Common Vulnerability Scoring System (CVSS - https://www.first.org/cvss/calculator/3.0) abgeleitet sind. Dies sind die erforderlichen Fähigkeiten, die erforderlichen Ressourcen, die erforderlichen Berechtigungen und der Angriffsvektor. Das Ergebnis von Schritt 2 ist eine Liste von Bedrohungen mit ihrem ungemilderten Risiko, wie es die IEC 62443 fordert.
Schritt 3 - Definition von Gegenmaßnahmen und Sicherheitsanforderungen
Im dritten Schritt werden Gegenmaßnahmen definiert, die die in Schritt 2 identifizierten Bedrohungen abschwächen. Zur Nachvollziehbarkeit wird jede Anforderung an eine Gegenmaßnahme mit den Bedrohungen, die sie abschwächt, und mit den IEC 62443 CRs/CR-REs, zu denen sie beiträgt, verknüpft.
Schritt 4 - Bewertung der Restrisiken
Im vierten Schritt wird das Restrisiko (nach Implementierung von Gegenmaßnahmen) jeder Bedrohung ermittelt. Dieses Risiko wird mit dem gleichen Bewertungsansatz wie für das ungemilderte Risiko in Schritt 2 bewertet. Wenn das Restrisiko als nicht akzeptabel angesehen wird, müssen zusätzliche Gegenmaßnahmen definiert werden, indem man zu Schritt 3 zurückkehrt. Nach Schritt 4 sind die Ergebnisse eine Liste von Bedrohungen mit ungemildertem und Restrisiko und eine Liste von Gegenmaßnahmen, die diese Bedrohungen mindern und zu den CRs/CR-REs des Standards beitragen
Schritt 5 - Spezifikation und Implementierung von Gegenmaßnahmen
Der fünfte Schritt besteht schließlich im Entwurf und der Umsetzung von Gegenmaßnahmen in Übereinstimmung mit dem bestehenden Entwicklungsprozess.
Wenn nach Schritt 5 das System so verändert wird, dass das Bedrohungsmodell nicht mehr mit dem Entwicklungsstand übereinstimmt (z. B. zu Beginn eines neuen Sprints), muss der Prozess der Bedrohungsanalyse ab Schritt 1 wiederholt werden. Das Bedrohungsmodell wird aktualisiert, um die Systemänderungen widerzuspiegeln, neu eingeführte Bedrohungen werden analysiert, Anforderungen für Gegenmaßnahmen werden überarbeitet/hinzugefügt, und die Risiken werden aktualisiert.
Auch wenn die Einhaltung von 62443 nicht das Ziel ist, sollte die Bedrohungsanalyse als eine der wichtigsten Best Practices betrachtet werden, die von Organisationen, die mit verschiedenen Arten von Assets arbeiten, initiiert und gehandhabt werden sollten. Sie erleichtert allen Beteiligten das Verständnis für die mit der Cybersicherheit verbundenen Aspekte und minimiert Cyber-Risiken, indem sie einen pragmatischen Ansatz sicherstellt, der die Identifizierung dieser Risiken in einem frühen Stadium des Konzepts unterstützt.
Wenn Sie Fragen zu den Ansätzen der Bedrohungsanalyse und/oder zu den Zertifizierungskriterien haben, zögern Sie bitte nicht, unseren Spezialisten für Cybersicherheit zu kontaktieren: Kilian Marty