In diesem Teil der Arbeit wird die Frage geklärt, wie Experten das VS-Scrum Framework in Bezug auf die Sichererstellung von IT-Sicherheit in Scrum Projekten bewerten. Für die Beantwortung dieser Frage wurde ein Fokusgruppeninterview durchgeführt. Dabei haben sich vier Experten aus dem Bereich IT-Sicherheit und agile Methoden zusammen mit dem Autor dieser Arbeit als Interviewer online zusammengefunden. Als Grundlage des Termins diente eine Präsentation (siehe [39]). Nachfolgend wird der Ablauf des Interviewtermins dargelegt.

Vorstellung des Frameworks im Fokusgruppeninterview

Zu Beginn wurde das VS-Scrum Framework vorgestellt. Im Anschluss daran wurde insbesondere auf die neuen Elemente eingegangen, die sich zu einem standardmäßigen Scrum-Vorgehen unterscheiden (vgl. Folie 3, 4, [39]). Dabei handelt es sich zum einen um den Security Master, der für die Bearbeitung von IT-Sicherheitsaufgaben verantwortlich ist. Eine dieser Aufgaben ist das Vergeben von S-Tags, welche eine spezielle Kennzeichnung von IT-Sicherheitsaufgaben darstellt. Zum anderen koordiniert der Security Master die Security Sprints, in welchen ausschließlich Sicherheitsaufgaben bearbeitet werden. Als letzte Aufgabe ist er für die Pflege und Priorisierung von Anforderungen des Security Backlogs verantwortlich, wobei es sich um eine Liste von IT-Sicherheitsanforderungen handelt (vgl. Folie 4, [39]).

Im Anschluss daran wurden die Vorteile des VS-Scrum Frameworks dargelegt. Durch die „Integration von Sicherheitsaspekte in alle Phasen des Entwicklungsprozesses" (Folie 5, [39]) und die „Systematische Behandlung von Sicherheitsaufgaben durch [den] Security Backlog und [die] Security Sprints" (Folie 5, [39]) wird die IT-Sicherheit verbessert. Zudem wird die Sicherheitskultur erhöht, da die IT-Sicherheit zu einem integralen Bestandteil des Entwicklungsprozesses wird und somit nicht als einmalige Aufgabe, sondern als kontinuierlicher Prozess betrachtet wird (vgl. Folie 5, [39]). Durch die Verwendung von S-Tags und dem Security Backlog als zentralen Ort von Sicherheitsaufgaben entsteht des Weiteren eine bessere Sichtbarkeit von Sicherheitsaufgaben. Dadurch wird die Priorisierung der verschiedenen Aufgaben vereinfacht (vgl. Folie 5, [39]). Die Sichtbarkeit der IT-Sicherheit wird zudem durch den Security Master verstärkt, der sich hauptsächlich auf die IT-Sicherheitsfragen fokussiert und damit ermöglicht, dass jene Aufgaben „parallel zu anderen Entwicklungsaktivitäten" (Folie 5, [39]) behandelt werden können.

Nach einer ausführlichen Einführung in das Thema und der detaillierten Präsentation des Frameworks wurde der Fokus auf die Evaluierung des VS-Scrum Framework gerichtet. Die Ergebnisse werden im weiteren Verlauf dargestellt.

Ergebnisse des ersten Fokusgruppeninterviews

Die Evaluation des VS-Scrum Frameworks erfolgte anhand von zehn Leitfragen. In diesem Abschnitt der Arbeit werden die gewonnenen Erkenntnisse und Rückmeldungen aus dem Fokusgruppeninterview in Bezug auf jede einzelne Leitfrage systematisch präsentiert und analysiert.

Security Master

Die erste Frage bezog sich auf die Rolle des Security Masters und lautete: „Wie beurteilen Sie die Rolle des Security Masters im VS-Scrum Framework? Ist diese Rolle in Ihrem aktuellen Team realisierbar?" (Folie 6, [39]).

