Eine DevSecOps-Kultur fördern: Implementierungen aus der Praxis

Auf dem fortlaufenden Weg zur Einführung und Weiterentwicklung eines DevSecOps-Modells können alle davon profitieren, wenn Erfolge und Erkenntnisse geteilt werden. Die folgenden Beispiele zeigen Organisationen, die DevSecOps eingeführt haben und ein höheres Reifegradniveau erreichen wollten.

DevSecOps bei Auth0

• Ein reibungsloses Erlebnis für Cloud-Entwickler schaffen

• Datenanalysen nutzen

• Risiken früh im SDL priorisieren

• Gemeinsam befähigen, flexibel entwickeln

Seit den Anfängen setzt Auth0 in großem Umfang auf die AWS-Cloud-Infrastruktur, um Kunden Lösungen für das Identitätsmanagement bereitzustellen. Mit dem rasanten Wachstum des Unternehmens und seines Serviceangebots musste Auth0 sicherstellen, dass seine Cloud-Infrastruktur geschützt ist. Duncan Godfrey, Senior Director of Security and Compliance, war kürzlich im Podcast The Secure Developer zu Gast und sprach über die Strategie zum Schutz dieser Umgebung.

Ein eigenes Cloud-Sicherheitsteam bei Auth0 ist für den Schutz der AWS-Umgebung verantwortlich. Damit das Team jedoch nicht in eine traditionelle SecOps-Denkweise verfällt, spielt Automatisierung mit Schwerpunkt auf Monitoring eine entscheidende Rolle. Godfrey zufolge lautet der Auftrag dieses Teams: „Sicherzustellen, dass wir Daten aus jeder erdenklichen Ecke und jedem Winkel von AWS erfassen und zur Analyse heranziehen.“ Dadurch steht das Team mit den Entwicklungsteams in engem Austausch, die nach einem DevOps-Modell arbeiten. Durch diese Zusammenarbeit mit den DevOps-Teams kann das Unternehmen insgesamt für mehr Transparenz sorgen. 

Für Auth0 und das Cloud-Sicherheitsteam ist es besonders wichtig, den Entwicklern ein „reibungsloses“ Erlebnis zu bieten. Die Sicherheitsintegration beginnt früh im SDL mit einem kurzen Formular, das dabei hilft, den erforderlichen Umfang der Zusammenarbeit mit dem Sicherheitsteam festzulegen. Funktionen mit hohem Risiko, etwa öffentliche Endpunkte, werden mit stärkerer Einbindung des Sicherheitsteams umgesetzt. „Wir begleiten sie dabei, damit hoffentlich von Anfang an die Anforderungen und geeigneten Kontrollen feststehen. So erhalten wir sichere Software und führen am Ende noch weitere Tests durch“, so Godfrey.

Die Kultur bei Auth0 ist eindeutig von gemeinsamer Befähigung geprägt. Entwickler können Software auf eine Weise entwickeln, die ihren Anforderungen entspricht, und zugleich werden ausgereifte Sicherheitspraktiken gefördert. So kann Auth0 weiterhin neue Technologien nutzen und gleichzeitig eine solide Sicherheitslage gewährleisten.

DevSecOps bei Segment

• Sich in die Lage der Entwickler versetzen

• DevSecOps mit Infrastructure as Code ermöglichen

• Sicherstellen, dass Entwickler neue Tools nutzen können

• Teamübergreifend eingebundene Fachkräfte

In einer kürzlich erschienenen Folge des Podcasts The Secure Developer sprachen Leif Dreizler und Eric Ellett darüber, wie wichtig dem Anbieter der Kundendatenplattform Segment die Zusammenarbeit zwischen Entwicklungs-, Sicherheits- und Betriebsteams ist. Segment arbeitet im Unternehmen nicht mit Sprints, sondern die Teams agieren unabhängig voneinander. Dank eines Beratungsmodells wird das Sicherheitsteam dennoch früh in den Entwicklungsprozess eingebunden, um Threat Modeling und Design-Reviews zu ermöglichen.

