Sicherheitskonzeption in agilen Projekten

Der Verzicht auf starre Phasenabfolgen und ausführliche, umfassende und detaillierte Planungsdokumentation hat seinen Preis. Die Ermittlung maßgeblicher Sicherheitsanforderungen und die Erarbeitung eines geeigneten Satzes an Sicherheitsmaßnahmen, als wirksames Sicherheitskonzept, müssen flexibel gestaltet werden. Neben dem konkreten Schutzbedarf muss fallspezifisch auf den Entstehungsverlauf der abzusichernden Lösung und auf Rahmenbedingungen für das Projektteam reagiert werden. Entsprechende Geschicklichkeit und Optionen zum Miteinander der verschiedenen Spezialisten bei agilem Vorgehen müssen erlernt und eingeübt werden.

Im Vergleich zum Einsatz klassischer Vorgehensmodelle ist der Schatz an nachlesbaren „good and best practices“ zur Einbindung des Sicherheitsmanagements und der Sicherheits-Expertise im agilen Vorgehen noch gering. Dem Lernen aus Erfahrungen durchlaufener agiler Projekte kommt hier besondere Bedeutung zu. Der vorliegende Artikel versucht, über Beobachtungen und Hinweise aus der ComConsult-Projektpraxis ein paar Beiträge zu leisten.

Agilität – Strategieanpassung auch unter Sicherheitsgesichtspunkten

Die Erstellung und Weiterentwicklung umfangreicherer Software- und IT-Lösungen erfordert eine koordinierte und planvolle Vorgehensweise. Nur so können konkrete Anforderungen gezielt erfüllt, die Ergebnisse notwendiger Arbeitsteilung effizient zusammengeführt und die Lösung geeignet in eine bestehende Umgebung eingefügt werden.

Wer Software-Entwicklung nach einer klassischen Methodik gelernt hat, ist ein Top-Down-artiges Vorgehen in Form einer mehr oder weniger formalen Anwendung eines Wasserfall-Modells gewohnt. Der Weg von Anforderungsanalyse zum erfolgreich realisierten und getesteten Ergebnis, das in einen Routinebetrieb übergeben werden kann, folgt einem Phasenmodell. Am Ende jeder Phase steht ein definiertes Ergebnis mit vorgegebener Dokumentation, die als Ausgangspunkt der Folgephase erwartet wird. Bei strenger Anwendung dieser Strategie ist eine Rückkehr in eine vorherige Phase, also ein iteratives Vorgehen bei der Lösungsentwicklung, nicht vorgesehen.

Kommt eine Rückkehr in eine eigentlich abgeschlossene Phase der Methodik und eine Anpassung an einer zum Phasenabschluss abgenommenen Dokumentation dennoch vor, sieht dies nach notwendiger Korrektur von Schwächen in der eigentlich abgeschlossenen Phase aus. Aus Sicht eines streng angewendeten Wasserfallmodell-Ansatzes musste offenbar qualitativ nachgebessert werden.

Funktioniert eine solche Vorgehensweise im konkreten Fall gut, fallen Ressourcenmanagement sowie Aufgaben der Termin- und Ressourcenplanung vergleichsweise leicht, sobald die maßgeblichen Anforderungen feststehen. Kontrollen zu den Zwischenständen und Endergebnissen einer Phase können sich gut auf Festlegungen und die Dokumentation aus den jeweils vorangegangenen Phasen stützen. Projektmanagement und strukturierte Qualitätssicherung werden so vom Vorgehensmodell der Lösungsentwicklung erleichtert. Die entstehende Dokumentation zur Lösung und ihrer Entstehung ist umfassend und mit einem durch die Methodik gegebenen roten Faden gut nachvollziehbar.

Soweit die Theorie, möchte man spontan anmerken: Trotz strategischen Vorgehens in der Art eines Wasserfallmodells findet man oft Dokumentationen mit Schwächen und Lücken. Größere Software-Projekte mit entsprechendem Umfang der Lösung kommen zudem selten ohne eine Lernkurve im Verlauf des Projekts aus, sodass die eigentlich verpönten Iterationen anfallen. Wird die Wasserfallmethodik mit einem strengen Abnahmeformalismus je Phase verbunden, bremsen solche Notwendigkeiten zum Nachsteuern nach Lerneffekten den Projektfortschritt stark aus.

Die notwendige Lernkurve hat dabei Ursachen der folgenden Art:
Auftraggeber und Stakeholder für die benötigte Lösung oder für eine Anpassung an einer bestehenden Lösung sind damit überfordert, schon frühzeitig ihre Anforderungen umfassend und präzise zu äußern. Dies gilt für Anforderungen an Funktionalität, Gestaltung typischer Sicherheitsvorkehrungen, Details mit Blick auf Nutzerfreundlichkeit usw. Die Vorstellungskraft bzgl. Möglichkeiten und Nutzungsabläufen, die sich aus aktuellen Lösungsoptionen ergeben, reicht nicht aus. Das Festhalten an bisher Bekanntem und Gewohntem hilft nicht, da veränderter Bedarf bedient werden und die Chancen technischer Innovation genutzt werden sollen. Oft sind erst Muster in Form von Teillösungen nötig, um bei der Anforderungsermittlung voranzukommen.

Während der Entwurfsphase in einer präzisen Dokumentation alle Detailfragen bzgl. Machbarkeit der Umsetzung vorwegzunehmen und erfolgreich zu klären, kann überfordern, z. B. wegen Komplexität der geforderten Lösung oder bei Nutzung neuer Möglichkeiten.

Architekten und Entwickler brauchen die Möglichkeit, in der Praxis zu lernen, wie man innovative Optionen für Design und Implementierung einsetzt. Sie benötigen dabei auch das Feedback aus Sicht der späteren Nutzergruppen und Betreiber, um einen möglichst geeigneten Lösungsweg zu beschreiten.

