Suchen

Security und DevOps: DevSecOps in 4 Schritten umsetzen

Autor / Redakteur: Ivan Novikov * / Stephan Augsten

Die Agilität von DevOps und Microservices-Umgebungen macht die Integration der Sicherheit nicht gerade einfacher. DevSecOps lässt sich aber durchaus realisieren, wenn man vom traditionellen Sicherheitsdenken abrückt.

Firmen zum Thema

Da Entwicklung und Betrieb gemeinsam für Continuous-Integration und -Deployment verantwortlich sind, müssen sie auch Sicherheit als Prozess gemeinsam umsetzen.
Da Entwicklung und Betrieb gemeinsam für Continuous-Integration und -Deployment verantwortlich sind, müssen sie auch Sicherheit als Prozess gemeinsam umsetzen.
(Bild gemeinfrei: Oliver Rowley - Unsplash.com / Unsplash)

Ende Mai findet in Barcelona die größte KubeCon-Konferenz bis dato statt. Dabei liegt ein thematischer Schwerpunkt auf DevOps-Prozessen und verteilten, Microservice-basierten Anwendungen. Eben diese Umgebungen einschließlich ihrer Cloud-basierten Zielsysteme und flexiblen Infrastrukturen machen die Sicherheit aber viel komplizierter.

Will man DevSecOps in diesen neuen Microservices-Landschaften umsetzen, geht es um nicht weniger als die Integration von Sicherheitsphilosophien und -prozessen in DevOps-Praktiken. Führt man sich vor Augen, dass APIs und Container sowie Kubernetes bei der Anwendungsbereitstellung über hochperformante CI/CD-Pipelines eine immer größere Rolle spielen, wird schnell klar, dass die Sicherheit mehr von dieser DevOps-Integration abhängt als von den jeweiligen Toolsets.

DevSecOps ist also mehr als ein Modewort von Unternehmen für Unternehmen. Als Kombinationsbegriff spiegelt DevSecOps die gegenseitige Abhängigkeit der Verantwortlichkeiten wieder, um Sicherheit von einem festen Satz unflexibler Tools hin zu einem umfassenden Prozess als solchen zu transformieren.

Was sind also die Herausforderungen, die verhindern, dass ein Unternehmen eine DevSecOps-Philosophie nachhaltig verfolgen kann? Und wie können Unternehmen diesen Herausforderungen begegnen?

Sicherheit kann ein ganz natürlicher Teil von DevOps sein

Sicherheitstests lassen sich leicht in die Testphase jeder Integration oder Bereitstellung integrieren. Der Return on Invest mag nicht immer so offensichtlich sein, wie er nach einer Sicherheitsverletzung oder einem Programmcode-Problem ist, doch der Blick zurück ist auch nicht gerade viel wert. Weil eine Integration an jedem Punkt möglich ist, warum optimieren wir dann nicht auf dieses Ziel hin?

Sicherheit neu denken und die Codequalität verbessern

Wie wir in puncto Sicherheit denken, ist ein enormes Hindernis für DevSecOps. Für die meisten ist die unmittelbare Wertschöpfung nicht leicht zu erkennen. Stattdessen wird Sicherheit oft damit gleichgesetzt, Zeit und Ressourcen für ein „Was wäre wenn“-Untergangsszenario zu opfern, wenn nicht gar zu verschwenden.

Sicherheit bietet aber einen beträchtlichen positiven Wert, wenn wir unser Verständnis auf das Testen ausweiten. Das muss nicht bis zur Bereitstellung warten oder auf Anwendungsprüfungen beschränkt sein. Die umfassendsten Sicherheitsprüfungen lassen sich an und in der gesamten Umgebung vornehmen.

Durch das Testen während des gesamten CI/CD-Lebenszyklus sind Teams Sicherheitsproblemen einen Schritt voraus und helfen, die Qualität des Programmcodes zu verbessern. Kontinuierliche Tests können sich wiederholende und systemische Probleme ermitteln.

Beispielsweise könnte fehlerhafter Code, der zu spät identifiziert wird, zu Lieferproblemen führen. Durch das Erkennen wiederkehrender Probleme außerhalb von Bibliotheken lassen sich Zyklen schaffen, die einen besseren Überblick über neuen Input geben, was letztendlich die Codequalität verbessert. Firmenspezifische Probleme lassen sich identifizieren und beheben, bevor sie überhaupt auftreten.

