Inspections de cybersécurité et incidents mineurs dans des centrales nucléaires aux USA

J'ai écrit, au début de l'année, un article consacré à une série d'incidents touchant des centrales nucléaires américaines via des Systèmes d'Information (SI) ou, cas le pire, une seul et unique machine de pilotage, souvent "oubliée", de type SCADA ou DCS.

Cet article montrait que, même sans intention malveillante, des dysfonctionnements et surtout de simples erreurs pouvaient causer des incidents de gravité sérieuse. Qui, sans dispositifs opérants de sûreté voire une certaine part de chance, auraient pu devenir catastrophiques ! 

De François Perrin à Stuxnet, les centrales nucléaires (cyber) vulnérables

Lunaire et maladroit compulsif, “Le Grand Blond” (and Co) nous a souvent fait rire et sourire, attendris par cette candeur désarmante et ce comique de situation, souvent désopilant. Transposons maintenant ce personnage dans la réalité, en plein cœur de situations ubuesques mais aux conséquences potentiellement catastrophiques ! Nul besoin de cyberarmes complexes quand de simples “cyber-gags” provoquent des conséquences que ne renieraient pas certains mouvements extrémistes ou terroristes.

Edwin I. Hatch Nuclear Plant, Unit 2

Centrale Nucléaire de Hatch, près de Baxley, Etat de Géorgie, USA.

Lorsqu’il débute son service ce 7 mars 2008, l’un des ingénieurs de la Southwest Company ne sait pas encore que l’une de ses tâches du jour, en apparence banale, va provoquer un incident grave sur le réacteur n°2. A l’origine, une simple mise à jour  sur l’un des ordinateurs opérant sur le réseau informatique de la centrale. Exception faite que cette ordinateur est tout de même particulier puisqu’il est l’une des interfaces SCADA de surveillance : il centralise des données servant à divers diagnostics et collecte les taux de différents composants chimiques du système primaire de contrôle du réacteur. La mise à jour logicielle est malgré tout importante puisqu’elle doit permettre la synchronisation des données entre différents systèmes de différents réseaux.

L’enquête de la NRC (Nuclear Regulatory Commission, l’équivalent américain de l’ASN) déterminera que le redémarrage de la machine après la mise à jour a aussi remis à zéro l’ensemble des données du système de contrôle. C’est lors de cette phase que les dispositifs de sécurité, interprétant correctement des données erronées, ont considéré qu’il y avait une fuite dans la “piscine”, cet énorme bassin d’eau permettant le refroidissement des barres du combustible nucléaire !

La conséquence logique fut que le système exécuta les instructions prévues pour un tel cas : le réacteur nucléaire fut immédiatement mis à l’arrêt d’urgence, arrêt qui dura 48 heures, le temps de comprendre l’origine de l’incident et d’autoriser un redémarrage sûr. La morale de cette histoire, cependant, serait que l’incident de Hatch illustre le type de conséquences inattendues qui peuvent se produire quand de l’informatique dite d’entreprise ou que des logiciels “pris sur étagère” (COTS) sont interfacés avec des systèmes de contrôle industriels, sans considérations de design ou d’intégration adéquates. Il faut aussi souligner que cet incident a peut-être été “chanceux” dans le sens où les dispositifs de sécurité ont fonctionné. A l’inverse, quel enchaînement de conséquences dramatiques auraient pu se produire dans le cas où ces mêmes dispositifs n’avaient pas exactement réagi comme prévu ?

Browns Ferry Nuclear Plant, Unit 3

Centrale Nucléaire de Brown Ferries, près d’Athens, Alabama, USA.

Ce qui demeure terriblement gênant avec l’incident de Hatch, c’est qu’il est loin d’être unique ! Un peu plus de 6 mois auparavant, un arrêt d’urgence (et manuel cette fois-ci !) se produisit sur le 3ème réacteur de la centrale de Brown Ferries. En cause, deux équipements cruciaux : le contrôleur du condensateur-déminéralisateur qui est un PLC (Programmable Logic Controler) et les pompes de recirculation qui reposent sur des VFD (Variable Frequency Drives).

Retenons simplement que ces deux équipements, essentiels au bon fonctionnement du réacteur, embarquent des micro-processeurs qui peuvent communiquer des données via de l’Ethernet (la couche liaison de données du modèle OSI). Là est le problème puisque les paquets de données sont broadcastés (diffusées) à tous les récepteurs connectés, sans distinction. C’est ensuite à chacun d’entre eux d’analyser chacun des paquets et de le conserver s’il lui est adressé.

