Les équipes de sécurité ont longtemps donné la priorité aux vulnérabilités de grande gravité tout en reportant souvent les correctifs pour les problèmes de moindre gravité. Cette approche pourrait bientôt devenir plus dangereuse.
Les pratiques actuelles de gestion des vulnérabilités ont été conçues pour un monde pré-IA. Selon Igor Seletskiy, PDG de TuxCare, les modèles d’IA commencent à identifier des chaînes impliquant plusieurs vulnérabilités de faible et moyenne gravité que les chercheurs humains connecteraient rarement. Individuellement, ces failles pourraient ne pas justifier une action urgente. Combinés, ils peuvent conduire à une compromission complète du système.
Entrepreneur de longue date dans les secteurs de Linux, de l’hébergement et de la cybersécurité, Seletskiy estime que les entreprises se concentrent sur les mauvais indicateurs. Le risque futur, a-t-il déclaré, n’est pas nécessairement une augmentation des vulnérabilités et expositions communes (CVE) de haute gravité. Il s’agit de la capacité de l’IA à créer des exploits à fort impact à partir de vulnérabilités qui n’ont jamais été considérées isolément comme à haut risque.
« Ce qui pose problème, c’est de l’utiliser comme porte de priorisation car il n’a aucun concept de composition. Trois faibles failles, une fuite d’informations, un bug de mémoire et un bac à sable faible peuvent aboutir à un compromis complet même si aucun lien n’est critique », a-t-il déclaré à LinuxInsider.
La plus grande menace
Seletskiy est plus préoccupé par un autre risque émergent. La menace n’est pas du tout le score CVE. C’est le nombre de vulnérabilités que vous portez.
Chaque faille ouverte est un autre lien qui peut se combiner avec le reste. Le nombre de chaînes possibles augmente de façon exponentielle avec ce nombre, et non linéairement.
« Un score de trois ne devrait pas être considéré comme un résultat sûr. Cela devrait être considéré comme un maillon potentiel dans une chaîne, et le nombre total de vulnérabilités ouvertes devient une mesure de risque de premier ordre à part entière », a-t-il averti.
Seletskiy soutient que si la notation CVE nécessite une refonte, elle devrait devenir plus contextuelle. Qu’est-ce qui s’exécute d’autre sur un serveur et combien reste non corrigé compte plus que n’importe quel score de base unique.
Si le décompte des CVE de haute gravité n’est pas une bonne mesure, les responsables de la sécurité de l’information (RSSI) doivent suivre les vulnérabilités logicielles à l’aide d’indicateurs de performance clés (KPI) spécifiques. Il leur a suggéré d’arrêter de mesurer les vulnérabilités entrantes et de commencer à mesurer leur propre exposition et leur propre débit de remédiation.
« Compter les CVE critiques vous indique ce que le monde a produit, et non quel est votre risque », a-t-il déclaré.
Suivez plutôt 4 choses
Seletskiy est connu pour sa passion d’aider les organisations à améliorer la sécurité, la disponibilité et la conformité grâce à des correctifs automatisés en direct et à une prise en charge du cycle de vie étendu pour Linux et les logiciels open source. Au lieu de s’appuyer sur des scores CVE isolés, il recommande de suivre ces métriques :
- Délai entre la découverte de la vulnérabilité et la correction sur l’ensemble de la flotte. Regardez l’horloge complète, pas seulement votre vitesse de déploiement, mais également les basses et moyennes. Si le fournisseur met six mois pour expédier le correctif, votre vitesse de déploiement n’a pas d’importance. Privilégiez les logiciels et les fournisseurs qui exécutent rapidement les correctifs, car la latence de leurs correctifs devient votre exposition.
- La taille du carnet de commandes, pas seulement son âge. Le nombre brut de vulnérabilités ouvertes constitue désormais une mesure de risque à part entière, car le risque en chaîne augmente de façon exponentielle avec lui : 200 points bas différés ne sont pas 200 petits problèmes. Ils constituent la matière première d’un très grand nombre de chaînes possibles.
- Âge du backlog : combien de temps les failles restent ouvertes. Une chaîne a seulement besoin que ses maillons restent ouverts suffisamment longtemps pour être assemblés.
- Arrêtez de considérer « inaccessible » comme « sûr ». Le chaînage brise ce filtre. Une faille aujourd’hui inaccessible le devient dès lors qu’un autre lien en ouvre le chemin.
« Votre risque d’enchaînement dépend du nombre de failles que vous portez et de la durée pendant laquelle elles restent ouvertes. Mesurez donc l’arriéré et la vitesse à laquelle vous l’effacez, et non la gravité de l’inbound », a-t-il résumé.
Comment 3 failles mineures deviennent une violation majeure
Seletskiy a utilisé un scénario basé sur trois failles que les équipes de sécurité très occupées retardent généralement la correction.
La première est une fuite d’informations de faible gravité – une erreur verbeuse qui expose une adresse mémoire. La seconde est une faille de contrôle d’accès ou de falsification de requête côté serveur (SSRF) à impact moyen qui permet à un utilisateur disposant de faibles privilèges d’accéder à un service interne. Le troisième est un bug de corruption de mémoire dans ce service, que tout le monde qualifie de « pratiquement non exploitable » car la randomisation de la disposition de l’espace d’adressage (ASLR) le rend peu fiable sans connaissance de la disposition de la mémoire.
Il a expliqué que, individuellement, ce sont les types de failles que les équipes informatiques retardent régulièrement leur correction. Cependant, une fois enchaînée, la faille 1 fournit la disposition de la mémoire qui rend la faille 3 fiable. Le deuxième défaut donne le chemin pour y parvenir. Il s’agit désormais d’une exécution de code à distance fiable et le pirate informatique est propriétaire du serveur.
« La contribution de l’IA ne consiste à trouver aucun d’entre eux. Elle reconnaît que la fuite est exactement l’ingrédient manquant qui fait fonctionner le bug de mémoire, sur les composants que votre tri a examinés à différents jours et s’est soldé par un niveau bas », a noté Seletskiy.
Il a poursuivi : « Il n’est pas nécessaire que cela s’arrête à trois. Une machine construira volontiers une chaîne de dix ou 20 maillons qu’aucun humain ne pourrait jamais tracer à la main. C’est pourquoi le décompte brut des défauts « inoffensifs » que vous portez est si important. Chaque échelon supplémentaire est un autre échelon que la chaîne peut utiliser. «
Renvoyez la balance aux défenseurs
Selon Seletskiy, une solution apparemment logique ne fonctionne pas. Essayer de pré-chaîner est un piège. Les chances sont en faveur des attaquants, qui n’ont besoin que de trouver une seule chaîne viable.
« Il faudrait tous les cartographier, et leur nombre augmente de façon exponentielle. C’est une course que vous ne pouvez pas gagner », a-t-il déclaré.
La solution la plus efficace nécessite de repenser la façon dont les logiciels sont créés et entretenus, plutôt que d’utiliser une IA défensive. Prédire les chaînes fait jouer le jeu des attaquants sur un plateau incliné en leur faveur. Au lieu de cela, réduire le nombre de choses qui peuvent être enchaînées est le jeu que les défenseurs peuvent gagner.
Seletskiy a recommandé d’éliminer les vulnérabilités qui permettent le chaînage. Retirez les liens pour qu’il n’y ait rien à assembler.
« Parce que le risque augmente de façon exponentielle, chaque défaut que vous supprimez en supprime une quantité disproportionnée », a-t-il déclaré.
Cette approche se résume à deux priorités : premièrement, renforcer les logiciels afin que moins de failles soient introduites grâce à des pratiques de développement sécurisées, des langages sécurisés en mémoire, des surfaces d’attaque réduites et une véritable isolation. Deuxièmement, éliminez rapidement les failles déjà présentes dans vos systèmes.
