Evaluation Pitfalls and Multimodal Baselines for the \dataset{} IoT Malware Dataset

Dans le monde numérique, les chercheurs en sécurité agissent comme des médecins du système immunitaire pour les ordinateurs. Ils construisent des outils pour repérer les logiciels malveillants, ou malwares, avant qu'ils ne puissent causer des dommages. Pour entraîner ces outils, ils ont besoin de vastes bibliothèques de données : des enregistrements de la façon dont les ordinateurs se comportent lorsqu'ils sont sains, et des enregistrements de la façon dont ils se comportent lorsqu'ils sont malades. La qualité des données d'entraînement détermine l'efficacité des outils de sécurité qui en résultent. Si les données sont défectueuses, les outils échoueront dans le monde réel, manquant souvent des menaces dangereuses ou générant de fausses alertes. Un défi majeur dans ce domaine est de s'assurer que la manière dont les chercheurs divisent leurs données en groupes d'entraînement et de test n'introduit pas accidentellement de biais. Si un programme informatique voit une pièce spécifique de malware pendant l'entraînement, puis voit exactement la même pièce pendant le test, il n'apprend pas réellement à détecter de nouvelles menaces ; il mémorise simplement la réponse. De plus, les chercheurs doivent décider s'ils jugent un outil de sécurité sur sa capacité à détecter des moments individuels d'activité suspecte, ou sur sa capacité à identifier des programmes infectés entiers, ce qui peut être une tâche très différente.

Une équipe de chercheurs de l'Université de Tarim a récemment porté son attention sur une nouvelle bibliothèque de données inhabituellement détaillée appelée CIC-YNU-IoTMal2026. Ce jeu de données est une véritable mine d'or pour les experts en sécurité car il enregistre simultanément trois types différents d'informations pour des milliers de programmes informatiques. Il capture le trafic réseau entrant et sortant, l'activité du système comme l'utilisation du processeur (CPU), et la liste spécifique des commandes que le programme donne au système d'exploitation. Ces programmes ont été exécutés sur quatre types différents de puces informatiques pour voir si les outils de sécurité pouvaient fonctionner sur différents matériels. Les chercheurs n'ont pas construit un nouvel outil de sécurité ; ils ont plutôt agi en tant qu'auditeurs. Ils ont examiné le jeu de données lui-même pour voir si les méthodes standard de test des outils de sécurité sur ces données cachaient des problèmes sérieux. Ils voulaient savoir si les scores élevés rapportés par d'autres chercheurs étaient réels ou s'ils étaient le résultat d'erreurs subtiles dans la manipulation des données.

L'audit a commencé par examiner comment les données étaient divisées. La méthode la plus courante consiste à prendre tous les moments d'activité enregistrés, à les mélanger de manière aléatoire, en plaçant certains dans un tas d'entraînement et d'autres dans un tas de test. Les chercheurs ont découvert que cette approche était fondamentalement erronée pour ce jeu de données spécifique. Comme les données enregistrent des programmes entiers, le mélange des moments signifiait que le tas de test contenait des moments provenant de programmes qui étaient déjà présents dans le tas d'entraînement. En fait, chaque moment de test partageait son programme parent avec l'ensemble d'entraînement, et un petit pourcentage des moments de test était une copie exacte des moments d'entraînement. Cela signifiait que tout outil de sécurité testé de cette manière était essentiellement noté sur des questions auxquelles il avait déjà vu les réponses. Bien que cela n'ait pas artificiellement gonflé les scores sur ce jeu de données particulier, cela signifiait que les résultats ne pouvaient pas être fiables pour prédire l'efficacité d'un outil sur de nouveaux programmes réellement inédits. Les chercheurs ont conclu que la seule façon équitable de tester ces outils est de garder les programmes entiers ensemble, en veillant à ce qu'aucun programme n'apparaisse à la fois dans l'entraînement et dans le test.