Hors, il est apparu que le réseau de contrôle de la centrale produisait plus de trafic que ne pouvaient en absorber les contrôleurs PLC et VFD ! Il est également possible que ce soit le contrôleur PLC qui ait malfonctionné en inondant (flooding) le réseau d’un trafic colossal, saturant puis désactivant les contrôleurs VFD. Quoiqu’il en soit, les tests menés durant l’enquête n’ont pas apporté de réponses satisfaisantes permettant de comprendre l’origine exacte de l’incident. Ce qui en soi est inquiétant puisque cela pose le problème d’absence de reproductibilité du phénomène donc d’identification des causes ou de l’enchaînement des causes.

Entre specticisme et alarmisme, quelles leçons ?

Défauts d’intégration des problématiques de sécurité dès la conception, absence de tests de non-régression (et tests en plate-forme de pré-production) ou inconsciences diverses montrent qu’il n’est nul besoin de développer un programme offensif, long et coûteux, les fameuses cyberarmes, pour provoquer des incidents qui, chance aidant, ne sont jamais passés du stade “inquiétant mais sous contrôle” à celui de “catastrophe écologique majeure”. Fukushima Daïshi étant passé par là, il est normal d’envisager des scénarii de menaces exceptionnels qui ne sont pas qu’environnementaux (au “hasard”, un tremblement de terre  suivi d’un tsunami) ou d’une incroyable complexité malveillante (Stuxnet).

Entre le sceptique et l’alarmiste, il est une fois encore question de pondération mais aussi d’honnêteté intellectuelle : une centrale nucléaire serait protégée de toute tentative de cyberattaque parce qu’aucun ordinateur n’est relié à Internet ou que les systèmes sont particuliers, ce que l’on appelle dans le jargon “propriétaires” ? Incompétence ! Il suffit simplement de se rappeler les deux incidents précédemment cités* : l’interopérabilité dans la communication entre systèmes dans un cas, un défaut de conception dans l’autre ou même Stuxnet, qui a pu se propager à partir de simples clés USB préalablement préparées. A l’inverse, une cyberattaque peut-elle se produire demain, l’état des systèmes de contrôle étant d’une telle vulnérabilité qu’une attaque serait plutôt simple à conduire ?

En réalité, les spécialistes s’accordent à dire que l’interconnexion de systèmes assez différents, leur hétérogénéité et d’autres subtilités ne rendent pas impossible de tels scénarii mais qu’ils sont difficiles et complexes. Jusqu’à présent, le seul exemple valable, Stuxnet et ses déclinaisons (Duqu) est le fait d’un ou plusieurs États qui sont les seuls acteurs à posséder le savoir, les ressources, les moyens et les compétences et qui encouragent en réalité, ou plutôt en dépit des annonces, de nouvelles stratégies dans le cyberespace.

Doit-on s’en féliciter ou, au contraire, s’en effrayer ? Un peu des deux, sans doute, lorsque l’on essaye de mieux cerner la problématique plus globale des infrastructures critiques et des SCADA en particulier. Si un certain nombre d’Etats se sont emparés du sujet ces dernières années (USA, France, Europe), on peut constater que le volet législatif et réglementaire, plutôt bien fourni, a été finalement franchi pour arriver actuellement à une phase opérationnelle et d’améliorations continues (audits / pentests / …). Si tel n’est pas le cas, il est plus que temps d’agir.

* j’ai volontairement omis d’autres exemples basés sur des infections virales (Slammer, par exemple) ayant également conduit à des incidents significatifs. Douze années se sont depuis écoulées. Et pourtant...

---

Pour aller plus loin (en anglais) :

Cyber incident blamed for nuclear power plant shutdown

The Vulnerability of Nuclear Facilities to Cyber Attack (pdf) – Brent Kesler

---

Cet article a également été publié sur le site de l'Alliance Géostratégique

Complexité et beauté de Stuxnet

Wired a publié vendredi 11 février un article bien documenté sur la typologie d'introduction de Stuxnet avant qu'il ne s'active et ne cause des dommages, difficilement quantifiés depuis, au sein du programme nucléaire iranien. La méthodologie retenue est somme toute "logique" puisque ne pouvant utiliser l'internet, seuls restent des vecteurs physiques de type support amovible (clé USB) afin de contaminer l'un des réseaux locaux (mais isolé) du programme nucléaire.

