Ericsson a fait d'un certificat de cœur de réseau mobile expiré un test de responsabilité de continuité transfrontalière

Résumé

• Un certificat de sécurité dans deux versions du logiciel Ericsson SGSN-MME a expiré à 04h30 (heure britannique) le 6 décembre 2018, perturbant plusieurs opérateurs et pays via une dépendance partagée du cœur de réseau mobile.
• Les archives publiques soutiennent une division claire du contrôle pratique: Ericsson contrôlait le certificat intégré et le cycle de vie du logiciel; les opérateurs contrôlaient l'architecture de déploiement, la réponse aux incidents, les communications avec les clients et la restauration du service; les régulateurs contrôlaient l'évaluation statutaire et les attentes futures en matière d'assurance.
• Ofcom a conclu qu'O2 avait pris des mesures appropriées et n'avait pas enfreint l'obligation de sécurité britannique applicable. Cette conclusion n'a pas effacé la leçon plus large qu'un fournisseur ne peut pas sous-traiter sa responsabilité légale ni traiter le certificat non divulgué d'un fournisseur comme le problème de continuité de quelqu'un d'autre.
• Le régulateur japonais a traité la panne de SoftBank comme un accident majeur affectant environ 30,6 millions d'utilisateurs et a émis un avertissement et des directives administratives écrites. SoftBank a décrit publiquement des mesures de restauration, d'inventaire, de procédure de récupération et de multi-fournisseurs.
• Le registre public des réparations est important mais incomplet. Il n'inclut pas le rapport final d'analyse des causes d'Ericsson, l'identité du certificat et l'historique de propriété, la validation indépendante du logiciel modifié, ou la preuve que chaque installation similaire exposée a été corrigée.
• La responsabilité durable nécessite un inventaire des expirations, une propriété nommée, des contrôles de cycle de vie avec alarmes indépendantes, une diversité des domaines de défaillance, une récupération répétée, un avis client tenant compte des dépendances et des preuves qui survivent aux assurances de gestion.

L'incident était programmé par une date, mais ses conséquences étaient architecturales

À 04h30 au Royaume-Uni le 6 décembre 2018, un certificat de sécurité intégré a atteint sa date d'expiration. Le réseau mobile d'O2 a commencé à perdre le service. Au Japon, où le même instant était 13h30, le réseau de SoftBank est tombé en panne quelques minutes plus tard.

Ericsson a finalement déclaré que les perturbations concernaient certains nœuds du cœur de réseau utilisés par un nombre limité de clients dans plusieurs pays, que deux versions particulières de son logiciel Serving GPRS Support Node et Mobility Management Entité étaient impliquées, et qu'un certificat expiré était le principal problème identifié dans son analyse initiale des causes. Sa mise à jour officielle distribuée via Cision a indiqué que le logiciel défectueux était en cours de déclassement et que la plupart des services affectés avaient été rétablis dans la journée.

Cette description établit le déclencheur, mais elle n'explique pas entièrement le problème de responsabilité. Les certificats sont des identifiants limités dans le temps. Selon le profil des certificats X.509 et de révocation de certificats de l'Internet Engineering Task Force,RFC 5280, un certificat porte un intervalle de validité défini parnotBeforeetnotAfter; un système qui s'y fie doit être capable de déterminer si le certificat est valide au moment pertinent. Le rôle précis du certificat d'Ericsson n'a pas été documenté publiquement avec assez de détails pour reconstruire son chemin de validation. Ce qui est confirmé, c'est que son expiration a interagi avec le logiciel d'une manière qui a arrêté les fonctions du cœur de réseau. L'instant de l'expiration était déterministe. Les conséquences nationales et transfrontalières étaient le produit de l'endroit où se trouvait le logiciel, de l'uniformité de son déploiement et des choix de récupération disponibles après la panne.

Le SGSN-MME concerné n'était pas une application optionnelle orientée client en périphérie du réseau. La description actuelle du produit SGSN-MME par Ericsson,disponible sur son site, décrit une fonction de contrôle du cœur de paquets prenant en charge la gestion de la mobilité et des sessions sur les accès GSM, WCDMA et LTE. Cette description actuelle ne peut pas, à elle seule, établir chaque détail de la conception d'un opérateur en 2018. Elle explique pourquoi une défaillance dans cette classe de composants peut avoir des effets bien au-delà d'un seul serveur: la fonction aide les appareils à s'attacher, à rester joignables et à établir des sessions de données. Un défaut logiciel commun répliqué sur les nœuds censés fournir une capacité ou une résilience géographique peut donc vaincre la redondance physique au même instant.

Cette distinction est importante. L'expiration d'un certificat est parfois présentée comme une omission de routine: renouveler l'identifiant, redémarrer le service, passer à autre chose. Dans un cœur de réseau mobile national, cependant, l'unité de contrôle pertinente n'est pas le seul certificat. C'est le système combiné de gouvernance des versions logicielles, d'inventaire des identifiants, d'indépendance des alarmes, d'acceptation par l'opérateur, de diversité de déploiement, de préparation à la restauration, de reconnexion des abonnés et de communications. L'événement de décembre 2018 a testé tout ce système.

Sa valeur en tant que cas de responsabilité réside dans la manière dont une petite condition programmée a exposé un grand domaine de défaillance partagé.

Un calendrier vérifiable montre deux incidents nationaux avec un seul déclencheur fournisseur

Le dossier britannique est exceptionnellement détaillé car Ofcom a enquêté. Sadécision concluant l'enquête sur la panne du réseau O2indique que la panne a commencé à 04h30 et a duré près de 23 heures. Elle a affecté tous les quelque 25 millions de clients directs d'O2, ainsi que les connexions fournies via des opérateurs de réseau mobile virtuel. À différents moments, les données mobiles, les appels et les messages étaient indisponibles. O2 a convoqué son équipe de gestion des incidents majeurs à 04h50, 20 minutes après la première défaillance, et a établi des liaisons de communication avec Ericsson. Une équipe de gestion des incidents majeurs au niveau du conseil d'administration, présidée par le directeur général d'O2, a supervisé la réponse.

