Über unsMediaKontaktImpressum
Florian Rappl, Lothar Schöttner & Jens Thirmeyer 15. Juni 2021

Threat Modelling für IoT-Lösungen

Nicht nur die Anzahl, sondern auch die Diversität von IoT-Geräten und deren Einsatzszenarien nehmen stetig zu. Waren anfänglich IoT-Anwendungsfälle hauptsächlich aus dem Consumer-Umfeld bekannt, gewannen sie im Rahmen der Digitalisierung von Prozessen und Produkten für Unternehmen signifikant an Wichtigkeit.

Ungeachtet der konkreten Anforderungen bzw. der Komplexität der jeweiligen Anwendungsszenarien ist der Bereich Security für IoT-Lösungen von zentraler Bedeutung. So ist beispielsweise die Integrität der gesammelten Daten eine essentielle Voraussetzung für eine zuverlässige Entscheidungsfindung mit Hilfe von künstlicher Intelligenz und somit für eine gesicherte Automatisierung von Geschäfts- und Produktionsprozessen.

Ein weiterer Aspekt ist die Absicherung der einzelnen Lösungskomponenten. Von der Entwicklung über den Betrieb bis hin zur endgültigen Abschaltung ist ein IoT-Gerät in jeder Phase unterschiedlichen Sicherheitsrisiken ausgesetzt. Daher ist es wichtig, bereits während der Konzeption mit Hilfe eines Threat Models mögliche Bedrohungsszenarien für die gesamte Lösung zu betrachten und deren Auswirkungen zu analysieren, um frühzeitig über geeignete Gegenmaßnahmen und entsprechende Umsetzungsmöglichkeiten entscheiden zu können.

Der Ausweis eines IoT-Geräts

Auch bei IoT-Geräten stellt sich die Frage "Wer bin ich?". Um ein Netz intelligenter Geräte verwalten oder gesammelte Gerätedaten verlässlich interpretieren zu können, ist die gesicherte Zuweisung einer eindeutigen Identität an jedes einzelne Gerät essenziell. Dies bedeutet, dass bereits in den ersten Momenten eines produktiven "Gerätelebens" die Identität feststehen bzw. als erstes vergeben werden muss.

Doch wie erlangt ein Gerät seine Identität? Hierzu gibt es verschiedene Ansätze. In der Praxis findet unter anderem die Vergabe der Identität beim Produktionsprozess, die Zuweisung mit Hilfe von Hardwaremodulen oder die Erstellung der Identität im Rahmen der Geräteinbetriebnahme Anwendung. Für alle Arten der Provisionierung ist es gleichermaßen wichtig, dass sowohl der Vergabeprozess als auch die Speicherung der Identität höchsten Sicherheitsanforderungen genügen.

Betrachtet man zum Beispiel die Identitätsvergabe während der Inbetriebnahme auf Basis eines X.509-Zertifikats, so sollte nicht nur Augenmerk auf die sichere Erstellung und Übermittlung gelegt werden, sondern auch auf deren gesicherte Ablage innerhalb des Gerätes. Hier könnte beispielsweise ein Trusted Platform Module (TPM) zum Einsatz kommen, welches als Speicherort für das Zertifikat dient aber das Auslesen des Private Keys und somit den "Identitätsklau" verhindert.

Nachdem ein Gerät nun eine Identität erhalten hat, die sicher verwahrt werden kann, gilt es im nächsten Schritt die Geräteidentität zu validieren, um z. B. die gesicherte Bearbeitung von gesammelten Daten im entsprechenden Gerätekontext zu ermöglichen. Analog zur Passkontrolle bei der Einreise in ein Land, muss die ID eines Gerätes bei jeder Anfrage erneut auf ihre Gültigkeit geprüft werden. Dies kann je nach Art der Identität auf verschiedene Arten erfolgen. Zum Beispiel kann bei Verwendung von digitalen Zertifikaten den enthaltenen Informationen vertraut werden, wenn die Signatur des Zertifikats durch eine vertrauenswürdige Zertifizierungsstelle erzeugt wurde.

