Les menaces liées à l'IA évoluent. Vos défenses doivent en faire autant.

Récemment, Vincent Danen de Red Hat a mis en lumière la façon dont les modèles d'IA ont détecté 271 failles de sécurité réelles dans Firefox en un seul passage lors de la collaboration entre Mozilla et Anthropic. Si l'IA peut agir ainsi pour les défenseurs, elle peut en faire de même pour les attaquants. Comme l'a dit Danen, « si votre stratégie de sécurité repose uniquement sur l'hypothèse que les logiciels seront exempts de vulnérabilités, vous avez déjà perdu ». 

Les vulnérabilités du code ne constituent que le point d'entrée. Les véritables dommages surviennent ensuite, par le biais de déplacements latéraux sur des réseaux mal configurés, d'identifiants disposant de trop de privilèges, de secrets sans rotation et de services qui se font mutuellement une confiance aveugle. Aucun cycle de correctifs ne peut suivre ce rythme. Cela souligne la nécessité de renforcer la « défense en profondeur » au sein des entreprises, un changement de culture qui part du principe qu'une compromission est inévitable et qui se concentre sur la réduction de l'impact de l'exposition elle-même. 

C'est la définition même du Zero Trust. Cette première vague de vulnérabilités en annonce une deuxième et une troisième, et les entreprises doivent adopter une approche Zero Trust pour passer d'une simple prévention à l'endiguement des brèches, en appliquant le principe du moindre privilège aux identités, aux secrets, à la segmentation du réseau et aux politiques à chaque couche. Les entreprises ont besoin d'une application automatisée capable de s'exécuter au rythme de ces menaces basées sur l'IA. Red Hat Ansible Automation Platform permet de rendre cela possible.

Évolution de la surface d'attaque liée à l'IA

Les outils traditionnels d'analyse des vulnérabilités signalent les problèmes potentiels et les transmettent à un humain pour le triage. L'IA a banalisé la cyberattaque. Aujourd'hui, les outils d'IA remplacent pratiquement toute une équipe à eux seuls, le tout pour le prix de quelques jetons. Alors que des brèches dévastatrices telles que SolarWinds exigeaient du temps, une expertise approfondie et de la chance, l'IA permet désormais à des attaquants motivés d'enchaîner sans effort des vulnérabilités complexes et multiplateformes.

Ces faiblesses en apparence mineures s'additionnent, et pas à votre avantage. Par exemple :

• Une page de connexion qui permet de tester des mots de passe trop rapidement
• Une page de paramètres qui ne vérifie pas à nouveau votre identité
• Une API qui expose brièvement un jeton de session lors de la déconnexion

Aucune de ces failles n'est excessivement dangereuse à elle seule. Pris individuellement, chacun de ces problèmes resterait dans un backlog avec une priorité « faible », mais une fois combinés, ils pourraient permettre à un attaquant de forcer un mot de passe par recherche exhaustive, de détourner la session avant son expiration et d'accéder à la page des paramètres en tant qu'administrateur. Trois bogues mineurs, et pourtant l'intrusion est réussie.

Ces modèles d'IA avancés écrivent, compilent et exécutent du code d'exploitation, en utilisant les échecs pour affiner et réitérer leurs attaques. Si les entreprises utilisent ces outils à leur avantage pour trouver et corriger rapidement des vulnérabilités jusque-là inconnues, la vérité est moins réjouissante : cette capacité est également à la disposition des attaquants. Comme l'a écrit Danen, « les mêmes outils qui servent aux défenseurs à détecter les bogues aideront inévitablement les attaquants à les trouver aussi ». Le niveau de compétences requis pour les attaquants vient de baisser. L'application plus rapide des correctifs fait partie de la solution, mais elle doit s'accompagner de systèmes de défense solides. 

La défense a besoin d'une couche opérationnelle automatisée

Red Hat Enterprise Linux avec SELinux et Red Hat OpenShift assurent déjà le durcissement au niveau de la plateforme, mais ces défenses doivent être complétées. Par exemple, SELinux ne décide pas qui est autorisé à déployer une application. L'isolation des conteneurs ne révoque pas les informations d'identification de la base de données lorsqu'un système de gestion des informations et des événements de sécurité (SIEM) détecte une attaque par force brute à trois heures du matin. Voici les rôles que l'automatisation peut jouer dans la création d'une bonne stratégie de défense. 