Bei Segment ist Empathie fest in der Kultur des Sicherheitsteams verankert. Das Team orientiert sich an dem Grundsatz: „Sich in die Lage der Entwickler versetzen.“ Ellett erklärte, dass sich das Sicherheitsteam intensiv darum bemüht, zu verstehen, wie sich seine Sicherheitsprozesse auf andere Unternehmensbereiche auswirken. Als das Unternehmen beispielsweise die Multi-Faktor-Authentifizierung einführen wollte, arbeitete Dreizler ein Quartal lang eng mit dem Entwicklungsteam zusammen. So erhält das Sicherheitsteam wertvolle Einblicke in die Herausforderungen des Entwicklungsteams und in die zu schützenden Bereiche.

Der Fokus auf Zusammenarbeit geht jedoch noch weiter. Ellett erklärte, dass ähnliche Initiativen auch in die andere Richtung stattfinden sollen. Mitarbeitende aus anderen Unternehmensbereichen sollen mit dem Sicherheitsteam zusammenarbeiten und dessen Perspektive kennenlernen. Dreizler sagte: „Ich denke, genau das sollte DevSecOps erreichen. Ähnlich wie bei DevOps, wo Betriebsteams das Programmieren lernen, ist bei Segment inzwischen die gesamte Infrastruktur Code.“

Segment setzt auch konsequent auf den „vorgezeichneten Weg“. Ein Leitprinzip des Sicherheitsteams lautet: „Würde der Entwickler dieses Tool nutzen?“ Anders gesagt: Im Mittelpunkt steht die einfache Anwendung, damit Sicherheitskontrollen auch tatsächlich eingeführt werden. Dreizler zufolge geht es letztlich darum, „es den Menschen so einfach wie möglich zu machen, das Richtige zu tun.“

Mit diesem kooperativen und empathischen Ansatz hat Segment eine starke Kultur der Zusammenarbeit im Unternehmen aufgebaut. Das ist ein Beispiel dafür, wie sich das Versprechen von DevSecOps einlösen lässt: indem alle Funktionen auf das gemeinsame Ziel ausgerichtet werden, das Richtige für das Unternehmen zu tun.

10X Banking setzt auf DevSecOps

• Transparenz über Sicherheitslücken im gesamten Unternehmen

• Tägliche teamübergreifende Stand-up-Meetings bringen alle zusammen

• Automatisierung für die sichere Bereitstellung von Code nutzen

• Stakeholder mit einem Threat-Modeling-Kartenspiel einbinden

Neil Drennan von 10x Future Technologies war in einer kürzlich erschienenen Folge des Podcasts The Secure Developer zu Gast bei Guy Podjarny. Drennan erläuterte, wie das Unternehmen mit wichtigen Kommunikationsstrategien die Beteiligung an Sicherheitspraktiken fördert und gleichzeitig die erste Cloud-native Banking-Plattform entwickelt. 10x legt großen Wert darauf, Sicherheit zu einem Bestandteil der Aufgaben aller zu machen: durch Transparenz und wirksame Kommunikation, Zusammenarbeit im Arbeitsalltag und proaktive Sicherheitsmaßnahmen.

Im Gespräch erörterten Guy und Neil, wie 10x die Zusammenarbeit zwischen externen Sicherheitsteams und internen Plattformteams gestaltet. Neil erklärte, dass bei 10x alle den aktuellen Stand der Sicherheitslücken einsehen können, die von den im Unternehmen eingeführten Tools erfasst werden. „Wenn wir Toolsets verwenden und bei entdeckten Sicherheitslücken Warnmeldungen ausgeben, sind diese Informationen transparent und für alle zugänglich. Jede Person im Team kann den aktuellen Stand der Sicherheitslücken im gesamten Unternehmen einsehen“, so Drennan. Diese Transparenz ist entscheidend, damit alle Teams ihre Rolle bei der gemeinsamen Verantwortung für die Bereitstellung sicherer Software verstehen.

Die Zusammenarbeit geht jedoch über den Einblick in aktuelle Sicherheitslücken hinaus. Bei täglichen Stand-up-Meetings mit Beteiligten aus verschiedenen Teams im Unternehmen stellt 10x sicher, dass unterschiedliche Perspektiven bei der Besprechung aktueller Sicherheitslücken berücksichtigt werden. Neil sagte: „Wir besprechen [aktuelle Sicherheitslücken] täglich im Stand-up mit allen Teams. Dabei geht es nicht nur um die funktionale Bereitstellung. Funktionale und nichtfunktionale Aspekte sowie Sicherheit kommen jeden Morgen zusammen.“ Drennan betonte, dass diese Strategie besonders wichtig dafür ist, wie das Unternehmen mit der zunehmend dynamischen Bedrohungslage umgeht.