Le chemin technique vers la récupération n'était ni un simple remplacement de certificat ni un redémarrage immédiat. Ofcom a enregistré qu'il a fallu environ 12 heures pour parvenir à une correction réussie. O2 et Ericsson ont ensuite restauré le service par phases, car reconnecter l'ensemble de la population d'abonnés nationaux en une seule fois risquait de provoquer une congestion et une surcharge. O2 a restauré le service 2G et 3G vers 21h30. Il a commencé à restaurer la 4G vers 23h30 et a terminé ce travail à 03h12 le 7 décembre.

La séquence par phases est une preuve importante: même après que les ingénieurs ont neutralisé la condition logicielle initiale, le réseau devait encore gérer une vague de récupération potentiellement déstabilisatrice.

Ledossier public de l'affaired'Ofcom ajoute le calendrier procédural. Le régulateur a ouvert son enquête le 22 février 2019 et l'a close le 1er novembre 2019. Il a évalué si O2 avait pris des mesures appropriées pour maintenir la sécurité et la disponibilité du réseau et si le fournisseur avait pris toutes les mesures appropriées pour rétablir le service. L'enquête s'est terminée sans conclusion de violation, mais avec des attentes détaillées sur la manière dont les fournisseurs devraient assurer le contrôle des certificats des fournisseurs à l'avenir.

Ofcom a également intégré la panne dans sonrapport Connected Nations 2018. Le rapport a noté les effets sur les propres clients d'O2 et sur les marques de gros, notamment Tesco Mobile, Sky Mobile, TalkTalk Mobile, giffgaff et Lycamobile. Il a observé que la voix et la messagerie étaient également affectées pendant certaines parties de l'incident et de la récupération. Il a identifié des leçons pratiques de résilience, notamment la vérification des éléments clés du réseau, le suivi des bonnes pratiques lors de la reconnexion d'un grand nombre d'utilisateurs et l'examen d'une plus grande redondance du plan de contrôle pour les réseaux prenant en charge les clients de gros.

La société mère d'O2 a fourni les détails de la réponse commerciale. Lerapport de gestion intégré 2018de Telefónica a enregistré l'événement comme une panne significative causée par l'expiration d'un certificat Ericsson et a décrit une perturbation 2G et 3G d'environ 17 heures et une perturbation 4G d'environ 24 heures. O2 a offert aux clients mensuels directs un crédit équivalent à deux jours de frais mensuels, aux clients prépayés un supplément de 10 % sur une recharge de janvier et aux clients de large bande mobile une remise de 10 % sur un achat de janvier. Le rapport confirme donc un transfert concret de coûts des utilisateurs vers l'opérateur, bien qu'il ne publie pas de valeur monétaire totale pour les crédits ou le coût total de l'incident.

Le calendrier public de SoftBank commence à 13h39, heure normale du Japon. Soncommuniqué sur l'incident du 6 décembreindique que le service LTE national pour les clients SoftBank et Y!mobile est devenu indisponible ou difficile à utiliser jusqu'à 18h04, soit une période de quatre heures et 25 minutes. Les effets ont également atteint le service fixe Ouchi-no-Denwa et une partie de SoftBank Air. Le trafic s'est déplacé vers la 3G, provoquant une congestion. SoftBank a déclaré que tous les commutateurs de paquets Ericsson à Tokyo et Osaka étaient affectés, que le logiciel était utilisé depuis neuf mois et qu'Ericsson avait signalé des incidents simultanés chez des opérateurs dans 11 pays. SoftBank a rétabli le service en appliquant un logiciel plus ancien à tous les commutateurs affectés.

L'explication de l'incident du 12 décembrede SoftBank a renforcé la preuve du contrôle. Elle a attribué la défaillance à une gestion incorrecte d'une expiration dans le logiciel du commutateur Ericsson et a indiqué que les informations d'expiration pertinentes avaient été intégrées par Ericsson lors de l'expédition et ne pouvaient pas être inspectées par SoftBank. La société a déclaré avoir migré vers un logiciel qui gérait correctement l'expiration et avoir vérifié les principaux équipements de communication, y compris les systèmes affectés, pour des problèmes similaires. Il s'agit d'une déclaration directe de l'opérateur, non d'un examen technique indépendant, mais elle est centrale pour déterminer qui pouvait voir et modifier la condition initiale avant le 6 décembre.

Lors d'un briefing de gestion le 19 décembre, résumé dans lecompte officiel d'actualités de l'entreprisede SoftBank, l'opérateur a estimé l'impact à environ 30,6 millions de lignes. Le compte rendu fournit une séquence de récupération minute par minute: la panne a commencé à 13h39; le premier avis sur le site Web est apparu à 14h19; les travaux de séparation ont commencé à 14h45; les contrôles de trafic LTE ont été appliqués à 14h57; le problème probable du commutateur LTE a été identifié à 15h54; la mise à jour de tous les commutateurs LTE a commencé à 16h22; l'ouest du Japon a récupéré à 17h35; et la restauration nationale a été déclarée à 18h04. Ce dossier ne rend pas les deux récupérations nationales directement comparables. Leurs conceptions de réseau, leurs conditions d'état d'abonné et leurs conventions de rapport étaient différentes et ne sont pas entièrement publiques. Il montre que les opérateurs confrontés à un déclencheur commun ont utilisé des chemins de récupération technique différents et ont rétabli le service selon des calendriers matériellement différents.

Le contrôle pratique était divisé, mais il n'était pas réparti uniformément

La responsabilité devient plus claire lorsqu'elle est séparée en contrôle avant la panne, contrôle pendant la panne et devoir de prouver la réparation. Ericsson avait un contrôle direct sur la source du logiciel, le packaging des versions et la condition du certificat intégré dans les versions affectées. Le dossier public indique qu'O2 n'a pas été informé du certificat codé en dur ni de son risque et que SoftBank ne pouvait pas inspecter les informations d'expiration intégrées.

