Methoden der Bedrohungsmodellierung für Produktionsunternehmen (Teil 1) – Kennen Sie Ihre Anlagen?

Bedrohungsmodellierung bezeichnet eine Praxis in der Informationssicherheit, bei der es darum geht, Bedrohungen und mögliche Angriffsvektoren schon während der Design Phase zu erkennen und zu bewerten. Dadurch wird die Möglichkeit geschaffen, die identifizierten Bedrohungen frühzeitig und angemessen zu adressieren. Dies ist vor allem auch für das Risikomanagement relevant, da auf der Basis der Risikobewertung aus dem Bedrohungsmodell Entscheidungen bezüglich Risikoakzeptanz, oder Mitigation fundiert getroffen werden können.

Zusätzlich schreibt der European Cyber Resilience Act, sowie die IEC 62443 Standardserie vor, dass für Produkte, Software wie Hardware, ein Cybersecurity Risk Assessment beziehungsweise eine Bedrohungsmodellierung durchzuführen ist. Im Zuge der Bedrohungsmodellierung werden die Komponenten eines Produktes, die Datenflüsse zwischen diesen Komponenten, sowie externe Einflüsse hinsichtlich potenzieller Risiken bewertet. Durch die frühe Ausführung dieses Projektschrittes im Produktentwicklungslebenszyklus, wird es ermöglicht, Designentscheidungen anhand der entstandenen Ergebnisse zu treffen, und die identifizierten Bedrohungen, soweit möglich, schon mit Hilfe eines sicheren Designs zu mitigieren.

Außerdem wird es, durch die stärkere Vernetzung von Produkten immer wichtiger, die Betriebsumgebung des Kunden in die Bedrohungsmodellierung mit einfließen zu lassen, damit eine integrierte Risikobetrachtung ermöglicht wird. Eine isolierte Betrachtung der Risiken des Produktes ist somit mittlerweile zu wenig. Dies ist unter anderem der Fall, da schon eine unsichere Komponente in der Betriebsumgebung ausreichen kann, um das Netzwerk des Kunden zu kompromittieren.