Darüber hinaus ist die Gültigkeitsdauer der Identität ein weiterer wichtiger Aspekt. Im realen Leben werden Ausweise in regelmäßigen Zeitabständen erneuert bzw. verlängert. Idealerweise geschieht dies für Geräte in ähnlicher Form. Die notwendigen Abläufe zur erneuten Ausstellung der Geräteidentität sollten daher gleich gemeinsam mit dem Prozess der initialen Identitätsvergabe entworfen und umgesetzt werden.

Es kann über die gesamte Laufzeit eines IoT-Gerätes nicht ausgeschlossen werden, dass an der ein oder anderen Stelle ein Fehlverhalten auftritt. Ziel ist es, diese Situationen zuverlässig und schnellstmöglich zu erkennen. Geeignete Mechanismen sollten sowohl im Gerät als auch in den Backendsystemen etabliert sein, um die fehlerfreie Funktionsweise eines Gerätes überprüfen zu können. Wird ein Fehlverhalten detektiert, kann das Problem in vielen Fällen durch ein Firmware-Update behoben werden. Daher ist es empfehlenswert, mit dem ersten Release zuverlässige Software-Update-Prozesse umzusetzen, um bereits beim Rollout des ersten Gerätes reaktionsfähig zu sein. Sollte sich ein Fehlverhalten nicht durch ein Update beseitigen lassen, kann dies das Ende des Lebenszyklus für ein Gerät bedeuten. In diesem Fall ist es wichtig, die Identität des betroffenen Gerätes zu invalidieren und aus dem Geräteinventar zu entfernen. Dadurch kann verhindert werden, dass das Gerät unerwünscht ein Schattendasein führt oder dessen Identität sogar böswillig von einem Angreifer übernommen wird.

In jedem der beschriebenen Prozesse und Lebensphasen eines IoT-Gerätes spielt dessen eindeutige und vertrauenswürdige Identität eine zentrale Rolle. Alle Abläufe in Zusammenhang mit der Geräteidentität müssen daher mit Fokus auf Sicherheit, Integrität und Zuverlässigkeit sorgfältig entworfen werden. Als begleitendes Instrument hierfür bietet sich das Thread Modelling an, welches in den nachfolgenden Abschnitten näher erläutert wird.

Wie kann ich mögliche Bedrohungen analysieren?

Zur Erkennung und Modellierung von Bedrohungen haben sich im Laufe der Zeit unterschiedliche Ansätze etabliert. In diesem Artikel stellen wir folgende Verfahren vor, die sich im Bereich IoT besonders bewährt haben:

  • CIA – Grundlegende Ziele der Informationssicherheit
  • STRIDE – Modellierung von Bedrohungen
  • Attack Trees – Modellierung der Kausalketten von Bedrohungen und deren Auswirkungen

Das höchste Gut eines Unternehmens und somit auch das Hauptziel von Angreifern sind Daten. Dies ist auf den ersten Blick nicht sofort ersichtlich, erzeugt doch beispielsweise die Industrie oder das verarbeitende Gewerbe zumeist materielle Produkte. Doch ohne die zugrundeliegenden Daten in den Rezepturen, den Materialstücklisten und den Verfahrensprozessen – um nur einige zu nennen – geht heutzutage eben nichts mehr.

Augenscheinlicher wird die Notwendigkeit von Daten bei Unternehmen, deren Zweck auf der Verarbeitung von Daten beruht. Angefangen von Banken und deren Geldflüssen, über Internetunternehmen und deren Benutzerdaten, bis hin zur digitalen Steuererklärung sind Unternehmen an der Verarbeitung von sensiblen, personenbezogenen Daten, aber auch Geschäftsgeheimnissen und Forschungsergebnissen beteiligt.

