Shift Left - Secure by Design und agile Entwicklung
Seite 2: Kein Widerspruch
Agile Entwicklung und Sicherheit galten lange Zeit als sich wechselseitig ausschließend. Es galt das sogenannte Sicherheitsparadoxon der Softwareentwicklung: Klassische Entwicklerarbeit war stets mit dem Problem konfrontiert, dass sich Sicherheit eines Softwareprodukts nicht hinreichend als finaler, statischer Endzustand definieren ließ, dessen Umsetzung vorab spezifizierbar ist. Aus dem Versuch, Sicherheit für ein Softwareprodukt zu definieren, entstand rasch die Erkenntnis, dass Sicherheit ein dynamischer und kontinuierlicher Prozess ist. Zeitgleich galt die agile Entwicklung mit ihren Prozessen als zu dynamisch, um eine dedizierte Sicherheitsanalyse des zu entwickelnden Softwareproduktes durchführen und einhalten zu können. Beide Annahmen stammen aus der Anfangszeit des Software-Engineerings und werden heute noch an Hochschulen in dieser Form gelehrt.
Tatsächlich ergänzen sich agile und sichere Entwicklung. Agile Entwicklung bietet die Möglichkeiten, auf kurzfristige Änderungen und veränderte Anforderungen zu reagieren. Es bedarf jedoch einer an die agile Entwicklung angepassten Umsetzung der eher statisch ausgelegten Sicherheitsanalysen und einer allgemeinen Veränderung im Umgang mit Sicherheitsanforderungen. Des Weiteren gilt zu beachten, dass agile Entwicklung featureorientiert und dementsprechend oft funktionsgetrieben ist. Sicherheitsanforderungen fallen jedoch überwiegend unter die Kategorie der nicht funktionalen Features und liegen häufig in implizit formulierter Form vor. Die Folge davon und eines fehlerhaften Security-Requirements-Engineerings sind fehlkalkulierte Sprints mit in der Folge erhöhtem Zeitdruck, Abbruch des Sprints aufgrund fehlerhafter Budgetkalkulationen, Erhöhen der Technical Debts, persistierende Schwachstellen oder konkrete Sicherheitslücken innerhalb der Codebasis.
Im Folgenden liegt der Fokus vor allem darauf, wie in agilen Entwicklungsteams Bedingungen geschaffen werden können, die das Sicherheitsniveau der Codebasis frühzeitig verbessern. Es existieren unterschiedliche agile Entwicklungsmodelle, und für die nachfolgenden Abschnitte ist nicht ausschlaggebend, welches Modell konkret zum Einsatz kommt. Da Scrum (s. Abb. 1) weit verbreitet ist, greift der weitere Text auf die üblichen Scrum-Bezeichnungen zurück.
Zunächst erscheint es sinnvoll, das Level an Sicherheit festzulegen, dass das jeweilige Entwicklerteam im Rahmen eines Produktinkrements erzielen kann. Ein Team mit einem starken Security-Fokus kann ein anderes Sicherheitsniveau auf Anhieb implementieren als ein Team ohne den Fokus. Allgemein sollten jedoch Mindeststandards für jedes Team gelten. Die OWASP Top 10 bieten eine Liste häufiger Sicherheitsmängel, die Entwickler durch einfache Maßnahmen vermeiden können. Sie dienen dementsprechend als Einstiegshilfe in das Thema und sollten zum Sicherheitsrepertoire eines jeden Entwicklers zählen. Dennoch zeigen Code Reviews häufig, dass Teams die "Top 10" nicht hinreichend berücksichtigen. Sie sollten sich daher fragen, wie sie diesen Zustand verbessern können.
Ebenfalls gilt anzuerkennen, dass Entwickler hervorragende Arbeit in ihrem Gebiet leisten können, aber keine Sicherheitsexperten sind. Neben unterschiedlichen Erfahrungswerten haben Entwickler und Sicherheitsexperten unterschiedliche Herangehens- und Denkweisen, die für ihre jeweiligen Aufgaben ausschlaggebend sind. Es ist daher wichtig, dass das Entwicklerteam sich über seine Grenzen bezüglich der Einschätzung von Angriffsvektoren und Sicherheitsaspekten im Klaren ist. Bei der Entwicklung kritischer Komponenten oder bei Problemen muss daher bereits vorab organisatorisch die Option etabliert sein, einen Sicherheitsexperten hinzuzuziehen. Dennoch sollten Entwickler grundsätzlich dazu befähigt sein, typische Sicherheitsfaktoren zu bewerten und einfache Maßnahmen zur Verbesserung der Sicherheit des Codes zu ergreifen.
Im Idealfall existiert in jedem Team ein Mitglied, das sowohl über Entwicklungs- als auch über Sicherheitswissen verfügt. Im Rahmen begleiteter Projekte heißen entsprechende Mitarbeiter Security Manager (SecM). Sie überwachen die Sicherheitsaspekte der entwickelten Codeabschnitte, definieren die sogenannte Attack Surface (Angriffsfläche) und Angriffsvektoren in jedem Sprint, unterstützen bei der Aufwandsabschätzung der User-Stories und bei der Umsetzung von Mitigationsstrategien (s. Abb. 3).
Um eine globale Sicht auf die Codebasis und dessen Sicherheitsniveau zu bekommen, ist es sinnvoll, einen regelmäßigen Austausch zwischen den SecMs der beteiligten Teams anzustreben. Da eine unternehmensweite Synchronisation der Sprintphasen unrealistisch ist, sollten die Treffen der SecMs zu regelmäßigen, festen Zeitpunkten stattfinden. In kleinen Unternehmen oder bei synchronisierten Sprints profitieren die Teams insbesondere von einem Austausch während des Sprint-Plannings. Dadurch lassen sich komponentenübergreifende Sicherheitsaspekte und die Auswirkungen der Sprints auf die Sicherheit des Produktinkrements abschätzen. Letzteres ist aktuell meist nur durch nachgelagerte Tests erreichbar. In Anlehnung an das Sprint-Review sollte auch ein SecM-Treffen im Nachgang der Umsetzung neuer Komponenten stattfinden. Dabei bewerten die Teilnehmer in Vorbereitung auf den nächsten Sprint das Sicherheitsniveau nach dem Inkrement. Es bestehen konzeptionelle Überschneidungen zum OWASP Security Champion.
Ein wesentlicher Unterschied ist jedoch das es sich bei einem SecM um einen vollwertigen Security Professional mit Entwicklungserfahrung handelt, der auf einer Ebene mit den Senior Developern agiert. Die OWASP Security Champions werden unterschiedlich umgesetzt, häufig handelt es sich hierbei jedoch um Entwickler, gegenbenenfalls Junior Developer, die sich zusätzliches Sicherheitswissen erarbeiten, welches je nach Erfahrungsstufe dementsprechend hochgradig domänenspezifisch sein kann. Wesentlich bei der Umsetzung sicherer Software ist jedoch Weitblick hinsichtlich der sicherheitsrelevanten Auswirkungen von Implementierungsentscheidungen und die Themenübergreifende Expertise.
Ungeachtet dessen, ob ein Team eine dedizierte Rolle schaffen kann, gibt es einige grundsätzliche Maßnahmen, um den Prozess zur Entwicklung sicherer Software zu unterstützen. Hierbei handelt es sich um die folgenden Best-Practice-Empfehlungen und Erfahrungswerte.