Zudem muss die Möglichkeit bestehen, auf im Projektverlauf erlangte neue Erkenntnisse bzgl. Schwachstellen der genutzten Implementierungsbasis zu reagieren. Lösungsdesign, zugehörige Architektur und bereits als Teilleistung eigentlich abgenommene Ergebnisse aus dem bisherigen Projektverlauf dürfen dann nicht in Stein gemeißelt und bzgl. Änderungen tabu sein.

„Agile“ Elemente in Projektmanagement und Vorgehensweise geben eine mögliche Antwort auf die Frage, wie man mit der dargestellten Problematik umgehen kann. Kombinierende Ansätze aus grundlegend agilem oder klassischem und agilem Vorgehen sind erkennbar auf dem Vormarsch.

Unabhängig davon, für welchen Grad an Agilität und welche Hilfsmittel zur Koordination und Steuerung man sich dabei entscheidet: Völlig neu ist die Vorgehensweise und auch die sich dadurch ergebende Veränderung bei der Begleitdokumentation nicht. In der Informatik kennt man schon lange den Ansatz, komplexe Aufgabenstellungen in überschaubare Teilaufgaben zu zerlegen und sich so schrittweise eine Gesamtlösung zu erarbeiten.

Warum nicht einen solchen Teile- und Herrsche-Ansatz verfolgen, wenn der Anspruch, Anforderungsdefinition, Design und Implementierung in starr aufeinanderfolgenden Projektphasen auf Anhieb ohne Iterationsnotwendigkeit zu leisten, nicht beherrschbar erscheint? Teilaufgaben in Tickets mit User Stories zu erfassen, deren Anforderungen für sich umgesetzt und abgenommen werden können, ist dann nur eine mögliche Form der Anwendung dieser Strategie. Ein anarchisches Ausbrechen aus strukturiertem Vorgehen, rein aus Disziplinlosigkeit, ist das jedenfalls nicht, wenn man solche Methoden zielorientiert und koordiniert einsetzt.

Doch halt: Bleibt denn nicht die notwendige Informationssicherheit auf der Strecke, wenn man möglichst flexibel sein will und damit iterativ an Anforderungen und Design ändert? Wie soll man denn ein angemessenes, umfassend und prüfbar wirksames Sicherheitskonzept erstellen und implementieren, wenn laufend an der abzusichernden Lösung geändert wird?

In dieser Formulierung ist die Fragestellung unsauber und wird dem Anspruch an das Management von Informationssicherheit nicht gerecht. Es kann sogar sein, dass flexible Reaktionsmöglichkeiten durch Agilität eine aus Sicherheitserwägungen notwendig werdende Iteration erleichtert.

Gerade für Details der Maßnahmen eines Sicherheitskonzepts inklusive deren wirksamer Umsetzung gilt, dass flexibel reagiert werden muss, wenn neue Erkenntnisse im Projektverlauf bisherige „good practices“ und Risikoeinschätzungen infrage stellen.

Ein Beispielfall aus der Praxis: In der Entwurfsphase wurden bestimmte Lösungsdetails gemäß dem aktuellen Kenntnisstand als starke Sicherheitsvorkehrung eingestuft. Im Projektverlauf werden neue Erkenntnisse zu Angriffsvektoren bzw. Wirksamkeit gewählter Sicherheitsvorkehrungen bekannt. Im Konzept vorgesehene Lösungsdetails reichen gemäß diesem aktualisierten Kenntnisstand nicht mehr aus, müssen angepasst oder durch weitere präventive oder reaktive Maßnahmen ergänzt werden. Ein weiteres Beispiel: Zu einem Teil der für die Implementierung eigentlich vorgesehenen und schon eingesetzten Lösungsbasis werden akut Schwachstellen bekannt, für die auf absehbare Zeit keine das Problem beseitigende Verbesserung in Sicht ist.

In beiden Beispielen muss die ursprüngliche Sicherheitskonzeption revidiert werden. Nicht immer genügt dabei eine Feinanpassung im Bereich der Implementierung, etwa die Änderung von Parameterwerten, die einer Schwachstellennutzung den nötigen Riegel vorschiebt. Je nach Umfang des nötigen Eingriffs können neue sicherheitsrelevante Erkenntnisse Auswirkungen auf das Software-Design, eventuell zwecks Umgehung eines neuen Risikos sogar auf Teile der Lösungs-Architektur haben.

Gerade die hohe Dynamik in der Bedrohungslage kann somit jederzeit auf dem Weg von der Anforderungsdefinition bis zur Übergabe an den produktiven Betrieb dazu führen, dass nachgesteuert werden muss.

Agilität im Umgang mit solchen Anpassungsnotwendigkeiten kann hier sehr nützlich sein, um den zeitlichen Ablauf des Projekts bis zur betriebsfertigen und erfolgreich in die Zielumgebung integrierten Lösung nicht mehr als nötig zurückzuwerfen.

Agilität darf also nicht pauschal als Widerspruch zu dem Anspruch gesehen werden, eine bedarfsgerechte Sicherheitskonzeption zu erarbeiten und umzusetzen. Allerdings muss man unabhängig vom methodischen Weg, den man in der Software-Entwicklung und in IT-Projekten beschreitet, die Anforderungen des Sicherheitsmanagements erfüllen, also auch bei der Entscheidung zu agilem Vorgehen.

Informationssicherheitsmanagement ist ein Schwerpunkt im Risikomanagement. Relevante Risiken, die mit einer entstehenden Software-Lösung, ihrem Betrieb und ihrer Nutzung verbunden sind, müssen erfasst und bewertet werden. Überwiegend sind typische, je nach konkretem Sicherheitsbedarf auch besondere Vorkehrungen zur Entschärfung oder Vermeidung zu beschließen. Solche Vorkehrungen können als Aufgabenstellung in Entwicklungsaufgaben einfließen oder über flankierende Lösungen geleistet werden, die dann die Gesamtarchitektur beeinflussen. Ein Restrisiko kann nur ausnahmsweise punktuell und unter Beobachtung bewusst in Kauf genommen werden.

