ESE Fachwissen
WannaCry or WannaAct?
Autoren: Daniel Angermeier, Alexander Nieding, Jörn Eichler, Fraunhofer-Institut für Angewandte und Integrierte Sicherheit (AISEC)
Beitrag - Embedded Software Engineering Kongress 2017
Dass eingebettete Systeme zunehmend vernetzt sind und oftmals ungehärtet in diese Situation gelangen, ist als "Internet of Shitty Things" wohlbekannt. Ebenso, dass der Entwurf einer Lösung ein angemessenes Problemverständnis voraussetzt. Wer sich jedoch bei der Entwicklung eingebetteter Systeme dieses Problemverständnis mittels einer Analyse der Angriffsrisiken verschaffen möchte, landet schnell in einer scheinbar endlosen Breiten- wie Tiefensuche nach möglichen Angriffsvektoren und unfruchtbaren Diskussion um Angriffswahrscheinlichkeiten und -auswirkungen. Im Folgenden diskutieren wir zentrale Herausforderungen und geben Hilfestellungen für die effektive Identifikation und Abschätzung relevanter Angriffsrisiken.
Im Folgenden stellen wir zunächst kurz die Rolle der Security-Risikoanalyse im Entwicklungsprozess vor und beschreiben den typischen Ablauf einer solchen Analyse. Im Anschluss beschreiben wir typische Probleme und deren Ursachen bei der Durchführung und stellen abschließend Lösungsansätze vor.
Risikoanalyse: kurz eingeführt & im Entwicklungsprozess verankert
Um im Entwicklungsprozess Security-Risiken behandeln zu können, müssen diese zunächst erkannt und bewertet werden. Hierbei verhindert ein methodisches und idealerweise toolgestütztes Vorgehen leicht vermeidbare Fehler, die bei späterer Entdeckung nur mit hohem Aufwand zu beheben sind. Wie immer wird jedoch Praxiserfahrung benötigt, um Methoden erfolgreich anwenden zu können. Im Folgenden zeigen wir einige Fallstricke und Herausforderungen, die bei der Anwendung von Risikoanalysemethoden in der Praxis auftreten. Wir zeigen dabei nicht "den richtigen Ansatz" für die Analyse von Angriffsrisiken, sondern vermitteln ein Verständnis, warum viele Risikoanalysen als unproduktiv wahrgenommen bzw. gelebt werden. Lösungsansätze werden mit ihren Vor- und Nachteilen vorgestellt, die in die eigene Arbeit übernommen werden können.
Typischer Ablauf einer Risikoanalyse für eingebettete Systeme
Der typische Ablauf einer Analyse umfasst die folgenden Aktivitäten [1] [2], wobei je nach gewählter Methode die Reihenfolge und Ausprägung variieren kann:
- Informationen über den Untersuchungsgegenstand vereinheitlichen:
Hierbei werden zur Vorbereitung der Risikoanalyse verfügbare Informationen zusammengetragen, vereinfacht und in einheitlicher Form dokumentiert. Dabei wird der Untersuchungsgegenstand klar von seiner Umgebung abgegrenzt. Übliche Techniken sind dabei Interviews und das Sichten von Dokumenten. - Bedrohungen identifizieren:
Der Analyst ermittelt mögliche Bedrohungen gegen den Untersuchungsgegenstand. Grundlage hierfür sind sowohl die Architektur und Technologieaspekte des Untersuchungsgegenstands als auch Angreifermodelle. - Schäden und Eintrittswahrscheinlichkeiten abschätzen:
Die ermittelten Bedrohungen werden hinsichtlich der durch sie verursachten Schäden und hinsichtlich ihrer Eintrittswahrscheinlichkeiten abgeschätzt. Als Grundlage der Schadensabschätzung dient häufig eine Festlegung des Schutzbedarfs, die direkt an die Modellierung des Untersuchungsgegenstands anschließt und unabhängig von den identifizierten Bedrohungen erfolgt [3]. Diese formuliert Schutzziele auf den Werten des Untersuchungsgegenstands und Schäden bei deren Verletzung. - Risiken bewerten:
Auf Basis der abgeschätzten Bedrohungen und den erwarteten Schäden werden mögliche Risiken für den Untersuchungsgegenstand identifiziert und bewertet.
Häufige Probleme und ihre Ursachen
Im Folgenden stellen wir einige der gängigen Probleme bei der Durchführung von Risikoanalysen vor und ergründen deren Ursachen.
Systemverständnis:
Typischerweise stellt eine Security-Analyse eine interdisziplinäre Aktivität dar, da sowohl das Systemverständnis (Anwendungsdomäne) als auch Security-Fachwissen (Security-Domäne) erforderlich sind. Folglich kann für einen der Anwendungsdomäne fremden Security-Experten bereits die Einarbeitung in das zu untersuchende System mit einem hohen Aufwand verbunden sein. Zudem besteht die Gefahr, bei der Sichtung umfangreicher Dokumentation die Übersicht zu verlieren und in "Paralyse durch Analyse" [4] zu verfallen. Umgekehrt fällt es Entwicklern ohne tieferes Security-Fachwissen oft schwer, die relevanten Aspekte des Systems im Kontext der Security-Analyse zu identifizieren und die richtige Balance aus Präzision und Komplexitätsmanagement zu finden.
Systemmodellierung:
Die Notation zur Modellierung des Untersuchungsgegenstands stellt eine weitere Herausforderung dar. Die freie Modellierung erlaubt eine schnelle und unkomplizierte Darstellung des Untersuchungsgegenstands. Allerdings werden durch eine ungeklärte Notation das einheitliche Verständnis des Systems durch Dritte und die Qualität der darauf aufbauenden Risikoanalyse gefährdet. Im Gegensatz dazu ermöglichen Notationen mit formalem Unterbau eine eindeutige Interpretation und möglicherweise auch technische Auswertung, erhöhen aber den zeitlichen Aufwand für die Systemmodellierung. Die Variante, die vollständige Systemmodellierung aus der Entwicklung zu verwenden, scheitert oft an der hohen Detailtiefe und Komplexität des Modells, die zwar für die Systementwicklung nötig, aber für die Risikoanalyse häufig hinderlich sind. Eine weitere Herausforderung stellt somit die Wahl der richtigen Granularität der Modellierung dar, um einerseits keine Bedrohungen zu übersehen, andererseits aber auch die Komplexität handhabbar zu halten.
Betrachtung der Schäden:
Das Abschätzen von Schäden fällt oftmals schwer, da Schadensereignisse oft noch nicht bei der Organisation eingetreten sind und somit keine Erfahrungswerte vorliegen. Teilweise werden Schäden benannt, die vom oftmals schwer abschätzbaren Verhalten Dritter abhängen (Imageschaden, Absatzverlust …) und eher als indirekte Schäden auftreten, während der primäre Schaden nicht erfasst wird. Häufig werden Schäden auch nicht konkret benannt, sondern nur die Höhe abgeschätzt ("Integrität der Firmware: hoch"). Dies erschwert die Nachvollziehbarkeit der Analyse und führt zu uneinheitlichen Bewertungen. Schließlich fällt es oft schwer abzuschätzen, wie oft ein Schaden eintritt und wie der entsprechende Skalierungseffekt berücksichtigt werden kann.
Identifikation von Bedrohungen:
Zur Identifikation der Bedrohungen für das System muss der Analyst die Perspektive potenzieller Angreifer einnehmen. Hierfür ist ein tiefgreifendes Verständnis möglicher Angriffstechniken nötig. Gleichzeitig muss für die Anwendbarkeit dieser Techniken ein ausreichendes Systemverständnis vorhanden sein. Dabei sollten weder kreative Angriffswege noch übliche und bekannte Bedrohungen übersehen werden. Die Herausforderung besteht also darin, sowohl unkonventionell zu denken, als auch systematisch vorzugehen, um Bedrohungen zu identifizieren.
Abschätzung von Bedrohungen:
In der Regel sind kaum systematische und relevante Daten als Grundlage der Abschätzung der Eintrittswahrscheinlichkeit von Bedrohungen vorhanden. Die Ermittlung einer Wahrscheinlichkeit im mathematischen Sinne ist in der Regel nicht möglich, da kaum belastbaren Grundlagen existieren. Zudem sind häufige Änderungen der Abschätzungen durch "Entdeckungen" von Sicherheitsforschern zu erwarten, die neue oder vereinfachte Angriffstechniken aufzeigen.
Identifikation und Abschätzung der Wirkung von Maßnahmen gegen Bedrohungen:
Analog dazu müssen Maßnahmen modelliert und hinsichtlich ihrer risikodämpfenden Effekte abgeschätzt werden. Dabei stellt der Vergleich verschiedener Maßnahmengruppen zur Auswahl eines geeigneten Schutzkonzepts ein wiederkehrendes Problem dar, da für einen Vergleich häufig mehrere Analysen durchgeführt und konsistent gehalten werden müssen.
Lösungsansätze für eine effektive Analyse von Angriffsrisiken
Systemverständnis:
Um den interdisziplinären Aspekt zwischen Anwendungs- und Security-Domäne zu unterstützen, hat sich ein Vorgehen analog dem Grey-Box-Testing bewährt. Hierbei tritt der Security-Experte mit dem Domänenexperten in Dialog, führt Interviews durch und nutzt selektiv vorhandene Dokumentation, um sein Wissen zu vertiefen und das System im Kontext der Security-Analyse zu modellieren. Während der weiteren Durchführung der Analyse findet eine regelmäßige Synchronisation zwischen den Domänenexperten statt, um eine konsistente Systemmodellierung sicherzustellen.
Systemmodellierung:
Unserer Erfahrung nach ist eine geeignete, zumindest teilformalisierte Notation erforderlich. Beispielsweise bietet sich (gegebenenfalls vereinfachtes) UML als Notation an, da es über ausreichende Ausdrucksstärke verfügt und üblicherweise gut verstanden wird. Hierbei sollte die Modellierungstiefe eingangs nicht zu detailliert gewählt werden, sondern bedarfsgerecht im Laufe der Analyse verfeinert werden. Indikatoren hierfür sind z.B. Technologieübergänge oder Vertrauensgrenzen.
Betrachtung der Schäden:
Um die einheitliche Abschätzung von Schadenshöhen zu unterstützen, sollte organisationsweit ein domänenspezifischer Katalog von möglichst konkreten Primärschäden und deren Schadenshöhe erstellt werden. Die Zuordnung der Schäden zu verletzten Schutzzielen im Gegensatz zur direkten Abschätzung der Auswirkungen von Bedrohungen bietet zudem zwei weitere Vorteile: Einerseits wird der Schaden aus der Systemmodellierung heraus nachvollziehbar, andererseits wird hierdurch auch die Konsistenz verschiedener Schadensabschätzungen verbessert.
Identifikation und Abschätzung von Bedrohungen:
Während das kreative Erkennen möglicher Angriffswege Erfahrung durch den Analysten erfordert, kann die systematische Erkennung typischer Angriffe erneut algorithmisch und katalogbasiert unterstützt werden. Hierfür ist es besonders nützlich, wenn das Systemmodell unter Verwendung einer geeigneten Notation Technologieinformationen enthält, auf die seitens der Bedrohungen Bezug genommen werden kann. Um die Abschätzung der Eintrittswahrscheinlichkeiten oder Häufigkeiten von Bedrohungen zu unterstützen, sollte ein Katalog Vorbewertungen durch Security-Experten als Grundlage der Abschätzung in der konkreten Analyse enthalten.
Identifikation und Abschätzung der Wirkung von Maßnahmen gegen Bedrohungen:
Maßnahmen sollten analog zu den Bedrohungen katalogisiert und vorbewertet werden. Bei der Auswahl einer Risikoanalysemethode empfiehlt es sich darauf zu achten, dass Maßnahmen und ihre Auswirkungen auf das System flexibel berücksichtigt werden können.
Fazit
Systematisches und idealerweise werkzeuggestütztes Vorgehen in der Risikoanalyse erleichtert deren Durchführung und erfüllt deren Nutzen. Dabei ist wichtig, nicht in "Paralyse durch Analyse" zu verfallen, sondern einen Überblick über die relevanten Security-Risiken zu gewinnen. Bedarfsgerechter Detailgrad bei der Modellierung und die Pflege von Katalogen zur Abschätzung von Schäden, Bedrohungen und Maßnahmen machen hierbei die Komplexität handhabbar. Die Risikoanalyse kann in der Systementwicklung vor allem frühzeitig Fehler im Systementwurf aufzeigen. Sie ersetzt dabei Aktivitäten wie beispielsweise das Testen nicht, sondern ergänzt diese.
Literatur- und Quellenverzeichnis
|
[1] |
International Organization for Standardization (ISO), "ISO/IEC 27005:2008 Information technology - Security techniques - Information security risk management", 2008. |
|
[2] |
J. Eichler und D. Angermeier, "Modular risk assessment for the development of secure automotive systems", in 31. VDI/VWGemeinschaftstagung Automotive Security, 2015. |
|
[3] |
D. Angermeier, A. Nieding und J. Eichler, "Supporting Risk Assessment with the Systematic Identification, Merging, and Validation of Security Goals", in International Workshop on Risk Assessment and Risk-driven Testing, 2016. |
|
[4] |
A. Langley, "Between" paralysis by analysis" and "Extinction by instinct", in Sloan Management Review 36.3, 1995. |
Unsere Trainings & Coachings
Wollen Sie sich auf den aktuellen Stand der Technik bringen?
Dann informieren Sie sich hier zu Schulungen/ Seminaren/ Trainings/ Workshops und individuellen Coachings von MircoConsult zum Thema Qualität, Safety & Security.
Training & Coaching zu den weiteren Themen unseren Portfolios finden Sie hier.
Qualität, Safety & Security - Fachwissen
Wertvolles Fachwissen zum Thema Qualität, Safety & Security steht hier für Sie zum kostenfreien Download bereit.
Fachwissen zu weiteren Themen unseren Portfolios finden Sie hier.