agile development vs. security requirements · thema: agile development vs. security requirements...

Seminararbeit

Agile Development vs. SecurityRequirements

Mirco Stickan16. Juli 2013

Gutachter: Prof. Dr. Jan JurjensDipl.-Inform. Daniel Poggenpohl

Prof. Dr. Jan Jurjens Lehrstuhl 14 Software EngineeringFakultat InformatikTechnische Universitat DortmundOtto-Hahn-Straße 1444227 Dortmundhttp://www-jj.cs.uni-dortmund.de/secse

Mirco [email protected]: 127029Studiengang: Master Informatik

Seminar Sicherheit und SoftwareengineeringThema: Agile Development vs. Security Requirements

Eingereicht: 16. Juli 2013

Betreuer: Daniel Poggenpohl

Prof. Dr. Jan Jurjens Lehrstuhl 14 Software EngineeringFakultat InformatikTechnische Universitat DortmundOtto-Hahn-Straße 1444227 Dortmund

iii

Ehrenwortliche Erklarung

Ich erklare hiermit ehrenwortlich, dass ich die vorliegende Arbeit selbststandig ange-fertigt habe; die aus fremden Quellen direkt oder indirekt ubernommenen Gedankensind als solche kenntlich gemacht.

Die Arbeit wurde bisher keiner anderen Prufungsbehorde vorgelegt und auch nochnicht veroffentlicht.

Dortmund, den 16. Juli 2013

Mirco Stickan

INHALTSVERZEICHNIS v

Inhaltsverzeichnis

1 Einleitung 11.1 Motivation und Hintergrund . . . . . . . . . . . . . . . . . . . . . . . 11.2 Aufbau der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Agile Softwareentwicklung 32.1 eXtreme Programming . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1.1 Prinzipien des eXtreme Programming . . . . . . . . . . . . . . 42.1.2 Praktiken des eXtreme Programming . . . . . . . . . . . . . . 5

2.2 Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2.1 Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2.2 Rollen in Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.3 Zwischenfazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3 Sicherheit in agiler Softwareentwicklung 113.1 Sicherheit in eXtreme Programming . . . . . . . . . . . . . . . . . . . 11

3.1.1 Abuse Case Modell . . . . . . . . . . . . . . . . . . . . . . . . 123.1.2 Abuser Stories . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.2 Sicherheit in Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.2.1 S-Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.2.2 Security Backlog . . . . . . . . . . . . . . . . . . . . . . . . . 18

4 Zusammenfassung 21

Literaturverzeichnis 23

vi INHALTSVERZEICHNIS

KAPITEL 1. EINLEITUNG 1

1 Einleitung

Die vorliegende Arbeit beschaftigt sich mit agilen Software Entwicklungsmethoden.Im Gegensatz zu traditionellen Vorgehensmodellen, nutzen diese Verfahren itera-tive Arbeitsablaufe und enge Zusammenarbeit mit dem Kunden. Sie basieren aufdie Idee des Spiralmodells [2]. Ziel agiler Entwicklung ist es, schnellstmoglich einenlauffahigen Prototypen (Rapid Prototyping) zu generieren, an dem durch das regel-maßige Feedback des Kunden, Schritt fur Schritt einzelne Funktionen implementiertwerden.

Durch geringe Dokumentation und kurze Planungsphasen stehen agile Softwareent-wicklungsmethoden immer wieder in der Kritik, fur sicherheitskritsche Systeme nichtgeeignet zu sein. Die Entwicklung der letzten Jahre beweist jedoch das Gegenteil.Durch Anpassungen der agilen Entwicklungsablaufe, das so genannte Security Engi-neering, verbessert werden konnte und somit Sicherheit und agile Entwicklung nichtmehr im direkten Konflikt zueinander stehen.

1.1 Motivation und Hintergrund

Die Vorgehensweise der Softwareentwicklung hat sich in den letzten 20 Jahren signi-fikant verandert. Wahrend in den neunziger Jahren und zu Beginn des zwanzigstenJahrhunderts ein dokumentengetriebener Ansatz der Programmierung dominierte,erfahren in den letzten Jahren agile Softwarentwicklungsmethoden zunehmende Be-liebtheit [10].

Ein Beispiel fur den klassischen Entwicklungsansatz ist das Wasserfallmodell [2].Dieses definiert einen genauen Ablauf der Entwicklungsarbeit, bestehend aus An-forderungsanalyse, Entwurf, Implementierungs- und Testphase, sowie der Einfuh-rung des Systems. Das Modell wurde zunachst nicht iterativ entwickelt, wobei ineiner spateren Uberarbeitung Rucksprungmoglichkeiten in die einzelnen Phasen alsnotwendige Erganzung implementiert wurden. Durch die ausfuhrliche Planung undDokumentation in den ersten Phasen des Modells, konnten sicherheitskritische Be-reiche des Systems besser analysiert und mogliche Risikofaktoren herauskristallisiertwerden. Trotzdem ist die Zahl der erfolglosen Projekte, welche mit Hilfe des Was-serfallmodells entwickelt werden sehr hoch, da die Entwicklung oft zu teuer, zu langoder funktional falsch ist [6]. Ein Hauptscheiterungsgrund ist zum Beispiel eine Fehl-analyse der Anforderungen zu Beginn des Projekts [4]. Nach jeder Phase finden beidiesem Modell Meilensteinsitzungen statt, bei denen die Ergebnisse des jeweiligenAbschnitts vorgestellt werden. Die wichtigsten Ergebnisse des Wasserfall Modells

2 1.2. AUFBAU DER ARBEIT

sind das Lastenheft und das Pflichtenheft, indem die Anforderungen des Kundenund die jeweiligen Use-Cases des zu entwickelnden Systems beschrieben werden.Anhand dieser Dokumente findet am Ende der Entwicklung die Abnahme des Sys-tems beim Kunden statt [2].Auch heute wird das traditionelle Wasserfall-Modell noch haufig in IT-Unternehmeneingesetzt. Oft wird das Modell jedoch an bestimmte Umstande angepasst oder nurdort vorteilhaft angewendet, wo sich Anforderungen und Ablaufe in der Planungs-phase prazise beschreiben lassen.

Da in einem schnelllebigen Bereich wie der IT-Industrie Anforderungen und Tech-nologien standig variieren, haben sich in den letzten Jahren Softwareentwicklungs-methoden entwickelt, die dieser standigen Veranderung gerecht werden. Die so ge-nannten agilen Software Entwicklungsmodelle konzentrieren sich im Gegensatz zumWasserfallmodell weniger auf die Dokumentation und vorgeschriebene Ablaufe, alsauf einen standigen Austausch mit dem Kunden und iterative Methoden. Dies er-moglicht schon fruhzeitig die Entwicklung eines Prototypen des Systems.

Ansatze wie Scrum, eXtreme Programming (XP), Crystal, etc. haben sich in vie-len Bereichen der Industrie etabliert. Grunde hierfur sind insbesondere die kurzenEntwicklungszyklen und die enge Zusammenarbeit mit dem Kunden, die in der Phi-losophie aller agilen Methoden steckt. Es gab damit eine Entwicklung vom ursprung-lichen

