Ce n’est pas un souhait, mais un constat : tout porte à croire qu’en 2012, les hackers vont pouvoir s’en donner à cœur joie sur les systèmes d’information industriels.

Voici les deux raisons qui m’amènent à ce constat, et autant faire ce peu, quelques idées pour tenter d’y remédier !

Premier constat : un certain retard à l’allumage

Il faut bien reconnaître que si le petit monde de la sécurité s’inquiète de l’état des lieux de la cybersécurité industrielle, c’est très loin d’être le cas des responsables en charge des installations ciblées. Il est relativement facile cependant de les inquiéter en leur exposant les événements récents.

Petit rappel historique : l’année 2011

J’ai posté sur ce blog la plupart des points qui me semblaient essentiels :

• le nombre extra-ordinaire des révélations de failles sur les SCADAs et automates
• les « proof of concepts » qui ont démontré la possibilité d’attaquer des systèmes « déconnectés », alors qu’on croyait jusqu’il y a peu que les systèmes isolés étaient protégés (certains le croient encore…)

A noter aussi le développement d’organisations structurées capable de mener des attaques planifiées à long terme, dont je ne me suis guère fait l’écho sur ce blog, que ce soit :

• Organisations d’état : Israël, Chine, Iran, USA bien sûr, mais selon des études récentes, les principaux états ayant une force de dissuasion à l’international montent des équipes de hackers pour bien sûr défendre, mais aussi pour mener des attaques,
• « Hacktivistes » (pour utiliser cet excellent néogologisme) : Anonymous, Lulzsec, Akincilar, et ceux que l’on ne connait pas encore, par exemple ceux qui sont à l’origine des attaques actuelles contre Israël.

Pour ces deux types d’organisations, la motivation n’étant pas financière, le risque est plus élevé car l’objectif de ces organisations n’est pas de prendre en otage, mais de blesser ou tuer (métaphore un peu martiale mais qui me semble adaptée) : il n’est pas utile de communiquer avec sa cible, et donc on peut rester anonyme, or justement les attaques informatiques facilitent l’anonymat (on peut facilement masquer les IPs « source » des attaquants).

Pourquoi les dirigeants des installations industrielles ne sont-ils pas mieux informés ?

Les signaux d’alerte que je rappelle ci-dessus ne sont malheureusement pas transmis aux responsables des établissements visés. D’une part le « whistle blowing » n’est pas encore très bien accepté en France, d’autre part il faut des convictions et donc une bonne maitrise du sujet pour prendre le risque d’alerter sa hiérarchie. Or il y a encore relativement peu de personnes formées aux enjeux de la cybersécurité industrielle : les courroies de transmission ne sont pas en place.

Par ailleurs,  la conjoncture générale n’est pas favorable : l’industrie dans les pays occidentaux se porte comme elle peut, la réduction des coûts est au programme de tous les comités de direction, et quand l’installation est complexe (suffisamment pour être facile à attaquer), c’est déjà un effort de tous les jours de parvenir à la faire fonctionner, notamment en remplaçant assez rapidement les pièces défectueuses étant donnés les effectifs de maintenance réduits, sans parler de la maintenance préventive…

Dans ce contexte, le collaborateur qui fait une présentation sur une histoire assez obscure qui se passe en Iran, qui explique que ça pourrait se passer demain ici, et qu’il faut dépenser des dizaines de milliers d’euros pour s’en prémunir, a forcément un succès très limité.

Quelquefois un patron un peu « geek » s’inquiète réellement, ou bien il a dans son « board » quelqu’un qui s’inquiète, ou bien l’ANSSI s’en mêle… et il décide d’agir de manière significative . Dans ce cas il y a un autre problème auquel il va devoir faire face, comme détaillé dans le chapitre suivant.

Avant de présenter ce second constat, voici tout de même quelques actions peu coûteuses, qu’il est bon de réaliser dans tous les cas :

• Sensibiliser le personnel (à minima les équipes qualité, informatique, gestion du risque) au sujet de la cybersécurité industrielle. Évidemment il y a un petit problème : le manque de formations ! SANS Institute propose des modules de pen-test industriel via HSC en France (pas encore testé, j’aimerais bien !), ISA France propose une formation sur la norme ISA 99 - IEC 62443 qui adresse tous les sujets sur une journée.
• Se tenir informé : consulter ce blog par exemple, et surtout les documents liés (la langue, en environnement industriel, est souvent un obstacle, à ce propos je rappelle que je maintiens à jour une sélection des documents pertinents en français)
• Exprimer des exigences auprès des fournisseurs : tant que les « clients » ne demanderont rien, les fournisseurs ne feront rien. Un exemple typique est la réaction de Schneider Electric suite à l’alerte niveau CVSS 10/10 du CERT ICS américain en décembre 2011, sur l’ensemble des automates de la gamme : un chercheur a posté sur internet la méthode pour désassembler, modifier, et recharger le firmware des cartes réseau des automates de la marque, grâce aux mots de passe « hard-codés » dont il donne la liste… A ce jour, Schneider n’a toujours pas communiqué. J’ai pris cet exemple car il est récent, mais Siemens a eu le même problème l’été dernier, et rien ne permet de supposer que les autres fournisseurs aient des pratiques de gestion des alertes de sécurité plus élaborées.

