Risikobewertungen für langfristigen IoT-Erfolg

IoT-Anwendungen kombinieren periphere Sensoren, Gateways und Cloud-Ressourcen und werden so zu beispiellosen Angriffszielen, da sie eine Vielzahl potenzieller Angriffsflächen und Sicherheitsschwachstellen bieten. Ein klares Verständnis solcher Bedrohungen, ihrer Wahrscheinlichkeit und ihrer Auswirkungen wird immer entscheidender, da Unternehmen diese Anwendungen immer enger in die Unternehmensinfrastrukturen einbinden. Mithilfe methodischer Ansätze für Bedrohungs- und Risikobewertungen können Entwicklungsteams die Sicherheit dort verbessern, wo es notwendig ist, oder fundierte Entscheidungen über akzeptable Risiken treffen.

In den Nachrichten wird nur allzu oft über das breite Spektrum der Sicherheitslücken in vernetzten Systemen berichtet. Schon ein kurzer Blick in die Schlagzeilen zeigt eine verblüffende Bandbreite von Angriffen: Sie reichen von offenen, massiven DDoS-Angriffen (Distributed Denial of Service) bis hin zu extrem verdeckten APTs (Advanced Persistent Threats), bei denen im Verborgenen wertvolle Daten abgegriffen oder noch extremere Angriffe vorbereitet werden.

Mit Modellen vor echten Cyberangriffe schützen

Auch wenn diese Angriffe aufsehenerregend sind, ist eine der wichtigsten Lehren daraus, dass der Einsatz von Sicherheitsmechanismen und die Schaffung eines sicheren Systems nicht dasselbe sind. Hacker dringen erfolgreich in Systeme ein, die mit allen möglichen Sicherheitsmechanismen ausgestattet sind. Selbst das sicherheitsbewussteste Entwicklungsteam kann unwissentlich offene Schwachstellen in seinem Design haben.

Aufgrund der enormen Komplexität heutiger Designs steigt die Wahrscheinlichkeit offener Schwachstellen, insbesondere bei mehrschichtigen, vernetzten Systemen wie IoT-Anwendungen. Wenn eine große Anzahl programmierbarer Geräte unterschiedlicher Art mit der Cloud verbunden ist, wird die End-to-End-Sicherheit eher zu einer statistischen Wahrscheinlichkeit als zu einer absoluten Gewissheit. Jedes Element in einem solchen vernetzten System von Systemen hat seine eigene Funktionalität und seine eigenen Schwachstellen im Hinblick auf die Gesamtsicherheit. Wenn sich ein Unternehmen ein umfassendes Bild davon macht, auf welche Weise jede einzelne Schwachstelle zu einer Bedrohung für die Gesamtanwendung werden könnte, kann es entscheiden, ob das Risiko eines erfolgreichen Ausnutzens dieser Schwachstelle die Akzeptanzschwelle überschreitet und letztendlich eine Abhilfemaßnahme erforderlich macht.

Ein derartiger Einblick in die Art des Risikos ist von unschätzbarem strategischem Wert. Gleichzeitig kann ein Entwicklungsteam durch die Verknüpfung von Sicherheitsschwachstellen mit Risikobewertungen eine taktische Roadmap für die Entwicklung einer praktischen Antwort auf die nahezu endlose Flut von Bedrohungen für jedes verbundene System erstellen. Ohne ein genaueres Verständnis der Bedrohungs- und Risikobewertungen setzt selbst das erfahrenste Entwicklungsteam die Sicherheit seiner Systeme und Anwendungen aufs Spiel. Voraussetzung für diese Erkenntnisse ist jedoch ein klares Verständnis der potenziellen Bedrohungen für ein System. Dies kann durch ein gut dokumentiertes Bedrohungsmodell erreicht werden.

Bedrohungsmodelle erfassen die spezifischen Sicherheitsschwachstellen des Systemdesigns. Die Erstellung eines Bedrohungsmodells scheint konzeptionell zunächst einfach: Entwickler analysieren beispielsweise ihre Designs, um Sicherheitsschwachstellen zu identifizieren, die mit jeder einzelnen Komponente verbunden sind. In der Praxis kann die Erstellung eines Bedrohungsmodells jedoch viel mehr Arbeit, Forschung und Strategie erfordern, als diese einfache Idee vermuten lässt. Ein solches Modell kann jedoch auch weit mehr als nur eine Liste von technischen Sicherheitsbedenken liefern. Bei einer breiteren Anwendung kann die Bedrohungsmodellierung auch Schwachstellen in den damit verbundenen Lebenszyklusprozessen und übergreifenden Sicherheitsrichtlinien aufzeigen, die mit einer IoT-Anwendung in Verbindung stehen. Letztendlich kann das, was akzeptable Bedrohungsmodelle kennzeichnet, so stark variieren wie die IoT-Anwendungen und Unternehmen, die sie einsetzen. Unterschiedliche Bedrohungsmodelle weisen bestimmte gemeinsame Merkmale auf und alle Methoden zur Bedrohungsmodellierung beruhen auf einigen gemeinsamen Schritten.

