zurück zur Übersicht

Secure Agile Development: Secure Scrum vs. Security Backlog

Sichere Zusammenarbeit: Secure Scrum und Security Backlog bieten agilen Teams Sicherheit bei der Entwicklung

Agiler Sprint, barfuß

Agile Entwicklungsmethoden wie z.B. SCRUM werden heutzutage von vielen Entwicklungsteams erfolgreich eingesetzt. Dabei zielen solche agilen Methoden vor allem auf möglichst große Autonomie der einzelnen Entwickler und auf Flexibilität bei der Feature-Entwicklung ab. Ein Kernkonzept von SCRUM ist dabei der sog. Sprint – eine Phase von 2-4 Wochen in der Features entwickelt werden und deren Ergebnis ein potentiell nutzbares Produkt ist.  Die Entwicklung von Features während eines solchen Sprints basiert dabei auf sog. User-Stories welche die Requirements eines Features definieren. Der Auftraggeber kann die Priorität solcher User-Stories definieren – jene mit sehr hoher Priorität werden im kommenden Sprint implementiert, alle anderen verbleiben im sog. Product Backlog wo sie auch umpriorisiert werden können.

Kein integraler Bestandteil von Scrum ist bisher das Thema Security bzw. Secure Development.

Agil & Sicher

Die Agilität von Scrum erfordert in Hinsicht auf Security spezielle Vorgehensweisen. So muss etwa davon ausgegangen werden, dass wichtige Design-Entscheidungen während der Entwicklung getroffen bzw. abgeändert werden – auch besteht die Möglichkeit, dass initiale Security-Konzepte auf Grund einer Änderung des Scopes nicht umgesetzt werden können. Derartige Umstände erfordern eine Betrachtung des Themas Security über den gesamten Entwicklungsprozess hinweg.

Im Laufe der Zeit wurden unterschiedlichste Weiterentwicklungen bzw. Anpassungen von SCRUM vorgeschlagen – zwei sollen hier vorgestellt werden.

Secure Scrum

Secure Scrum (Details hier) wurde von Christoph Pohl und Hans-Joachim Hof der Hochschule München entwickelt. Im Rahmen von Secure Scrum werden Security relevante User-Stories im Team (evtl. mit externer Unterstützung) identifiziert und gekennzeichnet. Hierzu wird für jede User-Story ein sog. Loss-Value festgelegt. Dabei handelt es sich um jenen Verlust der entsteht, wenn die Funktionalität dieser User-Story erfolgreich angegriffen bzw. Daten manipuliert/entwendet werden. User-Stories werden mittels sog. S-Marks gekennzeichnet welche wiederum auf ein S-Tag verweist – ein S-Tag beschreibt das entsprechende Security-Problem als auch mögliche Lösungsansätze (z.B. Verweise auf Best Practices). Wird eine User Story mit einem S-Mark implementiert, muss im selben Sprint der entsprechende S-Tag implementiert werden.

Secure Scrum legt großen Wert darauf den eigentlichen Scrum-Prozess und darauf, die entstehende Team-Dynamik nicht zu verändern, was es auch ermöglicht, Secure Scrum in bereits bestehende Scrum Teams/Projekte einzuführen.

Security Backlog

Ein weiterer Ansatz ist das sog. Security Backlog (mehr dazu hier). Hierbei wird zusätzlich zum Product Backlog und  Sprint Backlog das Security Backlog  sowie die Rolle des Security Masters eingeführt. Der Security Master managed das Security Backlog und markiert Security relevante Backlog Items. Für jedes markierte Backlog Item verfasst er ein Dokument mit Informationen zu erkannten Problemen und möglichen Lösungsansätzen. Dieses Dokument dient sowohl als Referenz für den Entwickler als auch für Tester. Abschließende sicherheitsrelevante Tests können auch wieder von dem Security Master durchgeführt werden.

Die Praxis zeigt, dass viele Entwicklerteams den ursprünglichen Scrum-Prozess geringfügig abändern, um besser auf individuelle Gegebenheiten reagieren zu können. Ähnliche Anpassungen sind auch bei den vorgestellten Scrum-Varianten gang und gäbe bzw. sogar notwendig (etwa bei Scrum-of-Scrums).

Fazit

Wer von Anfang an Sicherheitsaspekte im Development beachtet spart später viel Zeit. Immer mehr Firmen fordern aktiv ein hohes Level an Anwendungssicherheit – zurecht, und nicht nur aus Audit-Gründen, oder weil sich die gesetzlichen Vorschriften verschärfen. Jede Entwicklungsabteilung ist gut beraten, sich spätestens beim nächsten Projekt intensiv mit Secure Development zu befassen.

Dafür stehen nun nicht nur Software-Tools (mehr dazu im Artikel Statische Codeanalyse schmerzlos automatisieren) sondern auch die entsprechenden Entwicklungsmodelle zur Verfügung.

 


Bild: ©iT-CUBE SYSTEMS AG 2017

 

1 Kommentar

  • von Prof. Dr. Hans-Joachim Hof am 22.03.2018, 11:45 Uhr

    Es freut mich, dass hier unser Verfahren Secure Scrum vorgestellt wird. An Feedback zum Verfahren und Praxisberichten ist meine Forschungsgruppe immer sehr interessiert, wir würden uns über eine Mail an hof@thi.de freuen :-)

Schreibe einen Kommentar

Wir nehmen Datenschutz ernst! Deshalb informieren wir Sie, was mit Ihren Daten geschieht:

  • Daten aus Formularen und Webseiten-Tracking können von uns zur Analyse gespeichert werden
  • Die Daten können zur Optimierung der Webseite ausgewertet werden. Das ermöglicht es uns, besser zu verstehen, wo das Interesse unserer Besucher liegt. Wir benutzen primär Hubspot für dieses Tracking (mehr dazu finden Sie in der Erklärung auf unserer Datenschutzseite, siehe unten)
  • Wir geben Ihre Daten nicht an Dritte weiter. Im Rahmen von Veranstaltungen, an denen Sie teilnehmen möchten, kann es nötig sein, dass Ihre Daten an Vertragspartner übermittelt werden.
  • Sie haben jederzeit ein Recht auf die Herausgabe, Berichtigung oder Löschung persönlicher Daten.
  • Sie können Ihre Einwilligung, mit uns in Kontakt zu treten, jederzeit mit sofortiger Wirkung widerrufen.

Weitere Details dazu, was wir mit den Daten tun und nicht tun finden Sie auf unserer Datenschutzseite, oder schreiben Sie mich bei Fragen direkt an!

Felix Möckel
Data Protection Officer