Ces faits plaçaient les contrôles préventifs les plus directs chez le fournisseur: maintenir un inventaire faisant autorité, attribuer un propriétaire, renouveler ou supprimer l'identifiant, tester le comportement à la date d'expiration et au-delà, alerter indépendamment du chemin de code affecté et notifier chaque client exposé avec suffisamment de préavis pour agir.

Les opérateurs conservaient néanmoins un contrôle substantiel. Ils sélectionnaient et déployaient les versions, négociaient les obligations du fournisseur, concevaient la topologie et les domaines de défaillance, approuvaient les procédures de maintenance et de restauration, surveillaient la santé du service, déclaraient les incidents, communiquaient avec les clients et les régulateurs et géraient la reconnexion massive des appareils. Certains contrôles préventifs peuvent avoir été impraticables pour un identifiant invisible à l'intérieur d'un logiciel propriétaire.

Le confinement architectural, l'assurance du fournisseur, la répétition de la récupération et l'avis public restaient des responsabilités de l'opérateur. Le fait qu'un opérateur ne puisse pas inspecter un champ caché ne signifie pas qu'il n'avait aucune influence sur le système de continuité environnant.

Ofcom a rendu cette limite juridique et opérationnelle explicite. Sa décision a indiqué qu'un fournisseur de communications ne peut pas sous-traiter ses obligations statutaires en externalisant les fonctions réseau à un tiers. En même temps, le régulateur a examiné ce qu'O2 aurait raisonnablement pu faire dans les circonstances.

Il a constaté qu'O2 disposait de dispositions contractuelles, de tests et de gestion des risques solides; qu'Ericsson n'avait pas divulgué le codage en dur ni le risque associé; que l'erreur spécifique n'était pas conçue pour être détectée dans les tests d'acceptation d'O2; et que l'ajout d'un contrôle pour détecter ce problème particulier à l'avance n'était pas techniquement ou commercialement réalisable pour O2 sur la base des preuves disponibles. La responsabilité, dans cette décision, n'était pas une responsabilité stricte pour chaque défaut du fournisseur.

C'était un test fondé sur des preuves pour savoir si le fournisseur agréé avait pris des mesures proportionnées aux risques qu'il pouvait connaître et contrôler.

La base légale en vigueur à l'époque peut être consultée dans la version historique del'article 105A de la loi de 2003 sur les communications. Elle exigeait que les fournisseurs de réseaux et de services de communications électroniques publics prennent des mesures appropriées pour gérer les risques pour la sécurité, y compris des mesures visant à minimiser l'impact des incidents de sécurité sur les utilisateurs finaux et les réseaux interconnectés. La conclusion d'absence de violation par Ofcom doit être comprise à la lumière de cette norme et des preuves de l'enquête. Ce n'était pas une déclaration selon laquelle la panne était inoffensive, que les certificats ne nécessitaient pas de gouvernance ou que les opérateurs pouvaient ignorer le risque commun du fournisseur après que la leçon a été connue.

Les opérateurs de réseau mobile virtuel et les clients professionnels occupaient une position de contrôle plus faible. Ils dépendaient du réseau sous-jacent d'O2 et ne pouvaient pas corriger le logiciel de base d'Ericsson ni séquencer la récupération nationale des abonnés. Leurs contrôles étaient la visibilité contractuelle, la planification de la continuité des activités, les options multi-réseaux lorsque cela était justifié, les communications avec les clients et l'escalade.

Le dossier Connected Nations démontre pourquoi la chaîne d'approvisionnement est importante: une condition du cœur de réseau a atteint des marques que de nombreux consommateurs n'associeraient pas nécessairement à O2. Une cartographie des dépendances qui s'arrête à la marque de détail n'aurait pas décrit le domaine de défaillance réel.

Les régulateurs détenaient un type de contrôle différent. Ils pouvaient exiger des rapports d'incident, contraindre à fournir des preuves, évaluer la conformité légale et convertir un événement ponctuel en attentes prospectives en matière d'assurance. Ils ne pouvaient pas renouveler le certificat intégré ni restaurer un commutateur. Leur rôle en matière de responsabilité était de vérifier si ceux qui détenaient le contrôle opérationnel s'étaient comportés de manière appropriée et si le secteur avait modifié ses contrôles après l'événement.

Les investisseurs et les conseils d'administration, quant à eux, contrôlaient les incitations, les budgets et la surveillance. Ils devaient se demander si les affirmations de haute disponibilité couvraient les dates logicielles communes, si la correction était vérifiée sur l'ensemble de la base installée et si la concentration des fournisseurs était visible comme une exposition à la continuité plutôt que seulement un fait d'approvisionnement.

Les utilisateurs affectés par la panne n'avaient presque aucun contrôle préventif. Ils pouvaient réessayer, passer au Wi-Fi, utiliser un autre fournisseur s'ils en avaient déjà un, ou attendre. C'est cette asymétrie qui fait que la responsabilité publique ne peut pas reposer sur l'affirmation que les clients ont été informés par la suite. L'avis et l'indemnisation sont importants, mais ils interviennent après que le risque a déjà été attribué à des personnes qui ne pouvaient ni inspecter le certificat ni choisir comment le cœur de paquets était construit.

Les préjudices allaient au-delà des sessions de données perdues, tandis que le coût total reste inconnu

L'ampleur confirmée est grande, mais doit être énoncée avec prudence. O2 a déclaré environ 25 millions de clients directs, plus les connexions de gros. SoftBank a ensuite décrit environ 30,6 millions de lignes affectées. Ces chiffres utilisent des unités différentes et peuvent inclure plusieurs abonnements détenus par une même personne, ils ne doivent donc pas être additionnés et présentés comme un nombre d'individus uniques. Ericsson et SoftBank ont décrit des effets dans plusieurs pays, mais le dossier public de sources primaires examiné ici ne permet pas d'établir un total global complet opérateur par opérateur.