Drennan erläuterte, wie wirksam diese Gespräche sind: „Ich denke, das macht die Teams wirklich effektiver. Ein offener Kommunikationskanal zwischen den Teams ist unglaublich wichtig.“ Auch das stärkt das Konzept der gemeinsamen Verantwortung für sichere Software und verankert es in der Unternehmenskultur. So kann 10x das gegenseitige Verständnis und die Empathie zwischen den verschiedenen Rollen im Unternehmen fördern.

Neil beschrieb außerdem, wie 10x durch Threat Modeling dafür sorgt, dass Sicherheit frühzeitig in der Bereitstellungspipeline berücksichtigt wird. In seinem State of DevOps Report 2019 stellte Puppet fest, dass gemeinschaftliches Threat Modeling die Sicherheitslage eines Unternehmens erheblich verbessern kann. Damit sich die Stakeholder aktiv an dieser wichtigen Aufgabe beteiligen, nutzt 10x Kartenspiele zum Threat Modeling, um Bedrohungen anhand des STRIDE-Modells zu identifizieren. „Die Teams mit ihren Kartensets zusammenzubringen und verschiedene Szenarien mit Sicherheitslücken durchzuspielen, ist eine sehr ansprechende Möglichkeit, sie für Sicherheit zu begeistern und kontinuierlich über die richtigen Aspekte nachdenken zu lassen“, so Drennan.

Indem 10x die Grundlagen – Menschen, Prozesse und Technologien – in den Mittelpunkt stellt, konnte das Unternehmen einzigartige Praktiken einführen und eine Sicherheitskultur rund um die Softwarebereitstellung schaffen. Der Ansatz zeigt, wie alle drei Elemente auf kooperative Weise zusammenwirken können, damit 10x effiziente, zuverlässige und sichere Software bereitstellt.

Die DevSecOps-Kultur bei Datadog stärken

• Hürden abbauen und Sicherheit schrittweise in die Phasen der Bereitstellungspipeline integrieren

• Sicherheitsexperten in Entwicklungsteams einbinden, um Empathie und gemeinsame Verantwortung zu fördern

• Sicherheit als aktiver Beitrag zur Automatisierung der Pipeline

Datadog zeigt beispielhaft, wie sich Automatisierung und die Integration von Sicherheit in die Pipeline voranbringen lassen, indem zunächst die menschlichen Aspekte angegangen werden. Das Unternehmen hat ein Programm ins Leben gerufen, um Empathie zwischen organisatorischen Silos aufzubauen und die Zusammenarbeit zu verbessern. Außerdem trägt das Sicherheitsteam aktiv zur Automatisierung und zu den Tools in der Pipeline bei. Als Douglas DePerry im Podcast The Secure Developer zu Gast war, leitete er die Produktsicherheit bei Datadog und berichtete über einige innovative Ansätze zur Bewältigung dieser zentralen DevSecOps-Herausforderungen.

Der Versuch, Software schneller und besser zu entwickeln, scheitert oft. Wenn Sie Dutzende Male am Tag Code in die Produktion bringen, können Sie unmöglich alles überprüfen.  Datadog integrierte Sicherheitsexperten in die Entwicklungsteams – manchmal für einige Wochen, manchmal für mehrere Monate. Das Bewusstsein für Sicherheit zu stärken, hat für das Unternehmen Priorität. Dazu gehört auch, klarzumachen, dass Sicherheit in der Verantwortung aller liegt: „Lassen Sie mich helfen, einige dieser leicht zu behebenden Probleme oder Sicherheitsfehler zu beseitigen“ und dabei Wissen zu vermitteln und gemeinsam zu lernen.

DePerry zufolge muss „das Sicherheitsteam mehr Code schreiben. Es braucht mehr Automatisierung. So erzielen Sie einen Multiplikatoreffekt und können mit dem Tempo Schritt halten, in dem Code bereitgestellt wird.“ Datadog entwickelte dazu ein speziell auf die eigenen Anforderungen zugeschnittenes Tool. Damit kann das Sicherheitsteam den Entwicklungsteams umsetzbare Hinweise und Aufgaben zur Behebung bereitstellen, die auf dem von ihnen geschriebenen Code basieren.

