Simon Edwards, PDG et fondateur de SE Labs – Série d’interviews

Simon Edwards, PDG et fondateur de SE Labs, est un expert en tests de cybersécurité avec plus de trois décennies d’expérience couvrant la recherche en sécurité, l’évaluation de produits, le journalisme technique et les normes de l’industrie. Avant de fonder SE Labs en 2015, Edwards dirigeait Dennis Technology Labs, où il a dirigé des initiatives de tests de sécurité, et a auparavant passé de nombreuses années en tant que journaliste et rédacteur technologique. Il a également occupé des postes de direction au sein de l’Anti-Malware Testing Standards Organization (AMTSO), notamment en tant que président, directeur et coprésident. Edwards teste des produits de sécurité depuis le milieu des années 1990 et a été pionnier des premières approches de tests anti‑malware réalistes, conçues pour évaluer la performance des technologies de sécurité face à des attaques complètes, diffusées via Internet, plutôt qu’à des échantillons de logiciels malveillants isolés.

SE Labs est une société indépendante de tests et de conseil en cybersécurité qui évalue la performance des technologies de sécurité face à des attaques réalistes. Ses chercheurs reproduisent les techniques des attaquants tout au long de la chaîne d’attaque afin d’évaluer des produits tels que la protection des points de terminaison, la détection et réponse sur les points de terminaison (EDR), les services de sécurité cloud, les pare-feu, la sécurité des courriels et les technologies de détection réseau. En plus des tests comparatifs publics, SE Labs propose des certifications, des tests de sécurité avancés, la validation de produits et des services de conseil pour les entreprises et les fournisseurs de cybersécurité. L’entreprise publie ses méthodologies de test et ses cadres d’émulation de menaces et est certifiée ISO/IEC 27001:2022 et BS EN ISO 9001:2015 pour la prestation de tests de produits de sécurité informatique.

Votre carrière s’étend sur plus de trois décennies dans le journalisme technologique, le conseil en sécurité, les tests indépendants et les fonctions de direction au sein de l’Anti-Malware Testing Standards Organization (AMTSO). Comment cette expérience a‑t‑elle influencé votre manière de distinguer les véritables avancées en cybersécurité alimentée par l’IA des technologies qui sont principalement présentées comme « IA » à des fins marketing ?

Le journalisme m’a appris à remettre en question les affirmations, tandis que les tests indépendants m’ont montré que la seule réponse fiable provient des preuves. Les entreprises de cybersécurité utilisent l’apprentissage automatique et la prise de décision automatisée depuis de nombreuses années, ainsi ajouter « IA » au nom d’un produit ne représente pas nécessairement une avancée technique.

Trois points fondamentaux à considérer : Que fait réellement l’IA ? Quelle amélioration mesurable de la sécurité apporte‑t‑elle ? Et un testeur indépendant peut‑il reproduire cette amélioration ?

Si la réponse se limite à dire que le produit analyse une grande quantité de données ou automatise un processus existant, le label IA peut davantage relever du positionnement que d’une réelle capacité.

Une véritable avancée fonctionne efficacement contre des attaques inconnues ou toute nouvelles, améliore la protection ou la réponse, réduit la charge des analystes, et le fait sans introduire de risques inacceptables. Tout le reste constitue soit une absence d’amélioration, soit une régression !

« AI‑driven » est devenu une affirmation courante parmi les produits de cybersécurité. Quelles sont les capacités les plus importantes qui devraient être testées de manière indépendante avant qu’une organisation n’accepte qu’une plateforme de sécurité alimentée par l’IA délivre réellement ce que le fournisseur promet ?

Je ne commencerais pas par tester si un produit contient de l’IA. Je commencerais par vérifier les affirmations de sécurité qui sont faites à son sujet. Peu importe pour moi le fonctionnement du produit, tant qu’il fonctionne. C’est exactement l’objectif du programme de test PIVOT, qui gagne actuellement beaucoup d’adhésion dans l’industrie.