”Plan-design-build”-Ablauf zum

”speculate-colobarate-learn”-Verfahren [4].

Problematisch ist bei agilen Entwicklungsmodellen jedoch die Analyse sicherheitskri-tischer Bereiche, das so genannte Security Engineering, welches insbesondere durchgeringe Dokumentation und kurzere Planungsphasen vernachlassigt wird. Wahrendtraditionelle Entwicklungsmodelle mit Hilfe von aktuellen Sicherheitsstandards wieSSE-CMM [15] oder ISO 15408 CC (Common Criteria) [14] das Security Enginee-ring effektiv implementieren konnen, gibt es bei agilen Methoden noch keine vorge-schriebenen Standards. Neben der Kritik an unvollstandiger Dokumentation ist die-se Tatsache einer der Hauptkritikpunkte an agilen Softwareentwicklungsmethoden,weshalb an einer Verbesserung des Security Engineerings innerhalb dieser Ansatzegeforscht wird.

1.2 Aufbau der Arbeit

Die vorliegende Arbeit stellt Ansatze zur Verbesserung der Sicherheit in agiler Soft-wareentwicklung vor und skizziert Vor- und Nachteile der jeweiligen Verfahren.

Im folgenden Kapitel 2 werden die beiden bekanntesten agilen Methoden eXtre-me Programming und Scrum detailliert vorgestellt, bevor in Kapitel 3 Ansatze zurVerbesserung des Security Engineerings, also der Betrachtung von Sicherheitsanfor-derungen, innerhalb dieser Methoden vorgestellt werden. Hierbei wird in 3.1 auf dasPrinzip der Abuse Case Modelle und Abuser Stories eingegangen, wahrend in 3.2Scrum-spezifische Ansatze wie S-Scrum und das Security Backlog vorgestellt wer-den. Die Arbeit schließt in Kapitel 4 mit einer Zusammenfassung der vorgestelltenVerfahren ab.

KAPITEL 2. AGILE SOFTWAREENTWICKLUNG 3

2 Agile Softwareentwicklung

In einem standig variierenden Markt wie der IT kommt es wahrend einer Projekt-entwicklungsphase standig zu Anderungen der Anforderungen und der Umgebung.Traditionelle, nicht iterative Softwareentwicklungsmodelle wie das Wasserfallmodell,die schon zu Beginn des IT-Zeitalters eingesetzt wurden, sind demnach in vielen Be-reichen nicht mehr zeitgemaß und nicht mit den Anforderungen der Kunden zuubereinstimmen [9]. Außerdem werden sowohl zeitliche wie finanzielle Ressourcendurch die umfangreiche Dokumentation dieser Ansatze verbraucht.

Um naher am Kunden zu arbeiten und Software Schritt fur Schritt in einzelnen Itera-tionen entwickeln zu konnen, haben sich in den letzten 10 Jahren einige so genannteagile Softwareentwicklungsmodelle am Markt etabliert. Trotz einiger Vorurteile, dieinsbesondere mit der informellen Dokumentationsweise und der fehlenden Moglich-keit Sicherheitsaspekte zu planen zusammenhangen [16], werden diese Technikenmehr und mehr von Unternehmen genutzt. Langst sind es nicht nur sicherheitsun-kritische Systeme oder Low-Budget Projekte, die mit Methoden wie dem eXtremeProgramming oder Scrum entwickelt werden. Gerade durch ihren Umgang mit demKunden, welcher zu standigem Feedback fuhrt, konnen die Anforderungen eines Pro-jektes mit Hilfe agiler Methoden genauer definiert werden. Ein falsches Verstandnisder Anforderungen ist der Hauptscheiterungsgrund fur Softwareprojekte [16]. AgileMethoden helfen in diesem Bereich die Erwartungen des Kunden besser zu erfullen.

2.1 eXtreme Programming

Das eXtreme Programming (XP) ist eine der bekanntesten und am meisten ge-nutzten agilen Software Entwicklungsmethoden [10]. Das Verfahren wurde 1995 vonBeck, Cunningham und Jeffries wahrend einem Projekt der Firma Chrysler entwi-ckelt [1] und erfreut sich seit dem an steigender Beliebtheit. Die gundlegende Ideehinter diesem Ansatz ist simpel: Den Softwareentwicklungsprozess zu vereinfachen,die Arbeitsumgebung wahrend der Entwicklung so angenehm wie moglich zu ge-stalten und schnell sichtbare Erfolge erreichen. Um die vollen Vorzuge des eXtremeProgrammings zu genießen, muss jedoch innerhalb des Entwicklerteams einiges be-achtet werden. Dies wird zu einer Herausforderung fur Teams, die an nicht iterativeVerfahren wie das V-Modell / Wasserfall Modell gewohnt sind [10].

Das Vorgehensmodell des eXtreme Programmings geht davon aus, dass der Kundezu Beginn der Entwicklung noch nicht alle Anforderungen definieren und strukturie-ren kann, wodurch eine genaue Aufwandsschatzung auf Seiten des Entwicklerteams

4 2.1. EXTREME PROGRAMMING

nicht zu realisieren ist. In einem iterativen Prozess, in dem die Kommunikation mitKunden und innerhalb des Teams im Vordergrund steht, werden einzelne Anforde-rungen im Laufe der Entwicklung verschieden stark gewichtet oder im Laufe der Zeitkomplett vernachlassigt.

Die Philosophie im Bereich des Softwaredesigns bei XP wird wie folgt zusammenge-fasst: YAGNI (

”You Ain’t Going To Need It”) [10]. Dieses Akronym beschreibt die

einfache Vorgehensweise von XP um ein overdesigning der Software zu verhindern.Es werden nur die Anwendungsfalle betrachtet und implementiert, die fur das Sys-tem wichtig sind und in der aktuellen Situation benotigt werden. Man fokussiert sichsomit bei der Planung und Realisierung immer auf eine definierte Version eines Pro-totypen, bei dem bestimmte Anwendungsfalle implementiert sind. Außerdem basiertXP auf weitere grundlegende Prinzipien, die im Folgenden vorgestellt werden.

2.1.1 Prinzipien des eXtreme Programming

XP basiert auf vier grundlegende Werte: Kommunikation, Einfachheit, Feedbackund Respekt [1]. Mit Hilfe dieser Werte kann interpretiert werden, wovon der Erfolgeines Projektes nach XP-Richtlinien abhangt. Trotzdem definieren Beck et. al indem Buch Extreme Progamming Explained grundlegende Prinzipien, nach denen beidiesem Vorgehensmodell gearbeitet werden soll. Aus den im Folgenden vorgestelltenPrinzipien (vgl. [1]) konnen die wichtigsten Praktiken im XP Umfeld abgeleitet undsomit eine Brucke zwischen Werten und konkreter Anwendung geschaffen werden.

Schnelles Feedback

