Analyser des logs IoT, et retrouver ses réflexes BI

Jeudi (21/05) après-midi, j’ai assisté en distanciel à une session du Club EH Root-Me, l’événement mensuel ethical hacking que le CLUSIR Auvergne-Rhône-Alpes coorganise avec Root-Me Pro et Elysium Security. Le sujet : IoT Log Analysis. Trois heures, dont une bonne demi-heure d’introduction magistrale, puis deux heures de challenges sur la plateforme Root-Me Pro. La session était aussi accessible en présentiel à Charbonnières-les-Bains.

Ce billet n’est pas un retour de projet. Je n’ai rien construit. C’est de la veille, comme l’article que j’avais écrit après la session du CLUSIR sur les enjeux juridiques cyber. Je raconte ce que j’ai vu, ce qui m’a marqué, et la grille de lecture que j’ai ramenée à la maison. Tout ce qui relève du contenu pédagogique vient de l’intervenant, un analyste SOC chez Elysium Security.

Ce qu’est le CLUSIR ARA, vite fait

Je connais le CLUSIR depuis quelques mois maintenant, et je me rends compte que beaucoup de gens autour de moi ne savent pas ce que c’est. Le CLUSIR Auvergne-Rhône-Alpes est une association régionale qui anime la communauté cybersécurité du territoire : entreprises, écoles, indépendants, étudiants. Concrètement, il organise des rencontres techniques, des conférences, et surtout pour ce qui me concerne, un Club Ethical Hacking mensuel avec Root-Me Pro.

Chaque 3e jeudi du mois, une session de trois heures. Un intervenant fait un topo de fond sur un sujet offensif ou défensif, puis le groupe attaque des challenges Root-Me Pro autour de ce sujet. La plateforme reste ouverte un mois après la session, ce qui permet de revenir sur les exercices à tête reposée. C’est gratuit pour les pros et les étudiants des écoles partenaires.

Le sujet : analyser des logs quand l’objet ne parle pas

L’intervenant a planté le décor. Un parc IoT aujourd’hui, c’est entre 20 et 25 milliards d’objets connectés dans le monde, et la plupart sont des boîtes noires propriétaires. Pas d’agent qu’on peut installer dessus. Pas de journal système exploitable. Pas de standard commun. Une caméra de surveillance, un thermostat, un automate industriel et un pacemaker partagent la même propriété gênante pour un défenseur : ils sont muets.

Le constat de départ, c’est donc qu’on ne cherche pas un “log d’objet”. On instrumente ce qu’il y a autour : la passerelle qui agrège les objets, le segment réseau sur lequel ils discutent, la plateforme cloud où leurs données aboutissent. La question n’est plus “que dit cet objet ?” mais “que vois-je passer à son sujet ?”

Sur cette base, l’intervenant a proposé une grille en trois questions, à se poser dans l’ordre face à un objet suspect ou à un parc à instrumenter. La première : cet objet fait-il quelque chose qu’il ne devrait pas faire ? On cherche un comportement réseau anormal, type nouvelle destination jamais vue, changement de rythme, scan sortant. La deuxième : cet objet est-il devenu un point de pivot ? On regarde le mouvement latéral vers l’AD, vers d’autres postes, vers une base de données. La troisième, la plus délicate : puis-je faire confiance à ce qu’il rapporte ? Là on parle d’intégrité de la donnée elle-même, valeurs trop stables, incohérences entre deux sources, écart au témoin physique.

Chaque question oriente vers une source de logs différente : NetFlow et DNS pour la première, journaux de pare-feu et trafic latéral pour la deuxième, plateforme cloud et capteurs redondants pour la troisième.

Ce que j’ai trouvé fort dans cette démarche, c’est qu’elle s’applique aussi hors IoT. N’importe quel parc d’appliances boîte noire (terminaux fournisseurs, IPMI/iLO, BYOD non managé) se prête à la même grille.

Vingt-cinq ans d’attaques, et un seuil d’entrée qui s’effondre

L’intervenant a déroulé un historique que je ne connaissais pas en détail.

En 2000, à Maroochy Shire en Australie, un ex-prestataire pirate par radio le système SCADA d’assainissement d’une commune. Quarante-six attaques, près d’un million de litres d’eaux usées déversées dans l’environnement. C’est la première fois qu’un incident cyber-physique est documenté. À l’époque il fallait des connaissances internes très précises pour conduire ce type d’attaque.

