Cloud-Sicherheitsteams, die gestohlenen Modellzugriff untersuchen, sollten klären, wer neue KI-Dienste aktivieren und zusätzliche Identitäten anlegen konnte, und danach nachvollziehen, was diese Identitäten getan haben. Wird nur der zuerst offengelegte Schlüssel rotiert, können andere Zugriffswege und neu aktivierte Dienste ungelöst bleiben.
Das ist die operative Lehre, die Maetra aus dem LLMJacking-Bericht von Mandiant und der Google Threat Intelligence Group vom 2. November zieht. Mandiant beschreibt Vorfälle, in denen Angreifer Modellressourcen von Unternehmen kaperten. Der Bericht nennt betrügerische Ressourcenkosten von mehr als 100.000 US-Dollar an einem einzigen Tag in einzelnen Vorfällen sowie kumulierte Kosten von bis zu 1 Million US-Dollar bei manchen Organisationen. Das sind zugeordnete Beobachtungen aus untersuchten Fällen, kein durchschnittlicher Schaden, keine branchenweite Quote und keine unabhängig testierten Finanzergebnisse.
Prüfen Sie, wer Dienste aktivieren konnte
Dem Bericht zufolge waren offengelegte oder gestohlene Cloud-Identitätstokens über mehrere Untersuchungen hinweg der dominierende Weg für den Erstzugriff. Er beschreibt auch Fälle, in denen LLM-Dienste zu Beginn der Kompromittierung noch nicht aktiviert waren. Angreifer nutzten ihren Zugriff, um Dienste zu aktivieren und Ressourcen zu verbrauchen. Die praktische Folge ist, dass ein Inventar der derzeit genutzten Modelle nicht alle Modelldienste beschreibt, die eine Identität aktivieren könnte.
Beginnen Sie die Untersuchung mit dem betroffenen Cloud-Projekt, Abonnement oder Konto und mit den Berechtigungen der Identität zum relevanten Zeitpunkt. Vergleichen Sie die Dienste, die vor dem vermuteten Eindringen aktiviert waren, mit späteren Änderungen. Ermitteln Sie für jede ungeklärte Aktivierung Akteur, Zeitstempel und Konfiguration.
Diese Prüfung sollte auch gewöhnliche Automatisierungsidentitäten einschließen. Ein Servicekonto für Bereitstellungen muss möglicherweise genehmigte Infrastruktur bereitstellen, hat aber geschäftlich keinen Grund, zusätzlich einen weiteren Modellanbieter zu aktivieren. Prüfen Sie, ob sich diese Befugnisse in der tatsächlichen Umgebung trennen lassen. Gehen Sie nicht davon aus, dass der vertraute Name einer Zugangsdatenquelle ihre Nutzung legitim macht.
Erstellen Sie eine Zugriffskette statt nur einer Schlüsselliste
Maetra empfiehlt, die Beziehung zwischen der ursprünglichen Identität und jedem während des Vorfalls geschaffenen Zugriff zu dokumentieren. Erfassen Sie neue Konten, Zugangsdaten, Zuweisungen, Sitzungen und Dienste zusammen mit ihren Eigentümern und ihrem aktuellen Status. Wenn Aufzeichnungen unvollständig sind, markieren Sie die Beziehung als unsicher, statt Ereignisse nur deshalb miteinander zu verknüpfen, weil ihre Zeitstempel nahe beieinanderliegen.
Eine brauchbare Untersuchungsdokumentation beantwortet vier Fragen:
- Welche Identität erhielt zuerst Zugriff, und welche Belege stützen diese Schlussfolgerung?
- Welche neue Befugnis oder welche Zugangsdaten hat sie geschaffen oder erlangt?
- Welche Ressource erreichte diese Befugnis, und welche Anfragen wurden akzeptiert?
- Welche Belege zeigen, dass dieser Zugriffsweg geschlossen wurde?
Die letzte Frage verändert die Behebung. Der Widerruf einer übergeordneten Zugangsdatenquelle kann andere Auswirkungen auf abgeleitete Sitzungen oder unabhängig angelegte Konten haben. Lassen Sie diese Auswirkungen vom jeweils zuständigen Identitätseigentümer bestätigen. Sichern Sie die für die Untersuchung benötigten Belege, bevor bestätigte schädliche Artefakte entfernt werden, und folgen Sie dabei den Verfahren des Incident-Teams.
Kleine Tests mit Konfigurationsänderungen korrelieren
Große Nutzungsspitzen sind nützliche Signale, aber wer auf eine hohe Rechnung wartet, macht finanzielle Auswirkungen zum Teil der Erkennung. Der Bericht beschreibt sowohl die Validierung gestohlener Schlüssel mit geringem Volumen als auch Missbrauch mit hohem Volumen. Das spricht dafür, Zugriffsmuster zusammen mit Konfigurationsänderungen und Identitätsereignissen zu untersuchen.
Wählen Sie für eine klar eingegrenzte Prüfung einen Modelldienst aus und vergleichen Sie einen Zeitraum normaler Aktivität mit dem vermuteten Expositionsfenster. Achten Sie auf die erste Nutzung durch eine unerwartete Identität, auf eine ungewöhnliche Dienstaktivierung, auf neue Zugangsdaten oder auf eine Änderung am Logging. Untersuchen Sie Kombinationen solcher Signale im Kontext. Eine einzelne unbekannte Anfrage ist kein Beweis für eine Kompromittierung.
Ordnen Sie derselben Zeitleiste einen Verantwortlichen für Cloud-Sicherheit und einen Verantwortlichen für Kosten zu. Sicherheitstelemetrie kann belegen, welche Anfragen erfolgreich waren, während Abrechnungsdaten den zugeordneten Verbrauch in einem anderen Berichtsintervall beschreiben. Machen Sie diese Unterschiede sichtbar, wenn Sie die Auswirkungen schätzen. Stellen Sie eine vorläufige Nutzungsschätzung nicht als abschließende Rechnung oder bestätigten Schaden dar.
Bestätigen Sie die Eindämmung mit dem Ressourcenverantwortlichen
Der Bericht bietet cloud-spezifische Hinweise zu Erkennung und Behebung. Das Reaktionsteam sollte die jeweils relevanten Kontrollen des Anbieters anwenden und ihr Verhalten in der eigenen Umgebung verifizieren. Budgetbenachrichtigungen, Nutzungsquoten, Einschränkungen für Zugangsdaten und Berechtigungen zum Aktivieren von Diensten haben unterschiedliche Zwecke und unterschiedliche Durchsetzungslogiken.
Beispielsweise kann eine Budgetbenachrichtigung einen Verantwortlichen informieren, während Anfragen weiterlaufen. Eine konfigurierte Quote kann eine einzelne Ressource begrenzen, ohne jede Region, jedes Modell oder jede Identität abzudecken. Ermitteln Sie den tatsächlichen Geltungsbereich, bevor Sie eines von beidem als Grenze der Eindämmung behandeln. Das sind Prüffragen, keine Behauptungen darüber, dass sich jeder Anbieter gleich verhält.
Verifizieren Sie nach der Behebung den beabsichtigten Zielzustand: nicht autorisierte Identitäten sind deaktiviert, ungeklärte Zuweisungen sind entfernt, unnötige Dienste sind eingeschränkt und die erforderlichen Logs bleiben verfügbar. Testen Sie auch den freigegebenen Anwendungszugriff, damit die Wiederherstellung den legitimen Arbeitsablauf nicht stillschweigend beschädigt.
Quellenangaben und Produktrolle präzise halten
The Register berichtete unabhängig über den Bericht, einschließlich eines Kommentars aus der Führung von Googles Threat-Intelligence-Bereich. Das stützt die Offenlegung und Zuordnung. Es reproduziert jedoch weder die Vorfalluntersuchungen unabhängig noch verifiziert es die Kosten jedes betroffenen Opfers.
Ein nachweisgestütztes Agenteninventar ist ein sinnvoller Ausgangspunkt, um die beteiligten Anwendungen und Verantwortlichen zu ermitteln. Beziehen Sie auch Identitäten und Dienste außerhalb dieses Inventars in die Untersuchung ein.
Maetra Secure prüft Prompts, Nachrichten, Tool-Aufrufe und Ausgaben auf Laufzeitbedrohungen, einschließlich Datenoffenlegung. Eine solche Prüfung kann Belege für abgedeckte Anwendungsaktivitäten liefern. Cloud-IAM, der Widerruf von Zugangsdaten, Diensteinschränkungen und Finanzkontrollen müssen weiterhin von den jeweils zuständigen Systemen durchgesetzt werden. Dieser Artikel behauptet nicht, dass Maetra die gemeldeten Vorfälle verhindert oder erkannt hat.
Verwenden Sie die Dokumentation von Maetra, um die für eine Vorfallszeitleiste relevanten Anwendungsereignisse zu identifizieren, und verknüpfen Sie diese Aufzeichnungen dann mit den Belegen zu Cloud-Identität und Ressourcen. Die Prüfung ist erst abgeschlossen, wenn die zuständigen Verantwortlichen sowohl den legitimen Arbeitsablauf als auch die verbleibende Unsicherheit erklären können.