Datadog hatte zuvor in ein Static Analysis Security Tool (SAST) investiert. Ursprünglich sollte es den Nachweis der Compliance erleichtern, doch leider erfüllte es die Anforderungen nicht und ließ sich nicht gut in die bestehende DevOps-Pipeline integrieren. Deshalb entwickelte das Unternehmen ein eigenes Tool für SAST- und Software Composition Analysis (SCA)-Scans. DePerry berichtete: „Wir haben das Tool wenig einfallsreich Middleware genannt. Im Grunde war es ein Framework, für das wir weitere Plugins entwickeln konnten. Wir hatten also ein Plugin für statische Analysen und eines für Sicherheitslücken in Abhängigkeiten.“

DePerry sagte uns außerdem: „Sie müssen sich auf das konzentrieren, was Sie zuerst treffen wird. Aber wie entscheiden Sie das wirklich? Ich denke, je mehr Sie prognostizieren können – denn bestimmte Dinge lassen sich derzeit nur schwer messen, was die Prognose erschwert und fehleranfällig macht –, desto besser. Wenn Prognosen richtig eingesetzt werden, können sie dabei wirklich helfen.“

Cloud-Native-Kultur bei Pivotal

• Warum es bei der Cloud-Native-Transformation wichtig ist, Sicherheit zu einem Teil der Unternehmenskultur zu machen

• Schaffen Sie Leitplanken statt Hürden, damit Entwickler den sicheren Weg einschlagen

• „Pairing“ von Entwicklern und Sicherheitsexperten, um Empathie und gemeinsame Verantwortung zu fördern

Die Einführung von DevSecOps und die Transformation hin zu Cloud-Native-Technologien gehen oft Hand in Hand. Damit sich das Unternehmen an diese neuen Paradigmen anpassen kann, ohne die Sicherheit zu gefährden, muss auch ein kultureller Wandel stattfinden. Die Sicherheit muss sich ihrerseits von der Vorstellung lösen, Kontrollen als Hürden in der Delivery-Pipeline einzusetzen. Vieles davon lässt sich erreichen, indem Empathie und gemeinsame Verantwortung zwischen Entwicklern und Sicherheitsexperten gefördert werden.

Steve White, Field-CISO bei Pivotal (heute eine Tochtergesellschaft von VMWare), war kürzlich im Podcast The Secure Developer zu Gast. In seiner Folge teilte er einige Gedanken zur Cloud-Transformation, zur Rolle der Sicherheit in der DevSecOps-Pipeline und dazu, wie eine engere Zusammenarbeit von Sicherheit und Entwicklung zu besseren Ergebnissen führen kann. Steve arbeitet intensiv mit Sicherheitsverantwortlichen und Führungskräften an der Sicherheitsarchitektur für das Engineering. In praxisorientierten Workshops vermittelt er Vertretern der verschiedenen DevSecOps-Disziplinen, worauf es bei Cloud-Native-Sicherheit ankommt.

Ein entscheidender Faktor für die Transformation eines Unternehmens durch die Einführung von DevSecOps ist, den Fokus nicht nur auf Tools zu richten. „Der erste Grundsatz für Veränderungen in diesem Bereich lautet: Es geht nicht nur um einen Technologiewandel, auch wenn sich die Technologie teilweise ändern muss. Es geht um einen Wandel der Kultur und der Perspektive. Das ist letztlich der größere Teil dessen, was in der Informationssicherheit geschehen muss – so wie es auch im übrigen Unternehmen geschehen ist“, erklärte White. Damit wird anerkannt, dass DevOps viele kulturelle Veränderungen angestoßen hat, bei denen die Sicherheit ebenfalls aufholen muss.

Eine der zentralen Perspektiven, an deren Übernahme sich Sicherheitsexperten schwertun, ist die Frage, wie sich Sicherheitspraktiken in die Pipeline integrieren lassen. White sagte: „Ich spreche gern davon, dass wir uns von Hürden zu Leitplanken bewegen. Die Sicherheitsfunktion im Unternehmen sollte künftig diese Leitplanken bereitstellen – sie sind wie ein Sicherheitsnetz. Oben und unten begrenzen Leitplanken den Bereich, damit Sie keine wirklich kritischen Grenzwerte überschreiten, lassen Ihnen innerhalb dieser Grenzen aber Spielraum.“ Diese Sichtweise zeigt, worauf es ankommt, damit die Sicherheit die DevOps-Bewegung glaubwürdig und vor allem kompatibel mitgestalten kann.

