Mit Sicherheit agil: Entwicklungsbegleitende Security löst das Kostendilemma

Das Qualitätsmerkmal Sicherheit wird zunehmend zu einer zentralen Eigenschaft von Softwareprodukten. Wird es auf herkömmliche Weise – d.h. durch Schwerpunktsetzung auf Sicherheitstests am Ende von Meilensteinen – angegangen, ergeben sich jedoch fast unausweichlich gravierende Auswirkungen auf Zeit- und Budgetrahmen. Mit dem Resultat: Softwaresicherheit ist mit dem Makel behaftet, ein Hemmschuh zu sein. Dabei ist es durch die konsequente Einbindung der Security in den Entwicklungsprozess möglich, den Cost of Security kalkulierbar zu machen – und Softwareanwendungen in Produktion zu bringen, die durch und durch sicher sind.

Cyberangriffe gehören seit Jahren zum Alltag. Aus diesem Grund gehört die Definition angemessener Securitystandards zu den unabdingbaren Notwendigkeiten innerhalb der Softwareentwicklung. In der Realität scheitern Entwicklungsteams jedoch immer wieder daran, die anvisierten Sicherheitsanforderungen zeit- und budgetgerecht zu erfüllen. Dieses Scheitern ist keinesfalls Zufall. Vielmehr sorgt der übliche Workflow im Softwareentwicklungsalltag dafür, dass der Cost of Security lange im Unklaren bleibt.

So sehen agile Frameworks wie Scrum die Rolle des Sicherheitsexperten in der Regel nicht vor. Daher gehört es auch in agilen Projekten oftmals zur gängigen Praxis, die Sicherheit der entwickelten Software nicht iterativ im Rahmen der Entwicklung zu verbessern, sondern das entstandene Produkt erst kurz vor dem Go-Live in einer finalen Analyse auf Sicherheitslücken zu untersuchen. Nicht selten endet dieses Vorgehen in einem bösen Erwachen, wenn diese Überprüfung – zur Überraschung des Projekts – doch noch gravierende Sicherheitsmängel zu Tage fördert.

Sicherheit lässt sich nicht nachträglich hineinprüfen

In einer solchen Situation bestehen nur zwei Handlungsoptionen, die jedoch erhebliche Risiken bergen. Die erste Möglichkeit besteht darin, das mit den Sicherheitsmängeln verbundene Risiko bewusst einzugehen und den Go-Live wie geplant durchzuführen. In diesem Fall kann zwar der Zeitplan eingehalten werden – die Gefahr, dass ein Angreifer die Sicherheitslücken ebenfalls entdeckt und ausnutzt, ist jedoch unkalkulierbar. Neben dem konkreten Schaden, den ein Angreifer verursachen kann, steht zudem das Image des Softwarebetreibers auf dem Spiel, wenn der erfolgreiche Angriff publik wird und womöglich sogar sensible Kundendaten gestohlen wurden.

Alternativ können sich Organisationen dazu entschließen, den Livegang zu verschieben, um die Sicherheitslücken nachträglich zu schließen. Allerdings ist auch diese Lösung problematisch: Zum einen kann ein verspäteter Go-Live ebenfalls einen Imageschaden bewirken – beispielsweise, wenn der Livegang bereits im Vorfeld zu einem konkreten Termin angekündigt wurde und sich Kunden oder Partner auf den versprochenen Termin verlassen haben. Zum anderen kann das veranschlagte Budget schnell aus dem Ruder laufen, wenn nach Abschluss des eigentlichen Entwicklungsprozesses nachgebessert werden muss.

Die beschriebene Diskrepanz zwischen dem Zeitpunkt des Fehlereinbaus und der Fehlerentdeckung sowie deren Effekte auf das Budget hat Capers Jones bereits in seinem 1996 erschienenen Buch „Applied Software Measurement“ nachgewiesen und in einer für sich sprechenden und oft zitierten Infografik veranschaulicht:

An der Korrektheit der Infografik hat sich in den über zwanzig Jahren seit dem Erscheinen des Werkes nichts verändert. Allerdings stehen durch den herkömmlichen Umgang mit Securityfragen im Softwareentwicklungsprozess nicht nur die Zeit- und Budgetvorgaben auf dem Spiel: Möglicherweise stellt sich im Zuge der Nachbesserungen heraus, dass die Architektur der betroffenen Anwendung eine vollständige Beseitigung der Sicherheitsmängel unmöglich macht. In einem solchen Fall könnte sogar das gesamte Projekt in Frage gestellt werden.

