Impact de Slammer sur la centrale nucléaire de l'Ohio

Le 25 janvier 2003, la centrale nucléaire de Davis-Besse a été infectée par le ver MS SQL Server 2000. L'infection a provoqué une surcharge de données sur le réseau du site, entraînant l'incapacité des ordinateurs à communiquer entre eux. Le réseau d’entreprise de First Energy Nuclear (l’exploitant), qui est relié au réseau de la centrale de Davis-Besse, est connecté aux réseaux externes via un pare-feu. Un pare-feu est un ou plusieurs systèmes qui appliquent une politique de contrôle d'accès entre les réseaux. Parmi les nombreuses politiques de contrôle d’accès appliquées par le pare-feu d’entreprise de Davis-Besse figurait la politique consistant à interdire l’accès au réseau à toute donnée utilisant le protocole UDP en fermant le port 1434 (MSSQL) du pare-feu. Cette politique aurait protégé les réseaux de Davis-Besse contre l’infection par le ver MS SQL, sauf que le réseau de l’entreprise disposait d’une connexion T1 derrière le pare-feu qui fournissait un chemin permettant au ver d’entrer dans le système. Cette ligne T1 était utilisée par l’un des consultants du titulaire qui fournissait un logiciel d’application fonctionnant sur un serveur. Cette connexion a contourné toutes les politiques de contrôle d'accès appliquées par le pare-feu de l'entreprise, y compris la politique visant à empêcher les données utilisant UDP d'entrer dans le réseau de l'entreprise. Le serveur réseau de l’entreprise du consultant autorisait l’utilisation du protocole UDP pour les transferts de données et était infecté par le ver MS SQL. Lorsque le consultant a établi une connexion par ligne T1 sur le site d’entreprise du titulaire de licence, cette action a ouvert un chemin par lequel le ver qui a infecté le serveur d’entreprise du consultant a été envoyé au réseau d’entreprise du titulaire de licence via la ligne T1. Le ver a ensuite infecté de manière aléatoire tous les serveurs du réseau d'entreprise dont le port 1434 était ouvert. Étant donné que le ver MS SQL résidait uniquement dans la mémoire, l’arrêt du serveur a supprimé le ver de la mémoire du serveur, débarrassant ainsi le serveur de l’infection. Le titulaire de licence a isolé le serveur du réseau du site, installé le correctif de sécurité MS et reconnecté le serveur au réseau du site.

La lenteur de traitement informatique a commencé dans la matinée et vers 16h50, le système d'affichage des paramètres de sécurité (SPDS) est devenu indisponible et est resté indisponible pendant 4 heures 50 minutes. À 17 h 13, l'ordinateur de procédé de l'usine a été perdu et est resté indisponible pendant 6 heures et 9 minutes. Bien que les exploitants aient été grevés par ces pertes, l'événement n'a pas été jugé significatif puisque les fonctions de contrôle et de protection de l'usine n'ont pas été affectées.

En réponse à cet événement, Davis-Besse a mis en œuvre les actions correctives suivantes : (1) a exigé que les services réseau documentent toutes les connexions externes au réseau interne, (2) a installé le correctif de sécurité pour la vulnérabilité MS SQL Server 2000, (3) a installé un pare-feu entre le réseau de l'usine et le réseau de l'entreprise, (4) a établi une exigence de surveillance et de filtrage des données entrant dans le réseau de l'usine selon les mêmes normes que le pare-feu de l'entreprise et (5) a mis en œuvre un processus permettant au personnel d'ingénierie informatique d'examiner les correctifs de sécurité pour les systèmes pris en charge et de les installer dans un délai acceptable. délai.