Un programme inconnu s’exécute sur un poste de travail de développeur, accède aux informations d’identification stockées et se connecte à un serveur externe. Son comportement déclenche une alerte de détection et de réponse des points finaux (EDR), laissant un analyste répondre à deux questions : le code est-il malveillant et qu’a-t-il déjà fait ?
L’IA générative peut rendre cette évaluation plus difficile en aidant les attaquants et les développeurs à produire du code inconnu. Les attaquants peuvent l’utiliser pour écrire et réviser du code malveillant, tandis que les développeurs l’utilisent pour générer des scripts et des applications légitimes. Les équipes de sécurité doivent évaluer le code inconnu provenant des deux sources sans considérer la nouveauté comme une preuve de danger.
Lorsque ce code s’exécute avec accès aux informations d’identification ou aux systèmes de déploiement, l’attente d’un comportement suspect peut obliger les équipes à enquêter sur l’exposition après coup. Le défi consiste à décider ce qu’il faut vérifier et restreindre avant l’exécution, et ce qui nécessite encore une surveillance de l’exécution et le jugement des analystes.
Un code inconnu s’ajoute aux charges de travail des analystes
Le volume des alertes est souvent présenté comme un problème de personnel. Il s’agit également d’un problème de décision : les cas qui nécessitent un examen manuel font perdre du temps aux analystes, car les équipes doivent déterminer s’il convient de contenir l’activité, de lui permettre de se poursuivre ou d’intensifier l’enquête.
Quelqu’un doit déterminer ce qui s’est passé, ce que l’artefact pourrait faire et si son confinement est justifié. Un fichier suspect sur une machine de test isolée crée un niveau d’urgence. Le même fichier exécuté dans un environnement de build avec accès aux clés de signature, aux informations d’identification cloud ou aux droits de déploiement nécessite une enquête plus approfondie.
L’IA peut aider les attaquants à produire des variantes de code malveillant, compliquant ainsi les vérifications qui dépendent de fichiers ou de signatures préalablement identifiés. Mais un nouveau hachage de fichier ne signifie pas nécessairement une nouvelle technique d’attaque. La détection comportementale reste importante car différents fichiers peuvent effectuer les mêmes actions malveillantes.
La charge de travail dépend de la fréquence à laquelle un code inconnu déclenche des alertes que les contrôles automatisés ne peuvent pas résoudre.
Les scores de risque nécessitent des règles d’application
La notation probabiliste est utile car les environnements réels sont désordonnés. Les signaux sont incomplets, les comportements changent selon le contexte et les attaquants créent volontairement une ambiguïté. Un score peut aider à prioriser ce qui mérite une attention prioritaire.
Un score de risque devient une base faible pour l’application lorsque les organisations n’ont pas défini ce que le score devrait déclencher. Les politiques doivent préciser quand bloquer l’activité, restreindre les autorisations ou exiger un examen, en tenant compte du système impliqué et de l’accès disponible au code.
Les organisations doivent être en mesure d’expliquer quelle règle, quelle preuve et quel contexte environnemental ont conduit à une décision d’autorisation ou de blocage. Les cas comparables devraient recevoir un traitement comparable, tandis que les exceptions documentées devraient tenir compte des différences légitimes de risque.
Après l’exécution, l’enquête s’élargit
Une fois le code suspect exécuté, une enquête doit établir à la fois ce qu’est le code et ce qu’il a fait. Les analystes peuvent avoir besoin de déterminer s’il a accédé aux informations d’identification, établi un moyen de rester actif, communiqué avec des systèmes contrôlés par des attaquants ou affecté d’autres machines. Même lorsqu’aucun compromis n’est trouvé, ce travail prend du temps.
Les workflows de développement peuvent étendre l’exposition. Le script d’installation d’un package peut s’exécuter avec les autorisations du compte qui l’installe. Les scripts générés par l’IA peuvent également s’exécuter sous des comptes de service privilégiés, donnant au code un accès non vérifié aux informations d’identification ou aux systèmes de déploiement.
La détection et le confinement peuvent limiter une attaque, mais les analystes peuvent néanmoins avoir besoin d’établir ce qui s’est passé avant le confinement. Des vérifications antérieures peuvent compléter ces capacités en identifiant les violations de politique avant que le code n’atteigne les systèmes sensibles.
Vérifier le code et limiter l’accès avant l’exécution
Commencez par des workflows qui introduisent ou exécutent du code inconnu, notamment des téléchargements, des agents de codage IA, des installations de packages et des pipelines d’intégration et de livraison continues (CI/CD). Vérifiez quels comptes lancent ce code et si leurs autorisations dépassent celles requises par la tâche.
Avant qu’un code inconnu ne s’exécute dans un environnement de production ou privilégié, les organisations peuvent vérifier sa source, examiner son contenu et, le cas échéant, le tester dans un environnement isolé. Les contrôles d’application peuvent restreindre ce qui est autorisé à s’exécuter, tandis que des autorisations limitées peuvent réduire ce à quoi le code approuvé peut accéder. Ces mesures peuvent identifier ou limiter certains risques, mais elles ne peuvent pas établir toutes les actions que le code peut entreprendre au moment de l’exécution.
La surveillance du runtime reste nécessaire car certains comportements malveillants ne deviennent apparents que lors de l’exécution. Des contrôles et des restrictions d’exécution antérieurs peuvent compléter l’EDR en bloquant les violations de politique identifiables et en donnant aux analystes plus de contexte. Les équipes doivent mesurer si ces contrôles réduisent le temps d’enquête sans créer de faux blocages excessifs ni retarder le travail légitime.