Für die ständig wachsende Datenflut sind auch smarte Geräte aus dem Internet der Dinge maßgeblich mitverantwortlich. Von der intelligenten Lampe bis hin zu wettergestützen Belüftungs- oder Bewässerungssystemen, erzeugen und konsumieren die Geräte Daten, die u.a. auf die Verhaltensweisen und Gewohnheiten der Nutzer schließen lassen.

Da Daten die zentrale Rolle in der Sicherheitsbetrachtung spielen, stehen diese selbstverständlich im Mittelpunkt der CIA, der fundamentalen Triade zur Sicherheit in der Informationstechnologie.

CIA ist ein Akronym für die Themen Confidentiality (Vertraulichkeit, Geheimhaltung), Integrity (Datenschutz, Datenintegrität) und Availability (Verfügbarkeit für Berechtigte).

Um diese essentiellen Themen drehen sich die Verfahren zur Modellierung von Bedrohungen.

Auch so im ersten Modell, dem STRIDE. Dieses Verfahren wird verwendet, um Bedrohungen zu modellieren und hilft, diese zu erkennen und deren Ursachen zu ergründen. Auch der Begriff "STRIDE" ist ein Akronym, es steht für die folgenden Betrachtungsschwerpunkte:

Der Begriff Spoofing beschreibt, worum es bei einem derartigen Angriff geht: das Täuschen, das Hereinlegen, kurz: jemandem weiszumachen, man wäre jemand anderes, um sich unberechtigterweise Vorteile zu verschaffen. Im Kontext von IoT-Geräten könnte dies beispielweise bedeuten, das Gerät in ein kompromittiertes WLAN-Netzwerk zu locken, um dessen Kommunikation mit Cloud Services zu verändern oder "mitzuhören".

Der Angriffsvektor Tampering beschäftigt sich grundsätzlich mit dem Thema Sabotage. Es geht hierbei darum, einen Schaden auf Basis einer Manipulation herbeizuführen. IoT-Geräten könnte beispielsweise eine veränderte Firmware aufgespielt werden, um diese in einem Botnetzwerk für verteilte Angriffe (DDoS) einzusetzen. Des Weiteren könnten einem Gerät gefälschte Daten zugeführt werden, um damit dessen Verhalten zu beeinflussen.

Wenn ein Angreifer möglichst unauffällig und über einen langen Zeitraum operieren möchte, ist es für diesen wichtig, seine Spuren zu verwischen. Bei der Repudiation, zu Deutsch Leugnung, geht es darum, dass getätigte Aktionen nicht auditiert werden, also nicht dokumentiert und somit nicht nachverfolgbar sind.

Eine der wohl bekanntesten Angriffsformen behandelt das Thema Information Disclosure oder auch Datenschutz. Es vergeht kaum eine Woche, in der nicht in den Medien Nachrichten über Datendiebstahl gemeldet werden. Diese Bedrohung stellt sich bei IoT-Geräten auf verschiedene Weisen dar. Hier geht es beispielsweise um unverschlüsselte WLAN-Passwörter auf dem Flashspeicher, ungesicherte Zertifikate, "verräterische" Geräteaktivitäten, etc.

Wie beim Tampering bereits erläutert, könnte ein IoT-Gerät mit einer kompromittierten Firmware plötzlich Teil eines Botnetzwerks werden und an einer DDoS-Attacke (Distributed Denial of Service) teilnehmen. Andererseits könnte aber auch das IoT-Gateway der IoT-Plattform selbst Attacken ausgesetzt sein und somit könnten sich die echten Geräte nicht mehr mit den Cloud Services verbinden.

Der letzte Buchstabe in STRIDE ("E") beschäftigt sich damit, dass ein Angreifer bei seinem Zugriff mehr Rechte erhält, als ihm eigentlich zustehen würden. So kann es beispielsweise sein, dass der Angreifer Geräte eines anderen Benutzers steuern könnte. Beim Elevation of Privilege werden diese Bedrohungen betrachtet.

