Über unsMediaKontaktImpressum
Paul Arndt 10. Januar 2017

Systematische Bewertung der Cybersecurity-Risiken von eingebetteten Systemen

Eingebettete Systeme werden immer stärker mit ihrer Umwelt vernetzt. Dieser Trend gipfelt in dem, was als IoT (Internet of Things) bezeichnet wird. Wesentliche Besonderheit von Systemen, die im IoT-Kontext entwickelt werden, sind die vielfältigen Kommunikationsschnittstellen zur verteilten Kommunikation (z. B. BLE, LoRA, ZigBee), die eine Interaktion mit der Umwelt ermöglichen. Hieraus ergeben sich neue Wege, auf ein solches System zugreifen zu können; insbesondere von Personen oder Systemen, die dazu nicht berechtigt sind. Die Beschäftigung mit dem Schutz eines Systems und den darin verarbeiteten Daten ist Inhalt der Cybersecurity. Die Auswahl von geeigneten Maßnahmen, um ein System zu schützen, bedarf einer fundierten Analyse des Systems und der darauf einwirkenden Gefährdungen. Dieser Artikel stellt eine kompakte und erprobte Vorgehensweise für eine solche Analyse vor.

In der Regel werden bei der Entwicklung eines komplexen technischen Systems unterschiedliche Ziele berücksichtigt und umgesetzt. Typischerweise werden auch viele nötige Maßnahmen zum Schutz des Systems vor Cybersecurity-Risiken umgesetzt. Ohne eine systematische Analyse stellt sich früher oder später jedoch die Frage, ob die umgesetzten Maßnahmen ausreichen oder überhaupt die richtigen Maßnahmen getroffen wurden. Genau hier setzt die vorgestellte Vorgehensweise an, die mit überschaubarem Aufwand nachvollziehbare Ergebnisse liefert. Grundlage waren dabei das Wissen aus bewährten Standards wie der ISO 27000-Serie und den NIST 800 Special Publications. Auf Basis der Ergebnisse einer solchen Analyse kann dann, wenn nötig, eine tiefergehende und in der Regel erheblich aufwändigere Analyse durchgeführt werden.

Konkret ist das Ziel der vorgestellten Methode die Identifikation von Cybersecurity-Risiken eingebetteter Systeme und die Definition von Gegenmaßnahmen zur Reduktion dieser Risiken. Risiken sind definiert als Auftretenswahrscheinlichkeit x Auswirkung und werden durch eine übliche Risikomatrix quantifiziert. Diese legt jeweils 5 Stufen für Risiko und Wahrscheinlichkeit fest. Die unterste Stufe entspricht dabei einer quasi unmöglichen Wahrscheinlichkeit, bzw. einem minimalen Schaden. Die oberste Stufe entspricht einem Ereignis, das ständig wiederkehrend auftritt bzw. einem für die jeweils verantwortliche Organisation existenzbedrohenden Schaden (s. Abb. 1).

Die tatsächlichen Werte müssen vor der Durchführung eines Assessments für die jeweilige Organisation festgelegt werden. Bevor eine Analyse durchgeführt werden kann, sollten die Grenzen der Analyse und die Rahmenbedingungen, unter denen das zu analysierende System betrachtet wird, definiert und dokumentiert werden. Auch eine Festlegung der zu akzeptierenden bzw. der gewünschten Risiko-Zielwerte sollte vor der eigentlichen Analyse erfolgen.

Im ersten Schritt der Risikoanalyse müssen die Assets identifiziert werden, d. h. es muss festgelegt werden, was es zu schützen gilt. Typischerweise ist die eigentliche Funktion bzw. Aufgabe des Systems eines der zu schützenden Assets. Aufgabe einer Kaffeemaschine ist es zum Beispiel, in erster Linie Kaffee herzustellen. Eine Störung dieser Funktion durch Einflüsse von außen soll in gewissen Grenzen verhindert werden. Insbesondere sollen in der Regel bewusste Störungen verhindert werden. Weitere typische Assets sind alle Formen von Daten. Also sowohl Daten, die bereits bei der Auslieferung des Geräts existieren, meist vor allem die Software, als auch alle Daten die beim Betrieb entstehen. Letztere kann man häufig in personen- und nichtpersonenbezogene Daten trennen. Des Weiteren ist das neutrale Verhalten gegenüber anderen Geräten, mit denen das Gerät in Interaktion treten kann, typischerweise ein Asset. Die Identifikation von Assets kann auf der Grundlage von Use-Cases bzw. Prozessen und Dokumentationsunterlagen erfolgen.

