Que faudra-t-il pour faire de VulnOps une réalité ?

Il y a un peu plus d’un an, avant que les modèles d’IA avancés ne commencent à découvrir des vulnérabilités logicielles à une échelle presque ingérable dans ce que l’on appelle la vulnpocalypse, trois experts du secteur ont lancé le concept de « VulnOps ».

VulnOps, tel qu’envisagé par Heather Adkins, Gadi Evron et Bruce Schneier, constitue une phase importante dans l’évolution de la cyberdéfense assistée par l’IA dans laquelle la recherche et la correction des vulnérabilités deviendraient évolutives, reproductibles, automatisées et intégrées aux opérations de l’entreprise. Ils envisageaient que cette nouvelle ère de gestion des vulnérabilités organisationnelles passerait d’une gestion des vulnérabilités augmentée par l’IA à des réseaux d’auto-réparation.

Depuis lors, la Cloud Security Alliance a développé un modèle opérationnel VulnOps, SANS a publié des conseils de mise en œuvre de VulnOps et introduira une formation VulnOps, et les praticiens commencent à expérimenter les technologies constitutives entourant cette idée.

La vraie question, cependant, est de savoir si le développement de VulnOps est suffisamment rapide pour suivre le rythme des découvertes de vulnérabilités.

Ce n’est pas le programme de gestion des vulnérabilités de votre père

Le précurseur le plus évident de la manière dont VulnOps peut créer un changement de mentalité en matière de gestion des vulnérabilités est le changement généralisé dans le développement de logiciels créé par DevOps. Selon IBM, DevOps est « une méthodologie de développement logiciel qui accélère la fourniture d’applications et de services hautes performances en combinant et en automatisant le travail des équipes de développement logiciel (Dev) et d’opérations informatiques (Ops). »

Les experts soulignent toutefois que VulnOps ne signifie pas accélérer la gestion des vulnérabilités existantes en ajoutant des composants d’IA. Il s’agit d’une toute nouvelle façon d’aborder la gestion des vulnérabilités qui s’appuie sur des agents d’IA pour automatiser et accélérer la manière dont les organisations gèrent les vulnérabilités.

Ils affirment qu’il ne s’agit rien de moins qu’une refonte complète des pratiques existantes de découverte, de priorisation et de correction des vulnérabilités.

Cependant, tout le monde n’est pas convaincu que VulnOps représente une rupture aussi fondamentale par rapport aux pratiques établies.

« Les organisations ont toujours dû faire face à la gestion des vulnérabilités », explique Elgee, qui reconnaît que le rythme accéléré de la découverte des vulnérabilités exerce une nouvelle pression sur les organisations, mais se demande si VulnOps constitue une discipline fondamentalement différente.

L’humain dans le circuit est-il mort ?

Les experts ne sont pas d’accord sur un aspect fondamental de VulnOps tel qu’ils comprennent actuellement le concept. Le désaccord porte sur la mesure dans laquelle le contrôle humain peut survivre lorsque la correction des vulnérabilités doit fonctionner à la vitesse de l’IA.

« Et généralement, cela conduit à des changements radicaux, en particulier dans les systèmes existants qui durent depuis longtemps et sont en mode maintenance », explique Khan. « Vous ne voulez pas faire tomber une entreprise ou détruire sa source de revenus en installant un correctif qui arrête essentiellement le processus commercial. »

Ce risque est la raison pour laquelle la plupart des professionnels de la sécurité ne souhaitent pas mettre les humains à l’écart.

Mogull, du CSA, prévient : « Nous sommes loin d’automatiser entièrement (la réparation) une partie du processus. À terme, nous aurons besoin de davantage, mais nous n’en sommes pas encore là, même avec les outils d’aujourd’hui », dit-il.

Il n’imagine pas non plus que les VulnOps fonctionneraient sans surveillance humaine. «N’oubliez pas que ce sont les humains qui sont responsables», dit Mogull. Il souligne que dans le cadre du modèle opérationnel de l’ASC qu’il a contribué à développer, l’IA peut prendre des décisions dans le cadre de politiques prédéfinies, mais que des changements potentiellement perturbateurs nécessitent toujours une intervention humaine.

Skoudis, du SANS Technology Institute, plaide en faveur de ce qu’il appelle un processus de gouvernance dans la boucle dans lequel « vous avez une gouvernance qui décide que, ‘Hé, si une action donnée que je prends peut tomber en dessous de ce niveau de gouvernance dans la boucle, faites-la simplement. Automatisez-la. N’y pensez même pas.' »

« Chaque organisation aura sa propre ligne distincte pour déterminer où la gouvernance dans la boucle s’appliquera, mais on pourrait dire, par exemple, concernant les correctifs importants pour les postes de travail Windows, de les déployer s’ils sont critiques, sur une base continue. Donc, en d’autres termes, faites 25 % par heure ou deux, sur l’espace d’une demi-journée. »

Evron, de Knostic, estime cependant que même ces arrangements pourraient s’avérer insoutenables, à mesure que l’IA accélère la découverte et l’exploitation des vulnérabilités.

« L’une des principales conclusions de ces derniers mois est que l’humain impliqué dans la boucle est mort », dit-il. « Nous ne pouvons tout simplement pas avancer assez vite pour que la grande majorité des opérations aient un humain dans la boucle. »