Eine weitere Möglichkeit, das Vertrauen der Entwickler in die Sicherheitsteams zu stärken, ist der Aufbau von Empathie. Wenn Sicherheitsexperten und Entwickler in ihrem Arbeitsalltag zusammenarbeiten, können sie Vertrauen aufbauen und die Arbeit des jeweils anderen besser wertschätzen. White führte dazu aus: „Wenn ich von Pairing spreche, meine ich echtes Pair-Programming: Zwei Personen sitzen vor einem Bildschirm und lösen gemeinsam ein Problem. Wenn eine davon Security Engineer und die andere Feature-Entwickler ist, lernen beide viel und bringen wertvolle Beiträge in die Diskussion ein.“

Insgesamt spricht White einige zentrale Grundsätze an, die Teil jeder DevSecOps-Kultur sein sollten. Da Cloud Native in manchen Fällen die Einführung von DevSecOps vorantreibt und DevSecOps in anderen Fällen die Cloud-Transformation beschleunigt, wird deutlich, wie eng beides miteinander verknüpft ist. Unternehmen sollten diesen Zusammenhang kennen und darauf vorbereitet sein, beides als Teil eines umfassenden Wandels der Unternehmenskultur einzuführen, um aus beiden Bereichen geschäftlichen Nutzen zu ziehen.

DevSecOps bei Cisco/Duo

• Sicherheit in die Pipeline bringen: „Dort ansetzen, wo die Teams arbeiten“

• Sicherheit frühzeitig mitdenken und Sicherheitskonzepte bereits bei neuen Technologiechancen definieren

• Metriken müssen differenzierter sein und auf kontinuierliche Verbesserung ausgerichtet werden

Die DevSecOps-Kultur beruht auf der Idee, die Effizienz entlang der gesamten Pipeline zu steigern. Entwickler sollen so effizient wie möglich vom Backlog bis zum Deployment arbeiten können. Damit Sicherheit wirklich Teil der Pipeline ist, müssen sichere Praktiken reibungslos integriert werden. Dazu trägt bei, Sicherheitskonzepte so früh wie möglich zu definieren. Das ebnet Entwicklern den Weg, wenn sie mit dem Programmieren der gewünschten Funktionen beginnen. Wenn sich jedoch nicht zuverlässig messen lässt, wie sich diese Praktiken auf die Sicherheitslage auswirken, ist es außerordentlich schwierig zu begründen, warum sie Teil der Pipeline bleiben sollten.

Cisco-CISO und ehemaliger Leiter von Duo Security Michael Hanley war im Podcast The Secure Developer zu Gast und berichtete von den konkreten Ansätzen, mit denen Cisco/Duo diese Herausforderungen angeht. Hanley kam 2018 im Zuge der Übernahme von Duo zu Cisco und leitete dort fünf Jahre lang die Sicherheitsinitiativen. Seine Erkenntnisse zur Integration von Sicherheit in bestehende Entwicklertools, zum frühzeitigen Einbeziehen von Sicherheit in die Konzeption und zur Erhebung aussagekräftiger Metriken beruhen auf dieser umfangreichen Erfahrung.

Beim Aufbau einer DevSecOps-Kultur konzentrieren sich viele Unternehmen auf die Tools, die eine schnellere Pipeline ermöglichen sollen. Zu Beginn der DevOps-Bewegung bedeutete das vor allem, alles zu automatisieren: Code-Commits lösten automatisierte Builds aus, die Weitergabe von Code startete automatisierte Regressionstests und so weiter. Der Sicherheit ist es jedoch traditionell schwergefallen, Prozesse und Tools einzuführen, die zu diesem Modell passen. Das Ergebnis sind oft zusätzliche Reibungsverluste.