Second constat : un peu de réflexion n’entraverait pas l’action

Le problème, quand la décision d’agir est prise, est de choisir les actions à prendre. Et là, malheureusement, on a un autre obstacle à la mise en œuvre réfléchie de mesures de sécurité adaptées.

Idéalement, comment lancer un programme de sécurisation d’un site industriel critique ?

Tout d’abord, il faudrait mener une analyse de risque adaptée à l’environnement industriel, puis utiliser un référentiel adapté à l’industrie pour choisir les mesures à mettre en œuvre, et enfin démarrer un projet bien conçu, donnant toute sa part à la gestion du changement, avec actions de sensibilisation, messages clairs du management, et désignation d’un chef de projet expérimenté et  reconnu par les employés de l’installation.

Cela semble irait de soi si les ressources mentionnées ci-dessus étaient disponibles.

En effet, il n’y a pas encore de méthode officielle et bien acceptée d’analyse des risques en environnement industriel. Il est cependant possible de la construire, soit en prenant le meilleur d’EBIOS et en l’adaptant intelligemment (des gens savent faire cela), soit en construisant une approche pragmatique adaptée à l’environnement industriel, en s’inspirant des approches américaines (DHS, NIST).

Il faut ensuite des personnes compétentes en sécurité des SI, avec une vraie expérience industrielle.  Dans les faits, ce type de projet est affecté aux profils disponibles, soit au choix :

• techniciens et ingénieurs de la DSI, habitués à déployer et maintenir des mesures de sécurité du SI de gestion (backup, réseau, sécurité des postes Windows, anti-virus…)
• consultants « sécurité du SI », très à l’aise avec ISO 2700x, EBIOS, MEHARI, voire quelquefois certifiés CISSP, qui vont dérouler les méthodes qu’ils connaissent, et qui fonctionnent bien en environnement « SI de gestion ».

Deux problèmes avec les approches « SI de gestion »

Comme indiqué ci-dessus, en l’absence de compétences sur la cybersécurité industrielle, on utilise souvent des compétences et des référentiels des SI de gestion. Or l’utilisation des méthodes des « SI de gestion » en environnement industriel présente deux inconvénients :

• les mesures préconisées par les référentiels SI de gestion (27002, NIST 800-53…) ne sont pas toutes adaptées à l’environnement industriel, quelquefois contre-productives (impactant négativement la productivité), voire carrément dangereuses (risques sur la sûreté). Voici quelques exemples de mesures discutables : mettre des pare-feux mal gérés sur des flux critiques, mettre des mots de passe de plus de 15 caractères sur des postes opérateurs, mettre un H-IDS sur un poste temps réel, etc.
• certaines vulnérabilités spécifiques au contrôle commande sont ignorées des référentiels des SI de gestion. Il en résulte des « trous dans la raquette », ce qui réduit fortement l’impact du projet de sécurisation. Voici quelques exemples de spécificités non prises en compte : les protocoles non sécurisés (dnp3, modbus…), l’intervention régulière de nombreux sous-traitants, les failles des automates et SCADAs, la difficulté à déployer des « patches » sur un environnement de production, etc.

Je dois reconnaître que les référentiels adaptés à l’environnement industriel se font attendre, mais les versions « draft » sont disponibles, et déjà exploitables. Et si l’on parle Anglais, les normes américaines sont disponibles, et elles sont d’ailleurs obligatoires outre-Atlantique.

Conclusion : que faire ?

Il est urgent d’agir : les systèmes industriels sont peu protégés, fragiles, et actuellement visés.

Il faut cependant bien préparer ces actions : actions de sensibilisation pour faire accepter des mesures qui vont impacter au moins momentanément la productivité, analyse de risques adaptée et réalisée avant toute mise en place de mesures, planification concertée avec l’exploitant pour minimiser l’impact de ces actions, et surtout, inscription des mesures de sécurité dans une dynamique, et pas seulement dans des actions « coup de poing ».

Il est essentiel en effet de rappeler que la sécurité est un processus dynamique,  comme la qualité. Il est tentant, pour montrer que « l’on fait quelque chose » , de monter un projet ponctuel et bien médiatisé en interne pour montrer que l’on prend le sujet au sérieux. Et ensuite de considérer que c’est ok, ça y est, on est sécurisé.

Il faut inscrire la cybersécurité dans le processus de management, et donc dans les budgets et ressources récurrentes, et pas seulement dans une action « coup de poing ». Les Etats-Unis nous donnent encore une fois l’exemple : une étude a mesuré le coût des mesures NERC-CIP, pour les installations qui les ont mises en œuvre, à plus de 2M$ la première année, et environ 1,5M$ récurrents. C’est inscrit dans le budget de fonctionnement normal des installations (essentiellement les centrales nucléaires).

Faire un effort budgétaire exceptionnel est une chose, impacter durablement les marges en est une autre. Et pourtant c’est aujourd’hui ce qui doit devenir la norme dans l’industrie, comme dans l’informatique de gestion (environ 5% du budget SI, rappelons-le).

A défaut ce n’est pas seulement 2012 qui sera une bonne année pour les hackers, mais aussi les suivantes !

Tags: France, Industriel, Menaces, Risques