Renaud Lifchitz, directeur scientifique, expert en sécurité IT au sein de la société Holiseum

Les ramsomwares apparaissent comme la première préoccupation des collectivités territoriales en termes de cyber sécurité. Vous avez lancé récemment le « tir à blanc ransomware », un dispositif de test de vulnérabilité. L’intérêt suscité est-il à la hauteur du risque ?
Nous avons lancé ce service parce qu’aujourd’hui, face à la menace de ransomwares, la précaution d’une sauvegarde des données n’est plus suffisante. Dans les dernières attaques par ransomware, non seulement les données sont chiffrées, mais elles sont aussi volées, avec la menace de les rendre publiques. Ajoutons à cela que beaucoup de sociétés et de collectivités, n’ont parfois pas de sauvegarde du tout et n’ont pas travaillé leurs procédures de restauration.
Le « Tir à blanc ransomware » est le premier service qui permet de faire un entraînement grandeur nature pour connaître les failles de sécurité de son système d’information. Son objectif est de suivre, sans risque, de manière très personnalisée, la propagation d’un ransomware dans son réseau et d’en trouver les failles. Est-ce que c’est des mots de passe par défaut ? Des défauts de mise à jour ? Des défauts de cloisonnement du réseau ? Est-ce que vos équipements de détection de menaces (EDR) sont capables de voir une activité suspecte, soit de déplacement latéral sur le réseau, soit au niveau du système, et de détecter un processus qui accède à énormément de fichiers ? Ce sont des indices qui permettent de penser qu’il y a une menace. Pour cela, nous allons juste chiffrer de manière sélective un dossier par machine qui sera rempli de données banales. Il n’y a aucun risque d’interruption de service ou de corruption de données. Cela permet de tester différents aspects techniques et organisationnels et surtout d’avoir un constat personnalisé à la fin.

Comment coûte un test de ce type ?

Lorsqu’on fait des tests de propagation, on va regarder différents points de démarrage de l’infection par le ransomware, c’est ce qu’on appelle des patients zéro. Le patient zéro, cela peut être un poste bureautique dans lequel on a ouvert une pièce jointe infectée (très fréquent). Mais cela peut être aussi un serveur sur lequel il y a une faille de sécurité qui est accessible depuis internet, ou un serveur d’administration qui aura été corrompu par une mise à jour vérolée. On va regarder selon l’architecture réseau du client quels sont les types de patient zéro les plus probables et selon la taille du parc à tester on va déterminer une charge. Pour une charge moyenne, on va tourner autour de 10 jours/homme, soit entre 15 à 20 000 euros. Cela inclut toutes les réunions préparatoires, le choix des patients zéro, l’organisation, le déploiement de la solution, les tests en eux-mêmes, la surveillance sur site et un rapport personnalisé avec les vulnérabilités trouvées, les recommandations et, éventuellement, un re-jeu derrière pour voir si en corrigeant quelques aspects rapidement on bloque la propagation. Pour une collectivité locale qui a entre 10 et 20 postes, cela peut être plus court et on peut diviser par deux la charge et les coûts. Sur de tous petits réseaux, surtout sur des réseaux « à plat » (sans cloisonnement), comme c’est beaucoup le cas dans les collectivités, cela va plus vite, il n’y aura souvent qu’un patient zéro.

Concernant les risques de cyber sécurité que pose l’IoT, on a l’impression, à défaut d’attaques avérées et médiatisées, que cela reste quelque chose de très théorique. Qu’en pensez-vous ?

Il y a beaucoup d’incidents dans de petites villes qui n’ont pas beaucoup d’écho médiatique. A Lille, il y avait eu [en septembre 2015] des panneaux de parking qui avaient été détournés. On n’en aurait jamais parlé s’il n’y avait pas eu des gros mots sur ces panneaux. C’est le cas de beaucoup d’attaques. Cela peut passer pour un dysfonctionnement. Très souvent, les communiqués des organismes qui ont été touchés parlent de « dysfonctionnement informatiques » et pas d’attaque d’un hacker pour ne pas faire paniquer tout le monde.
Sur Lorawan, par exemple, nous avons trouvé de nombreuses vulnérabilités de design dans le protocole. De nombreuses infrastructures de smart city sont déployées sans la moindre sécurité et sont même directement connectées à internet. L’infrastructure Lorawan de Corée du Sud, par exemple, est sur Internet. On peut capturer l’ensemble des messages Lorawan qui sont échangés par l’opérateur national KT sans même se rendre sur place, simplement parce qu’il y a un défaut de configuration dans les infrastructures.
Aux Pays Bas, il y a beaucoup d’opérateurs de location de vélos qui utilisent des vélos avec des GPS connectés pour avoir un suivi de leur flotte et éviter le vol de vélos. Cet opérateur avait son interface d’administration également accessible sur internet sans la moindre authentification. On pouvait donc avoir la main complète sur le réseau de communications de cet opérateur, qui était en Lorawan aussi.