Software wird von Menschen programmiert. Die Wissenschaft zeigt, dass der Menschdas Gelernte am Besten bewahrt, wenn er es in kurzer Zeit anwendet und ein Feed-back erhalt. XP verlangt deshalb vom Programmierer, die Moglichkeiten das Systemzu designen, implementieren und zu testen in jedem Iterationsschritt zu verbessern,daraus zu lernen und im nachsten Schritt wieder anzuwenden.

Annahme von Einfachheit

Entwickler werden dazu ausgebildet, jedes Problem genau zu planen und eine opti-male Losung nach dieser Planung zu finden. Ein Prinzip des eXtreme Progammingsist es, jedes Problem zu Beginn als simpel zu betrachten und erstmal eine funktio-nierende Losung zu implementieren. Komplexitat und Wiederverwendbarkeit wirdim Laufe des Prozesses schrittweise implementiert. Der Fokus liegt auf der Losungfur das aktuell vorliegende Problem.

Schrittweise Anderung

Große Anderungen zur gleichen Zeit fuhren zu Problemen [1], da eventuelle Folgenschwer eingeschatzt werden konnen und ein Uberblick der einzelnen Anderungs-schritte vorhanden sein muss. XP nutzt deswegen inkrementelle Anderungen in al-len Bereichen der Entwicklung. Von der Planung bis zur Implementierung werden


Schritt fur Schritt Anderungen am System vorgenommen. Selbst das Entwicklungs-team andert seine Aufgaben bei verschiedenen Iterationen.

Qualitativ hochwertige Arbeit

Von den vier Projektentwicklungsvariablen Umfang, Kosten, Zeit und Qualitat [1]ist die Qualitat die einzige, die in der Realitat nicht wirklich variabel ist. Der Kun-de erwartet immer eine exzellente Qualitat und wird ein Projekt mit miserablerQualitat nicht abnehmen. Auch der Entwickler mochte hochwertige Leistung brin-gen. Um Qualitat zu garantieren muss der Arbeitsplatz fur den Entwickler jedochangemessen sein und regelmaßige Schulungen oder Fortbildungen angeboten werden.

Die vier vorgestellten Prinzipien sind nur eine Teilmenge der in [1] zu findendenListe. Sie geben jedoch einen Eindruck uber den Gedanken der hinter dem PrinzipeXtreme Programming steckt: einfaches, effektives Programmieren von qualitativhochwertiger Software in enger Zusammenarbeit mit dem Kunden und ansprechen-den Verhaltnissen fur den Entwickler.

Aus den Prinzipien des eXtreme Programmings konnen zahlreiche so genannte BestPractices die durchgefuhrt werden mussen abgeleitet werden. Die Entwickler dieserVorgehensweise betonen, dass jede dieser Praktik eng mit den anderen in Verbin-dung steht und schon das Vernachlassigen einer Methode den Erfolg des Projektsim großen Maße beeinflussen kann [1]. Desweiteren wird gesagt, dass an den Stellen,an denen diese teilweise einfachen Verfahren Schwachstellen besitzen, andere ange-wendete Verfahren diese mit ihren Starken ausgleichen. Die XP Praktiken werdenim folgenden Abschnitt vorgestellt.

2.1.2 Praktiken des eXtreme Programming

In der Anwendung des XP Vorgehensmodells sind traditionelle von evolutionarenPraktiken zu unterscheiden [1]. Wahrend traditionelle Praktiken regelmaßig mitdem Begriff des eXtreme Programmings verbunden werden, haben sich evolutionarePraktiken im Laufe der letzten Jahre durch Erfahrung mit diesem Vorgehensmodelletabliert. Eine Auswahl dieser Praktiken wird in diesem Abschnitt vorgestellt. Fureine komplette Auflistung der Prinzipien sei auf [1] verwiesen.

Das XP Planspiel

Zu Beginn einer jeden Iteration wird in Zusammenarbeit mit dem Kunden eine kurzeAufwandsabschatzung der zu implementierenden Funktionen des geplanten Releaseserstellt. Hierbei werden neben technischen Aspekten auch Geschaftsanforderungenbetrachtet. Wenn die Realitat vom Plan abweicht, wird dieser Plan angepasst.

6 2.1. EXTREME PROGRAMMING

Kollektives Eigentum

Es gibt keine Rollenverteilung innerhalb des Teams. Da fur XP kleine Teams mitbis zu 10 Personen empfohlen werden, kann jeder Entwickler zu jeder Zeit an jedemCode jede Anderung vornehmen.

Pair Programming

Der gesamte Code wird von zwei Entwicklern pro Maschine entwickelt, um so zeitnahProgrammierfehler zu erkennen und Codestandards einzuhalten.

Testgetriebene Entwicklung

Unit-Tests werden schon vor Beginn der Entwicklung geschrieben und automati-siert durchgefuhrt. Das gesamte System wird taglich sowohl automatisiert als auchteilweise manuell getestet um die Qualitat des Produkts durchgehend aufrecht zuerhalten.

Kundeneinbezieung

Der Kunde wird aktiv in das Team mit einbezogen und steht, wenn moglich, vollzeitigfur Rucksprachen zur Verfugung.

Keine Uberstunden

Kein Entwickler arbeitet mehr als 40 Stunden pro Woche. Falls dies der Fall seinsollte, gibt es niemals zwei aufeinanderfolgende Wochen, in denen zusatzliche Ar-beitsstunden anfallen.

Refactoring

XP geht davon aus, dass Code zu Beginn der Entwicklung nicht perfekt ist [1].Deshalb finden regelmaßig Code-, Design-, und Analyse Reviews statt, um Ablaufeund Implementierungen zu verbessern. Optimierungsfahige Stellen werden dafur ineinem Projektmanagementsystem als Fehler (

”Bugs”) eingetragen und schnellstmog-

lich behoben.

User Stories

Im Gegensatz zu den bisher vorgestellten traditionellen Praktiken sind User Storieseine evolutionare Praktik, die sich im Laufe der letzten Jahre als wertvoll bewiesenhat. Einzelne Funktionalitaten werden als zusammenhangender Text aus Sicht desNutzers beschrieben. In wochentlichen Treffen wird entschieden, welche User Storiesim nachsten Release implementiert werden. Eine Iteration (Release) dauert norma-lerweise zwei bis vier Wochen. Das Gesamtprojekt wird quartalsweise geplant. DieEntscheidung welche User Stories implementiert werden ist ein Richtwert und kannim Laufe der Iteration verandert werden.


Neben den hier vorgestellten Praktiken gibt es noch zahlreiche andere evolutionareund traditionelle Praktiken des eXtreme Programmings. Da die vollstandige Vorstel-lung dieser den Rahmen der vorliegenden Arbeit sprengen wurde, wird die Auflistungauf diese Anzahl beschrankt.

Als weitere bekannte agile Entwicklungsmethode wird im Folgenden Scrum vorge-stellt. Dieser Ansatz nutzt weitere interessante Entwicklungspraktiken und ist mitdem vorgestellten eXtreme Programming gut zu vereinen, weshalb er in vielen Be-reichen der Wirtschaft erfolgreich eingesetzt wird.

2.2 Scrum