Tester de cette manière consiste à exposer le produit à des attaques complètes et à mesurer comment il réagit. Il devrait probablement détecter l’activité, puis éventuellement empêcher la progression de l’attaque. Cela dépend de la façon dont le produit est construit et configuré, ainsi que des affirmations marketing avancées par son fournisseur.

Nous devons également examiner le récit d’enquête présenté au client. Le système a‑t‑il compris ce qui s’est passé, relié les événements pertinents et rendu les preuves visibles à la personne qui doit agir ?

Le test doit inclure des variantes inconnues, des configurations client réalistes et des activités commerciales normales. Il doit également mesurer les faux positifs, les exigences en ressources et les actions pouvant être potentiellement dangereuses. Si le système est autonome, nous devons savoir quand il agit, pourquoi il agit, quelles autorisations il utilise et si ses décisions peuvent être annulées.

Nous avons vu quelques articles dans les médias relatant des cas où la sécurité IA se comporte de manière incontrôlée, dépasse ses limites et potentiellement la loi. La question importante n’est pas de savoir si la plateforme semble intelligente, mais si elle produit des résultats de sécurité constamment meilleurs et plus sûrs.

Les agents IA autonomes peuvent potentiellement exécuter la reconnaissance, l’exploitation, le déplacement latéral et d’autres étapes d’une attaque bien plus rapidement qu’un attaquant humain. Comment les tests de cybersécurité doivent‑ils évoluer lorsque les attaques commencent à opérer à la vitesse d’une machine ?

L’unité de test doit passer de la technique individuelle à la campagne complète opérant sous contrainte de temps. Par là, je veux dire que, plutôt que d’essayer différentes méthodes d’attaque sur une matinée ou une semaine, les tests de certaines mesures de sécurité doivent être réalisés rapidement. Sinon, ce n’est pas réaliste, et le réalisme est très important.

Les tests traditionnels peuvent laisser des intervalles pratiques entre les étapes afin que chaque événement puisse être examiné séparément. Un attaquant autonome peut condenser la reconnaissance, l’exploitation et le déplacement latéral en une période beaucoup plus courte. Cela pourrait révéler des faiblesses invisibles lors de tests plus lents, notamment des retards dans la télémétrie, des systèmes surchargés et des actions défensives qui n’arrivent qu’après que l’attaque a atteint son objectif.

Pour vous donner un exemple extrêmement simple, si nous piratons un Mac, téléchargeons tous ses fichiers et volons les mots de passe des comptes, cela ne sert à rien si l’antivirus apparaît un jour plus tard avec la mauvaise nouvelle.

Tester les réponses de sécurité face à des attaquants IA nécessite donc une instrumentation à haute résolution et une mesure précise de la latence de détection et de réponse. Il faut vérifier si les performances se détériorent à mesure que le volume et la vitesse des activités augmentent, et si la défense peut interrompre une attaque sans attendre une décision humaine à chaque étape.

L’attaque peut également s’adapter à ce qu’elle découvre. Les tests doivent refléter cela tout en préservant la vérité de base, les preuves et la possibilité de rejouer les scénarios. La vitesse des machines ne doit pas conduire à abandonner une méthodologie contrôlée. Nous devons continuer à concevoir des tests contrôlés capables de fonctionner et de mesurer les événements à la même vitesse que les systèmes évalués.

SE Labs utilise des scénarios d’attaque réalistes basés sur les tactiques et techniques de groupes de menace tels que Scattered Spider. Comment recréez‑vous ces adversaires dans un environnement contrôlé tout en veillant à ce que le test reflète la façon dont une vraie attaque se déroulerait plutôt que de simplement tester contre une liste de contrôle prédéfinie ?

Nous commençons par les objectifs de l’adversaire, ses comportements connus et ses prises de décision probables, plutôt que de traiter ses techniques comme une simple liste d’achats.

