Ein agiler Sicherheitsbeauftragter sein: Mentalität der Sicherheitsverantwortlichen

Dies ist der zweite Teil meiner Blogserie zum Thema "Agiler Sicherheitsbeauftragter sein". In diesem Blog werde ich mich auf die Denkweise des Sicherheitsbeauftragten in agilen und DevOps-Umgebungen konzentrieren. In der agilen Welt ist der Product Owner die Person, die Geschäfts- und Kundenwünsche in Arbeitselemente (User Stories) für die Teams umsetzt. Die eigentlichen Wünsche und Anforderungen werden jedoch von den Stakeholdern geliefert. Stakeholder sind in der Regel Vertreter des Unternehmens und der Endbenutzer; in der neuen Welt sollten Sicherheitsbeauftragte die Rolle von Sicherheitsinteressenten übernehmen. Der Product Owner hat in der Regel mehrere Stakeholder zu berücksichtigen. Als Sicherheitsbeauftragter müssen Sie mit anderen Beteiligten um die wertvollsten Änderungen 'konkurrieren'. Es ist heute wichtiger denn je, dass Sie Ihre Anforderungen in einen tatsächlichen Wert umsetzen können.

Sie handeln mit Unzufriedenen; finden Sie sich damit ab!

Das erste, was Sie als Sicherheitsverantwortlicher wissen müssen, ist die Art der Änderungen, die Sie einbringen. Im KANO-Modell werden die verschiedenen Arten von Änderungen in 3 Hauptgruppen eingeteilt [1]:

• Delighters: Das sind die coolen, hippen Dinge, von denen die Benutzer gar nicht wussten, dass sie sie haben wollen, die sie aber nicht mehr missen möchten, sobald sie eingeführt sind.
• Satisfiers: das sind die eher traditionellen Änderungen, die das Produkt schrittweise verbessern
• Grundlegende Erwartungen (oder Unzufriedene): die Dinge, um die sich niemand kümmert, bis sie nicht vorhanden sind

Leider haben Sie als Sicherheitsinteressent wahrscheinlich nicht viele Freudenspender, die Sie auf den Tisch legen können. In der Tat werden die meisten Ihrer Anfragen nicht einmal zufriedenstellend sein. Die Linie, auf der Sie sich bewegen, sind meist die Unzufriedenen; die Dinge, um die sich niemand kümmert, es sei denn, sie sind nicht vorhanden. Das Positive daran ist, dass dies meist auch die Anforderungen sind, über deren Wichtigkeit wenig diskutiert wird. Bei der Erstellung und Bewertung von User Stories ist es wichtig, die Art der Änderungen zu verstehen, die Sie fordern. Dies wird im nächsten Blog ausführlicher beschrieben. Das Wichtigste, was Sie sich jetzt merken sollten, ist, dass der Wert für die 3 Arten von Änderungen unterschiedlich definiert wird, und ein guter Product Owner erkennt das an.

Engagieren Sie sich

Wie bereits erwähnt, müssen Product Owner eine Vielzahl von Interessengruppen berücksichtigen. Aus rein praktischer Sicht ist es unmöglich, sie alle auf die gleiche Weise zufrieden zu stellen. Product Owner verwenden daher eine Technik namens Stakeholder-Mapping oder Stakeholder-Analyse, um herauszufinden, wie viel Aufwand sie für jeden Stakeholder betreiben müssen [2]. Beim Stakeholder Mapping werden die Stakeholder auf der Achse Macht (Einflussnahme) gegen Interesse (am Produkt) aufgetragen. Das Ergebnis dieser Analyse hilft den Produktverantwortlichen beim Management aller Stakeholder. Ein Beispiel für dieses Mapping und den entsprechenden Aufwand finden Sie in der folgenden Abbildung.

Glücklicherweise befinden sich die Sicherheitsbeamten in der Regel bereits in der oberen Hälfte dieser Karte. (Wenn dies nicht der Fall ist, müssen Sie wirklich zuerst an Ihrem Bewusstsein arbeiten!) Um ein erfolgreicher agiler Sicherheitsbeauftragter zu werden, ist es von größter Bedeutung, in den oberen rechten Quadranten zu gelangen. Wie bei jedem Verbesserungsansatz ist der wichtigste Schritt eine Änderung der Denkweise. Für Sicherheitsbeauftragte bedeutet dies, dass sie von einem reaktiven Ansatz zu einem proaktiven Ansatz übergehen müssen. Ich werde in meinen zukünftigen Blogbeiträgen auf die schmutzigen Details eingehen, aber einen schönen Überblick bietet das 'DevSecOps Manifesto':