Die wirkliche Transformation von DevOps zu DevSecOps liegt also im Umstieg von Sicherheit „von der Stange“ auf die Sichereheitsprozess-gestütze Kompetenzbildung bei den Entwicklern. Auf technischer Ebene hat der Entwickler zunächst einmal keinen Grund, Anwendungen zu testen, bevor neuer Code eingepflegt wird. Dies erfolgt nur, wenn die Geschäftsprozesse Entwickler dabei unterstützen, Sicherheit als Primär-KPI zu etablieren.

Sicherheit für ihren Teil kann mit Richtlinien dafür sorgen, dass Entwickler Tests für ihre Anwendungen generieren und Probleme vor dem Release korrigieren. Operations sollte die Entwicklung dabei unterstützen, Anwendungen in jeder Entwicklungsphase zu testen, entsprechende Workflows und Prozesse festzulegen und Anwendungen erst nach Abschluss der Testphase freizugeben.

Entwickler und Sicherheitsabteilung arbeiten zusammen

Anhand der Kurzlebigkeit und hohen Geschwindigkeit des Lebenszyklus der kontinuierlichen Integration und Bereitstellung (CI/CD), haben sich Entwicklungs- und Betriebsteams in vielen Unternehmen zu einem kombinierten Team, DevOps, weiterentwickelt. Gemeinsam verwalten und unterstützen sie die CI/CD-Systeme in einer intuitiven, starken Symbiose.

Wenn nur durch wenige Minuten getrennt mehrere Bereitstellungen erfolgen, ist es oft schwierig, für Funktionstests Platz zu schaffen. Wenn Sicherheit ein Teil der DevOps sein soll, muss es sich um Sicherheit als Prozess (Security as a Process) handeln, die von der Operations-Abteilung unterstützt und von Entwicklern als Teil ihres gemeinsamen CI/CD-Workflows umgesetzt wird.

Vier Schritte zur Entwicklung von DevSecOps

Leider ist die Zeit meist zu knapp, um alles umzusetzen, was der Sicherheit zuträglich ist. Deshalb ist es so wichtig, zu automatisieren und zu verstehen, wie man gemäß der jeweils eigenen Geschäftslogik priorisiert werden sollte.

Es ist unmöglich, alle bekannten Tests und Varianzen umzusetzen und dann die Ergebnisse hunderttausender von Anforderungen zu generieren und zu analysieren. Um den CI/CD-Timelines zu entsprechen, muss das Testing in wenigen Stunden oder höchstens bei der nächtlichen Build-Erstellung erfolgen – einschließlich der Durchführung von Funktions-, Sicherheits- und aller anderen Tests.

Die richtige Planung sowie zugehörige Prozesse, Tools und die offensichtliche Umsetzung von Security-as-a-Process helfen, Sicherheit in DevSecOps zu realisieren. Auf der folgenden Seite finden Sie einen grundlegenden Überblick über Ihre Möglichkeiten.

1. Priorisierung von Sicherheitsbereichen und -zielen

Wie die Prozesse organisationsübergreifend variieren können, so variieren auch die Sicherheitsprioritäten. Der erste Schritt bei der Schaffung einer funktionsfähigen DevSecOps-Organisation besteht darin, die Testarten zu ermitteln, die angewandt werden sollten, und wie diese anzuwenden sind. In den Planungs- und Aktionsplan-Phasen wird die jeweilige Bedrohungslandschaft identifiziert, gleichzeitig werden Leitung und Ziele des Unternehmens und der Sicherheit zusammengeführt.

Planung anhand Ihrer Sicherheits-KPIs und Ziele

Schenken Sie Sicherheitsversprechen nach dem „One Size Fits All“-Universalprinzip nie Vertrauen. Schaffen Sie ein Sicherheits-Rahmenwerk, das speziell auf Ihre Organisation und Ihre Sicherheitsanforderungen zugeschnitten ist. Es sollte um realistische KPIs herum angelegt sein. Wie Ihre Sicherheitslandschaft aussieht, hängt von der allgemeinen Geschäftsumgebung einschließlich Organisationshierarchie, Produktlebenszyklen, Geschäftszielen sowie von den in der Organisation als Ganzes und in den Abteilungen im Einzelnen implementierten Prozessen ab.

