Security Quality Assurance in Enterprise Softwareprojekten

In der Enterprise Softwareentwicklung gewinnt das Qualitätsmerkmal Sicherheit zunehmend an Bedeutung. Traditionelle Ansätze, bei denen die Sicherheit erst am Ende von Meilensteinen durch Sicherheitstests berücksichtigt wird, führen jedoch oft zu erheblichen Beeinträchtigungen in Bezug auf Zeit und Budget. Dies hat zur Folge, dass Softwaresicherheit oft als Bremse wahrgenommen wird. Doch durch die konsequente Integration von Sicherheitsaspekten in den gesamten Entwicklungsprozess lassen sich die Security-Kosten kalkulierbar machen und eine Security Quality Assurance sicherstellen. Das Resultat: Softwareanwendungen können sicher und effizient in die Produktion überführt werden.

Cyber-Angriffe gehören seit Jahren zum Alltag und haben in jüngster Zeit stark zugenommen. Aus diesem Grund gehört die Definition angemessener Sicherheitsstandards zu den unabdingbaren Notwendigkeiten innerhalb der Softwareentwicklung. In der Realität scheitern Entwicklungsteams jedoch immer wieder daran, die angestrebten Sicherheitsanforderungen zeit- und budgetgerecht zu erfüllen. Dieses Scheitern ist keineswegs zufällig. Vielmehr sorgt der übliche Workflow im Softwareentwicklungsalltag dafür, dass die Kosten der Sicherheit lange im Dunkeln bleiben.

So sehen agile Frameworks wie Scrum die Rolle des Sicherheitsexperten in der Regel nicht vor. Daher ist es auch in agilen Projekten häufig gängige Praxis, die Sicherheit der entwickelten Software nicht iterativ während 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 mit einem bösen Erwachen, wenn diese Analyse – zur Überraschung des Projekts – doch noch gravierende Sicherheitsmängel aufdeckt.

Security Quality Assurance lässt sich nicht nachträglich hineinprüfen

In einer solchen Situation gibt es nur zwei Handlungsoptionen, die jedoch mit erheblichen Risiken verbunden sind. Die erste Möglichkeit besteht darin, das mit den Sicherheitslücken verbundene Risiko bewusst in Kauf zu nehmen und den Go-Live wie geplant durchzuführen. In diesem Fall kann zwar der Zeitplan eingehalten werden – das Risiko, dass ein Angreifer die Sicherheitslücken ebenfalls entdeckt und ausnutzt, ist jedoch unkalkulierbar. Neben dem konkreten Schaden, den ein Angreifer anrichten kann, steht auch das Image des Softwarebetreibers auf dem Spiel, wenn ein erfolgreicher Angriff publik wird und möglicherweise 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. Doch auch diese Lösung ist problematisch: Zum einen kann ein verspäteter Go-Live ebenfalls zu einem Imageschaden führen – etwa wenn der Go-Live 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 Auftretens und der Entdeckung von Fehlern und deren Auswirkungen auf das Budget hat Capers Jones bereits in seinem 1996 erschienenen Buch „Applied Software Measurement“ nachgewiesen und in einer aussagekräftigen und viel zitierten Infografik veranschaulicht:

An der Korrektheit der Infografik hat sich in den fast dreißig Jahren seit ihrem Erscheinen nichts geändert. Bei der herkömmlichen Behandlung von Sicherheitsfragen im Softwareentwicklungsprozess stehen jedoch nicht nur Zeit- und Budgetvorgaben auf dem Spiel: Im Zuge der Nachbesserungen kann sich herausstellen, 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 Application Security macht Sicherheit in Enterprise Software skalierbar

Wie die genannten Szenarien zeigen, birgt die Strategie, sich auf eine einmalige Sicherheitsüberprüfung am Ende des Entwicklungsprozesses zu verlassen, große Risiken hinsichtlich Zeit- und Budgetplanung. Eine Alternative bietet der Ansatz, das Thema Sicherheit entwicklungsbegleitend zu behandeln – unter anderem durch die Integration eines Sicherheitsberaters in das Projektteam, der dafür sorgt, dass Sicherheit von Anfang an als integraler Bestandteil der System- und Softwarearchitektur mitgedacht und entsprechend dem agilen Projektvorgehen iterativ umgesetzt wird.

Viele Organisationen scheuen jedoch den Schritt, einen Sicherheitsexperten in das Projektteam zu integrieren. Diese Zurückhaltung hat zwei Gründe: Zum einen befürchten viele Entscheider, dass die entwicklungsbegleitende Behandlung von Sicherheitsfragen die Komplexität des ohnehin schon komplexen Softwareentwicklungsprozesses deutlich erhöht. Zum anderen wird häufig vermutet, dass die Einbindung eines Experten zu überzogenen Sicherheitsmaßnahmen führt – zu Lasten anderer wichtiger Aspekte wie z.B. der Usability.

Diese Befürchtungen verkennen jedoch, dass Softwareentwicklungsprojekte sehr individuell sind und daher auch der Umfang der notwendigen Sicherheitsmaßnahmen stark variieren kann. Dieser Erkenntnis trägt der Lean Application Security-Ansatz Rechnung, nach dem der Aufwand für Sicherheit flexibel an die Notwendigkeiten des Projekts angepasst werden sollte. Statt des Mottos „So viel Sicherheit wie möglich“ gilt also das Credo „So viel Sicherheit wie nötig“. Diese Leitlinie sollte sich auch in der Ausgestaltung der Rolle des Sicherheitsberaters widerspiegeln: So kann er sowohl als vollwertiges Projektmitglied auftreten, das das Team während des gesamten Entwicklungsprozesses begleitet, als auch als Berater auf Abruf, der nur bei Bedarf hinzugezogen wird. Zwischen diesen beiden Extremvarianten kann die Einbindung des Security Advisors frei definiert werden.

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

