Deux chercheurs, Terry McCorkle et Billy Rios, se sont mis au défi de créer leur propre « Month of Scada Bug », et de trouver 100 bugs majeurs en l’espace de 100 jours dans un éventail de systèmes de commandes industriels. Le résultat de ce pari a fait l’objet d’une présentation formelle à l’occasion du « Kaspersky Security Analyst Summit 2012 » de Cancun, information rapportée par nos confrères de Search Security. Pouquoi 100 bugs « seulement » ? Parce que, estimaient les chercheurs, plus de 1000 trous de sécurité, dont 95% étaient exploitables très facilement, avaient déjà été découverts durant les 9 mois de travail qu’exigeait la phase préliminaire de leurs travaux. Trous bien entendu signalés aux éditeurs et équipementiers concernés et corrigés depuis. Il était donc logique que les perfectionnements et remises à plat provoquées par ce déluge d’alertes ait rendu la gageure plus difficile.
Que nenni ! les 100 trous furent trouvés sans effort démesuré. La faute en reviendrait principalement aux méthodes, ou plus exactement à la quasi absence de méthode des éditeurs de logiciels de supervision de contrôle de processus industriels. Pas la moindre notion de « software development lifecycle », pas la plus petite opération de « fuzzing » (laquelle est devenue une quasi routine chez bon nombre d’éditeurs de logiciels du secteur de « l’informatique informaticienne »).
L’on pourrait ajouter que, des décennies durant, ces spécialistes du pilotage d’automates programmables se sont habitués à pondre un code simple, destiné à des mini-ordinateurs ou des calculateurs industriels utilisant une architecture et des noyaux très propriétaires, le tout évoluant au sein de complexes industriels coupés de tout lien avec les réseaux publics. Mais, la crise économique actuelle aidant, les tarifs pratiqués durant toute cette période sont vite devenus prohibitifs. Les « Minis » ont été remplacés par des « micros », les noyaux cryptiques et les architectures ésotériques ont cédé la place à de la machine Wintel, la superbe isolation de l’automate programmable s’est évanouie aux accents triomphants d’Internet, outil de communication Ô combien plus économique qu’une ligne spécialisée posée par Transpac et louée à des tarifs proche du PIB d’un état Africain. Ces multiples virages technologiques contraignent aujourd’hui les éditeurs de logiciels de commande de processus industriels à réaliser en quelques mois ce qui a pris plus de deux décennies à des Microsoft, des Oracles ou des Linux : savoir écrire « propre » et avec méthode, afin de limiter (et encore) le nombre probable d’erreurs exploitables. Une équation à N inconnues qu’aucun exercice Piranet, même scénarisé par le plus imaginatif des Enarques, ne saurait résoudre.
1 commentaire