Où va la sécurité des Scada ?  

A le lire, on est tenté de penser que le problème est largement sous-estimé, peut-être plus répandu et plus grave que l’on ne le pensait jusqu’ici. Dans un entretien accordé anonymement à Threatpost, un responsable du département américain de la sécurité intérieur estime ainsi que certains problèmes de sécurité concernant les Scada «sont tout simplement trop gros pour être qualifiés de vulnérabilités». Pire : diffuser des alertes à leur sujet n’aurait même aucun sens. 

Comme le rapporte nos confrères, Marty Edwards, directeur de l’équipe de réponse rapide aux situations informatiques critiques pour les systèmes de contrôle informatisés, l’ISC-CERT, ne s’inquiète plus des failles de sécurité mais des «problèmes systémiques de conception ». Un changement terminologique qui en dit long. Et pour ces problèmes, pas question d’émettre un bulletin d’alerte. Pour eux, Marty Edwards se déclare incompétent, soulignant que la mission de son organisation est d’émettre, en quasi temps réel, des alertes sur des failles, et pas de corriger des systèmes entiers. Là encore, sans le dire expressément, c’est bien une vaste remise en cause de la conception des systèmes Scada qui est faite. 

Pour autant, la démarche ne convainc pas totalement. Ralph Langner, qui s’était déjà illustré pour son analyse du code de Stuxnet, la critique : pour lui, le seul effet de cette approche est de réduire la visibilité sur la vulnérabilité réelle des systèmes Scada, drastiquement ; c’est à dire d’environ «90 % puisque la plupart des “problèmes” de sécurité ne sont pas des bugs mais des défauts de conception ». Quitte, d’ailleurs, à ce que l’administration américaine entre en contradiction avec elle-même, elle qui définit une vulnérabilité comme «une faille ou une faiblesse dans la conception, l’implémentation, l’exploitation ou l’administration d’un système qui pourrait être exploitée pour violer les règles de sécurité du système.»

Bref, pour lui, l’administration américaine se simplifie la vie. Mais pas celle des chercheurs en sécurité ou des entreprises parce que «vos processus n’ont que faire que ce soit un bug ou une fonction qui est exploité ».