Veracode über sicherheitsgestützten Kulturwandel 6 Schritte hin zur DevSecOps-Strategie

DevSecOps steht sinnbildlich dafür, dass bei der Verzahnung von Entwicklung und Betrieb die Sicherheit nicht auf der Strecke bleiben darf. Doch auch die Integration von Sicherheitsprozessen erfordert einen Kulturwandel, die wichtigsten Punkte hat Veracode zusammengefasst.

Anbieter zum Thema

PresseBox - unn | UNITED NEWS NETWORK GmbH

FIS Informationssysteme und Consulting GmbH

Confluent Germany GmbH

Veracode Limited

Im Auftrag von Veracode hat das Analyseunternehmen Securosis für jede Phase des Software-Lebenszyklus wichtige Security-Tools und -Techniken identifiziert. Doch analog zu DevOps ist DevSecOps eben keine Lösung, die man kauft und implementiert. Mit der technischen Integration muss grundsätzlich ein organisatorischer und kultureller Wandel einhergehen.

Als Solution Architect bei Veracode hat Julian Totzek-Hallhuber die wichtigsten Punkte zusammengefasst:

Schritt 1: Die Definitionsphase

Zunächst gilt es, die eigene Sicherheitsarchitektur gründlich zu analysieren, um zu verstehen, wie Anwendungen arbeiten und kommunizieren. Dazu gehören auch Richtlinien von Cloud Providern. Nachdem Unternehmen sich den vollen Überblick verschafft haben, können sie damit beginnen, verbindliche Operationsstandards zu definieren. Dazu sollten Dinge gehören wie Mindestanforderungen für Sicherheitstests und feste Zeitrahmen für die Fehlerbehebung. Außerdem muss hier die Entscheidung fallen, welche Sicherheitstest durchgeführt werden sollen und welche Metriken man heranziehen möchte, um den Erfolg zu messen.

Schritt 2: Die Design-Phase

In diesem Schritt geht es vor allem darum, sicherzustellen, dass die Entwicklungs- und Testumgebungen sicher sind. Dazu braucht es strikte Zugangskontrollen für CI/CD-Pipelines und zusätzliches Monitoring für Skripte im Hintergrund. Außerdem sollten Entwickler zu häufigen Bedrohungstypen geschult werden.

Schritt 3: Die Entwicklungsphase

Wenn die Voraussetzungen geschaffen sind, kann man nun einen zentralen Punkt angehen: die Automatisierung des Testings. Dazu benötigen Entwickler sichere Repositories. Unternehmen sollten den Zugriff auf sichere und intern freigegebene Open-Source-Bibliotheken ermöglichen. Mit einer Kombination aus Analyse-Tools und Skripten können Verantwortliche dabei sicherstellen, dass Entwickler nur mit den freigegebenen Versionen arbeiten. Außerdem sollten Unternehmen Interactive Application Security Testing (IAST) etablieren. Mit dieser Methode können Schwachstellen in der Laufzeit identifiziert werden, bevor ein Code in Produktion geht.

Schritt 4: Die Testphase

Im Sinne des „Shift Left“-Ansatzes sollte man möglichst früh im Software-Lebenszyklus mit Tests beginnen. Es versteht sich von selbst, dass Unternehmen Fehler in ihrer Software finden wollen, bevor dies Kriminelle tun. Außerdem sollten auch die Testumgebungen kontinuierlich geprüft werden, um ihre Effizienz sicherzustellen. Mit verschiedenen, parallel durchgeführten Tests lassen sich die Methoden identifizieren, die das System verlangsamen und durch effektivere ersetzen.

Schritt 5: Die Pre-Release-Phase

Jetzt geht es darum, Sicherheit und Geschwindigkeit zu vereinen. Dazu sollten Unternehmen auch flexible On-Demand-Services aus der Cloud einsetzen. Produktionsumgebungen sollten außerdem gegen Datenlecks abgesichert werden, indem Tools wie Data Masking oder Tokenisierung zum Einsatz kommen, die dafür sorgen, dass Entwickler zwar alle Testdaten zur Verfügung haben, allerdings ohne Zugriff auf sensible Informationen.

Schritt 6: Die Deployment-Phase

Nun sollte man einzelne Testballons steigen lassen, um zu sehen, ob der Code, der vor dem Deployment funktionierte, auch im Deployment läuft. Muss das Deployment dann erweitert werden, können sich Unternehmen dieser drei Methoden bedienen:

• Beim Blue-Green oder Red-Black Deployment laufen alter und neuer Code parallel auf eigenen Servern. Treten Fehler auf, greifen die Load Balancer auf den alten Code zurück.

• Das Canary Testing ist eine weitere Methode. Dabei werden einzelne Sessions auf neuen Code umgestellt. Werden dabei Fehler entdeckt, wird der entsprechende Code zurückgezogen und die Probleme werden behoben.

• Als dritte Methode können durch Feature-Tagging neue Code-Elemente aktiviert und deaktiviert werden. Wenn Ereignisfehler in einem neuen Codeabschnitt gefunden werden, können Entwickler die Funktion deaktivieren, bis das Problem behoben ist.

Im eingangs genannten – registrierungspflichtigen und englischsprachigen – Report finden Interessierte weitere Informationen zum Aufbau eines DevSecOps-Programms.

(ID:46374787)