 Vincenzo Iso est un entrepreneur et il se spécialise en sécurité informatique. Il a commencé une start-up Gottenbord et il a fait d'autres controverses après, et maintenant il est advisor, conseiller de différentes entreprises. Il est fini par s'ennuyer et il recommence dans une autre entreprise. Il est également associé du MIT Media Lab. Cette présentation est le curious case of scale in cyber security. Les économies d'échelle et leurs effets intéressants en sécurité informatique. Applaudissements pour Vincenzo. Bonjour à tous, merci d'être venu. Comme l'a dit Karen, j'ai eu une carrière un petit peu variée, mais je viens à la base du monde technique. Et ce que je veux faire aujourd'hui, c'est parler de quelque chose qu'on ne remarque pas forcément, mais qui est pourtant peut-être un peu trop évident, mais que je pense qu'il faut prendre le temps de remarquer. Et c'est la sécurité informatique et les effets de la grande échelle et du cloud. Ce que je veux dire par là, c'est qu'on a maintenant la capacité de transformer, d'acquérir et de faire des calculs sur de larges quantités de données très facilement. Et ça a joué un rôle extrêmement important sur la façon dont l'industrie a évolué dans la dernière décennie. Donc avant, je vais donner un petit peu de contexte, parce que je pense que c'est important. Ça fait à peu près 15 ans que je suis dans l'industrie de l'informatique. Et à l'époque, même des endroits comme le congrès américain, c'était beaucoup plus petit, c'était plus facile de rencontrer tout le monde. Mais quelque chose s'est passé vers 2010 à peu près. Les gens se sont rendus compte qu'il y avait de plus en plus d'attaques par des acteurs d'État, des attaques contre aussi des entreprises qui ont énormément donné, comme Google. On a commencé à entendre parler des APT. On a appris que l'armée chinoise attaquait des infrastructures et volait des plages d'IP. Et ça a changé beaucoup de choses pour l'industrie de l'informatique à l'échelle mondiale. Il y a eu deux changements principaux à mon sens à cause de tout ça. Le premier, c'est la notoriété. On est passé d'une industrie qui n'était pas très connue dans la sécurité informatique à quelque chose dont tout le monde parle. Si on ouvre un journal, il y a quasiment toujours un article sur la sécurité informatique. On en parle dans les conseils d'entreprise. Tout le monde en parle. Moi, quand je suis arrivé au début, personne n'en parlait vraiment. On parlait de infosec et pas de cybersecurity. Et maintenant, le mot infosec, c'est un mot qui est presque devenu désuet. Alors, la notoriété, c'est quelque chose, mais ce n'est pas tout. Deuxième chose qui a changé, c'est aussi combien d'argent rentre dans le secteur de la cybersecurity. En 2004, ça dépend des estimations qu'on regarde. Mais en 2004, la dépense totale pour la sécurité informatique, c'était environ 3,5 milliards de dollars. Et maintenant, on est à peu près à 120 milliards de dollars par an. Cette dépense, elle est venue avec aussi un changement très important dans le genre de personne qu'on rencontre dans l'industrie de la cybersecurity. À l'époque, on avait plein de petites entreprises qui vendaient de la cybersecurity, mais ceux-là sont plutôt partis. Et maintenant, on a deux types d'entreprises qu'on voit. Il y a les grosses entreprises de cloud, Amazon, Google, etc. qui ont décidé de prendre la sécurité très au sérieux et qui essayent aussi souvent de monétiser la sécurité ou de s'en servir comme un argument pour vendre peut-être plus de téléphone ou plus de cloud. L'autre groupe de gens et d'entités qu'on trouve, c'est des grosses entreprises qui vendent de la cybersecurity. Et une chose qu'on remarque là-dessus, c'est que ces entreprises utilisent beaucoup plus de cloud ou de ressources à la taille du cloud pour penser ou pour combattre des problématiques de cybersecurity. Ce dont je veux parler ici, c'est des aspects plutôt techniques de comment on approche les problématiques de défense en cybersecurity. Et je veux aussi parler des types de gens qu'on rencontre dans l'industrie aujourd'hui. Donc ce que je veux faire, c'est donner quelques exemples des changements qu'on a vus. Et je pense qu'une des choses importantes à garder à l'esprit, c'est que ce qu'a changé avec l'échelle dans la décennie passée, ça a donné aux défenseurs un net avantage comparé aux attaquants. Ce n'est pas forcément quelque chose qui va rester, mais je pense que c'est un aspect qu'on remarque pas forcément, très important quand on pense à la sécurité et à l'échelle mondiale. Donc on va donner un petit peu de contexte ici. Dans les années 80, on commençait à parler de détection d'instruction et on avait ce papier. Et ça, l'idée c'était d'avoir un modèle de comment une machine fonctionnait. Et si on voyait qu'une machine avait un comportement différent de ce modèle, on pensait qu'il y avait une attaque ou un comportement malicieux. Et ça, c'est le premier papier qui a été publié sur ce sujet. Le problème des IDS comme ça, c'est qu'ils ne sont jamais vraiment marchés sur le plan commercial. Et la raison pour ça, il y a deux raisons pour ça. La première, c'est que c'était vraiment difficile d'interpréter les résultats d'un IDS. C'était vraiment difficile de se dire, tiens, il y a une anomalie et à partir de là, de dire, ah bah c'est pour ça qu'il y a cette anomalie et c'est ça l'incident de sécurité qu'il y avait. Le deuxième problème qu'il y avait, c'est qu'il y avait beaucoup de faux positifs et c'était vraiment difficile d'établir une sorte de baseline pour savoir quel était un comportement normal. Surtout que maintenant les machines font de plus en plus de... Enfin, les machines pourront faire énormément de choses différentes. Donc, ça nous a laissé avec, bah, ce qu'on avait, c'est-à-dire, surtout des antivirus qui se basaient sur des signatures de fichiers. Donc, on va accélérer maintenant un petit peu et on va venir jusqu'en 2013, presque 15 ans, presque 20 ans plus tard, plus de 20 ans plus tard. Et maintenant, on a des entreprises d'antivirus qui ont admis qu'ils n'avaient pas été capables de détecter des choses comme Stucknet ou Flame. Et il y a eu du coup un nouveau type de logiciel qui a été mis en place. On parlait de IDR, Incident Detection Response. Et si on enlève le côté de marketing de tout ça, IDR, c'est juste des IDS à grande échelle. Alors, ce que ça veut dire ici, c'est que la capacité d'avoir du cloud scale dans notre analyse, ça a permis de rendre les IDS possible. Parce que maintenant qu'on a ce qu'on appelle peut-être un Detalake où on a énormément de machines et énormément de données sur ces machines et on peut entraîner des modèles de façon beaucoup précise parce qu'on n'a plus besoin de données, c'est beaucoup plus facile d'établir une baseline pour savoir quand on commence à se comporter une machine et du coup d'établir une détection pas juste de malware, mais aussi d'attaque sans malware. L'autre chose qui s'est passé, c'est que les vendeurs d'EDR et les entreprises qui achètent des IDR, ou qui en utilisent en interne, peuvent aussi faire des économies d'échelle très importantes. On peut avoir une équipe d'analystes qui va établir une forme d'ontologie pour expliquer comment se fonctionne une attaque ou pourquoi certains signaux représentent certaines attaques et maintenant qu'on a un Detalake, on peut exploiter les données dedans pour détecter dans cet océan de données des attaques qu'avant on ne pouvait pas voir parce qu'elles étaient perdues dans le bruit. Donc ce que ça veut dire, c'est que grâce à ça on a pu bouger d'un modèle où on était basé sur des signatures de fichiers à des détections basées sur le comportement et du coup détecter des classes beaucoup plus larges d'attaques. Alors, un effet que ça a eu, c'est par contre que les données doivent maintenant être partagées et si vous êtes dans l'industrie depuis longtemps vous savez sûrement qu'il y a eu beaucoup d'efforts pour partager des données sur les attaques qu'on voyait entre différents acteurs, différentes entreprises et ces échanges n'ont jamais vraiment fonctionné parce qu'il n'y avait pas de protocole, il n'y avait pas de façon d'interagir qui était établie. Et ce qui est possible maintenant avec les EDR, c'est implicitement, on partage ces données, cette trust intelligence, sur comment marche ce partage. C'est-à-dire que maintenant on a des tiers, ce parti qui peuvent utiliser ces données pour déterminer comment les attaques se passent chez vous et chez eux. Donc, un des résultats pour ça, c'est qu'avant on disait un attaqueur doit juste avoir raison une fois. C'est plus vraiment vrai parce que maintenant, par le passé, on avait une situation où si on avait une infrastructure offensive, que ce soit des serveurs ou une chaine d'exploit, on pouvait en général les réutiliser beaucoup de fois. Même si c'était du malware, tout ce qu'on avait à faire c'était le modifier légèrement pour échapper à la détection de signature et on pouvait ensuite le réutiliser facilement. Mais maintenant, c'est plus le cas puisque si vous êtes détecté sur une machine quelque part, d'un seul coup, toute votre infrastructure offensive doit être remise à zéro et on doit recommencer. Alors, ça c'est le premier exemple et je pense que juste ça, c'est déjà très important à noter. La deuxième chose dont je veux parler, c'est le fuzzing. Le fuzzing, c'est très important pour une autre raison. Le fuzzing nous donne une idée de ce à quoi ressemblera le futur en sécurité. Si vous avez fait un peu de sécurité applicative par le passé, le fuzzing, c'est quelque chose de très important dans ce monde-là, le monde de la sécurité applicative. Mais dans les cinq dernières années environ, le fuzzing a eu vraiment une forme de renaissance et il y a deux choses qui ont changé et qui se sont améliorées récemment. La première, c'est qu'on a enfin trouvé une façon de déterminer si les fonctions qu'on utilise pour guider le fuzzing étaient bien adaptées ou pas. Vous avez peut-être entendu parlé du fuzzer qui s'appelle AFL, Américaine Fuzilope. Une des premières choses importantes de AFL, c'est que le fuzzer n'était pas piloté par une couverture de code et était conduit par une couverture de chemin, de chemin d'exécution dans le programme. Et ça, c'est beaucoup plus efficace. Ça permettait d'instrumenter le code et de trouver les bugs de façon beaucoup plus efficace. La deuxième chose qui est encore plus importante et qui a changé le fuzzing de façon vraiment très importante aussi, c'est pour le fuzzing c'est important d'être rapide. C'est plus important d'être rapide que d'être intelligent. Ce que je veux dire par là, c'est que si on garde AFL, c'est une façon de faire du fuzzing qui est très bête, ça inverse des bits ou ça modifie un octet, ça a des stratégies vraiment très simples pour les mutations. Mais ce qui est bien avec AFL, c'est que c'est extrêmement optimisé et que ça bénéficie très bien de l'échelle. Donc si vous avez un très bon serveur avec beaucoup de corps et que vous faites tourner AFL dessus, vous pouvez synthétiser des formes à fichiers vraiment très compliquées en peu d'itération. Et ce qui est intéressant, c'est que cette intuition ne s'applique pas juste au format de fichiers. Ça marche aussi pour des machines à état beaucoup plus compliquées. Par exemple, un type de fuzzing qu'on a vu, c'est Cluster Fuzz. Ça c'est un outil qui est utilisé notamment pour Chrome pour trouver des bugs dans Chrome. Cluster Fuzz existe depuis environ 6 ans et en 6 ans, Cluster Fuzz a trouvé 16 000 bugs dans Chrome et environ 11 000 autres bugs dans plusieurs projets open source. Si on regarde Cluster Fuzz et que l'on regarde aussi le deuxième fuzzer qui a le plus de succès, on va voir que le deuxième qui s'appelle JS Fuzz, lui, a trouvé environ 6000 bugs en 8 à 9 ans. Et si on regarde le code entre les deux, la différence principale, c'est pas la capacité de faire des mutations intelligentes. Cluster Fuzz fait pas de trucs spécialement compliqués, mais ce que Cluster Fuzz fait vraiment très bien, c'est l'échelle. On peut faire tourner Cluster Fuzz à très grande échelle. Ça tourne aujourd'hui sur environ 25 000 corps. Et avec le fuzzing maintenant, on peut voir que c'est tellement plus efficace que l'échelle et l'avantage principal. Parce que plus on a d'échelle, plus on peut être rapide pour détecter et patcher des exploit chains. D'un exemple que j'aimerais représenter est un petit peu différent. Il y a quelques mois, l'équipe de Google a trouvé, qu'était utilisé sur internet, un projet qui va tenter de faire des attaques. Il a pensé au début que c'était utilisé contre les dissidents musulmans en Chine. La meilleure dont cet attaque était détectée, c'était qu'on avait un appareil compromis et vous pouviez, à partir de cet appareil, comprendre comment il avait été compromis. Ce qui est intéressant, c'est que la manière dont l'équipe de Google a trouvé cela, c'est qu'ils ont utilisé leur logiciel de minage d'internet. Ça, c'est un autre exemple de passage à l'échelle qui est intéressant en termes de défense plutôt que d'attaque. Dans tous les exemples que j'ai présentés, quand vous voulez les examiner un peu précisément, ce qu'on voit, c'est que la sécurité s'est améliorée pas nécessairement parce qu'on est devenu meilleur, mais plutôt parce qu'on est devenu meilleur à s'occuper et à stocker de grandes quantités de données et à les traiter rapidement si besoin. Si cela est vrai, alors une autre chose à l'arrière dont tu vois son rencontre est que dans les exemples que j'ai présentés, le problème pris dans sa grande échelle est très différent de quand on regarde le problème sur un exemple clinique. Je vais utiliser un petit exemple pour essayer de vous montrer ça. Par exemple, disons que vous deviez auditer la fonction qu'on voit à l'écran. Si vous connaissez pas bien le code C, le problème c'est qu'on peut faire un overflow ou un underflow sur le buffer avec ce code. Simplement en mettant une valeur variable pour post. Si vous deviez auditer cette fonction, il y a beaucoup d'outils que vous pourriez utiliser pour faire ça, des outils d'exécution symbolique, d'utiliser du phazer et la plupart des solutions optimales pour ce cas vont être inutiles si maintenant il faut utiliser cette nouvelle fonction pour voir sur l'écran. En effet, l'état de la machine que cette fonction crée est trop complexe et il y a besoin de passer à une échelle supérieure pour résoudre ce genre de problème. Dans beaucoup des problèmes dont j'avais parlé auparavant, on voit ce phénomène. C'est-à-dire que quand on passe à l'échelle, on voit que le problème devient différent et qu'il n'a une résolute différemment. Ça nous fait réaliser que les compétences d'ingénieurs sont plus importantes que les compétences en sécurité maintenant. Si vous regardez comme des outils comme clusterfuzz ou IFL, ce qui compte, ce n'est pas l'expertise en sécurité, mais c'est la capacité de concevoir des systèmes qui peuvent facilement passer à l'échelle. Autant du côté du back-end, ça veut dire qu'il faut construire du code performant. Mais finalement, il y a assez peu de choses là-dedans qui vont avoir la sécurité au sens traditionnel. Une chose dont on se rend compte en analysant ces choses, c'est que la plupart des choses que l'on considère comme de la recherche ne prend pas place dans le même monde que celui auquel il lui faisait auparavant. Il y a six ans au CCS, une conférence académique. J'avais donné une conférence en disant que si le monde académique voulait faire de la recherche pertinente pour le monde de l'industrie, c'est plus dialogué entre eux. Et je crois que maintenant on a arrêté le point où c'est aussi vrai pour l'industrie dans le sens où si on veut toujours produire de la recherche pertinente à des endroits comme la conférence CCS, on n'est pas exactement au bon endroit pour l'instant parce que l'innovation qui se produit dans le vrai monde, elle se produit dans des environnements très larges auxquels on n'a pas vraiment forcément accès. On parle encore un petit peu, mais avant, j'aimerais aborder la question suivante. Voilà la question que je posais. Est-ce qu'il y a vraiment un changement significatif dans l'industrie ? Est-ce qu'on est dans une nouvelle époque, une nouvelle période de l'industrie ? Je pense que si on voulait penser à l'industrie de la cybersecurity sous forme de phase, on aurait des phases comme ci. Il y avait une phase où ce qui était le plus important, c'est la connaissance en sécurité. On est maintenant dans une phase où on a des systèmes experts qui demandent beaucoup plus de capacités en ingénierie que vraiment en sécurité. Mais ça demande quand même des données en entrée qui viennent de gens qui sont pointus en sécurité. La question à poser, c'est donc est-ce que c'est une étape à laquelle on va rester ou est-ce qu'il y a quelque chose d'autre dans le futur ? Je sais bien que faire des prédictions dans le monde de la sécurité, c'est généralement quelque chose qui ne marche pas. Mais par contre, ce que je peux faire, c'est faire un parallèle. Il y a une autre industrie similaire, c'est le machine learning. Richard Thun, qu'on a appelé le parrain du machine learning, a écrit un texte qui s'appelait la vérité amer et il a dit que dans cet essai, il disait, voilà ce que j'ai vu pendant environ 20 ans de recherche en machine learning. Il a dit, pendant très longtemps, on a essayé de mettre de la connaissance dans des systèmes de machine learning. L'idée étant, si on pouvait mettre de la connaissance dedans, on ferait un système plus intelligent. Mais en fait, ce qu'a marché à la place, ça a été de prendre des choses qui pouvaient monter en échelle si on avait plus de ressources. Au lieu de mettre plus d'intelligence, il fallait juste mettre plus de ressources. Et donc, il a vu que ce qu'il y avait marché dedans, c'était quelque chose qu'on a appelé Search and Learning, la recherche et l'apprentissage. Si on regarde par exemple AlphaGo, AlphaGo ne marche pas parce qu'on lui a donné énormément de connaissances sur le jeu de Go. AlphaGo marche parce qu'il a énormément de CPU. Il a la capacité de s'entraîner tout seul, de plus en plus vite, et donc d'apprendre le jeu. Et donc, il y a une question évidente, c'est à quel point est-ce que ça, on peut le transplanter dans le monde de la sécurité. Alors la sécurité n'est pas tout à fait pareil. La sécurité, c'est un monde adversarial par nature, donc c'est pas tout à fait la même chose, mais je pense qu'on est juste à la surface de ce qu'on peut faire en termes d'atteindre un nouveau niveau d'automatisation pour la défense et la sécurité. Je veux revenir sur AFL dont je parlais tout à l'heure. Une façon de conceptualiser ce que fait AFL, c'est que c'est un foseur qui fait de l'apprentissage par renforcement. Ce que je veux dire par là, dans ce slide, ce qu'AFL était capable de faire, c'était de prendre un fichier JPEG et en environ juste 1 200 iterations, il était capable de faire des mutations complètement stupides, mais qui donnaient quand même un autre fichier JPEG valide. Et ça, qu'on y pense, c'est vraiment impressionnant parce que AFL n'a aucune connaissance préalable du format fichier de JPEG. De plus en plus, on est en train de construire des systèmes qui n'ont pas besoin d'une connaissance experte initiale en matière de sécurité. Une autre chose dont je veux parler, c'est le cybercrime challenge. Ça, c'est une compétition qui est financée par DARPA, la recherche américaine en défense, en général. Et la question qui posait dans ce challenge, c'était, est-ce que vous pouvez automatiquement générer des exploits? Est-ce que vous pouvez automatiquement générer des patchs? Et donc, évidemment, ils l'ont fait dans le cadre de ce challenge dans des environnements simulés. Mais si vous parlez à n'importe qui qui s'intéresse à ce qui se passe autour de ça, c'est qu'on est probablement, peut-être, environ à 5 ans de distance de quelque chose qui est capable de automatiquement générer des exploits non trivials. Et c'est fascinant ça, parce que si on posait la question il y a 5 ans, la plupart des gens, et moi y compris, vous auraient dit, non, c'est quelque chose qui ne viendra pas avant très longtemps. Un service intéressant là-dessus, c'est Amazon Macy. C'est un service qui est fourni par Amazon qui utilise du machine learning pour identifier automatiquement des données à caractère personnel que vous stockez dans AWS. Et ça essaye de vous donner un meilleur sens de comment est-ce que ces données sont transformées, qu'est-ce qui se passe pour ces données. Et donc, des systèmes comme ça, comme on y pense, c'est un monde où il y a besoin de très peu de connaissances en sécurité préalables. Par contre, ce dont il y a besoin, c'est d'énormément d'échelle. Donc, tout ce que j'ai dit juste là, c'est quelque chose qui est plutôt positif pour ce qui est l'échelle. C'est plutôt quelque chose en faveur de l'échelle. Mais je pense qu'il y a un autre côté de la pièce en matière d'échelle, et je pense que c'est important d'en parler aussi. En particulier pour une audience comme celle du CCC. L'autre côté de cette pièce, c'est qu'avec l'échelle, vient la centralisation. Ce que je disais tout à l'heure, c'est qu'il y avait la recherche en sécurité qui était vraiment utile dans le monde réel. Où est-ce qu'elle se passait ? Elle se passe de plus en plus à des endroits comme Amazon, Google, ou des grosses entreprises de sécurité ou des agences publiques de sécurité et de renseignement. C'est-à-dire que pour pouvoir accéder à la recherche, pour pouvoir faire de la recherche, c'est de plus en plus difficile. Il faut de plus en plus de moyens. Il y a quelques années, quand j'étais encore au lycée, une des choses qui me fascinait sur la sécurité, c'est que n'importe qui, avec une connexion internet et un laptop, pouvait participer à l'industrie et même à l'industrie, le haut de l'industrie et le sommet de l'industrie. On pouvait faire de la recherche qui était notable à l'échelle de l'industrie entière. Maintenant, un ado de 15-16 ans au lycée va avoir beaucoup plus de mal à contribuer à l'industrie. On est dans une situation où, à cause de l'échelle et à cause de la centralisation que cette échelle apporte, cette centralisation rend l'accès à cette recherche de plus en plus difficile. Et donc, il est probable que de plus en plus pour faire de la recherche en cyber sécurité, il faudra avoir un background standard. Il faudra faire des études en informatique. Il faudra entrer dans une de ces grosses entreprises. Et ça, je pense que c'est pas forcément quelque chose de positif. Le même de Crosberg s'applique à la question de l'échelle. Il y a beaucoup de choses positives qui en sort, mais il y a également des problèmes. S'il y a quelque chose que j'aimerais que vous reteniez de cette conférence, c'est de penser à quel point quelque chose d'assez banal et considère comme acquis a changé l'industrie profondément. Et à quel point elle va contribuer à la prochaine phase de l'industrie. Et c'est pas seulement une question de capacité d'attaque, mais ça va aussi affecter le genre de personnes qui peuvent participer à cette introduction. Et je vous remercie pour votre attention. Merci beaucoup, on a du temps pour des questions. Si vous avez des questions, vous pouvez les poser dans la salle au microphone. Vous pouvez aussi les poser en ligne au signal angels par IRC ou par Twitter. Est-ce qu'on a des questions de l'Internet? Est-ce qu'on a des questions de l'Internet? Alors il n'y a pas de questions pour l'instant de l'Internet. Vincent Zou, est-ce que tu as des conseils pour les gens qui veulent rentrer dans l'industrie de la sécurité aujourd'hui? Comme je vous disais, la recherche la plus intéressante se fait de plus en plus dans les grandes compagnies technologiques. Ça ne me fait pas vraiment plaisir, mais mon avis, mon conseil, ce serait pouvoir avoir accès à un grand nombre de données et de puissance de calcul. C'est intéressant de travailler dans ce genre d'endroits. Bonjour. Merci pour cette super présentation et dans ce que vous dites vous montrez bien que vous argumentez vraiment bien pour dire que l'échelle permet de rendre la sécurité meilleure, mais est-ce que vous avez des données, des chiffres pour ça? C'est l'issue de répondre parce que les gens qui auraient intérêt à répondre ont un biais quand ils produisent ce genre de statistiques. Mais si on regarde les métriques comme le nombre de temps que les gens passent par attaque, ça signifie que ça a été significativement réduit avec le passage à l'échelle. Quand on regarde les exemples qu'en fadzing, à ma connaissance il n'y a pas eu d'exploration rigoureuse d'études poussées sur Social Network. On a atteint le point où la défense a un avantage sur l'attaque d'une certaine façon et si il y a des gens qui ont des capacités en matière d'attaque informatique ou qui travaillent dans le milieu quand ils m'en parlent, la plupart du feedback que je reçois c'est que c'est de plus en plus dur de garder une chaîne de bugs vivantes capables pendant un temps assez long. Et c'est en large partie grâce au fait de la même passage à l'échelle que j'ai expliqué. De ce que je peux en voir effectivement c'est bien le cas mais je n'ai pas de preuves statistiques formelles. Merci pour cette présentation intéressante. Ma question est plutôt à propos de la centralisation dont vous avez parlé. Le fait que la recherche se concentre de plus en plus à quelques endroits. Alors qu'est-ce que vous avez des conseils pour la communauté afin de garder accès à cette recherche à long terme ? C'est un sujet très intéressant. Il n'y a plus en plus d'open source qui vous permet de réunir de collecter les données mais le problème n'est pas tellement comment collecter les données mais quelle données collectée et comment les conserver. Parce que quand vous regardez par exemple le cloud qui a été fait pour la plupart des personnes ou le coût pour les personnes c'est de plus en plus élevé. Moi je n'ai pas vraiment de solution là-dessus. Vous pouvez utiliser des solutions moins chères mais le coût est toujours bien plus élevé que celui qui a été au parlant. Peut-être que le monde académique a un rôle à jouer là mais je ne suis pas sûr. Alors question depuis l'internet. Vous avez beaucoup parlé de fuzing à grande échelle. Est-ce que vous connaissez d'autres infrastructures de fuzing qui soient disponibles pour le grand public ? Non. Mais si vous regardez par exemple les participants au cyber guns challenge beaucoup d'eux utiliser un nombre assez important de puissance de calcul pour le fuzing. Je ne connais pas de méthodes plug and play de fuzing que vous pourriez utiliser à part OSS Fuzz mais de ce que j'en sais les gens qui font du fuzing leur profession ils ont accès à des ressources assez considérables et avec un passage à l'échelle important. Et bien je pense qu'on devrait applaudir Vincenzo, merci beaucoup.