Alon Noy, PDG et cofondateur d’Astelia – Série d’entretiens

Alon Noy, PDG et cofondateur d’Astelia, est un spécialiste de la cybersécurité qui possède plus de 15 ans d’expérience dans la sécurité offensive et défensive. Il a auparavant servi au sein de l’unité 8200 israélienne, puis dirigé l’équipe rouge nationale israélienne de cybersécurité. À ce poste, il a notamment éprouvé la résistance d’infrastructures critiques et collaboré avec des équipes de sécurité pour repérer et corriger des modes opératoires d’attaque observés dans des conditions réelles. Noy a également dirigé de grandes organisations de recherche et développement. Diplômé du programme Talpiot israélien, il est titulaire d’un master en informatique de l’université de Tel Aviv. Son expérience des points de vue de l’attaquant comme du défenseur a contribué à définir l’approche d’Astelia, qui consiste à déterminer quelles vulnérabilités sont réellement accessibles et exploitables dans l’environnement d’une organisation.

Astelia est une entreprise de cybersécurité native de l’IA, spécialisée dans la gestion de l’exposition et des vulnérabilités. Fondée par des vétérans et d’anciens responsables de l’équipe rouge nationale israélienne, l’entreprise s’appuie sur l’IA et sur l’analyse propre à chaque réseau pour déterminer quelles vulnérabilités constituent de véritables voies d’attaque, au lieu de se fier principalement à des scores de gravité génériques. Sa plateforme cartographie l’environnement d’une organisation à l’aide d’intégrations en lecture seule, analyse les conditions nécessaires à l’exploitation au regard de la topologie du réseau et aide les équipes de sécurité à hiérarchiser les vulnérabilités dont l’accessibilité est avérée, tout en recensant les mesures correctives possibles : correctifs, changements de configuration, segmentation ou mesures de compensation. Plus largement, l’entreprise vise à aider les organisations à réduire le volume d’alertes de vulnérabilité qu’elles doivent examiner et à concentrer leurs ressources sur les expositions que des attaquants pourraient réellement exploiter.

Avant de fonder Astelia, vous avez passé plus de dix ans dans les services de sécurité nationale israéliens, notamment au sein de l’unité 8200, et dirigé l’équipe rouge nationale israélienne de cybersécurité, où vous deviez penser et agir comme un attaquant. Que vous ont appris ces expériences sur le déroulement réel des attaques sophistiquées, et quelle lacune du marché de la cybersécurité vous a finalement conduit à cofonder Astelia ?

Pendant plus de dix ans, mon travail consistait essentiellement à penser comme la personne qui cherche à s’introduire dans un système, et non comme celle qui tente de l’en empêcher. La leçon la plus claire que j’en ai tirée, c’est que les attaques sophistiquées reposent presque jamais sur une seule faille spectaculaire. Elles résultent généralement de deux ou trois petites choses que personne ne jugeait importantes isolément : un compte qui n’a jamais été désactivé, une partie du réseau qui était censée être isolée mais ne l’était pas, une autorisation plus large que nécessaire, et ainsi de suite. Lorsque je dirigeais l’équipe rouge nationale, nous consacrions bien plus de temps à comprendre le fonctionnement réel du réseau ciblé qu’à élaborer l’exploit lui-même. Une fois les voies d’accès repérées, les exploiter est presque la partie la plus facile. Quand je suis passé du côté de la défense, j’ai commencé à remarquer un phénomène récurrent. Il existait une longue liste de vulnérabilités qualifiées de « critiques », sans aucun moyen concret de savoir lesquelles un attaquant pouvait réellement atteindre. C’est cette lacune qu’Astelia a été créée pour combler : mettre l’analyse de l’accessibilité, le processus dont les attaquants se servent pour trouver un moyen d’entrer, au service des défenseurs.

Astelia adopte une approche différente de la gestion des vulnérabilités : elle cartographie la topologie réelle du réseau d’une organisation et utilise une IA agentique pour déterminer quelles vulnérabilités sont véritablement accessibles et exploitables. Comment cela fonctionne-t-il concrètement, et pourquoi estimez-vous que les méthodes traditionnelles d’évaluation des vulnérabilités conduisent souvent les défenseurs à mal définir leurs priorités ?