En plus de cela, Evron se demande si les correctifs autonomes en eux-mêmes resteront une solution adéquate. « Nous devons comprendre que les correctifs ne seront tout simplement pas assez rapides », déclare Evron. « Nous devons commencer à réfléchir à la manière dont nous construisons des programmes de sécurité dans un monde où l’application de correctifs n’est pas viable. »

Les correctifs autonomes ne peuvent être que transitoires

Evron pense que l’application automatisée de correctifs est une étape intermédiaire nécessaire, mais que même une remédiation entièrement automatisée pourrait éventuellement s’avérer insuffisante à mesure que l’IA accélère la découverte et l’exploitation des vulnérabilités.

« Démarrez votre programme de correctifs autonomes dès aujourd’hui, mais comprenez que nous devons nous préparer à un monde sans correctifs », prévient-il. « Si nous avons un humain dans la boucle, ce n’est qu’un interprète. L’humain aurait toute la responsabilité sans autorité ni capacité à comprendre ce qu’il fait. »

Evron soutient que l’industrie devrait cesser de penser exclusivement à la recherche de failles et à leur correction après coup et devrait plutôt opter pour des logiciels et des systèmes défensifs qui empêchent l’introduction des vulnérabilités, détectent et neutralisent l’exploitation en premier lieu, ou rendent les vulnérabilités individuelles moins conséquentes.

Il envisage trois approches pour faire de ces systèmes préventifs une réalité. La première consiste à les intégrer directement dans les agents de codage de l’IA, plutôt que de s’appuyer principalement sur l’analyse des vulnérabilités une fois le code écrit. « Contrôlez vos agents de codage et vous contrôlez votre code, afin que le code lui-même soit généré de manière plus sécurisée », explique Evron. Il préconise également d’analyser le code à la recherche de vulnérabilités dès sa génération, plutôt que d’attendre qu’il entre dans les pipelines d’intégration continue traditionnels.

La deuxième approche consiste à détecter et neutraliser les attaques au moment de l’exécution. Evron décrit ce qu’il appelle « un correctif en place pendant l’exécution ». Lors de la conférence (in)invite de cette année, Evron est monté sur scène pour montrer les moyens de mettre en place des correctifs pendant l’exécution. « Au fur et à mesure qu’une attaque se produit, elle est détectée dans les journaux et corrigée », explique Evron.

La troisième approche pour créer un système qui évite le cycle actuel de correctifs consiste à rendre les correctifs moins urgents grâce à une défense en profondeur, selon Evron. Il suggère de s’orienter vers des approches dans lesquelles les vulnérabilités critiques deviennent une question de défense en profondeur, « de sorte que vous n’ayez pas nécessairement besoin de mettre à jour immédiatement ».

Mesures que les RSSI devraient prendre dès maintenant

Selon Evron, la mesure la plus critique que les RSSI devraient prendre pour adopter VulnOps est de cesser de s’appuyer uniquement sur des pratiques établies qui pourraient les empêcher de reconnaître à quel point l’IA modifie fondamentalement l’environnement des menaces.

Par exemple, l’hygiène de base en matière de sécurité reste importante mais ne peut pas être considérée comme une réponse suffisante à la découverte de vulnérabilités basée sur l’IA, dit-il. « Arrêtez d’avoir peur d’imaginer, allez plus grand et comprenez que, bien sûr, nos fondamentaux comptent toujours ; ils ne nous sauveront pas », ajoute-t-il.

Et pourtant, d’autres experts se demandent comment les organisations peuvent s’adapter au nouveau monde exigeant de VulnOps sans définir au préalable leurs bases de sécurité. Elgee de Counter Hack déclare : « De nombreuses organisations, peut-être la plupart, n’ont même pas une idée complète de l’ensemble de leur inventaire d’actifs. »

Iru’s Khan estime que les RSSI devraient commencer à réfléchir à la manière dont la sécurité et l’ingénierie doivent renégocier leurs relations, étant donné que les équipes de sécurité ne peuvent pas simplement remettre des tickets de correction aux développeurs et s’attendre à des résultats plus rapides. « Ce mur doit tomber et il faut pouvoir laisser les autres équipes contribuer techniquement aux systèmes », déclare Khan.

Skoudis du SANS Technology Institute conseille aux RSSI de commencer à mettre en œuvre VulnOps sans tenter de transformer l’ensemble de l’entreprise vers un nouveau paradigme. Il soutient que les organisations devraient commencer à établir des limites de gouvernance au sein desquelles les agents d’IA peuvent opérer.

« Si le montant dépasse le seuil, s’il s’agit d’un risque commercial plus élevé, alors vous devez le faire examiner par un humain », explique Skoudis. « Mais si le montant est inférieur au seuil de gouvernance dans la boucle, poussez-le. »

Evron est convaincu que les RSSI peuvent s’attendre à ce que leurs équipes existantes gèrent la transition vers VulnOps, en particulier s’ils réduisent leur dépendance à l’égard des outils d’analyse des vulnérabilités qui génèrent tant de rapports de vulnérabilité. « Les équipes existantes peuvent gérer cela, mais pas avec les technologies actuelles qu’elles utilisent », dit-il. « Nous devons arrêter de payer inconsidérément aux grands services de numérisation, car le goulot d’étranglement a toujours été la réparation et l’application de correctifs. »

Il ajoute : « Par conséquent, construire un système dans lequel nous faisons confiance aux correctifs autonomes est ce que nous devons faire dès maintenant, dans l’immédiat, et à plus long terme, dans nos plans, nous devons comprendre que nous ne pourrons pas compter sur les correctifs.