Les effets sur le service étaient plus larges qu'un simple Internet mobile lent. Ofcom a constaté que les données, les appels et les messages étaient indisponibles à différents moments au Royaume-Uni. SoftBank a signalé une panne LTE nationale, une congestion sur la 3G, une perturbation d'un produit fixe et un impact partiel sur un produit de large bande sans fil. Le ministère japonais des Affaires intérieures et des Communications a traité l'événement comme un accident majeur en vertu de la loi sur les télécommunications. Sonavis concernant la réception du rapport d'accident grave de SoftBankdocumente l'étape de signalement formel après la panne, ancrant l'événement dans un processus juridique plutôt que seulement dans les communications d'incident de l'entreprise.

L'annonce d'avertissement et de directives administratives du 23 janvier 2019du ministère a enregistré une panne d'environ quatre heures et 25 minutes affectant environ 30,6 millions d'utilisateurs. Il a souligné le rôle du réseau mobile dans l'acheminement des appels d'urgence et son rôle de bouée de sauvetage sociale, et a décrit l'impact social comme extrêmement important. Cette déclaration soutient une conclusion de risque systémique. Elle n'établit pas qu'un appel d'urgence particulier a échoué, qu'une personne spécifique a été blessée ou que la panne a causé un décès. Ces résultats ne sont pas documentés dans le dossier public cité et doivent rester non revendiqués.

Le préjudice financier n'est également que partiellement visible. Les crédits d'O2 sont confirmés. Les clients et les entreprises ont également perdu du temps, des transactions et un accès, mais aucun total vérifié n'est public. SoftBank a décrit des mesures correctives comprenant l'examen des équipements, des changements procéduraux et une plus grande diversité; les documents publics n'isolent pas leurs coûts. Ericsson s'est excusé et a travaillé à la restauration, mais sa mise à jour n'a pas divulgué les indemnités versées aux opérateurs, les dépenses d'ingénierie ou la responsabilité contractuelle.

Tout chiffre unique de perte mondiale mélangerait donc des crédits confirmés avec des hypothèses non étayées sur le comportement des clients, les accords de niveau de service et l'interruption d'activité en aval.

Il y avait des coûts de responsabilité moins visibles. Les équipes d'intervention ont travaillé au-delà des frontières du fournisseur et de l'opérateur pendant des heures. Les régulateurs ont rassemblé et examiné des preuves techniques et contractuelles. Les opérateurs ont dû expliquer une panne qu'ils ne contrôlaient pas entièrement à des clients dont la relation était avec l'opérateur, non avec le fournisseur d'équipement. Les marques de gros ont hérité d'un problème de communication d'une couche réseau en dehors de leur gestion directe.

Ce sont des catégories réelles de fardeau, mais le dossier public ne fournit pas suffisamment de données pour les monétiser de manière responsable.

Le préjudice le plus durable a été la découverte que la prétendue redondance pouvait partager une expiration cachée. Si un logiciel et un état d'identifiant identiques sont reproduits sur plusieurs nœuds, l'ajout de nœuds peut augmenter la capacité sans créer d'indépendance par rapport à cet état. Il s'agit d'une inférence étayée par la déclaration de SoftBank selon laquelle tous les commutateurs de paquets Ericsson concernés sont tombés en panne et par les effets nationaux sur O2. Ce n'est pas la preuve que chaque nœud de chaque réseau affecté avait une topologie identique, ni n'établit le chemin d'exécution exact du logiciel.

La distinction protège l'analyse contre la transformation d'une leçon architecturale en un rapport médico-légal inventé.

Le dossier réglementaire a blanchi O2 de toute violation mais a relevé la norme d'assurance

La décision d'Ofcom est plus utile qu'un simple résumé coupable ou non coupable. Le régulateur a conclu qu'O2 avait pris des mesures appropriées pour gérer les risques de sécurité et avait pris toutes les mesures appropriées pour rétablir le service. Il n'a donc constaté aucune violation de l'article 105A(4). Son raisonnement a crédité le cadre contractuel d'O2 avec Ericsson, les dispositions de test, la gestion des risques, l'organisation rapide des incidents, la supervision de la direction, la collaboration avec le fournisseur et la restauration prudente par phases.

Il a également accepté que le certificat codé en dur non divulgué et ce mode de défaillance spécifique étaient en dehors de ce qu'O2 aurait raisonnablement pu identifier par son processus d'acceptation existant.

Cette conclusion a établi une limite pour la responsabilité rétrospective sur la base des preuves alors disponibles. Elle n'a pas figé la limite pour les incidents futurs. Une fois le mode de défaillance connu, les fournisseurs ne pouvaient plus traiter l'expiration d'un certificat intégré comme totalement imprévisible.

Ofcom a énoncé des attentes futures selon lesquelles les fournisseurs cherchent à obtenir des assurances sur les politiques de certificats des fournisseurs, la surveillance du cycle de vie et la gestion des exceptions; veillent à ce que les écarts par rapport à la politique soient documentés et examinés; testent soigneusement l'utilisation des certificats là où la disponibilité peut être affectée; et maintiennent des processus proportionnés pour les certificats sur l'ensemble de leurs réseaux.

Ofcom a également déclaré que son propre travail d'assurance de sécurité demanderait spécifiquement des informations sur l'utilisation et l'expiration des certificats.

C'est le changement fondamental en matière de responsabilité. Avant le 6 décembre, Ofcom a accepté la preuve qu'O2 n'aurait pas raisonnablement pu ajouter un contrôle préventif spécifique. Après le 6 décembre, le régulateur a converti l'événement en connaissance du secteur. Un fournisseur évaluant un identifiant caché comparable dans les années suivantes serait confronté à une question de prévisibilité différente.

La responsabilité durable dépend donc non seulement de savoir si la conduite répondait à la norme au moment de la défaillance, mais aussi si les organisations ont intégré une leçon documentée dans les achats, l'acceptation, les opérations et l'audit.

