Wenn über mögliche Bedrohungen gegenüber einer Software gesprochen wird, haben die Wenigsten direkt konkrete Angriffsszenarien wie Cross-Site-Scripting oder SQL-Injection im Sinn. Meistens ist die „Sicherheit“, die man für sein Projekt umsetzen will, ein eher schwammiger Begriff. Security ist etwas das man auf jeden Fall braucht, aber wie genau man es umsetzen oder gar messen kann ist völlig unklar.
Ein mögliches Mittel um diese Unsicherheit zu lösen, ist die Bedrohungsanalyse oder auch Threat Modeling. Hierbei geht es darum, das System auf seine Schwachstellen hin zu bewerten. Die Beteiligten versetzen sich dabei in die Rolle einer/eines Angreifenden und müssen sich überlegen, wie sie ihr eigenes Produkt hacken würden. Es handelt sich dabei um ein sogenanntes White-Box-Testing, das heißt, alle Beteiligten können und sollen ihr Insiderwissen über das System mit in ihre Überlegungen einfließen lassen, um so alle vorhandenen Schwachstellen zu identifizieren. Dabei ist der Teilnehmendenkreis des Threat Modeling nicht nur auf die jeweiligen Entwickelnden beschränkt, sondern sollte idealerweise aus allen Projektbeteiligten bestehen, damit möglichst vielfältige Herangehensweise entsteht.
Wer bereits von Evil User Stories gehört oder gelesen hat, wird hier einige Parallelen sehen. Tatsächlich ist das Erstellen von Evil User Stories eine mögliche Herangehensweise an das Threat Modeling. Durch Evil Personas können sich die Teilnehmenden besser in die Motivation von Angreifenden hineinversetzen und erkennen so mögliche Angriffsziele. Eine andere Herangehensweise ist die STRIDE Methode. Bei dieser werden verschiedene Kategorien von Angriffen (z.B. Denial of Service, Manipulation von Daten, Datenpannen) genannt und alle Teilnehmenden müssen sich mögliche Angriffe aus dieser Kategorie überlegen.
Um die Teilnehmenden der Threat Modeling Session bei der Identifikation der Bedrohungen zu unterstützen, empfiehlt sich ein strukturiertes Vorgehen. So sollten im Vorfeld bereits die schützenswerten Güter definiert werden, also beispielsweise Daten, Services oder Zugänge, die für den Betrieb essenziell sind und vor unbefugter Nutzung geschützt werden müssen. Auch die Infrastruktur des Systems sollte bereits im Vorfeld analysiert werden und durch entsprechende System- und Datenflussdiagramme visualisiert werden. Hierdurch wird den Teilnehmenden vor Augen geführt, an welchen Stellen die Daten in unser System hineingelangen und wo sie es wieder verlassen. Beide Ereignisse stellen einen potenziellen Angriffsvektor dar.
Wurden unter Berücksichtigung aller verfügbaren Daten nun ausreichend viele Angriffsszenarien definiert, geht es darum, diese zu bewerten. Zuerst werden alle Bedrohungen herausgefiltert, die nicht vom Entwicklungsteam behandelt werden können. Dies kann beispielsweise sein, weil sie auf potenzielle Schwachstellen in einem Teil des Systems abzielen, der von einem Drittanbieter betreut wird. Auch Duplikate oder bereits vom System behandelte Szenarien können entfernt werden.
Die verbliebenen Bedrohungen werden im Anschluss einer Risikoanalyse unterzogen. Wir verwenden hierzu die Risiko-Matrix des BSI. Dabei stellt eine Achse die Wahrscheinlichkeit dar, mit der eine Bedrohung eintreten kann, die andere Achse steht für die Höhe des verursachten Schadens. Zur Einschätzung der Wahrscheinlichkeit eines erfolgreichen Angriffs wird unter anderem betrachtet, wie viel Fachkenntnis zur Durchführung notwendig ist, wie viel Aufwand es eine*n Angreifenden kosten würde und wie hoch die Chance ist, dass der Angriff bis zum erfolgreichen Abschluss unbemerkt bleibt. Bei der Bewertung des Schadens sollten nicht nur die unmittelbar entstehenden Kosten berücksichtigt werden, sondern auch Einbußen durch notwendige Gegenmaßnahmen, Geschäftsausfall und Reputationsverlust.
Wurde allen Bedrohungen ein entsprechender Risikowert zugeordnet, so kann man nun über die Risikobehandlung sprechen. Der Risikowert hilft bei der Entscheidung, wie mit einer Bedrohung umzugehen ist, denn sowohl sehr unwahrscheinliche Ereignisse als auch Ereignisse mit sehr geringem Schadenspotenzial müssen nur mit niedriger Priorität behandelt werden. In manchen Fällen kann sogar für eine Risikoübernahme entschieden werden, also dafür die Bedrohung überhaupt nicht zu behandeln.
Für alle weiteren Fälle gibt es drei mögliche Lösungen. Im Idealfall findet sich ein Weg zur Risikovermeidung. Diese Lösung kann entweder die Eintrittswahrscheinlichkeit eliminieren oder den verursachten Schaden auf null setzen. In beiden Fällen ist das Risiko für das Unternehmen nicht mehr existent. Lässt sich ein Risiko nicht komplett vermeiden, kann eine Risikoreduktion versucht werden. Hierbei werden ebenfalls Maßnahmen definiert, welche Eintrittswahrscheinlichkeit oder Schaden möglichst verringern. Auch wenn hierdurch keiner der beiden Werte auf null sinkt, das Risiko also nicht völlig ausgeschlossen wird, kann es unter Umständen auf akzeptables Rest-Risiko reduziert werden. Ist auch das nicht möglich, so bleibt noch die Option des Risikotransfers. In diesem Fall wird das Risiko auf eine andere Instanz ausgelagert. Ein Beispiel hierfür wäre das Auslagern des Risikos durch Hardwareausfall indem ein Datacenter genutzt wird, welches eine ausreichend hohe Verfügbarkeit garantieren kann.
Am Ende der Threat Modeling Session sollte man noch eine kurze Selbstreflexion einlegen, in der sich alle Beteiligten darüber austauschen können, wie gut die Analyse gelaufen ist und wie sicher sie sich mit den erarbeiteten Maßnahmen fühlen. Die Ergebnisse sollten selbstverständlich entsprechend dokumentiert und als Tickets in die kommenden Sprints aufgenommen werden.
Ähnliche Artikel