Eine entsprechend systematische und strukturiert analytische Handhabung von Informationssicherheitsrisiken ist zu leisten. Die zugehörige Dokumentation muss so detailliert und umfassend sein, dass mit ihrer Hilfe die Sicherheitskonzeption, Gründe für ihre Gestaltung sowie zugehörige (Rest-)Risikobewertungen nachvollzogen und einer Revision unterzogen werden können. Daran ändert sich nichts, wenn das Vorgehensmodell zur Lösungsfindung von agilen Ansätzen geprägt ist.

Agilität und Erarbeitung eines Sicherheitskonzepts: einige Herausforderungen

Aus den bisherigen Betrachtungen kann man erkennen: Schon die fallweise Bestimmung, ob und an welchen Stellen in einem Software- oder sonstigen IT-Projekt Ansätze klassischer bzw. agiler Vorgehensweisen nützlicher sind, kann eine knifflige Aufgabe sein. Man muss bei einer solchen Bestimmung passende Projektstrukturen gestalten und dabei flexibel auf den konkreten Fall eingehen. „Wir arbeiten agil“ für bestimmte Teile der Gesamtaufgabe reicht da nicht als Festlegung.

An dieser Stelle soll es allerdings nicht um dieses Abwägen zwischen agilen und klassischen Vorgehenselementen in einem Software-Projekt gehen. Vielmehr soll ein Blick aus der Praxis erfolgen, wie man agile Vorgehensweise mit den erläuterten Anforderungen zum Informationssicherheitsmanagement kombiniert, ohne dass die geübte Praxis bei der Agilität zu Problemen führt, gar selbst zum (Projekt-)Risiko wird.

Man versetze sich entsprechend in folgende Situation: Die begründete Entscheidung für einen Einsatz agiler Vorgehensweise bei der Entwicklung einer Lösung, inklusive bestimmter Formen und Hilfsmittel für Zusammenarbeit, Koordination und Begleitdokumentation ist gefallen.

Im Detail muss man nun auch gestalten, wie Entwicklungstätigkeit und Umsetzung technisch-funktionaler Anforderungen an die Lösung geschickt mit Erarbeitung und Umsetzung eines bedarfsgerechten, bewertbaren und freigabefähigen Sicherheitskonzepts kombiniert werden können. Als Rahmenbedingung wird eine übliche Arbeitsteilung in dem Sinne angenommen, dass Personen für die Erstellung des Sicherheitskonzepts zuständig sind, die sich auf Sicherheitsthemen, zugehöriges Risikomanagement und Bestimmung von Sicherheitsmaßnahmen konzentrieren.

Agile Vorgehensweise und sich dazu etablierende Hilfsmittel und Ansätze ändern die Rahmenbedingungen für die notwendigen Sicherheitsanalysen und Entscheidungen so, dass man lernen und üben muss, damit geschickt umzugehen. Eine „Schema F“-Organisation des notwendigen Miteinanders von Architekten, Entwicklungs- und Sicherheitsspezialisten, die man einfach irgendwo als Best Practices abschauen kann, wird man nicht erwarten können. Es soll ja flexibel auf Unerwartetes im Entstehungsprozess der zu schaffenden Lösung reagiert werden können – so kam es zur Entscheidung für die agilen Vorgehenselemente. Der hier nötige Lernprozess und Erfahrungsschatz ist in der Praxis längst nicht so weit fortgeschritten wie beim Einsatz klassischer Vorgehenselemente.

Trotzdem können aus erster Praxiserfahrung sowohl wichtige Beispiele für das Pannenpotenzial gegeben werden als auch erste Tipps, die je nach konkreter Situation nützen können. Dies versucht dieser Artikel im Weiteren, gestützt auf die Praxis erster derartiger Vorgänge. Die zugehörigen Erfahrungen stammen aus der Perspektive von Personen, die in Software- und IT-Projekten mit agiler Vorgehensweise an Sicherheitsanalysen und Erstellung der Sicherheitskonzeption mitgewirkt haben.

• Agilität: Anforderungen, Teilaufgaben zur Umsetzung und zugehörige Prüfpunkte entstehen Zug um Zug.Trotzdem muss man rechtzeitig mit Sicherheitsanalysen und Festlegung von Sicherheitsmaßnahmen ansetzen, um nicht böse Überraschungen bzgl. umfangreicher Änderungsnotwendigkeiten aus Sicherheitsgründen zu erleben.
• Lösungswege zu Teilaufgaben und dabei genutzte technische Elemente werden gemäß agiler Vorgehensweise ebenfalls nach und nach beschlossen. Sie werden dabei teilweise nach Proof-of-Concept-Tests oder als Reaktion auf Wünsche eines Stakeholders oder Auftraggebers relativ kurzfristig nochmals revidiert.Bewertungen von Sicherheitsrisiken und die resultierende Sicherheitskonzeption müssen da flexibel „mitgehen“. Voraussetzung dafür, dass dies genügend zeitnah erfolgt, um entstehende Detail-Sicherheitsanforderungen bei der Umsetzung sofort mit zu berücksichtigen, ist ein guter Informationsfluss in Richtung Sicherheitsspezialisten über neue Beschlüsse.
• Die mit den genannten Punkten verbundene schrittweise Entscheidungsfindung ist in der Praxis der agilen Vorgehensweise sehr „besprechungsintensiv“.Gehören viele Personen standardmäßig zum Kreis der an vielen Besprechungsterminen Beteiligten, bedeutet dies eine hohe Kapazitätsbindung. Ist eine Einbindung von Sicherheitsspezialisten in möglichst viele Besprechungen im konkreten Fall ein effizienter Weg, um den benötigten guten Informationsfluss zu realisieren?Können Besprechungsprotokolle die Lösung sein, insbesondere als Informationsquelle, über die Sicherheitsexperten selbständig erkennen, wann sie sich einbringen müssen? Das ist eher schwierig. Entweder sind Besprechungsprotokolle bei agilem Vorgehen eher „knapp“, oder man verfehlt durch Abkehr vom Wasserfall-Phasenformalismus das Ziel, den Dokumentationsaufwand zugunsten der Implementierungszeit signifikant einzusparen.
• Bei agilem Vorgehen entsteht aus Sicherheitsperspektive die Ergebnisdokumentation zu Lösungs-Design und -Entwicklung schleppender und zum Teil mit geringerer Aussagekraft als bei klassischem Vorgehen.Die über Besprechungsnotizen, Aktivitätsplanung und Tickets hinausgehende Dokumentation bleibt vorerst oft Stückwerk und dabei teilweise skizzenhaft. Das Entwicklungs-Team mag auf dieser Basis wissen, was es zu tun hat. Für eine Sicherheitsanalyse ist dies in vielen Fällen unzureichend, man muss gezielt nachfassen, unter Fokus auf sicherheitsrelevante Gesichtspunkte. Dazu muss man mit gezielten Klärungsfragen aus der Sicherheitsperspektive auf geeignete Ansprechpartner zugehen und hierfür Termine finden.