Le dossier japonais a emprunté une voie formelle différente. Le ministère des Affaires intérieures et des Communications a reçu le rapport d'accident grave de SoftBank fin décembre et a émis un avertissement strict et des directives administratives écrites en janvier. Lalettre d'orientation formelleest l'instrument écrit faisant autorité associé à l'annonce du ministère. Le ministère a appelé à des mesures concrètes de prévention des récidives et à des rapports, tandis que son compte rendu public a mis en lumière la coordination interne et externe, les informations fournies aux utilisateurs et le partage des leçons à l'échelle du secteur. L'action était dirigée contre SoftBank en tant qu'opérateur agréé, même si la condition logicielle initiale était attribuée à Ericsson. Cette répartition reflète le principe britannique en termes pratiques: l'opérateur reste redevable envers le régulateur sectoriel pour la continuité et les communications publiques, tandis que le contrôle du fournisseur sur le défaut reste une partie de l'analyse factuelle.

Les deux résultats réglementaires ne doivent pas être réduits à une contradiction. Ofcom a mené une enquête légale détaillée et a jugé O2 conforme. Le ministère japonais a émis un avertissement et des directives administratives après le rapport de SoftBank. Les cadres juridiques, les procédures et les dossiers de preuves différaient. Aucun des deux résultats n'établit par lui-même une responsabilité civile entre le fournisseur et l'opérateur. Aucun dossier public ne publie les contrats pertinents, les dispositions de garantie ou tout règlement confidentiel.

La responsabilité légale dans le domaine public est donc la plus forte au niveau des devoirs de l'opérateur et des conclusions du régulateur, et non de l'attribution privée des dommages.

L'affaire démontre également pourquoi l'examen réglementaire doit examiner les fournisseurs sans prétendre que le régulateur les exploite directement. Ofcom a recueilli des informations substantielles auprès d'Ericsson et les a utilisées pour évaluer O2. Il a pu comparer les contrôles de l'opérateur avec ce que le fournisseur avait divulgué. Un examen sérieux des infrastructures critiques externalisées nécessite cette portée. Si l'enquête ne prenait en compte que les documents déjà visibles par l'opérateur, la partie ayant la connaissance la plus directe d'une condition intégrée pourrait rester en dehors du tableau des preuves.

Des preuves de réparation existent, mais les affirmations d'assurance présentent encore des lacunes

La mise à jour du jour même d'Ericsson est la première couche de preuve de réparation. Elle indiquait que le logiciel défectueux était en cours de déclassement, que les services étaient rétablis et qu'une analyse initiale avait identifié un certificat expiré tandis qu'une analyse complète des causes se poursuivait. La déclaration incluait des excuses du directeur général. Elle n'a pas publié l'analyse finale, n'a pas identifié le certificat, n'a pas expliqué comment il était entré dans les versions, n'a pas indiqué depuis combien de temps il était connu, ni n'a listé tous les clients et versions affectés.

Une mise à jour opérationnelle le jour même est appropriée pour la restauration, mais elle ne remplace pas un dossier de clôture technique durable.

Les preuves de réparation d'O2 sont plus solides en ce qui concerne le processus d'intervention. Ofcom a examiné la gouvernance des incidents, la collaboration technique, le séquencement de la restauration, la gestion des fournisseurs et les modifications post-incident. Le régulateur a jugé la réponse appropriée et a décrit les futures mesures d'assurance des certificats. Telefónica a documenté l'indemnisation des clients. Les limites sont toujours importantes: la décision publique résume les preuves plutôt que de publier les artefacts de configuration, les résultats de test ou un inventaire complet de correction version par version.

L'absence de ces artefacts dans le domaine public ne signifie pas qu'ils n'ont jamais existé. Elle signifie que les lecteurs externes ne peuvent pas les utiliser pour vérifier la suppression complète du risque.

SoftBank a divulgué un ensemble plus large de mesures techniques et organisationnelles. Son briefing de décembre indiquait qu'elle achèverait un inventaire des certificats dans les équipements commerciaux, raccourcirait la procédure de démarrage d'urgence d'un logiciel plus ancien, modifierait les conceptions pour qu'une condition similaire n'arrête pas le système, ajouterait des commutateurs LTE et promouvrait un déploiement multi-fournisseurs. Elle a également déclaré avoir vérifié les principaux équipements de communication pour des problèmes similaires.

Ces mesures correspondent de manière sensée à la prévention, à la récupération et au confinement. Ce sont des affirmations de l'entreprise, cependant, et le dossier public cité n'inclut pas de rapports de test indépendants montrant que l'inventaire était complet ou qu'une simulation d'expiration ultérieure a réussi.

La différence entre l'action et la preuve est centrale. « Nous avons vérifié les certificats » est une déclaration d'action. Une preuve durable identifierait la population vérifiée, la méthode de découverte, les propriétaires responsables, les exceptions, les horizons d'expiration, les chemins d'alerte, les dates de clôture et l'échantillonnage indépendant. « Nous avons ajouté de la redondance » est une déclaration d'action. Une preuve durable montrerait que les chemins redondants ne partagent pas le même identifiant, la même date logicielle ou la même dépendance de gestion.

« Nous pouvons effectuer une restauration » est une déclaration d'action. Une preuve durable montrerait une restauration répétée sous charge, les effets connus sur l'état des abonnés, les objectifs de temps de restauration et les critères pour choisir la restauration plutôt qu'une correction sur place.

Il existait déjà un modèle de contrôle pertinent avant l'incident. En novembre 2017, l'Institut national des normes et de la technologie des États-Unis a publié unedescription de projet de gestion des certificats de serveur TLS. Elle décrivait les risques de panne créés par les certificats expirés et appelait à un inventaire formel, des propriétaires identifiés, une découverte et une surveillance automatisées, des rapports d'état et une correction organisée. Cette publication n'a pas été écrite pour l'implémentation du cœur de réseau mobile d'Ericsson, et le dossier public n'établit pas que l'identifiant intégré était un certificat de serveur TLS conventionnel géré par les mêmes outils. Sa valeur probante est plus étroite: le problème général de gouvernance de l'expiration des certificats était documenté avant décembre 2018, même si ce comportement logiciel particulier et ce déploiement n'étaient pas connus d'O2.

