Application Security in einer agilen Welt

Security, Waste und die Definition of Done

Wenn ihr euch den sehr umfangreichen Bereich der Anwendungssicherheit einmal anschaut, werdet ihr euch sicherlich fragen, wie das alles in einem, möglicherweise kleinen, Softwareprojekt beachtet werden soll. Hier eine kleine Notiz am Rande: Der noch relativ übersichtliche OWASP-Application-Security-Verification-Katalog umfasst bereits circa 75 Kontrollen. Andere Anforderungskataloge sind hingegen deutlich umfangreicher.

Wie könnt ihr also dieses ganze vorhandene Wissen sinnvoll in ein agiles Projekt transportieren? Ich erkläre es euch:

Zunächst ist die nicht ganz ernst gemeinte Waste-Variante eine Option: Man beauftrage den neuen, noch nicht so ausgelasteten Mitarbeitenden mit dem Ausfüllen des Kataloges oder der entsprechenden Checkliste – gerne auch über ein separates Backlog Item. Idealerweise stört dieser die anderen Team-Mitglieder nicht bei der Arbeit mit Fragen. Das entstandene Dokument solltet ihr dann wegen des sensiblen Inhaltes – es geht ja schließlich um die Sicherheit – unter Verschluss halten. Ich denke damit kommt man der Definition von „Waste“ sehr nahe. Was hier durchaus etwas überspitzt dargestellt ist, hat aber leider oft einen wahren Kern.

Als Alternative könnt ihr das Thema Security auch über die „Definition of Done“ angehen – hier müssen eine Reihe von Kriterien erfüllt werden, damit das Thema als abgeschlossen gilt. Sicherheit als nichtfunktionale Eigenschaft passt thematisch sehr gut zu dieser Definition. Die Schwierigkeit dabei ist, eine sinnvolle Form der Umsetzung zu finden. Einen Anforderungskatalog zu verlinken und davon auszugehen, dass das Team die Definition of Done schon richtig abarbeitet, wird vermutlich nicht funktionieren. Der Vorteil dieses Ansatzes ist aber, dass man Sicherheit nicht wegpriorisieren kann, wie das eventuell bei spezifischen Sicherheits-Backlog-Items möglich ist. Ein Nachteil ist jedoch die geringe Sichtbarkeit von Sicherheitsanforderungen im Projekt.

Security mit mehr Kontextbezug

Wenn ihr euch die beiden vorherigen Ansätze anschaut, kommt sicherlich relativ schnell die Frage auf, inwieweit Sicherheit einen pauschalen Aspekt hat und welcher Anteil davon in welchen Kontexten relevant ist. Hier ist es nicht zielführend, alle Sicherheitsanforderungen zu beachten, da deren Anzahl einfach zu hoch ist. Besser ist es, wenn ihr euch über den Kontext ganz gezielt nur die relevanten Anforderungen anschaut. Das heißt, wenn ihr zunächst alle Sicherheitsanforderungen beachtet und bewertet, könnt ihr auch mit einer speziellen Umgebung beginnen und euch die Frage stellen, welche Anforderungen hier genau relevant sind.

Dieses Kontextwissen ist beispielswiese auch bei der Bewertung von Schwachstellen notwendig. Aktuelle Verfahren für die Bewertung von Schwachstellen – etwa der Industriestandard CVSS (Common Vulnerability Scoring System) - versuchen, diesen Kontext mit in die Bewertung aufzunehmen.

Ein Kontextbezug kann beispielsweise die Frage beinhalten, ob die entsprechende Anwendung über das Netzwerk erreicht werden kann. Hier wird ein abstrakter Kontextbezug hergestellt, der jedoch im eigentlichen Softwareprojekt nochmals deutlich anders aussehen kann. Ein Beispiel: Ein CVSS-Rating von zehn, also die höchste Kritikalität einer Schwachstelle, kann im eigenen Projekt im besten Falle nicht relevant sein, da etwa die entsprechende Bibliothek nicht aufgerufen wird. So etwas kommt übrigens durchaus häufiger vor. Das soll natürlich keine Aufforderung sein, CVSS-Ratings grundsätzlich zu missachten.

