Einführung

Wie werden Sicherheitsrisiken erkannt und gemindert? Industriestandards wie ISO^®/SAE^® 21434 und DO-356 verlangen, dass diese Frage beantwortet wird, bevor neue Produkte auf den Markt gebracht werden. Ohne einen einheitlichen Prozess zur Dokumentation, zum Tracking, zur Umsetzung und zur Verifizierung von Änderungen kann dies schwierig sein. Je nach Branche kennen Sie diesen Prozess möglicherweise unter der Bezeichnung TARA (Threat Analysis and Risk Assessment), SRA (Security Risk Assessment) oder einem anderen Namen. Durch den Einsatz eines modellbasierten Frameworks für die SRA (siehe Abbildung 1) lässt sich eine enge Verzahnung zwischen Design sowie Sicherheits- und Schutzanforderungen erreichen – und das anhand eines geführten, schrittweisen Prozesses. Sie können den Prozess mithilfe der umfangreichen Funktionen von MATLAB^® ganz einfach an Ihre Anforderungen anpassen, erweitern oder automatisieren.

Kontext: Roboter für den Lagerbetrieb

In diesem Whitepaper wird ein Beispiel für einen Lagerroboter beschrieben, der unter anderem einen Fernbedienungsoperator, eine Softwarearchitektur, eine Regelstrecke sowie ein Kameramodell umfasst (siehe Abbildung 3). Die in Abbildung 4 dargestellte Softwarearchitektur umfasst unter anderem Module für den Planungsscheduler, die Routenplanung, die Regelung sowie die Positionsschätzung.

Die modellgestützte Sicherheitsanalyse erfolgt in mehreren Schritten, die in Abbildung 2 veranschaulicht sind:

1. Identifikation von Assets und Bedrohungen
2. Berechnung des Sicherheitsrisikos
3. Definition, Implementierung und Verifikation von Gegenmaßnahmen

Identifikation von Assets und Bedrohungen

Eine entscheidende Frage bei der Ermittlung von Schutzgütern und Bedrohungen ist: „Welche Komponenten oder Informationen erfordern besonderen Schutz?“ Im Idealfall ist alles schützenswert, was für das System einen Wert hat. In der Praxis führen Komplexität und Kosten dazu, dass der Schutz auf das Wesentliche beschränkt wird, beispielsweise auf sicherheitskritische Funktionen. Solche Funktionen werden als „Assets“ definiert. Jedes Asset weist dabei eine oder mehrere Schutzattribute auf, etwa:

• Verfügbarkeit
• Integrität
• Authentizität
• Vertraulichkeit
• Nichtabstreitbarkeit
• Autorisierung

Asset-Identifikation: Was soll geschützt werden?

Es gibt viele Methoden zur Identifikation von Assets, etwa die Bewertung ihrer Benutzerexponierung, die Analyse von Datenflüssen, die Überprüfung einer Software-Stückliste (SBOM) oder die Berücksichtigung ihrer Rolle in sicherheitsrelevanten Funktionen. Als einfache Faustregel sollten alle Komponenten berücksichtigt werden, die externe Eingaben verarbeiten.

In der Softwarearchitektur des Roboters befinden sich Komponenten, die auf das Signal (robotPosition) der Lagerdeckenkameras im Simulationsmodell angewiesen sind:

• Planungsscheduler
• Positionsschätzer

Im Rahmen dieses Beispiels konzentriert sich dieser Bericht auf den Schutz der Verfügbarkeit, Integrität und Authentizität dieses Signals in Bezug auf die genannten Assets. Es ist zu beachten, dass zusätzliche Schutzeigenschaften für diese Assets relevant sein können und die Analyse vollständig für sämtliche Assets im System erfolgen sollte.