Integration von Sicherheit bedeutet nicht Umstrukturierung der Prozesse

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

Dies gilt auch für die Integration der Sicherheit in den Entwicklungsprozess. Entsprechend müssen klassische Security-Vorgehensweisen an agile Prozesse angepasst werden – und nicht umgekehrt. Um ein Beispiel zu nennen: Die Etablierung einer festen Testphase inklusive obligatorischer Code Reviews und Penetrationstests ist im Rahmen eines Sprints nicht zu empfehlen. Zu groß wäre die Gefahr, einen Security-Bottleneck zu produzieren, der die Geschwindigkeit der agilen Softwareentwicklung bremst.

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

Die Ergebnisse der anschließenden Entwicklungsarbeit werden dann vor allem automatisiert getestet, um einen schnellen Durchlauf zu gewährleisten. Die frühe Integration von automatisierten Sicherheitstests verschiebt die Entdeckung von Schwachstellen auf der Zeitachse nach vorne und wird daher auch als „Shift Left“ bezeichnet. In der Abbildung von Capers Jones würde sich eine solche Integration durch eine Verschiebung der gelben Kurve und insbesondere ihres Maximums nach links parallel zur blauen Kurve darstellen.

Im besten Fall verursacht die Integration solcher Tests kaum nennenswerten Aufwand auf Seiten des Entwicklungsteams. Voraussetzung dafür ist, dass die Konfiguration und der Aufruf der entsprechenden Tools sowie die Prüfung, Bewertung und Weiterverarbeitung der identifizierten Schwachstellen ohne spezielle Expertise und im Wesentlichen mit dem Wissen der Entwickler und DevOps funktionieren. Prädestiniert hierfür sind Security-Testing-Plattformen wie mgm ATLAS.

Manuelle Code Reviews und Penetrationstests 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 Sicherheitseigenschaft zu testen. Auf diese Weise können Mitarbeiter der Qualitätssicherung die Umsetzung solcher Sicherheitsanforderungen testen, ohne selbst Experten auf diesem Gebiet zu sein.

Auch wenn das agile Projektvorgehen durch die Integration von Sicherheitsmaßnahmen in den Entwicklungsprozess nur behutsam angepasst wird, ist es entscheidend, dass die Veränderungen vom gesamten Team getragen werden und nicht zur One-Man-Show des Security Advisors verkommen. Um das Team über die Vorteile einer entwicklungsbegleitenden Security aufzuklären und die notwendige Awareness zu schaffen, haben sich initiale Schulungen als sehr effektive Maßnahme erwiesen, die wesentlich zum Projekterfolg beitragen können. In diesen Schulungen sollte auch ein gemeinsames Vokabular erarbeitet werden, um spätere Missverständnisse zwischen dem Security Advisor und dem Team zu vermeiden. Auch Entscheidungsträger außerhalb des eigentlichen Teams sollten durch Awareness-Seminare für das Thema sensibilisiert werden, um den Nutzen von Security zu verdeutlichen und einen kräftezehrenden „Kampf gegen Windmühlen“ zu vermeiden. Schließlich sind es gerade diese Entscheidungsträger, die im Hinblick auf Sicherheitsanforderungen immer wieder Abwägungen zwischen verschiedenen Alternativen treffen müssen – Entscheidungen, die sie später unter Umständen auch organisationsintern rechtfertigen müssen.

Fazit

Vor dem Hintergrund der genannten Beispiele ist nicht von der Hand zu weisen, dass die Strategie, Sicherheitsanforderungen entwicklungsbegleitend umzusetzen, den Zeit- und Budgetaufwand innerhalb der Softwareentwicklung zunächst – in Relation zum Gesamtentwicklungsaufwand gering – erhöht. Schließlich muss mit dem Security Advisor nicht nur eine zusätzliche Rolle innerhalb des Frameworks installiert werden, sondern auch die Prozesse müssen minimal erweitert werden, um das Thema zu einem festen Bestandteil des Entwicklungsprozesses zu machen. Auch die Anschaffung von Werkzeugen für automatisierte Sicherheitstests verursacht zunächst Kosten.

Durch den anfänglichen Mehraufwand erkauft sich ein Unternehmen jedoch die Beseitigung zentraler Schmerzpunkte, wodurch sich diese schnell amortisieren. So wird die Wahrscheinlichkeit, dass ein Go-Live durch gravierende Sicherheitsmängel verzögert wird und damit den Budgetrahmen sprengt, durch die Einbindung eines Sicherheitsexperten in den Entwicklungsprozess und entwicklungsbegleitende automatisierte Tests deutlich reduziert. Indem die Möglichkeit von Verzögerungen und unkalkulierbaren Risiken deutlich reduziert und durch kalkulierbare Größen wie die Kosten eines Security Advisors und ggf. Lizenzkosten ersetzt werden, muss der Cost of Security zudem nicht mehr nach dem Prinzip Hoffnung geschätzt werden. Vielmehr wird er bereits im Vorfeld weitgehend kalkulierbar.