Für Design-Entscheidungen ist es nahezu unmöglich, ohne Sicherheitskontext zu arbeiten. Es ist ein großer Unterschied, ob eine Anfrage bereits authentifiziert und autorisiert wurde. Genauso entscheidend ist es, ob eine Komponente an der Angriffsoberfläche zu finden ist oder ob es sich um eine Bibliothek handelt, die nicht direkt erreichbar ist.

Im typischen Wasserfallprojekt würde man die Design-Entscheidungen in der Architekturphase treffen, also eher gebündelt und möglichst umfassend. Interessanterweise funktioniert das aber teilweise auch in der agilen Welt. Ab einem gewissen Zeitpunkt, also wenn sich das Design einigermaßen stabilisiert hat, könnt ihr einen klassischen Threat-Modeling-Workshop durchführen und die gefundenen Bedrohungen dann als Backlog Items einplanen. Alternativ könnt ihr auch die Sicherheit beim Erstellen oder Umsetzen der jeweiligen User-Stories berücksichtigen - quasi zum Zeitpunkt der jeweiligen Aktivität.

Egal, für welches Vorgehen ihr euch entscheidet, in beiden Fällen muss sichergestellt werden, dass die Mitarbeitenden mit dem entsprechenden Know-how vor Ort sind und unterstützen.

Die Frage der richtigen Security-Know-how-Logistik

Ein gewisses Grundverständnis für Security sollte eigentlich jeder haben – egal ob Architekt oder Entwickler. Auf der anderen Seite ist Security ein sehr spezifisches Themenfeld, dass bei den entsprechenden Expertinnen und Experten durchaus gut aufgehoben ist.

Ich bin, um ehrlich zu sein, der festen Überzeugung, dass man auf die entsprechenden Expertinnen oder Experten nicht verzichten kann. Es ist nämlich nicht ohne weiteres möglich, das notwendige Wissen und die Erfahrung komplett in Prozesse, Guidelines oder Tools zu gießen. Zudem kann von Entwicklerinnen und Entwicklern nicht erwartet werden, dass sie, neben ihrem bereits sehr breiten Aufgabenfeld, auch noch eine Security-Expertise an den Tag legen.

Daraus ergibt sich die Konsequenz, dass in jedem Projekt eine Security-Expertin oder ein Security-Experte vor Ort benötigt wird. Wie ihr sicherlich wisst, ist das vor allem bei kleineren Projekten oft nicht machbar. Ich denke aber, dass es durchaus eine sinnvolle Alternative gibt, ohne das agile Manifest gleich über Bord werfen zu müssen. Ausgehend von der Annahme, dass in einem Projekt nicht zu jeder Zeit die Security-Brille benötigt wird, können die entsprechende Expertinnen und Experten temporär und je nach Verfügbarkeit – etwa bei der Auswertung der Scan-Ergebnisse oder bei der Durchführung einer Bedrohungsanalyse – eingebunden werden. Schließlich geht es ja auch um Funktionalität, Benutzbarkeit, Performance und viele andere Aspekte. Unterstützend könntet ihr dann noch „Security Champions“ - also Mitarbeitende, die quasi Security als Teilaufgaben haben - benennen. Auf diese Weise kann zumindest sichergestellt werden, dass immer jemand im Projekt verfügbar ist, der eine gewisse Affinität zu diesem Thema hat.

Ein Plädoyer für den Security-Experten

Egal ob verteilt auf viele Sprint-Diskussionen oder konzentriert in wenigen Workshops oder Code-Scan-Läufen: Eine Security-Expertise wird in jedem Fall benötigt. Dieses Expertenwissen sollte, wie gesagt, dann vor Ort sein, wenn relevante Entscheidungen getroffen werden.

Idealerweise verfügt ein Projektteam über einen Security-Fachmann, der kontinuierlich verfügbar ist. Allerdings ist das nicht immer machbar oder gar sinnvoll. Das beschriebene Modell mit einem Pool von Security-Expertinnen oder -Experten, die temporär in den Projekten verfügbar sind, kann einen guten Kompromiss zwischen geballtem Security-Know-how und agilem Vorgehen bilden.

Ihr möchtet mehr zu spannenden Themen aus der adesso-Welt erfahren? Dann werft auch einen Blick in unsere bisher erschienenen Blog-Beiträge.