Fachleute mit Erfahrung in Sicherheits-Audits wissen, dass Sicherheitslösungen und -planung für jedes Unternehmen individualisiert werden müssen und es unmöglich ist, alle Unwägbarkeiten abzudecken. Angenommen, Sie identifizieren jede Anomalie. In der Big-Data-Ära wären unglaublich viele Ressourcen nötig, um die Anomalien zu sortieren. Automatisierung hilft, kann aber nicht nach dem Zufallsprinzip und global angewendet werden.

Führen Sie zunächst ein Audit Ihrer Organisation sowie eine Risikobeurteilung durch und untersuchen Sie die organisatorischen und prozessualen Infrastrukturen. Bitten Sie Personen aus der gleichen Branche und des gleichen Unternehmens- und Geschäftstyps sowie ähnlicher Reife, ihre eigenen Praktiken und Erfahrungen mitzuteilen.

Erstellen eines Aktionsplans

In der Ära von Big Data und performanter Continuous-Integration und -Delivery kann niemand jedes Problem beheben, wie bereits erklärt wurde. Eine effektive Integration von Sicherheit in DevOps ohne KPIs und Ziele ist nicht möglich. Zielgerichtete Sicherheitsaktionen sind von kritischer Bedeutung.

Aktionspläne müssen auf dem Verständnis basieren, was implementiert ist und welche Best Practices für Ihr jeweiliges Unternehmen bestehen. Die Sicherheitsprobleme eines etablierten Unternehmens oder Ladens mit 25 Jahren Betriebserfahrung, dessen Hauptgeschäft offline erfolgt oder das sich auf Vor-Ort-Servern und Datenbanken verlässt, sind ganz andere, als die eines E-Commerce- oder modernen Enterprise-Unternehmens. Dessen Geschäft ist ganz auf das Internet und Mobil-Traffic ausgerichtet und es hat wahrscheinlich mehrere Website und komplexere IT-Architekturen.

Wenn Sie Best Practices gewählt haben, kann die Sicherheitsabteilung einen Sicherheitsintegrationsplan oder andere Aktionspläne entwickeln, die speziell auf die Anfälligkeiten und Anforderungen Ihres Untenrehmens abzielen.

2. Die richtigen Prozesse

Integrieren Sie Sicherheitstests in ein Testing Framework.

Wenn Sie damit beginnen, Sicherheit gemäß Ihrer Bedrohungslandschaft zu integrieren, muss dies zielgerichtet entsprechend realer und priorisierter Bedrohungen, basierend auf Ihrem Rahmenwerk erfolgen. Wallarm-Produkte z. B. sind speziell für die Sicherheit auf Anwendungsebene angelegt und bieten Layer-7-Bereitstellung. Wir hätten eine ganze Reihe von Sicherheitsprodukten und -Frameworks entwickeln können, erkannten aber ein Problem, das durch die sich verändernden Technologie- und Geschäftsumgebungen entsteht.

Projektmanager und Entwickler agieren unter dem Druck kurzer Software-Lebenszyklen und kontinuierlicher Bereitstellungen besonders agil. Um die durch diese Veränderungen entstandenen Probleme angemessen zu beheben, muss Sicherheit für den jeweiligen Standort nativ sein und darf nicht durch einen ausländischen Agenten bereitgestellt werden, der sich weit entfernt befindet und eine andere Sprache spricht. Sie muss diese Herausforderungen auf Anwendungsebene berücksichtigen und damit arbeiten.

Entwicklern und Sicherheit aneinander ausrichten

Funktionsübergreifende Unterstützung und die Akzeptanz einer Sicherheitsphilosophie erfordern offene Kommunikationswege. Die Führungskräfte der verschiedenen Abteilungen müssen Platz für diese Beziehungen schaffen und sie positiv fördern. Erstellen Sie gemeinsam verwendete Dashboards, richten Sie Workflows aus, integrieren Sie Transparenz und planen Sie Meetings, an denen alle Beteiligten gleichrangig teilnehmen. Fördern Sie die teamübergreifende Kommunikation und beseitigen Sie Organisations-Silos. Schließen Sie die Geschäftsabteilungen mit ein, sodass DevSecOps mit den funktionellen Zielen des Produkts und den vom Kundenstamm generierten Anforderungen ausgerichtet sind.