Le NIST a ensuite publié le guide de pratique plus completSP 1800-16 sur la sécurisation des transactions Web via la gestion des certificats de serveur TLS. Encore une fois, une architecture de référence de certificat Web ne peut pas être transplantée mécaniquement dans un cœur de paquets d'opérateur. Les principes durables sont transférables: découvrir les certificats, les lier à des propriétaires et systèmes responsables, surveiller l'état du cycle de vie, protéger l'accès de gestion, automatiser le renouvellement sécurisé lorsque c'est approprié, tester les modifications et conserver des preuves opérationnelles. Pour les identifiants intégrés ou propriétaires, la mise en œuvre peut nécessiter des attestations du fournisseur, des factures de matériel logiciel pour les dépendances d'identifiants, une manipulation du temps en laboratoire et un préavis contractuel au lieu d'outils de découverte d'entreprise ordinaires.

Les spécifications de sécurité des télécommunications actuelles rendent désormais explicite la préoccupation de disponibilité. L'édition de janvier 2026 del'ETSI TS 133 310 sur la sécurité du domaine réseau et l'infrastructure à clé publiqueinclut des dispositions sur le cycle de vie des certificats et des attentes en matière d'alarme liée à l'expiration destinées à atténuer l'indisponibilité du service. Il s'agit d'une référence actuelle, non d'une preuve des exigences exactes appliquées à Ericsson ou aux opérateurs en 2018, et elle ne prouve pas la correction dans un réseau installé. Elle démontre ce qu'un environnement de contrôle durable devrait désormais pouvoir opérationnaliser: l'expiration doit produire une action gérée avant de produire une perte de service.

Les contrefactuels séparent les défaillances évitables des détails inconnaissables

Un contrefactuel discipliné demande quel contrôle spécifique aurait changé le résultat sans supposer des faits qui restent privés. Le contrefactuel de prévention le plus fort est un inventaire faisant autorité des identifiants côté fournisseur lié à la version et au déploiement client. Si le certificat intégré avait un propriétaire nommé, un horizon d'expiration surveillé et une escalade indépendante du logiciel affecté, la date aurait pu déclencher un renouvellement, un remplacement, une suppression ou une campagne de mise à niveau client avant le 6 décembre.

Il s'agit d'une inférence étayée, fondée sur l'intervalle de validité déterministe et la pratique établie de gestion des certificats. Elle ne révèle pas pourquoi les contrôles réels d'Ericsson ont échoué.

Un contrefactuel côté opérateur est moins direct mais toujours significatif. Un processus de contrat et d'assurance de version pourrait exiger que le fournisseur divulgue chaque identifiant capable d'affecter la disponibilité, sa date d'expiration, la conception du renouvellement, le comportement d'alarme et les versions affectées. Les opérateurs pourraient exiger un inventaire lisible par machine des expirations ou une attestation signée pour les composants propriétaires qu'ils ne peuvent pas inspecter.

Ofcom a constaté que les contrôles existants d'O2 étaient raisonnables pour le risque non divulgué, cela ne doit donc pas être réécrit comme un contrôle qu'O2 était légalement tenu d'avoir en 2018. Il s'agit d'un contrôle prospectif rendu raisonnable par l'incident lui-même.

Le confinement fournit un deuxième contrefactuel. SoftBank a indiqué que tous les commutateurs de paquets Ericsson concernés à Tokyo et Osaka sont tombés en panne. Si les nœuds redondants partageaient le même logiciel et la même condition d'expiration, leur séparation physique n'a pas créé d'indépendance logique. La diversité des versions, le déploiement par étapes, la diversité des identifiants ou un standby implémenté séparément auraient pu réduire le domaine de défaillance commun. L'architecture multi-fournisseurs est une voie possible, et SoftBank l'a nommée comme mesure permanente.

Elle n'est pas sans coût: plusieurs fournisseurs peuvent créer une complexité d'interopérabilité, opérationnelle et d'assurance. Le test de responsabilité n'est pas de savoir si un opérateur a acheté une seconde marque, mais s'il a identifié quelles défaillances restaient communes à des chemins prétendument indépendants et justifié le risque résiduel.

La récupération offre la comparaison observée la plus claire. SoftBank est revenu à un logiciel plus ancien et a rétabli la LTE en quatre heures et 25 minutes. O2 et Ericsson ont mis environ 12 heures pour parvenir à une correction réussie, puis ont restauré les générations par phases et ont achevé la récupération 4G près de 23 heures après le début. Un package de restauration prévalidé, une sauvegarde de configuration à jour, une autorité de décision pratiquée et un plan de reconnexion des abonnés pourraient raccourcir une future panne. Il serait incorrect de déduire de la seule durée qu'une équipe d'opérateur était meilleure.

Le dossier public ne divulgue pas la topologie équivalente, la charge, les contraintes de sécurité ou les défauts présents dans chaque option de restauration.

Les communications forment un troisième contrefactuel. Des avis plus précoces, des déclarations plus claires sur les services affectés et des messages coordonnés entre les marques de gros n'auraient pas réparé le réseau. Ils pourraient réduire les efforts inutiles des utilisateurs, aider les organisations à invoquer des plans de continuité et permettre aux utilisateurs de services d'urgence de chercher des alternatives. Le régulateur japonais a spécifiquement traité l'information des utilisateurs et la coordination comme faisant partie du problème de correction.

La mesure durable n'est pas le volume de mises à jour, mais leur rapidité, leur cohérence, leur accessibilité via des canaux non affectés et leur caractère explicite sur ce qui reste indisponible.

Enfin, l'indemnisation aborde une partie du préjudice après coup. Les crédits d'O2 ont reconnu la défaillance du service sans exiger que chaque client prouve une perte individuelle. Ils n'ont pas indemnisé chaque interruption d'activité en aval, ni empêché la récurrence. Un système de responsabilité mature utilise l'indemnisation, la correction technique et la divulgation de preuves comme des outils séparés. Aucun ne peut remplacer les autres.

Faits confirmés, inférences étayées et inconnues