Zur Gewährleistung der durchgängigen Nachverfolgbarkeit in dieser Analyse empfiehlt sich die Nutzung der Tabellen des Safety Analysis Manager innerhalb von Simulink Fault Analyzer™. Um diese Assets in die Tabelle aufzunehmen, werden Stereotypen in System Composer™ verwendet. Durch die Zuweisung des Stereotyps „Asset“ zu den entsprechenden Subsystemen erfolgt deren automatische Übernahme in die Tabelle. In der Tabelle werden der Typ des Assets, die schützenswerten Eigenschaften und alle weiteren relevanten Informationen festgehalten (siehe Abbildung 5). Mithilfe der Requirements Toolbox™ lassen sich Assets mit den ermittelten Bedrohungen verknüpfen, wodurch ein digitaler Thread für die gesamte weitere Analyse entsteht. So lassen sich folgende Ziele verfolgen: 

1. Erfüllung der in Industriestandards geforderten Nachverfolgbarkeitskriterien.
2. Durchführung einer Auswirkungsanalyse bei Änderungen.

Identifikation von Bedrohungen: Welche potenziellen Fehlerquellen bestehen?

Da nun die zu schützenden Assets identifiziert wurden, besteht der nächste Schritt darin, die Bedrohungen zu ermitteln, denen diese Werte ausgesetzt sind. Ein gängiges Verfahren zur Identifizierung von Sicherheitsbedrohungen in Software ist das STRIDE-Modellierungsframework. Die gewünschten Eigenschaften der Assets werden direkt den entsprechenden Bedrohungen zugeordnet, wie in Tabelle 1 dargestellt.

Unabhängig davon, ob Sie STRIDE oder eine andere Methode verwenden, können Sie eine MATLAB-Funktion erstellen, die basierend auf den zuvor identifizierten Schutzeigenschaften des Wertes automatisch passende Bedrohungen vorschlägt. Beispielsweise ist die Bedrohung, die dem Schutzziel Verfügbarkeit zugeordnet wird, die Dienstverweigerung. Dies ist ein breit gefasster Begriff, und es wird in der Regel erforderlich sein, eine genauere Spezifizierung vorzunehmen, um das tatsächliche Risiko sowie geeignete Gegenmaßnahmen bestimmen zu können. Bedrohungskataloge wie CAPEC™¹, ATT&CK^®2 und EMB3D^™3 können verwendet werden, um genauere Informationen darüber zu erhalten, wie eine Bedrohung im konkreten Fall aussehen kann. In diesem Beispiel könnte dies etwa das Stören des Signals von der Kamera zum Positionsschätzer (Jamming) sein.

Sobald die konkrete Bedrohung identifiziert wurde, kann die Bedrohungstabelle mit dem entsprechenden CAPEC-Eintrag (z. B. CAPEC-601) aktualisiert werden. Wie die Assets-Tabelle ermöglicht auch die Bedrohungstabelle eine Rückverfolgbarkeit und Auswirkungsanalyse durch ihre Verknüpfungen mit den übrigen Teilen der Analyse.

Berechnung des Sicherheitsrisikos

Die Berechnung des Risikos einer bestimmten Bedrohung basiert auf mehreren zentralen Faktoren. Der erste Faktor ist die Umsetzbarkeit, die beschreibt, wie einfach ein Angriff durchgeführt werden kann. Der zweite Faktor ist die Auswirkung, die die Schwere der möglichen Konsequenzen berücksichtigt.

Umsetzbarkeit: Wie komplex ist die Umsetzung?

Die Anwendung der Attack-Potential-Methode gemäß ISO 18045 bietet ein systematisches Framework zur Abschätzung der Umsetzbarkeit eines Angriffs auf Grundlage der folgenden erforderlichen Faktoren:

• Expertise: Über welche technischen Kenntnisse und Fertigkeiten verfügt der Angreifer?
• Wissen: Welches Maß an Insiderwissen ist für den Angriff notwendig?
• Equipment: Welche Tools oder Hardware sind für die Durchführung des Angriffs erforderlich?
• Benötigte Zeit: Wie lange dauert es, eine Schwachstelle zu identifizieren und einen Exploit zu entwickeln?
• Zeitfenster für den Angriff: Wann und unter welchen Bedingungen kann der Angriff durchgeführt werden?