Die aus dem STRIDE-Modell bekannten Ansatzpunkte lassen sich nun gut in den Attack Trees verwenden. Diese eröffnen durch die Abbildung kausaler Zusammenhänge eine logische und nachvollziehbare Betrachtungsweise. Des Weiteren treten dadurch meist weitere Bedrohungen zutage, da logische Ketten und Abfolgen für uns Menschen leichter fortzusetzen sind als isolierte abstrakte Themen.

Das Diagramm rechts stellt das Schema des Attack Trees vor, welches im weiteren Verlauf an einem Beispiel angewendet wird, um mögliche Bedrohungen zu modellieren und geeignete Gegenmaßnahmen aufzuzeigen. Der Fokus liegt dabei auf der Anwendung der Methoden und nicht auf der Vollständigkeit der Betrachtungen, kurz: es gibt noch weitere Bedrohungen, hier nur ein Ausschnitt.

Was habe ich zu befürchten und wie kann ich es vorher erkennen?

Im Folgenden beschäftigen wir uns nun mit einem Beispiel, um die in den vorherigen Abschnitten theoretisch beschriebenen Themen konkret anzuwenden. Ausgangspunkt ist hier der "Attack Tree" (siehe Abb. 5), mit dessen Hilfe wir die Zusammenhänge und Abhängigkeiten ausgehend von einem initialen Sicherheitsproblem beleuchten.

Nehmen wir nun wie in B1 an, der Flashspeicher unseres IoT-Gerätes wäre nicht gegen das Auslesen geschützt, falls der Angreifer physischen Zugriff darauf hätte. Hier bestünde nun die Gefahr, dass der Angreifer die Daten des Flashspeichers auslesen oder diese verändern könnte. Ein Auslesen der Firmware (siehe B5) hätte zur Folge, dass das IoT-Gerät vervielfacht werden und somit die Integrität des ursprünglichen Gerätes Schaden nehmen könnte. Eine detaillierte Beschreibung werden wir nun im Folgenden für das Bedrohungsszenario B2 darstellen:

Bedrohungsszenario B2

Es besteht die Gefahr, dass sensible Daten – in diesem Fall die WLAN-Zugangsdaten – vom Angreifer ausgelesen werden können.

Ursache

Das Sicherheitsrisiko besteht, weil über den Mini-USB-Anschluss auf den Flash-Speicher zugegriffen werden kann. Dieser versorgt das Gerät nicht nur mit Strom, über diesen ist es außerdem möglich, die Firmware zu flashen und auszulesen, sowie serielle Kommandos an das Gerät zu schicken.

Bewertung der Risiken

  • Tragweite
    Das Risiko ist als Einzelgeräterisiko einzustufen, weil für einen solchen Angriff immer der physische Zugriff auf das Gerät und die Kommunikationsschnittstelle notwendig ist. Aus der Ferne lässt sich diese Sicherheitslücke nicht ausnutzen. Der Angreifer müsste also zuerst immer in den physischen Besitz eines Gerätes kommen.
  • Schadenspotential
    Der potentielle Schaden hierbei wäre, dass der Angreifer Zugriff auf das WLAN-Netzwerk des Benutzers hätte und hier unterschiedliche weiterführende Angriffe tätigen könnte. Dies würde sich jedoch nicht negativ auf den weiteren Betrieb von Geräten anderer Nutzer auswirken.
    Fazit: Schaden für Einzelnutzer wäre hoch, ein Risiko für die anderen Geräte besteht jedoch nicht.
  • Reproduzierbarkeit:
    Der Angriff könnte beliebig oft bei allen Geräten derselben Baureihe ausgeführt werden.
  • Erkennbarkeit:
    In der Vergangenheit gab es immer wieder derartige Angriffe und diese Schwachstelle könnte auch von Nicht-IT-Spezialisten entdeckt und ausgenutzt werden.

Risikomanagement

