Zum Newsroom

16.06.2020

Seit rund drei Jahren ist ein spürbarer Paradigmenwechsel in der Softwareentwicklung zu beobachten: Statt im Wasserfallmodell wird nun mit agilen Entwicklungsmethoden gearbeitet – oftmals kombiniert mit DevOps-Ansätzen. Im Bereich IT-Security verändert diese Entwicklung auch die Arbeitsmodelle von IT-Sicherheitsexperten. Waren früher die Ziele eines Softwareentwicklungsprozesses durch Fachkonzepte relativ früh abgesteckt, können sich heute die Funktionen des geplanten Softwareprodukts noch bis kurz vor der Produktivsetzung ändern. Damit müssen viele Sicherheitsanforderungen nun dynamisch und parallel zu den agilen Sprints entwickelt werden. Was bedeutet diese Entwicklung konkret für die Aufgaben und Arbeitsbereiche der IT-Sicherheitsverantwortlichen? msg gibt fünf Tipps für die agile Sicherheit.

1. Wissensaustausch unter allen Stakeholdern

Alle Stakeholder – Security Teams, Entwickler, der Betrieb sowie Fachabteilungen – müssen von Anfang an in die Projekte einbezogen werden, um den Wissensaustausch unter allen Beteiligten zu gewährleisten und kontinuierlich zu pflegen. So sollten beispielsweise Entwickler beim Aufsetzen einer Systemarchitektur den Sicherheitsexperten schon mit dem Projektstart einbeziehen, damit dieser die Sicherheitsanforderungen gegenüber der vorgeschlagenen Lösung abgleichen und grundsätzliche Schwachstellen sofort aufdecken kann. Er kann dann die notwendigen Maßnahmen definieren, um die Sicherheit des Projekts zu gewährleisten.

2. Die Rolle des Applikations-Sicherheitsexperten

Die Rollen im Softwareentwicklungsprozess haben sich nicht zuletzt auch durch agile Verfahrensmethoden verändert: Ein Applikations-Sicherheitsexperte sollte die Projekte und Prozesse heute eher ganzheitlich als Coach begleiten. Damit umfasst sein Arbeitsfeld mehr als das Schreiben und Aufsetzen von Sicherheitskonzepten. Er steuert den Gesamtprozess und bringt sein Wissen ins Team ein. Zudem endet die Rolle des Applikations-Sicherheitsexperten nicht mit dem Ende des Projekts. Seine Expertise wird auch nach der Produktivsetzung gebraucht. Dass diese Entwicklung sinnvoll ist, belegt auch die Tatsache, dass sich ein Produkt auch nach seiner erstmaligen Produktivsetzung weiterentwickelt.

3. Security User Stories für Sicherheitsanforderungen

Sicherheitsanforderungen lassen sich in der agilen Softwareentwicklung über Security User Stories adressieren bzw. einplanen. So wird eine Gesamtübersicht der Aufgaben des Sicherheitsexperten deutlich und sie fördern zusätzlich die Zusammenarbeit und Kreativität. Der Sicherheitsexperte sollte sich aktiv in das Erstellen der Security User Stories einbringen und die Software-Entwickler auf fehlende Szenarien hinweisen. So ist es auch seine Verantwortung darauf hinzuweisen, wenn der Produktverantwortliche eine Security User Story nicht einplant und durchführt, obwohl sie notwendig wäre. Aus diesem Grund sollte die Organisation so gebaut sein, dass ein Verdacht auf Mängel an die zuständige zentrale Sicherheitsorganisation eskaliert werden kann. Am Ende der Security-User-Story-Entwicklung muss eine Dokumentation der relevanten Sicherheitsanforderungen und der fachlichen Prozesse erstellt werden. Dadurch, dass die wichtigsten Aspekte durch die User Stories abgedeckt wurden, sind die relevanten Szenarien beim Entwicklungsteam adressiert.

4. Penetrationstests zur Sicherheitsprüfung

Penetrationstests vor dem Einsatz in der Produktion („Go-live“) dienen zur Verifikation, ob Sicherheitsanforderungen ausreichend berücksichtigt worden sind. So lassen sich technische Schwachstellen entdecken und beheben.

Automatisierte statische Code-Analysen im CI-/CD-Zyklus sollten Standard sein. Sie ermöglichen es den Experten, sich von Anfang an mit den Ergebnissen der Source-Code-Analysen zu beschäftigen und Fehler automatisch zu erkennen. Daher stellt sich nach der initialen Produktivsetzung gerade im DevOps-Modell die Frage, wann weitere Penetrationstests einzuplanen sind. Da Tests in der Regel mit einem großen Aufwand verbunden sind, gilt es vorher festzulegen, wann sie durchgeführt werden. Möglich sind hier Tests vor einer Produktivsetzung, jährlich wiederkehrende Tests oder auch Tests zu risikobasierten Anlässen, wie etwa im Falle von Kritikalitätstests bei Software-Änderungen. Wünschenswert wären vollständig automatisierte dynamische Sicherheitsprüfungen, die sich zyklisch wiederholen und Schwachstellen zeitnah aufdecken. Die Realität sieht momentan jedoch anders aus, denn die dynamischen Penetrationstests müssen in der Regel noch manuell ausgeführt werden.

5. Unternehmensweite Sicherheitsanforderungen und Architekturvorgaben

Grundsätzliche und organisationsweit bekannte Sicherheitsanforderungen wie Checklisten oder Richtlinien, durch die ein Grundschutz gegeben ist, bleiben weiterhin notwendig. Wichtig sind eine Prüfung und Freigabe von Musterlösungen, die unternehmensweit eingesetzt werden, sowie die Bereitstellung von Sicherheitskomponenten für den produktübergreifenden Einsatz. Andernfalls wird speziell bei größeren Organisationen die Betreuung durch Sicherheitsexperten sehr aufwändig oder es kommt zu Insellösungen, die sicherheitstechnisch stetig aufs Neue bewertet werden müssten. Dies bindet unnötig viele Ressourcen.