Nous cartographions le réseau réel d’une organisation — la façon dont les systèmes sont effectivement connectés entre eux et les endroits où les contrôles réseau en place font déjà obstacle à un attaquant — au moyen d’intégrations en lecture seule. Une fois cette vue d’ensemble établie, l’IA examine chaque vulnérabilité et détermine ce qu’exigerait concrètement son exploitation : les accès nécessaires, le parcours à travers le réseau et les conditions qui devraient être réunies. Elle confronte ensuite tous ces éléments à la topologie réelle et aux contrôles existants. Parmi les vulnérabilités signalées par un outil d’analyse, moins de 1 % se révèlent généralement réellement accessibles. Le CVSS et l’EPSS se heurtent tous deux au même problème fondamental : ils évaluent une vulnérabilité comme si tous les réseaux étaient identiques, comme si le système était exposé sur l’Internet public ou comme si les tendances d’exploitation observées dans l’ensemble du secteur indiquaient quoi que ce soit sur votre environnement précis. Dans la plupart des environnements, aucune de ces hypothèses ne tient. Une faille jugée critique, située à trois sauts derrière un réseau segmenté, ne présente pas le même risque qu’une faille sur un serveur accessible depuis Internet. De même, une vulnérabilité dont le score EPSS est élevé à l’échelle du secteur peut être totalement inaccessible sur votre réseau. Ces scores sont figés à un instant donné et ne tiennent pas compte de votre réseau. Or, l’accessibilité évolue constamment, car les réseaux et les contrôles qui les protègent évoluent eux aussi.

Vous avez affirmé qu’une grande partie des risques qui préoccupent les défenseurs n’a rien à voir avec la façon dont les véritables attaquants opèrent. D’après votre expérience des attaques autorisées menées contre des environnements hautement sécurisés, quelles erreurs les équipes de sécurité commettent-elles le plus souvent lorsqu’elles cherchent à comprendre comment les attaquants repèrent des faiblesses et les combinent ?

On croit souvent que les attaquants s’en prennent aux vulnérabilités jugées les plus graves. En pratique, c’est rarement le cas. Nous ciblons ce qui nous rapproche le plus rapidement de notre objectif, et il s’agit souvent d’un élément que l’outil d’analyse a classé comme présentant un risque moyen ou faible : un partage de fichiers dont les autorisations sont mal configurées, des identifiants qui subsistent après la fermeture supposée d’un projet, ou un petit point d’appui qui ne devient dangereux qu’une fois combiné à un autre élément que personne ne pensait lié. Les outils d’analyse évaluent les problèmes séparément. Les attaques ne fonctionnent pas ainsi : un attaquant cherche toujours à comprendre comment les éléments s’articulent. Un élément qui paraît inoffensif à lui seul peut être exactement ce dont un attaquant a besoin pour passer d’un compte aux privilèges limités au contrôle total. La plupart des équipes de défense évaluent encore les risques un problème à la fois, et c’est pourquoi elles continuent de passer à côté des chemins d’attaque qui comptent vraiment.

L’IA réduit considérablement le temps et l’expertise nécessaires pour transformer des vulnérabilités nouvellement divulguées en exploits fonctionnels. Quel effet cela a-t-il sur l’économie des cyberattaques, et quels types d’attaquants ont le plus à gagner de modèles d’IA toujours plus performants ?

La partie coûteuse de la création d’un exploit était autrefois l’expertise nécessaire : trouver le bogue, déterminer précisément comment le déclencher et rendre l’exploit fiable. Ce qui prenait souvent des mois à une équipe d’experts peut désormais ne prendre que quelques heures à un attaquant ordinaire qui a accès aux modèles d’IA les plus avancés. Cela change réellement la donne sur le plan économique. L’exploitation d’une nouvelle CVE à des fins offensives exigeait auparavant un véritable investissement ; aujourd’hui, à peine, et le délai entre la divulgation d’une vulnérabilité et l’existence d’un exploit fonctionnel ne cesse de se réduire. La plupart des cycles de mise à jour n’ont jamais été conçus pour suivre un tel rythme. Les attaquants qui en tirent le plus grand avantage ne sont pas les acteurs étatiques de premier plan, qui disposaient déjà de solides capacités offensives. Ce sont plutôt les petits groupes et les cybercriminels opportunistes qui n’avaient pas cette expertise en interne : l’IA la leur fournit de fait.

