Les programmes d'IA malveillants imposent : l'extension du principe de confiance zéro au code.

La sécurité logicielle a toujours reposé sur le développement humain. Autrefois, ce sont les humains qui écrivaient, relisaient et publiaient le code. Désormais, ces tâches sont automatisées.

Dans un récent article de recherche, Anthropic a indiqué que plus de 80 % du code intégré à sa base de données de productivité est généré par son modèle d'IA , Claude.

Les mêmes capacités qui augmentent la productivité des développeurs modifient l'économie des cyberattaques.

Pendant que les adversaires sont encore en train d'identifier la cible, les machines peuvent générer des charges utiles malveillantes, tester des variantes, adapter le code à différents environnements et répéter le processus à une vitesse que les logiciels de sécurité ne peuvent pas suivre.

La vitesse prime sur les commandes de sécurité

La plupart des processus de sécurité des logiciels d'entreprise prévoient une phase de revue. Le code est écrit, vérifié, testé, approuvé, puis déployé. Si un problème survient ultérieurement, les équipes de sécurité enquêtent et interviennent.

Ce modèle se heurte à des difficultés lorsque le programme passe de simples instructions à l'exécution en quelques minutes.

Le code généré par l'IA peut être transformé quasi instantanément en scripts, dépendances, tâches d'automatisation ou modifications d'infrastructure. Parallèlement, les agents de développement peuvent modifier des fichiers, résoudre des packages et exécuter des commandes.

Les examinateurs humains ne font plus partie du processus.

Les attaquants peuvent utiliser les mêmes mécanismes pour générer des vulnérabilités, tester des techniques d'évasion et modifier le comportement des charges utiles malveillantes en fonction des cibles. Il en résulte une plus grande flexibilité, avec moins d'indicateurs stables que les défenseurs peuvent identifier.

Bien que l'analyse basée sur l'IA puisse améliorer le filtrage, elle produit souvent des probabilités et non des politiques. Or, à la vitesse des machines, la mention « probablement suspect » est insuffisante. Par conséquent, la nécessité de règles et de cadres de gouvernance pour l'IA devient de plus en plus urgente.

Les machines modifient le modèle d'attaque.

Les attaquants humains ne disparaîtront pas, mais une plus grande partie de la chaîne d'attaque est désormais exécutée par des machines.

L'intelligence artificielle peut automatiser la reconnaissance, accélérer la découverte des vulnérabilités, générer du code d'exploitation, réécrire les charges utiles malveillantes et adapter les séquences de commandes à l'environnement cible. Cependant, la plupart des mesures de défense sont conçues pour pallier les limitations humaines : réutilisation d'infrastructures, raccourcis et schémas traçables. Ces limitations ne s'appliquent pas aux attaques de machines.

La charge utile malveillante générée par la machine peut ne correspondre à aucune signature connue ni ne pas être réputée. Elle peut être créée, utilisée brièvement, puis supprimée. Cependant, un logiciel malveillant basé sur l'IA doit interagir avec l'environnement cible pour atteindre son objectif. Son comportement ne peut dissimuler ses intentions ; il doit accéder aux ressources et modifier l'environnement de manière à faire progresser l'attaque.

Ce qu'un code malveillant peut faire, c'est créer le signal de sécurité le plus durable.

La sécurité doit se poser une question différente.

La sécurité de la chaîne d'approvisionnement logicielle s'est améliorée, mais une grande partie de cette sécurité consiste encore à vérifier les caractéristiques d'impact avant l'exécution plutôt qu'à contrôler l'exécution elle-même.

Les listes de composants logiciels (SBOM), les signatures et le code source permettent aux équipes de sécurité d'avoir une meilleure compréhension de la composition, de l'origine et de la date de compilation du code. Cependant, la connaissance du code source ne révèle pas le comportement du programme lors de son exécution.