Cinq Six organisations/groupes, dont on ne sait rien pour le moment mais dont on peut supposer un lien direct ou indirect avec le programme nucléaire, ont été ciblées et ont fait l'objet d'attaques temporelles successives. Les deux premières vagues ont eu lieu en juin et en juillet 2009 puis il y a eu neuf mois d'inactivité complète avant que trois autres vagues n'aient lieu (mars, avril et mai 2010).

Symantec, qui a mené ces analyses, est capable de dire que c'est l'attaque conduite en mars 2010 qui a obtenu le taux de réussite le plus important (69%). Deux autres informations intéressantes émergent du rapport : il n'a fallu qu'une douzaine d'heures entre l'introduction réussie de Stuxnet et que sa charge devienne active (du point de vue logiciel). Enfin, Stuxnet semble avoir été conçu pour être uniquement "LAN-based" ("réseau local") afin de ne pas s'échapper into the wild (dans l'Internet).

Si ces informations viennent à être confirmées, on peut de nouveau souligner la grande complexité  opératoire de ce code malveillant high-tech. Enfin, je signale qu'une partie du code décompilé de Stuxnet est disponible ici. A projeter le samedi soir en soirée, pour faire son geek ! :)

D'ailleurs, en parlant de geek, la toile bruisse ces dernières heures d'une rumeur insistante : les Anonymous auraient déclaré être entrés en possession de Stuxnet. On imagine aisément la vision d'Apocalypse relayée par certains média. La bonne question à se poser serait : qui a intérêt à quoi ? Je pense que l'on assiste à de la désinformation voire de l'intoxication informationnelle. Cet article, sérieux et étayé, semble confirmer mon sentiment.

Lutter contre Stuxnet peut entraîner la mort

Malgré le titre légèrement ironique de ce billet, il semble très probable que l'ultra-sophistiqué malware Stuxnet a fait ses premières "vraies" victimes, hier (lundi 29 novembre 2010), en Iran. Les professeurs Majid Shahriari et Feredoun Abbassi-Davani, accompagnés de leurs épouses respectives, circulaient dans leurs véhicules lorsque qu'une ou deux équipes à moto ont attaqué les véhicules. La première équipe aurait apparemment réussi à glisser une bombe magnétiques contre le véhicule, déclenchée à distance de sécurité, tandis que l'autre véhicule aurait été mitraillé. 

La photo parue dans la presse laisse peu de doute sur le mitraillage dans lequel le professeur Shahriari a été tué, les autres personnes étant blessés sans que l'on sache l'état de ces blessures. En tout état de cause, ces attentats ne sont pas le fruit du hasard, les deux professeurs travaillant pour le programme nucléaire iranien. Mais le professeur tué n'est pas n'importe qui puisqu'il coordonnait la lutte contre Stuxnet au sein du programme nucléaire et des réseaux militaires. Je donnerai des informations supplémentaires prochainement sur l'efficacité de Stuxnet qui semble de plus en plus avérée : le site d'enrichissement de Natanz où tournent plusieurs centaines de centrifugeuses a dû être suspendu durant 6 jours du 16 au 22 novembre tandis qu'un important exercice de défense aérienne a dû être écourté le 17 novembre. Au-delà donc des installations nucléaires, il semble que cette fois-ci le ou les systèmes radar aient indiqué des pistes "fantômes".

Les deux attaques quasi-simultanées d'hier ont été réalisées de manière professionnelles dans l'une des zones normalement les plus surveillées de Téhéran. Je ne m'étendrai pas sur les commanditaires possibles mêmes si les regards se tourneront forcément vers Israël. Dans tous les cas, le décès de celui qui luttait contre Stuxnet est un coup dur pour le programme nucléaire iranien. A l'heure où Wikileaks fait parler de lui, l'Iran semble de plus en plus la cible de moyens divers et complémentaires d'ordre non conventionnels, sophistiqués et ciblés.

L'article traitant des attaques d'hier peut être lu ici (en anglais).

Incident à la centrale nucléaire d'Heysham 1 (2/2)

L'incident s'est produit le jour ou EDF a cédé le marché de la distribution d'énergie (presque 8 millions de clients à Londres, dans l'est et le sud-est de l'Angleterre) au groupe Cheung Kong basé à Hong Kong. Si l'on se penche quelques instants sur cette entreprise (rapport annuel 2009 de CK - Holdings - Ltd) on a la composition page 142 des principaux actionnaires du conglomérat : 

