Autoren: Daniel Angermeier, Alexander Nieding, J\u00f6rn Eichler, Fraunhofer-Institut f\u00fcr Angewandte und Integrierte Sicherheit (AISEC) Dass eingebettete Systeme zunehmend vernetzt sind und oftmals ungeh\u00e4rtet in diese Situation gelangen, ist als „Internet of Shitty Things“ wohlbekannt. Ebenso, dass der Entwurf einer L\u00f6sung ein angemessenes Problemverst\u00e4ndnis voraussetzt. Wer sich jedoch bei der Entwicklung eingebetteter Systeme dieses Problemverst\u00e4ndnis mittels einer Analyse der Angriffsrisiken verschaffen m\u00f6chte, landet schnell in einer scheinbar endlosen Breiten- wie Tiefensuche nach m\u00f6glichen Angriffsvektoren und unfruchtbaren Diskussion um Angriffswahrscheinlichkeiten und -auswirkungen. Im Folgenden diskutieren wir zentrale Herausforderungen und geben Hilfestellungen f\u00fcr die effektive Identifikation und Absch\u00e4tzung relevanter Angriffsrisiken.<\/strong><\/p>\n Im Folgenden stellen wir zun\u00e4chst 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\u00fchrung und stellen abschlie\u00dfend L\u00f6sungsans\u00e4tze vor.<\/p>\n Um im Entwicklungsprozess Security-Risiken behandeln zu k\u00f6nnen, m\u00fcssen diese zun\u00e4chst erkannt und bewertet werden. Hierbei verhindert ein methodisches und idealerweise toolgest\u00fctztes Vorgehen leicht vermeidbare Fehler, die bei sp\u00e4terer Entdeckung nur mit hohem Aufwand zu beheben sind. Wie immer wird jedoch Praxiserfahrung ben\u00f6tigt, um Methoden erfolgreich anwenden zu k\u00f6nnen. 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\u00fcr die Analyse von Angriffsrisiken, sondern vermitteln ein Verst\u00e4ndnis, warum viele Risikoanalysen als unproduktiv wahrgenommen bzw. gelebt werden. L\u00f6sungsans\u00e4tze werden mit ihren Vor- und Nachteilen vorgestellt, die in die eigene Arbeit \u00fcbernommen werden k\u00f6nnen.<\/p>\n Der typische Ablauf einer Analyse umfasst die folgenden Aktivit\u00e4ten\u00a0[1]\u00a0[2], wobei je nach gew\u00e4hlter Methode die Reihenfolge und Auspr\u00e4gung variieren kann:<\/p>\n Im Folgenden stellen wir einige der g\u00e4ngigen Probleme bei der Durchf\u00fchrung von Risikoanalysen vor und ergr\u00fcnden deren Ursachen.<\/p>\n Systemverst\u00e4ndnis<\/em>: Systemmodellierung<\/em>: Betrachtung der Sch\u00e4den<\/em>: Identifikation von Bedrohungen<\/em>: Absch\u00e4tzung von Bedrohungen<\/em>: Identifikation und Absch\u00e4tzung der Wirkung von Ma\u00dfnahmen gegen Bedrohungen<\/em>: Systemverst\u00e4ndnis<\/em>: Systemmodellierung<\/em>: Betrachtung der Sch\u00e4den<\/em>: Identifikation und Absch\u00e4tzung von Bedrohungen<\/em>: Identifikation und Absch\u00e4tzung der Wirkung von Ma\u00dfnahmen gegen Bedrohungen<\/em>: Systematisches und idealerweise werkzeuggest\u00fctztes Vorgehen in der Risikoanalyse erleichtert deren Durchf\u00fchrung und erf\u00fcllt deren Nutzen. Dabei ist wichtig, nicht in „Paralyse durch Analyse“ zu verfallen, sondern einen \u00dcberblick \u00fcber die relevanten Security-Risiken zu gewinnen. Bedarfsgerechter Detailgrad bei der Modellierung und die Pflege von Katalogen zur Absch\u00e4tzung von Sch\u00e4den, Bedrohungen und Ma\u00dfnahmen machen hierbei die Komplexit\u00e4t handhabbar. Die Risikoanalyse kann in der Systementwicklung vor allem fr\u00fchzeitig Fehler im Systementwurf aufzeigen. Sie ersetzt dabei Aktivit\u00e4ten wie beispielsweise das Testen nicht, sondern erg\u00e4nzt diese.<\/p>\n
\n<\/strong><\/p>\nBeitrag – Embedded Software Engineering Kongress 2017<\/h3>\n
Risikoanalyse: kurz eingef\u00fchrt & im Entwicklungsprozess verankert<\/h2>\n
Typischer Ablauf einer Risikoanalyse f\u00fcr eingebettete Systeme<\/h2>\n
\n
\nHierbei werden zur Vorbereitung der Risikoanalyse verf\u00fcgbare Informationen zusammengetragen, vereinfacht und in einheitlicher Form dokumentiert. Dabei wird der Untersuchungsgegenstand klar von seiner Umgebung abgegrenzt. \u00dcbliche Techniken sind dabei Interviews und das Sichten von Dokumenten.<\/li>\n
\nDer Analyst ermittelt m\u00f6gliche Bedrohungen gegen den Untersuchungsgegenstand. Grundlage hierf\u00fcr sind sowohl die Architektur und Technologieaspekte des Untersuchungsgegenstands als auch Angreifermodelle.<\/li>\n
\nDie ermittelten Bedrohungen werden hinsichtlich der durch sie verursachten Sch\u00e4den und hinsichtlich ihrer Eintrittswahrscheinlichkeiten abgesch\u00e4tzt. Als Grundlage der Schadensabsch\u00e4tzung dient h\u00e4ufig eine Festlegung des Schutzbedarfs, die direkt an die Modellierung des Untersuchungsgegenstands anschlie\u00dft und unabh\u00e4ngig von den identifizierten Bedrohungen erfolgt\u00a0[3]. Diese formuliert Schutzziele auf den Werten des Untersuchungsgegenstands und Sch\u00e4den bei deren Verletzung.<\/li>\n
\nAuf Basis der abgesch\u00e4tzten Bedrohungen und den erwarteten Sch\u00e4den werden m\u00f6gliche Risiken f\u00fcr den Untersuchungsgegenstand identifiziert und bewertet.<\/li>\n<\/ul>\nH\u00e4ufige Probleme und ihre Ursachen<\/h2>\n
\nTypischerweise stellt eine Security-Analyse eine interdisziplin\u00e4re Aktivit\u00e4t dar, da sowohl das Systemverst\u00e4ndnis (Anwendungsdom\u00e4ne) als auch Security-Fachwissen (Security-Dom\u00e4ne) erforderlich sind. Folglich kann f\u00fcr einen der Anwendungsdom\u00e4ne 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 \u00dcbersicht zu verlieren und in „Paralyse durch Analyse“ [4] zu verfallen. Umgekehrt f\u00e4llt 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\u00e4zision und Komplexit\u00e4tsmanagement zu finden.<\/p>\n
\nDie 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\u00e4rte Notation das einheitliche Verst\u00e4ndnis des Systems durch Dritte und die Qualit\u00e4t der darauf aufbauenden Risikoanalyse gef\u00e4hrdet. Im Gegensatz dazu erm\u00f6glichen Notationen mit formalem Unterbau eine eindeutige Interpretation und m\u00f6glicherweise auch technische Auswertung, erh\u00f6hen aber den zeitlichen Aufwand f\u00fcr die Systemmodellierung. Die Variante, die vollst\u00e4ndige Systemmodellierung aus der Entwicklung zu verwenden, scheitert oft an der hohen Detailtiefe und Komplexit\u00e4t des Modells, die zwar f\u00fcr die Systementwicklung n\u00f6tig, aber f\u00fcr die Risikoanalyse h\u00e4ufig hinderlich sind. Eine weitere Herausforderung stellt somit die Wahl der richtigen Granularit\u00e4t der Modellierung dar, um einerseits keine Bedrohungen zu \u00fcbersehen, andererseits aber auch die Komplexit\u00e4t handhabbar zu halten.<\/p>\n
\nDas Absch\u00e4tzen von Sch\u00e4den f\u00e4llt oftmals schwer, da Schadensereignisse oft noch nicht bei der Organisation eingetreten sind und somit keine Erfahrungswerte vorliegen. Teilweise werden Sch\u00e4den benannt, die vom oftmals schwer absch\u00e4tzbaren Verhalten Dritter abh\u00e4ngen (Imageschaden, Absatzverlust \u2026) und eher als indirekte Sch\u00e4den auftreten, w\u00e4hrend der prim\u00e4re Schaden nicht erfasst wird. H\u00e4ufig werden Sch\u00e4den auch nicht konkret benannt, sondern nur die H\u00f6he abgesch\u00e4tzt („Integrit\u00e4t der Firmware: hoch“). Dies erschwert die Nachvollziehbarkeit der Analyse und f\u00fchrt zu uneinheitlichen Bewertungen. Schlie\u00dflich f\u00e4llt es oft schwer abzusch\u00e4tzen, wie oft ein Schaden eintritt und wie der entsprechende Skalierungseffekt ber\u00fccksichtigt werden kann.<\/p>\n
\nZur Identifikation der Bedrohungen f\u00fcr das System muss der Analyst die Perspektive potenzieller Angreifer einnehmen. Hierf\u00fcr ist ein tiefgreifendes Verst\u00e4ndnis m\u00f6glicher Angriffstechniken n\u00f6tig. Gleichzeitig muss f\u00fcr die Anwendbarkeit dieser Techniken ein ausreichendes Systemverst\u00e4ndnis vorhanden sein. Dabei sollten weder kreative Angriffswege noch \u00fcbliche und bekannte Bedrohungen \u00fcbersehen werden. Die Herausforderung besteht also darin, sowohl unkonventionell zu denken, als auch systematisch vorzugehen, um Bedrohungen zu identifizieren.<\/p>\n
\nIn der Regel sind kaum systematische und relevante Daten als Grundlage der Absch\u00e4tzung der Eintrittswahrscheinlichkeit von Bedrohungen vorhanden. Die Ermittlung einer Wahrscheinlichkeit im mathematischen Sinne ist in der Regel nicht m\u00f6glich, da kaum belastbaren Grundlagen existieren. Zudem sind h\u00e4ufige \u00c4nderungen der Absch\u00e4tzungen durch „Entdeckungen“ von Sicherheitsforschern zu erwarten, die neue oder vereinfachte Angriffstechniken aufzeigen.<\/p>\n
\nAnalog dazu m\u00fcssen Ma\u00dfnahmen modelliert und hinsichtlich ihrer risikod\u00e4mpfenden Effekte abgesch\u00e4tzt werden. Dabei stellt der Vergleich verschiedener Ma\u00dfnahmengruppen zur Auswahl eines geeigneten Schutzkonzepts ein wiederkehrendes Problem dar, da f\u00fcr einen Vergleich h\u00e4ufig mehrere Analysen durchgef\u00fchrt und konsistent gehalten werden m\u00fcssen.<\/p>\nL\u00f6sungsans\u00e4tze f\u00fcr eine effektive Analyse von Angriffsrisiken<\/h2>\n
\nUm den interdisziplin\u00e4ren Aspekt zwischen Anwendungs- und Security-Dom\u00e4ne zu unterst\u00fctzen, hat sich ein Vorgehen analog dem Grey-Box-Testing bew\u00e4hrt. Hierbei tritt der Security-Experte mit dem Dom\u00e4nenexperten in Dialog, f\u00fchrt Interviews durch und nutzt selektiv vorhandene Dokumentation, um sein Wissen zu vertiefen und das System im Kontext der Security-Analyse zu modellieren. W\u00e4hrend der weiteren Durchf\u00fchrung der Analyse findet eine regelm\u00e4\u00dfige Synchronisation zwischen den Dom\u00e4nenexperten statt, um eine konsistente Systemmodellierung sicherzustellen.<\/p>\n
\nUnserer Erfahrung nach ist eine geeignete, zumindest teilformalisierte Notation erforderlich. Beispielsweise bietet sich (gegebenenfalls vereinfachtes) UML als Notation an, da es \u00fcber ausreichende Ausdrucksst\u00e4rke verf\u00fcgt und \u00fcblicherweise gut verstanden wird. Hierbei sollte die Modellierungstiefe eingangs nicht zu detailliert gew\u00e4hlt werden, sondern bedarfsgerecht im Laufe der Analyse verfeinert werden. Indikatoren hierf\u00fcr sind z.B. Technologie\u00fcberg\u00e4nge oder Vertrauensgrenzen.<\/p>\n
\nUm die einheitliche Absch\u00e4tzung von Schadensh\u00f6hen zu unterst\u00fctzen, sollte organisationsweit ein dom\u00e4nenspezifischer Katalog von m\u00f6glichst konkreten Prim\u00e4rsch\u00e4den und deren Schadensh\u00f6he erstellt werden. Die Zuordnung der Sch\u00e4den zu verletzten Schutzzielen im Gegensatz zur direkten Absch\u00e4tzung 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\u00e4tzungen verbessert.<\/p>\n
\nW\u00e4hrend das kreative Erkennen m\u00f6glicher Angriffswege Erfahrung durch den Analysten erfordert, kann die systematische Erkennung typischer Angriffe erneut algorithmisch und katalogbasiert unterst\u00fctzt werden. Hierf\u00fcr ist es besonders n\u00fctzlich, wenn das Systemmodell unter Verwendung einer geeigneten Notation Technologieinformationen enth\u00e4lt, auf die seitens der Bedrohungen Bezug genommen werden kann. Um die Absch\u00e4tzung der Eintrittswahrscheinlichkeiten oder H\u00e4ufigkeiten von Bedrohungen zu unterst\u00fctzen, sollte ein Katalog Vorbewertungen durch Security-Experten als Grundlage der Absch\u00e4tzung in der konkreten Analyse enthalten.<\/p>\n
\nMa\u00dfnahmen sollten analog zu den Bedrohungen katalogisiert und vorbewertet werden. Bei der Auswahl einer Risikoanalysemethode empfiehlt es sich darauf zu achten, dass Ma\u00dfnahmen und ihre Auswirkungen auf das System flexibel ber\u00fccksichtigt werden k\u00f6nnen.<\/p>\nFazit<\/h2>\n
Literatur- und Quellenverzeichnis<\/h2>\n