Les entreprises sont engagées dans une course contre la montre face à l’accélération des cyberattaques alimentées par l’IA

Jan Wildeboer, Evangeliste EMEA, Red Hat partage son analyse et ses conseils.

Ces modèles analysent automatiquement les correctifs publiés pour identifier les vulnérabilités concernées, puis génèrent du code d’exploitation et peuvent même repérer les systèmes exposés n’ayant pas encore appliqué ces correctifs – le tout en guère plus de temps qu’il n’en faut pour se servir une tasse de café. Alors qu’auparavant, les entreprises disposaient de plusieurs semaines pour corriger une vulnérabilité connue, elles n’ont aujourd’hui souvent que quelques heures (et encore). Face à ce constat, les entreprises peuvent mettre en œuvre quatre mesures pour adapter leur infrastructure informatique à ce nouveau rythme de menaces.

Lorsqu’un correctif de sécurité est publié pour un composant open source, la vulnérabilité qu’il corrige peut être identifiée directement à partir de ce correctif. C’est cette situation que les analyses assistées par l’IA exploitent. Un dispositif d’IA servant à mener des attaques compare automatiquement les anciennes et les nouvelles versions, puis reconstitue la vulnérabilité concernée et génère un exploit fonctionnel à partir de celle-ci. Il lui suffit ensuite de rechercher les systèmes connectés à Internet qui exécutent encore des versions anciennes et non corrigées, chacun constituant une cible immédiatement exploitable.

Résultat : le délai entre la publication d’un correctif et l’exploitation de la vulnérabilité corrigée est passé de plusieurs semaines à parfois quelques heures seulement.

Or, les entreprises qui ne parviennent pas à mettre à jour leurs systèmes à une telle vitesse donnent aux attaquants l’occasion de cibler et d’exploiter automatiquement ces systèmes.

Quatre stratégies clés peuvent contribuer à réduire cette fenêtre d’opportunité au minimum.

Jan Wildeboer, Evangeliste EMEA, Red Hat

Miser sur des éditeurs fiables et actifs

Les éditeurs de logiciels ne sont pas tous aussi fiables en matière de sécurité, notamment pour ce qui est des composants open source intégrés à leurs produits. L’implication active d’un éditeur dans les projets open source – par ses contributions au code (commits), l’intégration de correctifs de sécurité dans des versions antérieures (backports) et la divulgation responsable des vulnérabilités découvertes – constitue des indicateurs clés de fiabilité et de proactivité.

Les éditeurs qui agissent et investissent dans les écosystèmes open source protègent non seulement leur relation avec leurs clients, mais également le code source sur lequel s’appuient nombre d’utilisateurs.

Établir et tenir à jour un inventaire des dépendances

Lorsque l’on ne sait pas exactement quelles bibliothèques open source, quelles dépendances et quelles versions sont utilisées dans un environnement en production, il est impossible de réagir rapidement en cas d’urgence. Mais aujourd’hui, il est tout aussi important de connaître le temps réellement nécessaire à un correctif pour passer des revues de sécurité internes aux phases de test et d’approbation, puis au déploiement en production.

Or, réduire nettement ces délais n’est possible que si les processus de recompilation (rebuild) et de redéploiement sont entièrement automatisés plutôt que gérés manuellement.

Automatiser les silos opérationnels

Ce qui ralentit les cycles d’application des correctifs n’est généralement pas le manque d’outils, mais le passage de relais manuel entre les environnements de développement, de staging, de pré-production et de production. Certes, ces interfaces ont leur importance. Toutefois, elles peuvent être rationalisées en divisant les applications en couches indépendantes, déployables séparément au moyen de processus automatisés.

Une telle approche exige au préalable de disposer d’interfaces stables entre les couches (stabilité des API/ABI), afin de pouvoir mettre à jour une couche sans avoir à retester et valider toute l’application.

Adapter les délais de réponse au niveau de criticité

Toutes les vulnérabilités ne nécessitent pas le même délai de réaction. En hiérarchisant les bibliothèques déployées en fonction du niveau de risque, les entreprises peuvent intervenir immédiatement sur les composants critiques. Pour les applications moins critiques, l’accès au réseau peut être temporairement coupé ou d’autres mesures d’atténuation reposant sur des processus peuvent être mises en œuvre jusqu’à ce qu’un correctif soit prêt, plutôt que de déployer à la hâte un correctif incomplet.

Cet arbitrage relève du rôle classique du RSSI, à savoir trouver le juste équilibre entre risque et productivité, et passe par une collaboration étroite avec les architectes d’entreprise.

L’application de ces mesures exige rarement d’investir dans de nouveaux outils ou de nouvelles technologies, mais plutôt de revoir les priorités. Dans de nombreux cas, la transition vers des processus plus rapides ou des stratégies plus résilientes ne s’amorce qu’après qu’un incident de sécurité majeur se soit déjà produit. Certains systèmes utilisant des versions non corrigées et vieilles de plusieurs années continuent souvent de tourner en arrière-plan simplement parce qu’ils remplissent discrètement leur fonction.

Face à l’accélération des attaques et la précision avec laquelle les vulnérabilités peuvent être identifiées, c’est cette attitude attentiste qui constitue le véritable risque.