Von der Behebung zur Schadensbegrenzung: Adressierung von Insecure-by-Design-Fehlern

11. Dezember 2024
Kat Traxler
Principal Security Researcher
Von der Behebung zur Schadensbegrenzung: Adressierung von Insecure-by-Design-Fehlern

Vergessen Sie obskure Bug-Klassen - einige der raffiniertesten Schwachstellen verstecken sich im Verborgenen. 

Es handelt sich dabei um Sicherheitslücken, die in der Funktionalität eines Systems begründet sind. Oft handelt es sich dabei um wohlbekannte "Macken" des Systems, deren volle Auswirkungen jedoch nicht ausreichend erforscht sind. Während herkömmliche Schwachstellen nur durch die Behebung von Codezeilen behoben werden können, erfordern diese konstruktionsbedingten Probleme häufig ein komplettes Überdenken eines Systems und eine vollständige Überarbeitung seiner Funktionalität.

Wenn die Funktionalität des Dienstes cloud von den Industrienormen oder den Kundenerwartungen abweicht, kann der beschriebene "Fehler" zwar in der Konzeption begründet sein, aber dennoch tiefgreifende Auswirkungen auf die Sicherheit haben.

Dieser Beitrag befasst sich mit diesen schwerwiegenden, oft strukturellen cloud Schwachstellen und zeigt auf, warum die Behebung von by-design Sicherheitslücken mehr als nur einen einfachen Patch erfordert.

Feature-Missbrauch vs. Insecure-by-Design Schwachstellen in Cloud Sicherheit

Nehmen wir uns einen Moment Zeit, um die Grenzen von "Insecure-by-Design"-Schwachstellen zu definieren, indem wir sie dem "Feature Abuse" gegenüberstellen, d. h. dem absichtlichen Missbrauch eines Features, einem weiteren häufigen Sicherheitsproblem auf cloud.

Missbrauch von Funktionen - ein anerkanntes Risiko in Cloud Umgebungen

Der Begriff "Feature-Missbrauch" beschreibt, dass ein Akteur eine Funktion von cloud nutzt, um ein bösartiges Ziel zu erreichen. Es handelt sich dabei nicht um eine Schwachstelle oder einen Fehler, sondern um die böswillige Absicht, die hinter der Nutzung einer legitimen cloud Funktion steht. 

Lassen Sie uns die Standardfunktionalität in IAM-Systemen hervorheben, die es ermöglicht, Anmeldedaten für einen anderen Benutzer als den eigenen zu generieren. Diese Fähigkeit definiert laterale Bewegung (und wahrscheinlich Privilegieneskalation) mit dem anerkannten Risiko des absichtlichen Missbrauchs. Es gibt jedoch keine Schwachstelle in einem IAM-System, die es einem Benutzer ermöglicht, Anmeldeinformationen für einen anderen zu erstellen. Stattdessen arbeitet die Branche daran, diesen Funktionsmissbrauch mit den verfügbaren abschwächenden Kontrollen zu verhindern und zu erkennen.

Insecure-by-Design - Eine Cloud Schwachstellenklasse

Die Erwartungen und Normen der Branche erstrecken sich auch auf die Sicherheitskontrollen für die von cloud bereitgestellten Funktionen. Zu den von vornherein unsicheren Schwachstellen können unzureichende Kontrollmöglichkeiten durch den cloud Anbieter gehören. 

In dem oben beschriebenen Szenario zur Erstellung von Berechtigungsnachweisen würden die Kunden des Dienstes eine Überprüfung der Berechtigung erwarten, bevor sie Berechtigungsnachweise ausstellen und solche Ereignisse protokollieren. Das Fehlen dieser Kontrollen würde die Kunden einem erheblichen Risiko aussetzen, was auf einen Konstruktionsfehler des Dienstes hinweist. 

