Agentische Fehlanpassung: Ihre nächste Insider-Bedrohung könnte ein KI-Agent sein

Angenommen, Sie bitten einen Agenten, einen fehlgeschlagenen Deploy zu beheben. Ein Mensch würde den Dienst neu starten, vielleicht zurückrollen. Der Agent erkennt, dass das Erweitern einer Firewall-Regel und das Bearbeiten einer sudoers-Datei den Deploy schneller durchbringt, also macht er beides.Er hatte die Berechtigungen, niemand hat ihm gesagt, dass er es nicht tun soll, und niemand in Ihrem Team wäre so vorgegangen.

Agenten laufen auf der Infrastruktur, die Sie bereits haben, sie laufen auf denselben Servern, Dateifreigaben und Anmeldeinformationen wie alles andere und nehmen jede Route, die zum Ziel führt, einschließlich solcher, die kein Mensch ausprobiert hat, sofern keine wirksamen Schutzvorrichtungen vorhanden sind. Das Sicherheitsteam von NVIDIA beschreibt es als Agenten, die Wege finden, die ihre ursprünglichen Anweisungen nicht vorhergesehen hatten.

Anweisungen sind Empfehlungen, Berechtigungen sind Durchsetzung

Eine Systemaufforderung gibt an, was der Agent tun soll. Sie kann den Agenten nicht daran hindern, etwas anderes zu tun. Jede Schutzmaßnahme im Prompt, Modell oder Code hängt davon ab, dass sich das Modell korrekt verhält, was Ihre Sorge ist. Eine Berechtigung hängt davon nicht ab. Hat der Agent keinen Zugriff auf ein System, kann er es nicht ändern, egal was er entscheidet.

Die Prinzipien sind die, die Sie bereits kennen, least privilege und explizite Autorisierung zuerst. Die offene Frage ist, wo man sie in einem Agenten-Stack durchsetzt.

Geben Sie jedem Agenten seine eigenen Grenzen

Schreiben Sie Anweisungen für jeden Agenten: die Aufgabe, die Grenzen und was zu tun ist, wenn eine erreicht wird. Unterstützen Sie diese dann mit Richtlinienberechtigungen, denn Anweisungen sind nur Aufforderungen. Listen Sie die Daten auf, die der Agent lesen kann, die Systeme, die er ändern darf, und die Aktionen, die eine Genehmigung durch eine Person erfordern. Das Ändern von Berechtigungen benötigt immer diese Genehmigung.Credentials sollten eng gefasst, kurzlebig und leicht widerrufbar sein.

Nehmen Sie einen Agenten, der Kundendaten aktualisiert. Wenn eine versteckte Anweisung in einem Anhang ihn nach der Kundenliste sendet, sollte eine network policy den Export blockieren, und das Protokoll sollte zeigen, welches Tool aufgerufen wurde, was es erlaubt hat und wie es endete.

Überprüfen Sie, was der Agent ausführt, und härten Sie dann den Ort, an dem er ausgeführt wird

Agenten laden Tools, Fähigkeiten und Abhängigkeiten, und jedes läuft mit den Berechtigungen des Agenten. Ein manipuliertes Tool erhält denselben Zugriff wie der Agent. So wird ein Agent rogue, ohne dass jemand den Agenten selbst berührt. Bevor etwas geladen wird, bestätigen Sie die Herkunft, erstellen einen Hash und vergleichen ihn mit einer bekannten, sicheren Basislinie. Wenn eine Datei nicht mit einer genehmigten Anforderung übereinstimmt, markieren Sie sie und vertrauen ihr nicht mehr.

Härtung folgt durchgehend dem Prinzip der geringsten Rechte. Führen Sie es als Nicht-Root-Benutzer aus. Beschränken Sie Dateisystemberechtigungen und offene Ports. Entfernen Sie Pakete, Dateien und Dienste, die niemand nutzt, einschließlich Build-Reste, da alles Installierte ein Weg ist, den ein Agent finden kann. Blockieren Sie das Herunterladen und Ausführen von Remote-Code und bereinigen Sie Eingaben.

Erfassen Sie, was die Kontrollen übersehen

Ein Teil wird durchkommen, daher müssen Sie es sehen. Die Bedrohungserkennung sucht nach Verhaltensweisen, die nicht zur Aufgabe des Agenten passen. Die Änderungsverfolgung zeigt, was sich an den berührten Systemen geändert hat, und prüft dies gegen das, was jemand genehmigt hat. Bewahren Sie geschützte Aufzeichnungen über Tool-Aufrufe und die Entscheidungen, die sie ermöglichten, sowie eine getestete Methode zum Sperren des Zugriffs auf, damit Ermittler rekonstruieren können, was passiert ist, und entsprechend handeln.

Change Tracker markiert die Änderung, die niemand genehmigt hat

Agenten schreiben Dateien, bearbeiten Konfigurationen, installieren Pakete und starten Dienste. Netwrix Change Tracker überwacht die Systeme, auf denen all dies geschieht. Es zieht Konfigurationsdaten von Servern, Desktops, Datenbanken und Netzwerkgeräten, speichert eine Basislinie für jedes und vergleicht sie mit Ihrem gehärteten Build-Standard, wie einem CIS Benchmark. Dateiintegritätsüberwachung erkennt Änderungen an Dateien, sodass manipulierte Tools oder Abhängigkeiten sichtbar werden.

Zurück zur sudoers-Datei. Planned Change-Regeln, gespeist durch Änderungsanfragen von ServiceNow und anderen ITSM-Tools, stimmen mit den genehmigten Änderungen überein, und Change Tracker meldet alles, was keiner Regel entspricht, als potenzielle Verletzungsaktivität. Die Bearbeitung des Agenten hat keine genehmigte Anfrage dahinter, daher erscheint sie. Jedes Ereignis zeichnet auf, was sich geändert hat, wann und auf welchem Gerät, und die Historie ist bei der Untersuchung noch vorhanden.