Faits confirmés.Ericsson a déclaré que deux versions spécifiques du logiciel SGSN-MME utilisées par un nombre limité de clients dans plusieurs pays étaient impliquées et a identifié un certificat expiré comme le principal problème dans son analyse initiale. Ofcom a constaté qu'un certificat de sécurité intégré ou codé en dur a expiré à 04h30 (heure britannique), provoquant la panne d'O2; il a documenté près de 23 heures de perturbation, environ 25 millions de clients directs d'O2 plus les connexions de gros, une activation de l'équipe d'intervention en 20 minutes, un chemin d'environ 12 heures vers une correction réussie et une restauration par phases. Ofcom n'a constaté aucune violation par O2 et a considéré ses mesures préventives et correctives appropriées. SoftBank a signalé une panne LTE nationale de quatre heures et 25 minutes, une congestion et des effets de service connexes, une restauration vers un logiciel plus ancien, des commutateurs Ericsson à Tokyo et Osaka, et des informations d'Ericsson selon lesquelles des opérateurs dans 11 pays ont connu des incidents simultanés. Le ministère japonais a enregistré environ 30,6 millions d'utilisateurs affectés et a émis un avertissement et des directives écrites. Telefónica a documenté les crédits clients d'O2. SoftBank a décrit publiquement des mesures d'inventaire, de récupération et de diversité.

Inférences étayées.L'expiration déterministe aurait dû être détectable par quiconque détenait un inventaire précis et une visibilité sur l'identifiant intégré. La réplication du même logiciel vulnérable et du même état d'identifiant a créé un risque corrélé que la redondance physique des nœuds seule ne pouvait pas contenir. Le contrôle direct avant la panne appartenait à Ericsson car les opérateurs ont déclaré que la condition pertinente était non divulguée ou non inspectable, tandis que les opérateurs conservaient le contrôle de l'architecture, de l'assurance du fournisseur, de la réponse, de la restauration, de l'avis et du recours client. Une restauration prévalidée et une procédure de reconnexion massive pourraient réduire le temps de récupération lors d'un événement comparable. Après l'incident, l'expiration des certificats intégrés est devenue une classe prévisible de risque de continuité pour les opérateurs et les fournisseurs, même si le mécanisme exact de défaillance au niveau du code restait propriétaire.

Inconnues.Le dossier public n'identifie pas le certificat par son sujet, son émetteur, son numéro de série, son empreinte ou ses dates de validité exactes au-delà de l'heure d'expiration observée. Il ne publie pas le rôle protocolaire précis du certificat, le chemin de code qui a converti l'expiration en défaillance du nœud, qui l'a créé ou approuvé, quelles portes de révision il a franchies, quelles alertes existaient ou pourquoi ces alertes n'ont pas empêché la panne. Le rapport final d'analyse des causes d'Ericsson n'est pas public dans le dossier cité. Il n'existe pas de liste publique complète de tous les pays, opérateurs, nœuds ou versions logicielles affectés. Les contrats et toute répartition privée de la responsabilité sont indisponibles. Les pertes totales, les paiements des fournisseurs et les coûts de correction ne sont pas audités publiquement. Le dossier n'établit pas de cyberattaque ou d'acte malveillant. Il ne fournit pas de vérification indépendante à l'échelle de la flotte que chaque réparation et inventaire de certificats était complet.

Ces catégories ne doivent pas être floues. Les faits confirmés sont suffisamment solides pour attribuer un contrôle pratique à un niveau fonctionnel. Les inférences étayées montrent comment les contrôles de continuité auraient pu interrompre la séquence. Les inconnues empêchent les affirmations sur la faute individuelle, le motif, la négligence au sein d'Ericsson, les dommages privés ou l'exhaustivité de la correction. La responsabilité est renforcée, non affaiblie, lorsque ces limites sont explicites.

Un test de responsabilité durable pour les logiciels de cœur de réseau mobile partagés

L'incident ne mérite une clôture que lorsqu'un fournisseur et chaque opérateur qui s'y fie peuvent répondre à un ensemble de questions de preuve. La première est lepérimètre: quels produits, versions, nœuds, réseaux et clients contiennent un certificat ou une autre dépendance limitée dans le temps capable d'affecter le service? Un inventaire devrait inclure les identifiants intégrés que les scanneurs réseau ordinaires ne peuvent pas voir. Il devrait mapper chaque élément à une version logicielle, une population de déploiement, un service métier, un propriétaire et un horizon d'expiration. Un pourcentage sans dénominateur défini n'est pas suffisant.

La deuxième est lapropriété: qui peut renouveler, remplacer ou supprimer l'identifiant, et qui doit agir lorsque le propriétaire est un fournisseur? La propriété doit être un rôle avec autorité, budget et une voie d'escalade, pas un alias de messagerie. Les contrats des fournisseurs devraient spécifier la divulgation, les périodes de préavis, les correctifs d'urgence, les versions de restauration prises en charge, la livraison de preuves et le traitement des logiciels en fin de vie. L'acceptation par l'opérateur devrait vérifier que ces obligations sont reflétées dans les données de version réelles.

La troisième est l'indépendance de détection: l'avertissement survivrait-il à la même condition qui menace le service? Une alarme générée uniquement par le composant en cours d'expiration peut disparaître lorsque le composant s'arrête. La surveillance du cycle de vie devrait donc utiliser une source de vérité gérée séparément et plusieurs seuils d'avertissement. Les exceptions, y compris les certificats codés en dur et les identifiants qui ne peuvent pas être renouvelés automatiquement, doivent être documentées, approuvées, limitées dans le temps et examinées à un niveau approprié.

La quatrième est letest de limite. Un laboratoire devrait tester le comportement avant, pendant et après les limites de validité pertinentes, y compris les décalages d'horloge, le remplacement de certificat, le redémarrage, le basculement et la restauration. Les tests devraient couvrir la disponibilité du plan de contrôle et l'effet sur les appareils tentant de s'attacher ou de rétablir des sessions. Un test d'acceptation générique qui prouve un fonctionnement normal à la date d'aujourd'hui ne répond pas à ce qui se passe à la date d'expiration. Les preuves devraient identifier la version testée, l'horloge de test, l'état du certificat, les alarmes attendues, le comportement observé et les écarts non résolus.