En 2010, Stuxnet. L’attaque dont tout le monde a entendu parler, ciblée sur les automates Siemens qui pilotaient les centrifugeuses iraniennes de Natanz. Niveau de sophistication étatique : quatre 0-days, signatures volées, propagation par USB pour franchir l’air-gap. Le détail qui m’a particulièrement frappé : les écrans HMI affichaient un état nominal pendant que les centrifugeuses partaient en vrille.

Plus surprenant, l’intervenant a évoqué fast16, un malware échantillonné dès 2005 mais révélé seulement en 2026 par les équipes de SentinelOne. Un driver noyau qui patchait en mémoire des logiciels d’ingénierie pour fausser des simulations de détonation. Plus ancien que Stuxnet, et invisible pendant vingt ans.

Enfin 2016, et le passage à l’échelle avec Mirai. On ne cherche plus une cible précise, on ratisse tout l’IoT grand public exposé avec ses mots de passe par défaut. Botnets de zombies pour DDoS sur Krebs, OVH, Dyn. Et aujourd’hui, des variantes industrialisées comme Aisuru ou Kimwolf, qui dépassent les 20 Tbps et qui arrivent parfois préinstallées dans des firmwares bas de gamme achetés sur AliExpress.

Le tableau qu’il a montré juxtaposait ces quatre périodes selon les compétences requises pour conduire l’attaque. 2000 : connaissances internes d’un système précis. 2010 : capacités étatiques. 2014-2016 : code public, niveau faible. 2024 et après : achetable comme service. Sur vingt-cinq ans, le ticket d’entrée s’est effondré.

Le bruit, et ce qu’il coûte

L’intervenant a passé une bonne partie de la présentation sur un sujet auquel je ne m’attendais pas : le bruit. À un moment il a dit, en parlant de la normalisation des logs : “le SOC c’est quand même une majorité de bruit, et essayer de trouver des indicateurs au milieu de tout ça.” J’ai noté.

Le constat est simple. Un parc IoT instrumenté produit énormément de données. La répétitivité des objets fait qu’une grande partie de ces données est de l’écho de leur fonctionnement normal. Si on ingère tout sans tri, le SIEM se transforme en archive coûteuse et illisible. La détection ne porte plus, elle se noie.

Sa réponse à ce problème tient en deux principes opérationnels.

D’abord, un critère d’élimination des sondes. Une sonde qui ne répond à aucune des trois questions de détection (comportement, pivot, intégrité) n’a pas de raison d’être. Elle collecte, elle remonte, elle pèse sur le pipeline, mais elle ne sert pas. Autant la couper. La logique est radicale mais elle découle du framework : chaque sonde doit être justifiée par une question à laquelle elle aide à répondre. Sinon ce n’est pas une sonde utile, juste du volume.

Ensuite, le travail de normalisation à la source. Plutôt que d’ingérer tous les messages bruts et de filtrer en aval dans le SIEM, on normalise et on filtre dès la collecte. On ne remonte que ce qui s’écarte de la baseline. Il a dit que c’était l’effort principal des équipes SOC, ce qui m’a surpris au début parce qu’on parle souvent du SOC en termes de détection et d’investigation, pas de plomberie de données. Mais à y réfléchir, ça tient.

Une question est arrivée en fin de session sur ce point, et c’est elle qui m’a le plus marqué. Quelqu’un a soulevé que dans un contexte industriel, l’IoT lui-même sature parfois la bande passante du réseau. Si on ajoute par-dessus des sondes qui dupliquent ou agrègent du trafic, on peut faire monter les CPU des switchs, voire faire tomber l’infrastructure qu’on est censé surveiller. La réponse de l’intervenant a été précieuse. La supervision est un sujet d’architecture amont. Avant de placer la moindre sonde, il faut dimensionner ce que la surveillance elle-même va coûter en ressources. Le contexte ne justifie pas seulement le placement, il justifie aussi le seuil de ce qu’on peut se permettre de collecter.

Cette partie m’a parlé pour une raison que je vais détailler dans la section suivante. C’est exactement le métier que j’ai fait pendant douze ans, transposé. Arbitrer entre granularité, fréquence, coût de stockage et utilité analytique, c’est de l’ETL. Faire de l’ETL avec des logs plutôt qu’avec des tables transactionnelles ne change pas la nature du problème.

Le moment où la BI a refait surface

La lecture de logs IoT, ce n’est pas exactement le sujet sur lequel mes douze ans à la Caisse d’Épargne m’avaient préparé. Je me voyais déjà perdu dans des dumps protocolaires obscurs.