Als Basis der Bedrohungsmodellierung dient meist ein Modell des zu analysierenden Systems. Dieses Modell beinhaltet Schnittstellen, Komponenten und die Datenflüsse zwischen diesen Elementen, sowie Trust Boundaries, welche einen Zonenwechsel und eine damit einhergehende Änderung des Vertrauensniveaus darstellen (z.B. vom Internet (nicht vertrauenswürdig) ins Intranet (vertrauenswürdiger). In der Informationstechnologie haben sich unter anderem Datenflussdiagramme als Basis für die Bedrohungsmodellierung etabliert.

Aber wie sieht es im Umfeld von sicherer Produktentwicklung aus?

Die Komplexität dieser Systeme, welche eine Mischung aus IT und operationaler Technologie (OT) darstellen, erfordern die Betrachtung und Modellierung beider Welten, um eine korrekte Abschätzung des Risikos zu ermöglichen.

In diesem ersten Blogpost unserer Serie zu OT-Bedrohungsmodellierung gehen wir auf die Modellierung der komplexen Systeme ein. Im zweiten Blogpost wird die Durchführung einer Bedrohungsmodellierung und Risikobestimmung auf Basis dieser Modelle vorgestellt.

Hier möchten wir Details der CERTAINITY Modellierungstechnik und das dahinterliegende Metamodell vorstellen. Ein Metamodell beschreibt die, in einer Modellierungstechnik verwendeten Modellelemente und erklärt deren Zusammenhänge. Daher bildet es die Basis der Modellierung ab.

Modellierung der Systeme

Der vorgestellte Modellierungsansatz basiert auf einer Methodik mit drei Abstraktionsebenen, welche eine vollumfängliche Modellierung und Bewertung von Bedrohungen und Risiken unterstützt. Dies hat den Vorteil, dass der Modellierungsansatz auf der höchsten Abstraktionsebene managementtaugliche Modelle hervorbringt, welche eine geeignete Basis für erforderliche Entscheidungen zur Behandlung von Cyber Risiken bilden.

Der Modellierungsansatz baut auf dem Metamodell (Abbildung 1), auf, und wird über die Abstraktionsebenen immer detaillierter.

Das Metamodell beinhaltet 10 Modellelemente, welche benötigt werden, um eine detaillierte Bedrohungsmodellierung eines produzierten Produktes, oder Systems durchzuführen. Mit Hilfe des Produktionsprozesses werden die Produkte und deren Komponenten produziert. Für Komponenten, beziehungsweise Produkte, oder Systeme, wird auch Software, wie zum Beispiel Firmware benötigt. Daher benötigt der Produktionsprozess auch einen Entwicklungsprozess, welcher für die Herstellung der Software durchgeführt wird. Eine Komponente kann, wie in Abbildung 1 ersichtlich, aus mehreren Komponenten bestehen, wie zum Beispiel Chips von Drittanbietern. Außerdem kann eine Komponente von anderen Komponenten im Produkt abhängig sein.

Ein Produkt besteht aus mehreren Komponenten und ein System aus mehreren Produkten. Zusätzlich haben die Software, das Produkt, die Komponente, das System und die Technologie Assets eine Input/Output Verbindung zu einer Schnittstelle, welche den Datenfluss zwischen den einzelnen Elementen ermöglicht. Die Schnittstelle selbst nutzt Datenobjekte, welche in einem Technologie Asset, wie zum Beispiel einer Datenbank gespeichert sind. Abschließend, sind die Technologie Assets, das System beziehungsweise das Produkt Teil der Betriebsumgebung des Kunden. Wobei das Technologie Asset, wie aus dem oberen Beispiel, eine Datenbank, auch in der Cloud liegen kann.

Die verschiedenen Abstraktionsebenen, welche auf dem Metamodell in Abbildung 1 basieren, werden in den folgenden Absätzen beschrieben. Die Modellierung wird im nächsten Blogpost anhand eines Beispiels verdeutlicht. In diesem Blogpost wird das verwendete Metamodell, welches als Basis für die Modellierung dient, beschrieben.

Die erste und höchste Abstraktionsebene ist die Systemebene, welche high-level Abhängigkeiten zeigt. Hier ist es wichtig, dass die Modellierung der Abhängigkeiten bis zum jeweiligen Prozess stattfindet. Dies ermöglicht eine bessere Einschätzung in welchem Produktions-, oder Entwicklungsprozess die gefundenen Bedrohungen mitigiert werden können und lässt eine Härtung der spezifischen Prozesse zu. Außerdem kann man während der Produktentwicklung identifizierte Lessons Learned dazu verwenden, diese Prozesse zu optimieren. Die Bedrohungen, welche auf der detailliertesten Abstraktionsebene identifiziert werden, können auf dieser Ebene den in Abbildung 2 grünmarkierten Modellelementen zugeordnet werden, wodurch eine high-level Übersicht der Bedrohungen entsteht. Durch die Inklusion der Betriebsumgebung wird gleich klar definiert, welchen Einsatzzweck das Produkt beim Kunden haben sollte.

Die zweite Ebene ist die Komponentenebene, welche die Abhängigkeiten zwischen den einzelnen Komponenten des Systems darstellt. Diese Ebene bietet einen detaillierten Einblick auf den Aufbau des Produktes, oder des Systems. Diese Darstellung ist eine Ebene unter der Systemebene und bietet einen detaillierten Überblick über die eingebundenen Komponenten. Durch den erhöhten technischen Detailgrad ist diese Ebene für technisches Personal bestimmt, welches einen tieferen Einblick über die Abhängigkeiten braucht, um die potenziellen Bedrohungen besser identifizieren und beurteilen zu können. Außerdem werden hier auch Trust Boundaries betrachtet, welche einen Zonenwechsel und eine damit einhergehende Änderung des Vertrauensniveaus zwischen den einzelnen Komponenten darstellen. Diese Ebene beinhaltet alle Informationen über das Produkt beziehungsweise das System, außer die Datenflüsse und Schnittstellen zwischen den Komponenten oder Produkten, welche im höchsten Detaillierungsgrad modelliert werden.

Die letzte Ebene stellt die Informationsebene dar, welche auch die Datenflüsse zwischen den einzelnen Komponenten oder Produkten, sowie die technischen Details, wie verwendete Kommunikationsprotokolle abbilden. Diese Ebene bildet den Kern der Bedrohungsmodellierung ab. Hier wird am detailliertesten modelliert und alle relevanten technischen Details werden abgebildet. Nachdem diese Modellierung abgeschlossen ist, sollten alle produktrelevanten Details modelliert sein und dadurch eine vollumfängliche Bedrohungsmodellierung ermöglich werden.

Im nächsten Abschnitt wird kurz auf die Bedrohungsmodellierung eingegangen, welche den Inhalt für den nächsten Blogbeitrag darstellt.

Bedrohungsmodellierung

Auf Basis der Modelle, welche mittels der oben beschriebenen Methodik modelliert wurden, kann in weiterer Folge die eigentliche Bedrohungsmodellierung und Risikobewertung beginnen. Da alle Schnittstellen, Trust Boundaries, Kommunikationsprotokolle usw. bekannt sind, wird als nächster Schritt evaluiert, wo genau im Design Bedrohungen existieren könnten. Dies kann zum Beispiel mit der STRIDE Methode und mit Hilfe der MITRE ATT&CK Matrix für ICS erfolgen. STRIDE ist ein Akronym für Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Access und Elevation of Privilege. Anhand dieser Bedrohungskategorien kann je Modellelement evaluiert werden, ob das spezifische Element betroffen ist. Die MITRE ATT&CK Matrix für ICS kann dabei helfen spezifische Angriffsmuster von größeren Angreifer-Gruppierungen in die Bedrohungsmodellierung mit einfließen zu lassen. Die dabei identifizierten potenziellen Bedrohungen werden dann hinsichtlich ihrer Kritikalität bewertet und mit Hilfe eines Scoring Systems, wie zum Beispiel dem Common Vulnerability Scoring System (CVSS) eingeordnet. Auf Basis der Ergebnisse werden Security Anforderungen definiert und ein sicheres Design entworfen, welches die definierten Anforderungen umsetzt. Das sichere Design kann die identifizierten potenziellen Bedrohungen schon in der Design-Phase mitigieren und bildet daher die Basis für einen sicheren Produktentwicklungslebenszyklus. Eine detaillierte Beschreibung der Bedrohungsmodellierung können Sie im nächsten Blogbeitrag nachlesen, welcher die Methodik der Bedrohungsmodellierung, der Risikobewertung und möglichen Toolsupport näher beleuchtet.

CERTAINITY hilft Ihnen gerne dabei Ihre Industrie 4.0 beziehungsweise OT- und IT-Landschaft zu modellieren. Kontaktieren sie uns