Même lorsque les chercheurs ont corrigé la méthode de division des données, ils ont découvert un second problème, plus trompeur. Le jeu de données contient des milliers de minuscules instantanés d'activité, et de nombreux outils de sécurité sont jugés sur leur capacité à détecter ces instantanés individuels. Les chercheurs ont découvert que cette méthode cache un mode de défaillance dangereux. Environ seize pour cent des programmes malveillants du jeu de données étaient complètement manqués par les outils de sécurité. Ces programmes manqués n'étaient pas sophistiqués ; ils étaient simplement dormants. Ils avaient été exécutés dans l'environnement de test mais n'avaient pas réussi à s'éveiller pour commencer leurs activités malveillantes, ils ressemblaient donc exactement à des programmes inoffensifs. Comme les programmes malveillants qui s'éveillaient étaient très bruyants et généraient des centaines d'instantanés d'activité, ils dominaient les statistiques. Les programmes calmes et dormants étaient noyés, faisant paraître l'outil de sécurité bien meilleur qu'il ne l'était réellement. Les chercheurs ont souligné que pour obtenir une image réelle de la sécurité, il faut juger l'outil sur sa capacité à attraper le programme entier, et non seulement les moments bruyants.

L'étude a également examiné la manière dont les outils se comportaient face à différents types de puces informatiques. Le jeu de données comprenait des programmes s'exécutant sur quatre architectures différentes, et les chercheurs ont testé si un outil entraîné sur trois d'entre elles pouvait détecter des menaces sur la quatrième. Les résultats ont été frappants. Lorsqu'un outil a été testé sur un type de puce spécifique appelé ARM, qui est courant dans de nombreux petits appareils, il s'est effondré. L'outil est devenu si peu fiable qu'il signalait des programmes inoffensifs comme dangereux près de quatre-vingts pour cent du temps, tout en détectant presque tous les malwares réels. Cet échec n'était pas dû au fait que l'outil ne pouvait pas reconnaître le malware ; c'est parce que les programmes inoffensifs sur la puce ARM se comportaient différemment des programmes inoffensifs sur les autres puces. L'outil avait appris les mauvais schémas de ce qui constituait la "normalité" sur ce matériel spécifique. Les chercheurs ont trouvé que ce problème pouvait être résolu de manière très peu coûteuse. En montant à l'outil une infime fraction des programmes inoffensifs de la nouvelle puce — moins de un pour cent des données totales — la performance de l'outil est instantanément revenue à la perfection. Cela suggérait que la solution pour la sécurité inter-puces n'est pas d'utiliser des algorithmes complexes, mais simplement d'exposer l'outil à quelques exemples du nouvel environnement.

Enfin, les chercheurs ont examiné les différents types de données disponibles : le trafic réseau, l'activité du système et les traces de commandes. Ils ont constaté que dans un environnement contrôlé, la combinaison de ces trois types de données rendait les outils de sécurité presque parfaits. Cependant, cette perfection était fragile. Lorsque les outils étaient contraints de ne compter que sur le trafic réseau, ils manquaient les programmes dormants. Lorsqu'ils ne reposaient que sur les traces de commandes, ils échouaient complètement lorsque l'architecture de la puce changeait. La combinaison la plus robuste s'est avérée être un mélange de trafic réseau et d'activité système, ce qui permettait d'éviter les faiblesses spécifiques des autres méthodes. Les chercheurs ont également noté que le type de modèle mathématique utilisé pour construire l'outil importait très peu. Qu'ils utilisent un modèle linéaire simple ou un réseau neuronal complexe, les résultats étaient presque identiques. Cela a prouvé que le facteur de succès n'était pas la sophistication de l'outil, mais les choix faits concernant la division des données, la définition d'un succès et la gestion des différents types de puces.

L'article conclut par un ensemble de directives claires pour toute personne utilisant ce jeu de données. Ils recommandent de toujours garder les programmes entiers ensemble lors de la division des données, de rapporter les résultats basés sur le fait que des programmes entiers sont capturés plutôt que sur de simples moments individuels, et d'être transparent sur la manière dont les programmes inconnus ou non classés sont traités. Ils exhortent également les chercheurs à tester leurs outils sur différentes puces informatiques et à rapporter à quel point les résultats varient si l'expérience est répétée plusieurs fois. Le point le plus important est que la voie vers une meilleure sécurité ne réside pas dans la construction de modèles plus complexes, mais dans le fait de poser de meilleures questions et d'utiliser des données plus propres. En corrigeant les méthodes d'évaluation, la communauté peut s'assurer que les outils qu'elle construit fonctionneront réellement lorsqu'ils seront le plus nécessaires.