Puis sont arrivés les challenges Root-Me Pro, qui tournaient sur des stacks Kibana avec des logs IIoT à analyser. Et là, je n’étais pas largué du tout.

Pas parce que je maîtrise Kibana, j’en suis loin. Il y a une vraie courbe d’apprentissage sur le KQL et sur les subtilités des filtres avancés. Mais ce que je faisais, c’était de l’analyse de données. Filtrer une colonne par une valeur. Grouper par champ. Compter les occurrences. Chercher les valeurs uniques. Concaténer deux conditions. Identifier un pattern de fréquence anormal.

J’ai littéralement passé douze ans à faire ça, en SQL, en DAX, dans Power BI. La syntaxe change, les outils changent, mais la logique d’analyse est la même. Un filtre KQL pour isoler les requêtes DNS suspectes d’une IP source, c’est un WHERE source_ip = X AND query NOT IN (whitelist) que j’aurais écrit les yeux fermés sur Oracle. Une aggregation Kibana pour compter les destinations distinctes par device, c’est un GROUP BY device_id, COUNT(DISTINCT destination).

Je ne dis pas que je pourrais m’asseoir demain dans un SOC et travailler en autonomie. Loin de là. Mais le réflexe mental est là. Ce qui me manque, c’est moins l’analyse elle-même que la culture des indicateurs de compromission, des patterns offensifs, des protocoles spécifiques à l’IoT. C’est plus une question de savoir quoi chercher que de savoir comment chercher.

Les questions GRC que la session a laissées ouvertes

L’intervenant est analyste SOC. Son angle, c’est la détection en aval, et il l’a tenu de bout en bout. C’est ce qu’on attendait d’une session blue team. Mais en sortant, j’avais une liste de questions qu’il n’avait pas eu le temps d’aborder, et qui touchent à mes axes : la gouvernance et l’architecture.

Le tableau qu’il a montré indiquait que pour un parc IoT cellulaire (LoRaWAN, NB-IoT via opérateur), la seule visibilité est côté plateforme cloud du constructeur. Pour un RSSI, ça veut dire concrètement qu’il n’a pas de visibilité native sur son propre parc. C’est un sujet de rapport de force fournisseur, et ce rapport est rarement favorable au client. Une PME qui consomme un service IoT externalisé pour quelques centaines d’euros par mois ne va pas obtenir d’intégration SIEM custom en négociant son contrat. Le fournisseur a un contrat-type, parfois lui-même limité dans ce qu’il peut techniquement exporter.

Comment garantir l’intégrité de ce qu’on reçoit ? La troisième question de son framework (peut-on faire confiance à la donnée) est la plus difficile à industrialiser. Stuxnet et fast16 ont prospéré justement parce qu’aucune source de vérité indépendante ne contredisait les valeurs affichées. C’est un sujet de gouvernance de la donnée, de capteurs redondants, de cohérence inter-sources. La détection toute seule n’y répond pas.

Et la couche réglementaire ? Le Cyber Resilience Act européen, dont la mise en conformité totale est attendue pour fin 2027, va imposer aux fabricants d’IoT des exigences essentielles de cybersécurité dont la collecte de logs est une brique. NIS2 fait entrer dans son périmètre les opérateurs IIoT industriels.

Ce que je vais en faire

Quelques actions concrètes en sortie de session.

La première, finir les challenges Root-Me Pro tant que la plateforme reste ouverte. Je n’ai pas eu le temps de tout faire pendant la session, et c’est le genre de pratique régulière qui me manque pour passer de “je comprends le concept” à “je manipule l’outil”.

Et puis surtout, retourner aux prochaines sessions du Club EH Root-Me. La fréquence mensuelle me convient, le format topo + challenges aussi. Plus largement, le CLUSIR ARA est le type de structure dont je veux faire partie, pas seulement pour apprendre, mais pour participer au tissu cyber régional.

Pour finir

Je m’attendais à être largué. Je suis rentré avec la sensation inverse : il y a plus de passerelles que je ne le pensais entre ce que je sais déjà faire et ce que je vais avoir à faire. Pas une équivalence. Mais pas non plus une rupture totale. Ça suffit pour un retour de session.

Merci à Alex Triplet pour la session, au CLUSIR ARA, à Root-Me Pro et à Elysium Security pour l’organisation. La prochaine session est dans un mois.

Précision : le contenu pédagogique de ce billet (framework des trois questions, historique IoT, exemples Maroochy/Stuxnet/Mirai) vient de l’intervenant. Mon apport personnel se limite au parallèle BI et aux questions GRC laissées ouvertes.