Mit derartigen Eigenheiten des agilen Vorgehens ist so umzugehen, dass die Sicherheitsperspektive nicht in schädlicher Weise zu lange außen vor bleibt. Andernfalls provoziert man vermeidbaren Korrekturbedarf durch verspätet erkannte Sicherheitsrisiken. Die agile Vorgehensweise mag dann den Umgang mit solchem Korrekturbedarf erleichtern, die durch die Korrekturaktivitäten entstehende Mehrarbeit bleibt ärgerlich und gefährdet Terminziele.

Speziell der Aspekt der schrittweise entstehenden Lösungsdokumentation muss mit Blick auf die erläuterten Risikomanagement-Aufgaben wachsam begleitet werden. Soweit die technische Lösungsdokumentation erst zum Projektabschluss vervollständigt wird, erfolgen entsprechende Ergänzungen der noch lückenhaften Unterlagen ohne den Druck, hierüber dem Entwicklungsteam notwendigen Input zu geben. Hier besteht ein entscheidender Unterschied zur strengen Phasenreihenfolge gemäß Wasserfallmodell und der dabei erforderlichen Dokumentation. Typisches Resultat beim „Nachdokumentieren“ am Ende eines agilen Projekts: Jetzt erst erstellte Teile der Dokumentation sind eher eine Kurzzusammenfassung der entstandenen Lösung als eine umfassende Spezifikation und Umsetzungsbeschreibung. Eine solche Dokumentation ist als Basis für nötiges Verständnis und darauf aufbauende, knapp formulierte Sicherheitsanalysen und -bewertungen entsprechend eingeschränkt geeignet. Für eine zugehörige Sicherheitskonzeption bedeutet dies:

Damit strukturierte Sicherheitsanalysen und zugehörige Stellungnahmen und Bewertungen zum Umgang mit Sicherheitsanforderungen und Restrisiken verständlich sind, muss das Sicherheitskonzept die geringere Ausführlichkeit der technischen Konzeption ausgleichen.

Dies ist kein „methodischer Fehler“ der Agilität. Konzentriert sich bei agilem Vorgehen die abschließende Aufbereitung von Lösungsdesign, Lösungsarchitektur und Implementierung auf knappe Darstellung des Ergebnisses, ist dies nicht pauschal als unzulängliche technische Dokumentation abzulehnen. So lange für die weitere Wartung und Weiterentwicklung der Lösung eine solche Dokumentation inklusive zugänglicher Programmiercodes und Soll-Konfigurationsdateien als Arbeitsbasis ausreichen, sind wesentliche Aufgaben der technischen Dokumentation erfüllt.

Man muss sich jedoch klarmachen, dass sich unter solchen Umständen der Aufwand im Rahmen der Gesamtdokumentation signifikant in Richtung Erstellung von Sicherheitsanalysen und Sicherheitskonzeption verschieben kann: Es ist unzweckmäßig, wenn man als Voraussetzung API-Call-Spezifikationen, Programmiercode usw. studieren muss, um Sicherheitsbewertungen nachvollziehen zu können.

In einem zugehörigen Sicherheitskonzept muss unter solchen Umständen zur Kompensation zunächst relativ ausführlich dargestellt werden, was abzusichern ist. Erst dann kann aus Security-Sicht gut nachvollziehbar spezifiziert werden, wie die Absicherung erfolgt und dass damit ein akzeptables Sicherheitsniveau erreicht wird. Dies muss bei der Ressourcen- und Zeitplanung für die Sicherheitskonzeption berücksichtigt werden, und es sind klare Absprachen in diesem Sinne nötig. Auch diese können „agil“ erfolgen, als fallweise Reaktion, wenn beim ersten Versuch notwendiger Analysen und Konzeptarbeiten zu Sicherheitsaspekten ein eher dünner Zustand an technischer Dokumentation vorgefunden wird. Wichtig ist jedoch, dass rechtzeitig Klarheit geschaffen wird, wie groß die Anteile des Sicherheitskonzepts an einer Beschreibung der abzusichernden Lösung sind.
Auf dieser Basis kann man dann sogar koordiniert und gezielt „voneinander abschreiben“, Beispiele:

