Die Grundidee von Evil User Storys ist recht einfach: Während man bei klassischen User Storys verschiedene Kundenperspektiven einnimmt, um deren Bedürfnisse und Ziele zu erfassen, nimmt man bei Evil User Storys die Perspektive von Personengruppen ein, die bewusst oder unbewusst versuchen, ein Produkt zu missbrauchen oder gar zu zerstören. Dabei können Evil User Storys so einfach aussehen wie:
Als Angreifer möchte ich über einen „Passwort zurücksetzen“-Link einen Benutzer zwingen, ein neues Passwort zu vergeben, um ihn kurzfristig vom Login abzuhalten.
Auch wenn es im ersten Moment nicht offensichtlich scheinen mag, aber wenn eine „Passwort zurücksetzen“-Funktion dafür sorgt, dass direkt das bisherige Passwort ungültig wird, dann stellt dies einen möglichen Angriffspunkt dar. Beispielsweise könnte man so für verärgerte Benutzer eines Online-Dienstes sorgen oder zum Beispiel einen Benutzer daran hindern, eine dringende Bezahlung vorzunehmen.
Wie entwickelt man Evil User Storys?
Generell ist das Schreiben von Evil User Storys vergleichbar einfach wie das Schreiben von klassischen User Storys. Man kann sogar direkt das gleiche Format verwenden:
Als Rolle möchte ich Wunsch, um Nutzen.
Natürlich mit anderen Ausprägungen, wie zum Beispiel
Als böswilliger Autoverkäufer, möchte ich die Bewertungen meiner Konkurrenz manipulieren, um selber eine bessere Angebotspositionierung zu erreichen.
Das Warum bekommt bei Evil User Storys noch mal eine ganz andere Bedeutung, da hierüber zum Beispiel das Ausmaß des möglichen Schadens benannt werden kann.
Auf die Perspektive kommt es an ...
Bei der Entwicklung der „bösen User Storys“ gibt es zwei Gruppen von Rollen, die man einnehmen kann
- böswillige Angreifer und
- unbedarfte Anwender.
Während die Perspektive der „böswilligen Angreifer“ recht offensichtlich ist, so gilt es die Gruppe der unbedarften Anwender ebenfalls zu berücksichtigen. Falls Sie ein Windows-User sind: Ist Ihnen schon mal aufgefallen, dass die Passworteingabe bei der Anmeldung kein Einfügen erlaubt? Hintergrund ist, dass man nach dem Sperren des Rechners nicht aus Versehen an schützenswerte Informationen aus der Zwischenablage gelangen soll.
Vorgehen mit System und Kreativität
Ein systematischer Ansatz ist, die regulären User Storys anzuschauen und zu überlegen, wie man die beschriebenen Anforderungen missbrauchen könnte. Wenn eine User Story beispielsweise Rabatt-Codes in einem Online-Shop fordert, wäre eine Überlegung, wie man es hierdurch schaffen könnte, die Waren kostenlos zu bestellen. Eine weitere systematische Vorgehensweise ist, sich an den Eingabe- und Interaktionsmöglichkeiten des Produkts entlangzuhangeln. Hier kann man bei jedem Element die Frage stellen, was hier manipuliert oder durch eine falsche Verwendung ausgehebelt werden könnte.
Betrachten wir unser Eingangsbeispiel des Passwort-Resets. In Abbildung 1 sind folgende Evil User Storys denkbar:
- Als Angreifer möchte ich alle Nutzer-Accounts zum Setzen eines neuen Passworts zwingen, um dem Betreiber zu schaden.
- Als Angreifer möchte ich die Passwort-Vergessen-Mail an eine E-Mail-Adresse meiner Wahl senden, um ein Passwort meiner Wahl setzen zu können.
- Als Angreifer möchte ich den Verifizierungscode für den Passwort-Reset erraten, um ein Passwort meiner Wahl ohne Kontrolle über die E-Mail-Adresse setzen zu können.
Genauso können auch alle Schnittstellen betrachtet werden. Etwas mehr Kreativität kommt ins Spiel, wenn man versucht, sich vorzustellen, was Angreifer erreichen möchten oder welcher Schaden droht. Hier ist die einfachste Herangehensweise ein einfaches Brainstorming. Mehr Systematik hängt in der Regel vom jeweiligen Szenario ab. Beispielsweise könnte man im Online-Shopping systematisch betrachten, wie Waren an eine falsche Adresse geliefert werden könnten.
Abb. 1: Beispiel Passwort Reset.jpg
Wie finden Evil User Storys ihre Umsetzung?
Sind die Evil User Storys geschrieben, gibt es wie in Abbildung 2 angedeutet zwei Ansätze, wie sie in das Backlog gelangen können:
- Ansatz 1: Eigenständige Backlog Items: In diesem Fall werden sie analog zu klassischen User Storys direkt als eigene Items im Backlog gepflegt, geschätzt und wenn sie zu einer klassischen User Story gehören als Erweiterung dieser umgesetzt. Als eigene Backlog Items empfiehlt sich auf jeden Fall eine Kennzeichnung, wie zum Beispiel ein Tag „Evil User Story“, wenn man mit einem Tool wie Jira arbeitet.
- Ansatz 2: Ableitung von Akzeptanzkri- terien: Als Alternative legt man die Evil User Storys neben die zugehörige User Story für den eigentlichen Kundennutzen und leitet Akzeptanzkriterien für diese ab.
Beide Ansätze sind valide und zahlen entweder auf eine zeitnahe Umsetzung der Sicherheitsperspektive oder auf kompaktere Backlog Items ein. Welcher Weg der richtige ist, sollte das Team für sich entscheiden und gegebenenfalls auch auf beide zurückgreifen. Je nach potenzieller Sicherheitslücke sollte diese natürlich zwingend zusammen mit dem Feature geschlossen werden. Sprich, die Evil User Story muss ein Teil der Akzeptanzkriterien werden.
Abb. 2: Evil User Storys auf dem Weg ins Backlog
Wie geht man mit Evil User Storys im Review um?
Geschlossene Sicherheitslücken sind im Gegensatz zu Qualitätsverbesserungen nicht immer offensichtlich zu präsentieren. Dennoch kann es nützlich sein, Stakeholdern ein Bild davon zu geben, dass und welche Sicherheitslücken geschlossen wurden. In welchem Umfang dies geschieht, sollte je nach Teilnehmergruppe entschieden werden. Wenn eigenständige Backlog Items wie oben beschrieben mit einer Kennzeichnung genutzt werden, dann können auch leicht Daten, wie zum Beispiel die Zahl der offenen und bekannten Sicherheitsoptimierungen mit entsprechendem Investitionsbedarf, vorgestellt werden. Manchmal kann es auch einen guten Aha-Effekt erzeugen, zunächst eine Sicherheitslücke mit einer älteren Produktversion zu demonstrieren und anschließend den umgesetzten Schutz vorzuführen. Achtung: Je nach Stakeholder kann die Frage aufkommen, warum solche Lücken nicht direkt geschlossen werden. Hier sollte entsprechend moderativ beispielsweise mit einer inkrementellen Vorgehensweise oder einer Weiterentwicklung im Team reagiert werden. Wie zuvor beschrieben, gibt es aber auch Sicherheitslücken, die direkt gemeinsam mit einer Funktion geschlossen werden müssen.
Positive Nebenwirkungen von Evil User Storys
Evil User Storys sind sowohl inhaltlich als auch methodisch ein empfehlenswertes Mittel für Teams aller „Erfahrungsklassen“. Der bewusste Umgang mit Security-Anforderungen und die Sensibilisierung für das Thema helfen, diese Aspekte mit der Zeit automatisch mitzudenken. So wie der Umgang mit Testautomatisierung und Qualität im Allgemeinen, bedarf es auch hier einer gewissen Übung und Regelmäßigkeit. Darüber hinaus bieten die „etwas anderen User Storys“ ein gutes Mittel, um einfach mal etwas Auflockerung in das Schreiben von User Storys zu bringen und die Kreativität im Team zu fördern. Also auch ein gutes Mittel für Scrum Master, um Abwechslung zur Weiterentwicklung des Teams einzubauen.
Evil Experten
Die Kreativität der meisten Teams reicht problemlos aus, um viele Sicherheitsaspekte selbst zu identifizieren und einige Evil User Storys zu schreiben. Dennoch kann es sehr hilfreich sein, einen gemeinsamen Workshop mit einem Security-Experten durchzuführen. Experten bringen oft ganz neue und teils indirekte Angriffsmöglichkeiten mit, an die man zunächst nicht denken würde. Beispielsweise werden sogenannte „Malicious Insider“, sprich verärgerte Mitarbeiter mit umfangreichen Zugängen, als Angreifer von innen gern vergessen. Bereit für die eigene Evil User Story? Wir wünschen viel Freude mit der Methode! Wie so oft gilt: Übung macht den (Evil-) Meister.
