Wie man IT-Sicherheit auch in agilen Projekten verankert

Aufgabe einer zentralen Governance-Funktion ist es, auch in einem agilen Umfeld die Verantwortung klar zuzuordnen und gegebenenfalls notwendige zusätzliche Rollen außerhalb des Scrum-Lehrbuchs vorzugeben. Somit können unternehmensspezifische, angepasste Vorgehensmodelle berücksichtigt und implementiert werden.

Beispiele für solche Governance-Vorgaben sind:

• Die Etablierung der Rolle eines Projekt-Sponsors, der für Projekte und das Vorgehen die Verantwortung trägt und auch final für die Übernahme von Risiken verantwortlich ist.

• Die Präzisierung der Verantwortung der Rolle Product Owner, z.B. bezüglich der Priorisierung und Umsetzung von Security-Anforderungen inklusive einem entsprechenden Reporting und Eskalationsverhalten.

• Die Präzisierung der Verantwortung der Rolle Scrum Master, z.B. bei der Berücksichtigung von Security-Maßnahmen in der Planung von Iterationen/Sprints, bei der Eskalation von Security-Problemen, bei der Planung und Leitung von Bedrohungsanalysen.

• Die Etablierung der Rolle Security-Architekt, der als Experte Teams unterstützen kann - z.B. bei der Durchführung von Bedrohungsanalysen oder Reviews - und auch Security-Anforderungen an die Teams formuliert.

• Die Präzisierung der Verantwortung einzelner Entwickler in Teams bzw. Projekten, z.B. in Bezug auf die Behandlung von Security Issues oder die Teilnahme an sicherheitsspezifischen Weiterbildungs- und Informationsveranstaltungen.

Allerdings reicht es nicht, sich nur auf die Erstellung von Vorgaben zu konzentrieren, sondern auch die Umsetzung dieser Vorgaben in der Organisation und den agilen Projekten muss im Fokus stehen. Dafür ist eine enge Zusammenarbeit auf allen Ebenen wichtig. Als zentrales Bindeglied zwischen den agilen Projekten/Teams und den internen Sicherheitsfunktionen (wie z.B. CISO) sollten daher Austauschformate und Vernetzung der Communities untereinander etabliert werden, sodass auch in der Governance-Aufteilung eine agile Arbeitsweise und Arbeitsumgebung gefördert wird.

Security in Meilensteine zerlegen

Genauso wie die Entwicklungsarbeit muss in agilen Projekten auch Security in einzelne Inkremente zerlegt und innerhalb von Sprints umgesetzt werden. Das bedeutet aber auch: Security wird vom einmaligen Quality Gate zum Prozess, dessen Aktivitäten sich mit den Sprints wiederholen müssen. Zu solchen Aktivitäten zählen zum Beispiel Schwachstellenbeseitigung, Abarbeiten sicherheitsrelevanter User- und Abuse Stories oder Source-Code-Analysen.

Von zentraler Bedeutung für die Security in agilen Projekten ist die Erarbeitung eines von allen Beteiligten akzeptierten Gesamtbildes bei gleichzeitiger Verantwortung der agilen Teams für die sichere Entwicklung. Diese darf nicht an eine zentrale Stelle verschoben werden, weil das einerseits einen Geschwindigkeitsverlust bedeuten würde und andererseits das agile Prinzip der Eigenverantwortlichkeit verwässern würde.

Dieses Gesamtbild muss die Bedürfnisse der Governance und der Gesamtorganisation, aber auch der agilen Projekte/Teams berücksichtigen. Dabei dürfen die Governance-Einheiten nicht als Elfenbeinturm verstanden werden. Es muss möglich sein, dass Projekte und Teams Einfluss auf ihre Arbeit haben - zum Beispiel durch vorübergehende Mitarbeit von Team-Mitgliedern in den Governance-Einheiten.

Übergreifende Kennzahlen werden definieren

Um einheitliche Vorgehensweisen und Standards zu etablieren, müssen übergreifende Kennzahlen und Dokumentationsvorgaben bestehen, um Transparenz und damit Steuerungsmöglichkeiten zu schaffen. Im agilen Kontext kann dies beispielsweise durch die Definition von Anforderungen geschehen, welche in Akzeptanzkriterien oder Elemente einer DoD (Definition of Done) überführt werden.

Eine andere Vorgehensweise könnte sein, dass ein Sprint-Inkrement nur Komponenten verwenden darf, die keine bekannte Schwachstelle mit einem CVSS-Wert >3 haben. CVSS steht dabei für das "Common Vulnerability Scoring System" und ist ein Industriestandard zur Bewertung des Schweregrades von möglichen sowie tatsächlichen Sicherheitslücken in IT-Systemen.

Schulungen dauerhaft etablieren

Da Security in agilen Umgebungen sowohl eine Aufgabe der Teams als auch der Governance-Funktion ist, müssen die Beteiligten breit geschult werden. Dabei sollte das Schulungsprogramm die agilen Strukturen berücksichtigen. Die Inhalte solcher Programme sind weitgehend unternehmensspezifisch und sollten mit den geplanten Vorhaben gekoppelt sein und aus deren Anforderungen abgeleitet werden.

Empfohlen werden eine kurze Basisschulung, auf die Schwerpunkte der Mitarbeiter zugeschnittene vertiefende Schulungen und eine weitere Spezialisierung von ausgewählten Mitarbeitern zu Security-Experten innerhalb der agilen Projekte/Teams. Neben der Etablierung eines Schulungscurriculums ist es unabdingbar, Security-Experten aufzubauen und in der Organisation zu halten. Wichtig dafür ist, dass die qualitative Weiterbildung der Mitarbeiter an den Karrierepfad gebunden werden kann, um zusätzliche Anreize zu schaffen.