Auf folgende Weise könnte mit den bestehenden Risiken umgegangen werden:

  • Eliminieren
    Die ideale Lösung ist selbstverständlich die Ursache der Schwachstelle zu eliminieren und das Problem damit erst gar nicht entstehen zu lassen.
  • Abschwächen/Mildern
    Das Problem könnte abgeschwächt werden, indem man dessen Auswirkungen eingrenzt und den Schaden somit kontrollierbar macht.
  • Übertragen/Ersetzen
    Möglicherweise können kritische Komponenten ausgelagert und das Risiko somit verschoben und reduziert werden.
  • Akzeptieren
    Falls es keine Gegenmaßnahmen gibt bzw. diese in keinem Verhältnis zum potentiellen Schaden stehen, könnte man das Risiko akzeptieren.

Gegenmaßnahmen

In dem genannten Beispiel wäre eine der beiden Eliminierungsmöglichkeiten möglich:

  • Verschlüsselung der WLAN-Zugangsdaten
    Solange die sensiblen Daten im Flashspeicher des Gerätes persistiert werden sollen und dieser ausgelesen werden kann, sollten die Daten verschlüsselt abgelegt werden.
  • Speichern der WLAN-Zugangsdaten in Sicherheitschips
    Eine weitere Möglichkeit wäre, die sensiblen Daten nicht im Flashspeicher sondern in einem dedizierten Sicherheitschip zu speichern, der keinen externen Zugriff erlaubt und nur programmatisch angesprochen werden kann.

Für welche Maßnahmen sollte ich mich entscheiden?

Grundsätzlich ist es eine Ermessensentscheidung, welche Maßnahmen ergriffen werden, sprich: wie groß ist der potentielle Schaden und was müsste investiert werden, um die Sicherheitslücke zu schließen. Dabei spielt es letztlich eine Rolle, wie hoch die Wahrscheinlichkeit des Entdeckens bewertet wird und wie wahrscheinlich es sein wird, dass diese Sicherheitslücke auch wirklich ausgenutzt wird.

Auch ein Angreifer macht die Rechnung für sich: wo kann ich mit möglichst wenig Aufwand einen möglichst hohen Schaden anrichten.

Sie sollten Schutzmaßnahmen einsetzen, die nicht mit anderen Schutzmaßnahmen korreliert sind. Das bedeutet: Wenn eine Maßnahme fällt, sollten andere unabhängig davon weiter funktionieren. In einem Brandfall können beispielsweise alle Türen eines Gebäudes entriegelt werden um die Flucht aus dem Gebäude zu erlauben. Ein Zutritt zum Gebäude für Unbefugte sollte jedoch weiterhin nicht möglich sein, also werden die Türen auch nur von innen entriegelt.

Wie kann Sicherheitsproblemen vorgebeugt werden?

Die beste Vorgehensweise ist, sich schon in einer frühen Phase der Entwicklung konkret Gedanken zu machen. Basierend auf der Lösungsarchitektur sollten Reviews mit Fokus auf Sicherheitsaspekte mit Spezialisten aus den Domänen Architektur, Entwicklung und Betrieb durchgeführt werden. Zudem ist ein Hinzuziehen externer Spezialisten ratsam, da sich diese unabhängig und mit spezifischen Ansätzen einbringen können.

Während der Konzeptions- und der Implementierungsphase sollte man sich an fundamentalen Prinzipien orientieren, wie beispielsweise (Auszug):

  • Principle of Least Privilege – ein Benutzer sollte nur so viele Rechte haben, wie er unbedingt für die Erfüllung einer Aufgabe benötigt.
  • Principle of Fail-Safe Defaults – solange ein Benutzer keinen expliziten Zugriff auf ein Objekt hat, sollte der Zugriff verweigert werden.
  • Principle of Open Design – nutzen sie offene und damit verbreitete und vielfach validierte Sicherheitsstandards.
  • Principle of Separation of Privilege – der Zugriff auf das System sollte von mehreren Bedingungen abhängen, beispielsweise dürfen nur Benutzer zugreifen, die authentifiziert und über Rollenzugehörigkeit berechtigt sind.