Ein derartiger Einblick in die Art des Risikos ist von unschätzbarem strategischem Wert. Gleichzeitig kann ein Entwicklungsteam durch die Verknüpfung von Sicherheitsschwachstellen mit Risikobewertungen eine taktische Roadmap für die Entwicklung einer praktischen Antwort auf die nahezu endlose Flut von Bedrohungen für jedes verbundene System erstellen. Ohne ein genaueres Verständnis der Bedrohungs- und Risikobewertungen setzt selbst das erfahrenste Entwicklungsteam die Sicherheit seiner Systeme und Anwendungen aufs Spiel. Voraussetzung für diese Erkenntnisse ist jedoch ein klares Verständnis der potenziellen Bedrohungen für ein System. Dies kann durch ein gut dokumentiertes Bedrohungsmodell erreicht werden.

Bedrohungsmodelle erfassen die spezifischen Sicherheitsschwachstellen des Systemdesigns. Die Erstellung eines Bedrohungsmodells scheint konzeptionell zunächst einfach: Entwickler analysieren beispielsweise ihre Designs, um Sicherheitsschwachstellen zu identifizieren, die mit jeder einzelnen Komponente verbunden sind. In der Praxis kann die Erstellung eines Bedrohungsmodells jedoch viel mehr Arbeit, Forschung und Strategie erfordern, als diese einfache Idee vermuten lässt. Ein solches Modell kann jedoch auch weit mehr als nur eine Liste von technischen Sicherheitsbedenken liefern. Bei einer breiteren Anwendung kann die Bedrohungsmodellierung auch Schwachstellen in den damit verbundenen Lebenszyklusprozessen und übergreifenden Sicherheitsrichtlinien aufzeigen, die mit einer IoT-Anwendung in Verbindung stehen. Letztendlich kann das, was akzeptable Bedrohungsmodelle kennzeichnet, so stark variieren wie die IoT-Anwendungen und Unternehmen, die sie einsetzen. Unterschiedliche Bedrohungsmodelle weisen bestimmte gemeinsame Merkmale auf und alle Methoden zur Bedrohungsmodellierung beruhen auf einigen gemeinsamen Schritten.

Die Modellierung von Bedrohungen beginnt mit einer genauen Beschreibung des Systems, dem so genannten Evaluationsgegenstand (EVG), der mit einem bestimmten Anwendungsfall verbunden ist, z. B. dem Betrieb eines Wasserzählers eines Versorgungsunternehmens. Bildlich gesprochen: Wenn ein Bedrohungsmodell das Bild der Systemschwachstellen zeichnet, dann ist die EVG-Beschreibung die Leinwand. Durch die Erweiterung oder Verengung des EVG-Bereichs kann ein Bedrohungsmodellierungsteam den Fokus in einem Prozess zur Identifizierung von Bedrohungen erweitern oder einschränken. So schränkt zum Beispiel das Bedrohungsmodell für intelligente Wasserzähler von Arm (2018) den EVG-Bereich stark ein und konzentriert sich nur auf den Kern des Systems.

Ein EVG, der auf eine einzige Teilmenge eines größeren, komplexeren Systems oder einer Anwendung beschränkt ist, bedeutet natürlich, dass die Fähigkeit zur Identifizierung von Bedrohungen, zur Risikobewertung und zur Erstellung eines wirksamen Plans zur Risikominderung eingeschränkt ist. Für ein komplexes System von Systemen wie eine IoT-Anwendung können erfahrene Bedrohungsmodellierer eine Reihe von Bedrohungsmodellen erstellen, die von einer recht abstrakten Beschreibung des Gesamtsystems bis hin zu immer detaillierteren Beschreibungen von Teilsystemen reichen, die für das Unternehmen von besonderer Bedeutung sind.

Unabhängig von der Herangehensweise ist für die Beschreibung des EVG keine absolute Anforderung an den Detaillierungsgrad erforderlich. Modellierungsansätze, die darauf abzielen, jede Komponente bis ins kleinste Detail zu beschreiben, können die Teilnehmer des Prozesses schlichtweg überfordern. Andererseits verbergen zu abstrakte Modelle wahrscheinlich verborgene Schwachstellen oder verhindern die Erkennung von Schwachstellen, die tief in einer Kette von Abhängigkeiten oder Softwarebibliotheken von Drittanbietern versteckt sind.