Un programme peut réussir tous ces contrôles et malgré tout présenter des risques. Même l'impact d'un processus de compilation légitime peut enfreindre les politiques de sécurité lors de son exécution, tandis qu'un script généré par l'IA peut accomplir sa tâche d'une manière qui compromet les données ou les systèmes. Par conséquent, une liste de dépendances sans erreur n'est pas une garantie de sécurité, ce qui souligne l'importance de ne pas transiger sur les normes de programmation, même avec des outils d'IA.

La divulgation après la mise en œuvre intervient trop tard.

La détection et la réponse restent nécessaires, mais elles interviennent une fois que la menace a déjà infiltré l'environnement. Au moment où un comportement suspect devient visible, le logiciel malveillant a peut-être déjà accédé à des informations confidentielles, modifié l'état du système, ouvert des connexions réseau ou établi des points de continuité.

L'intelligence artificielle réduit considérablement ce délai. Le code peut être créé, modifié et déployé bien plus rapidement que les humains ne peuvent le vérifier. L'attente des preuves post-exécution laisse aux attaquants une grande marge de manœuvre.

Il nous faut avancer le processus de décision. Au lieu de se demander : « Peut-on contenir ce logiciel s’il dysfonctionne ? », il faudrait se demander : « Faut-il autoriser ce comportement dès le départ ? »

Cela ne signifie pas remplacer les commandes existantes, mais plutôt modifier l'emplacement du point de contrôle de sécurité critique.

Zéro confiance dans les instructions de programmation

Le principe de confiance zéro a transformé la sécurité des organisations en rejetant la confiance implicite. Les utilisateurs, les appareils, les sessions et les demandes d'accès ne sont plus considérés comme fiables simplement parce qu'ils semblent familiers ; ils doivent tous être vérifiés au regard des politiques établies.

La mise en œuvre du logiciel requiert le même niveau de vérification.

Il ne faut pas accorder à un code la seule raison pour laquelle il provient d'un dépôt connu, est signé par un éditeur reconnu, a été compilé ou n'a jamais présenté de comportement malveillant. Ce sont des indicateurs utiles, mais non concluants.

Le principe « Zéro confiance pour le code » répond à ce problème. Avant l’exécution d’un programme, son comportement attendu doit être évalué au regard des politiques définies. Si le comportement est acceptable, l’exécution peut se poursuivre. Dans le cas contraire, l’élément doit être bloqué, restreint, mis en quarantaine ou faire l’objet d’une enquête plus approfondie. Ce besoin souligne l’importance d’établir des règles et des cadres clairs pour l’intelligence artificielle, allant au-delà des simples politiques.

Les organisations peuvent commencer par définir chaque voie d'accès au code, que ce soit par son intégration à l'environnement ou son exécution avec des privilèges élevés. Cela inclut les canaux de développement formels tels que les dépôts, les packages open source, les conteneurs et les pipelines d'intégration continue/déploiement continu (CI/CD), ainsi que les pièces jointes aux courriels, les fichiers téléchargés, les macros, les extensions de navigateur, les installateurs de points de terminaison, les intégrations tierces et les scripts injectés via des outils d'IA ou d'automatisation.

Il est ensuite crucial d'identifier les points où ces mécanismes reposent sur une confiance héritée. Si l'exécution est autorisée parce que le logiciel provient d'une source fiable, a été signé, a subi un processus de compilation ou ne présente aucun antécédent malveillant, ce contrôle est incomplet. Le comportement doit encore être évalué avant que l'élément puisse être autorisé à s'exécuter. Ceci met également en évidence la vulnérabilité à la vulnérabilité découlant de la dépendance croissante aux fournisseurs d'IA.

À mesure que l'intelligence artificielle prend en charge une part croissante de la création de code, qu'il soit légitime ou malveillant, les organisations ne peuvent plus se contenter d'autoriser l'exécution de code ayant passé les contrôles actuels. La mise en œuvre de telles mesures doit désormais faire l'objet d'une décision de sécurité mûrement réfléchie.

Nous avons répertorié les meilleures suites de sécurité Internet pour PC, Mac et appareils mobiles.