Es bestand bei den Befragten Einigkeit darüber, dass der Security Master ein absoluter Spezialist für IT-Sicherheit sein muss (vgl. ID3, ID8, ID43, Tabelle 5 im Anhang). Zudem wurden seine Aufgaben im Rahmen des VS-Scrum Frameworks, die Erstellung und Pflege des Security Backlogs sowie das Tagging von Anforderungen, als verständlich eingeordnet (vgl. ID2, Tabelle 5 im Anhang). Diese speziellen Aufgaben sind unter anderem ein Grund, warum die Rolle des Security Masters nicht vom Scrum Master übernommen werden kann (vgl. ID9, Tabelle 5 im Anhang). Ein weiterer positiver Aspekt der Rolle ist, dass es bereits frühzeitigen Input seitens der IT-Sicherheit gibt und eine Nähe zwischen der IT-Sicherheit und dem Projektteam aufgebaut wird (vgl. ID44, Tabelle 5 im Anhang).

Seitens der Interviewpartner wurden jedoch nicht alle Belange hinsichtlich des Security Masters im VS-Scrum Framework als positiv bewertet. Es wurde kritisiert, dass es zu Kompetenzüberschneidungen kommen kann, wenn der Security Master im Rahmen des Security Sprints Aufgaben übernimmt, die eigentlich im Zuständigkeitsbereich des Scrum Masters liegen (vgl. ID4, ID42, Tabelle 5 im Anhang). Deshalb sollte der Security Master den Sprint, lediglich als beratende Instanz begleiten (vgl. ID7, Tabelle 5 im Anhang).

Security Backlog

Als nächstes wurde über die Frage „Wie stehen Sie zur Idee eines separaten Security Backlogs im VS-Scrum Framework?" (Folie 7, [39]) diskutiert. Der Security Backlog wurde, wie die folgenden Antworten verdeutlichen, überwiegend kritisch bewertet.

Ein separater Security Backlog würde in einem Projekt nur dann als sinnvoll erachtet, wenn das Projekt sehr komplex ist oder die IT-Sicherheit einen außerordentlich hohen Stellenwert hat (vgl. ID14, Tabelle 5 im Anhang). Standardmäßig sollten Anforderungen der IT-Sicherheit allerdings als markierte Anforderungen im normalen Product Backlog liegen (vgl. ID13, Tabelle 5 im Anhang).

Zudem wurden wiederholt Bedenken bezüglich der potenziellen Überschneidungen und Unklarheiten in den Zuständigkeiten zwischen dem Scrum Master und dem Security Master hervorgebracht. Einige Teilnehmende des Interviews äußerten die Befürchtung, dass diese nicht klar abgegrenzten Rollen zu Konflikten in Bezug auf Verantwortlichkeiten und Entscheidungsbefugnisse führen könnten (vgl. ID19, ID20, ID21, Tabelle 5 im Anhang).

Security Sprints

Im Kontext der Bewertung des VS-Scrum Frameworks durch das Anwendungsumfeld lautete die dritte Frage: „Wie beurteilen Sie die Umsetzbarkeit der vorgeschlagenen Security Sprints in Ihrem derzeitigen Projektzyklus?" (Folie 8, [39]).

Die Security Sprints wurden im Rahmen des Frameworks eher als Fremdkörper empfunden und abgelehnt (vgl. ID1, ID31, Tabelle 5 im Anhang). Grund hierfür ist unter anderem, dass der Versuch einer Implementierung in der Organisation vom Interviewten 1 von negativem Feedback geprägt war (vgl. ID28, Tabelle 5 im Anhang). Das Problem bestand darin, dass die Security Sprints aufgrund von Kapazitätsengpässen in der Praxis nicht umgesetzt wurden (vgl. ID41, Tabelle 5 im Anhang).