Scrum ist ein weiteres iteratives Vorgehensmodell der Softwaretechnik. Es basiertahnlich wie XP auf der Annahme, das traditionelle Entwicklunsmethoden zu kom-plex sind und nicht mehr den aktuellen Anforderungen der Softwaretechnik entspre-chen. Es eignet sich insbesondere bei Teams mit bis zu 10 Mitgliedern, die fur einemflexiblen, standig variierenden Markt Software entwickeln [12].Scrum basiert ahnlich wie XP auf eigene Prinzipien [12]. Diese sind

• Transparenz

• Uberprufung

• Anpassung

Mit Hilfe verschiedener Hilfsmittel wird der Fortschritt des Projekts standig fur alleTeammitglieder sichtbar festgehalten. So kann das Prinzip der Transparenz gewahr-leistet werden. Durch iterative Entwicklung und standige Verbesserung der einzelnenElemente des Systems sind die Prinzipien Uberprufung und Anpassung gesichert. Imfolgenden Abschnitt wird das Vorgehensmodell Scrum detailliert erlautert.

2.2.1 Grundlagen

Bei der Anforderungsanalyse eines Projektes sind Chaos und Unklarheiten im Rah-men von Scrum durchaus gewollt [12], da so die Kreativitat der Entwickler gefordertwird. In taglichen Treffen, den so genannten Daily Scrums, die zu Beginn eines jedenArbeitstages stattfinden, nehmen alle Teammitglieder teil. Ziel dieser Treffen ist einregelmaßiger Informationsaustausch innerhalb des Teams. Mit einer Zeit von 15-20Minuten sind diese Treffen lang genug um das Team auf den aktuellen Stand zu brin-gen und kurz genug um keine Zeit wahrend der Entwicklung zu verlieren. Ein ScrumMeeting wird vom so genannten Scrum Master geleitet, welcher den teilnehmendenEntwicklern taglich folgende Fragen stellt [12]:

• Was hast du seit dem letzten Treffen implementiert?

• Welche Probleme sind dabei aufgetreten oder bestehen weiterhin?

• Was mochtest du bis zum nachsten Treffen implementieren?

8 2.2. SCRUM

Probleme, die nicht innerhalb eines Tages gelost werden konnen, werden in einzelneTeilaufgaben unterteilt und als einzelne Tasks in das Backlog aufgenommen.Das Backlog ist die Ansammlung von Aufgaben, die innerhalb eines Sprints erle-digt werden mussen. Ein Sprint bezeichnet eine Iteration des Projektes fur die zweibis vier Wochen Entwicklungszeit eingeplant werden. Am Ende eines jeden Sprintssteht ein lauffahiges, getestetes Produkt, wobei erst das Ergebnis des letzten Sprintsdie abzunehmende Software darstellt. Zu Beginn eines Projekts werden ahnlich wiebei der evolutionaren Praktik des XP User Stories geschrieben, welche bestimmteAnwendungsfalle des Systems definieren. Es wird fur jeden Sprint entschieden, wel-che User Stories innerhalb der Entwicklungszeit dieses Sprints implementiert werden.Auch hier ist diese Vorgabe nur ein Richtwert und kann jeder Zeit verandert werden.Durch die Ahnlichkeit von Sprint und Release sowie die Planung mit User Storiessind die agilen Entwicklungsmethoden Scrum und XP eng verwandt. Im Gegensatzzu XP werden in Scrum jedoch feste Rollen innerhalb des Teams definiert. Diesewerden im Folgenden vorgestellt.

2.2.2 Rollen in Scrum

Scrum definiert feste Rollen fur jeden Teilnehmer eines Projekts. Die Rollenzuteilunggarantiert einen definierten Ablauf des Projekts und eine klare Aufgabenverteilung.Folgende Rollen sind zu finden [17]:

Scrum Master

Der Scrum Master sorgt fur den reibungsfreien Ablauf von Scrum innerhalb des Pro-jekts. Er arbeitet mit dem Entwicklungsteam eng zusammen, wobei er selbst nichtentwickelt, sondern in einer Managementposition agiert. Er ist kein Vorgesetzter,weshalb er einzelnen Teammitgliedern keine Aufgaben zuteilen kann. Er ist insbe-sondere fur eine klare Zusammenarbeit zwischen dem Entwicklungsteam und demProduct Owner verantwortlich.

Product Owner

Der Product Owner entwickelt die Vision eines Produktes. Er ist zustandig fur stra-tegische Produktentwicklung und priorisiert die einzelnen Produktfunktionen furjeden Sprint. Er ist damit verantwortlich fur den jeweiligen Prototypen nach einemSprint. Er optimiert das Produkt bezuglich wirtschaftlicher Faktoren und entschei-det daruber was, wann, wie ausgeliefert wird.

Entwicklungsteam

Das Entwicklungsteam ist dafur zustandig, einzelne User Stories in funktionale An-forderungen zu transformieren und damit den Aufwand eines jeden Sprints zu kalku-lieren. Außerdem wird die gesamte Design-, Implementierung-, und Testphase vonden Entwicklern ausgefuhrt. Idealerweise besteht das Entwicklungsteam aus einerungeraden Anzahl von Mitgliedern um die Bildung von Kleingruppen zu verhindernund ist moglichst interdisziplinar.


Customer

Der Customer ist der Kunde oder die jeweilige interne Abteilung fur die das Produktentwickelt wird. Er steht im standigen Kontakt mit dem Product Owner, von dem dieWunsche des Customers verstanden werden mussen. Schon nach den ersten Sprintswird der Prototyp des Produkts dem Customer vorgelegt um zeitnah Feedback zuerhalten.Der Customer ist nicht zwangslaufig der Nutzer, weshalb in verschiedenen Defi-nitionen noch die Rolle des Users zu finden ist. Ein Nutzer der Zielgruppe solltespatestens beim finalen Sprint Review eingeladen werden um das System zu testenund Feedback aus Nutzersicht zu geben.

Wie aus der Beschreibung von Scrum deutlich wird, gibt es viele Praktiken undVisionen, die sich mit anderen agilen Entwicklungsmethoden wie eXtreme Program-ming oder Crystal uberschneiden. Die taglichen Treffen und definierten Rollen undStrukturen innerhalb des Teams sind eine Besonderheit von Scrum wodurch eineiterative, flexible Entwicklung von Software garantiert werden kann. Dabei werdenindividuelle Fahigkeiten innerhalb des Scrum Teams ausgenutzt. Wie jedes andereVorgehensmodell kann Scrum keinen Erfolg des Projektes garantieren.

2.3 Zwischenfazit