Ein konkreteres Beispiel für eine nicht sicher konzipierte Schwachstelle trat kürzlich im DocumentAI-Dienst von Google auf. Ein Nutzer von Document AI konnte Cloud Speicherobjekte mit den Rechten des DocumentAI-Service-Agenten außerhalb des Projekts verschieben, ohne dass das IAM-System überprüfte, ob der Endnutzer Zugriff auf die Objekte hatte.

Das Fehlen der erwarteten Berechtigungsprüfungen stellte eine erhebliche Abweichung von den Grundsätzen der sicheren Gestaltung dar. 

Designbedingte Sicherheitslücken und die gemeinsame Verantwortung

Wie wir sehen können, sind einige der heimtückischsten Sicherheitsrisiken direkt in den Entwurf eines Systems eingebaut. Diese "Insecure-by-design"-Fehler werden offensichtlich, wenn die Funktionalität eines Dienstes oder die verfügbaren Kontrollen von etablierten Normen und Kundenerwartungen abweichen. 

Fehler, die bei der Entwicklung entstanden sind, können auf cloud besonders frustrierend sein, da es in der Verantwortung der Kunden liegt, den Missbrauch von Diensten zu verhindern. Aufgrund der Aufgabenteilung im Modell der geteilten Verantwortung ist der Dienstanbieter jedoch dafür verantwortlich, die notwendigen Kontrollen zur Verfügung zu stellen, eine genaue Dokumentation zu liefern und für die sichere Implementierung eines Dienstes zu sorgen.

Abschwächung der Auswirkungen von "Insecure-by-Design"-Schwachstellen in Cloud Diensten

Bei der Behebung von Sicherheitslücken wird oft ein einfacher Ansatz verfolgt: den fehlerhaften Code identifizieren, einen Patch erstellen und das Update verteilen. Diese "Fix-it-and-forget-it"-Mentalität greift jedoch zu kurz, wenn es um unsicher konzipierte Schwachstellen in cloud -Diensten geht. Und warum? Weil sich diese Schwachstellen durch zwei Merkmale von klassischen Schwachstellen in einem Softwarepaket unterscheiden. 

  1. Diese Schwachstellen sind oft tief mit der Funktionalität des Dienstes verwoben oder untermauern sogar seine grundlegenden Prinzipien, so dass eine einfache "Behebung" nicht möglich ist. Die Deaktivierung oder wesentliche Änderung der Funktion könnte zahlreiche Arbeitsabläufe stören.
  2. Bei stets verfügbaren APIs betrifft eine Funktionalität mit Missbrauchspotenzial nicht nur diejenigen, die den Dienst nutzen, sondern alle Kunden, unabhängig davon, ob sie die API verwenden oder nicht.

Eine Nullsummen-Mentalität, die sich ausschließlich auf die "Reparatur" des Dienstes konzentriert, schränkt die Möglichkeiten einer wirksamen Risikominderung ein. Stattdessen benötigen diejenigen, die sich auf cloud Sicherheit konzentrieren, eine ganzheitlichere Strategie. Dazu gehört die Implementierung von präventiven und detektiven Kontrollen zur Risikominderung bei gleichzeitiger Erkundung potenzieller langfristiger Lösungen für den zugrunde liegenden Konstruktionsfehler. Ein wirksames Instrument dieser Strategie ist die Verwendung von Leitplanken.

Abschwächende Kontrollen: Leitplanken

In cloud Sicherheit sind Leitplanken präventive Kontrollen, die Sicherheitsrichtlinien und -standards in der gesamten cloud Umgebung eines Unternehmens durchsetzen. Sie wirken wie Stoßstangen entlang einer Bowlingbahn und geben dem Sicherheitsbeauftragten die Gewissheit, dass die Nutzung nicht zu weit von einem vorgegebenen Muster abweicht. 

Die Bereitstellung von vorgefertigten Leitplanken kann dazu beitragen, die Schwachstellen von cloud zu entschärfen. Sie sind besonders hilfreich, wenn es darum geht, unerwünschtes Verhalten auszuschalten oder ganz zu entfernen. Die Wirksamkeit von Leitplanken nimmt jedoch ab, wenn unsichere Funktionen tief in kritische Prozesse eingebettet sind. In diesen Fällen ist es unter Umständen nicht möglich, den Zugriff auf die Funktion zu blockieren. 