Übersichtsbilder aus der technischen Dokumentation lassen sich oft auch für eine eher ausführliche Darstellung im Sicherheitskonzept, was überhaupt abzusichern ist, geschickt verwenden. Erfahrungsgemäß entstehen solche Bilder gerade bei agiler Design- und Lösungsfindung ziemlich sicher. Grafische Darstellungen als Basis einer Abstimmung in Besprechungsform funktionieren meist besser als eine Besprechungsvorbereitung auf Textbasis. Verwenden als Resultat die technische Ergebnisdokumentation und Sicherheitsdokumentation die gleichen Bilder (im Sicherheitskonzept evtl. auch ausschnittsweise an mehreren Stellen), schafft dies eine gute und intuitive Klammer für das Gesamtverständnis.

Umgekehrt kann man versuchen, für die abschließende Vervollständigung der technischen Dokumentation auf zwischenzeitlich entstandene Textpassagen aus Sicherheitsanalysen und Sicherheitskonzept zurückzugreifen. Siehe oben: Zum verständlichen Einstieg in Sicherheitsanalysen und -konzept muss zunächst oft Input aus verschiedener Begleitdokumentation des agilen Vorgehens in einem beschreibenden Text, rund um übernommene Design-Bilder, zusammengeführt werden. Warum dies nicht als Vorleistung für die technische Dokumentation nutzen? Vorteile: Es erfolgt zwangsläufig eine inhaltliche Qualitätssicherung des Beschreibungstexts aus der Sicherheitsdokumentation. Danach erfolgendes Copy & Paste schafft sofort konsistente Inhalte der verschiedenen Dokumentationsbestandteile.

Gelingt es gar, dieses wechselseitige Übernehmen von Dokumentationsteilen kontinuierlich projektbegleitend zu praktizieren, arbeitet man unwillkürlich auch inhaltlich zusammen, ohne dafür regelmäßig in den gleichen Besprechungsterminen zu sitzen. Missverständliche oder an wichtigen Stellen ungenaue Darstellungen bzw. Beschreibungen fallen auf, können geklärt und verbessert werden. Das Gleiche gilt für die fehlende Aktualisierung: Zwischenzeitliche Widersprüche im agil entstehenden Ticket- und Dokumentationspuzzle entstehen oft durch fehlende Aktualisierung von Bildern oder Texten, aus Zeitmangel. Fällt so etwas beim Copy- & Paste-Versuch als Plausibilitätsproblem auf, kann man sich gegenseitig darauf hinweisen. Wer die Aktualisierung vornimmt und dann an beiden Stellen für den aktuellen Stand sorgt, kann sogar fallweise abgesprochen werden und wechseln. So variabel die Rahmenbedingungen für Sicherheitskonzept-Arbeiten in agil angegangenen Software-Vorhaben sind, so wenig hilfreich wäre der Versuch, an dieser Stelle goldene Regeln oder Ähnliches anzubieten, mit denen man Herausforderungen der beschriebenen Art „garantiert“ in den Griff bekommt.

Hilfreicher sind da Erfahrungen aus konkreten, agil angegangenen Software-Vorhaben und der Versuch, aus diesen zum nächsten konkreten Fall Passendes auszuwählen.

Einbindung von Sicherheitsanalysen und -experten in agile Projekte: einige Tipps

Nachfolgend wird eine Auswahl positiver Beobachtungen aus der Mitwirkung an Software-Projekten mit agiler Vorgehensweise angeboten. Eine entsprechende Nachbetrachtung kann gerade bei solchen Vorgängen nützlich sein, um den „Werkzeugkasten“ zur Ablaufgestaltung für zukünftige Fälle zu erweitern, die ebenfalls hohe Flexibilität und agiles Vorgehen benötigen.

Was ist im jeweiligen Projekt „gut gelaufen“, sodass die Erarbeitung des Sicherheitskonzepts nicht als Fremdkörper, sondern möglichst als integrierter Teil der Aktionen zur Lösungsgestaltung und Entwicklungssteuerung gewirkt hat? Ohne Anspruch auf Vollständigkeit werden nachfolgend entsprechende Beispiele gegeben, was in diesem Sinne hilfreich sein kann – „so erlebt“, bei passenden Rahmenbedingungen also machbar.

• Frühzeitiges Festlegen, Regeln und Schaffen von Dokumentationsorten und Zugängen: So fördert man Informationsfluss und vermeidet ungewollte „Geheiminformationen“.Wird frühzeitig festgelegt, welche Art von Planungs-, Vorgangs- und Ergebnisdokumentation entstehen soll und wo sie abzulegen ist, wird das Entstehen von versteckten Schätzen an vorläufigen Ablageorten weniger wahrscheinlich. Die Ablage von Zwischenständen erfolgt bei ein bisschen Disziplin mindestens in Kopie an Orten, wo berechtigte Personen sie jederzeit sichten und von ihrer Existenz und ihrem Zustand Kenntnis nehmen können.Ergänzt man dies noch mit einer groben, jedoch über Namensgebung der Teilbereiche leicht verständlichen Struktur von Ablagebereichen, füllen sich solche Ablagen erfahrungsgemäß auch kontinuierlich. Wichtig dabei: Man klärt bei Hinzukommen einer neuen Person zum „Projektteam“ sofort, welche Information diese nutzen bzw. selber erzeugen soll. Die entsprechenden Berechtigungen für den Neuzugang sollten dann zügig initiiert werden, nicht erst auf Nachfrage.

  Der Rest ist dann Nutzung von Angeboten der technischen Ausstattung:

  Der Neuzugang wird sich, evtl. nach einer kurzen Einführung, selbständig einen Überblick über die zugängig gemachten Informationsmöglichkeiten bilden. Gerade als Nachrücker (häufige Situation derer, die für Sicherheitsanalysen und -konzepte zuständig sind) kann man sich dann strukturiert „einlesen“ und sich auf gezielte Verständnisfragen beschränken. Eine noch so gut gemeinte und ausführliche mündliche „Druckbetankung“ kann da selten einen gleich guten Einstieg bieten – Informationsbedarf und Sichtweisen der verschiedenen „Spezialisten“ sind zu unterschiedlich.

  Wenn noch geschickt mit der Aktivierung von Benachrichtigungsautomatismen bzgl. „Neuigkeiten in der Doku“ gearbeitet wird, bekommen z.B. für Sicherheitsthemen Zuständige frühzeitig mit, wenn sich etwas für ihren Fokus Relevantes tut. Man muss dann für solche News nicht an möglichst vielen Besprechungen teilnehmen und auch nicht zeitnah alle Besprechungsprotokolle sichten, nur um nicht den Zeitpunkt zu verpassen, an dem man sich einbringen oder nachhaken sollte.

