Agiler Sicherheitsbeauftragter sein: Anwenderberichte

Dies ist der vierte Teil meiner Serie 'Ein agiler Sicherheitsbeauftragter sein'. In diesem Blogbeitrag gehe ich näher darauf ein, wie User Stories erstellt werden und welche Rolle die Sicherheitsverantwortlichen dabei spielen sollten.

Das Epos

Bei Agile wird die Arbeit in der Regel in User Stories definiert. Dabei handelt es sich um minimale und definierte Arbeitsmengen, die in der Regel in einem Sprint abgeschlossen werden können. User Stories entstehen jedoch nicht auf magische Weise aus dem Nichts. Alles beginnt mit so genannten Epics. Ein Epos ist in der Regel ein übergeordneter Wunsch, der vor allem das gewünschte Ergebnis beschreibt. Ein Beispiel wäre:

Ich möchte, dass meine Kunden die Möglichkeit haben, Produkte online zu bestellen und sich diese liefern zu lassen.

Dieses Epos gibt bereits eine Vorstellung davon, was Sie erreichen möchten, lässt aber viele Optionen für die Funktionen und die Lösung offen. Eine gängige Technik, um von einem Epos zu User Stories zu gelangen, ist das Story Mapping. Beim Story Mapping geht es darum, die Wünsche und Anforderungen im Zusammenhang mit dem Epos zu ermitteln. Das Story Mapping ist am effektivsten, wenn es in kleinen Gruppen durchgeführt wird (3 bis 5 Personen werden oft als Richtlinie verwendet). Als Sicherheitsbeauftragter ist es wichtig, an dieser Phase teilzunehmen, da dies der erste Punkt ist, um mögliche Risiken zu identifizieren und Anforderungen zu spezifizieren. Die einzige Möglichkeit, sich diesen Platz zu 'verdienen', besteht darin, ein 'Promotor Stakeholder' zu sein (siehe meinen vorherigen Blog). Während der Mapping-Phase identifiziert die Gruppe die wichtigsten Funktionen des Epos und definiert die spezifischen User Stories.

Kartierung der Geschichte

Um das vorherige Beispiel zu verwenden, müssen detailliertere Spezifikationen für die Webshop-Funktionalität (z.B. wie sollen die Benutzer suchen können), die Zahlungsoptionen, die Informationen, die Sie für den Abschluss der Bestellung benötigen, und die Art und Weise, wie Sie die Lieferung abwickeln wollen, erstellt werden. Das Endergebnis sollte eine vollständige Übersicht über alles sein, was mit unbegrenzter Zeit und unbegrenzten Ressourcen machbar ist. Ein erstes Mapping würde demnach etwa so aussehen:

Hinzufügen von Sicherheitsanforderungen

Als Sicherheitsverantwortlicher sollten Sie relevante Sicherheitsanforderungen angeben. Diese Anforderungen können auf einer allgemeinen Ebene (z.B. sollte die gesamte Kommunikation TLS verwenden), auf einer funktionalen Ebene oder auf einer sehr detaillierten Ebene liegen und mit einem bestimmten Teil (oder einer Gruppe) der Story Map verknüpft sein. Wenn z.B. die Erstellung von Benutzerprofilen im Webshop aktiviert ist, sollte dies in den Datenschutzrichtlinien festgehalten werden und über einen Opt-In- oder Opt-Out-Mechanismus verfügen. Sobald die Story Map vollständig ist, beginnt die Phase der Priorisierung. In der agilen Arbeitsweise ist das erste Ziel das minimal lebensfähige Produkt oder Walking Skeleton. Dabei handelt es sich um die minimale Anzahl von User Stories, die für das Unternehmen von Nutzen sind. Die meisten User Stories werden in der Tat nicht Teil dieser ersten Lieferung sein.

Agiles Risikomanagement

Aus der Sicherheitsperspektive kann dies eine Menge Unsicherheiten und Risiken mit sich bringen, aber wenn die User Stories mit den richtigen Sicherheitsanforderungen angewendet wurden, sollte dies kein Problem sein. Einige Beispiele;

• Eine der Anforderungen könnte sein, dass die gesamte Kommunikation durch TLS geschützt sein muss. Der Sicherheitsbeauftragte hätte diese Anforderung der gesamten Gruppe der Webshop-Benutzergeschichten hinzufügen sollen. Unabhängig davon, welche Stories für den Webshop im Walking Skeleton ausgewählt werden, sollte TLS dazugehören.
• Eine andere Anforderung könnte sein, dass das System den PCI-DSS-Standard erfüllen muss, wenn Kreditkarten als Zahlungsmittel akzeptiert werden. Solange diese User Story nicht Teil eines Sprints ist, ist die Sicherheitsanforderung nicht relevant. Wenn Sie dies bereits in einem frühen Stadium des Prozesses festlegen, kann ein Produktverantwortlicher sogar entscheiden, dass die Annahme von Kreditkartenzahlungen den Aufwand nicht wert ist, und sich für eine andere Zahlungsmethode entscheiden oder eine Lösung eines Drittanbieters verwenden.
• Es könnte auch eine Anforderung geben, dass bestimmte Daten nicht in der Online-Analyse erfasst werden dürfen. Solange das Team das Tracking nicht implementiert und aktiviert, ist diese Anforderung auch für frühere Sprints nicht relevant.

Durch die Einbeziehung von Sicherheitsinteressenten in die Erstellung der User Stories können Sicherheits- und Datenschutzaspekte früh im Prozess identifiziert werden und es wird sichergestellt, dass diese zum richtigen Zeitpunkt implementiert werden. Durch die Verknüpfung der Sicherheitsanforderungen mit der Story Map können die Teams auch sicher sein, dass die Sicherheit nicht zu einer Ausweitung des Umfangs führt.

Alle Teile dieser Blogserie

Teil 1: Ein agiler Sicherheitsbeauftragter sein Teil 2: Die Denkweise der Sicherheitsverantwortlichen Teil 3: Pwn the Process Teil 4: User Stories Teil 5: Verbreiten Sie Ihr Wissen Bilder: Website www.scrumalliance.org