Abschwächende Kontrollen: Erkennung und Reaktion

Präventive Kontrollen wie Leitplanken sind zwar wertvoll, reichen aber nicht immer aus. Die Implementierung kann komplex sein, und Ausnahmen sind oft notwendig, um legitime Anwendungsfälle zu berücksichtigen. Außerdem sind mehr als Leitplanken und präventive Kontrollen erforderlich, um Kunden zu helfen, die bereits auf unsichere Funktionen angewiesen sind. 

Aus diesem Grund sind die Erkennung und der Aufbau einer schnellen Reaktion oft die wertvollsten Abhilfemaßnahmen, wenn eine unsichere Funktionalität erkannt wird.

Wenn Sie sich mit der Erkennung und Reaktion auf cloud Schwachstellen beschäftigen, sollten Sie sich folgende Fragen stellen:

  • Erhalten die Kunden ein zuverlässiges Signal für das verletzende Verhalten, oder sind zusätzliche Protokolle erforderlich?
  • Sind die Protokolle standardmäßig aktiviert, oder muss der Kunde benachrichtigt werden, um eine zusätzliche Protokollierung zu ermöglichen?
  • Können Sie schnell auf das Erkennungsergebnis reagieren, um Schäden zu verringern oder zu beseitigen?

Beendigung unsicherer Cloud Funktionalitäten: Der lange Abschied

Die Einführung von unsicheren Funktionen mit Missbrauchspotenzial kann sich für Dienstanbieter als kostspielig erweisen. Sobald diese Funktionen in die Arbeitsabläufe der Kunden integriert sind, kann es schwierig sein, sie zu entfernen oder zu ändern, da sie von nachgelagerten Abhängigkeiten und Annahmen in Bezug auf die Produkt- und Kunden-Workloads abhängen. 

Zwar ist es oft möglich, diese Schwachstellen zu beseitigen oder zu beheben, vor allem mit einem schrittweisen Ansatz und der Einführung sicherer Alternativen, aber der Prozess ist selten schnell. Aus diesem Grund sind Leitplanken und detektivische Kontrollen so wichtig. Sie fungieren als dringend benötigte Bandagen und verschaffen Unternehmen und ihren Kunden wertvolle Zeit für die Abkehr von unsicheren Funktionen, ohne die Geschäftsprozesse zu unterbrechen. 

Missbrauch aufdecken und Schutzmechanismen einführen: 

  • Verschaffen Sie Ihren Entwicklungsteams die Zeit, die sie benötigen, um unsichere Funktionen in geordneter Weise zu beseitigen, indem Sie die beiden Hebel der detektiven und präventiven Kontrollen nutzen. 

Sonnenuntergang-Funktionalität:

  • Migration bestehender Arbeitslasten, die von unsicheren Funktionen abhängen, auf sicherere Muster. Beenden Sie die Nutzung anfälliger Funktionen und stellen Sie schließlich die entsprechenden APIs ein.

Shared-Fate-Ansatz zur Behebung von Schwachstellen Cloud

Letzten Endes erfordert die Behebung von "Insecure-by-Design"-Schwachstellen ein gemeinsames Vorgehen. Cloud Anbieter und ihre Kunden müssen zusammenarbeiten und sich der Verflechtung ihrer Verantwortlichkeiten bewusst sein. 

Die Anbieter müssen transparent machen, wenn die Sicherheitskontrollen hinter den Erwartungen zurückbleiben und Schwachstellen verursachen, die von vornherein unsicher sind. Die Kunden wiederum müssen die verfügbaren Tools nutzen, um den Missbrauch von Funktionen zu verhindern und zu erkennen und ihre Umgebungen von unsicheren, veralteten Mustern zu befreien. 

Dieser kooperative Ansatz wird dazu beitragen, dass sich cloud zu einem widerstandsfähigeren und sichereren System weiterentwickelt.

Häufig gestellte Fragen