Attivo warnt vor Angriffen auf DevOps

Fremont/Kalifornien, 18. November 2020

Die kontinuierliche Entwicklung im Rahmen von DevOps-Modellen bietet Angreifern die Möglichkeit, schon in der Entwicklungsphase einer Anwendung bösartigen Code einzufügen, der sich dann im gesamten Netzwerk verbreiten wird, warnt Attivo Networks. Die Continuous Integration/Continuous Delivery (CI/CD)-Mechanismen, nach denen DevOps arbeitet, bieten laut Attivo Angreifern neue Möglichkeiten, in das Netzwerk einzudringen. Es sei daher besonders wichtig, über innovative DevSecOps-Ansätze alle Versuche der Manipulation in der Entwicklungsphase schon im Keim zu ersticken.

DevSecOps bedeutet letztlich, Sicherheit in den DevOps-Zyklus zu bringen. DevOps, das die Anwendungsentwicklung mit der Bereitstellung der Infrastruktur verbindet, hat in der heutigen Welt immer mehr an Bedeutung gewonnen. Es bietet eine agilere Funktionalität, die es Entwicklern ermöglicht, ein ständiges Feedback zu ihrem Code zu erhalten, was eine kontinuierliche Verbesserung ermöglicht. Die Integration der Sicherheit in diesen Zyklus hat den gleichen Effekt und gewährleiste ein hohes Sicherheitsniveau bei der Inbetriebnahme der Anwendung. Eine DevSecOps-Mentalität zu schaffen, kann eine Herausforderung sein, da die Entwicklung an sich keine inhärenten Sicherheitsanforderungen stellt. Und sie erst kurz vor dem Einsatz zu injizieren, führt oft zum Opfern der Sicherheit zugunsten einer schnellen Markteinführung.

Bösartiger Code schon in der Entwicklungsphase

Während des gesamten Entwicklungsprozesses ist es laut Attivo insbesondere von Bedeutung, kontinuierlich zu prüfen, ob Angreifer in der Lage waren, bösartigen Code in die Umgebung einzuschleusen. In so einem Fall muss es eine Möglichkeit geben, schnell davon zu erfahren und darauf reagieren zu können. Viele Unternehmen haben jedoch keine Mechanismen, um solche Situationen zuverlässig zu erkennen. Code ist Text, und der beste Weg, Code zu überprüfen, ist immer noch, ihn mit den Augen zu betrachten. Aus diesem Grund gilt Open-Source-Software im Allgemeinen als sicherer, denn hier gibt es mehr prüfende Augäpfel. Wenn ein Benutzer Code "committen" oder finalisieren kann, wird niemand ohne gründliche Überprüfung wissen, ob er zusätzlichen Code eingefügt hat. Diese Bewusstseinslücke ist der Grund dafür, dass es Richtlinien gibt, die bestimmen, wer den Code einsehen oder prüfen kann. Entwicklungsteams werden auch wissen wollen, ob sich ein Angreifer die Autorität erworben hat, Code zu committen. Ungeprüft können diese Angreifer nahezu nach Belieben Malware einfügen.

Diese Möglichkeit stellt laut Attivo ein oft vernachlässigtes Problem dar. Da die beste Möglichkeit, in eine DevOps-Umgebung einzudringen, darin besteht, sich die entsprechenden Berechtigungsnachweise zu beschaffen, können Angriffe auf DevOps klein anfangen - vielleicht sogar als Phishing-Angriffe - um einen ersten Brückenkopf zu errichten. "Wenn Angreifer auf Code-Depots zielen, sind sie möglicherweise nicht nur hinter diesem Code her", warnt Thomas Drews, Solution Engineer DACH bei Attivo. "Möglicherweise wollen sie sicherstellen, dass sie in Zukunft überall dort Fuß fassen können, wo die in der Entwicklung befindliche Anwendung eingesetzt wird. Folglich ist die Fähigkeit, diese Angriffe zu erkennen und umzuleiten, bevor sie Fuß fassen und bösartigen Code einsetzen können, von entscheidender Bedeutung." Hier können Täuschungstechnologien helfen, die den Verteidigern nicht-invasive Werkzeuge an die Hand geben, mit denen sie in jeder DevOps-Phase arbeiten können.

Man kann DevOps in vier primäre Phasen einteilen: Planung, Build, Deployment und Betrieb. Täuschungs- oder Deception-Technologien kommen vor allem in den letzten drei Phasen zum Einsatz, obwohl es auch in der Planungsphase Möglichkeiten gibt, Cyber-Täuschung einzusetzen.

Planungsphase

Die Planungsphase findet in erster Linie offline statt und beinhaltet die Schaffung der Grundlagen für die Entwicklung. Angreifer können hier versuchen, Zugang zu Code zu erhalten, Änderungen vorzunehmen und Malware im Netzwerk zu verbreiten. Dagegen können gefälschte Code Repositories, Dokumente, Netzwerkfreigaben, die auf Dateiserver verweisen, und andere Mittel der Täuschung eingesetzt werden, um Angreifer vom wahren Ziel abzulenken. Häufig werden zur Verwaltung von DevOps-Projekten webbasierte Projektmanagement-Tools verwendet, und Sicherheitsteams können gefälschte Instanzen dieser Tools erstellen.

Build-Phase

In der Build-Phase beginnt die eigentliche Softwareentwicklung. Hier können Angreifer versuchen, Computer, Zielbetriebssysteme, Active Directory (AD) oder andere Bereiche anzugreifen, in denen sie die Entwicklung stören können. Zudem werden sie AD-Aufklärung auf der Suche nach hochwertigen Servern und Code-Repositories betreiben. Gefälschte Repositories, getarnte Netzwerkfreigaben und andere Täuschungsmittel, die schon während der Planphase eingesetzt werden, können auch hier Angreifer zum Entgleisen bringen. Auch gefälschte Jenkins-Server oder Github-Code-Depots sind hier attraktive Ziele für potentielle Angreifer.

Deployment

In der Deployment-Phase werden Angreifer versuchen, sich Zugangsdaten mit der Berechtigung zur Ausführung von Code zu beschaffen. Wenn sie diese erlangen, können sie sich Zugang zum Deployment verschaffen, um Code zu modifizieren und im gesamten System zu verteilen. In dieser Phase sollten Decoy-Technologien gemeinsam mit anderen Sicherheitsmethoden eingesetzt werden, wie z.B Einmal-Passwörtern für den Zugriff auf Konfigurationsdateien. Verteidiger können auch gefälschte Zugangsdaten in Konfigurationsdateien einbetten und neben den echten Zugangsdaten platzieren, um Angreifer auszutricksen.

Betriebsphase

Im regulären Betrieb werden Angreifer primär auf die Endpunkte abzielen, in der Hoffnung, ihre Malware von dort aus im gesamten Netz zu verbreiten. Deception-Technologien können diese Risiken reduzieren. Wenn die Verteidiger entsprechende Netzwerk-Köder eingesetzt haben, werden die Angreifer diese anstelle der eigentlichen Endpunkte anvisieren. Endpunktköder können Angreifer dann zu Decoy-Systemen führen. Da kompromittierte Zugangsdaten ein wesentlicher Bestandteil der Art und Weise sind, wie Angreifer DevOps ins Visier nehmen, kann die Suche nach Fehlkonfigurationen und gestohlenen Berechtigungsnachweisen, die sich auf Entwickler-Endpunkten befinden, die Angriffsfläche weiter reduzieren.