• Saubere Führung und bewusstes Schließen machen Tickets zur wertvollen Information.Wird ein Teilaspekt als mögliche Lösungseigenschaft in agile Abstimmungen aufgenommen und genauer betrachtet, wird typisch ein zugehöriges Ticket angelegt. Entscheidet man sich für die Realisierung, lässt sich die Möglichkeit schaffen, über das Ticket einsteigend, die Zielsetzung, Prüfpunkte für eine erfolgreiche Umsetzung und nötigenfalls notwendige Feinabstimmungen (Kommentare, Verweise auf zugehörige Besprechungstermine) nachvollziehen zu können.Für Sicherheitsanalysen und die Sicherheitskonzeption können solche Tickets als klarer Input dienen. „Umgesetzte“ Tickets machen gezielt getroffene Entscheidungen zum Design sichtbar, die durch vorgeschlagene Optionen an Sicherheitsmaßnahmen nicht unnötig wieder infrage gestellt werden sollten.

  Sie können zudem helfen, Sicherheitsbetrachtungen zu triggern und zu steuern. Die Beschreibung des Zwecks (Wozu dient das gemäß Ticket vorgesehene Lösungselement?) kann Impulse und Hilfestellung für gezielte Risikobetrachtungen geben:

  Eine als Anforderung hoch eingestufte Funktionalität sollte insbesondere bzgl. Sicherung ihrer Verfügbarkeit besonders im Auge behalten werden. Ist erkennbar, dass das Ticket einen Informationen verändernden Vorgang zum Thema hat, lohnt eine besondere Beleuchtung des Aspekts „Prüfung und Sicherstellung korrekter Ergebnisse“ des Vorgangs. Auch kann geprüft werden, inwiefern es sinnvoll ist, die eigentliche Nutzdatenverarbeitung um die Erzeugung von Hilfsinformationen an dieser Stelle zu ergänzen, deren Überprüfung auf nachträgliche Nutzdatenverfälschungen an den nachfolgenden Zwischenstationen erleichtert wird.

  Werden für die Sicherheitskonzeption zuständige Personen auf solche Ticket-Inhalte aufmerksam, können sie sich in die Feinabstimmung einschalten, wie beschrieben die Aspekte Verfügbarkeitssicherung und Integritätsschutz gezielt adressieren und bei Einigkeit über den entsprechenden (erhöhten) Bedarf Maßnahmenoptionen zur Diskussion stellen.

  Zielt das Ticket gar auf ein Lösungselement ab, das die unbefugte Kenntnisnahme von Informationen gezielt erschwert, sind dies und der Umgang mit dieser Designidee unmittelbar relevant für die Sicherheitskonzeption, Schwerpunkt Vertraulichkeitsschutz. Bei einer Umsetzung, die aus dem Ticket hervorgeht, kann dieser Sicherheitsbeitrag natürlich sofort im Sicherheitskonzept erfasst und bei weiteren (Rest-)Risikobetrachtungen als Gegebenheit berücksichtigt werden.

  Das aktive Schließen eines Tickets markiert einen neuen Zustand des Designs der schrittweise und agil entstehenden Lösung. Das ist beim Arbeiten am Sicherheitskonzept auch dann beachtenswert, wenn das Ticket mit dem Ergebnis „keine Umsetzung“ abgeschlossen wird.

  Wurde eine im Ticket spezifizierte Designidee verworfen, braucht sie auch nicht abgesichert zu werden.

  Wäre der verworfene Ticketgegenstand ein besonderer Sicherheitsbeitrag gewesen, ist das Notieren des Grundes für ein „Nein“ wichtig, sowie die beteiligten Rollen. Wurde der konkrete Sicherheitsbedarf als zu gering eingeschätzt, um die Idee weiter zu verfolgen, kann das direkt in die formale, dokumentierte Risikobewertung einfließen. Es ist dann auch wenig sinnvoll, die verworfene Maßnahme über einen Entwurf zum Sicherheitskonzept nur deswegen noch einmal zur Diskussion zu stellen, weil es um eine „good-practices“-Option (Standard-Sicherheitsmaßnahme) geht. Wer als Sicherheitsexperte die begründete Entscheidung im Ticket gelesen hat, wird in diese Falle nicht hineintappen. Es wird ein nochmaliges Besprechen des schon Entschiedenen vermieden.

  Waren nicht der konkrete Sicherheitsbedarf oder schon ausreichend wirkende andere Sicherheitsmaßnahmen der Grund für das Verwerfen der Idee, ist aus der Sicherheitsperspektive heraus aufzuhorchen. Ist das verbleibende Restrisiko aufgrund des Auslassens einer im Ticket betrachteten Sicherheitsoption nicht an sich vernachlässigbar, kann es aus Risikomanagement-Sicht angesagt sein, dies als kalkuliert akzeptiertes Restrisiko zu notieren, das es zu beobachten gilt. Eine Person, die für eine entsprechende Risikoentscheidung autorisiert ist, sollte über das Ticket als an der Entscheidung beteiligt erkennbar sein, sonst ist sie mindestens nachträglich zu informieren. Der Vorgang des begründeten Verzichts auf eine mögliche Risikoreduzierung lässt sich als Risikomanagement-Dokumentation in den Sicherheitsanalysen notieren. Eine Person, die für eine formale Bestätigung der „Risikoinkaufnahme“ herangezogen wird, ist, ausgehend vom Ticket, leicht gefunden, wenn sie selbst im Ticket als beteiligt erkennbar ist oder über eine beteiligte Person per Delegierungsprinzip vertreten war.

  Warnhinweis: Tickets, die nach dem Anlegen nicht weitergeführt werden (Idee verworfen und Ticket offen gelassen, oder nach schneller mündlicher Absprache und Umsetzung den Ticketabschluss vergessen), lassen solche Chancen liegen. Sie „leisten“ eher das Gegenteil. Sie können bei dem Versuch zur Nutzung des Ticketsystems als Quelle für Sicherheitsanalysen Verwirrung stiften und unnötig Zeit durch vermeidbares Nachfragen binden. Ein Ticket, das ohne weitere Begründung einfach geschlossen wird, ist da nicht besser. Nicht bei manuellem Abschluss und noch weniger bei automatischem Schließen per Ticket-System, nach mehrmaliger Wiedervorlage ohne Reaktion.