Die Bedrohungstabelle (Abbildung 6) enthält Spalten für jeden der zu berücksichtigenden Faktoren und eine individuell erstellbare MATLAB-Formel berechnet die Umsetzbarkeit automatisch. Wie oben erwähnt, wird die Attack-Potential-Methode verwendet, bei der der standardisierte, nummerisch bewertete Wert jedes einzelnen Faktors aufsummiert wird.

Auswirkung: Wie schwerwiegend ist es?

Jede Bedrohung hat eine potenzielle Auswirkung oder Konsequenz. In diesem Beispiel wird die Auswirkung anhand der sicherheitsrelevanten Folgen bestimmt. Dazu wird die bestehende Auswirkungsbewertung aus einer vorhandenen Sicherheitsanalyse (d. h. der Gefährdungsbeurteilung) direkt genutzt. Beachten Sie, dass dies eine Vereinfachung darstellt. Üblicherweise wird die Auswirkung zusätzlich hinsichtlich betrieblicher, finanzieller sowie datenschutzbezogener Aspekte bewertet.

In der Gefährdungsbeurteilung (Abbildung 7) reicht der Schweregrad eines funktionalen Ausfalls des Positionssensors von S3 bis S5. Zur Vereinfachung wird der höchste dieser Werte als Auswirkung der Dienstverweigerungsbedrohung (DoS) herangezogen.

Risikoermittlung und -behandlung

Sobald Umsetzbarkeit und Auswirkung bewertet wurden, kann das Risiko mithilfe einer weiteren MATLAB-Formel automatisch berechnet werden. In diesem Beispiel wird das Risiko berechnet, indem die Umsetzbarkeit mit der Auswirkung multipliziert wird.

Je nach Risikotoleranz können Sie entscheiden, wie Sie Risikobehandlungen durchführen. Die Risikobehandlung wird in der Tabelle (Abbildung 8) durch Kennzeichnung einer der folgenden Eigenschaften dargestellt:

• Vermeiden: Das Risiko muss vollständig vermieden werden (z. B. durch Entfernen von Funktionalität).
• Verringern: Das Risiko muss durch technische Gegenmaßnahmen gesenkt werden.
• Teilen: Das Risiko wird an Versicherung, Nutzer oder Dritte übertragen.
• Akzeptieren: Das Risiko wird „wie es ist“ akzeptiert, ohne weitere Maßnahmen.
• Nicht anwendbar: Die Bedrohung existiert in diesem System nicht.

Hinweis: Sowohl Vermeiden als auch Verringern führen zu technischen Anforderungen.

Die Risikoermittlung sowie die Beziehungen zwischen Bedrohungen, Assets und weiteren Elementen lassen sich in einem Graphen visualisieren, wodurch Einblicke in deren Beitrag zum Gesamtrisiko gewonnen werden. Da der Graph Informationen zur Bedeutung jeder Beziehung liefert, kann er zur Priorisierung der Arbeiten genutzt werden. Wie aus Abbildung 9 ersichtlich ist, stellt Dienstverweigerung (DoS) eine größere Bedrohung dar als Manipulation und sollte daher zuerst behandelt werden. Dies liegt daran, dass der Schweregrad bei Dienstverweigerung mit S5 höher ist als bei Manipulation (S4).

Definition, Implementierung und Verifikation von Gegenmaßnahmen

Um das Risiko einer Störung des Signals (DoS) von der Kamera zum Positionsschätzer zu reduzieren, kann das Risiko entweder durch Verringerung der Umsetzbarkeit oder durch eine Gegenmaßnahme gemindert werden. In diesem Fall wurde die Auswirkung durch Hinzufügen einer Notbremsfunktion verringert. Diese Maßnahme ist mithilfe eines Links im Gegenmaßnahmenblatt (Abbildung 10) bis zur Bedrohungstabelle rückverfolgbar. Jede Gegenmaßnahme führt zu einem Sicherheitsziel, das in Form mindestens einer abgeleiteten Anforderung konkretisiert wird. In diesem Fall besteht die Anforderung darin, dass der Roboter innerhalb einer Sekunde nach Erkennung der Störung zum Stillstand kommt; diese Anforderung ist ebenfalls für Rückverfolgbarkeit und Auswirkungsanalyse verknüpft.

