Ein agiler Sicherheitsbeauftragter sein

Wann immer ich einen Vortrag halte, eine Schulung abhalte oder einfach nur mit Sicherheitsteams spreche, wird deutlich, dass im Laufe der Jahre eine Lücke zwischen Anwendungssicherheit und Entwicklung entstanden ist. Eine Kluft, die wir bewusst und mit Absicht geschaffen haben und die mit der Einführung von Agile und DevOps schmerzlich sichtbar wurde. Plötzlich wurden erschöpfende Informationssicherheitsrichtlinien mit Checklisten und Penetrationstests zu ernsthaften Hindernissen. Die Herausforderung, vor der wir jetzt stehen, ist, wie wir diese Lücke wieder schließen können. Glücklicherweise ist diese Herausforderung einfacher zu lösen, als es den Anschein hat. Der Schlüssel zum Erfolg liegt in der Aufteilung der Funktion des Sicherheitsbeauftragten in mehrere agile Rollen mit unterschiedlichen Verantwortlichkeiten und Aufgaben. In den kommenden Blogs werde ich tiefer in die verschiedenen Aspekte dieser Rollen und die Unterschiede bei den Verantwortlichkeiten und Aufgaben eintauchen. Doch zunächst müssen wir einen kleinen Ausflug in die Vergangenheit machen, um zu verstehen, wie wir in diese Situation geraten sind.

Ein wenig Geschichte

Informationssicherheit als Beruf begann mehr oder weniger 1985, als Stephen Katz der erste CISO (Chief Information Security Officer) bei Citibank wurde [1]. Die Sicherheit erhielt eine eigene Abteilung im Unternehmen mit einem eigenen C-Level Officer. Zu dieser Zeit schien dies eine logische Entscheidung zu sein. Sicherheit wurde mehr oder weniger durch Infrastruktur und Richtlinien definiert und hatte wenig mit der Anwendungsentwicklung zu tun. Das begann sich Mitte der neunziger Jahre mit dem Aufkommen von Webanwendungen zu ändern, aber wir (als Sicherheitsbranche) haben es versäumt, vielleicht sogar abgelehnt, dies zu erkennen und die Sicherheit von der Entwicklung getrennt gehalten.

Der Status Quo

Mit dem zunehmenden Einsatz von Webanwendungen, Cloud-Lösungen und vernetzten 'Dingen' wird die Sicherheit heutzutage größtenteils von der Entwicklung bestimmt, aber dennoch fallen die Sicherheitsaspekte in der Regel in die Zuständigkeit einer anderen Abteilung mit ihren eigenen Prozessen. Bis vor ein paar Jahren hat selbst diese unnatürliche Trennung keine großen Probleme verursacht. Sicher, die Sicherheit war die 'Abteilung von NO' und die Entwickler 'kümmerten sich nie um die Sicherheit', aber mit Risikobewertungen zu Beginn eines Projekts und Penetrationstests am Ende konnte das Endergebnis mehr oder weniger sicher werden. Die meisten Schwachstellen, die dennoch in der Produktion landeten, konnten von Incident-Response-Teams bearbeitet werden, und die Ergebnisse der jährlichen Prüfung wurden mit hoher Priorität behandelt und behoben, bevor Geldstrafen verhängt wurden. Dies war keine ideale Situation, aber für die meisten Unternehmen hat sie gut genug funktioniert.

Die Winde des Wandels

Dieser Status Quo geriet mit der Einführung von Agile und DevOps ins Wanken. Plötzlich gab es keinen 'Projektbeginn' mehr und die Release-Zyklen wurden so kurz, dass Penetrationstests zu einem ernsthaften Hindernis wurden. Da die Entwicklung in direktem Zusammenhang mit dem Geschäftswert und damit dem Unternehmensumsatz steht, wurde die Sicherheit aus Zeit- (und Geld-) Gründen immer mehr umgangen. Da die Verantwortung für die Sicherheit vor mehr als 2 Jahrzehnten der Entwicklung entzogen wurde, ist es nicht verwunderlich, dass die meisten Entwicklungsframeworks und -ansätze diesem Thema nicht viel Zeit widmen. Meistens gibt es einen kleinen Abschnitt, in dem erwähnt wird, dass Sicherheit wichtig ist und Sie sich an die Unternehmensrichtlinien halten sollten, und das war's [2]. Auch in der Ausbildung wird dem Thema in der Regel nicht viel Zeit gewidmet (obwohl sich das ändert), so dass die meisten Entwickler sich der Probleme gar nicht bewusst sind, es sei denn, sie recherchieren auf eigene Faust, unterstützt von Organisationen wie OWASP [3]. Die Sicherheitsspezialisten wiederum sind nicht in modernen Softwareentwicklungspraktiken geschult. Sie sind immer noch darauf trainiert, Tollgates, Checkpoints und eine Welt von ziemlich statischen Situationen zu verwenden, um widerstandsfähig zu werden und zu bleiben.

