Sicherheitsanforderungen und User Stories

Wie sollte ich Sicherheitsanforderungen darstellen, wenn ich User Storys verwende?

oder

  • Sollten sie nur „unsichtbare“ Teile von User Stories sein? Das heißt, wenn der Entwickler eine User Story implementiert, sollte er sie bereits mit guter Sicherheitsqualität implementieren.

Antworten (3)

In Scrum (wo User Storys auch als Teil des Product Backlogs existieren) ist es üblich, Sicherheit, Verfügbarkeit, Reaktionsgeschwindigkeit und andere nicht funktionale Anforderungen als Teil der Definition von „Done“ zu sehen. Diese Art deckt sich mit Ihrer Vorstellung:

Das heißt, wenn der Entwickler eine User Story implementiert, sollte er sie bereits mit guter Sicherheitsqualität implementieren.

Dies ist die Definition von „Fertig“ – alle Anforderungen aus der Liste sollten erfüllt sein, damit die User Story als abgeschlossen oder abgeschlossen betrachtet wird.

Mehr zur Definition von „Done“

Mehr zum Umgang mit nichtfunktionalen Anforderungen, auch bekannt als NFRs

Als ich meine zweite Meinung verfasst habe, habe ich genau über Definition of Done nachgedacht. Aber ich habe mich entschieden, Fragen häufiger zu stellen, deshalb habe ich nicht über Scrum gesprochen. Aktuell handhaben wir Sicherheitsanforderungen genau so. Aber ich habe von "bösen Geschichten" gelesen und dachte, dass dieser Ansatz vielleicht richtiger ist.
"Böse Geschichten" scheinen ein guter Weg zu sein, wenn Sie eine bestimmte Sicherheitsanforderung haben, die nur im gegenwärtigen Moment gilt. Wenn Sie nach 1 Jahr neue "User Stories" haben, für die das Sicherheitsproblem gelten sollte, wäre das meiner Meinung nach schwierig zu handhaben (z. B. jemand vergisst, die "böse Geschichte" anzuwenden).

Sie können sich ansehen, wie Microsoft an dieses Thema herangeht. Sie stellten eine Idee des Security Development Lifecycle (SDL) vor, bei dem es sich um einen Softwareentwicklungsprozess handelt, der zum Erstellen sichererer Software verwendet werden kann.

Ein Teil dieses Prozesses ist die Aktivität Threat Modeling; Ziel ist es, ein Diagramm zu erstellen, das Ihre Anwendungsinteraktionen zusammenfasst und sowohl interne als auch externe Faktoren enthält. Es hilft, Stellen in Ihrer Anwendung zu identifizieren, an denen Sicherheitsbedrohungen auftreten können.

Informationen zur Anwendung von SDL und Threat Modeling finden Sie unter: https://technet.microsoft.com/en-us/security/hh855044.aspx

Ich hoffe, es beantwortet Ihre Fragen und gibt Ihnen zumindest einen Überblick, wie Sie solche Probleme angehen können.

Interessanter Ansatz. Danke für Informationen.

Es ist eine sehr gute Frage, aus meiner früheren Erfahrung haben wir dies als Anwendungsfälle für Geschichten oder Akzeptanzkriterien dieser bestimmten Geschichte hinzugefügt.

Auf diese Weise können Sie den Entwickler bitten, Ihre Funktionalität auf der Grundlage von Anwendungsfällen/Akzeptanzkriterien zu testen.

Ich denke, das wird dir helfen