Security- und die Development-Abteilung müssen beide ein gemeinsames Verständnis für die Produktanforderungen, die relevanten Geschäfts- und Benutzeranforderungen sowie Teambeziehungen entwickeln. Dann müssen beide sich wirklich darüber informieren, woran die jeweils andere Abteilung gemessen wird. Programmierer müssen z. B. wissen, welche gespeicherten Prozeduren andere nicht auslösen können, welchen Code sie nicht generieren können und welche anderen Parameter hinsichtlich der Sicherheitsanforderungen gelten.

3. Die richtigen Tools

Neue Technologie, die hervorragend mit anderen Technologien zusammenarbeitet.

Machen Sie mehr aus benutzerfreundlichen Tools, die bestehende Sicherheitsfunktionen verstärken. Sie müssen auch gar nicht auf Legacy-Tools und Prozeduren verzichten. Sie müssen vielmehr sicherstellen, dass Altbewährtes bestimmte Bereiche nicht ungeschützt lässt.

Planen Sie voraus, um die Adaption zu erleichtern

Suchen Sie Tools, die gut mit bestehenden Sicherheitstools und -protokollen zusammenwirken, um die Ihrem bestehenden Sicherheitsteam zur Verfügung stehende Zeit und seine Ressourcen auszuweiten. Suchen Sie ein schnell einsetzbares Out-of-the-Box-Dienstprogramm, das bei minimaler CI/CD-Störung ebenso schnell angenommen wird. Die Automatisierung der iterativen Aspekte der Bedrohungsdetektion und -behebung helfen sowohl Sicherheits- wie auch Qualitätssicherungsteams.

Skalierbare Tools und Automatisierung

Erwägen Sie Technologien, die besser für die neue Entwicklungsumgebung geeignet sind. Wahrscheinlich werden auch die stärksten Sicherheitstool mitwachsen und sich an ständig verändernde Bedrohungsumgebungen und multivariate Entwicklungsprotokolle und -nuancen anpassen müssen. KI-basierte Sicherheitstools, maschinelles Lernen, fortgeschrittene neuronale Netzwerke und spezialisierte Sicherheit können Sicherheitsteams dabei unterstützen, mit weniger Arbeit mehr abzudecken.

4. Akzeptanz von DevSecOps

Die Endphase besteht in der Adaption. Die Ziele, Prozesse und Tools aktiv einzusetzen, ist der letzte und wichtigste Teil bei der Entstehung einer robusten DevSecOps-Philosophie. Das bedeutet, Sicherheit kontinuierlich in Schulungen, Führung und Denkweise zu integrieren.

Alle mit an Bord nehmen

Beginnen Sie mit teamübergreifenden Gesprächen, um die Führungskräfte der Abteilungen Entwicklung, Operations (Betriebliche Prozesse) und Sicherheit miteinander auszurichten (wir empfehlen, Führungskräfte auch aus anderen Geschäftsbereichen wie z. B. Produkte mit einzuschließen). Dies ist essentiell, um die Sicherheit wirklich eng zu integrieren.

Wirklich alle mitnehmen

Schulungen für alle Teams sind sehr wichtig, um wirklich für Sicherheit zu sorgen. Legen Sie Richtlinien fest und schulen Sie Mitarbeiter, stellen Sie sicher, dass regelmäßige Sicherheits-Audits stattfinden, implementieren Sie Best Practices und Compliance-Maßnahmen, die Teamführungskräfte durchsetzen müssen. Alle, die dezentral arbeiten, auch wenn sie nur im Urlaub E-Mail auf ihrem Smartphone beantworten, können ein Sicherheitsproblem darstellen.

Eine umfassende Adaption bedeutet auch, sich auf Simplizität zu konzentrieren, um die nötigen Tools zur Stärkung der Teams und des funktionsübergreifenden Wissens zu finden. Schaffen Sie eine unterstützende Umgebung, in der alle für Sicherheitsbelange sensibilisiert sind. Erstellen Sie Sicherheitsprotokolle und führen Sie Audits der Sicherheitsrichtlinien durch, damit Benutzer die Gesamtsicherheit verbessern können. Falls Sie die nötigen Ressourcen haben, laden Sie Vertreter der Marketing-, Personal- oder Kommunikationsabteilungen zu Sicherheitsinitiativen ein und planen Sie, diese stärker in den Mittelpunkt zu rücken.

Dieser Beitrag stammt von unserem Partnerportal Dev-Insider.de.

* Ivan Novikov ist CEO und Vorsitzender von Wallarm, einem Anbieter von KI-gestützter Anwendungssicherheit.

(ID:45939183)