Risiko Cloud

Entwickler verlieren die Kontrolle

Je intensiver Unternehmen die Cloud nutzen und Entwickler Cloud-native-Anwendungen schreiben, desto intransparenter werden die Software-Lieferketten. Um Schwachstellen zu reduzieren, ist ein neuer Ansatz erforderlich.
CSO | 13. Oktober 2021 10:40 Uhr
  • Entwicklerteams vernachlässigen häufig die DevOps-Sicherheit
  • Sicherheitsprozesse und -Tools sollten in alle Stadien der CI/CD-Pipeline integriert werden ("Linksverschiebung")
  • Um Sicherheit näher an die Entwicklung heranzuführen, gilt es erst einmal herauszufinden, wo im Unternehmen Software entsteht

In ihrem Unit 42 Cloud Threat Report 2H 2021 stellen die Sicherheitsforscher von Palo Alto Networks fest, dass Unternehmen ihre Cloud-Infrastruktur oft für sicherer halten als sie ist. Es gebe große Bedrohungen in den Softwarelieferketten, die katastrophale Auswirkungen auf das Geschäft haben könnten, heißt es dort.

Im Cloud-Irrgarten können Unternehmen schnell den Überblick verlieren.
Im Cloud-Irrgarten können Unternehmen schnell den Überblick verlieren.
Foto: Gordon J A Dixon - shutterstock.com

63 Prozent der Code-Templates von Drittanbietern, die beim Aufbau von Cloud-Landschaften verwendet werden, enthalten demnach unsichere Konfigurationen. Und sogar 96 Prozent der Containeranwendungen von Drittanbietern, die in der Cloud-Infrastruktur eingesetzt werden, weisen teils bekannte Schwachstellen auf.

Kritische Fehler bei bekanntem SaaS-Unternehmen

Die Palo-Alto-Experten wurden von einem Kunden, der zu den führenden SaaS-Anbietern gehört, beauftragt, seine Softwareentwicklungs-Umgebung mit einer Red-Team-Übung zu überprüfen. Binnen drei Tagen entdeckte allein ein einziger Forscher mehrere kritische Fehler. Sie können das Unternehmen und seine Kunden für Angriffe anfällig machen, wie sie in diesem Jahr etwa auf SolarWinds und Kaseya VSA stattgefunden haben.

Bei einem Angriff auf den IT-Dienstleister Kaseya war dessen Fernwartungssoftware manipuliert worden. Rund 60 Firmenkunden hatten ein Update eingespielt und sich damit einen Erpressungstrojaner der Ransomware-Gang REvil eingefangen. Das führte unter anderem bei der Supermarktkette Coop in Schweden dazu, dass Hunderte Filialen aufgrund defekter Kassensysteme nicht öffnen konnten.

Aufsehen erregte auch der Angriff auf die in Großkonzernen weit verbreitete IT- und Netzwerkmanagement-Plattform Orion von Solarwinds: Über ein manipuliertes Update konnten Angreifer eine Hintertür (Sunburst) in die Systeme und Netze der Nutzer einschleusen. In Hackerkreisen waren die Schwachstellen schon länger bekannt gewesen. Allein in Deutschland zählt das Unternehmen 16 Bundesbehörden und Ministerien zu seinen Kunden.

Der SaaS-Kunde von Palo Alto Networks, dessen Entwicklungsumgebung getestet wurde, verfügte durchaus über ein Cloud-Sicherheitskonzept, das die meisten Unternehmen als ausgereift betrachten würden. Dennoch enthielt die Entwicklungsumgebung mehrere kritische Fehlkonfigurationen und Schwachstellen, die es dem Team von Unit 42 ermöglichte, die Cloud-Infrastruktur innerhalb weniger Tage zu übernehmen.

Zu viel Vertrauen in Drittanbieter