Es wurden die beiden bekanntesten agilen Entwicklungsmethoden Scrum und XPvorgestellt. Beide Verfahren liefern einen modernen Ansatz zur Entwicklung vonSoftware innerhalb kleiner Teams und einer standig varriierenden Umgebung. Siezeigen, wie man effizient auf Anforderungsanderungen reagieren kann, den Kundenaktiv in das Projekt mit einbeziehen und die Entwicklung fur den Programmiererabwechslungsreich und positiv gestalten kann.Einige Punkte werden bei eXtreme Programming und Scrum jedoch kritisiert. DasPair programming in XP verbraucht aus betriebswirtschaftlicher Sicht viel personelleRessourcen bei nicht proportionalen Nutzen. Des Weiteren ist durch das Prinzip deskollektiven Eigentums keine Moglichkeit gegeben, Spezialisten innerhalb eines Teamszu finden. Jeder Entwickler muss sich nach dem Prinzip des XP z.B. mit Datenbankund GUI-Elementen beschaftigen, wodurch das Team eventuell ineffizienter arbeitet.Das Prinzip der testgetriebenen Entwicklung ist außerdem bei komplexen verteiltenSystem nur schwer zu realisieren.Ein weiterer Kritikpunkt dieser Methoden ist die fehlende Betrachtung der SoftwareSicherheit [10] [3] [4]. Da weder Scrum noch XP eine Phase fur umfangreiche Risiko-analyse oder Security Engineering definieren, wird Sicherheit bei diesen Methodenoft vernachlassigt. Eine Erweiterung der traditionellen agilen Methoden um eine Si-cherheitskomponente stellt demnach eine interessante Forschungsaufgabe dar. VierAnsatze, die in den letzten Jahren entwickelt wurden, werden im folgenden Abschnittvorgestellt.

10 2.3. ZWISCHENFAZIT

KAPITEL 3. SICHERHEIT IN AGILER SOFTWAREENTWICKLUNG 11

3 Sicherheit in agiler Softwareentwicklung

Sicherheit ist in Zeiten des Internets und Cloud Computing ein sehr wichtiges The-ma im IT-Bereich. Software die personliche Informationen bearbeitet, wie z.B. einOnline-Banking System kann heutzutage ohne umfangreiche Sicherheitstechnik nichtmehr entwickelt werden.

Um Sicherheit weitestgehend zu garantieren, muss der Entwickler schon wahrendder Planung denken wie ein potentieller Angreifer. Dieser ist nicht nur der typischeHacker, sondern auch die Personengruppe der spateren

”normalen” Nutzer, die das

System durch ihr Verhalten beeinflussen konnen. Jedes Softwaresystem ist ein sozio-technisches System [8], bei dem sich das Verhalten jedes Einzelnen auf das Gesam-tergebnis widerspiegelt. Um hierbei ein sicheres System zu erhalten, mussen schonvon Beginn der Entwicklung alle realistischen Falle von Nutzereingaben betrachtetwerden.

Der Kunde erwartet von Software automatisch ein gewisses Level an Sicherheit.Problematisch ist dabei, dass die Art wie

”sicher” ein System ist großtenteils vom

Softwareentwickler selbst bestimmt wird [12]. Die damit verbundene Abhangigkeitder Fahigkeiten der Entwickler fuhrt zu einem proportionalen Verhaltnis von Skillund Softwaresicherheit [13]. Dazu kommt, dass viele Softwareentwickler Sicherheitals eine Art Feature sehen [12]. Featurebasierte Angaben wie

”built with SSL” oder

”128-bit Encryption included” in der Beschreibung von Software machen dies deut-

lich. Statt einem Feature kann Sicherheit als eine wichtige, nicht-funktionale An-forderung gesehen werden [8]. Hope und McGraw beschreiben Sicherheit als einenotwendige Eigenschaft eines jeden Softwareprojekts [12]. Sie nennen hierbei denVergleich mit einem Zelt, dessen notwendige Eigenschaft es ist, die Personen im in-neren trocken zu halten. Aus der Eigenschaft, dass das Zelt stabile Stangen hat, kannnoch nicht geschlossen werden, dass die Personen trocken bleiben. Die Folie mussebenfalls dicht und das Zelt groß genug sein, damit genug Leute darunter passen.

Aus diesem Beispiel wird deutlich, dass wahrend der gesamten Entwicklungszeiteiner Software die Sicherheit mit betrachtet werden muss. Wie aus Kapitel 2 deutlichwurde, ist bei agilen Ansatzen der Bereich des Security Engineerings eher klein.Dennoch gibt es Ansatze, agile Entwicklung mit Security Engineering zu verbinden.Vier dieser Ansatze werden in diesem Kapitel am Beispiel von XP und SCRUMvorgestellt.

3.1 Sicherheit in eXtreme Programming

Das eXtreme Programming als eine der bekanntesten Methoden agiler Software Ent-wicklung wird neben weiteren Kritikpunkten haufig auf Grund seiner fehlenden Do-

12 3.1. SICHERHEIT IN EXTREME PROGRAMMING

kumentation im Bereich des Security Engineerings kritisiert [10]. Trotzdem ist dieAnwendung dieses Verfahrens durchaus forderlich fur die Betrachtung von Sicher-heit, zum Beispiel durch regelmaßige Code Reviews und Pair Programming. Wie dieSicherheit jedoch strukturierter betrachtet und dokumentiert werden kann, wird indiesem Abschnitt erklart.

Dazu wird in Abschnitt 3.1 zunachst auf die Abuse Case Modelle eingegangen, eineVariation der klassischen Use Case Diagramme, die Anwendungsfalle dokumentie-ren, welche kriminelle oder sicherheitsgefahrdende Absichten haben. Abschnitt 3.2beschaftigt sich dagegen mit einer Variation der fur eXtreme Programming typischenUser Stories: den Abuser Stories beziehungsweise Security related User Stories. Auchhier werden Nutzungsablaufe beschrieben, bei denen ein Systemangriff versucht wirdoder das System mit Absicht falsch genutzt wird.

3.1.1 Abuse Case Modell

Zu Beginn eines Softwareentwicklungsprozesses werden die Anwendungsfalle (Use-Cases) einer Software definiert. Oft wird dabei in Zusammenarbeit mit dem Kundenein so genanntes Anwendungsfall-Diagramm (Use-Case Diagram) erstellt, in demgrob beschrieben wird, wie der Nutzer mit dem entwickelten System interagiert. DerNutzer wird in diesem Diagramm als eine Strichfigur gezeichnet, die verschiedeneRollen annehmen kann. Die einzelnen Anwendungsfalle werden in Ellipsen darge-stellt und sind durch Linien mit dem Nutzer verbunden (Association). Zu einementwickelten Anwendungsfalldiagramm wird zusatzlich eine Beschreibung der ein-zelnen Use-Cases innerhalb der Dokumentation angelegt. Abbildung 3.1 stellt einsolches Diagramm fur eine Onlinesystem dar, welches innerhalb der Madison Uni-versity of Virginia fur eine Ubungsgruppe fur Softwaresicherheit genutzt wird. DieStudenten konnen mit Hilfe des Systems Softwareangriffe entwickeln und demons-trieren und lernen Gegenmaßnahmen kennen.

Der Nutzer des Systems kann in der Rolle des Studenten, des Administrators und desGruppenleiters auftreten. Als Student hat er mit Hilfe des Systems die Moglichkeit,einen Softwareangriff oder Abwehrmechanismus zu entwickeln und zu demonstrie-ren. Der Administrator kann das System hoch und herunterfahren. Der Gruppenlei-ter kann neue Aufgaben fur die Studenten erstellen und eine Bewertung anlegen.