Security Development Life Cycle

In Entwicklungsprojekten hat sich die Implementierung eines Security Development Life Cycle (SDLC) zum Standard entwickelt. Aber auch hier gilt, dass die Elemente mit dem agilen Vorgehen zusammenspielen müssen. Ist die Integration erfolgreich, können Sicherheitsaspekte von Anfang an berücksichtigt werden - Security by Design. Besondere Herausforderungen dabei sind:

• Anwendungen werden inkrementell (schrittweise) entwickelt. Die Elemente des SDLC müssen daher sinnvoll auf die entstehenden Inkremente anwendbar sein.

• Die kurzen Entwicklungszyklen betragen in der Regel in agilen Projekten nur noch zwei bis vier Wochen. Damit wird eine Tool-Unterstützung im SDLC wichtig, die darauf abzielt, möglichst viele Aktivitäten vollständig zu automatisieren.

Die Notwendigkeit zur Umstellung auf eine inkrementelle Arbeitsweise betrifft z.B. die Durchführung von Bedrohungsanalysen. Die Durchführung einer Bedrohungsanalyse zu einem festen Zeitpunkt ist in agilen Projekten kaum zielführend. Stattdessen sollten Bedrohungsanalysen inkrementell entstehen. Man kann in den ersten Sprints beginnen, sobald ein erster (grober) Entwurf einer Architektur vorliegt. Die Ergebnisse der Analysen liefern Sicherheitsanforderungen, die in den folgenden Sprints umgesetzt werden müssen. Die Fortsetzung und Verfeinerung der Bedrohungsanalyse sollte entsprechend organisiert werden.

Zur Identifikation von Sicherheitsanforderungen in agilen Projekten hat sich die Verwendung von Abuse Stories bewährt. Über Abuse Stories können mit Hilfe von Security-Spezialisten zu einem frühen Zeitpunkt (d. h. innerhalb der ersten Sprints) gezielt Sicherheitsaspekte beleuchtet und Anforderungen abgeleitet werden. Das Arbeiten mit Abuse Stories sollte im Rahmen von Schulungen für Entwickler aufgenommen werden, damit "einfache" Abuse Stories auch ohne die Beteiligung von Spezialisten erarbeitet werden können.

Um einen hohen Automatisierungsgrad zu erreichen, empfiehlt sich die konsequente Nutzung von Delivery Pipelines, die "Continuous Integration" und "Continuous Deployment" (zumindest bis auf Test- und Abnahmeumgebungen) umsetzen. Grundsätzlich wird empfohlen, den Automatisierungsgrad der Security-Prüfungen so weit wie möglich (und wirtschaftlich sinnvoll) zu erhöhen und dabei - soweit vorhanden - auf KI-basierte Mechanismen zu setzen.

Vier Empfehlungen

1. Security-Spezialisten on Demand: Agile Projekte/Teams benötigen wegen der nicht planbaren Unwägbarkeiten im Security-Bereich flexiblen und unbürokratischen Zugriff auf Security-Know-how. Agil organisierte Security-Teams, die andere Teams/Projekte bei der Umsetzung sicherer Lösungen unterstützen, können hier eine Lösungsvariante sein.

2. Skalierbarkeit: Security-Teams müssen bei Bedarf kurzfristig über Rahmenverträge mit Externen skalieren können.

3. Vernetzung: Jede Organisationseinheit muss für sich sicherstellen, dass ihre Projekte/Teams angemessen vernetzt sind und z.B. ihre Interessen in übergreifenden Communities oder Gremien vertreten. Wichtig ist in dem Zusammenhang, dass der notwendige Freiraum und eventuelle finanzielle Mittel bereitgestellt werden. Eine "Software Security Group" mit Vertretern aus allen Business-Einheiten wäre ein Ansatz, um Best Pratices zu etablieren. Basierend auf dem Austausch können KPIs definiert und Aktivitäten verbindlich vereinbart werden.

4. Verbindliche Vorgaben: Die Gesamtorganisation sollte verbindliche Vorgaben in Betracht ziehen, um bestimmte Maßnahmen als verpflichtend einzustufen. Welche das sind, hängt von den Bedürfnissen der Organisation und den Compliance-Regeln ab, denen sie unterliegt.

Fazit

Security und agiles Vorgehen schließen sich nicht aus. Der Anwenderverband Cross-Business-Architecture Lab e.V., in dem 12 große Unternehmen und Organisationen aus dem deutschsprachigen Raum in Sachen EAM und digitale Transformation zusammenarbeiten, empfiehlt daher, dass Organisationen eine Governance-Struktur aufbauen, welche auch mit agilen Vorgehensweisen kompatibel ist und diese befähigt.

Des Weiteren sollten zentrale security-relevante Services bereitgestellt werden, und agilen Projekten/Teams der Zugriff auf diese Services (Wissen und Leistungen) so einfach wie möglich gemacht werden. Abschließend müssen agile Teams selbst für die Belange der Sicherheit sensibilisiert werden und diese in ihre tägliche Arbeit integrieren.

Wenn alle Komponenten zusammenspielen, findet sich eine Symbiose zwischen Agilität und Security, welche nachhaltig das Sicherheitsniveau in den Produkten, Leistungen und "Köpfen" steigert.

Gleichermaßen zu diesem Artikel beigetragen haben die EAM-Spezialisten und Mitglieder der Arbeitsgruppe Security im CBA Lab: Stefan Brüning, Matthias Gruber, Roland Paprotta, Martin Pettau, Annika Schewior, Luis Servín und Burkhard Trinder.