Les changements opérationnels (déploiements, correctifs, reconfigurations réseau, rotation des informations d'identification) passent par des personnes, des scripts, des pipelines et l'automatisation. Si ces chemins ne sont pas contrôlés par des politiques, le durcissement de la plateforme vous protège d'une catégorie d'attaques tout en en laissant une autre grande ouverte. 

NIST SP 800-207 présente le modèle d'architecture Zero Trust (ZTA), au centre duquel se trouve le point d'application des politiques (PEP). La plupart des gens considèrent le PEP comme un pare-feu ou une passerelle qui filtre le trafic réseau. Cependant, lorsque les équipes déploient des applications, appliquent des correctifs aux serveurs et modifient les configurations réseau, ces actions ne passent pas par un pare-feu, elles passent par l'automatisation. En fin de compte, le modèle Zero Trust est une discipline opérationnelle qui exige que l'automatisation soit mise en œuvre à grande échelle.

Ansible Automation Platform comme point d'application des politiques

Lorsqu'Ansible Automation Platform joue le rôle de PEP, chaque action opérationnelle passe par une plateforme qui vérifie l'identité, évalue les politiques, gère les secrets et consigne les résultats. Il ne s'agit pas de capacités avancées, mais des contrôles minimaux viables qu'exige le modèle Zero Trust. L'opérateur n'intervient jamais directement sur le système cible. C'est le playbook Ansible qui s'en charge, et il ne s'exécute qu'une fois que la plateforme a confirmé que l'opérateur est autorisé.

L'avantage architectural réside dans l'application centralisée avec une exécution distribuée. Les décisions relatives aux politiques sont prises au niveau d'un seul plan de contrôle, mais leur application a lieu partout où l'automatisation est exécutée. Il n'y a pas de connexion directe aux serveurs ni d'exécution de scripts à partir d'ordinateurs portables, ce qui réduit les risques de pratiques d'ingénierie non encadrées et de dérive de configuration intraçable. Cette approche permet également de corriger les anti-modèles tels que la prolifération des informations d'identification, l'automatisation de l'ombre (« shadow automation ») ou les mouvements latéraux non régis par des politiques.

Cette architecture atténue les vulnérabilités de sécurité critiques en éliminant les informations d'identification de production à hauts privilèges sur les points de terminaison locaux vulnérables. La plateforme d'automatisation est le point de contrôle unique, et chaque modification s'accompagne d'une identité, d'une approbation de politique et d'un enregistrement d'audit. 

Ansible Automation Platform peut mettre cela en œuvre via un modèle d'application à deux anneaux. L'anneau externe fonctionne au niveau de la plateforme. Avant le lancement d'un modèle de tâche, Ansible Automation Platform consulte le serveur Open Policy Agent (OPA) par le biais de la fonctionnalité intégrée d'application des politiques, avec l'ensemble du contexte de la tâche : l'identité de l'auteur du lancement, son équipe et le modèle exécuté. 

Figure 1 : Application des politiques par anneaux interne et externe avec Ansible Automation Platform

L'OPA évalue la demande par rapport à la politique et renvoie une autorisation ou un refus. Le playbook ne s’exécute jamais si l’anneau externe dit non. La politique OPA mappe l’appartenance à une équipe aux catégories de modèles autorisées.

package aap.gateway
import rego.v1 
default decision := {"allowed": true, "violations": []} 
patching_teams := {"Infrastructure", "Security"} 
network_teams := {"Infrastructure"} 
app_teams := {"Applications", "DevOps"} 
user_teams := {name | name := input.created_by.teams[_].name} 
decision := {     
	"allowed": false,     
	"violations": [sprintf(         
	"user '%s' is not in an authorised team for patching templates (requires: %v, has: %v)",         
	[input.created_by.username, patching_teams, user_teams],     
	)] 
} if {     
	not input.created_by.is_superuser     
	is_patching_template     
	not team_match(patching_teams) 
}

Fig. 2 Exemple de politique Rego pour une vérification Policy as Code

L'anneau interne s'exécute à l'intérieur du modèle ou du workflow lui-même. Pour les opérations potentiellement importantes comme les modifications de VLAN, le playbook récupère une identité SPIFFE (une identité de charge de travail cryptographique) et l'envoie à OPA. OPA évalue trois conditions : 

• La personne est autorisée par son appartenance à une équipe.
• La charge de travail est légitime via l'identité vérifiable SPIFFE.
• La modification demandée se situe dans une plage approuvée.

Les trois doivent réussir.

Fig. 3 Exemple d'application de plusieurs politiques avec Ansible Automation Platform

Cette technique est importante pour lutter contre les menaces basées sur l'IA, car la chaîne d'exploitation se brise au point d'application, et non au niveau de la vulnérabilité. Un agent d'IA qui enchaîne les bogues pour accéder à un serveur se retrouve bloqué dans le plan de données, où les politiques Zero Trust, comme la micro-segmentation du réseau et les informations d'identification à courte durée de vie, le privent de tout accès externe ou déplacement latéral. Il ne peut pas abuser de votre déploiement pour envoyer des applications malveillantes, ni modifier les politiques réseau de l'entreprise sans passer par Ansible Automation Platform. Dès qu'une compromission locale est détectée, la solution Event-Driven Ansible, incluse dans Ansible Automation Platform, isole automatiquement le système et fournit un contexte immédiat aux équipes de sécurité.

Les informations d'identification de l'utilisateur volées échouent au contrôle SPIFFE, car l'identité de la charge de travail ne correspond pas. Un nœud d'automatisation compromis échoue à la vérification des membres de l'équipe, car l'attaquant ne contrôle pas la session Ansible Automation Platform de l'utilisateur. Chaque anneau est indépendant. Il ne suffit pas d'en compromettre un. C'est la défense en profondeur en action.

Limiter l'impact potentiel à l'aide d'informations d'identification dynamiques et d'une micro-segmentation

Même avec l'application de politiques au niveau de l'automatisation, les informations d'identification et les chemins réseau restent une surface d'attaque. En cas de rotation mensuelle des mots de passe des bases de données, un attaquant qui y accède dispose d'une fenêtre d'un mois. Si les listes de contrôle d'accès réseau (ACL) sont constamment ouvertes entre les niveaux application et base de données, le chemin est toujours disponible.

Lors de l'exécution d'un workflow de déploiement d'applications, Ansible Automation Platform est en mesure de demander des informations d'identification de base de données dynamiques à HashiCorp Vault, un rôle PostgresSQL défini sur le schéma de l'application avec une durée de vie de 5 minutes. Les informations d'identification n'existent que pendant la fenêtre de déploiement. Lorsque la TTL expire, le rôle est supprimé. Il n'y a rien à voler, car rien n'est persistant.

Dans le même workflow, Ansible Automation Platform configure le réseau pour ouvrir une entrée de liste de contrôle d'accès qui autorise le trafic depuis l'adresse IP de l'application vers le port de base de données.

Contre les chaînes d'exploitation de l'IA, cela modifie l'attaque. Les outils peuvent enchaîner les bogues pour atteindre un niveau de base de données, mais ils trouvent des informations d'identification qui ont expiré il y a 4 minutes. La fenêtre d'exploitabilité passe de « jusqu'à ce que quelqu'un change le mot de passe » à « jusqu'à la fin de l'automatisation », soit quelques minutes seulement et non plusieurs mois. Lors de l'exécution de l'application en production, l'agent Vault gère le cycle de vie continu des informations d'identification.

Réponse aux incidents au rythme de la machine

Si les agents d'IA peuvent générer des exploits et les enchaîner, le recours à un analyste du Security Operations Center (SOC) pour être averti, se connecter, lire l'alerte, enquêter et révoquer manuellement les accès revient à agir à une échelle de temps humaine face à une menace numérique.

La solution Event-Driven Ansible permet de combler ce manque. Un système SIEM tel que Splunk détecte un modèle de force brute au niveau du point de terminaison d'authentification d'une application. Splunk peut déclencher une alerte dans Event-Driven Ansible via un flux d'événements, puis Event-Driven Ansible évalue l'événement et lance une tâche d'automatisation pour intervenir. Cette tâche appelle l'API de HashiCorp Vault pour révoquer chaque bail de base de données dynamique actif détenu par l'application. L'application perd immédiatement sa connectivité à la base de données.

—  
  name: Splunk Brute-Force credential revocation
  hosts: all
  sources:
    - ansible.eda.webhook:
        host: 0.0.0.0
        port: 5000
  rules:
    - name: Revoke credentials on SSH brute-force detection
      condition: event.payload.search_name is search("SSH Brute Force Detected")
      action:
        run_job_template:
          name: "Emergency: Revoke App Credentials"
          organization: Default

Fig. 4 : Exemple de rulebook Event-Driven Ansible pour les événements de force brute de Splunk
 

La boucle de la détection au confinement se termine en quelques secondes, ce qui réduit le temps moyen de résolution de plusieurs heures à quelques secondes. L'impact potentiel passe de « l'attaquant peut avoir accès à la base de données » à « l'attaquant a accès à une application qui ne peut plus accéder à ses données ».

Fig. 5 : Exemple de réponse à un incident pour une architecture Zero Trust avec Event-Driven Ansible
 

Il s'agit d'un confinement automatisé, qui peut être suivi d'une restauration manuelle. Event-Driven Ansible peut révoquer les informations d'identification sans approbation humaine, car la révocation est une mesure de sécurité par défaut : l'application cesse de fournir des données, mais rien n'est détruit. La restauration nécessite une intervention humaine pour enquêter, confirmer que la menace est résolue et lancer un workflow de restauration qui redéploie l'application. Le point de contrôle dans le processus de récupération existe car la restauration de l'accès après une compromission n'est pas une étape que l'on souhaite automatiser sans enquête humaine.

Plusieurs couches, une seule défense

La découverte des vulnérabilités assistée par l’IA rend la défense en profondeur non négociable. Cependant, une défense en profondeur sans couche opérationnelle automatisée laisse une faille que les attaques à la vitesse de la machine sauront exploiter.

Trois couches peuvent combler cette lacune, chacune brisant la chaîne d'exploitation de l'IA à un stade différent :

• Le renforcement de la plateforme (indicateurs de compilateur, SELinux, isolement des conteneurs, Address Space Layout Randomization (ASLR)) rend le bogue initial plus difficile à exploiter. Un modèle d'IA peut trouver la vulnérabilité, mais la plateforme renforcée impose une chaîne en plusieurs étapes uniquement pour parvenir à l'exécution du code.
• L'application des politiques avec Ansible Automation Platform bloque les chemins d'exploitation non autorisés. Même si la chaîne d'exploitation réussit, l'attaquant ne peut pas déployer, corriger, reconfigurer ni accéder à des secrets sans passer par le plan de contrôle d'automatisation. Les identifiants volés ne suffisent pas.
• La réponse automatisée avec Event-Driven Ansible aide à contenir les failles avant que le mouvement latéral ne commence. Le passage de la détection au confinement en quelques secondes s'aligne sur la vitesse des menaces basées sur l'IA, ce qu'une intervention humaine ne permet pas.

Chaque couche fonctionne de façon indépendante. Le renforcement de la plateforme ne dépend pas de l'application des politiques. L'application des politiques ne dépend pas de la réponse automatisée. Si une seule couche échoue, les deux autres limitent toujours les dommages. Cette indépendance permet aux équipes de sécurité de consacrer du temps à la réduction stratégique des risques plutôt qu'à la gestion des alertes, et elle permet aux organisations d'adopter des opérations assistées par l'IA avec la certitude que les garde-fous tiendront même lorsque les outils évoluent plus vite que les politiques.

La plupart des organisations disposent d'un renforcement de la plateforme. De nombreuses organisations adoptent les principes du Zero Trust. Peu d'entre elles ont relié l'application des politiques à l'automatisation à la vitesse requise par ces menaces. C'est dans cette faille que se produira la prochaine intrusion. En associant les trois couches décrites ci-dessus, vous renforcez vos défenses contre les conséquences d'une attaque basée sur l'IA.  

Ressources

• Webinaire : Mise en œuvre du Zero Trust avec Red Hat Ansible Automation Platform
• Webinaire : Automatiser la sécurité Aligner l'ITOps
• Livre numérique : Automatiser la sécurité pour aligner l'informatique d'entreprisePage affichée en Anglais (Français non disponible)
• Livre numérique : Red Hat Ansible Automation Platform, le guide du débutant
• Présentation interactive : Automatisation informatique, y compris l'automatisation de la sécurité
• Page Web : Automatisation de la sécurité