Security zu einem kritischen Element machen

Seit einiger Zeit treibt ein Schlagwort die Entwickler und Security-Verantwortlichen um: DevSecOps, die systematische und logische Integration von Sicherheit in den DevOps-Prozess. Dies bedeutet in der Praxis, dass ein Unternehmen dafür sorgt, dass Security ein wesentliches, nahtlos integriertes Element von DevOps ist und keine nachträgliche Überlegung.

„Idealerweise gelingt es dabei Sicherheit zu einem kritischen Element zu machen, ohne Reibung zu erzeugen oder das Tempo von DevOps zu verlangsamen. Vielerorts steht die DevOps-Reise jedoch erst am Anfang – und die Praxis erweist sich als nicht so einfach wie die Theorie“, berichtet Martin Zeitler, Senior Manager Systems Engineering bei Palo Alto Networks .

Die Realität ist oftmals, dass es schon beim ersten Schritt zu einer möglichen Fehlausrichtung kommt. DevOps ist eine abteilungsübergreifende Gruppe mit einem einfachen Ziel: eine technologiebasierte Geschäftsfunktion bereitzustellen, die sich in der Regel im Laufe der Zeit weiterentwickelt. Hierin liegt die Diskrepanz: IT-Sicherheit versteht Risiken gerne und trifft fundierte Entscheidungen. Das DevOps-Team konzentriert sich auf die Erzielung von Ergebnissen, in der Regel in einem Tempo, das dem Wettbewerb voraus sein soll. In diesem Zusammenhang würden die Ingenieure das Thema Sicherheit eher als potenzielle Bedrohung für ihre gemessenen Ziele sehen.

Eine weitere Herausforderung besteht darin, dass sich die Erwartungen der Unternehmen an DevOps so schnell ändern können, wie sich das Projekt selbst entwickelt. Allzu oft beginnen diese Projekte als Skunkworks-Konzepte, bei denen oft externes Fachwissen eingekauft wird, um zu sehen, ob es im eigenen Unternehmen funktioniert. Das Projekt wird dann zum Erfolg und etabliert sich im Mainstream. Die Berater, die für den Einstieg herangezogen wurden, haben aber nicht die gleiche Sicherheitsbasis wie das Unternehmen. Die Bereitschaft, in einem kleinen Pilotprojekt Risiken einzugehen, ist in der Regel sehr unterschiedlich. Ein Blick in die Nachrichten genügt, um zu sehen, wie die Ausnutzung von Zugangsdaten zu Sicherheitsvorfällen führt.

„Wenn ein solches Projekt als einfaches Proof-of-Concept eingerichtet wurde, kamen zweifellos einfache Passwörter zum Einsatz oder wurden im Klartext gespeichert, damit andere Mitglieder des Teams leicht darauf zugreifen konnten. Sicherheit muss deswegen von Beginn an mit einbezogen werden“, meint Martin Zeitler.

DevOps besteht typischerweise aus funktionsübergreifenden Teams, die selbst dynamisch sein können. Es wird immer Reibungen zwischen diesen Rollen geben. Dies ist Teil dessen, was DevOps zum Erfolg führt, also kleine, dynamische Gruppen, die fokussierte Herausforderungen lösen. Die Agilität kann jedoch die Risiken der Cyberhygiene erhöhen. Der Wechsel von Mitarbeitern und Teams erschwert es, einen dauerhaften Security-Champion im Team zu haben. Außerdem können sich die Anforderungen an die Cybersicherheit ändern.

Dies betrifft beispielsweise das Risiko, dass Angreifer auf fremde Rechenleistung für Krypto-Mining zugreifen. Wenn die Firewall so konfiguriert ist, dass sie eine unlimitierte Kommunikation nach außen zulässt, um die standortübergreifende DevOps-Zusammenarbeit nicht einzuschränken, ist diese Bedrohung nicht unrealistisch. Auch wenn sie „nur“ Rechenleistung kostet: Kommt eine solche Sicherheitslücke ans Tageslicht, drohen dem Unternehmen negative Schlagzeilen und ein Imageschaden.

Die Frage ist daher, was Unternehmen von einem Sicherheitsverantwortlichen im DevOps-Teams erwarten können. Wie hält man die Konsistenz aufrecht, wo es zu großen Veränderungen kommen kann? Und vor allem, was sind die Übergabepunkte, an denen Fachwissen benötigt wird? Wie geschieht dies auf eine Weise, die das Projekt nicht verlangsamt oder Engpässe verursacht, wo es auf kleinteilige Fachexpertise ankommt?

Cybersicherheit nutzt zunehmend die Automatisierung, damit sie in agilen Rechenräumen dynamisch funktionieren kann. Dabei geht es darum, zu erkennen, dass die Unternehmensziele und die Expertise der Teams unterschiedlich sind. Daher ist es wichtig, dass sich alle darüber im Klaren sind, was von ihnen erwartet wird und wo die Übergabe an das zentrale Cybersicherheitsteam erfolgt.

Agilität und Tempo können und sollten keine Ausrede dafür sein, das Gelernte aus jahrelangen Erfahrungen mit der Cybersicherheit nicht anzuwenden. Das bedeutet, dass die gleiche Transparenz und Metriken erforderlich sind wie bei jedem anderen IT-Prozess. Die Realität ist jedoch, dass DevOps typischerweise mehr funktionsübergreifende Beteiligte bedeutet, die zusammenarbeiten, und zwar in einem höheren Tempo. Daraus resultiert, dass auch die Cybersicherheitsteams in diesem Tempo zusammenarbeiten müssen. Angesichts des Fachkräftemangels ist es wichtig zu wissen, welche Fähigkeiten in den Teams vermittelt werden müssen und wann und wo die Cybersicherheitsexperten eingesetzt werden sollen. Es ist wichtig, dass alle ein gemeinsames Ziel verfolgen, das auf Geschäftsergebnissen basiert und nicht auf einzelnen Produktionselementen.

„Die Realität ist, dass jedes Unternehmen seinen eigenen DevOps-Reifegrad hat“, berichtet Martin Zeitler. In Zukunft könnten DevSecOps vielleicht als Schlagwort in den Hintergrund rücken. Heute ist es jedoch eine gute Erinnerung daran, dass die Sicherheit ein Teil der Entwicklungs- und Betriebsprozesse sein muss, die neue Geschäftsmöglichkeiten ermöglichen. In ein paar Jahren wird vielleicht genau das als „agile IT“ oder etwas ganz Anderes bezeichnet.

Die Schlussfolgerungen aus Sicht von Palo Alto Networks

• DevSecOps ist eine junge, sich noch entwickelnde Praxis, die noch nicht Teil der Entwicklungskultur der meisten Unternehmen ist.
• Automatisierung und andere Werkzeuge der nächsten Generation sollten in breitem Umgang eingesetzt werden, um sicherzustellen, dass Sicherheitsvorkehrungen vorhanden und im DevOps-Prozess implementiert sind – und dies nicht nachträglich erfolgt.
• Eine strategische Ausrichtung auf DevSecOps wird dafür sorgen, dass die Sicherheit eine schnelle und regelmäßige Veröffentlichung neuer Software ermöglicht und nicht verlangsamt.