Le test suit une chaîne d’attaque réaliste à travers la reconnaissance, l’accès initial, l’exécution, l’escalade de privilèges, les activités post‑compromission et le déplacement latéral. Il est important que le testeur n’utilise que les informations réellement découvertes lors de la reconnaissance et de l’attaque. Nous ne donnons pas à l’attaquant des connaissances qui ne seraient pas disponibles dans un vrai engagement.

Le scénario est limité et soigneusement contrôlé, mais il ne s’agit pas simplement d’une séquence de pressions de boutons prédéterminées. Si une voie est bloquée, l’attaquant peut poursuivre une alternative crédible dans le cadre des règles du test. Cela permet au produit de sécurité d’influencer la façon dont le scénario se déroule.

En même temps, chaque action et résultat important sont enregistrés afin que nous puissions expliquer le résultat et comparer les produits de manière équitable. Contrôlé ne signifie pas forcément rigide. Il doit signifier sûr, observable et étayé par des preuves.

Les produits de cybersécurité ont traditionnellement été évalués principalement sur leur capacité à détecter les menaces. Pourquoi les organisations devraient‑elles de plus en plus se pencher sur la protection, le confinement et la réponse aux incidents lorsqu’elles évaluent des systèmes de sécurité pilotés par l’IA ?

La détection n’est pas synonyme de défense. Une plateforme peut générer une alerte précise tout en permettant à l’attaquant d’atteindre son objectif. C’est pourquoi le programme de test PIVOT inclut à la fois la détection et la protection comme parties conjointes et séparées du test global.

Vous pouvez comparer la détection en cybersécurité à une caméra de vidéosurveillance. Elle doit remarquer une intrusion et vous fournir des indices sur ce qui s’est passé, mais elle n’arrêtera pas physiquement l’intrus. La protection en cybersécurité est beaucoup plus active. Elle peut expulser ou neutraliser un attaquant, empêchant ainsi les dommages.

Les organisations doivent savoir si le produit a empêché l’activité initiale, interrompu la chaîne d’attaque, limité le déplacement latéral, protégé les actifs importants et soutenu la récupération. Si une attaque réussit, les questions suivantes portent sur la rapidité avec laquelle elle a été contenue et si le client a reçu suffisamment d’informations fiables pour répondre efficacement.

Cela devient particulièrement important avec les systèmes pilotés par l’IA car, bien qu’ils puissent produire des résumés très convaincants de ce qui s’est passé, une explication persuasive ne remplace pas la protection. L’explication doit être étayée par des preuves et conduire à une action appropriée.

Nous mesurons donc la détection et la protection séparément. Nous examinons également si la détection annoncée était réellement visible et utile pour le client. En fin de compte, la valeur d’un système de sécurité réside dans la capacité à changer le résultat d’une attaque, pas seulement à l’observer.

À mesure que les plateformes de sécurité introduisent des agents autonomes capables d’enquêter sur les alertes et de prendre des mesures de remédiation, comment les laboratoires indépendants doivent‑ils tester l’ensemble du flux de travail humain‑et‑IA plutôt que d’évaluer la technologie de détection sous‑jacente isolément ?

Le test doit suivre l’ensemble du processus depuis la première activité malveillante jusqu’au résultat final de sécurité, qui peut être l’arrêt complet de l’attaque ou sa réussite totale – ou quelque part entre les deux.

Nous devons examiner ce que l’agent a observé, ce qu’il a conclu, ce qu’il a recommandé ou fait, ce qui a été présenté à l’opérateur humain et comment ce dernier a réagi (ou quelles options lui ont été proposées). Cela inclut la qualité des preuves, la clarté du transfert, le temps requis, le nombre d’interventions et la capacité de l’humain à comprendre, contester ou inverser la décision de l’agent.

Différents modes de fonctionnement comptent également. Un agent qui recommande une action pour approbation présente un risque différent de celui qui peut isoler automatiquement les systèmes, désactiver des comptes ou modifier les contrôles de sécurité.