Bei der Entwicklung des Anwendungsfalldiagramms einer Software werden noch kei-ne Angriffe oder vorsatzliche Fehlnutzungen des Systems betrachtet. McDermott undFox [9] sowie [4] und [13] stellen dafur die so genannten Abuse Case Modelle vor, indenen nur maliziose Anwendungsfalle dokumentiert sind. Das Abuse Case Diagrammwird im Entwicklungsprozess direkt nach dem normalen Anwendungsfalldiagrammerstellt. Es beschreibt nicht eine Moglichkeiten von Angriffen, sondern den genauenAnwendungsfall eines bestimmten Angriffes von einer bestimmten Person auf einenTeilaspekt des Gesamtsystems [9]. Dazu konnte ein Security Engineer innerhalb desTeams bestimmt oder in das Team integriert werden, der spezielles Domanenwissenim Bereich der Sicherheit besitzt und sich mit der Dokumentation und den Testsder Abuse Cases beschaftigt. Dieser kann ebenfalls innerhalb des Teams fur Weiter-


Abbildung 3.1: System einer Ubungsgruppe im Universitatsumfeld [9]

bildung und Hilfestellungen im Sicherheitsbereich eingesetzt werden [10].

Ein Abuse Case beschreibt welche Rolle der potentielle Angreifer ubernehmen wirdund welche Rechte ihm damit zur Verfugung stehen. Dabei wird definiert, welcheFahigkeiten und Ressourcen der Angreifer besitzt und welche langfristigen Ziele erdamit erreichen mochte. Außerdem wird definiert wie der Zustand des Systems vordem Angriff ist und in welchem Zustand sich das System nach dem Angriff befindet.

Das Abuse Case Modell fur das oben genannte Beispiel der Ubungsgruppe mit mog-lichen Angriffszenarios ist in vereinfachter Form in Abbildung 3.2 zu finden. AlsNutzer des Systems werden hier ein Student mit boswilligen Absichten, ein Angreifermit begrenzten Ressourcen und Domanenwissen (Script Kiddie) und ein Angreifermit umfangreichen Ressourcen und Domanenwissen (Nazgul) angegeben. Die defi-nierten Nutzer sind nur Rollen. In der Realitat kann in jeder Rolle eine Mehrzahl vonAngreifern auftreten. Der bosartige Student kann das System schadigen, in dem erErgebnisse oder Aufgaben verfalscht. Er konnte aber auch die Arbeit eines anderenStudenten kopieren und als sein Arbeit ausgeben.

Script Kiddie konnte das System schadigen, in dem er den Server manipuliert odersich die Zugriffsrechte des Administrators beschafft. Er konnte auch Software nutzen,die speziell fur ahnliche Angriffe entwickelt wurde (Warez ) um weiteren Schaden an-zurichten. Nazgul kann auf Grund seiner ausgereiften technischen Fahigkeiten mitspeziell fur dieses System entwickelter Angriffssoftware (Scalpel) arbeiten oder Zu-griff auf den gesamten Serverbereich erhalten.

14 3.1. SICHERHEIT IN EXTREME PROGRAMMING

Abbildung 3.2: Abuse Case Modell des Systems [9]

Um moglichst realistische Angriffszenarios zu finden und damit das System sicherzu realisieren, konnen so genannten Attack Patterns betrachtet werden [5]. MoglicheAttack Patterns sind [13]:

• Client unsichtbar machen

• Programme angreifen, die Nutzungsrechte des Betriebsystems verandern kon-nen

• Skript Injektionen

• Lokale Dateipfade an Funktionen ubergeben, die eine URL erwarten

• etc.

Das Finden der richtigen Attack Patterns und den damit zusammenhangenden Ab-use Cases kann im XP-Prozess zu Beginn durchgefuhrt werden. Schon wahrend derPhase des XP-Planspiels mussen die Anforderungen und Anwendungsfalle des Sys-tems definiert werden. Durch die einfache Darstellung der Abuse Case Modelle undden naturlichsprachlichen Beschreibungen der Rollen und Anwendungsfalle sind Ab-use Cases leicht zu verstehen. Auch in Zusammenarbeit mit dem Kunden wahrenddes Planspiels wird somit nur wenig Fachwissen vorausgesetzt, so dass die Integra-tion einer Risikoanalyse durch Abuse Case Modelle leicht in den XP-Prozess zuintegrieren ist [9]. Wahrend der testgetriebenen Entwicklung mussen die definiertenAbuse Cases widerlegt werden um die Sicherheit der Software zu demonstrieren.Neben vielen Vorteilen, die die Einfuhrung von Abuse Cases innerhalb des XP Um-felds realisiert, ist es nicht moglich alle moglichen Angriffe am System zu modellieren.


Die Sicherheit des Systems steht auch hier in engem Zusammenhang mit dem Doma-nenwissen des Security Engineers bzw. des Entwicklungsteams. Außerdem konnenAbuse Case Modelle ubermodelliert werden [13]. Die einzelnen Abuse Cases sinddemnach vom Entwicklungsteam zu bewerten und je nach moglichen resultierendenSchaden zu gewichten.

Neben der Moglichkeit Anforderungen eines Systems in Anwendungsfalldiagram-men zu definieren, hat sich die Praktik der User Stories innerhalb des XP-Umfeldsetabliert. Wie diese schriftliche Dokumentation der Anwendungsfalle um einen Si-cherheitsaspekt erweitert werden kann, wird im nachsten Abschnitt deutlich.

3.1.2 Abuser Stories

Um die Anwendungsfalle einer Software innerhalb agiler Vorgehensmodelle festzu-halten, hat sich in den letzten Jahren das Prinzip der User Stories als erfolgreichbewiesen. Diese werden vom Kunden geschrieben und bieten eine kurze, informelleBeschreibung der Anforderungen [16]. Innerhalb des iterativen Prozesses von XPkonnen sie genutzt werden, um einzelne Funktionen nacheinander zu implementie-ren und somit ein strukturiertes Vorgehen erleichtern.

Um ein System sicher zu implementieren, mussen jedoch schon zu Beginn die Sicher-heitsanforderungen betrachtet werden. Durch fehlendes technisches Know-how undzeitlicher Ressourcen ist es dem Kunden nicht moglich, diese Aspekte in den UserStories festzuhalten. Um dieses Ziel zu erreichen, ohne den agilen Prozess des eXtre-me Programmings zu verlangsamen, konnen sogenannte Abuser Stories geschriebenwerden.

Abuser Stories werden vom gesamten Team geschrieben, sofern innerhalb des Teamskein Security Engineer integriert ist, der sich, ahnlich wie bei den Use Case Diagram-men, speziell mit diesem Thema beschaftigt. Wie bei den Abuse Case Diagrammenwird auch hier eine Interaktion mit dem Kunden durch leicht verstandliche Doku-mentation ermoglicht.