- Bank of China  
- Hang Seng Bank (Chine)

- Industrial and Commercial Bank of China  
- China Merchants Bank
- Bank of Communications Co., Ltd (Chine)

On relativisera néanmoins avec la présence britannique (HSBC), canadienne (CIBC) et française (BNP).

En page 26 se trouvent les biographies des responsables clefs visibles :

- Ka-Shing LI est le président fondateur du Groupe, d'origine et de nationalité chinoise, détenteur des principaux avoirs de Hutchison Wampoa (entité du conglomérat dans laquelle on trouve en particulier la branche s'occupant de génération énergétique, distribution, infrastructures, etc.).

- Victor (Tzar-Kuoi) LI, fils de son père président, est le managing director. Origine chinoise, nationalisé canadien.

- Le staff est à 100% d'origine chinoise, je ne saurai en dire autant des nationalité en cours. 

Au passage, on remarquera les fonctions de :

- Davy (Sun Keung) CHUNG, executive director depuis 1993 (pas mal pour un simple architecte !), membre du PC chinois (la section exacte du Parti est indiquée).

- Siu Hon LEUNG, non executive Director, est représentant à la Haute Court de la région administrative spéciale de Hong Kong et officier officiel du Parti.

- Comme on fait ça en famille, on retrouve son cousin Roland (Kun Chee) CHOW, également représentant de l'administration chinoise de Hong Kong. 
- Katherine (Siu Lin) HUNG, Audit du Groupe, pointe au PC chinois (section précise encore une fois indiquée).

- pareil pour Rosanna (…) WONG.

Au sujet de la centrale de Heysham constituée de deux usines (0,76TWh et 8,32Twh) à deux blocs réacteurs (soit 4 réacteurs), on s'étonnera peu de savoir que le site doit être rénové prochainement (arrêt de Heysham 1 en 2013 ou 2014) pour accueillir une nouvelle infrastructure plus puissante et plus moderne (d'où les mouvements velociraptoresques Areva / Rosatom (russe) avec les chinois en embuscade… qui eux ont déjà remporté un gros point avec la reprise du site à EDF.

Les mouvements de ces derniers jours pour la gestion de la production et de la distribution de l'énergie au Royaume-Uni illustrent parfaitement la partie d'échec qui se déroule en Europe. Partie à plusieurs niveaux et entre plusieurs acteurs : Siemens et Areva frontalement pour prendre le leadership au niveau continental et se positionner en éventuel numéro 1 mondial, EDF et Rosatom en embuscade avec des entreprises chinoises disposant de capitaux très importants.

Que l'arrêt d'Heysham 1 se soit produit le jour de son rachat est une coïncidence intrigante qui ne doit pas faire oublier que, parfois ou souvent, les coïncidences ne sont que ce à quoi elles ressemblent. On peut néanmoins affirmer, sans jugement de valeur aucun, que l'approvisionnement énergétique de la zone urbaine londonienne n'est plus sous contrôle national ni même européen mais dorénavant chinois. Affaire à suivre.

Incident à la centrale nucléaire d'Heysham 1 (1/2)

Le dimanche 31 octobre 2010, la tranche 1 de la centrale nucléaire d'Heysham a été mise hors de service suite à une "interruption imprévue". Opérée par British Energy, détenue pour partie par EDF Energy PLC la filiale britannique d'EDF, il n'aura pas fallu longtemps pour que certains spéculateurs s'interrogent sur un rapport éventuel : systèmes de contrôles Siemens + Stuxnet = clash ? 

En tout cas le blog The Firewall de Jeffrey Carr sur le site de Forbes, expert qui a gagné en audience par ses interventions antérieures sur Stuxnet, n'aura pas mis longtemps à franchir le Rubicon. Dès le lendemain, on pouvait trouver son article spéculant sur un lien possible entre l'interruption d'Heysham 1 et le code sophistiqué et malveillant, tube de l'été et de l'automne.

Je n'apporterai aucun commentaire spéculant dans un sens ou dans l'autre, me bornant à livrer les faits, dont le démenti de l'un(e) des porte-paroles de la compagnie en date également du 1er novembre.

Au-delà d'une affaire qui, somme toute, n'a probablement pas d'origine malveillante, il faut noter ce que dit Jeffrey Carr. Et ce qu'il n'ose pas non plus dire. La suite est dans la partie 2 de ce billet...