Im Laufe des Entwicklungsprozesses sollte konsequent und automatisiert getestet werden, und dies mit einem besonderen Augenmerk auf die "unhappy" Flows, sprich: wo könnte ein Problem entstehen, falls es nicht so läuft wie im Idealfall definiert, und wie ist das System darauf vorbereitet? Oft liegen die Fehler in Details der Schnittstellendefinitionen und deren Autorisierungsmechanismen oder es besteht die Möglichkeit, dass manipulierte Daten induziert werden, die mit einer einfachen Wertebereichsprüfung entdeckt worden wären.

Mit dem Beginn des produktiven Einsatzes einzelner Komponenten oder Systeme ist die Arbeit jedoch nicht getan. Daher sollte es kontinuierliche Prüfungen der Sicherheitsmechanismen geben und gezielt auf Hinweise geprüft werden. Fällt beispielsweise auf, dass einzelne Benutzer oder auch Geräte die Cloud-Services ungewöhnlich aktiv nutzen und dies nicht durch ein "normales" Verhalten zu erklären ist, könnte ein Sicherheitsproblem vorliegen.

Fazit

Bei der Planung eines IoT-Gerätes sollten sie selbstverständlich weiterhin mit dem Idealfall planen und den Kundennutzen in den Mittelpunkt stellen. Jedoch sollten sie auch für den Ernstfall vorbereitet sein, da dieser existenzielle Auswirkungen haben könnte.

Cybersecurity ist und bleibt ein wichtiges Thema sowohl in der Entwicklung als auch in der langfristigen Pflege von IoT-Geräten. Unternehmen sollten ihr Investment und ihre Ideen schützen und dabei Angreifern eine möglichst kleine Angriffsfläche geben. IT-Sicherheit muss zu einer Kernkompetenz in jedem Unternehmen werden, welches sich mit dem Internet of Things beschäftigt. Diese kann neben den "normalen" Produktfeatures auch zum entscheidenden Wettbewerbsvorteil gegenüber der Konkurrenz werden, in einer zunehmend durch virtuelle Angriffe betroffenen Welt.

Zusammenfassend kann man sagen, dass IT-Sicherheit ein essenzieller Teil der Produkt- bzw. Lösungskonzeption sein sollte, auch wenn es im ersten Moment zusätzlichen Aufwand bedeutet. Es ist jedoch ein entscheidender Faktor für den Erfolg und bedarf frühzeitiger Planung. Da das Schließen einer Sicherheitslücke aufgrund der steigenden Systemkomplexität über die Zeit immer aufwendiger werden kann, darf es nicht wie ein Feature behandelt werden, welches man ausliefert, sobald es gebraucht wird. Denn dann kann es bereits zu spät sein!

Autoren

Dr. Florian Rappl

Dr. Florian Rappl ist Solution Architect bei der smapiot GmbH mit Einsatzgebiet digitale Transformation. Als Microsoft MVP für Entwicklungstools befasst er sich mit Themen wie C#/.NET, TypeScript, sowie skalierbaren Backend- und…
>> Weiterlesen

Lothar Schöttner

Lothar Schöttner ist Gründer und Geschäftsführer der smapiot GmbH. Neben der Entwicklung eigener Lösungen von smapiot ist er im Rahmen von Beratungsprojekten hauptsächlich als Solution Architect in den Bereichen IoT und Identity…
>> Weiterlesen

Jens Thirmeyer

Jens Thirmeyer ist Solution Architect bei der smapiot GmbH und konzipiert Lösungen in den Themenbereichen IoT, Cloud und Identity & Access Management.
>> Weiterlesen
Das könnte Sie auch interessieren
Kommentare (0)

Neuen Kommentar schreiben