Lean Security macht Sicherheit skalierbar

Wie sich an den genannten Szenarien erkennen lässt, ist die Strategie, sich auf eine einmalige Sicherheitsüberprüfung am Ende des Entwicklungsprozesses zu verlassen, im Hinblick auf die Zeit- und Budgetplanung mit großen Risiken verbunden. Eine Alternative bietet der Ansatz, das Thema Security entwicklungsbegleitend zu bearbeiten – unter anderem durch die Integration eines Security Advisors ins Projektteam, der dafür sorgt, dass Sicherheit von Beginn an als integraler Bestandteil der System- und Softwarearchitektur mitgedacht und getreu des agilen Projektvorgehens iterativ implementiert wird.

Vor dem Schritt, einen Sicherheitsexperten ins Projektteam zu integrieren, schrecken viele Organisationen allerdings zurück. Diese Zurückhaltung hat zweierlei Gründe: Einerseits fürchten viele Entscheidungsträger, dass die entwicklungsbegleitende Bearbeitung der Sicherheitsfragen die Komplexität des ohnehin schon komplexen Softwareentwicklungsprozesses deutlich erhöht. Andererseits wird häufig vermutet, dass der Einbezug eines Experten zu überzogenen Securitymaßnahmen führt – zu Lasten anderer wichtiger Aspekte wie beispielsweise der Usability.

Aufwände für die Sicherheit sollten flexibel an die Notwendigkeiten des Projekts angepasst werden. Statt dem Motto „So viel Sicherheit wie möglich“ gilt das Credo „So viel Sicherheit wie nötig“.

Diese Befürchtungen verkennen jedoch, dass Softwareentwicklungsprojekte äußerst individuell sind und somit auch der Umfang der notwendigen Sicherheitsmaßnahmen stark schwanken kann. Dieser Erkenntnis trägt der Lean-Security-Ansatz Rechnung, laut dem die Aufwände für die Sicherheit flexibel an die Notwendigkeiten des Projekts angepasst werden sollten. Statt dem Motto „So viel Sicherheit wie möglich“ gilt demnach das Credo „So viel Sicherheit wie nötig“. Diese Leitlinie sollte sich auch in der Rollenausgestaltung des Security Advisors widerspiegeln: So kann er ebenso als vollwertiges Projektmitglied auftreten, das das Team während des gesamten Entwicklungsprozesses begleitet, wie als Berater auf Abruf, der lediglich bei Bedarf hinzutritt. Zwischen diesen beiden Extremvarianten kann die Involvierung des Security Advisors frei definiert werden.

Eine Beratungsfunktion übernimmt der Security Advisor insbesondere dann, wenn er selbst nicht Teil der Organisation ist, sondern von einem externen Dienstleister zur Verfügung gestellt wird. Neben der technischen „Grundsicherung“ besteht die Aufgabe des Security Advisors im Hinblick auf die Optimierung der Geschäftsprozesse in diesem Fall darin, den Entscheidungsträgern in konkreten Fragestellungen Möglichkeiten aufzuzeigen und deren Vor- und Nachteile zu erläutern. Auf dieser Grundlage kann der Projektverantwortliche der beratenen Organisation, der im Vergleich zum Security Advisor über ein größeres Detailwissen hinsichtlich der fachlichen Prozesse verfügt, anschließend eine kompetente Entscheidung treffen. Die Organisation behält somit letztlich in diesem sensiblen Bereich die Kontrolle.

Integration von Sicherheit bedeutet nicht Umstrukturierung der Prozesse

Agile Methoden haben sich nicht umsonst in vielen Bereichen der Softwareentwicklung etabliert. Sie lassen den Teams viel Raum für Flexibilität, machen Fehlentwicklungen durch regelmäßige Iterationszyklen schnell sicht- und korrigierbar und erhöhen die Effizienz. Um diese Effizienz nicht zu gefährden, sollten Veränderungen an den eingespielten Abläufen der agilen Softwareentwicklung nur äußerst behutsam vorgenommen werden.

Dies gilt auch für die Einbindung der Security in den Entwicklungsprozess. Dementsprechend müssen klassische Security-Vorgehensweisen an agile Prozesse angepasst werden – und nicht umgekehrt. Um hierfür ein Beispiel zu nennen: Die Etablierung einer festen Testphase inklusive verpflichtender Codereviews und Penetrationstests ist im Rahmen eines Sprints nicht empfehlenswert. Zu groß wäre die Gefahr, einen Security-Bottleneck zu produzieren, der die Geschwindigkeit der agilen Softwareentwicklung ausbremst.

