IT-Security in Scrum-Teams etablieren

Agil Arbeiten und dabei den Ansprüchen an IT-Sicherheit zu genügen, fällt vielen Scrum-Teams schwer. Daher ist es wichtig, IT-Security als festen Bestandteil des Scrum-Prozesses zu etablieren und so im eigenen Takt kontinuierlich die Sicherheit zu verbessern.

Aus der modernen Softwareentwicklung ist Scrum nicht mehr wegzudenken. Das agile Arbeiten in kurzen Iterationen erlaubt es, schnell und flexibel auf Änderungen zu reagieren – ohne in totalem Chaos zu versinken oder gar das Projekt zu gefährden.

IT-Security hingegen verlangt Kontinuität, Stabilität und feste Prozesse, um sicherzustellen, dass etablierte Security-Controls eingehalten werden und auditierbar bleiben. Diese Anforderung lässt sich oft schwer mit der hohen Dynamik der agilen Entwicklungsmethodik vereinbaren und macht somit ein gemeinsames Arbeiten zwischen Entwicklungsteams und Sicherheitsverantwortlichen schwer bis hin zu unmöglich.

Sicherheitslücken lassen sich ähnlich schwer voraussehen wie Softwarefehler. So sind beide nicht gewünscht, leider jedoch gängige Seiteneffekte, die bei komplexen Projekten auftreten können. So kann das Team zwar für das Schreiben von Unit-Tests gewisse Erfahrungen sammeln und entsprechend den daraus resultierenden Aufwand für die Feature-Entwicklung miteinrechnen, aber eben nicht von Anbeginn an einen festen Arbeitsblock pro Sprint zum Beheben von möglichen Fehlern vorausplanen. Genauso verhält es sich mit Security. Letztendlich hilft die gemeinsam gesammelte Erfahrung dabei zu lernen, wieviel Zeit für sinnvolle Sicherheitsfeatures reserviert werden sollte.

Ein guter Ansatz ist es daher, einen festen Block in jeden Sprint oder in jedes Product-Increment zu planen, den das Team nutzen kann, um Risiken und Schwachstellen zu untersuchen und Code- und Feature Reviews mit einem Fokus auf Sicherheitsaspekte durchzuführen. Analog verhält es sich beim Schreiben von Unit- oder Integration-Tests. In Projekten, in denen das gesamte Testing Teil des regulären Codes ist, ist es empfehlenswert, eine Risikobetrachtung im Rahmen einer COP (Community of Practice) oder einer vergleichbaren Institution durchzuführen.

Auch sollten Produktverantwortliche klar erkennen, dass neben Features auch Stories zum Verbessern der Sicherheit notwendig sind. Features in Scrum beschreiben die gewünschten Funktionen, Stories sind die Arbeitspakete, die im Team umgesetzt werden. Neben den Tasks, die zur konkreten Weiterentwicklung von Funktionen im Zielprojekt führen, ist es also auch notwendig, Arbeitspakete vorzusehen, die der Sicherheit und Stabilität zuträglich sind. Die Stories selbst können dann von den Teams besser eingeschätzt und in konkrete Aufgaben heruntergebrochen werden. Da auch hier der Kosten-/Nutzen-Faktor schwer zu ermitteln ist, macht es Sinn, diese Stories als reguläre Weiterentwicklung anzusehen, in Reviews aufzunehmen und so auch das Team daran wachsen zu lassen. Dabei ist gegenseitiges Vertrauen von Team und Product Owner, wie immer bei Scrum, unerlässlich.

Regelmäßige Risikoanalysen durch die Entwicklungsteams sind eine großartige Möglichkeit, Teams Eigenverantwortung für die Sicherheitsanforderungen zu übertragen. Dabei können mögliche Risiken früh entdeckt und mitigiert werden. Gleichzeitig gilt es, den Sicherheitsverantwortlichen mit aktuellen Informationen zu versorgen, um die Anforderungen an das ISMS zu erfüllen. Auch lässt sich eine solche Risikoanalyse nutzen, um beide Parteien – Scrum Team und Sicherheitsverantwortlichen – näher zusammenzubringen und gemeinsam an der Sicherheit der Plattform der Software zu arbeiten.

