Schritt 1: Systemmodell erstellen
Eine Einführung
Im ersten Teil unserer Tutorial-Serie haben wir die Grundlagen der Bedrohungsanalyse gelegt und die fünf essenziellen Schritte vorgestellt, die uns systematisch durch den Analyseprozess führen. Wenn du den Teil verpasst hast, kannst du alle wichtigen Informationen hier nachlesen: Bedrohungsanalyse – Teil 1.
Nun starten wir mit dem ersten Schritt: die Erstellung des Systemmodells. Dieses Modell bildet die Grundlage für alle weiteren Aktivitäten der Bedrohungsanalyse. Es hilft, die Komponenten, Datenflüsse und Schnittstellen eines Systems zu verstehen und Vertrauensgrenzen zu identifizieren.
Im Kontext unseres Beispiels – einer vernetzten Wallbox für Elektrofahrzeuge – werden wir in diesem Teil:
- ein klar strukturiertes (vereinfachtes) Systemmodell erstellen,
- die Beziehungen zwischen den Systemkomponenten visualisieren, und
- die Basis für die Identifikation von Schwachstellen und Bedrohungen legen.
1. Beschreibung des Systemkontext
Um ein System effektiv zu analysieren und abzusichern, ist es entscheidend, zunächst ein klares Bild davon zu gewinnen, welche Elemente zu unserem System gehören und wie es mit seiner Umgebung interagiert. Ein guter Ausgangspunkt ist die Beschreibung des Systemkontextes. Diese Beschreibung erfolgt auf einer hohen Abstraktionsebene und beantwortet grundlegende Fragen wie:
-
Was ist unser System?
Definition des Hauptsystems, z. B. eine Wallbox als zentrale Einheit. -
Aus welchen Komponenten besteht unser System?
Identifikation der Bestandteile wie die Wallbox, mobile App, Cloud-Server oder Heimautomation. -
Welche Akteure gibt es in unserem System?
Unterscheidung zwischen menschlichen Akteuren (z. B. Endanwender) und technischen Akteuren (z. B. Heimautomationssystem, Fahrzeuge). -
Welche Schnittstellen gibt es?
Betrachtung der Verbindungen, wie Bluetooth zwischen Wallbox und App oder Ethernet zur Cloud. -
Wo liegt die Systemgrenze?
Abgrenzung zwischen internen Systembestandteilen und externen Komponenten wie dem Stromnetz oder dem Internet.
Im Kontext der Security sind zusätzliche Aspekte zu berücksichtigen:
-
Gibt es spezielle Vertrauensgrenzen (Trust Boundaries)?
Beispielsweise der Übergang vom lokalen Heimnetzwerk zum Internet oder physische Grenzen wie das Gehäuse der Wallbox, das unbefugten Zugang verhindert. -
Welche Daten werden zwischen den Komponenten ausgetauscht?
Sensible Informationen wie Authentifizierungsdaten oder Steuerbefehle sollten identifiziert und entsprechend geschützt werden.
Durch die Modellierung des Systemkontextes schaffen wir die Grundlage, um die Sicherheitsanforderungen und potenzielle Schwachstellen in den folgenden Schritten der Bedrohungsanalyse systematisch zu adressieren.
2. Modellierung
Für die Modellierung bietet es sich an, auf zwei Ebenen zu arbeiten. In meinen Workshops starte ich häufig mit der Ebene 0, da sie eine einfache und verständliche Grundlage für Diskussionen mit den Stakeholdern bietet. Bereits auf dieser abstrakten Ebene lassen sich viele potenzielle Bedrohungen identifizieren, was sie zu einem idealen Ausgangspunkt macht.
Für eine detailliertere Bedrohungsanalyse oder die Nutzung spezialisierter Tools wie dem Microsoft Threat Modeling Tool oder dem OWASP Threat Dragon ist jedoch ein umfassenderes Datenflussdiagramm (DFD) erforderlich. In diesem Tutorial konzentrieren wir uns auf die Bedrohungsanalyse basierend auf dem Systemkontext-Modell aus Ebene 0. Eine tiefere Analyse mit einem DFD und der Einsatz eines Threat Modeling Tools werden wir in einem separaten Tutorial ausführlich behandeln.
3. Beispiel für unsere Wallbox
Für unsere (vereinfachte) Wallbox könnte unser Systemkontext-Model wie folgt aussehen. Der Fokus dabei liegt hierbei die Komponenten, die mit unserem System interagieren und welche Schnittstellen es nach außen gibt.
Übersicht der Komponenten
Neben den einfachen Blöcken in unserem Modell sollten wir für ein besseres Verständnis die Blöcke auch näher beschreiben und sofern möglich auch schon Hinweise darauf geben, welche Funktionalitäten oder auch Daten hier bereitgestellt oder genutzt werden. Auch ist es wichtig zu wissen, welche Komponenten liegen im Fokus der Betrachtung und welche sind komplett als externe Komponenten zu betrachten.
| Komponente | Klassifizierung | Beschreibung |
|---|---|---|
| Wallbox | System of Interest | Wallbox mit Gehäuse und internen Komponenten wie einem Touchpanel, Steuerungselektronik und einer Ladeelektronik |
| Cloud Service | System of Interest | Eine Cloud-Komponente der Wallbox, mit der ein Fernzugriff / Fernwartung möglich wird und auch Statistiken / Historische Daten ausgewertet werden können. Auf den Cloud Service kann nur über die Mobile App zugegriffen werden |
| Mobile App | System of Interest | Mobile App auf einem Apple oder Android Gerät, mit dem der Anwender Ladevorgänge steuern kann, den Ladestatus abfragen kann oder Konfiguration und Profile der Wallbox anpassen kann. Die App kann dabei direkt über Bluetooth mit der Wallbox kommunizieren oder über das Internet mit den Cloud Service. |
| Touchpanel | System of Interest | Ist Bestandteil der Wallbox selbst und ermöglicht bei phyikalischem Zugriff das Starten / Beenden von Ladevorgängen und die Abfrage des Ladezustands. |
| Webbrowser | Externe Komponente | Ermöglicht das Aufrufen einer Konfigurationsseite direkt auf der Wallbox, um z.B. die Konfiguration für den Cloud Service vorzunehmen oder ein Update einzuspielen. |
| Auto | Externe Komponente | Wird mittels Ladekabel an die Wallbox angeschlossen. Hierüber werden u.a. auch Informationen zum maximalen Ladestrom ausgetauscht. |
| Stromnetz | Externe Komponente | Quelle für die Versorgungspannung und Ladestrom |
| Heimautomation | Externe Komponente | Anbindung an die Heimautomation, um z.B. für Ladevorgänge die vorhandene PV Anlage zu nutzen. |
Schnittstellen / Interfaces nach "außen"
| Schnittstelle | Beschreibung |
|---|---|
| IF_Stromeinspeisung | Physikalischer Stromanschluss für die Wallbox |
| IF_Heimautomation | Kommunikation mit der Heimautomation über gängige Protokolle, um z.B. das Laden mit dem Ertrag der PV Anlage zu koppeln |
| IF_WebConfig | Ethernet Interface zum lokalen Web Server auf der Wallbox, um eine Konfigurations-Webseite aufrufen zu können. Zur Konfiguration gehören z.B. Ausführen von Updates, Konfiguration der Verbindung zum Cloud Service. |
| IF_CloudService | Interface über eine REST API zu einem Cloud Service, der die Datensammlung und Konfiguration der Wallbox aus der Ferne ermöglicht. |
| IF_MobileAppBluetooth | Lokales Bluetooth Interface der Wallbox, um mit der App auf einem mobilen Endgerät kommunizieren zu können. |
| IF_MobileAppCloud | Interface zur Kommunikation von der mobilen App über eine REST API zum Cloud Service, um darüber die Konfiguration der Wallbox vorzunehmen, Ladevorgänge zu kontrollieren / zu steuern oder sich Statistiken anzeigen zu lassen. |
| IF_Ladeanschluss | Physikalisches Interface zum Anschluss des Autos, welches geladen werden soll. Über den standardisierten Stecker und Datenkanal werden u.a. Informationen zum maximalen Ladestrom ausgetauscht. |
| UI_WebConfig | Webseite die vom Anwender aufgerufen werden kann zur Konfiguration, die vom Anwender in einem Webbrowser aufgerufen werden kann. Über diese Webseite können Updates installiert oder die Konfiguration der Wallbox angepasst werden. |
| UI_MobileApp | App die vom Anwender aufgerufen wird auf einem mobilen Endgerät, mit dem die Konfiguration der Wallbox angepasst werden kann, Updates installiert werden können, der Ladevorgang gesteuert werden kann, ... |
| UI_Bedienpanel | Physikalisches Interface direkt am Gehäuse der Wallbox, um Ladevorgänge zu Starten / zu Stoppen und sich einen Status auf dem Display anzeigen zu lassen. |
4. Vertrauensgrenzen
Für die Bedrohungsanalyse ist es nun wichtig zu wissen, ob es in unserem System Vertrauensgrenzen gibt und ob es Komponenten gibt, die sich gegenseitig Vertrauen. Typische Fragen, die dabei helfen, die Grenzen und Vertrauenszonen zu identifizieren sind dabei:
- Welche Bereiche oder Komponenten im System benötigen unterschiedliche Sicherheitsanforderungen (z. B. sensiblere Daten oder höhere Zugriffsrechte)?
Ziel: Klärung, wo Sicherheitsstufen variieren und spezielle Schutzmaßnahmen erforderlich sind.
Beispiel: z.B. das Ausführen eines Firmware Updates oder die Einrichtung der Kommunikation zum Cloud Service. - Wo gibt es Übergänge zwischen internen und externen Systemen oder Nutzern (z. B. Verbindungen ins Internet, externe APIs oder Benutzerzugriffe)?
Ziel: Identifikation von Schnittstellen, an denen das Vertrauen nicht automatisch gewährleistet ist.
Beispiel: Die Kommunikation über Bluetooth zwischen einem mobilen Endgerät und der Wallbox - Welche Arten von Daten oder Operationen fließen zwischen den Komponenten, und wie sensibel oder kritisch sind diese?
Ziel: Bewertung der Risiken für Datenintegrität, Vertraulichkeit und Verfügbarkeit in verschiedenen Zonen.
Beispiel: Authentifizierung des Anwenders in der mobilen App, die mit dem Cloud Service kommuniziert
In unserem Beispiel der Wallbox können wir diese Grenzen auch Skizzenhaft im Systemkontext einzeichnen. (Hinweis: man kann die Grenzen auch modellieren, davon sehen wir in diesem Beispiel aber ab, da wir da Modell nur als Diskussionsbasis nutzen und den Fokus auf die Identifikation legen, ähnlich wie wir das in einem Workshop am Whiteboard tun würden).
| Vertrauensgrenze (Trust Boundary) | Beschreibung |
|---|---|
| #1 | Physikalischer Zugriff auf die Wallbox, hier speziell auf das Bedienpanel am Gerät |
| #2 | Vertrauensgrenze zwischen der mobilen App und dem Cloud Service. Die Kommunikation erfolgt hier über das Internet. |
| #3 | Bluetooth Verbindung zwischen der mobilen App und der Wallbox |
| #4 | Die Internet Verbindung zwischen der Wallbox und dem Cloud Service (zur Info: die Wallbox selbst hat keinen direkten Internetzugang sondern benötigt hierzu einen externen Router, der als Gateway zum Internet benötigt wird) |
| #5 | Zugriff über Ethernet auf den Webserver der Wallbox |
| #6 | Zwischen der Wallbox und der Heimautomation und den hier genutzten Protokollen |
5. Ausblick auf Teil 3 "Assets und Schutzziele"
Im ersten Teil unserer Tutorial-Serie haben wir die Grundlagen der Bedrohungsanalyse behandelt und die fünf wesentlichen Schritte kennengelernt und nachdem wir nun im ersten Schritt das Systemmodell für unsere Wallbox erstellt haben, werden wir uns im kommenden Teil 3 mit der Identifikation von Schutzzielen, Assets und Trust Levels befassen. Dieser Schritt ist entscheidend, um die spezifischen Sicherheitsanforderungen unseres Systems zu bestimmen.
In Teil 3 werden wir:
-
Schutzziele definieren: Bestimmung der zentralen Sicherheitsziele wie Vertraulichkeit, Integrität und Verfügbarkeit, die für Ihr System relevant sind.
-
Assets identifizieren: Ermittlung der schützenswerten Komponenten und Daten innerhalb Ihres Systems, die für den Betrieb und die Sicherheit essenziell sind.
-
Trust Levels festlegen: Einstufung der verschiedenen Systemkomponenten und Akteure nach ihrem Vertrauensniveau, um geeignete Sicherheitsmaßnahmen zu implementieren.
Durch die Identifikation dieser Elemente legen wir die Grundlage für eine effektive Bedrohungsanalyse und die Entwicklung gezielter Schutzstrategien.
Hinweis: der dritte Teil erscheint voraussichtlich am 10.12.2025
6. Empfohlenes Training: Security Requirements Engineering
Um noch besser auf Sicherheitsanforderungen eingehen zu können, empfehle ich Dir mein Training „Security Requirements Engineering„. Dieses Training vermittelt praxisnah, wie Du Sicherheitsanforderungen von Anfang an in Deinen Entwicklungsprozess integrieren kannst. Du lernst u.a.:
- Sicherheitsziele effektiv zu definieren.
- Risiken systematisch zu analysieren und in Anforderungen umzuwandeln.
- Mit bewährten Methoden wie STRIDE und OWASP Bedrohungen zu identifizieren, Risiken zu bewerten und zu priorisieren.
Mit dem Training bist Du bestens darauf vorbereitet, Sicherheitsaspekte frühzeitig in Deine Projekte zu integrieren und Systeme ganzheitlich abzusichern.