La cinquième est l'indépendance du domaine de défaillance. La discussion ultérieure d'Ericsson sur lesréseaux critiques robustesexplique que les nœuds du plan de contrôle tels qu'un MME peuvent servir de très grandes populations et que la conception de la récupération doit tenir compte de la charge de signalisation et de la redondance géographique. Cette discussion architecturale du fournisseur n'est pas une preuve de réparation après l'événement de 2018. Elle est utile pour évaluer la bonne question: les nœuds redondants sont-ils simplement situés à des endroits différents, ou évitent-ils le même logiciel, le même identifiant, la même synchronisation, la même orchestration et la même défaillance de gestion? Les opérateurs devraient documenter les dépendances communes entre les régions, les générations et les services de gros, puis tester la défaillance de ces couches communes.

La sixième est larécupérabilité sous charge. Les équipes ont besoin d'un artefact de restauration connu comme bon, d'une configuration compatible, d'un accès protégé, d'une autorité pour choisir la restauration et d'un plan de reconnexion par étapes. Les exercices devraient mesurer séparément le temps de détection, de diagnostic, de décision, de déploiement et de restauration du service. Ils devraient inclure la charge secondaire créée lorsque des millions d'appareils réessayent. Un redémarrage réussi en laboratoire d'un seul nœud n'est pas la preuve qu'une population nationale peut revenir en toute sécurité.

La septième est laresponsabilité des communications. Les opérateurs devraient maintenir une carte de contacts tenant compte des dépendances, couvrant les marques de détail, les clients de gros, les canaux d'entreprise, les parties prenantes des services d'urgence et les régulateurs. Les avis devraient distinguer les effets de service confirmés de l'enquête, indiquer les alternatives pratiques disponibles et utiliser des canaux indépendants du service mobile défaillant. Les enregistrements horodatés devraient montrer quand l'organisation a eu connaissance d'un fait matériel et quand elle l'a communiqué.

La huitième est lerecours et l'apprentissage. Les crédits clients ou autres recours devraient avoir une éligibilité transparente et ne pas dépendre de la connaissance par les utilisateurs de la cause technique cachée. L'apprentissage post-incident devrait alimenter les achats de logiciels, l'approbation des versions, la continuité des activités, l'assurance réglementaire et le reporting des risques au conseil d'administration. La leçon devrait être testée ultérieurement: échantillonner les systèmes installés, inspecter les preuves, simuler l'expiration et vérifier la clôture des exceptions. Une révision de politique sans échantillonnage opérationnel est de la documentation, pas de l'assurance.

La neuvième est uneclôture publiquement défendable. Les fournisseurs d'infrastructures critiques ne peuvent pas publier chaque détail de configuration sensible, mais ils peuvent divulguer suffisamment pour établir le périmètre, la catégorie de cause, la population corrigée, la méthode de validation et le risque résiduel. Une déclaration de clôture utile dirait quelles familles de produits et plages de versions ont été affectées, comment tous les clients ont été identifiés et notifiés, quel contrôle de cycle de vie a changé, comment le comportement à l'expiration a été testé, qui a examiné indépendamment le résultat et si des exceptions subsistent. Les identifiants sensibles peuvent être omis sans réduire le compte rendu à « logiciel corrigé ».

Appliqué à décembre 2018, ce test produit un résultat mitigé. La restauration est confirmée. La réponse et la conformité d'O2 ont été examinées par un régulateur indépendant, et le régulateur a jugé ses mesures appropriées. SoftBank a divulgué des actions immédiates et permanentes concrètes, et le ministère japonais a exigé un rapport de prévention des récidives. Ericsson a identifié la catégorie de cause initiale et a déclaré qu'il déclassait le logiciel défectueux.

Pourtant, la clôture publique reste incomplète car l'analyse finale du fournisseur, le périmètre de la base installée, l'historique du propriétaire du contrôle et la validation indépendante à l'échelle de la flotte ne sont pas disponibles.

Cet écart ne justifie pas une accusation au-delà des preuves. Il justifie une demande durable de preuve. La prochaine expiration devrait être découvrable des années à l'avance, visible à la fois par la partie qui l'intègre et par l'opérateur dont les clients en dépendent, testée à sa limite, isolée des défaillances de mode commun et récupérable via un chemin répété. Les conseils d'administration et les régulateurs devraient pouvoir inspecter ces affirmations sans attendre une autre panne synchronisée.

La responsabilité après que les horloges ont avancé

La panne de décembre 2018 n'était pas importante parce que les certificats sont exotiques. Elle était importante parce qu'une limite de temps ordinaire à l'intérieur d'un logiciel propriétaire partagé a traversé les frontières organisationnelles et nationales à la fois. Ericsson contrôlait la condition intégrée et le logiciel affecté. O2 et SoftBank contrôlaient différentes parties du déploiement, de la résilience, de la récupération et de la réponse client. Les régulateurs ont évalué les opérateurs agréés et ont traduit l'incident en attentes plus fortes.

Les utilisateurs ont subi la perte immédiate de connectivité bien qu'ils ne contrôlent aucune de ces décisions en amont.

La lecture la plus équitable du dossier évite deux erreurs faciles. L'une est d'absoudre les opérateurs parce que le fournisseur a fourni le défaut. L'autre est d'attribuer chaque conséquence aux opérateurs malgré les preuves que la condition déclencheuse était cachée et, dans le cas d'O2, raisonnablement non détectable avec les contrôles examinés par Ofcom. La responsabilité pratique suit le contrôle, la connaissance et le devoir légal à chaque étape. Elle peut être partagée sans devenir vague.

D'ici 2026, la question durable n'est plus de savoir si cette expiration précise était prévisible pour chaque opérateur en 2018. Il s'agit de savoir si les fournisseurs et les opérateurs peuvent désormais prouver que les dépendances limitées dans le temps dans les logiciels de réseau critiques sont inventoriées, possédées, surveillées, testées, diversifiées et récupérables. L'incident a fourni l'avertissement. Le test de responsabilité est de savoir si les preuves du changement survivront à la mémoire de la panne.