La première journée des Assises de la Sécurité 2010, qui se tient traditionnellement à Monaco, a respecté la tradition : soleil de plomb, mer bleue, ambiance affairée, nombre de participants en remarquable progression… mais il flottait dans l’air un parfum « d’après ». Fragrance d’autant plus prenante qu’au nombre des premières conférences qui se sont tenues durant ce « day one », se tenait une table ronde ayant pour thème sécurité et réseaux Scada et intitulé « Pourquoi les RSSI ne s’emparent-ils pas de ce sujet critique ? ». Un sujet qui n’aurait certainement pas fait salle comble il y a un an et qui, dans cette atmosphère d’après-stuxnet, d’après-première-véritable-opération-de-cyberguerre, posait enfin clairement la question : que peut-on protéger dans une infrastructure nationale ou industrielle d’importance stratégique.
Pour y répondre, Pascal Lointier, du Clusif, qui joue les Monsieur Loyal et brosse à grands traits le tableau des menaces possibles, l’accompagnent Cyril Moneron, DSSI du groupe Saint Gobain, Laurent Beaussart, Directeur Adjoint des systèmes opérationnels et RSSI de Cofiroute et Sylvain Thiry, RSSI à la SNCF.
Il serait long et vain de retranscrire par le détail les échanges de ces participants. D’autant plus qu’à aucun moment il n’y a eu contradiction ou divergence d’opinion entre participants : la lutte contre le risque Scada passe avant tout par une résolution d’une multitude de problèmes culturels. De culture d’entreprise, tout d’abord, comme le fait remarquer Silvain Thiry, citant l’exemple de la SNCF au sein de laquelle tout est fait pour que la sécurité soit polarisée sur les personne plus que sur les systèmes d’information (ce qui, dans le domaine du transport, peut sembler logique). Problème culturel également sur le plan organisationnel car si souvent, dans l’informatique « informaticienne », la sécurité (en l’occurrence le rssi) dépend souvent de la DSI, c’est plus rarement le cas dans le cadre des DSI industrielles. Problèmes de compétence également, car la protection d’une infrastructure industrielle ou de communication (la gestion de la sécurité des Autoroute est édifiante sur ce point) passe par une maîtrise pluridisciplinaire, polytechnique au sens premier du terme, qui est parfois fort éloignée des considérations informatiques ou logicielles. Problèmes de taille, enfin, car dès que l’on touche aux infrastructures d’envergure nationale, les capteurs, les actuateurs, de la barrière automatique à la caméra de surveillance en passant par la jauge de température, se comptent par dizaines de milliers, fournissant des flux dont l’interprétation repose sur des règles différentes pour chaque cas. Trois dépassements de point de consigne ou trois pannes de capteur éparses au cours d’une journée n’ont pas du tout la même signification ni les mêmes implications de risques que ces trois mêmes pannes ou alertes constatées ou relevées dans un même secteur géographique ou sur une chaine de traitement de processus unique. Ce cas typique d’une même information qui peut, selon les cas, générer des réactions différentes nécessite à la fois des méthodes, mais aussi des connaissances métier très vastes.
Mais ce n’est pas le pire.
« Autrefois », il n’y a pas plus de 6 ou 10 ans, le pilotage de processus industriels s’opérait principalement à grand renforts d’automates programmables, eux-mêmes généralement reliés à des systèmes de calcul de type « mini » ou à des microordinateurs relativement spécialisés. « Aujourd’hui, précisent les intervenants, nous utilisons des systèmes standard avec des noyaux Linux ou Windows (cas le plus fréquent) des réseaux non plus basés sur de architectures radio spéciales mais sur des routeurs wifi standards, des PDA, des cartes RFID classiques identiques aux MyFare utilisées dans les transports en commun, le tout « tournant » sur des PC qui ne sont plus « durcis » comme cela a longtemps été la tradition… tout çà étant généralement dicté par des contraintes budgétaires et un souci d’économie. Une normalisation des outils qui ajoute une part de risque informatique inconnue jusqu’à présent.
A ce choc technologique s’ajoute le choc des langages et des cultures, celles des informaticiens qui est parfois très éloignée de celles des automaticiens, eux-mêmes parfois pas toujours au fait de la façon de voir les choses des électroniciens, des mécaniciens et des chimistes. Comment établir une politique de sécurité unifiée et cohérente, capable d’assurer un dialogue et des bonnes pratique n’offrant aucune (ou peu) point de vulnérabilité aux « jointures » technologiques, là ou l’informatique laisse le pas à l’automatisme, à la pneumatique, voir même à l’électricité et aux courants forts ? c’est un long travail à la fois de communication, de formation, de dialogue, qui est loin d’aboutir.
Mais grâce à Stuxnet, pourrait-on dire, l’on assiste à un réveil des consciences. Ce rootkit a prouvé qu’un vecteur d’attaque Scada n’était pas un « malware comme les autres, qu’il faut combattre avec les moyens traditionnels ». Stuxnet est aux réseaux Scada ce que Vendredi 13 fut à la microinformatique en général, un électrochoc que l’on espère salvateur.