Bei der ursprünglichen Entwicklung des VS-Scrum Frameworks wurde der Security Sprint unter anderem integriert, um die nötige Verfügbarkeit eines Experten auf einen möglichst geringen Zeitraum zu fixieren und dadurch der geringen Ressourcenverfügbarkeit entgegenzuwirken (vgl. Kapitel 4.1). Im Interview hat sich allerdings herausgestellt, dass eine solche Planbarkeit der benötigten Ressourcen besser durch einen Security Fokus im Sprint erreicht werden kann (vgl. ID28, Tabelle 5 im Anhang). Die Formalisierung in zwei Sprints bringt künstliche Komplexität in das Framework und führt zu einem Flexibilitätsverlust (vgl. ID6, ID29, Tabelle 5 im Anhang). Die Quintessenz ist deshalb, dass die IT-Sicherheit in jedem normalen Sprint mitberücksichtigt werden muss (vgl. ID38, Tabelle 5 im Anhang).

Penetrationstests

Im Anschluss an den Sprint finden im VS-Scrum Framework Penetrationstests statt. Erst danach wird ein neues Inkrement geschaffen. Deshalb wurde den Interviewten die folgende Frage gestellt: „Wie beurteilen Sie die vorgeschlagenen Penetrationstests im VS-Scrum Framework? Sind diese Tests in Ihrem aktuellen Projekt durchführbar?" (Folie 9, [39]).

Reine Penetrationstests wurden durch die Interviewpartner eher als kritisch betrachtet, weil es ihrer Meinung nach im Rahmen des Frameworks nach finalen und keinen iterativen Tests aussieht (vgl. ID35, Tabelle 5 im Anhang). Sie sehen Penetrationstests eher als Teil von Validierungsmaßnahmen, die iterativ durchgeführt und nach Kritikalität priorisiert werden müssen (vgl. ID32, ID35, Tabelle 5 im Anhang).

S-Tags

Als nächstes wurden die Experten nach ihrer Meinung zur folgenden Leitfrage gefragt: „Wie beurteilen Sie die Verwendung von S-Tags?" (Folie 10, [39]). S-Tags empfanden die Interviewten als eine gute Lösung, um „Security Anforderungen im Backlog zu strukturieren und hervorzuheben" (ID40, Tabelle 5 im Anhang) (vgl. ID15, Tabelle 5 im Anhang). Deshalb wird es auch nicht als notwendig betrachtet, einen separaten Security Backlog zu führen, da die Anforderungen seitens der IT-Sicherheit durch die Verwendung der S-Tags hervorgehoben werden und dadurch ein Bewusstsein geschaffen wird (vgl. ID16, ID17, Tabelle 5 im Anhang). Zusätzlich wurde betont, dass in den Sprints stets die miteinander verbundenen User Storys bearbeitet werden sollten. Das bedeutet, sowohl die grundlegende User Story als auch die zugehörige Story, die sicherstellt, dass die Umsetzung sicherheitskonform erfolgt, sollten gemeinsam umgesetzt werden (vgl. ID39, Tabelle 5 im Anhang).

Anwendbarkeit

Die sechste Frage, die den Interviewteilnehmenden gestellt wurde, war: „Wie bewerten Sie die Anwendbarkeit des VS-Scrum Frameworks in Ihrer aktuellen Arbeitsumgebung?" (Folie 11, [39]).

Die Experten legten besonderen Wert auf den Aspekt des IT-Sicherheit-Inputs und der IT-Sicherheits-Spezialisierung durch den Security Master (vgl. ID42, Tabelle 5 im Anhang). Sie betonten, dass diese Komponente in vielen aktuellen Arbeitsumgebungen fehlt und daher das VS-Scrum Framework als sehr gut anwendbar erachtet wird (vgl. ID42, Tabelle 5 im Anhang). Besonders die spezialisierte Rolle des Security Masters füllt in vielen Projekten eine Lücke, die bisher oft unberücksichtigt blieb (vgl. ID42, Tabelle 5 im Anhang).

Herausforderungen bei der Implementierung

Anschließend wurde sich über die erwarteten Herausforderungen bei der Implementierung des VS-Scrum Frameworks ausgetauscht. Die zugehörige Interviewfrage lautete: „Welche Herausforderung sehen Sie bei der Implementierung des VS-Scrum Frameworks in Ihrem aktuellen Projekt?" (Folie 12, [39]).

