Ein agiler Sicherheitsbeauftragter sein: den Prozess besiegen

Dies ist der dritte Teil meiner Serie 'Ein agiler Sicherheitsbeauftragter sein'. Wie ich bereits in meinem letzten Blog erwähnt habe, ist der Product Owner in der agilen Welt die Person, die Geschäfts- und Kundenwünsche in Arbeitsaufgaben für die Teams umsetzt. Um dies zu tun, stehen den Product Ownern verschiedene Techniken und Mittel zur Verfügung. In diesem Blog werde ich mich auf das Backlog und die Definition von "erledigt" konzentrieren. Als Produktverantwortlicher ist es wichtig, deren Zweck zu verstehen und zu lernen, wie sie Ihnen helfen können, Ihre Ziele zu erreichen.

An den Prozess anpassen

Wie ich bereits in meinem letzten Blog erwähnt habe, hilft die Kategorisierung der Anforderungen dabei, die Arbeitsbelastung der Teams zu minimieren. Aus der Sicht der Entwicklung können die Anforderungen an die Informationssicherheit in 4 Kategorien eingeteilt werden:

• Außerhalb des Geltungsbereichs: Dies sind in der Regel Anforderungen, an denen die IT-Abteilung nicht beteiligt ist, wie z.B. physische Sicherheit, Hintergrundüberprüfungen bei Neueinstellungen und Einhaltung steuerlicher Vorschriften. Agile Teams sollten sich normalerweise nicht um diese Punkte kümmern müssen, da sie von Prozessen außerhalb der Entwicklung erledigt werden.
• Verfahrensanforderungen: Dies sind Anforderungen, die IT-Teams einhalten sollten, die aber nicht mit der Entwicklung verbunden sind. Beispiele sind BYOD-Richtlinien, die Klassifizierung und Handhabung von Informationen und die Trennung von Aufgaben. Normalerweise werden diese Anforderungen durch Onboarding-Prozesse, Awareness-Programme und organisatorische Prozesse erfüllt.
• Allgemeine Anforderungen: Anforderungen, die in den Entwicklungsbereich fallen und immer angewendet werden sollten. In der Regel sind dies die "nicht verhandelbaren Anforderungen", die die Sicherheitsgrundlage bilden. Beispiele sind die Pflege einer CMDB, die Anwendung von Risikobewertungen und die Anwendung von Kryptographiestandards.
• Spezifische Anforderungen; Anforderungen, die sich auf die tatsächliche Entwicklung der User Story beziehen. Diese Anforderungen sind an Bedingungen geknüpft und hängen von der tatsächlichen Entwicklung ab. Wenn zum Beispiel ein neues Formular entwickelt wird, sollten die Benutzereingaben überprüft werden.

Ein agiler Sicherheitsbeauftragter sollte die Informationssicherheitspolitik aufteilen und dafür sorgen, dass sich die Entwicklung nur um die letzten beiden Kategorien kümmern muss. Die Identifizierung der ersten beiden Kategorien ist in der Regel nicht der schwierigste Teil und oft sind diese bereits durch bestehende Prozesse und Verfahren abgesichert. Der schwierige Teil besteht darin, zu entscheiden, welche Anforderungen allgemein und welche spezifisch sind. Allgemeine Anforderungen sollten Anforderungen sein, die immer gelten, unabhängig von der tatsächlichen Entwicklung. Diese Punkte sollten in der Definition of Done aufgeführt werden. Spezifische Anforderungen sind Anforderungen, die mit den User Stories im Sprint verknüpft sind. Ein häufig zu beobachtender Fehler ist es, zu viele Anforderungen in die Kategorie der allgemeinen Anforderungen zu packen. Das wird nicht funktionieren, da die Teams dann jeden Sprint durchgehen müssen, was zu viel Zeit in Anspruch nimmt und letztlich dazu führt, dass die Sicherheit ignoriert wird.

Definition von Erledigt

Die Definition von "done" ist ein entscheidender Schritt in der SCRUM-Arbeitsweise. Der tatsächliche Inhalt ist jedoch von Team zu Team und von Unternehmen zu Unternehmen unterschiedlich. Im Wesentlichen deckt die Definition der Scrum Alliance [1] die Idee ziemlich gut ab:

Die Definition von Erledigt ist eine einfache Liste von Aktivitäten (Schreiben von Code, Codierungskommentare, Unit-Tests, Integrationstests, Versionshinweise, Designdokumente usw.), die dem Produkt einen nachweisbaren/nachweisbaren Wert hinzufügen. Die Konzentration auf Schritte mit Mehrwert ermöglicht es dem Team, sich auf das zu konzentrieren, was zur Erstellung der Software abgeschlossen werden muss, und gleichzeitig verschwenderische Aktivitäten zu eliminieren, die die Softwareentwicklung nur verkomplizieren.