Ein guter Mittelweg besteht darin, einen fortschreitenden Detaillierungsgrad bis zu der Ebene zu erfassen, die erforderlich ist, um alle Interaktionen zu erfassen, die „Vertrauensgrenzen“ zwischen den einzelnen Bereichen eines Systems überschreiten. So kann eine IoT-Anwendung beispielsweise mehrere Bereiche umfassen, die mit Cloud-Ressourcen, Gateways, IoT-Endgeräten und Benutzern verbunden sind. Transaktionen, die über Vertrauensgrenzen hinweg durchgeführt werden, sind in besonderem Maße anfällig für eine Vielzahl von Angriffen auf übertragene Daten, Sicherheitsdaten oder Protokolle. Selbst scheinbar harmlose Versuche, über eine Vertrauensgrenze hinweg zu kommunizieren, können einen Weg für einen Fingerprinting-Angriff schaffen, bei dem Hacker bekannte Anhaltspunkte in der Systemantwort nutzen, um die zugrundeliegenden Komponenten des Systems zu ermitteln und gezieltere Angriffe vorzubereiten.

Hierbei ist es natürlich sehr wichtig, die Interaktionen zwischen den einzelnen Komponenten innerhalb eines Bereichs zu verstehen, insbesondere, wenn einige dieser Komponenten von Drittanbietern stammen. So könnte beispielsweise ein IoT-Gerät, das einen Sensortreiber eines Drittanbieters verwendet, für Bedrohungen an der Treiberschnittstelle anfällig sein.

Eine hinreichend detaillierte Beschreibung ist zwar für die Modellierung von Bedrohungen unerlässlich, aber die Identifizierung spezifischer Bedrohungen, die mit diesen Details in Verbindung stehen, ist der eigentliche Gewinn. Im Bedrohungsmodell für den Wasserzähler von Arm stellen die Modellierer eine einfache Liste von Bedrohungen zur Verfügung, die mit jedem einzelnen Asset verbunden sind, wie z. B. Firmware, Messdaten und Interaktionen mit externen Einheiten (Benutzer, Administratoren und Angreifer), die mit dem EVG in Verbindung kommen könnten.

Für Firmware beschreibt das Modell spezifische Bedrohungen, wie etwa die Installation kompromittierter Firmware, Änderungen der entsprechenden Sicherheitszertifikate, die zur Authentifizierung von Firmware-Updates verwendet werden, Klonen und andere. Auf der Grundlage der aufgeführten Assets und der identifizierten Schwachstellen können die Entwicklungsteams entsprechende Sicherheitsziele und Gegenmaßnahmen entwickeln. Das Modell des Wasserzählers von Arm beispielsweise enthält eine ganze Reihe von Sicherheitsanforderungen, auch für die Firmware, wie z. B. die Notwendigkeit eines sicheren Bootvorgangs, einer Firmware-Authentifizierung, einer Reaktion auf eine fehlgeschlagene Authentifizierung und andere.

Bei der Erkennung potentieller Bedrohungen können nur wenige Entwicklerunternehmen über alle möglichen Bedrohungen auf dem Laufenden bleiben, die sich auf die in ihren EVG-Beschreibungen enthaltenen detaillierten Assets und Prozesse beziehen könnten. Die gute Nachricht ist, dass Entwickler mehrere öffentliche Quellen finden können, die sie bei diesem Teil des Prozesses unterstützen. Die Entwickler können öffentliche Ressourcen wie die CAPEC-Liste (Common Attack Pattern Enumeration and Classification) nutzen, um die wahrscheinlichsten Angriffsarten von oben nach unten zu überprüfen. Dann können sie von unten nach oben arbeiten, um die wahrscheinlichen Angriffsziele zu identifizieren, die in der Common Weakness Enumeration (CWE)-Liste aufgeführt sind. Diese Liste beschreibt inhärente Schwachstellen in Systemdesign-Ansätzen, wie z. B. die Verwendung von hartkodierten Anmeldedaten. Wenn Entwickler bestimmte Hardware- oder Softwarekomponenten erkennen, die in ihren Designs verwendet werden, können sie auf die CVE-Liste (Common Vulnerabilities and Exposures – Gemeinsame Schwachstellen und Gefährdungen) zurückgreifen, in der spezifische Softwarefehler oder potenzielle Schwachstellen in verfügbaren Hardware- oder Softwarekomponenten aufgeführt sind.