Prüfung auf Konsistenz und Vollständigkeit

Bis hierhin hat dieses Whitepaper Bedrohungen identifiziert, deren Risiken bewertet und Gegenmaßnahmen definiert, wenn das Risiko unakzeptabel hoch war. Der nächste Schritt wäre die Entwicklung der Gegenmaßnahme(n). Bevor Sie die Sicherheitsziele übergeben, stellen Sie sicher, dass das Bedrohungs- und Risikomodell gültig ist, indem Sie Folgendes überprüfen:

• Für jedes Asset wurde mindestens eine Bedrohung identifiziert (Prinzip der Vollständigkeit).
• Alle Bedrohungen wurden geprüft.
• Gegenmaßnahmen wurden festgelegt, in den Fällen, in denen das Risiko zu hoch ist.
• Anforderungen (z. B. Sicherheitsziele) wurden erstellt und mit den Gegenmaßnahmen verknüpft.
• Es gibt keine unterbrochenen Verknüpfungen zwischen Bedrohungen, Assets, Modellen und der Sicherheitsanalyse.

Mithilfe eines einzigen Funktionsaufrufs lassen sich all diese Validierungen durchführen und ein Diagramm erzeugen (Abbildung 11).

Implementierung von Gegenmaßnahmen

Sobald Gegenmaßnahmen definiert wurden, ist es an der Zeit, diese im Modell zu implementieren. Im Simulink^®-Modell des Reglers wird MATLAB verwendet, um einen Funktionsblock hinzuzufügen (Abbildung 12), der für die Rückverfolgbarkeit mit der Anforderung verknüpft ist.

Verifikation und Validierung

Nach der Implementierung ist der nächste Schritt, den Angriff zu modellieren und die Funktionalität der Gegenmaßnahme zu verifizieren. Dies lässt sich mit dem Simulink Fault Analyzer realisieren, mit dem der Angriff modelliert und simuliert wird. Abbildung 13 visualisiert die Einstellungen, die beim Modellieren des Angriffs verwendet werden.

Nachdem der Fehler aktiviert und das Modell ausgeführt wurde, kann man die Signale im Simulation Data Inspector (SDI) genauer betrachten, wie in Abbildung 14 gezeigt. Außerdem können die Reaktionen auf den Angriff mithilfe der Navigation Toolbox™ visualisiert werden, wie in Abbildung 15 dargestellt. Diese Tools ermöglichen eine visuelle Überprüfung, dass die Gegenmaßnahme wie beabsichtigt funktioniert, und mithilfe des Simulink Test Manager™-Frameworks lässt sich dieser Workflow skalieren, um die vollständige Verifikation aller Funktionalitäten sicherzustellen.

Abbildung 15. Visualisierung eines Angriffs mit (links) und ohne (rechts) Gegenmaßnahmen.

Fazit

Ein modellbasiertes Sicherheitsanalyse-Framework bietet einen Workflow mit integrierter Rückverfolgbarkeit, individueller Anpassbarkeit an Ihre Compliance-Standards und Automatisierung, um die Konsistenz zwischen Entwurf und Analyse sicherzustellen. Beschleunigen Sie Verifikation und Validierung, indem Sie diese mithilfe dieses optimierten Workflows früher in den Entwicklungsprozess verlagern und so sowohl Entwicklungszeit als auch -kosten reduzieren. Von der Identifizierung potenzieller Bedrohungen über die Quantifizierung und Bewertung von Risiken bis hin zur Definition und Simulation der Wirksamkeit Ihrer Gegenmaßnahmen sorgt dieser End-to-End-Ansatz dafür, dass Ihr Sicherheitsprozess lückenlos abgedeckt ist.

Referenzen

1. Die MITRE Corporation. „CAPEC – Common Attack Pattern Enumeration and Classification (CAPEC™).” Aufgerufen am 18. März 2025.

2. Die MITRE Corporation. „MITRE ATT&CK^®.” Aufgerufen am 18. März 2025.

3. Die MITRE Corporation. „MITRE EMB3D™.” Aufgerufen am 18. März 2025.