• Es lohnt sich, den Einsatz von Verschlüsselung frühzeitig mindestens grundlegend zu klären.Ob Verschlüsselung eingesetzt wird, ist in der Regel gar nicht die Frage. Wo und wie sie eingesetzt werden soll oder kann, hat allerdings weitreichende Konsequenzen. Wo sollte oder muss Kommunikation verschlüsselt werden? Wo reicht das nicht aus, sondern es wird eine Verschlüsselung der Nutzdaten gefordert oder ist zumindest als Option zu betrachten? Wie sehen Auflagen und Rahmenbedingungen für die Bereitstellung und Verwaltung von Schlüsselmaterial aus? Durch wen und auf welcher technischen Basis sollen Beiträge zum Schlüsselmanagement geleistet werden?Die Praxis lehrt: Hier muss man mit Überblick herangehen und die Verhältnismäßigkeit wahren. Sicherheitsanalysen, zumindest in erster grober Form, sind für die Verhältnismäßigkeit wesentlich. Es geht um mehr als nur Details wie Verschlüsselungsmethode und Schlüssellängen, bei denen man agil bedingt noch leicht austauschen und anpassen kann. Architekturentscheidungen zur Schlüsselverwaltung können festlegen, welche Elemente der Gesamtlösung welche Beiträge leisten müssen. Soll man entsprechende Services als Teil der Programmierleistung realisieren, oder sind spezialisierte Lösungen (vorhandene PKI, bei erhöhtem Sicherheitsbedarf auch intelligente Hardware-Sicherheitsmodul-Produkte) einzubinden? Wo verhindert ein verschlüsselter Zustand von Informationen Inhalts-Checks, sodass man diese an anderer Stelle platzieren muss? Inwiefern ist es wichtig, für verschlüsselte Daten „unterwegs“ zumindest Integritäts-Checks vornehmen zu können, um nicht erst am Ende einer langen Kette von Übergaben und der Zwischenspeicherung wieder entschlüsselte Daten zu prüfen, die sich dann als unbrauchbar herausstellen?

  Solche Fragen erst nach und nach zu klären und dabei auf erkannte grundlegende Probleme immer wieder agil reagieren zu müssen, kann den Projektfortschritt mehrfach empfindlich zurückwerfen. Das hat schnell die Negativ-Qualität von einer bei strengem Wasserfall-Modell erst in der Integrationstestphase auffallenden, grundlegenden Designschwäche.

• Die Nutzung spezialisierter Sicherheitskomponenten muss man gezielt „bestellen“.Eine zu entwickelnde Lösung wird meist nicht inselartig genutzt. Sie wird dann zwangsläufig in eine bestehende, mit Sicherheitsübergängen und -gateways ausgestattete Kommunikationsinfrastruktur eingegliedert. Die Nutzung bestimmter Funktionalitäten solcher Übergänge ist eine grundlegende Strategie von Sicherheitskonzeptionen nach „good practices“. Entsprechende Funktionalitäten werden von den Sicherheitskomponenten auch unterstützt – jedoch nicht umfassend für jede „Freischaltung“ eines Kommunikationsdurchgangs auch automatisch aktiviert bzw. gezielt eingerichtet.Hier ist bewusste Abstimmung nötig. Die Erfahrung lehrt: Nachdem die grobe Architektur der zu entwickelnden Lösung feststeht und man eine „Kommunikationsmatrix“ hat, wer mit wem netzbasiert interagieren wird, lohnt sich ein gezieltes Abstimmungsgespräch.

  Wer die Möglichkeiten der Nutzung und Feineinrichtung vorhandener Sicherheitskomponenten auf den erkennbaren Kommunikationswegen kennt, kann diese auf aktuellem Stand (nochmal) vorstellen. Hat man sich einen Überblick über Kommunikationsbeziehungen, dabei genutzte Protokolle und transportierte Inhalte verschafft, kann man dann konkret beraten, was von den Möglichkeiten der Sicherheitsübergänge gezielt genutzt werden kann und soll. In der Praxis zu beobachtende Vorteile frühzeitiger Abstimmung dieser Art: Man vermeidet ein Ping-Pong von Rückfragen und schrittweisen Genehmigungen zu Service-Tickets, über die beim Betreiber der Sicherheitskomponenten benötigte Freischaltungen und Feineinrichtung auf Sicherheitskomponenten zu beantragen sind. Entscheidungen zu Sicherheitsbeiträgen durch die genutzte Infrastruktur, die bei der Festlegung der Sicherheitskonzeption ohnehin zu treffen sind, können schon in frühen Testphasen umgesetzt sein. Bereits bei ersten Tests können solche Sicherheitskomponenten beim probeweisen Zugriff auf Implementierungsstände in Entwicklungs- und Testumgebung integriert werden. Dann erfolgen diese Tests so nahe wie möglich an der späteren Produktivsituation. Unverträglichkeiten der bislang bewährten Grundkonfiguration von Sicherheitskomponenten mit der neuen, in Entwicklung befindlichen Lösung zeigen sich frühzeitig. Sicherheitsexperten können dann gezielt hinzugeholt werden, sodass notwendige Änderungen an der Feineinrichtung sofort dahingehend betrachtet werden, ob das Resultat akzeptabel sicher ist oder flankierende Maßnahmen erforderlich macht.

  So setzt Agilität an vorteilhafter Stelle ein, und nicht erst hektisch kurz vor einem Projektende, bei dem auf Nachforderung aus Sicherheitsanalysen oder Sicherheits-Scans besondere Funktionalitäten von Sicherheitskomponenten abschließend aktiviert werden – und es dann „knallt“.