Nach der Dokumentation der User Stories und Abuser Stories werden ihre jeweili-gen Prioritaten vergeben. Angriffszenarios die einen vergleichbar geringen Schadenverursachen, werden geringer priorisiert als solche, die grundlegende Faktoren desSystems manipulieren. Statt einem Abnahmetest kann die Sicherheitsbewertung desSystems nach der Fertigstellung der Software durch die Widerlegung der Abuser Sto-ries erfolgen. Wie dieser Ansatz in das XP-Planspiel integriert werden kann, zeigtAbbildung 3.3 im Detail.

Die beiden vorgestellten Ansatze haben gezeigt, dass es durchaus moglich ist, sichereSoftwareentwicklung mit der Agilitat von XP zu verbinden, ohne von den ursprung-lichen Prinzipien dieses Vorgehensmodells abzuweichen. Zusatzliche Dokumentationim geringen Maß ist dafur dennoch notwendig [11].

16 3.2. SICHERHEIT IN SCRUM

Abbildung 3.3: Ablauf des XP-Planspiels im Bereich der Sicherheit. [4]

3.2 Sicherheit in Scrum

Scrum ist neben eXtreme Programming eines der bekanntesten Vorgehensmodelleder agilen Softwareentwicklung. Da Sicherheitsaspekte oft aus Zeitgrunden bei dieserMethode vernachlassigt werden, wurden in der Forschung bereits mehrere Ansatzezur Integration von Security Engineering in Scrum entwickelt. Bei diesen Ansatzenwurde klar, dass die Sicherheitsanalyse zu Beginn der Entwicklung stattfinden mussund damit nicht innerhalb der Sprintiterationen liegt [18] [7]. Außerdem wurdenvorhandene Scrum Praktiken um Sicherheitsaspekte erweitert um somit sicherheits-kritische Systeme mit Hilfe von Scrum verlasslich zu implementieren [19].

Die in der Forschung entwickelten Erweiterungen beweisen, dass die Vorurteile ge-genuber Scrum im Bereich der Sicherheit widerlegt werden konnen. Zwei dieser An-satze, die eine simple Erweiterung des Scrum Prozesses darstellen und gleichzeitigkompatibel mit dem agilen Prozess dieses Vorgehensmodells sind, werden im Fol-genden vorgestellt. Dazu wird in 3.2.1 zunachst auf S-Scrum (Secure Scrum) einge-gangen, bevor das Security Backlog in Abschnitt 3.2.2 prasentiert wird.

3.2.1 S-Scrum

S-Scrum (Secure Scrum) ist eine einfache Erweiterung des klassischen Scrum-Prozesses,welcher von Mougouei, Sani und Almasi 2013 in Malaysia vorgestellt wurde [3]. Siebetonen die Notwendigkeit von Risikoanalyse und der Betrachtung von Sicherheits-anforderungen innerhalb von Scrum und machen deutlich, dass ohne Dokumentati-on im Bereich des Security Engineerings, Sicherheitsstandards wie SSE-CMM nicht


adaptiert werden konnen. Um den klassischen Scrum Prozess um eine Sicherheits-komponente zu erweitern, wird nach der initialen Erstellung des Product Backlogs(Anforderungen des Gesamtsystems) und der Planung des Releases, eine weiterePhase zur Sicherheitsanalyse eingefuhrt. In dieser Phase werden zum Beispiel Ab-user Stories (siehe 3.1.2) erstellt und Gegenmaßnahmen fur potentielle Angriffe de-finiert. Anschließend muss gegebenenfalls das Product Backlog angepasst werden,bevor in einer weiteren Phase die Ergebnisse der Sicherheitsanalyse in das aktuelleModell des Releases ubernommen werden [3]. Abbildung 3.4 zeigt den verandertenScrum Prozess im Detail. Die Phasen, die fur den S-Scrum Prozess eingefugt wur-den, sind sind durch ein rotes Rechteck hervorgehoben. Das restliche Modell zeigteinen herkommlicher Scrum Ablauf.

Abbildung 3.4: S-Scrum Prozess im Detail [3]

Durch die Erweiterung des klassischen Prozesses um zwei zusatzliche Sicherheitspha-sen kann schon zu Beginn das potentielle Risiko des Systems analysiert werden. Dadieser Prozess außerhalb der iterativen Sprint Entwicklung liegt, wird dieser von derErweiterung nicht verandert. Nur innerhalb der Testphase mussen die sicherheits-kritischen Aspekte mit der Implementierung verglichen werden und Abuse Caseswiderlegt werden. Die Vorteile des klassischen Scrum Prozesses wie Transparenzund Anpassung bleiben somit weiterhin erhalten.

Im Folgenden wird ein weiterer Ansatz zur Verbesserung der Sicherheit in Scrumvorgestellt. Hierbei wird ein zusatzliches Backlog angelegt, in dem speziell Sicher-heitsanforderungen verwaltet werden.


3.2.2 Security Backlog

Das Backlog bildet innerhalb der Scrum Umgebung einen wesentlichen Bestandteilder Entwicklung. Es ist dabei zwischen dem Product- und dem Sprint Backlog zuunterscheiden. Wahrend im Product Backlog eine priorisierte Liste aller Anforderun-gen des Gesamtsystems zu finden ist [12] sind im Sprint Backlog alle Anforderungendes aktuellen Sprints aufgelistet.

Um Security Engineering in den Scrum Prozess zu integrieren ohne dabei die Agili-tat des Ansatzes zu vernachlassigen, stellen Azham et.al das Element des SecurityBacklogs vor [19]. Dieses ist eine Auflistung spezieller Sicherheitsanforderungen desGesamtsystems. Da Sicherheitsanforderungen nicht vom Kunden definiert werdenkonnen und evtl. nicht alle Mitglieder des Entwicklungsteams ausreichende Kennt-nisse daruber besitzen, wird eine zusatzliche Rolle innerhalb des Scrum Prozessesvorgeschlagen: Der Security Master.

Der Security Master beschaftigt sich innerhalb des Scrum Teams mit der Identifika-tion von sicherheitskritischen Teilbereichen des Systems, dokumentiert diese Risikenim Security Backlog und fuhrt Sicherheitstests zum Ende eines Sprints durch. Erverfugt uber ein umfangreiches Domanenwissen im Bereich der Sicherheit und istentweder Teil des ursprunglichen Scrum Teams oder wird extern hinzugezogen. Ei-ne Illustration der Verwaltung einzelner Backlogs durch den Security Master ist inAbbildung 3.5 zu finden.Wie zu erkennen ist, definiert der Security Master zunachst die Funktionen im Pro-duct Backlog, die sicherheitskritisch sind. Das sind in diesem Fall die Funktionen5,10 und 11. Diese werden im Security Backlog aufgenommen, und ggf. ein SecurityTest hinzugefugt. Das Release Backlog besteht aus einer Teilmenge der Funktionenaus Product- und Security Backlog. Fur einen Sprint wird eine Teilmenge des Relea-se Backlogs implementiert und getestet. Die sicherheitskritischen Funktionen werdendabei vom Security Master getestet. Bei erfolgreichen Funktions- und Sicherheits-tests entsteht im nachsten Schritt ein potentiell lieferbares System.