L’initiative GOLD EAGLE de la Maison-Blanche repose sur une coopération plus étroite entre les pouvoirs publics, les entreprises technologiques et les opérateurs d’infrastructures critiques, l’IA de pointe servant à repérer et à corriger les vulnérabilités plus rapidement. Du point de vue d’un attaquant, quels sont les points forts de ce modèle et quelles sont ses limites ?

GOLD EAGLE a raison de souligner le temps perdu en efforts redondants : différentes organisations analysent et évaluent séparément la même vulnérabilité divulguée avant que quiconque n’agisse réellement. Centraliser ces efforts et recourir à l’IA pour accélérer la coordination entre les pouvoirs publics et les opérateurs d’infrastructures réduit véritablement le temps dont dispose un attaquant, et c’est là, de son point de vue, l’essentiel. Dans ce domaine, la vitesse est primordiale. À mon avis, le modèle montre toutefois ses limites : une coordination à l’échelle du secteur ne permet pas à une entreprise donnée de savoir si une vulnérabilité précise est accessible depuis son propre réseau. Une organisation peut disposer d’un flux de renseignements sur les menaces bien hiérarchisé sans savoir pour autant si ces informations la concernent. Cette dernière étape, qui consiste à vérifier les vulnérabilités au regard de sa propre topologie réseau, reste de la responsabilité de chaque organisation.

Plus de 100 organisations des secteurs des technologies, de la cybersécurité, de la finance et des infrastructures ont averti que le temps pourrait être compté pour renforcer les défenses avant que les attaques rendues possibles par l’IA ne se généralisent nettement. Partagez-vous ce sentiment d’urgence, et que devraient raisonnablement accomplir les organisations pendant cette « fenêtre de protection » ?

Je partage ce sentiment d’urgence, même si j’en expliquerais la raison un peu différemment. Les attaques rendues possibles par l’IA ne sont pas une menace future : le délai entre la divulgation d’une vulnérabilité et l’existence d’un exploit fonctionnel se réduit déjà plus vite que la plupart des organisations ne peuvent appliquer des correctifs. Il n’est pas réaliste d’espérer remporter cette course en appliquant simplement les correctifs plus vite. En revanche, il est réaliste de profiter de cette période pour mieux comprendre son propre environnement. Cela signifie connaître la topologie réelle du réseau, savoir quelles vulnérabilités sont véritablement accessibles et concentrer les efforts sur cet ensemble plus restreint, au lieu de les disperser sur des milliers de problèmes théoriques. Il vaut également la peine de profiter de cette période pour développer des solutions de remédiation autres que l’application de correctifs, par exemple la segmentation ou des changements de configuration, car la seule rapidité d’application des correctifs ne permettra pas de suivre le rythme du développement d’exploits accéléré par l’IA.

La défense collective contre les cybermenaces repose largement sur le partage, entre organisations, de renseignements sur les vulnérabilités et les menaces. Quels changements techniques ou culturels sont nécessaires pour que les gouvernements et les entreprises privées puissent partager assez rapidement des informations utiles pour qu’elles aient un réel impact, sans créer de nouveaux risques de sécurité au passage ?

Le défi technique est le plus facile à résoudre. Le problème le plus difficile est celui de la confiance. Aucune organisation ne souhaite divulguer une faille dans son propre environnement et risquer qu’elle lui soit attribuée, surtout si elle est ensuite mentionnée dans un rapport sur une violation de données. La solution consiste à partager des informations utiles sans qu’elles permettent d’identifier leur source : le mode d’exploitation possible d’une faille, plutôt qu’une description assez précise pour désigner une entreprise. Cela exige une meilleure infrastructure et des données sur les menaces lisibles par machine, transmises par des canaux automatisés plutôt que par des PDF et des listes de diffusion. Mais l’infrastructure n’a jamais vraiment été le principal obstacle. Pour la plupart des organisations, le partage reste associé à un risque juridique plutôt qu’à une mesure de protection. La mise à disposition d’un intermédiaire neutre et digne de confiance fait partie des objectifs de GOLD EAGLE et pourrait contribuer largement à changer les choses.

Astelia met l’accent sur l’« accessibilité » plutôt que sur la seule gravité ou l’existence d’un exploit connu. À mesure que l’IA accélère la création d’exploits et la rend potentiellement plus courante, l’accessibilité devient-elle un indicateur de risque plus important, et comment les RSSI devraient-ils repenser la hiérarchisation des vulnérabilités à partir de ce concept ?

