Im letzten Teil meiner Reihe Vier agile Werkzeuge für mehr Sicherheit beschäftigen wir uns mit den Abuser Stories. Sie sind das Gegenstück zu User Stories in der agilen Softwareentwicklung. Hier können wir auf unser Wissen über die Assets, Anti-Personas und Attack Trees aus den vorherigen Teilen zurückgreifen und konkrete Stories für Produktteams entwerfen, mit denen Sie ihr Produkt sicherer machen können.
Einführung in User Stories
Hier nochmal eine kurze Definition einer User Story der Agile Scrum Group:
Eine User Story oder Anwendererzählung ist eine kurze Beschreibung (Story) dessen, was ein Benutzer (User) will.
Dabei gelten die INVEST Grundsätze. Das Akronym steht für
- Independent: Eine User Story beschreibt Funktionen oder Features, die unabhängig voneinander implementiert werden können.
- Negotiable: Die Story ist verhandelbar. Das heißt, dass die Story nicht fertig definiert beim Team ankommt, sondern diese Spielraum haben, eine bessere Lösung zu finden, um das Ziel zu erreichen.
- Valuable: Die Story ist für einen oder mehrere Stakeholder und User nützlich. Wenn sie keinen Nutzen hat, wäre es Verschwendung, sie umzusetzen.
- Estimable: User Stories werden geschätzt, das heißt dem Team ist klar, welche technische Komplexität die Lösung haben wir.
- Small: Die Story ist so klein geschnitten, dass das Team sie in einem Sprint abarbeiten kann.
- Testable: Die User Story kann so getestet werden, dass die Product Owner und Stakeholder prüfen können, ob sie den Mehrwert bietet und korrekt implementiert ist.
Aufbau einer User Story
Meistens, aber nicht zwangsweises, werden User Stories mit dem Connextra Format beschrieben, welches bei der gleichnamigen Firma entworfen wurde.
As a [role], I want [requirement -> output], so [reason -> outcome].
Wegen der drei Bestandteile Role, Requirement und Reason wird auch von den drei Rs gesprochen. Die Role gibt an, aus welcher Perspektive das Feature betrachtet wird oder für welche Persona ein Mehrwert generiert werden soll. Das Requirement oder der Output beschreibt das Resultat der Story und ist das, was entwickelt wird. Die Reason oder das Outcome ist der Mehrwert oder der Nutzen, der durch die Implementierung erzielt wird.
Auf Deutsch könnte das Template z. B. so aussehen:
Als [Persona] möchte ich [etwas haben], um [einen Mehrwert zu bekommen].
Beispiel User Story
Hier ein konkretes Beispiel für eine User Story. Nehmen wir an, wir haben eine Webanwendung entwickelt und am Anfang wurden Useraccounts von einem Admin händisch angelegt, wenn diese per Mail angefragt wurden. Das hat bei wenigen neuen Nutzer*innen pro Woche gut funktioniert. Jetzt ist unser Service bekannter und es sind mehrere hundert Anmeldungen pro Tag geworden. Die Admins kommen kaum noch hinterher. Die Wartezeiten werden immer länger. Jetzt soll ein Feature entwickelt werden, damit die Anmeldung automatisch abläuft.
Als User möchte ich ein Registrierungsformular, mit dem ich mir selbst einen Account anlegen kann, damit ich nicht lange auf einen Admin warten muss.
Die Rolle ist hier der User. Etwas spezifischer ein neuer User. Das Was ist ein Registrierungsformular in unserer Webanwendung. Der Nutzen ist eine verkürzte Wartezeit. Da die Story aus sicht des neuen Users geschrieben ist, ist das der Nutzen, auch wenn wir als Betreiber zusätzlich unsere Admins entlasten. Eine Story kann also auch mehrere Ziele haben.
Akzeptanzkriterien
Die meisten Teams arbeiten bei User Stories mit Akzeptanzkriterien. Diese geben Stichpunktartig an, welche Kriterien erfüllt sein müssen, damit die Story abgenommen werden kann.
Diese Akzeptanzkriterien werden idealer weises so formuliert, dass sie testbar sind. Ansonsten könnten ja auch nicht geprüft werden, ob sie erfüllt sind. Aber es lassen sich dann auch automatisierte Tests bauen, um sicherzustellen, dass die Kriterien reproduzierbar erfüllt sind und bleiben.
Bei dem Registrierungsformular wären folgende Akzeptanzkriterien denkbar
- Nutzer*in muss Usernamen und Mailadresse angeben
- Nutzer*in muss Passwort vergeben und bestätigen
- Username darf noch nicht vergeben sein
Diese Kriterien lassen sich sowohl manuell auf der Weboberfläche testen und so vom PO prüfen, als auch automatisch in Unittests.
Vor- und Nachteile von User Stories
User Stories können schnell angelegt werden und sind in der Regel einfach zu verstehen. Im Gegensatz zu technischen Beschreibungen vermitteln sie auch die Motivation für diesen Teil der Produktentwicklung und ermöglicht es dem Team nach passenden Lösungen zu suchen.
Stories können inkrementell verbessert werden, indem die nötigen Details nach und nach ergänzt werden, bis die Story entwicklungsreif ist. Dadurch wird Verschwendung minimiert und wenig Zeit in aufwändige Planung von Dingen gesteckt, die am Ende doch nicht umgesetzt werden.
Allerdings kann das vorgestellte Template dazu führen, dass alles zwangsweise als Story formuliert wird, auch wenn es keinen Mehrwert hat. Stories sind auch nicht gut darin, nichtfunktionale Aspekte abzubilden.
Abuser Stories
Im zweiten Beitrag der Reihe haben wir Anti-Personas kennengelernt. Anti-Personas sind archetypische Nutzer*innen, die unser Produkt nicht benutzen sollen, das sie mit Absicht Schaden anrichten wollen oder aus Versehen anrichten können. Diese können wir nun wie Personas in Abuser Stories einsetzten.
Aufbau einer Abuser Story
Eine Abuser Story hat dann folgenden Aufbau.
Als [Anti-Persona] möchte ich [etwas böses tun], um [Schaden anzurichten].
Die Anti-Persona nimmt den Platz der Rolle bzw. der Persona ein. Der Output, also das was, wird durch eine böse Tat ersetzt. Sie kann von versehentlichen Klicken auf einen Löschen-Button zu ausgefeilten Angriffen reichen. Das Outcome, der Mehrwert, ist der Schaden, der durch die Aktion verursacht wird.
Beispiel einer Abuser Story
Nehmen wir unsere Webanwendung aus dem User Story Beispiel. Es wurde nun ein Registrierungsformular gebaut, damit die Nutzer*innen sich selbst registrieren und schnell mit unserem Produkt starten können. Doch dabei wurde nur das Feature umgesetzt, nicht aber überlegt, welche Gefahren entstehen könnten. Um dem Team zu zeigen, dass ein paar Sicherheitsfunktionen nötig sind, schreibt der PO folgende Abuser Story:
Als Skriptkiddie Simon möchte ich per Skript beliebig viele Accounts anlegen, um den Server des Anbieters zu überlasten und so Ruhm zu erlangen.
Hier möchte unsere Anti-Persona Skriptkiddie Simon so viele neue Accounts anlegen, dass die Server die Last (Webrequests, Datenbankabfragen, Mailversand…) nicht mehr aushalten und zusammenbrechen. Mit seiner Tat möchte er dann angeben und Ruhm erlangen.
Ablehnungskriterien
Bei Abuser Stories lassen sich analog zu Akzeptanzkriterien Ablehnungskriterien definieren. Auch diese sollten sich testen lassen und erst wenn alle Kriterien erfüllt sind, kann das Angriffsszenario aus der Abuser Story abgelehnt werden. Das lässt sich am besten mit einem Beispiel verdeutlichen.
In der Abuser Story möchte Skriptkiddie Simon den Server zu Fall bringen, indem er die Anmeldemaske vielfach aufruft. Um dies zu verhindern, können verschiedene Abwehrmaßnahmen als Ablehnungskriterien angegeben werden.
- Beim Registrieren wird ein Captcha angezeigt, das korrekt gelöst werden muss
- Die Registrierungs-API verfügt über ein Rate-Limiting und kann pro IP nur ein Mal pro Sekunde aufgerufen werden
- Die aufwendigen Teile der Einrichtung werden erst durchgeführt, wenn die Nutzer*in auf einen Bestätigungslinke geklickt hat
Diese Kriterien können manuell und automatisch geprüft werden und wenn alle erfüllt sind, hat das Produktteam das Angriffsszenario ausreichend abgewehrt.
INVEST Kriterien bei Abuser Stories
Die INVEST Kriterien gelten im Grunde auch für Abuser Stories. Sehen wir uns das an unserem Beispiel an.
Independent
Die Abuser Story kann unabhängig von anderen Stories umgesetzt werden, da keine anderen Features dafür benötigt werden. Sollte aber z. B. noch kein Feature existieren, dass eine Email verschickt wird, kann hinterfragt werden, warum die Adresse bei Anmeldung abgefragt wird und ob dieses Ablehnungskriterium wirklich benötigt wird.
Negotiable
Die Story sowie die Ablehnungskriterien können verhandelt werden. Je nach Anti-Persona reichen z. B. grundlegende Sicherheitsfunktionen oder es werden mehrstufige Schutzfunktionen benötigt. Angriffe von Skriptkiddies kann man anders abwehren als die NSA. Es kann aber durch rechtliche Auflagen nötig sein, dass manche Dinge umgesetzt sein müssen.
Valuable
Da die Abuser Story den Schutz eines Assets als Ziel hat, besteht der Wert meistens aus eben diesem. Es kann aber z. B. auch in der Erfüllung der Voraussetzungen einer Zertifizierung liegen.
Small
Je nach Anzahl und Komplexität der möglichen Ablehnungskriterien kann eine Abuser Story in der Größe variieren. Falls sie nicht mehr in einen Sprint passt, weil die Umsetzung zu aufwendig wird, sollte sie weiter aufgeteilt werden. Statt eine Abuser Story für “Die Absicherung der Loginmaske” zu schreiben, könnte sie aufgeteilt werden in die “Passwort zurücksetzten Methode” und den eigentlichen Loginvorgang.
Testable
Die Abuser Story hat Ablehnungskriterien. Diese lassen sich manuell oder automatisch testen, wobei die automatische Methode bevorzugt werden sollte. Die Tests sind dadurch deterministisch und einfach reproduzierbar.
Woher bekommt mein Team Ideen für Abuser Stories?
Um an Ideen für Abuser Stories zu kommen, eignen sich unter anderem die Attack Trees. Nehmen wir noch einmal den Beispielbaum aus dem Artikel.
Basierend auf einem Teilbaum kann man Abuser Stories mit Akzeptanzkriterien formulieren. Nehmen wir den obersten Ast bis zum Knoten Zugangsdaten erlangen und unsere Anti-Persona Simon.
Als Skriptkiddie Simon möchte ich die Zugangsdaten zum System erlangen, um die Nutzerdaten zu stehlen.
Die Ablehnungskriterien würden aus den Blättern des Knotens erstellt werden:
- Das Passwort hält einem Bruteforceangriff mindestens 30 Minuten stand
- Das Passwort hält einem Wörterbuchangriff mindestens 30 Minuten stand
- Das Standardpasswort muss nach der ersten Anmeldung geändert werden
Vor- und Nachteile von Abuser Stories
Abuser Stories können genauso behandelt werden wie User Stories und fügen sich gut in den gewohnten Ablauf von Scrum Teams ein. Sie können genauso refined, geschätzt und entwickelt werden.
Die Stories helfen sich auf eine Anti-Persona zu fokussieren und sich bestimmte Risiken genauer anzusehen. Dafür werden relativ viele Stories benötigt, da ein Produktteil auf vielfältige Weise angegriffen werden kann.
Außerdem verleitet es dazu, Sicherheit nicht als integraler Bestandteil der Softwareentwicklung zu betrachten, sondern zu versuchen, sie hinterher dranzuflanschen.
Dennoch können Abuser Stories gerade bei bestehenden Systemen einen wichtigen Beitrag leisten, das Thema Sicherheit in die Teams zu bringen und sie daran zu gewöhnen.
Besonders Teams, die automatische Tests für Akzeptanzkriterien schreiben, können von den Ablehnungskriterien profitieren und automatische Tests für sicherheitsrelevante Funktionen einbauen. Sie ersetzten zwar keine Penetration Tests, die einen unabhängigen und qualifizierten Blick bieten, ergänzen diese aber und sorgen für eine solide Basis.
Bis bald,
seism0saurus