Für die Assets müssen nun die Gefährdungen identifiziert werden, die diese bedrohen. Dies lässt sich sehr gut an einem alltäglichen Beispiel veranschaulichen. Als Assets wird der Besitz, der in den persönlichen Wohnräumen aufbewahrt wird, angenommen. Bedroht werden diese Assets z. B. dadurch, dass eine fremde Person in die Räumlichkeiten eindringen könnte und diese Assets entwendet. In der Regel erfolgt das Eindringen durch die Tür oder durch ein Fenster, theoretisch könnte es aber auch durch eine Wand erfolgen. Damit ergibt sich in diesem Fall die Gefährdung, dass jemand durch ein Fenster einbricht. Diese Gefährdung muss durch eine Schwachstelle ermöglicht werden. Fenster haben in vielen Fällen eine Schwachstelle gegenüber dem Einsatz von Werkzeugen, die als Hebel eingesetzt werden, um die Verriegelung aufzubrechen. Wände sind verwundbar gegenüber dem Einsatz von Abbruchwerkzeugen. Die Wahrscheinlichkeit dieser beiden Szenarien ist offensichtlich unterschiedlich. Sie kann über die Bewertung des zu erwartenden Schadens und die Wahrscheinlichkeit des Eintritts dieses Szenarios quantifiziert werden. Liegt der mit Hilfe der Risikomatrix bestimmte Wert über dem als zu akzeptierenden bzw. dem als gewünscht definierten Wert, müssen Maßnahmen zur Reduktion des Risikos zusammengestellt werden. Für die Absicherung eines Fensters ist eine realistische Maßnahme zum Beispiel die Installation eines Gitters oder der Einbau einer Alarmanlage (s. Abb. 2).

Fazit

Um eine möglichst vollständige Analyse zu erhalten, müssen für alle Assets die möglichen Threats und für diese alle möglichen Vulnerabilities betrachtet werden. Für den Bereich der Cybersecurity existieren hier einige Quellen, die als Ausgangsbasis verwendet werden können, so listet zum Beispiel die ISO/IEC 27005 in ihren Anhängen eine Sammlung von Threats und Vulnerabilities auf. Aus der Kombination von Assets, Threats und Vulnerabilities ergeben sich die konkreten Incident-Scenarios. Im obigen Falle zum Beispiel: Ein Einbrecher entwendet Wertsachen, indem er durch das Terrassenfenster einbricht, das er mithilfe eines Schraubenziehers aufhebelt. Gegenmaßnahmen können ebenfalls aus vorhandenen umfangreichen Katalogen entnommen werden, als Beispiele seien hier die ISO/IEC 27002 und die NIST SP 800-53 genannt.

Das Vorgehen kann in Zusammenarbeit von einem Experten für das zu betrachtende System, z. B. dem Systemarchitekten und einem Security-Experten, der die nötige "kriminelle Energie" mitbringt, umgesetzt werden. Praktische Erfahrungen haben gezeigt, dass bereits nach zwei bis drei Workshops ein sehr gutes Bild für recht umfängliche Systeme erzeugt werden kann.

Autor

Paul Arndt

Paul Arndt ist spezialisiert auf die Einführung und Optimierung von Entwicklungsprozessen, insbesondere in Projekten mit hohen Softwareanteilen. Einen besonderen Schwerpunkt bilden dabei die Methoden und Tools rund um das Thema...
>> Weiterlesen
botMessage_toctoc_comments_9210