Diese Reibungsverluste frustrieren Entwickler und können die Einführung sicherer Praktiken behindern. Hanley berichtete, dass Duo sich darauf konzentrierte, bestehende Tools einzubinden. Er sagte: „… wir gehen dorthin, wo unsere Engineers am liebsten arbeiten, und sprechen sie dort an. Wir nutzen zum Beispiel dieselben Ticketsysteme wie für die Quellcodeverwaltung und die übrige Nachverfolgung der Engineering-Arbeit. Wir arbeiten viel mit unseren Engineering-Teams in diesen vertrauten Umgebungen, um ihnen den Einstieg zu erleichtern.“ Die Teams dort abzuholen, wo sie arbeiten, und die Tools einzubinden, die sie bereits kennen, ist ein wirkungsvoller Ansatz zum Aufbau einer echten DevSecOps-Kultur.

Hanley sprach außerdem ein weiteres wichtiges Konzept an, um Sicherheit in die Pipeline zu bringen: Security nach links zu verlagern. Das Konzept ist nicht neu, doch in einer DevSecOps-Kultur müssen Sicherheitsteams immer früher ansetzen. Hanley sagte: „… wenn ich den Softwareentwicklungslebenszyklus bei Duo betrachte, würde ich den frühesten Zeitpunkt dort verorten, wo unser Labs-Team eingebunden ist. Dazu gehört, strategisch neue Technologiechancen zu identifizieren, aber auch früh festzulegen, wie gute Sicherheitsdesignparameter aussehen sollten …“

Das ist ein wichtiger und sehr innovativer Ansatz. Wenn Unternehmen Sicherheitskonzepte festlegen, bevor eine User Story überhaupt im Backlog landet, können sie sicherstellen, dass Entwickler von Anfang an dokumentierte Sicherheitsanforderungen haben. So wird verhindert, dass die Sicherheitskonzeption die schnelle Bereitstellung von Code beeinträchtigt. Sicherheit wird dadurch zum Wegbereiter: Entwickler können schneller von den Sicherheitskonzepten zur Programmierung übergehen. Außerdem müssen sie sich keine Sorgen machen, wichtige Sicherheitsaspekte zu übersehen, die später in künftigen Sprints als Schwachstellen behoben werden müssten.

Wie können Unternehmen feststellen, ob diese Ansätze die gewünschte Wirkung erzielen? Hier sind Metriken entscheidend. „Ich habe grundsätzlich ein großes Problem mit Sicherheitsmetriken und dem Zählen von Bugs nach Volumen … Damit lassen sich viele Programme und insbesondere unseres nicht differenziert genug beschreiben“, sagte Hanley. Das ist für viele Unternehmen eine echte Herausforderung. Eine einfache Zahl offener Bugs liefert keinen Kontext. Wie viele Releases haben diese Schwachstellen verursacht? Ist die Zahl der Schwachstellen niedrig, weil die Sicherheit besser geworden ist, oder wurde die Anwendung schon lange nicht mehr getestet? Metriken müssen mehr Kontext bieten.

Hanley erläuterte, wie Cisco/Duo ein Reifegradmodell einsetzt, um den Erfolg des Programms zu messen: „Das Reifegradmodell, das wir bei Duo verwenden, ist eine Mischung aus BSIMM und SAMM … Wir überlegen, welche wichtigen Metriken sich daraus ableiten lassen, welcher Anteil der Aktivitäten zumindest teilweise abgedeckt ist und welcher Anteil vollständig abgedeckt wird.“

Außerdem erwähnte er einen weiteren wichtigen Aspekt, den Unternehmen bei Metriken berücksichtigen sollten. Hanley berichtete, dass ihr Ansatz den Fokus auf kontinuierliche Verbesserung lenkte. Viele Sicherheitsinitiativen scheitern, weil sie astronomische und schlicht unrealistische Ziele anstreben. Wenn wir uns stattdessen auf Fortschritt statt auf Zielerreichung konzentrieren, bleibt Raum für Fehler, Anpassungen und Innovationen. So lässt sich der geschäftliche Nutzen von Sicherheitspraktiken letztlich leichter nachweisen.

Die Erkenntnisse, die Hanley aus seiner Zeit bei Duo teilte, zeigen, vor welchen Herausforderungen jedes Unternehmen steht, das eine DevSecOps-Kultur aufbauen möchte.

Cloud-Sicherheit mit 2nd Sight Lab

• Entwickler befähigen, indem Sie ihnen Best Practices für Cloud-Sicherheit vermitteln

• Empathie zwischen Entwicklern und Sicherheitsexperten fördern

• Governance als Bestandteil der Cloud-Sicherheit