Um eine Risikoanalyse durchzuführen, ist es hilfreich, eine Methodik zu nutzen. Ein probates Hilfsmittel ist z. B. das „Elevation of Privileges“ Kartenspiel von Microsoft, welches auf dem STRIDE-Modell zur Klassifizierung von Risiken aufbaut.

Das STRIDE-Modell kategorisiert Sicherheitsrisiken in jeweils eine von sechs Kategorien:

• Spoofing: Das Risiko der Verschleierung der Identität des Angreifers.
• Tampering: Risiken durch das Manipulieren von Verbindungen und Daten.
• Repudiation: Provozierbarer Vertrauensverlust und damit fehlende Beweise und Sicherheitsmechanismen.
• Information Disclosure: Verletzung von Datenschutz und Risiken durch den Verlust von Daten.
• Denial of Service: Dienstverweigerung durch Überlastung und provozierbare Fehler.
• Elevation of Privileges: Risiken und Fehler, die Angreifern ermöglichen ihre Rechte auszuweiten.

Dieses Kartenspiel nutzt einen Satz von Karten, ähnlich wie handelsübliche Spielkarten, um eine Interaktion bei allen Beteiligten herauszufordern und dabei neue Denkansätze zum Brainstorming zu geben. Im Ergebnis werden die gesammelten Risiken dann analysiert und ein gemeinsames Vorgehen abgestimmt.

Risiken können entweder durch das Team akzeptiert (Achtung: hier muss ggf. ein Verantwortlicher involviert werden), an andere Teams kommuniziert/weitergegeben oder als User-Story aufgenommen und priorisiert werden. Am Ende bleibt für den Sicherheitsverantwortlichen eine strukturierte Analyse des Projekts, die als Teil des ISMS betrachtet werden kann und im Überblick über mögliche Risiken und Mitigations informiert.

Beim nächsten Risk-Assessment kann diese Liste hinzugezogen werden, um bestehende Risiken mit neuen zu vergleichen und um festzustellen, ob gegebenenfalls eine Neubewertung vorgenommen werden muss.

Damit ein Scrum-Team in die Lage versetzt wird, professionell mit dem Thema Sicherheit umzugehen, bedarf es oft einer Schulung, zum Beispiel eine OWASP Top 10 Schulung, um das grundlegende Wissen über IT-Security überhaupt erst einmal aufzubauen. Die OWASP Top 10 geben einen Überblick über die häufigsten Sicherheitslücken und Risiken in Webanwendungen. International und in vielen Zertifizierungen werden die OWASP Top 10 referenziert und als Grundlage von Sicherheitstrainings angesetzt. Je nachdem, welche Art von Software entwickelt wird, existieren viele verschiedene Möglichkeiten über Trainings zu Kernthemen das Wissen im Team aufzubauen. Gerade in IT-Unternehmen gibt es auch häufig interessierte Kollegen, die helfen können, einen Security-Prozess mit aufzubauen. Erfahrungen sollten im Rahmen einer Community of Interest oder Community of Practice geteilt werden, damit das ganze Projekt-Team profitieren und lernen kann.

Scrum fordert eigenverantwortliches Arbeiten in Teams, das gilt natürlich auch für Sicherheitsthemen. Daher ist es wichtig, dass eine gemeinsame Sprache gesprochen wird und Prioritäten klar festgelegt werden. Sicherheitsverantwortliche sollten dabei nach Möglichkeit versuchen, dem agilen Prozess entgegenzukommen. Ein sinnvolles Investment in Weiterbildung und Wissensaustausch statt in tagelanges Ausfüllen von Compliance Dokumenten ist anzuraten. Das agile Arbeiten lebt von kleinen Iterationen und dem kontinuierlichen Lernen und Adaptieren, ein Prozess, der eigentlich zu der Stabilisierung und dem Lernen genauso gut passt, wie zu dem Verbessern von Sicherheit.