Serious Game IT Security

Spiel, Spaß und Sicherheit…

… und das auch noch gepaart mit Wissensaufbau – eine Win-Win-Situation, doch wie erreichen wir das?
Zunächst nochmal ein paar Schritte zurück. Wir (und natürlich auch noch andere ) bauen Software, damit wir die Bedürfnisse unserer Kunden befriedigen. Das grundlegendste Bedürfnis von Nutzern 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 leider sowohl in der Vergangenheit als auch teilweise heute leider 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 Kunden. Erfreulich ist aus unserer Sicht auch, dass diese Erkenntnis sich auch für die frühe Einbindung von User-Experience-(kurz UX)-Spezialisten 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 Entwickler auch automatisch ein IT-Security-Experte ist.

Entwickler sind nicht automatisch IT-Security-Experten
Auch wenn es Entwickler 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 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 etc. Das Problem hierbei ist jedoch, dass dies nur „Quick-Fixes“ sind, welche kaum Mehrwert für die Schulung der Entwickler bringen. Bestenfalls schaut sich ein Entwickler 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 dieser Entwickler danach ähnliche Fehler in anderen Projekten begeht, die dann wieder teuer über externe oder interne Experten gefunden werden müssen. Um diesem Zyklus entgegenzuwirken, gibt es einen interessanten Ansatz aus dem Buch „Threat Modeling: Designing for Security“ von Adam Shoshack.

Enabling von Entwickler-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 Experten gedacht, die in einer lockeren Runde Sicherheitsprobleme erarbeiten können. Wir haben hier jedoch einen leicht modifizierten Ansatz versucht – indem wir unsere Sicherheitsexperten und die Entwickler eines Projektes gemeinsam spielen lassen, im Rahmen eines Workshops. Das primäre Ziel ist hier weiterhin, Security-To-dos für das Projekt abzuleiten – jedoch schafft die Einbindung der Entwickler in diesen Prozess auch Awareness für IT-Sicherheit in ihrem Projekt und allgemein. Sie können in einem zwanglosen Setting an einem ihnen bekannten Projekt mit einem geschulten Lehrer Sicherheitsskills erlernen und üben. Dies hilft nicht nur kurzfristig dem Projekt – es ist schließlich immer noch eine Analyse mit konkreten To-dos, die schlussendlich das Ergebnis ist – sondern auch der Firma und dem Entwickler langfristig, die Softwaresicherheit zu erhöhen. Und am Ende hat dies auch noch Spaß gemacht

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. Dies kann beispielsweise mit dem freien Tool OWASP Threat Dragon (https://threatdragon.org/login) erstellt werden. Alternativ kann man aber auch andersartige Architekturskizzen benutzen. Bei einem physischen Workshop benötigt man nur die Skizze/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, ähnlich Skat oder Wizard, in dem 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 (https://de.wikipedia.org/wiki/STRIDE_(IT-Sicherheit)) der Sicherheitsmodellierung orientieren.
Der Clou an dem Spiel ist, dass jeder, der eine Karte spielen und Punkte bekommen möchte, eine Sicherheitslücke im System finden muss, die auf die Karte passt – und die anderen Spieler müssen zustimmen, dass die Lücke auch wirklich existiert. Jeder Spieler muss also argumentieren und seine Mitspieler überzeugen. Am besten erarbeitet man auch sogleich einen Weg, diese Lücke zu beheben. Hierbei ist es aber irrelevant, ob ein echter Angreifer 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 Spieler spielt nun die Karte „Denial of Service 5 – Ein Angreifer schafft es, unser Budget für die Cloud zu benutzen“.
• Der Spieler beschreibt das Angriffsszenario: Ein Angreifer ruft das System wiederholt auf und leert zwischenzeitlichen immer wieder 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 Spieler erhält einen Punkt!
• Gemeinsam wird anschließend nach Abwehrstrategien gesucht, hier zum Beispiel das Einstellen von Rate-Limits oder den Zukauf eines DoS-Schutzes des entsprechen 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 sowie in den Entwicklungsprozess einfließen.

Unsere Erfahrung und das 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 nicht gedacht haben. Daher hat es sich auf jeden Fall gelohnt und wir werden dies auch in anderen – auch schon bestehenden – Projekten bei uns und auch bei Kunden anwenden.
Unsere Erfahrung ist, dass es insbesondere für den Austausch am Anfang sinnvoll ist, wenn alle Spieler gemeinsam versuchen, Angriffe zu modellieren und die Punkte eher weniger beachten. Auch ist es gut, wenn nicht nur ein Mitspieler, sondern auch die Moderation des Spiels durch einen IT-Security Experten, oder zumindest Enthusiasten, erfolgt. Dieser kann auch die gefundenen Angriffsmuster erklären und bewerten. Er kann bei Streitigkeiten, ob es die Lücke wirklich gibt, einschreiten . Außerdem kann er beim Erarbeiten von Maßnahmen hilfreiche Tipps geben. Der Lerneffekt ist dadurch besonders hoch.
Fazit: Das Team hat sich spielerisch mit dem Thema IT-Security auseinandergesetzt sowie diverse Angriffsmuster und Verteidigungs- und Vermeidungsstrategien kennengelernt. Die IT-Security-Awareness im Team wurde damit positiv verstärkt. Nicht zu unterschätzen: Alle Teilnehmer hatten Spaß und der Workshop sogar einen Team-Building-Charakter.