L’accessibilité ne prend pas seulement de l’importance : elle devient la mesure déterminante. La gravité a toujours été une approximation des dommages qu’un problème pouvait causer ; l’accessibilité indique s’il peut être exploité dans votre environnement à l’heure actuelle. Les défenseurs estimaient que la plupart des vulnérabilités de faible gravité pouvaient rester sans correctif pendant des mois, car personne ne chercherait raisonnablement à les exploiter. Cette hypothèse ne tient plus dès lors que la création d’exploits est rapide et peu coûteuse. Il faut passer d’un arriéré classé par gravité à l’élimination des expositions réellement accessibles. Ce qui distingue le petit nombre de vulnérabilités qui comptent de toutes les autres, c’est la possibilité pour un attaquant de les atteindre compte tenu de votre réseau réel. Les RSSI devraient demander des preuves d’accessibilité, plutôt qu’un score supplémentaire venant s’ajouter au CVSS.

Astelia fait également appel à des agents d’IA à différentes étapes du cycle de vie des vulnérabilités, de la détection de nouvelles expositions à la coordination des mesures correctives. Dans quelle mesure les agents de cybersécurité devraient-ils être autonomes à terme lorsqu’ils sont capables de modifier des environnements de production, et à quelles étapes les humains devraient-ils absolument rester dans la boucle ?

Les agents devraient disposer d’une réelle autonomie pour l’analyse : cartographier le réseau, déterminer les conditions nécessaires à l’exploitation, établir des liens entre les nouvelles divulgations et faire ressortir les éléments accessibles. C’est là que la rapidité compte le plus ; une erreur ne produit qu’une mauvaise recommandation qu’un humain peut repérer. Je fixe une limite claire aux modifications de la production sans supervision. Sans données sur l’accessibilité du réseau, un agent qui applique un correctif ne fait que deviner, et une mauvaise règle de pare-feu ou une modification erronée de la segmentation peut causer plus de dégâts que la vulnérabilité qu’elle était censée corriger. C’est aussi pourquoi la plupart des solutions aujourd’hui présentées comme de la « remédiation autonome » se limitent en réalité à créer automatiquement des tickets. Les entreprises veulent qu’un humain approuve ce type de modification, d’autant qu’un correctif n’est pas toujours disponible au départ. Le bon modèle consiste à laisser les agents proposer des correctifs étayés par des preuves, qu’une personne valide avant toute intervention sur la production. Cette exigence s’assouplira à mesure que les données sur l’accessibilité gagneront en maturité et que la confiance s’installera dans des catégories de modifications plus restreintes et bien testées, mais je ne commencerais pas par des interventions non supervisées en production.

À l’avenir, alors que les attaquants comme les défenseurs auront accès à des systèmes d’IA autonomes toujours plus performants, comment pensez-vous que l’équilibre entre cybersécurité offensive et défensive va évoluer ? Et qu’est-ce qui distinguera les organisations prêtes à entrer dans cette nouvelle phase de celles qui ne le sont pas ?

Les attaquants conservent une longueur d’avance au début avec l’IA, car ils n’ont besoin que d’une seule méthode qui fonctionne, et l’IA est particulièrement efficace pour la trouver rapidement : la reconnaissance s’accélère, le développement d’exploits aussi, et les contenus d’hameçonnage deviennent plus convaincants. Les défenseurs ne combleront pas cet écart en utilisant l’IA pour faire les mêmes choses plus rapidement. Ils le combleront en se servant de l’IA pour découvrir et éliminer les vulnérabilités réellement accessibles dans leur propre réseau, en fonction de leur contexte, au lieu de gérer les risques à partir de données génériques sur les menaces à l’échelle du secteur. Ce qui distinguera les organisations préparées, c’est d’avoir opéré ce changement avant d’y être contraintes et de pouvoir indiquer, preuves à l’appui, quelles vulnérabilités sont réellement exploitables dans leur environnement, plutôt que d’espérer que leur calendrier de correctifs suffise. Les organisations qui continuent de gérer les risques dans un contexte générique continueront d’être prises au dépourvu par une vulnérabilité que leur propre outil d’analyse avait jugée peu prioritaire un an plus tôt.

Merci pour cet excellent entretien. Les lecteurs qui souhaitent en savoir plus peuvent consulter Astelia.