Evil User Storys - Security im Story Telling

Viele Teams fokussieren sich heutzutage auf Kundenmehrwert und haben User Storys zur leichtgewichtigen Anforderungserhebung etabliert. Doch was ist eigentlich mit den Besucher:innen, die man nicht haben möchte? Evil User Storys bieten Freiraum für "böswillige Gedanken" und helfen Sicherheitslücken zu schließen – dieser Artikel erklärt wie.

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. Evil User Storiys zahlen damit elementar auf die IT-Sicherheit von Software ein.

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:innen eines Online-Dienstes sorgen oder zum Beispiel Benutzer:innen 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 "Als ... möchte ich ..., um ..." verwenden.

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 nochmal eine ganz andere Bedeutung, da sich 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:innen
• Unbedarfte Anwender:innen

Während die Perspektive der "Böswilligen Angreifer:innen" recht offensichtlich ist, so gilt es die Gruppe der unbedarften Anwender:innen 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 wäre 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 entlang zu hangeln. Hier kann man bei jedem Element die Frage stellen, was hier manipuliert oder durch eine falsche Verwendung ausgehebelt werden könnte. Genauso können auch alle Schnittstellen betrachtet werden. 

Etwas mehr Kreativität kommt ins Spiel, wenn man versucht sich vorzustellen, was Angreifer:innen 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.

Wie finden Evil User Storys ihre Umsetzung?

Sind die Evil User Storys geschrieben, gibt es zwei Ansätze, wie sie in das Backlog gelangen können:

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 es sich auf jeden Fall eine Kennzeichnung, wie zum Beispiel ein Tag 'Evil User Story' wenn man mit einem Tool wie Jira arbeitet.

Ableitung von Akzeptanzkriterien
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.

Wie geht man mit Evil User Storys im Review um?

Geschlossene Sicherheitslücken sind vergleichbar mit Qualitätsverbesserungen nicht immer offensichtlich zu präsentieren. Nichtsdestotrotz 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 User Story Schreiben reinzubringen und die Kreativität im Team zu fördern. Also auch ein gutes Mittel für Scrum Master:innen, um eine Abwechslung zur Weiterentwicklung des Teams einzubauen.

Evil Expert

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 Security-Expert:innen durchzuführen. Expert:innen 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:innen mit umfangreichen Zugängen als Angreifer:innen von innen oft vergessen.

Bereit für die eigene Evil User Story? Wir wünschen viel Freude mit der Methode!

Für eine IT-Security-Sensibilisierung lohnt sich auch ein Blick auf unser IT-Security Seminar IT-Sicherheit für Entwicklerteams, um Ihre Softwareentwicklung nicht nur agil, sondern auch sicher zu gestalten. Für weiterführende Tipps als Scrum Master:in bieten wir auch extra unser Scrum Master:in Advanced-Training an.

Beratung zu Agilität und Organisationsentwicklung

Vom einzelnen Scrum-Team über Skalierung bis hin zu vollständiger Business Agility – gehen Sie mit unseren Kolleg:innen von viadee spark Ihren individuellen Weg zur Agilität. Das Portfolio von viadee spark umfasst neben Beratung rund um Agilität und Innovationsmanagement auch partnerschaftliche Transformationsbegleitung, Leitbildentwicklung sowie Coaching & Mediation.