Qu’en est-il de Sigfox, dont le trafic n’est pas chiffrable ?

Pour beaucoup d’usages, le chiffrement des communications dans la smart city n’est pas indispensable. Je pense à des systèmes de relevé de compteurs ou des systèmes d’alarme incendie ou d’inondation, qui n’ont pas besoin de chiffrement dans la mesure où il n’y a pas besoin de confidentialité pour ces données non critiques. Dans la smart city, plus de que confidentialité, on a besoin de disponibilité. On a besoin que ça fonctionne 24 h/24.

On a l’impression qu’il y a dans les collectivités territoriales, une sorte de confusion sur la nature des risques qu’il peut y avoir sur les différents types de terminaux ou d’objets connectés. Avez-vous une sorte de grille d’analyse sur la manière de procéder ?

Nous avons fait un top 5 des vulnérabilités, dans lequel on va trouver l’absence de mots ou de passe ou la conservation du mot de passe par défaut chez tous les fabricants (ce qui permet de faire des attaques de masse), l’installation de mises à jour non sécurisés, l’absence de chiffrement des communications, le stockage de données non sécurisé et les interface de débogage ouvertes.
Je constate depuis plusieurs années que chez les développeurs de solutions comme chez les intégrateurs, il y a une volonté que cela fonctionne, mais la priorité n’est pas à la cybersécurité. Installer un équipement sur internet ou sur un réseau local, ce n’est pas les mêmes contraintes de sécurité.

Quels types d’attaques peut-on redouter sur l’IoT des villes ?

Les attaques de masse sur des périphériques liés à la smart city ou au smart building devraient se développer. Qui dit attaque de masse, dit attaque par déni de service pour provoquer une panne globale d’un système au niveau de la ville. On peut s’attendre également à des attaques de rançonnage au niveau des périphériques. On l’a vu sur des équipements grand public, comme les télés connectées. On trouve aussi le risque que représentent les mécanismes de rétrocompatibilité. Lorsqu’on installe du nouveau matériel sécurisé, on fait en sorte qu’il fonctionne aussi avec l’ancien, qui l’est moins ou pas du tout.

Vous parlez d’une méthode de sécurisation des IOT via un audit qui se développe en quatre axes (sécurité matérielle, sécurité réseau & radio-fréquences, sécurité applicative, sécurité système). Pensez-vous que les DSI des collectivités peuvent faire ça par eux-mêmes ?

Non, je ne pense pas. Il y a deux axes qui sont connus des équipes IT (communication et système). Mais il y en a deux autres qui sont souvent délaissés parce qu’ils demandent une expertise de sécurité sur le matériel et une expertise sur la sécurité des radio communications.
Il y a dix ans, la sécurité des radio communications était un domaine totalement vierge. On considérait que tout ce qui passait par les ondes radio n’était pas interceptable et pas lisible. Ce qui a changé, c’est l’apparition de récepteurs en radio logicielle. Ces récepteurs low cost (des clés USB qui permettaient par exemple de recevoir la télé sur son PC) peuvent être facilement piratés pour aller sur d’autres bandes de fréquences (entre 50 MHz et 2,5 GHz) qui permettent d’écouter tous les protocoles liés à l’IOT, y compris le GSM (3G, 4G, etc). On peut faire des écoutes passives sur les protocoles et récupérer des informations sensibles.

Si on fait un peu de prospective très proche, la 5G, voyez-vous ça nativement sécurisée, notamment pour la gestion massive d’objets connectés ?

Entre la 2G, la 3G, la 4G et la 5G il y a eu, à chaque fois, des couches de sécurité qui ont été rajoutées. La 5G sera difficile à pirater, plus que la 4G, qui n’est déjà pas simple. Mais il y aura encore, là aussi, le souci de la rétrocompatibilité. Comme il n’y aura pas de la 5G partout, on basculera en 4G, 3G ou 2G. Par ces mécanismes de rétrocompatibilité, les équipements 5G seront très peu sécurisés lorsque la couverture sera mauvaise ou lorsqu’il y aura quelqu’un qui viendra se placer à proximité avec un brouilleur. Si j’ai un brouilleur 5G et 4G, l’équipement va se mettre en 3G et il va « discuter ». Or, en 3G ou 2,5 G, on sait casser très vite un chiffrement et l’authentification. On va donc pouvoir écouter et falsifier tout le trafic envoyé par le dispositif connecté. La rétrocompatibilité engendre des problèmes de sécurité un peu partout, parce qu’on ne renonce pas à ces protocoles très peu sécurisés. C’est vrai aussi avec le Bluetooth ou avec le protocole Zigbee.