Für Risikobewertungen bieten Ressourcen wie das Common Vulnerability Scoring System (CVSS) einen einheitlichen Ansatz zur Bewertung der mit bestimmten Schwachstellen verbundenen Risiken. Ein Risiko bezieht sich zwar auf die Art einer bestimmten Schwachstelle, umfasst aber auch andere Faktoren wie den Weg (Vektor), der zur Durchführung des Angriffs verwendet wird, die Komplexität des Angriffs, der zur Ausnutzung der Schwachstelle erforderlich ist, und andere. So birgt beispielsweise ein Angriff, der über ein Netzwerk durchgeführt werden kann, ein wesentlich höheres Risiko als ein Angriff, der physischen Zugang erfordert. Ebenso birgt ein einfach durchzuführender Angriff ein deutlich höheres Risiko als ein hochkomplexer Angriff. Mit Hilfe eines CVSS-Rechners können Entwickler diese verschiedenen Faktoren schnell berücksichtigen und einen numerischen Wert für das mit einer bestimmten Bedrohung oder Klasse von Bedrohungen verbundene Risiko ermitteln. Für den Wasserzähler von Arm stellt der CVSS-Rechner fest, dass die Kombination der Faktoren, die zu einem Firmware-Angriff führen, einem kritischen Risikowert von 9,0 entspricht.

Aufgrund des breiten Spektrums an Anforderungen und Techniken gibt es automatisierte Tools wie das Threat Dragon Project des Open Web Application Security Project (OWASP), SeaSponge von Mozilla und das Threat Modeling Tool von Microsoft, die Entwickler bei der Modellierung unterstützen. Jedes dieser Tools arbeitet mit einer anderen Methode der Bedrohungsmodellierung, die von der Erstellung eines Systemdiagramms im Threat Dragon Project und SeaSponge bis hin zu Microsofts detailliertem STRIDE-Ansatz (übersetzt als Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service und Elevation of Privilege) reicht. Diese Tools sind zwar schon einige Jahre alt und wurden ursprünglich für Unternehmenssoftwaresysteme entwickelt, aber die Bedrohungsmodellierung ist ein breit anwendbarer, immer wiederkehrender Prozess, der mehr von den aktuellen Listen der Angriffsvektoren, Schwachstellen und Anfälligkeiten abhängt als von spezifischen Methoden. Mittlerweile gibt es jedoch neuere Tools, die eine engere Verbindung zwischen einer Systembeschreibung und der Identifizierung von Bedrohungen versprechen. Trotz des raschen Aufkommens von Deep-Learning-Technologien in anderen Bereichen bestehen nach wie vor erhebliche Herausforderungen bei der Anwendung dieser Technologien auf automatische Bedrohungs- und Risikobewertungen. Es ist jedoch davon auszugehen, dass intelligente Modellierungs- und Bewertungstools schon bald zur Verfügung stehen werden.

Bis dahin können Entwickler auf verschiedene Datensammlungen zurückgreifen, in denen Sicherheitsschwachstellen, Verwundbarkeiten und Angriffsmuster aufgelistet sind. Diese Vielzahl an Details kann insbesondere für diejenigen erdrückend wirken, die gerade erst mit der Modellierung von Bedrohungen beginnen. Eine der häufigsten Ausreden, um die Bedrohungsmodellierung zu vermeiden, ist das Argument, sie sei einfach zu kompliziert. Anstatt sich in die Tiefe der Details zu stürzen, können Entwickler mit einem bescheideneren Ansatz beginnen, der sich nur auf die häufigsten Bedrohungen konzentriert. Die OWASP-Liste der Top-10-IoT-Sicherheitsbedrohungen liefert einen sinnvollen Ansatzpunkt. Entwickler müssen nur auf ihre bevorzugten News-Seiten gehen, um einen fertigen Katalog der wichtigsten Schwachstellen und Exploits zu finden.

Für Unternehmen mit der Fähigkeit, schnell über die Grundlagen hinauszugehen, können sich die gleichen Methoden bei der Behandlung von ebenso kritischen Aspekten des IoT-Designs als unschätzbar wertvoll erweisen. Systeme, die in der Maschinensteuerung eingesetzt werden, unterliegen in der Regel den damit verbundenen kritischen Anforderungen an die funktionale Sicherheit. Bei diesen Systemen sind Sicherheit und funktionale Sicherheit so eng miteinander verwoben, dass geeignete Bedrohungsmodelle für diese Systeme wahrscheinlich Szenarien umfassen müssen, in denen Sicherheits- oder Betriebssicherheitsschwächen gleichermaßen zu physischen Risiken führen können. In ähnlicher Weise überschneiden sich Sicherheit und Datenschutz in vielerlei Hinsicht. Dennoch können Schwächen in beiden Bereichen zum gleichen Ergebnis führen, nämlich zur Offenlegung personenbezogener Daten. (prm)