Un système n’a pas réussi simplement parce que son détecteur sous‑jacent a identifié l’attaque. S’il crée une file d’attente incompréhensible, masque des preuves importantes, recommande une mauvaise réponse ou entreprend une action perturbatrice, le flux de travail global a échoué. Les tests indépendants doivent mesurer la performance combinée de la technologie, de ses composants autonomes et des personnes censées les utiliser.

Un risque lié aux référentiels de sécurité standardisés est que les fournisseurs puissent optimiser leurs produits spécifiquement pour le test. Comment les tests indépendants peuvent-ils rester reproductibles et équitables tout en introduisant suffisamment d’imprévisibilité pour révéler la performance des produits face à des attaques inconnues ?

La reproductibilité ne nécessite pas de fournir aux participants les questions de l’examen à l’avance.

Un test crédible doit publier sa méthodologie, son environnement, ses principes de notation, la configuration du produit et les exigences en matière de preuves. Les fournisseurs doivent comprendre les règles et disposer d’une opportunité équitable de vérifier que leurs produits fonctionnent correctement. Cependant, la campagne d’attaque précise, les charges utiles et certaines des trajectoires d’attaque doivent rester inconnues jusqu’à la réalisation du test.

Par exemple, dans PIVOT nous ne divulguons pas quels groupes d’attaque nous allons reproduire avant la fin des tests. Les cibles réelles ne sont pas prévenues avant le lancement d’une attaque !

Nous pouvons combiner un noyau standard, qui permet la comparaison dans le temps, avec des variantes inconnues qui testent la capacité générale. L’établissement d’une ligne de base et d’une période silencieuse cachée peut montrer comment le produit se comporte avant l’attaque. La configuration doit ensuite être contrôlée, les journaux préservés et toute affirmation vérifiée à l’aide des propres preuves du testeur.

L’équité consiste à appliquer les mêmes règles et les mêmes normes de preuve à chaque participant. Cela ne signifie pas répéter une attaque de façon si prévisible qu’un fournisseur puisse reconnaître le benchmark plutôt que la menace.

De plus, une transparence radicale aide les fournisseurs à reproduire les attaques, ce qui est important s’ils souhaitent corriger les problèmes rencontrés, comme le fait de ne pas détecter ou de ne pas se protéger contre une menace. SE Labs forme essentiellement ses clients lorsqu’ils rencontrent des difficultés.

Les agents de sécurité autonomes introduisent une catégorie de risque différente, car une décision erronée peut déclencher une action de remédiation inutile voire perturbatrice. Comment les tests doivent-ils mesurer les faux positifs, le raisonnement incorrect et les actions autonomes potentiellement nuisibles aux côtés de la précision de détection traditionnelle ?

Les tests traditionnels de faux positifs ne constituent que la première couche. Avec un agent autonome, il faut distinguer entre une alerte fausse, une conclusion non étayée et une action incorrecte. Chacune a un impact potentiel différent.

Les tests doivent exposer le système à une activité légitime qui ressemble à un comportement malveillant, ainsi qu’à des preuves incomplètes, ambiguës ou trompeuses. Si l’agent consomme du contenu non fiable, le test doit également vérifier si ce contenu peut influencer indûment ses décisions.

Le raisonnement doit être jugé à l’aune de la mesure dans laquelle la conclusion est soutenue par les preuves disponibles, et non par la plausibilité ou la confiance que l’explication inspire. Pour les actions autonomes, il faut mesurer l’étendue, la proportionnalité, l’utilisation des permissions, les contrôles d’approbation, l’auditabilité et la réversibilité.

Le score doit refléter les conséquences. Une alerte inutile est gênante ; désactiver un compte important ou isoler un système critique pourrait perturber l’organisation. Une mesure de sécurité utile doit donc prendre en compte à la fois la fréquence des erreurs et le dommage que chaque erreur pourrait causer.

