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

 

Schreibe einen Kommentar