Ein zentrales Thema sind die Ressourcen und die Budgetierung im Zusammenhang mit IT-Sicherheit (vgl. ID47, Tabelle 5 im Anhang). Es wurde betont, dass die aktuelle Situation in der Organisation des Interviewpartners 1 oft als ‚Black Box’ wahrgenommen wird und es schwierig ist, Security in einem agilen Ansatz zu planen sowie zu integrieren (vgl. ID48 und ID49, Tabelle 5 im Anhang).

Ein weiteres wiederkehrendes Thema ist die Notwendigkeit, zusätzliche Ressourcen für die IT-Sicherheit bereitzustellen. Dies wurde als eine der größten Herausforderungen eingestuft (vgl. ID50, Tabelle 5 im Anhang). Ergänzend dazu wurde darauf hingewiesen, dass IT-Sicherheitshemen oft übersehen werden und nicht ausreichend Ressourcen bereitgestellt werden (vgl. ID51, Tabelle 5 im Anhang). Deshalb besteht die Notwendigkeit, IT-Sicherheit in der Unternehmensführung und Strategie entsprechend zu beachten und zu priorisieren (vgl. ID52, im Anhang).

Ein weiterer Kritikpunkt war die Tatsache, dass in der Organisation des Interviewten 4 viele Projektleitungen nicht ausreichend über das Prozessmodell und die IT-Sicherheitsanforderungen informiert sind (vgl. ID53, Tabelle 5 im Anhang). Es ist allerdings wichtig, das Wissen über IT-Sicherheitsanforderungen in der gesamten Organisation zu verankern (vgl. ID54, Tabelle 5 im Anhang).

Effektivität

Als nächstes wurde die Effektivität des VS-Scrum Frameworks betrachtet. Hierfür antworteten die Teilnehmenden auf die Frage: „Wie bewerten Sie die Effektivität des VS-Scrum Frameworks in Bezug auf IT-Sicherheit?" (Folie 14, [39]).

Die Bewertung fiel überwiegend positiv aus. Ein zentrales Element war die Minimierung des Risikos technologischer Fehlentscheidungen, die im schlimmsten Fall schwerwiegende Auswirkungen haben. Dies könnte unter anderem eine Neuentwicklung sein (vgl. ID61, ID62, ID64, Tabelle 5 im Anhang), wenn beispielsweise von Beginn an auf einen falschen, unsicheren Technologie-Stack gesetzt wird. Es wurde hervorgehoben, dass eine organische Integration von IT-Sicherheit in das Produkt vorteilhaft ist, da sie nicht als zusätzliches Element hinzugefügt, sondern von Anfang an in den Entwicklungsprozess integriert wird (vgl. ID65, Tabelle 5 im Anhang).

Die Befragten betonten zudem die Prozesssicherheit des Frameworks und die Notwendigkeit, IT-Sicherheit von Beginn an zu berücksichtigen (vgl. ID62, ID66, Tabelle 5 im Anhang). Darüber hinaus wird die Meinung geäußert, dass die kontinuierliche Berücksichtigung von IT-Sicherheit die Kreativität im Team fördert, weil sie einen konstanten Wert im Projekt darstellt (vgl. ID67, Tabelle 5 im Anhang).

In diesem Kapitel wurde die erste Forschungsfrage ‚Wie bewerten Experten das VS-Scrum Framework in Bezug auf die Sicherstellung von IT-Sicherheit in Scrum-Projekten?’ beantwortet (vgl. Kapitel 1.2). Zusammenfassend zeigen die Ergebnisse, dass das Framework generell positiv aufgenommen wird, jedoch noch Raum für Verbesserungen besteht. Da die Evaluierung des VS-Scrum Frameworks in seiner ersten Version abgeschlossen ist, wird es nachfolgend mit ‚VS-Scrum Framework 1.0’ referenziert. Die folgenden Kapitel dieser Arbeit widmen sich der gezielten Weiterentwicklung des VS-Scrum Frameworks.