Palo Alto warnt insbesondere vor zu viel Vertrauen in den Code von Drittanbietern. Bei den meisten Angriffen auf die Lieferkette kompromittiere der Angreifer nicht das Opfer, sondern einen von dessen Anbietern und füge bösartigen Code in dessen Software ein. Auch bei Cloud-Infrastrukturen könne ungeprüfter Code von Drittanbietern dazu führen, dass Sicherheitslücken importiert würden und Angreifer sich Zugang zu sensiblen Daten in der Cloud-Umgebung verschaffen könnten. Wenn Unternehmen ihre Quellen nicht überprüften, riskieren sie, sich ungeprüften Code einzuhandeln. Es könnte dann auch ein Advanced Persistent Threat (APT) dahinterstecken, ein Angriff also, bei dem sich Personen über längere Zeiträume unautorisiert und unentdeckt in einem Netzwerk aufhalten.

Die Sicherheitsforscher stellen auch fest, dass Entwicklerteams immer noch häufig die DevOps-Sicherheit vernachlässigen. Das sei auch darauf zurückzuführen, dass sie den Bedrohungen in der Lieferkette zu wenig Aufmerksamkeit schenkten. Cloud-native Anwendungen bergen eine lange Kette von verschachtelten Abhängigkeiten. Palo Alto empfiehlt den DevOps- und Sicherheitsteams, sich einen Überblick über die Stückliste jedes Cloud-Workloads zu verschaffen, um das Risiko auf jeder Stufe der Abhängigkeitskette zu bewerten und dementsprechend Leitplanken für die Sicherheit zu setzen.

Während der Bericht des IT-Sicherheitsunternehmens wichtige Erkenntnisse über Angriffe auf die Softwarelieferkette selbst enthält, liegt der Schwerpunkt doch eher darauf, wie sich Unternehmen vor dieser wachsenden Bedrohung schützen können. So gilt es zunächst, zugelieferter Drittsoftware mehr Aufmerksamkeit zu schenken und noch vor dem Einsatz nach Defekten und Schwachstellen zu suchen.

Palo Alto empfiehlt eine "Linksverschiebung" der Sicherheitsarbeiten, was bedeutet, dass Entwickler Sicherheitsprozesse und Tools in alle Stadien der CI/CD-Pipeline integrieren und so automatisch Sicherheitsleitplanken erstellen. Es gelte, vor dem Deployment die Schwachstellen im eigenen und im eingebundenen Code zu analysieren und zu fixen. Die oft lange Kette der Abhängigkeiten bei Cloud-native Anwendungen müsse durchblickt werden - auch bei Komponenten anderer Anbieter und bei Open-Source-Tools.

Sicherheitsaspekte müssen schon in der Frühphase der Softwareentwicklung berücksichtigt und dann durchgängig verfolgt werden.
Sicherheitsaspekte müssen schon in der Frühphase der Softwareentwicklung berücksichtigt und dann durchgängig verfolgt werden.
Foto: Palo Alto Networks

Palo Alto empfiehlt, dass DevOps- und Sicherheitsteams Einblick in die Stückliste jedes Cloud-Workloads erhalten. Eine solche Transparenz ermögliche es, das Risiko in den verschiedenen Phasen der Abhängigkeitskette zu bewerten und dafür zu sorgen, dass es nur noch begrenzte Auswirkungen hat, wenn einmal eine Phase gefährdet ist. Auf jeden Fall greife es viel zu kurz, am Ende eines Entwicklungslebenszyklus' einmalig den Code zu scannen. Das vermittele Unternehmen ein falsches Gefühl von Sicherheit in der Cloud.

Der Sicherheits-Company zufolge hat das Fehlverhalten der Unternehmen bereits dazu geführt, dass Entwicklungsumgebungen zum bevorzugten Angriffsvektor für APTs geworden sind. Das sei beim SolarWinds-Angriff der Fall gewesen und habe auch auf den beschriebenen Palo-Alto-eigenen SaaS-Testfall zugetroffen.

Um die Sicherheit der Cloud-Software-Lieferkette ganzheitlich anzugehen, hat die Cloud Native Computing Foundation (CNCF) 2021 ein Whitepaper mit Best Practices veröffentlicht. Es konzentriert sich auf die fünf Schlüsselbereiche

  • Sicherung des Quellcodes,

  • Sicherung von Materialien,

  • Sicherung von Build-Pipelines,

  • Sicherung von Artefakten und

  • Sicherung von Implementierungen.

