Les équipes de sécurité qui évaluent Sysdig AI Defense devraient vérifier si elles peuvent relier l’appel d’outil déclaré par un agent aux processus qui l’exécutent réellement. Sysdig a annoncé la disponibilité générale le 4 novembre. La question d’évaluation utile est concrète : lorsqu’un outil lance des processus supplémentaires, l’équipe peut-elle identifier l’action, l’identité responsable et la réponse du contrôle à partir de preuves collectées indépendamment du compte rendu rédigé par l’agent ?
Ce qu’a annoncé Sysdig
Le communiqué de Sysdig décrit une surveillance à la fois dans l’environnement d’exécution de l’agent et au niveau du système d’exploitation, avec des politiques d’abord configurées pour émettre des alertes et pouvant ensuite être appliquées de manière contraignante. Il précise une disponibilité générale pour macOS et Windows. L’explication du lancement décrit l’association entre les actions déclarées et l’activité observée. SecurityWeek couvre séparément le lancement.
Il s’agit d’allégations de capacité du fournisseur et d’articles consacrés au lancement, pas d’une preuve indépendante d’une couverture complète ni d’une prévention complète. Maetra n’a pas testé le produit. L’évaluation ci-dessous est une analyse de Maetra destinée aux responsables de la sécurité d’exécution qui évaluent leur propre environnement. Elle ne suppose pas que chaque hôte, sous-processus ou service géré par un fournisseur soit observable.
Définir un périmètre d’observation avant le test
Choisissez un flux de travail d’agent hors production et une tâche sans risque avec un résultat connu. Par exemple, demandez à l’agent de générer un petit rapport à partir de fichiers de test au moyen d’une commande qui lance un processus auxiliaire. Gardez les identifiants réels et les informations clients en dehors de l’exercice. Notez l’hôte, la version de l’agent, l’environnement d’exécution de l’agent, l’identité, l’outil et le résultat attendu avant de commencer.
Le test doit déterminer si deux enregistrements différents peuvent être mis en relation. L’un décrit l’appel d’outil demandé. L’autre consigne l’activité de l’hôte qui a suivi. Une explication lisible de l’agent peut aider un enquêteur à comprendre l’intention, mais elle ne peut pas établir quels processus ont été exécutés ni quels fichiers ils ont touchés.
Demandez à l’évaluateur du produit de préciser les environnements dans lesquels les données sont effectivement recueillies. Une commande locale, un processus à l’intérieur d’un conteneur et un travail délégué à un service hébergé peuvent exiger des méthodes de collecte différentes. Si le test n’inclut que l’ordinateur portable, sa conclusion ne doit couvrir que ce périmètre testé. Étendre la conclusion à un compte cloud exigerait des preuves supplémentaires.
Rapprocher les enregistrements plutôt que les compter
Un appel d’outil et un processus sont deux unités différentes. Plusieurs processus peuvent être les conséquences ordinaires d’une commande autorisée. Un décalage numérique à lui seul ne prouve ni un comportement malveillant, ni une couverture de sécurité manquante, ni une dérive de tâche.
Pour la session de test, conservez les références suivantes :
- La tâche demandée et l’enregistrement de l’appel d’outil de l’agent.
- Les relations de processus observées sur l’hôte et les horodatages pertinents.
- L’identité et les autorisations utilisées pour l’opération.
- Les fichiers ou destinations concernés, avec des valeurs de test sûres.
- La configuration de la politique et son mode de réponse actif.
- L’artefact produit et toute lacune de collecte.
Suivez une chaîne de processus depuis la demande initiale, en passant par le processus auxiliaire, jusqu’au résultat produit. Demandez ensuite à une personne qui n’a pas exécuté l’exercice d’expliquer la séquence à partir de ces enregistrements. Si elle ne peut pas relier un processus enfant à la tâche d’origine, documentez le maillon manquant. Évitez de combler cette lacune avec la propre affirmation de l’agent selon laquelle tout s’est bien passé.
Un processus auxiliaire bénin connu fournit un point de référence utile. Répétez l’exercice avec une destination ou un fichier de test délibérément interdit, dans l’environnement de test autorisé, afin d’examiner la réponse de la politique. Le test doit être conçu de sorte qu’une autorisation inattendue ait un effet limité et sans danger.
Séparer l’alerte de l’application
Une alerte peut être exacte alors même que l’action s’exécute jusqu’au bout. Avant d’exécuter un test de blocage, confirmez que la politique choisie est configurée pour appliquer la réponse prévue. Consignez ce mode avec le résultat. Un tableau de bord qui affiche une détection ne prouve pas, à lui seul, que l’écriture, le téléversement ou le lancement de processus a été empêché.
Pour un test sans risque de blocage d’écriture, inspectez la destination après coup. Conservez à la fois l’événement de sécurité et le résultat observé sur la destination. Si le produit arrête un processus après son démarrage, identifiez ce que le test permet d’établir au sujet des effets survenus avant l’arrêt. Évitez de présenter l’arrêt du processus comme une preuve qu’aucune donnée n’a pu être déplacée.
Examinez aussi la procédure de dérogation. Consignez qui peut approuver une exception, l’action qu’elle couvre et sa durée. Une évaluation devient moins instructive si une exception large modifie silencieusement les conditions entre le cas autorisé et le cas refusé. Restaurez la configuration de test et conservez l’historique des changements lorsque l’exercice se termine.
Utiliser le résultat pour améliorer une procédure d’investigation
Le résultat devrait prendre la forme d’un bref compte rendu de ce qui a été observé, de ce que la politique a fait et des périmètres qui restent non testés. Indiquez les échecs de collecte en même temps que les corrélations réussies. Cela donne au responsable de la sécurité un élément exploitable pour la préparation aux incidents, sans transformer une démonstration produit en déclaration générale de garantie.
Cela diffère de l’enquête sur des extensions d’agent malveillantes : la tâche immédiate consiste à relier une demande d’outil ordinaire à son exécution sur l’hôte et à vérifier le mode de réponse. Le guide de Maetra sur les preuves d’audit IA aide à planifier la collecte des éléments de preuve correspondants.
Maetra Secure analyse les prompts, les messages, les appels d’outils et les résultats à la recherche de menaces à l’exécution. Audit prend en charge un historique d’événements inspectable. Ces capacités n’impliquent pas une collecte de processus au niveau noyau ni une intégration native avec Sysdig. Utilisez la documentation Maetra pour définir les preuves au niveau applicatif dont vous avez besoin en complément de vos outils de sécurité hôte.