Cela dit, parfois le client choisit une politique qui engendre des problèmes. Ce n’est pas nécessairement la faute du fournisseur de sécurité.

L’IA générative et les modèles open‑source de plus en plus performants abaissent la barrière à l’automatisation de parties du processus d’attaque. Pensez‑vous que l’IA rendra les cyberattaques fondamentalement plus sophistiquées, ou le danger majeur est‑il que les attaquants puissent simplement opérer à une échelle et une vitesse nettement supérieures ?

Mon attente est que le danger le plus immédiat soit l’échelle, la vitesse et la réduction des coûts.

L’IA peut aider les attaquants à collecter des informations, à personnaliser l’ingénierie sociale, à modifier du code et à coordonner des parties d’une campagne. Certaines attaques deviendront plus sophistiquées grâce à l’IA, notamment lorsqu’elle aide à combiner des techniques existantes ou à les adapter à une cible précise. Mais l’IA ne supprime pas le besoin d’accès, d’identifiants, de vulnérabilités exploitables ou d’erreurs de la part des défenseurs.

L’IA n’est pas très efficace pour produire des exploits fiables, ce qui est déjà très difficile à réaliser pour un humain qualifié. Cela réduit donc, à mon avis, la probabilité d’attaques fondamentalement plus sophistiquées.

Le changement majeur réside dans le fait que des activités qui nécessitaient auparavant du temps, des compétences ou une équipe peuvent être tentées plus rapidement et sur beaucoup plus de cibles. L’IA peut élever la compétence d’attaquants relativement ordinaires tout en permettant aux attaquants capables de mener davantage d’opérations simultanément.

C’est significatif même si les techniques d’attaque sous-jacentes ne sont pas révolutionnaires. Le danger n’est pas forcément une forme totalement nouvelle de cyberattaque. Il s’agit d’attaques familières qui deviennent plus rapides, moins chères, plus personnalisées et beaucoup plus nombreuses.

À mesure que les agents d’IA défensifs et offensifs gagnent en autonomie, à quoi devra ressembler un environnement de test de cybersécurité crédible pour suivre le rythme ? Pourrions‑nous éventuellement arriver à un point où les produits de sécurité devront être continuellement mis au défi par des adversaires IA adaptatifs plutôt qu’évalués principalement à travers des tests de sécurité périodiques ?

Un environnement crédible devra ressembler à une organisation vivante plutôt qu’à un ensemble de cibles isolées. Il doit inclure les points de terminaison, les systèmes d’identité, le courrier électronique, les réseaux, les services cloud, des utilisateurs réalistes et une activité commerciale normale. Il doit également fournir une instrumentation complète afin que chaque décision et chaque conséquence puissent être reconstituées.

Des adversaires adaptatifs pourraient recevoir des objectifs et des limites, puis être autorisés à choisir leurs trajectoires en fonction de leurs découvertes et de la manière dont le produit défensif réagit. Le test aurait toujours besoin de conditions de départ contrôlées, d’une description fiable de ce qui s’est réellement passé et de la capacité de rejouer les événements importants. Sans ces éléments, les tests adaptatifs pourraient sembler impressionnants mais rester scientifiquement faibles.

Je m’attends à ce que les tests deviennent plus continus, notamment lorsque les produits, modèles et politiques peuvent changer fréquemment. Cependant, le défi continu doit compléter plutôt qu’éliminer les tests comparatifs périodiques. Les organisations ont besoin des deux : des références contrôlées comme PIVOT qui assurent la responsabilité et la comparaison, et une évaluation adaptative continue qui révèle comment les systèmes se comportent à mesure que les menaces et les produits eux‑mêmes évoluent.

Je pense que nous devrions nous inquiéter davantage du fait que des humains relativement peu qualifiés peuvent pénétrer les systèmes et les réseaux, plutôt que des robots créant la prochaine génération de technologies d’attaque cybernétique.

Merci pour cette excellente interview, les lecteurs qui souhaitent en savoir plus devraient visiter SE Labs.