Da die Cloud-Transformation in den IT-Strategien der meisten Unternehmen im Mittelpunkt steht, können die Herausforderungen bei der Absicherung dieser Umgebungen noch größer werden. Entwickler sollen Cloud-Native-Technologien nutzen können, ohne die Sicherheit zu gefährden – das ist nicht immer einfach. Für die Sicherheit komplexer Cloud-Umgebungen ist es außerdem entscheidend, dass die verschiedenen Disziplinen im Unternehmen zusammenarbeiten und das große Ganze verstehen. Schließlich ist es bei jeder solchen Unternehmenstransformation wichtig, das Programm zu überwachen und aus Fehlern zu lernen.

Guy Podjarny sprach mit Teri Radichel, CEO von 2nd Sight Lab und Autorin von Cybersecurity for Executives in the Age of Cloud. Teri erzählte, wie sie nach einem Sicherheitsvorfall bei ihrem früheren Unternehmen für Webanwendungsentwicklung und -hosting in die Welt der Cloud-Sicherheit kam. 2nd Sight Lab ist ein Schulungs- und Beratungsunternehmen für Cloud-Sicherheit. Viele ihrer Erkenntnisse beruhen nicht auf der Einführung von Cloud-Technologie in einem einzelnen Unternehmen, sondern auf ihrer beratenden Tätigkeit für zahlreiche Unternehmen.

Ein grundlegendes Problem, das bei Gesprächen über Cloud und Cloud-Transformation aufkommt, ist die schlichte Frage, was mit „Cloud“ eigentlich gemeint ist. Teri sagt dazu: „Manche sagen, es sei einfach der Computer von jemand anderem. Ich sage aber immer, dass mehr dahintersteckt, denn als ich in einem Managed-Hosting-Rechenzentrum arbeitete, war das auch der Metallcomputer von jemand anderem, oder?“ Für manche Unternehmen können sogar Software-as-a-Service-Lösungen (SaaS) Teil ihrer Cloud-Strategie sein.

Wenn schon das Verständnis der Cloud komplex ist, bedeutet die dynamische Natur von Cloud-Native-Technologien, dass wir Entwicklern viel Verantwortung für die Sicherheit übertragen. Teri ging auf diese Komplexität ein: „Wenn Sie als Entwickler jetzt Netzwerke aufbauen oder S3-Buckets, Load Balancer oder CDNs konfigurieren sollen, müssen Sie sich unbedingt mit den Best Practices vertraut machen.“ Ihr Rat an Entwickler: „Es gibt die CIS Benchmarks, die Ihnen Best Practices für alle drei führenden Cloud-Anbieter nennen.“

Ein weiterer wichtiger Schlüssel zum Umgang mit der Komplexität von Cloud-Sicherheit besteht natürlich darin, Entwickler und Sicherheitsexperten zusammenzubringen, damit sie Wissen austauschen, die Aufgaben der jeweils anderen verstehen und gemeinsam auf sichere Software hinarbeiten. Radichel betonte, dass die Sicherheitsteams dabei eine aktive Rolle übernehmen müssen. „Ich glaube, dass Sicherheit auch eine wichtige Funktion hat, die nicht direkt an der Tastatur stattfindet. Es geht nicht um Anwendungssicherheit und darum, sicherzustellen, dass Ihr Code keine Cross-Site-Scripting-Schwachstelle enthält. Bei Sicherheit geht es um Risiken“, erklärte sie.

Bei jeder umfassenden Transformation ist es schließlich auch äußerst wichtig, dafür zu sorgen, dass festgelegte Prozesse und Verfahren konsequent eingehalten werden und dass wir aus Fehlern lernen. Radichel räumt ein: „Aber Menschen machen auch Fehler. Deshalb müssen Sie über Ihre gesamte Governance nachdenken und auch darüber, wie Sie Ihre Organisation so aufstellen, dass solche Fehler nicht passieren können, oder?“

Letztlich sorgt das gemeinsame Verantwortungsmodell einer echten DevSecOps-Kultur bei der Cloud-Transformation für bessere Praktiken. Radichels Beobachtungen und zentrale Empfehlungen verdeutlichen, wie wichtig es ist, dass alle Teams entlang der Delivery-Pipeline zusammenarbeiten, Wissen austauschen und sich auf ein gemeinsames Ziel konzentrieren.