• Erstmals eingesetzte Lösungsmöglichkeiten gezielt von Sicherheitsexperten durchleuchten lassen – frühzeitig eingeplant und initiiert hilft dies an vielen Stellen.Auch wenn man aus eigener Sicht einen Lösungsweg, gar eine hoch-innovative Lösungsmöglichkeit zum ersten Mal einsetzt: Ist man wirklich der Erste, der dies tut? Oftmals nicht, und dann gilt: Erste Erkenntnisse zu Sicherheitsaspekten in diesem Zusammenhang wird es geben, man muss sie nur kennen bzw. finden.Dies ist die Domäne von auf Sicherheit spezialisierten Personen und Bereichen, entweder im eigenen Haus, oder als externe Wissensträger hinzuziehbar. Es lohnt sich, so spezialisierte Personen zeitnah nach der Entscheidung zum erstmaligen Einsatz eines Lösungselements einzuschalten. Diese können dann gezielt recherchieren, beraten, „good-practice“-Informationen einbringen, erste Implementierungsentwürfe unter Sicherheitsgesichtspunkten sichten, typische Tests vorschlagen, sich bzgl. Lesart entsprechender Testergebnisse „belesen“, usw. Wer dies frühzeitig initiiert, schafft Luft für den eventuell nötigen Vorlauf, der entsprechendes Wissen und entsprechende Abstimmungen so ermöglicht, dass man mindestens erste grobe Pannen oder Unterlassungssünden bzgl. Sicherheit vermeidet. Danach kann man nötigenfalls im Detail agil nachbessern und ergänzen, ohne viel Arbeit aus ersten Entwicklungsschritten und Sprints zur Nutzung der „neuen“ Lösungsmethode noch mal machen zu müssen.

  Zusatztipp: So einmal gemeinsam erarbeitete und per Tests, Sicherheits-Revision und Scans etc. erprobte Implementierungswege sollte man im Haus „weitererzählen“! Hier lohnt sich in jedem Fall eine vom konkreten Projekt unabhängige Kurzdokumentation, was man wie gelöst hat, inklusive Detaillierungsgrad „Musterkonfiguration“ o.Ä. Je nach Thema ist sogar eine „Guideline zur Entwicklung bei Nutzung von XXX“ sinnvoll, wenn die mühselig abgestimmten und getesteten Details umfangreich waren – oder, wenn zur eingesetzten Technik von gängigen Sicherheits-Prüfkatalogen ein solches Vorgabedokument gefordert wird!

  Parallel laufende oder gerade startende Projekte mit eigenen Teams, die auch mit dieser Neuerung als Lösungsbasis arbeiten wollen, können einen solchen Input dann kurzfristig aufnehmen und in die weiteren Arbeiten einfließen lassen. Agiles Vorgehen schafft hierfür gute Voraussetzungen. Warum also riskieren, das Rad im eigenen Haus unnötig mehrfach zu erfinden?

Wie angekündigt war dies nur eine Auswahl von Beobachtungen aus der Erarbeitung von Sicherheitsanalysen und darauf basierenden Sicherheitskonzepten in agil geführten Projekten. Sie reichen jedoch zur Vermittlung des Eindrucks, dass es oft um die Vermeidung von Schwächen bei Informationsfluss, geschickt koordiniertem Vorgehen und Dokumentationsqualität geht. Diese kommen in der Praxis unabhängig vom Vorgehensmodell vor. Allerdings ist man bei der agilen Vorgehensweise in frühen Stadien der Lösungsfindung und -realisierung darauf angewiesen, solche Schwächen aktiv

• durch geschickten Einsatz der gewählten Methoden und Hilfsmittel zu vermeiden bzw.
• über Treffsicherheit die Zeitpunkte der Einbindung von Sicherheits-Know-how rechtzeitig zu erkennen. Rechtzeitig heißt hier, dass man den Agilitätsansatz durch schnelles Gegensteuern so nutzen kann, dass möglichst wenig Zeit durch Korrigieren und Nachbessern an bereits implementierten Teilen der Lösung verloren geht.

Feste Zeitpunkte der Qualitätssicherung einer umfassenden Dokumentation der Anforderungen, Grobplanung und Lösungsdesign, sind bei der agilen Methodik als Quelle einer derartigen Früherkennung nicht gegeben. Diese Option entfällt zu großen Teilen zugunsten einer Zeitersparnis bei der vor Implementierung erfolgenden Dokumentation. Also muss man im agilen Projekt Trigger und Zeitpunkte „organisieren“, über die prüfendes und analytisches Know-how geschickt eingebunden wird, insbesondere Sicherheits-Expertise. Einige Beispiele und Tipps wurden gegeben.

Nach diesem Vorbild kann man weiter überlegen und aus eigenen agilen Projekten durch Nachbetrachtung lernen.