Das Team von Unit 42 empfiehlt eine gründliche Lektüre dieses Dokuments und die Einbindung der Best Practices in die eigene Cloud-Sicherheitsstrategie. Viele Unternehmen seien aber noch gar nicht so weit und kämpften noch mit der Umsetzung der Theorie in die Praxis. Vor allem, wenn noch keine definierte Cloud-Sicherheitsstrategie vorliegt, empfiehlt Palo Alto mit dem Framework Big Cloud 5 zu beginnen, das sich im Kern mit dem Einbetten von Sicherheitsaspekten in den Softwareentwicklungs-Prozess beschäftigt.Teams sollten folgende drei Schritte befolgen:

Genaue Definition der - nach links verschobenen - Sicherheitsstrategie: Unternehmen sollten ein prägnantes Strategiedokument (idealerweise eine Seite) verfassen, aus dem hervorgeht, was die Verlagerung für das eigene Unternehmen bedeutet. Die Teams müssen ein klares Bild vor Augen haben, was ihr gemeinsames Verständnis von Erfolg ist. In diesem Dokument sollten Vision, Verantwortlichkeiten, Meilensteine und Kennzahlen (Key Performance Indicators = KPIs) formuliert sein. Das Strategiedokument muss nicht von Anfang an perfekt sein, wichtiger ist, dass es immer wieder hervorgeholt und optimiert wird.

Verständnis entwickeln, wo und wie Software im eigenen Unternehmen erstellt wird: Vor allem in größeren Konzernen ist es eine der schwierigsten Aufgaben zu erkennen, wo und wie Software entsteht. Das aber ist Voraussetzung dafür, dass Sicherheitsteams verstehen, wo und wie sie die Sicherheit näher an die Entwicklung heranführen können. Große Unternehmen dürften einige Monate damit zubringen, hier den nötigen Durchblick zu gewinnen. Das liegt auch daran, dass Entwicklungsaufgaben oft an Zulieferer ausgelagert wurden. Sie einzubinden, macht zusätzliche Arbeit und erfordert mitunter auch Vertragsüberprüfungen. Für Mittelständler ist dieser Schritt einfacher, aber ebenfalls lohnend.

Den gesamten Softwarefluss im Unternehmen zu erkennen und zu dokumentieren, muss das Ziel sein. Größere Betriebe sollten auf der Konzernebene beginnen und sich dann in die einzelnen Geschäftsbereiche vortasten. Es ist wahrscheinlich, dass jede Geschäftseinheit ihren eigenen Softwareentwicklungsprozess und ihre eigenen Tools hat. Zu den wichtigsten Aspekten, die in dieser Phase ermittelt werden müssen, gehören

  • die Personen, die den Code entwickeln (Mitarbeiter),

  • die Art und Weise, wie der Code von den Entwicklungsrechnern in die Produktion gelangt (Prozess) und

  • die Systeme, die zur Unterstützung des Prozesses eingesetzt werden (Technologie).

Identifizieren und Implementieren von Leitplanken für die Sicherheitsqualität: Qualitätssicherung war schon immer Teil des Softwareentwicklungs-Lebenszyklus. In der Vergangenheit hing Softwarequalität aber nicht von Sicherheitsaspekten ab. Das muss sich ändern, und die in den vorangegangenen Schritten geleistete Arbeit kann dabei unterstützen. Jeder Prozessschritt in der Softwareentwicklung bietet die Gelegenheit, Feedback zu geben und nach Sicherheitsproblemen zu suchen.

Die effektivsten Sicherheitsteams fangen klein an. Sie rüsten ihre Entwicklungsteams mit einfachen und effektiven Tools aus, die Teil der täglichen Entwicklungsroutine werden. Zu den Open-Source-Tools, die gut in diese Kategorie passen, gehören Checkov/Bridgecrew, Yor und AirIAM.