Wie beim Agilen Manifest sollte auch diese Liste richtig interpretiert werden. Obwohl die Punkte auf der rechten Seite manchmal notwendig oder einfacher sind, führen die Punkte auf der linken Seite letztendlich zu einer besseren Lösung. Um als Sicherheitsverantwortlicher erfolgreich zu sein, sollten die Punkte auf der linken Seite daher immer das Ziel sein, das Sie verfolgen. Die einzige Möglichkeit, dies zu erreichen, besteht darin, mit den Produktverantwortlichen und ihren Teams zusammenzuarbeiten. Arbeiten Sie mit ihnen zusammen, verstehen Sie die Herausforderungen, vor denen sie stehen, und die Entscheidungen, die sie treffen müssen, und helfen Sie ihnen auf jede erdenkliche Weise, ihre Ziele zu erreichen.

Minimieren Sie die Arbeit

Wie bei jeder Optimierungsstrategie ist die Minimierung der Arbeit das oberste Ziel. Je weniger Zeit Sie für etwas aufwenden müssen, desto mehr können Sie tun und desto höher wird Ihre Effizienz. Aus der Perspektive der Sicherheit (oder des Datenschutzes, der Einhaltung von Vorschriften oder anderer Risiken) bedeutet dies, die Auswirkungen von Richtlinien und Anforderungen zu minimieren. Sicherheitsbeauftragte müssen sich in der Regel mit einer Vielzahl von Richtlinien befassen, die alle in irgendeiner Weise einen eigenen Nachweis erfordern. In der Realität müssen jedoch viele dieser Punkte nicht für jede einzelne Änderung nachgewiesen werden. Ein wichtiger Schritt in der Zusammenarbeit mit den Teams besteht darin, zu ermitteln, welche Punkte unter welchen Umständen nachgewiesen werden müssen. Microsoft hat mit seinem agilen Sicherheitskonzept [3] bereits eine Menge Vorarbeit geleistet.

Kurz gesagt, es läuft darauf hinaus, dass Sie die Policen in 3 Bereiche aufteilen:

• Anforderungen, die einmalig (oder z.B. jährlich) nachgewiesen werden müssen
• Anforderungen, die häufig nachgewiesen werden müssen, aber unabhängig von tatsächlichen Einsätzen
• Anforderungen, die bei jedem Einsatz nachgewiesen werden müssen

Mit diesem Ansatz minimieren Sie die Arbeitsbelastung der Teams, was letztlich dazu führt, dass mehr Änderungen möglich sind. Der nächste Schritt besteht darin, den effizientesten Weg zu finden, um den Nachweis zu erhalten. Auch hier ist die Minimierung des Zeitaufwands der Schlüssel. Als Sicherheitsbeauftragter sollten Sie dazu beitragen, indem Sie Richtlinien in die Build-Pipeline integrieren und die Sammlung von Beweisen automatisieren.

Werden Sie Mitglied des Teams!

Ein erfolgreicher Sicherheitsbeauftragter zu werden, ist eine Reise, ähnlich wie die eines Produktverantwortlichen. Chris Lukassen hat auch einige Blogs darüber geschrieben, was Sie auf dem Weg dorthin erwartet; ich empfehle Ihnen, diese zu lesen, bis ich meinen nächsten Blog schreibe. Sein Blog über die Implementierung des ISO27001-Standards in die agile Arbeitsweise ist ein sehr schönes Beispiel [4]. Als abschließende Anmerkung zu diesem Blog zeigt dieses Bild, wie man diese Reise nicht beginnen sollte :)

Alle Teile dieser Blogserie

Teil 1: Ein agiler Sicherheitsbeauftragter sein Teil 2: Die Denkweise der Sicherheitsverantwortlichen Teil 3: Pwn the Process Teil 4: Anwenderberichte Teil 5: Verbreiten Sie Ihr Wissen Links [1] Wiki-Seite zum Kano-Modell [2] Wiki-Seite zur Stakeholder-Analyse [3] SDL-Agile Anforderungen [4] ISO/IEC 27001:2013 und Scrum 5 Wege, es weniger schmerzhaft zu machen