Die beiden vorgestellten Ansatze zeigen, dass Sicherheit im gesamten Scrum Pro-zess berucksichtigt werden kann und die Entwicklung sicherheitskritischer Softwa-re durchaus mit agilen Vorgehensmodellen wie Scrum realisiert werden kann. Dieerreichte Sicherheitsebene hangt dabei stark von dem Sicherheitsbewusstsein derjeweiligen Entwickler ab [19].


Abbildung 3.5: Interaktion des Security Masters mit den jeweiligen Backlogs [19]

KAPITEL 4. ZUSAMMENFASSUNG 21

4 Zusammenfassung

In dieser Arbeit wurden die weit verbreiteten agilen SoftwareentwicklungsmethodeneXtreme Programming und Scrum vorgestellt. Wie in den ersten beiden Kapitelnverdeutlicht, liegen die Vorteile dieser Methoden insbesondere in den iterativen Ab-laufen der Entwicklungsphasen und dem standigen Austausch innerhalb des Teamssowie die intensive Kundenanbindung. Falsche Interpretation von Anwendungsfallenkann so zum großen Teil vermieden und die Entwicklung eines fruhen Prototypenrealisiert werden.Wahrend der Beschreibung der einzelnen Methoden wird klar, dass die Nachteilevon XP und Scrum insbesondere im Bereich der Sicherheit liegen. Durch fehlen-des Security Engineering konnen sicherheitskritsche Systeme evtl. nicht ausfuhrlichanalysiert und sicher implementiert werden, da hierfur eine umfangreiche Planunginitiiert werden muss.Das Sicherheit und agile Methoden nicht unbedingt im Konflikt zueinander stehenmussen, wurde in Kapitel 3 verdeutlicht. Hier wurden Ansatze vorgestellt, wie XPund Scrum erweitert werden konnen, um Sicherheitsaspekte zu berucksichtigen, oh-ne die Vorteile agiler Entwicklung zu verlieren. Zu diesen Ansatzen gehoren zumBeispiel Abuse Case Modelle und Abuser Stories, welche eine Erweiterung der tradi-tionellen Use Case Diagramme und User Stories darstellen, bei denen eine malizioseNutzung des Systems vorausgesetzt wird. Die ubersichtliche Darstellung und einfa-che Handhabung dieser Ansatze sind die Vorteile dieser Idee wobei mit Ihnen niemalsalle moglichen Vorfalle modelliert werden konnen.In Scrum werden Ansatze wie S-Scrum und das Security Backlog genutzt um dieSicherheit des Systems zu gewahren. Dazu wird in den Scrum Prozess ein weiteresElement hinzugefugt, welches sich speziell mit Themen der Sicherheit beschaftigt.Die zusatzliche Komponente wirkt sich positiv auf den Sicherheitsaspekt des Systemsaus, wobei mit einem Mehraufwand zu rechnen ist.

Fazit

Wie in dieser Arbeit deutlich wird, kann das Vorurteil, dass agile Entwicklungs-methoden gegensatzlich zur sicherer Software stehen teilweise widerlegt werden.Die Forschung in diesem Bereich hat neue Ansatze hervorgebracht, welche einenKompromiss zwischen Security Engineering und dem schnellen, iterativen Entwick-lungsprozess agiler Methoden wie Scrum und XP finden. Auch wenn niemals dievollstandige Sicherheit einer Software garantiert werden kann, bieten diese Ansat-ze Moglichkeiten, eine sicherheitssensible Entwicklung zu realisieren und damit einahnliches Sicherheitslevel wie bei der Nutzung des Wasserfall Modells zu erreichen.

22

Auch in Zukunft wird weiterhin verstarkt auf agile Vorgehensmodelle innerhalb derSoftwareentwicklung gesetzt, um auf unvorhergesehene Anderungen schnell zu rea-gieren und damit wirtschaftlich konkurrenzfahig zu bleiben. Da die Sicherheit heutebei jedem Softwareprodukt eine entscheidende Rolle spielt, sind die in dieser Arbeitvorgestellten Ansatze ein guter Anfang Sicherheit und agile Entwicklung zu kom-binieren. Um diese Ansatze erfolgreich zu implementieren, mussen Unternehmen inSchulungen und Fortbildungen im Bereich der Sicherheit investieren, damit durchumfangreiches Know-how, sichere Software innerhalb kurzer Entwicklungszyklen er-stellt werden kann.

LITERATURVERZEICHNIS 23

Literaturverzeichnis

[1] Beck. Extreme Programming Explained: Embrace Change. Addison-Wesley,2000.

[2] B. W. Boehm. A spiral model of software development and enhancement.Technical report, TRW Defense Systems Group, 1988.

[3] M. M. Almasi D. Mougouei, N.F.M. Sani. S-scrum: a secure methodology foragile development of web services. Technical report, Universiti Putra Malaysia,2013.

[4] M. Boden K. Beznosov P.Kruchten G. Bostrom, J. Wayrynen. Extending xppractices to support security requirements engineering. Proceedings of the 2006international workshop on Software engineering for secure systems, 2006.

[5] G. McGraw G. Hoglund. Exploiting Software. Addison-Wesley, 2004.

[6] Standish Group. The chaos report: Extreme chaos. Technical report, TheStandish Group, 2001.

[7] S-H. Mirian-Hosseinabadi H. Keramati. Integrating software development se-curity activities with agile methodologies. 978-1- 14244-1968-5/08/2008 IEEE,2008.

[8] M. A. Sasse I. Flechais, C. Mascolo. Integrating security and usability into therequirements and design process, 2007.

[9] C. Fox J. McDermott. Using abuse case models for security requirements ana-lysis, 1999.

[10] G. Bostrom J. Wayrynen, M. Boden. Security engineering and extreme pro-gramming: An impossible marriage?, 2004.

[11] P.Kruchten K. Beznosov. Towards agile security assurance. Technical report,University of British Columbia, 2004.

[12] N. S. Janoff L. Rising. The scrum software development process for small teams.Technical report, AG Communication Systems, 2000.

[13] G. McGraw. Misuse and abuse cases: Getting past the positives. IEEE Com-puter Society, 2004.

24 LITERATURVERZEICHNIS

[14] Common Criteria Project Sponsoring Organisation. Common criteria for in-formation technology security evaluation. Common Criteria ImplementationBoard, 1998.

[15] P.Barzin. Sse-ccm. Datenschutz und Datensicherheit, 2007.

[16] J. Peeters. Agile security requirements engineering. johannpeeters.com, 2005.

[17] Roman Pichler. Scrum - Agiles Projektmanagement erfolgreich einsetzen.d.Punkt Verlag Heidelberg, 2009.

[18] A. Vaha-Sipila. Marrying scrum and security, 2013.

[19] N. Ithnin Z. Azham, I. Ghani. Security backlog in scrum security practices.Software Engineering (MySEC), 2011 5th Malaysian Conference in, 2011.

agile development vs. security requirements · thema: agile development vs. security requirements...

Documents