Anforderungen an die Sicherheit sollten von Beginn an als Teil der Definition of Done in den Entwicklungszyklus integriert werden.

Stattdessen sollten Sicherheitsanforderungen nicht erst nach der Entwicklung einer Funktionalität überprüft, sondern von Beginn an als Teil der Definition of Done in den Entwicklungszyklus integriert werden – mit den entsprechenden Auswirkungen auf den Ticket-Workflow: Demnach kann der Security Advisor bereits bei der Formulierung von Tickets hinzugezogen werden, um wichtige Sicherheitsanforderungen im Ticket anzulegen oder auch ein Ticket als nicht sicherheitsrelevant einzustufen.

Die Ergebnisse der folgenden Entwicklungsarbeit werden anschließend vor allem automatisiert getestet, um einen schnellen Durchlauf zu garantieren. Manuelle Codereviews und Penetrationstest werden nur noch bei Bedarf durchgeführt. Darüber hinaus kann der Security Advisor in vielen Fällen im Ticket beschreiben, welche Schritte notwendig sind, um die gewünschte Security-Eigenschaft zu testen. Auf diese Weise können Quality-Assurance-Mitarbeiter die Umsetzung derartiger Sicherheitsanforderungen testen, ohne selbst Experten auf diesem Gebiet zu sein.

Auch wenn das agile Projektvorgehen durch die Einbindung der Sicherheitsmaßnahmen in den Entwicklungsprozess nur vorsichtig angepasst wird, ist es von entscheidender Bedeutung, dass die Veränderungen vom gesamten Team mitgetragen werden und nicht zur One-Man-Show des Security Advisors verkommen. Zur Aufklärung des Teams über die Vorteile einer entwicklungsbegleitenden Security und zur Schaffung der notwendigen Awareness haben sich initiale Schulungen als äußerst effektive Maßnahme erwiesen, die ganz wesentlich zum Projekterfolg beitragen kann. In diesen Schulungen sollte zudem ein gemeinsames Vokabular erarbeitet werden, um spätere Missverständnisse zwischen dem Security Advisor und dem Team zu verhindern. Auch die Entscheidungsträger außerhalb des eigentlichen Teams sollten über Awareness-Seminare für das Thema sensibilisiert werden, um den Nutzen der Security zu verdeutlichen und einen kräftezehrenden „Kampf gegen Windmühlen“ zu vermeiden. Schließlich sind es gerade diese Entscheidungsträger, die hinsichtlich der Sicherheitsanforderungen immer wieder Abwägungen zwischen verschiedenen Alternativen machen müssen – Entscheidungen, die sie im Anschluss unter Umständen auch organisationsintern rechtfertigen können müssen.

Fazit

Angesichts der erwähnten Beispiele lässt sich nicht leugnen, dass die Strategie, Sicherheitsanforderungen entwicklungsbegleitend umzusetzen, die Zeit- und Budgetaufwände innerhalb der Softwareentwicklung zunächst einmal – im Verhältnis zum gesamten Entwicklungsaufwand in geringem Maße – erhöht. Schließlich muss mit dem Security Advisor nicht nur eine weitere Rolle innerhalb des Frameworks installiert werden, sondern auch die Prozesse müssen minimal erweitert werden, um das Thema zum festen Bestandteil des Entwicklungsprozesses zu machen.

Durch die initialen Mehraufwände erkauft sich ein Unternehmen jedoch die Beseitigung zentraler Schmerzpunkte, wodurch sich diese schnell amortisieren. So wird die Wahrscheinlichkeit, dass sich ein Go-Live durch gravierende Sicherheitsmängel verzögert und somit den Budgetrahmen sprengt, durch die Einbindung eines Sicherheitsexperten in den Entwicklungsprozess deutlich reduziert. Indem die Möglichkeit von Verzögerungen und unkalkulierbaren Risiken spürbar verringert und durch berechenbare Größen wie die Kosten eines Security Advisors ersetzt wird, muss der Cost of Security zudem nicht mehr nach dem Prinzip Hoffnung geschätzt werden. Er wird stattdessen bereits im Vorfeld weitestgehend berechenbar.

Bildquelle: Fotolia – Jakub Jirsák