Sicherheitsteams, die Sysdig AI Defense bewerten, sollten testen, ob sie den vom Agenten gemeldeten Werkzeugaufruf mit den Prozessen verknüpfen können, die ihn tatsächlich ausführen. Sysdig hat am 4. November die allgemeine Verfügbarkeit angekündigt. Die nützliche Bewertungsfrage ist konkret: Wenn ein Werkzeug zusätzliche Prozesse startet, kann das Team dann die Aktion, die verantwortliche Identität und die Reaktion der Kontrolle anhand von Belegen nachvollziehen, die außerhalb der eigenen Zusammenfassung des Agenten erfasst wurden?
Was Sysdig angekündigt hat
Die Mitteilung von Sysdig beschreibt eine Überwachung sowohl innerhalb der Agenten-Laufzeitumgebung als auch auf Betriebssystemebene sowie Richtlinien, die zunächst im Alarmmodus beginnen, bevor sie auf Durchsetzung umgestellt werden. Sie nennt die allgemeine Verfügbarkeit für macOS und Windows. Die Einführungserklärung beschreibt, wie gemeldete Aktionen mit beobachteter Aktivität gekoppelt werden. SecurityWeek berichtet separat über den Start.
Dabei handelt es sich um Herstellerangaben zu Fähigkeiten und um Berichterstattung zum Produktstart, nicht um einen unabhängigen Nachweis vollständiger Abdeckung oder Verhinderung. Maetra hat das Produkt nicht getestet. Die folgende Bewertung ist eine Analyse von Maetra für Verantwortliche der Laufzeitsicherheit, die ihre eigene Umgebung beurteilen. Sie setzt nicht voraus, dass jeder Host, jeder Unterprozess oder jeder verwaltete Dienst beobachtbar ist.
Vor dem Test den Umfang der Überwachung festlegen
Wählen Sie einen Agenten-Workflow außerhalb der Produktion und eine harmlose Aufgabe mit bekanntem Ergebnis. Bitten Sie den Agenten zum Beispiel, aus Testdateien einen kleinen Bericht zu erzeugen, und verwenden Sie dabei einen Befehl, der einen Hilfsprozess startet. Halten Sie echte Zugangsdaten und Kundeninformationen aus dem Test heraus. Notieren Sie vor dem Start Host, Agentenversion, Harness, Identität, Werkzeug und erwartete Ausgabe.
Der Test sollte beantworten, ob sich zwei unterschiedliche Aufzeichnungen miteinander verknüpfen lassen. Eine Aufzeichnung beschreibt den angeforderten Werkzeugaufruf. Eine andere zeichnet die darauf folgende Host-Aktivität auf. Eine gut lesbare Erklärung des Agenten kann Ermittlern helfen, die Absicht zu verstehen, aber sie kann nicht belegen, welche Prozesse gelaufen sind oder welche Dateien sie berührt haben.
Lassen Sie den Produkttester genau angeben, wo die Erfassung tatsächlich greift. Ein lokaler Befehl, ein Prozess innerhalb eines Containers und Arbeit, die an einen gehosteten Dienst delegiert wird, können unterschiedliche Erfassungsmethoden erfordern. Wenn der Test nur den Laptop umfasst, sollte sich seine Schlussfolgerung auch nur auf den tatsächlich geprüften Bereich beziehen. Um die Schlussfolgerung auf ein Cloud-Konto auszudehnen, wären zusätzliche Belege erforderlich.
Die Aufzeichnungen abgleichen statt sie zu zählen
Ein Werkzeugaufruf und ein Prozess sind unterschiedliche Einheiten. Mehrere Prozesse können normale Folgen eines einzelnen autorisierten Befehls sein. Eine zahlenmäßige Abweichung allein belegt weder bösartiges Verhalten noch fehlende Sicherheitsabdeckung oder ein Abweichen von der Aufgabe.
Halten Sie für die Testsitzung die folgenden Referenzen fest:
- die angeforderte Aufgabe und die Aufzeichnung des Werkzeugaufrufs durch den Agenten
- die beobachteten Prozessbeziehungen des Hosts und die relevanten Zeitstempel
- die für den Vorgang verwendete Identität und ihre Berechtigungen
- die beteiligten Dateien oder Ziele mit sicheren Testwerten
- die Richtlinienkonfiguration und ihr aktiver Reaktionsmodus
- das entstandene Artefakt und etwaige Lücken in der Erfassung
Verfolgen Sie eine Prozesskette von der ursprünglichen Anfrage über den Hilfsprozess bis zur Ausgabe. Bitten Sie dann jemanden, der den Test nicht selbst durchgeführt hat, die Abfolge allein auf Basis dieser Aufzeichnungen zu erklären. Wenn diese Person einen Kindprozess nicht mit seiner auslösenden Aufgabe verknüpfen kann, dokumentieren Sie das fehlende Bindeglied. Füllen Sie diese Lücke nicht mit der eigenen Behauptung des Agenten, alles sei erfolgreich verlaufen.
Ein bekanntermaßen unkritischer Hilfsprozess liefert eine nützliche Vergleichsgrundlage. Wiederholen Sie den Test innerhalb der autorisierten Testumgebung mit einem absichtlich nicht erlaubten Testziel oder einer absichtlich nicht erlaubten Datei, um zu prüfen, wie die Richtlinie reagiert. Der Test sollte so angelegt sein, dass eine unerwartete Erlaubnis einen begrenzten und harmlosen Effekt hat.
Alarmierung von Durchsetzung trennen
Eine Warnung kann korrekt sein, auch wenn die Aktion trotzdem abgeschlossen wird. Bevor Sie einen Blockiertest durchführen, bestätigen Sie, dass die ausgewählte Richtlinie so konfiguriert ist, dass sie die beabsichtigte Reaktion auch tatsächlich durchsetzt. Halten Sie diesen Modus zusammen mit dem Ergebnis fest. Ein Dashboard, das eine Erkennung zeigt, belegt für sich genommen nicht, dass der Schreibvorgang, Upload oder Prozessstart verhindert wurde.
Prüfen Sie bei einem harmlosen Test für blockiertes Schreiben anschließend das Ziel. Bewahren Sie sowohl das Sicherheitsereignis als auch das Ergebnis am Ziel auf. Wenn das Produkt einen Prozess stoppt, nachdem er bereits gestartet wurde, halten Sie fest, was der Test über Wirkungen aussagen kann, die vor der Beendigung eingetreten sind. Beschreiben Sie die Prozessbeendigung nicht als Beweis dafür, dass keine Daten bewegt worden sein können.
Prüfen Sie außerdem das Verfahren für Ausnahmen. Halten Sie fest, wer eine Ausnahme genehmigen kann, welche Aktion sie abdeckt und wie lange sie gilt. Eine Bewertung verliert an Aussagekraft, wenn eine weit gefasste Ausnahme stillschweigend die Bedingungen zwischen dem erlaubten und dem verweigerten Fall verändert. Stellen Sie die Testkonfiguration nach Abschluss der Übung wieder her und bewahren Sie den Änderungsnachweis auf.
Das Ergebnis nutzen, um einen Untersuchungsablauf zu verbessern
Das Ergebnis sollte ein kurzer Bericht darüber sein, was beobachtet wurde, was die Richtlinie getan hat und welche Grenzen ungetestet bleiben. Nennen Sie Erfassungsausfälle neben erfolgreichen Korrelationen. So erhalten Sicherheitsverantwortliche etwas, das sich für die Vorbereitung auf Vorfälle nutzen lässt, ohne eine Produktdemonstration in eine pauschale Zusicherung zu verwandeln.
Das unterscheidet sich von der Untersuchung bösartiger Agentenerweiterungen: Die unmittelbare Aufgabe besteht darin, eine gewöhnliche Werkzeuganforderung mit ihrer Ausführung auf dem Host zu verknüpfen und den Reaktionsmodus zu prüfen. Der Leitfaden von Maetra zu Prüfnachweisen für KI-Audits bietet dazu eine verwandte Planung von Nachweisen.
Maetra Secure prüft Prompts, Nachrichten, Werkzeugaufrufe und Ausgaben auf Laufzeitbedrohungen. Audit unterstützt eine nachvollziehbare Ereignishistorie. Diese Fähigkeiten bedeuten nicht automatisch eine Prozesserfassung auf Kernel-Ebene oder eine native Sysdig-Integration. Nutzen Sie die Maetra-Dokumentation, um die Nachweise auf Anwendungsebene zu definieren, die Sie zusätzlich zu Ihren Host-Sicherheitswerkzeugen benötigen.