Das Problem mit dieser Definition ist, dass sie sich auf die geleistete Arbeit zu konzentrieren scheint und nicht auf den gewünschten Zustand des Inkrements. Außerdem wird beschrieben, dass die vollständige Integration erst bei der Systemdemo am Ende des Sprints erreicht wird, was darauf hinzudeuten scheint, dass der volle Umfang der Arbeit nur einmal pro Sprint erreicht wird. Dies stellt ein Problem für die Sicherheitsanforderungen dar, da wir wollen, dass diese kontinuierlich berücksichtigt und nicht nur am Ende überprüft werden. Das Scaled Agile Framework [2] versucht, dies zu verbessern, indem es unterschiedliche Definitionen von Done auf verschiedenen Ebenen definiert. Scaled Scrum betont, dass Teams sich bemühen sollten, häufiger zu integrieren und sicherzustellen, dass sie in jedem Sprint mindestens ein integriertes, freizugebendes Inkrement haben, selbst wenn sie skalieren. Als Sicherheitsinteressent ist es daher wichtig zu verstehen, wie die Definition of Done in der agilen Herangehensweise Ihres Teams verwendet wird, so dass Sie Sicherheitselemente auf eine Weise hinzufügen können, die für Sie genau richtig ist... Unabhängig von der tatsächlichen Verwendung der Definition of Done sind Elemente sinnvoll, die darin enthalten sein sollten:

• Die SAST- und DAST-Scans sollten keine offenen kritischen und risikoreichen Posten aufweisen.
• Alle Ausnahmen sollten von den Sicherheitsverantwortlichen genehmigt werden.
• Die gesamte angewandte Kryptographie sollte gemäß den Kryptographierichtlinien implementiert werden.

Der Rückstand

Das Product Backlog ist eine Liste der gewünschten Funktionen, Fehlerbehebungen, nicht-funktionalen Anforderungen usw., die für die erfolgreiche Bereitstellung eines lebensfähigen Produkts erforderlich sind. Der Product Owner priorisiert das Backlog auf der Grundlage von Überlegungen wie Risiko, Geschäftswert, Abhängigkeiten und benötigtem Termin. In Scrum wird die Arbeit in der Regel in Form von User Stories ausgedrückt. User Stories beginnen ihr Leben als übergeordnete Ideen, die Epics genannt werden. Da ein Epos in der Regel zu umfangreich ist, als dass ein agiles Team es in einem Sprint abschließen könnte, wird es in mehrere kleinere User Stories aufgeteilt, bevor es bearbeitet wird. User Stories können auf verschiedene Weise geschrieben werden, werden aber in der Regel aus der Perspektive des Ziels geschrieben. Ein gängiges Format zur Definition von User Stories ist das folgende:

Als <Benutzertyp>, ich möchte <irgendein Ziel> so dass <irgendein Grund>.

Sobald ein Product Backlog-Element ausreichend detailliert ist, um als User Story bezeichnet zu werden, und ihm eine Priorität zugewiesen wurde, wird es in das Sprint Backlog verschoben. Das Sprint Backlog enthält alle User Stories, die ein Team in einem einzigen Sprint fertigstellen wird.

User Story Anforderungen

Neben dem Ziel enthalten die User Stories auch die Anforderungen an die Lösung [3]. Es ist wichtig zu wissen, dass diese Anforderungen vorzugsweise beschreiben sollten, was die Lösung erreichen soll, und nicht die Lösung selbst beschreiben. Für die Sicherheitsverantwortlichen sind diese Anforderungen am wichtigsten, da Sie die relevanten Anforderungen mit diesen User Stories verknüpfen können. Auf diese Weise minimieren Sie den Arbeitsaufwand für die Teams, und das ist das Ziel, das wir zu erreichen versuchen. Einige Beispiele für User Story-Anforderungen wären:

• Wenn ein Kunde seine Daten angibt, sollte ein sicherer Kommunikationskanal verwendet werden.
• Kundendaten sollten an einem sicheren Ort gespeichert werden
• Finanzielle Transaktionen sollten im Hauptbuch registriert werden
• Kreditkartendaten sollten nach der Zahlung vernichtet werden

Einem Product Owner dabei zu helfen, alle relevanten Anforderungen zu ermitteln, kann zeitaufwendig sein. Sicherheitsverantwortliche sollten daher Tools entwickeln (helfen), mit denen sich diese Anforderungen leichter ermitteln lassen. Im nächsten Blog werden wir den Prozess der Erstellung und Verbesserung von User Stories näher beleuchten.

Alle Teile dieser Blogserie

Teil 1: Ein agiler Sicherheitsbeauftragter sein Teil 2: Die Denkweise der Sicherheitsverantwortlichen Teil 3: Pwn the Process Teil 4: Anwenderberichte Teil 5: Verbreiten Sie Ihr Wissen Links [1] Was ist die Definition von Done (DoD)? [2] Scaled Agile Framework Releases [3] Anforderungen und User Stories