Heute gibt es einen Gastbeitrag aus dem Collaboration-Lab von PPI, mit dem wir im Versicherungsbereich viel zusammenarbeiten, vor allem bei technischen Themen. Geben Sie uns gerne Feedback, ob Ihnen mal die etwas technischere Perspektive gefällt.
Spiel, Spaß und Sicherheit …
…, und auch noch gepaart mit Wissensaufbau ist eine Win-win-…-Situation – doch wie erreichen wir das?
Zuerst sollten wir die Frage beantworten, wo in der Versicherungswirtschaft überall Software eingesetzt wird. Nach kurzem Überlegen wird klar, dass im Prinzip die gesamte Wertschöpfungskette mit Software durchzogen ist. Ohne Software geht gar nichts mehr! Umso wichtiger, dass diese gut läuft. Doch wo fängt man da an?
Wir – und natürlich auch noch andere 😊 – bauen Software, damit wir die Bedürfnisse unserer Kunden befriedigen. Das grundlegendste Bedürfnis von Benutzer*innen ist natürlich die richtige Funktionsweise, damit die operativen Aufgaben erfolgreich abgeschlossen werden können. Eine sehr gute Usability und ein ansprechendes Design werden ebenfalls sehr gerne angenommen.
Sicherheit von Software, die eigentlich ein Grundbedürfnis ist, wurde in der Vergangenheit und wird teilweise leider heute noch kaum oder wenig beachtet – zum Glück rückt aber auch dieser Aspekt immer mehr in den Fokus, zum Teil dank mehr medialer Aufmerksamkeit.
Sicherheit von Anfang an mitdenken
Schon seit langer Zeit ist selbstverständlich, dass die fachliche Konzeption die Entwicklung von Software von der ersten Idee bis hin zur Auslieferung und Weiterentwicklung eng begleitet. Dass auch Tests als Teil der Softwareentwicklung und nicht ausschließlich als Qualitätssicherung am Ende einer Iteration signifikant zur Kostenersparnis führen, findet schon lange Berücksichtigung bei den meisten unserer Kund*innen. Erfreulich ist aus unserer Sicht auch, dass sich diese Erkenntnis auch für die frühe Einbindung von User-Experience-Spezialist*innen (kurz UX-Spezialist*innen) durchsetzt. Leider stellen wir immer wieder fest, dass dies für die Sicherheit nicht gilt. Ein möglicher Grund ist, dass bei Zusammenstellung von Projektteams implizit angenommen wird, dass ein*e Entwickler*in auch automatisch ein*e IT-Security-Expert*in ist. Das ist vergleichbar mit der Annahme, dass jede*r Underwriter*in in einer Versicherung automatisch auch ein*e Vertriebsspezialist*in ist. Dem ist nicht so und Gleiches gilt auch für Entwickler*innen.
Entwickler*innen sind nicht automatisch IT-Security-Expert*innen
Auch wenn es teilweise Entwickler*innen gibt, die sich zum Beispiel durch ihr Studium oder aus Interesse mit IT-Sicherheit auseinandergesetzt haben, heißt dies nicht, dass sie auch wissen, wo genau in ihrem Projekt die Sicherheitsprobleme liegen. Hier ist es ähnlich wie beim Erlernen einer Sprache – nur weil man die Grammatik im Grundsatz versteht, heißt es nicht, dass man danach automatisch jeden Satz fehlerfrei aussprechen kann. Dafür benötigt es vor allem viel gezielte Übung. Daher ist es entscheidend, in Projekten den Fokus explizit auf das Thema Sicherheit zu lenken. Dazu gibt es diverse Ansätze wie externe Screenings, Pentests und Ähnliches. Das Problem hierbei ist jedoch, dass dies nur Quick-Fixes sind, die kaum Mehrwert für die Schulung der Entwickler*innen bringen. Bestenfalls schaut sich ein*e Entwickler*in dann den Bericht an und kann die Fehler beheben, ohne jedoch wirklich verstehen zu können, woher das Sicherheitsproblem stammt. Daher ist die Gefahr groß, dass diese*r Entwickler*in danach ähnliche Fehler in anderen Projekten begeht, die dann wieder teuer über externe oder interne Expert*innen gefunden werden müssen. Um diesem Zyklus entgegenzuwirken, gibt es einen interessanten Ansatz aus dem Buch „Threat Modeling: Designing for Security“ von Adam Shostack.
Enabling von Entwickler*innen – Sicherheit nachholen
Das Serious Game Elevation of Privilege ermöglicht auf spielerische Art und Weise, Systeme auf ihre Sicherheit zu analysieren und Gefahrenpotenzial zu erkennen. Eigentlich war dieses Spiel vor allem für Sicherheitsaffine und Expert*innen gedacht, die in einer lockeren Runde Sicherheitsprobleme erarbeiten können. Wir haben hier jedoch einen leicht anderen Ansatz versucht – indem wir unsere Sicherheitsexpert*innen und die Entwickler*innen eines Projekts gemeinsam spielen lassen, im Rahmen eines Workshops. Das primäre Ziel ist hier weiterhin, Security-To-dos für das Projekt abzuleiten – jedoch schafft es die Einbindung der Entwickl*innen in diesen Prozess, bei ihnen auch Awareness für IT-Sicherheit in ihrem Projekt und allgemein zu schaffen, weil sie in einem zwanglosen Setting an einem von ihnen bekannten Projekt mit einer geschulten Lehrkraft Sicherheits-Skills erlernen und üben können. Dies hilft nicht nur dem Projekt kurzfristig (es ist schließlich immer noch eine Analyse mit konkreten To-dos, die schlussendlich das Ergebnis ist), sondern auch der Firma und dem/der Entwickler*in langfristig, die Softwaresicherheit zu erhöhen. Und am Ende macht dies auch noch Spaß. 😊
Spielvorbereitung und Durchführung
Um Elevation of Privilege spielen zu können, sollte man zunächst eine Skizze der zu analysierenden Infrastruktur haben. Standardmäßig benutzt man hier Datenflussdiagramme zum Modellieren des Systems. Ein solches kann zum Beispiel mit dem freien Tool OWASP Threat Dragon erstellt werden. Alternativ kann man aber auch andersartige Architekturskizzen benutzen. Bei einem physischen Workshop benötigt man nur die Skizze beziehungsweise das Diagramm und eine Kopie der Karten (https://github.com/adamshostack/eop/blob/master/EoP_Card%20Game%20Images.pdf). Für Onlinemeetings gibt es freie Tools, die man verwenden kann, zum Beispiel http://elevation-of-privilege.herokuapp.com/.
Das Spiel ist ein Stich-Kartenspiel wie zum Beispiel Skat oder Wizard, in dem es das Ziel ist, mithilfe von Karten, die potenzielle Sicherheitslücken beschreiben, Sicherheitsprobleme in Systemen zu modellieren. Die Karten sind alle in Kategorien von Sicherheitslücken aufgeteilt, die sich am STRIDE-Verfahren der Sicherheitsmodellierung orientieren.
Der Clou in dem Spiel ist, dass alle, die eine Karte spielen (und Punkte bekommen) möchten, eine Sicherheitslücke in dem System finden müssen, die auf die Karte passt – und die anderen Spieler*innen müssen zustimmen, dass die Lücke auch wirklich existiert. Jede*r Spieler*in muss also argumentieren und seine Mitspieler*innen von der Lücke überzeugen. Am besten erarbeitet man so auch gleich einen Weg, diese Lücke zu beheben. Hierbei ist es aber irrelevant, ob ein*e echte*r Angreifer*in dies auch ausnutzen kann – die Priorisierung der gefundenen Angriffe erfolgt im Nachgang.
Beispiel:
- Hintergrund: Eine Webanwendung läuft bei einem Cloud-Anbieter, der nach Traffic abrechnet.
- Der/die Spieler*in spielt nun die Karte „Denial of Service 5 – ein Angreifer schafft es, unser Budget für die Cloud zu benutzen“.
- Der/die Spieler*in beschreibt das Angriffsszenario: Ein*e Angreifer*in ruft das System wiederholt auf und leert zwischenzeitlichen immer wieder ihre/seine Caches. Das System liefert immer wieder dieselben Daten aus. Die Kosten für den Traffic steigen.
- Die anderen Spieler diskutieren und kommen überein, dass die Sicherheitslücke in der Tat besteht – der/die Spieler*in erhält einen Punkt!
- Gemeinsam wird danach nach Abwehrstrategien gesucht, hier zum Beispiel das Einstellen von Rate Limits oder den Zukauf eines DoS-Schutzes des entsprechenden Cloud-Anbieters.
Das Spiel kann dann so lange gespielt werden, bis man keine Karten mehr hat oder die Timebox zu Ende ist. Die identifizierten Schwachstellen und deren potenzielle Lösung sollten dann im Nachgang als Security-To-dos in Tickets überführt und priorisiert werden und in den Entwicklungsprozess einfließen.
Unsere Erfahrung und Fazit
Wir haben das Spiel im Rahmen der Entwicklung der Anwendung Convo (https://ppi-x.de/smart-solutions/convo.html) gespielt und dabei die ein oder andere Schwachstelle entdeckt, an die wir vorher nicht gedacht hatten. Daher hat es sich auf jeden Fall gelohnt und wir werden dies in anderen Projekten (auch schon in bestehenden) bei uns und auch bei Kunden anwenden.
Unsere Erfahrung war, dass es insbesondere für den Austausch am Anfang sinnvoll ist, wenn alle Spieler*innen gemeinsam versuchen, Angriffe zu modellieren und die Punkte eher weniger beachten. Auch ist es gut, wenn nicht nur ein*e Mitspieler*in, sondern auch die Moderation des Spiels durch eine*n IT-Security-Expert*in (oder zumindest -Enthusiast*in) erfolgt. Diese*r kann auch die gefundenen Angriffsmuster erklären und bewerten (und bei Streitigkeiten, ob es die Lücke wirklich gibt, einschreiten 😊). Außerdem kann sie/er beim Erarbeiten von Maßnahmen hilfreiche Tipps geben. Der Lerneffekt war dadurch besonders hoch.
Fazit: Das Team hat sich spielerisch mit dem Thema IT-Security auseinandergesetzt sowie diverse Angriffsmuster, Verteidigungs- und Vermeidungsstrategien kennengelernt. Die IT-Security-Awareness wurde damit positiv im Team verstärkt – und auch nicht zu unterschätzen: Alle Teilnehmer*innen hatten Spaß und der Workshop hatte sogar einen Teambuilding-Charakter.
Wenn Ihnen der Beitrag gefallen hat, dann schauen Sie doch gerne auch beim PPI-X-Blog vorbei: https://blog.ppi-x.de
