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