Weg mit dem Alten

Nachdem wir also 30 Jahre lang versucht hatten, sichere Software und Systeme zu entwickeln, standen wir am Ende vor zwei Welten, die sich bekriegten. Die eine wollte mit Ziegeln, Beton und Stahl bauen, die andere mit Lego und Meccano. Die Geschichte hat gezeigt, dass Geschwindigkeit immer über Sicherheit siegen wird. Selbst wenn Sie sich irren, obwohl Sie schnell sind, haben Sie mehr Zeit (und damit mehr Chancen), um zu korrigieren, und am Ende werden Sie gewinnen. Fließbänder, Workflow-Software, Lean, Agile, DevOps und alle anderen Ansätze, die die Geschwindigkeit erhöhen, haben über die alten Methoden gesiegt und werden dies auch in Zukunft tun. Die Lösung für den Kampf zwischen Sicherheit und Entwicklung liegt also nicht darin, die Entwicklung zu verlangsamen oder ihr weitere Schlagbäume hinzuzufügen. Stattdessen muss die Sicherheit anfangen zu verstehen, wie die neue Welt funktioniert und neue Wege finden, um die Situation wieder in den Griff zu bekommen. In der agilen Welt gibt es eine Reihe von Rollen, die Ihnen die Mechanismen dafür bieten.

Der Sicherheitsinteressent: Definieren, was und was nicht

Bei der agilen Arbeitsweise ist der Product Owner die Person, die die Wünsche des Unternehmens und der Kunden in Arbeitsaufgaben (User Stories) für die Teams umsetzt [4]. Die eigentlichen Wünsche und Anforderungen werden jedoch von den Stakeholdern geliefert. Als Security Stakeholder müssen Sie mit anderen Stakeholdern bei der Priorisierung von User Stories "konkurrieren". Daher ist es wichtig, dass Sie in der Lage sind, Anforderungen in echten geschäftlichen Nutzen zu übersetzen.

Der Sicherheitsexperte; Hilfe beim Wie

Sicherheitsexperten geben aktive Anleitung und Unterstützung innerhalb der Teams. Sie helfen aktiv bei der Implementierung von Sicherheitskontrollen und -mechanismen. Als Sicherheitsexperte sollten Sie sich auf die richtige Umsetzung der User Story konzentrieren und nicht die User Story selbst diskutieren, denn das ist die Aufgabe der Stakeholder.

Der Evangelist; die Messlatte höher legen

Abhängig von Ihrer Arbeitsbelastung als Sicherheitsexperte ist eine letzte interessante Rolle für Sicherheitsbeauftragte in agilen Welten die des Sicherheitsevangelisten. Der Evangelist fungiert als Fachexperte für alle Teams und coacht die Teams, damit sie mehr über Best Practices, Vorschriften, Tools und Informationen erfahren, sicherheits- und datenschutzbezogene Themen diskutieren und das Bewusstsein und die Fähigkeiten in den Teams verbessern.

Fortsetzung folgt!

Wie zu Beginn dieses Beitrags erwähnt, werde ich in einer kommenden Blogserie tiefer in die verschiedenen Aspekte dieser Rollen und die Unterschiede bei den Verantwortlichkeiten und Aufgaben eintauchen. In der Zwischenzeit kann ich Ihnen empfehlen, den Blog meines Kollegen Chris zu lesen, der mehr Hintergrundinformationen über die Rolle eines Product Owners und den Wachstumspfad bietet, den Sie als Stakeholder erwarten können (der meiner Meinung nach dem eines Product Owners ähnelt) [5].

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] Die Beeinflusser: Steve Katz [2] Wiki Agile Softwareentwicklung - Geregelte Bereiche [3] OWASP Foundation-Website [4] Scrum: Die mythische Rolle des Product Owner [5] Die fünf Bänder des Product Owner