L’intrusion de 2013 chez Belgacom a transformé l’accès aux routeurs d’itinérance en test de responsabilité pour l’opérateur

Résumé

En septembre 2013, Belgacom a révélé une intrusion sophistiquée dans son environnement informatique interne. BICS a reconnu que certains de ses systèmes internes partageant cet environnement avaient été touchés, tout en indiquant qu’aucun élément ne signalait alors une compromission de son réseau de télécommunications distinct ou de l’acheminement du trafic de ses clients. [3][9]
Des réponses officielles belges ultérieures ont indiqué que des contrôles renforcés avaient révélé des indices dans le logiciel de routeurs. Les enquêteurs n’ont toutefois pas pu établir l’usage qui avait été fait de l’accès non autorisé. Cette évolution a déplacé le périmètre des preuves sans démontrer une interception, une modification, une surveillance ou un sabotage du trafic. [3][4][7]
Des articles fondés sur des documents divulgués ont décrit le ciblage d’ingénieurs disposant de privilèges au moyen de fausses pages web ainsi qu’un objectif lié à l’environnement de routeurs GRX de BICS. Il s’agit de descriptions rapportées d’une opération présumée, et non de constatations judiciaires publiques couvrant chaque terminal, routeur ou paquet. [13][16][18][19]
Les recherches consacrées à Regin fournissent un contexte technique sur une plateforme sophistiquée et modulaire employée contre des acteurs des télécommunications. Elles ne constituent pas une chaîne d’attribution complète reliant chaque artefact de l’affaire Belgacom à une décision étatique déterminée. [14][15]
Le véritable test de responsabilité consiste à savoir si l’opérateur pouvait reconstituer l’origine des accès privilégiés, l’état logiciel et la configuration réellement actifs sur les routeurs, les changements effectués et les observations soutenant ses déclarations sur le trafic.
Une architecture probatoire solide séparerait la navigation web des tâches d’administration, imposerait des chemins privilégiés contrôlés, attesterait les changements apportés aux routeurs, conserverait les journaux hors du domaine administré et évaluerait les effets sur le trafic indépendamment de la seule détection d’une compromission.
Belgacom, BICS, leurs fournisseurs, les partenaires d’itinérance, les enquêteurs et les autorités détenaient chacun une partie potentielle des preuves. Aucun acteur ne pouvait remplacer l’état d’exécution vérifié par une simple politique, une frontière organisationnelle ou une déclaration de conformité.
La leçon centrale relève de la continuité opérationnelle : maintenir le service ne suffit pas. Un opérateur doit aussi pouvoir démontrer dans quel état il a continué à fonctionner, quelles incertitudes subsistaient et comment ses assurances publiques ont évolué avec les preuves.

Une affaire d’infrastructure avant d’être un récit d’attribution

L’intrusion chez Belgacom a suscité une attention politique immédiate parce qu’elle concernait un opérateur national majeur et s’accompagnait d’allégations visant un service de renseignement étranger. La commission des libertés civiles du Parlement européen a organisé une audition et regretté l’absence des services britanniques. Les représentants de Belgacom présents n’ont pas confirmé ni démenti les articles attribuant l’opération au GCHQ. Des questions au Sénat belge, des documents européens et les travaux de l’organe belge de contrôle du renseignement ont ensuite maintenu l’affaire dans le champ du contrôle institutionnel.

[1][2][5][6][8][11]

Cette dimension politique compte, mais elle ne suffit pas à définir le problème d’infrastructure. L’attribution cherche à déterminer qui aurait dirigé l’opération. Le contrôle démocratique examine la légitimité, la proportionnalité et les autorisations éventuelles d’une activité de renseignement. La responsabilité de l’opérateur pose une question distincte : après la découverte d’une intrusion touchant l’environnement de personnes capables d’administrer des réseaux internationaux, Belgacom et BICS pouvaient-ils établir l’état réel de ces réseaux et les limites exactes de l’incident ?

Réduire « Belgacom » à un seul objet technique ferait disparaître cette question. Le dossier public distingue plusieurs ensembles : l’informatique d’entreprise de Belgacom, certains systèmes internes de BICS hébergés dans un environnement partagé, le réseau de télécommunications propre à BICS, les postes utilisés par du personnel privilégié et l’environnement de routeurs GRX évoqué dans les articles fondés sur des documents divulgués. À cela s’ajoute une affirmation spécifique de BICS sur l’absence d’indication d’incidence sur l’acheminement du trafic. Chaque ensemble exige des preuves différentes. [3][9][13][16]

La continuité apparente d’un réseau ne tranche pas la question. Un routeur peut continuer à acheminer des communications tandis qu’un accès non autorisé reste en cours d’analyse. À l’inverse, la découverte d’indices dans le logiciel d’un routeur ne prouve pas que des communications ont été interceptées, altérées, surveillées ou interrompues. Entre ces deux extrêmes, le niveau de certitude dépend de la qualité des observations, des périodes couvertes, de la conservation des journaux et de la possibilité de rapprocher des événements provenant de systèmes différents.

L’affaire doit donc être lue comme un test de capacité probatoire. Que savait l’opérateur au moment de sa première déclaration ? Sur quels actifs et quelles mesures cette connaissance reposait-elle ? Qu’ont ajouté les contrôles renforcés ? Quels faits les enquêteurs ont-ils pu relier entre eux ? Quelles conclusions sont restées hors de portée ? Ces questions résistent mieux au temps que les titres les plus spectaculaires consacrés à l’auteur présumé de l’opération.

Des frontières techniques à préserver sans les transformer en alibis

Une analyse rigoureuse commence par séparer les environnements concernés.

Périmètre	Ce que le dossier public permet d’affirmer	Ce qu’il ne permet pas d’affirmer	Preuves nécessaires à la responsabilité
Informatique interne de Belgacom	Belgacom a divulgué une intrusion sophistiquée dans son environnement informatique interne. [3][9][10]	Cela ne signifie pas que chaque équipement de Belgacom ou de BICS a été compromis.	Inventaire des terminaux, chronologie, images forensiques, identités et connexions vers les systèmes d’administration
Systèmes internes de BICS	BICS a indiqué que certains systèmes internes partageant l’environnement de Belgacom avaient été touchés. [9]	Le partage de services informatiques ne rend pas ces systèmes identiques au réseau de télécommunications de BICS.	Propriété des actifs, dépendances partagées, domaines d’authentification et segmentation effective
Réseau de télécommunications de BICS	Des documents officiels belges le présentent comme distinct du réseau de Belgacom. [3][4][7]	Une distinction architecturale ou organisationnelle ne prouve pas que toutes les voies d’accès étaient isolées.	Topologie d’administration, inventaire des routeurs, contrôles d’accès, état logiciel et mesures externes
Terminaux privilégiés	Des articles fondés sur des documents divulgués décrivent le ciblage d’ingénieurs au moyen de pages imitant notamment LinkedIn ou Slashdot. [13][16][18][19]	Ces récits ne démontrent pas que chaque tentative décrite a réussi contre chaque cible supposée.	Télémétrie des terminaux, isolation de la navigation, usage des identités, corrélation des sessions et journaux de sortie
Environnement GRX	Des reportages techniques évoquent comme objectif l’accès aux routeurs GRX de BICS. [13][16]	Un objectif rapporté n’établit ni chaque action exécutée sur les routeurs ni un effet sur le trafic.	Logiciels et configurations actifs, historique des commandes, attestation des changements et observations des plans de contrôle et de transfert

Il faut encore distinguer l’accès au réseau de ses effets sur le trafic. BICS a déclaré en septembre 2013 qu’aucune indication ne signalait une atteinte à son réseau de télécommunications ou à l’acheminement du trafic de ses clients. Cette formulation décrivait l’état des connaissances à une date donnée. Elle ne constituait pas une démonstration universelle de l’absence de tout accès non autorisé. La divulgation ultérieure d’indices dans le logiciel de routeurs a rendu cette nuance décisive. [3][4][7][9]

Fusionner tous les périmètres sous l’expression « le réseau » produirait des conclusions injustifiées. Un artefact découvert sur un poste de travail ne prouve pas, à lui seul, qu’un routeur a été modifié. L’absence de panne ou de plainte inhabituelle ne démontre pas non plus l’absence d’accès administratif clandestin. Des observations appartenant à une couche ne peuvent servir automatiquement de preuve pour toutes les autres.

Une séparation trop confortable serait tout aussi trompeuse. Le fait qu’un réseau de service soit officiellement distinct du système informatique d’entreprise ne suffit pas si des personnes, des identifiants, des postes, des annuaires ou des outils de gestion relient les deux environnements dans la pratique. Une frontière dessinée dans une architecture n’a de valeur probatoire que si les flux autorisés, les exceptions et les sessions réelles la respectent.

La bonne question n’est donc pas seulement : « Les réseaux étaient-ils séparés ? » Il faut demander : « Une compromission dans la zone d’entreprise pouvait-elle fournir des identifiants, une connectivité, une connaissance opérationnelle ou une position de confiance utilisables dans la zone d’administration des routeurs ? » Le dossier public ne donne pas de réponse complète sur la réutilisation des identifiants, les postes à double usage, les canaux de maintenance ou la reconstruction de chaque changement. Ces éléments doivent rester qualifiés d’inconnus.

Une assurance publique dont le périmètre a évolué

La déclaration de BICS de septembre 2013 constitue le premier repère public précis. L’entreprise a reconnu que certains de ses systèmes informatiques internes, utilisant l’environnement de Belgacom, avaient été touchés. Elle a simultanément indiqué qu’il n’existait alors aucune indication d’effet sur son réseau de télécommunications distinct ni sur l’acheminement du trafic de ses clients. [9]

Cette déclaration ne doit être ni effacée par les informations ultérieures ni étendue au-delà de ses termes. Elle ne disait pas que chaque routeur avait fait l’objet d’un examen forensique concluant. Elle ne certifiait pas qu’aucun acteur non autorisé n’avait jamais atteint un système d’administration. Elle rapportait ce que les éléments disponibles permettaient d’indiquer à ce moment-là.

Des réponses officielles belges ont ensuite déplacé le périmètre des faits connus. Elles ont expliqué qu’au moment de la première communication, rien n’indiquait que des routeurs de BICS avaient été piratés, mais que des contrôles renforcés avaient par la suite révélé des indices dans leur logiciel. Elles précisaient aussi que les enquêteurs n’avaient pas pu établir l’usage fait de l’accès non autorisé. [3][4][7]

Ces deux propositions sont indissociables. Les indices logiciels montrent que l’enquête a fini par atteindre une surface de contrôle du réseau qui n’avait pas été identifiée dans l’assurance initiale. L’impossibilité d’établir l’usage de l’accès signifie que le dossier public ne permet pas de déterminer quelles actions auraient suivi. L’incertitude ne doit être convertie ni en preuve d’interception ni en preuve définitive d’innocuité.

Il n’existe pas nécessairement de contradiction entre une déclaration initiale soigneusement bornée et une découverte ultérieure. Une assurance peut être fidèle aux observations disponibles à sa date, puis devenir incomplète lorsque de nouveaux contrôles font apparaître d’autres éléments. La responsabilité se mesure alors à la manière dont l’organisation conserve le fondement de la première déclaration et actualise son périmètre.

La notion de « contrôles renforcés » laisse néanmoins des questions ouvertes. Les sources indiquent qu’ils ont révélé des indices dans le logiciel de routeurs, mais elles ne publient ni la logique complète de détection, ni l’ensemble des images des équipements, ni l’historique intégral des configurations. Elles n’expliquent pas non plus pourquoi l’usage de l’accès n’a pas pu être établi.

Plusieurs causes sont théoriquement compatibles avec ce résultat : aucune action aux conséquences observables n’a peut-être été menée ; la télémétrie disponible ne couvrait peut-être pas l’action pertinente ; certains enregistrements ont pu manquer ; les artefacts ont pu rester ambigus ; ou les contraintes de divulgation ont pu limiter la réponse publique. Les documents cités ne permettent pas de choisir entre ces hypothèses. Les présenter comme des possibilités ne revient pas à les transformer en faits.

Une assurance solide doit donc comporter sa propre limite de preuve. Dire « aucune indication d’impact n’a été trouvée » devient réellement informatif lorsque l’opérateur précise la période examinée, les équipements couverts, les mesures consultées et les lacunes connues. Sans ces éléments, une formulation provisoire risque d’être relue plus tard soit comme une garantie absolue, soit comme une tromperie. Le dossier public ne justifie automatiquement aucune de ces deux interprétations.

L’accès privilégié commence souvent loin du routeur

Les articles fondés sur des documents divulgués décrivent le ciblage d’ingénieurs de Belgacom au moyen de pages contrefaites ressemblant à des sites familiers, ainsi que l’emploi allégué d’une technique dite Quantum Insert. Ces récits relient le ciblage de postes humains à un objectif concernant l’environnement GRX de BICS. [13][16][18][19]

La conclusion opérationnelle doit rester circonscrite. Une activité web ordinaire effectuée par une personne disposant de privilèges d’administration peut devenir un point d’entrée vers des systèmes de télécommunications sensibles. Les sources publiques ne révèlent pas la configuration de chaque poste, le succès de chaque tentative, les identifiants éventuellement récupérés ou toutes les étapes du passage vers les routeurs. Elles justifient toutefois d’examiner si la navigation générale et l’administration du réseau partageaient un terminal, une identité ou une relation de confiance.

Un opérateur devrait empêcher une session d’administration critique de dépendre de la sécurité d’une navigation web ordinaire. Cette séparation peut reposer sur des postes physiques dédiés, des espaces de travail virtuels fortement contrôlés ou des postes d’accès privilégié incapables d’atteindre librement le web. Les identités servant à gérer des routeurs ne devraient pas être utilisables pour la messagerie, des extensions de navigateur ou des applications bureautiques ordinaires.

Cette isolation ne relève pas uniquement de la prévention. Elle améliore aussi la capacité d’enquête. Si toute administration sensible ne peut provenir que d’un petit ensemble de postes attestés, chaque session observée sur un routeur peut être comparée à un inventaire fini. Si les administrateurs peuvent se connecter depuis des postes polyvalents, des accès distants génériques ou des environnements personnels, le nombre de chemins plausibles augmente et la reconstruction devient plus fragile.

Une politique écrite ne suffit pas à établir cette séparation. Les restrictions de sortie, certificats des équipements, listes d’applications autorisées, contrôles des destinations et tentatives bloquées doivent produire des enregistrements. Ceux-ci doivent être conservés ailleurs que sur le poste dont ils décrivent le comportement.

La distinction entre informatique d’entreprise et réseau de télécommunications ne résout pas ce problème. Un réseau de service physiquement séparé peut rester accessible par l’intermédiaire d’une identité, d’un annuaire, d’une station d’administration ou d’un serveur de gestion issus de l’environnement d’entreprise. C’est la chaîne opérationnelle réelle, non l’étiquette apposée sur chaque réseau, qui détermine le niveau de séparation.

Il serait spéculatif d’affirmer qu’une mesure particulière aurait empêché l’opération décrite. Un acteur sophistiqué peut emprunter d’autres voies, et les contrôles existant réellement chez Belgacom ou BICS en 2013 ne sont pas entièrement publics. La conclusion défendable est que le ciblage rapporté d’ingénieurs privilégiés place l’isolation des usages et la traçabilité des sessions au cœur du test de responsabilité.

La segmentation administrative doit être démontrée par les sessions réelles

Un chemin d’administration segmenté comporte plusieurs couches : terminal, identité, connectivité, autorisation, exécution de session et conservation des preuves. La présence d’un pare-feu entre l’informatique de Belgacom et les équipements de BICS n’aurait répondu qu’à l’une d’elles.

Dans une architecture défendable, l’administrateur utilise une identité dédiée, distincte de son compte professionnel ordinaire. Il se connecte depuis un équipement attesté, passe par une passerelle contrôlée, reçoit une autorisation limitée dans le temps et ne peut atteindre que l’équipement ou la fonction désignés. La session, les commandes et les changements sont rattachés à l’identité, au terminal, à l’autorisation et au motif correspondant.

La segmentation doit limiter les mouvements latéraux après la compromission d’un poste ou d’un compte. L’obtention d’une identité professionnelle générale ne devrait pas révéler automatiquement les adresses, secrets ou relations de confiance nécessaires pour administrer les routeurs. Une identité différente, une approbation supplémentaire et une frontière réseau observable devraient encore séparer l’attaquant éventuel du plan d’administration.

Le niveau de preuve exigé dépasse la configuration théorique des contrôles. L’opérateur doit pouvoir montrer que les sessions ont effectivement emprunté la voie prescrite, que les canaux de maintenance alternatifs étaient désactivés ou surveillés et que les accès d’urgence ont laissé une trace indépendante. Une procédure d’urgence peut être nécessaire à la continuité, mais elle devrait créer davantage de preuves : justification nominative, durée courte, approbation séparée et examen immédiat après utilisation.

Cette exigence prend un relief particulier dans un environnement où certains services internes étaient partagés tandis que le réseau de télécommunications de BICS était présenté comme distinct. [3][4][7][9] La frontière institutionnelle aide à définir les responsabilités, mais elle ne dit pas si un poste, un annuaire, un outil ou une identité permettait de la traverser.

Les fournisseurs et prestataires doivent suivre la même logique. Un accès de maintenance distant devrait entrer par une identité propre au fournisseur, une autorisation explicite et une session enregistrée dans le même système de preuves. Il ne s’agit pas d’affirmer qu’un accès fournisseur a joué un rôle dans l’affaire Belgacom, mais de définir le niveau de traçabilité que l’incident rend nécessaire.

Enfin, l’administrateur capable de modifier un routeur ne devrait pas pouvoir supprimer seul l’unique enregistrement de son intervention. La responsabilité suppose qu’un autre domaine de sécurité puisse vérifier la session, même si le domaine administré ou l’un de ses comptes privilégiés est compromis.

L’état réellement exécuté prime sur l’état prévu

La mention officielle d’indices trouvés dans le logiciel de routeurs déplace l’analyse vers l’état d’exécution. [3][4][7] Un opérateur peut disposer d’une version approuvée, d’un fichier de configuration validé et d’un ticket de changement parfaitement documenté sans que ces objets prouvent ce que l’équipement exécutait réellement au moment pertinent.

L’état prévu se trouve dans les dépôts, les procédures de déploiement et les inventaires. L’état opérationnel comprend l’image effectivement démarrée, les modules actifs, les processus en mémoire, la configuration courante, les comptes, les clés, les tâches programmées ainsi que le comportement produit dans les plans de contrôle et de transfert. Ces deux états peuvent diverger.

La primauté du code en exécution impose de relier l’artefact approuvé à l’appareil. Une chaîne robuste comprendrait l’identité de la version du fournisseur, son empreinte cryptographique, son entrée dans le système de déploiement, l’événement d’installation, la mesure du démarrage et une vérification ultérieure de ce qui était chargé. Une simple référence de version ne suffit pas si elle ne peut être liée au routeur examiné.

La provenance des configurations requiert une chaîne comparable. Chaque modification autorisée devrait préciser l’équipement, l’auteur, l’autorité approbatrice, le motif, l’état avant et après ainsi que l’heure. Les changements automatisés doivent désigner l’identité d’automatisation et leur entrée exacte. Les modifications d’urgence doivent rester distinguables des opérations ordinaires.

L’attestation ne peut dépendre exclusivement de l’équipement suspect. Un routeur sous contrôle non autorisé pourrait modifier ses journaux locaux ou présenter un état trompeur. Des instantanés distants, des événements de gestion signés, des observations externes du plan de contrôle et des copies de configuration conservées séparément permettent de comparer le récit local à des traces indépendantes.

La métadonnée de sécurité est aussi importante que le logiciel lui-même. Elle comprend l’empreinte de l’image, le certificat de signature, le résultat de sa validation, l’heure de démarrage, la liste des composants actifs, l’origine du paquet et toute exception ayant permis l’usage d’une image non standard. Sans ces éléments, un inventaire peut nommer un produit sans démontrer son état réel.

Une signature du fournisseur apporte une information utile, mais partielle. Elle peut attester l’origine d’un artefact sous réserve de l’intégrité du processus de signature. Elle ne démontre pas que seul cet artefact a démarré, qu’aucun composant actif n’a été modifié ou que le comportement du routeur correspondait au comportement attendu.

Les recherches sur Regin illustrent l’importance de cette distinction. Kaspersky a décrit une plateforme modulaire sophistiquée visant notamment des opérateurs de télécommunications. Wired a rapporté les rapprochements établis par des chercheurs entre Regin, ou un ensemble d’outils très similaire, et l’enquête Belgacom. [14][15] Cette modularité renforce l’intérêt d’examiner les composants actifs, mais elle ne permet pas d’étiqueter automatiquement chaque artefact Belgacom ni d’attribuer chaque action à un opérateur déterminé.

Le dossier public ne fournit pas toutes les images forensiques, tous les comptes affectés, l’intégralité des configurations ou l’historique reproductible de chaque routeur. Cette absence publique ne démontre pas que Belgacom ou BICS ne possédaient aucun de ces éléments. Elle limite simplement ce qu’un observateur extérieur peut conclure.

Les journaux sont un registre opérationnel, pas une déclaration de sécurité

Dans une infrastructure critique, les journaux d’accès et de changement ne sont pas de simples sous-produits administratifs. Ils forment un registre de la réalité opérationnelle. Leur rôle n’est pas de proclamer qu’un système est sûr, mais de consigner qui a fait quoi, depuis quel point, sur quel équipement et à quel moment.

La première exigence est la séparation. Les événements des routeurs et des passerelles devraient être transmis rapidement vers un domaine que les administrateurs du réseau ne peuvent pas modifier. Les traces des terminaux, du fournisseur d’identité, des passerelles privilégiées et du système de configuration doivent pouvoir y être rapprochées.

La deuxième exigence est la détection des altérations. Une immutabilité absolue n’est pas toujours réalisable, mais un stockage en ajout seulement, le chaînage cryptographique, la limitation des suppressions, la rétention d’objets et la réplication indépendante rendent les manipulations plus visibles. L’authentification de la source d’un événement doit elle-même conserver ses limites connues.

La troisième exigence concerne le temps. Des équipements dont les horloges divergent ou sont manipulées peuvent produire une chronologie faussement précise. Les systèmes doivent surveiller la synchronisation, conserver les écarts et exprimer l’incertitude lorsque la provenance temporelle n’est pas fiable.

La quatrième porte sur la complétude. Le collecteur doit connaître le volume attendu et détecter les interruptions. Un silence peut signifier qu’aucun événement n’a eu lieu, mais aussi qu’un équipement était hors ligne, que la journalisation avait été désactivée ou que le transfert avait échoué. L’absence d’une ligne ne constitue une preuve négative solide que si le système peut démontrer qu’il observait correctement la période concernée.

La cinquième exigence est une durée de conservation adaptée au délai de détection. Une intrusion sophistiquée peut être découverte longtemps après l’accès initial. Si les journaux de navigation, d’identité, de passerelle et de configuration expirent selon des calendriers incompatibles, l’enquête pourra retrouver un événement de poste sans pouvoir le relier à une session réseau.

La conservation doit naturellement respecter le droit, la protection des données et la proportionnalité. Cela n’empêche pas de retenir les métadonnées techniques nécessaires avec un accès limité, un objectif défini et une politique de destruction. Lorsqu’une intrusion est soupçonnée, une mesure de préservation doit suspendre la suppression habituelle pour les systèmes corrélés, et non uniquement pour le premier appareil où un indicateur a été découvert.

Les réponses officielles indiquent que les enquêteurs n’ont pas pu établir l’usage fait de l’accès non autorisé. [3][4][7] Elles ne disent pas si cette limite provenait de journaux manquants, d’artefacts ambigus, d’une absence d’activité conséquente ou de restrictions de divulgation. Il serait incorrect d’inventer un défaut précis de conservation. Le cas montre en revanche pourquoi la survivabilité et l’explicabilité des preuves sont elles-mêmes des résultats opérationnels.

L’impact sur le trafic doit faire l’objet d’un examen distinct

La déclaration initiale de BICS indiquait qu’aucun élément ne signalait une atteinte à son réseau de télécommunications ou à l’acheminement du trafic des clients. [9] La découverte ultérieure d’indices dans le logiciel de routeurs ne démontre pas que le trafic a été intercepté, modifié, surveillé ou saboté. [3][4][7] Ces deux faits imposent de séparer la preuve d’accès de la preuve d’impact.

Un accès non autorisé peut exister sans effet démontré sur le trafic. Une dégradation peut également provenir d’une cause sans rapport avec cet accès. L’enquête doit donc disposer d’un premier ensemble de preuves sur les identités, les sessions, le logiciel et les commandes, puis d’un second sur le routage, le transfert et la qualité du service. Leur corrélation est plus utile que l’un ou l’autre pris isolément.

L’examen de l’impact commence par une hypothèse définie. Pour une éventuelle modification de route, il faudrait rechercher les changements de configuration, les mises à jour du plan de contrôle, les variations de prochain saut, les chemins inattendus et les observations de joignabilité depuis l’extérieur. Pour une perturbation du service, les mesures pertinentes pourraient inclure les taux d’échec, la latence, les pertes, la disponibilité et les alarmes associées. Il s’agit ici d’un modèle de preuve, non d’une description de ce qui se serait produit chez BICS.

La période testée doit coïncider avec la fenêtre plausible de l’accès. Une mesure normale réalisée après la remise en état ne démontre pas le comportement antérieur. L’opérateur doit conserver la télémétrie historique ou indiquer clairement qu’il ne dispose que de mesures postérieures à la découverte.

Plusieurs points d’observation sont préférables. Les compteurs locaux du routeur sont utiles, mais ils proviennent de l’équipement examiné. Des sondes externes, les observations des partenaires, des résumés de flux, les données de signalisation et les mesures de niveau de service peuvent apporter une comparaison indépendante, dans les limites légales applicables.

Les constatations négatives doivent être formulées selon la couverture réelle. « Aucun effet n’a été trouvé dans des mesures complètes couvrant les chemins et la période pertinents » est plus robuste que « aucune plainte inhabituelle n’a été reçue ». « Aucun indice n’a été trouvé dans les données disponibles » est une formulation plus prudente lorsque des lacunes sont connues.

L’expression « trafic des clients » doit elle-même être délimitée. Elle peut renvoyer à la disponibilité du service, au choix des routes, au volume, à l’intégrité, à la signalisation ou à d’autres paramètres. Une assurance générale peut donner l’impression de couvrir des catégories qui n’ont pas toutes été testées. La précision protège à la fois les clients et l’opérateur.

Le dossier public ne décrit pas l’ensemble des tests ayant soutenu la déclaration de BICS. Il n’est donc pas possible d’en noter rétrospectivement la complétude. La conclusion autorisée demeure plus étroite : l’entreprise ne signalait initialement aucune indication d’impact, des indices ont ensuite été trouvés dans le logiciel de routeurs, et l’usage de l’accès n’a pas pu être établi.

Les assurances publiques nécessitent un historique de versions

Une communication d’incident est une affirmation liée à un état des preuves et à une date. Elle devrait être gérée avec une discipline comparable à celle d’une configuration critique : texte versionné, responsable identifié, périmètre précis, tests documentés et mise à jour lorsque le fondement factuel évolue.

Pour chaque assurance, l’opérateur devrait conserver le libellé exact, l’heure, les actifs couverts, les contrôles terminés, les lacunes et le niveau de confiance. Si la déclaration porte sur l’absence d’indication d’impact sur le trafic, le dossier interne doit préciser les mesures qui soutiennent cette formule et les catégories qui n’étaient pas encore évaluables.

La déclaration de BICS et les réponses officielles ultérieures montrent pourquoi cet historique compte. La première faisait état d’une absence d’indication concernant le réseau de télécommunications et l’acheminement du trafic. Les secondes mentionnaient des indices dans le logiciel de routeurs tout en maintenant que l’usage de l’accès n’avait pas été établi. [3][4][7][9] Un registre rigoureux permet de conserver les deux états sans déformer l’un pour faire place à l’autre.

Les termes « non observé », « non détecté », « non affecté » et « non établi » ne sont pas interchangeables. « Non observé » dépend du système d’observation. « Non détecté » dépend des capacités de détection. « Non affecté » formule une conclusion sur le résultat. « Non établi » indique que les preuves disponibles ne permettent pas de trancher. La stabilité de ces nuances conditionne la crédibilité des mises à jour.

Une divulgation correctement bornée ne suppose pas de publier les détails d’un exploit, les identités des administrateurs, les adresses sensibles ou les données des clients. L’opérateur peut décrire les catégories de preuves examinées, la période couverte, les écarts connus et ce qui a changé depuis la déclaration précédente.

Une bonne mise à jour répond à quatre questions : qu’est-ce qui est confirmé ? Qu’est-ce qui n’a pas été trouvé, et par quels tests ? Qu’est-ce qui demeure inconnu ? Qu’est-ce qui a évolué depuis la communication précédente ? Dans l’affaire Belgacom, cette structure aurait permis de relier clairement l’assurance initiale, la découverte dans le logiciel des routeurs et l’incertitude persistante sur l’usage de l’accès.

L’attribution au GCHQ reste une affirmation à plusieurs niveaux

Les sources publiques mobilisent plusieurs catégories d’attribution qu’il ne faut pas fusionner.

Le premier niveau est celui des faits reconnus : une intrusion dans l’environnement informatique de Belgacom, l’effet sur certains systèmes internes partagés de BICS et, plus tard, des indices dans le logiciel de routeurs. Ces faits n’exigent pas de déterminer publiquement quel service a dirigé l’opération. [3][4][7][9]

Le deuxième niveau provient de reportages fondés sur des documents divulgués. Wired et Statewatch ont décrit le ciblage d’ingénieurs, des pages web contrefaites, la technique Quantum Insert et un objectif concernant les routeurs GRX de BICS. Ces récits fournissent un scénario opérationnel rapporté. Ils ne constituent pas une constatation judiciaire publique établissant que chaque étape envisagée a été exécutée comme décrite. [13][16]

Le troisième niveau est la caractérisation parlementaire. Des documents du Parlement européen et des contributions adressées à des commissions du Parlement britannique ont abordé l’« Operation Socialist », Belgacom et les allégations concernant le GCHQ. Ils démontrent que ces allégations ont été soumises au débat et au contrôle parlementaires. Ils ne créent pas une chaîne technique juridiquement établie reliant une autorisation, un opérateur et chaque artefact. [17][18][19]

Le quatrième niveau tient à un article de 2018 du Guardian consacré à un rapport confidentiel du parquet belge. Le journal a rapporté que ce document jugeait probable une implication britannique et que le parquet avait refusé de commenter son contenu. Cette information est importante, mais elle doit rester attribuée à l’article et au rapport confidentiel qu’il décrit. Elle n’équivaut pas à un jugement public. [12]

L’audition européenne reflétait déjà cette limite : les représentants de Belgacom n’avaient ni confirmé ni démenti l’attribution rapportée, tandis que la commission regrettait l’absence des services britanniques. [1][11] Cette situation documente une controverse institutionnelle, pas une décision publique établissant la responsabilité du GCHQ.

Regin ajoute un contexte de capacité sans compléter l’attribution. Une famille d’outils sophistiquée peut aider à comprendre le niveau de menace auquel un opérateur devait faire face. Une ressemblance technique ne démontre cependant pas à elle seule l’identité de chaque opérateur, l’autorité ayant commandé l’action ou l’effet concret produit sur le réseau.

Cette discipline n’affaiblit pas l’analyse. Même une attribution publique incontestable ne démontrerait pas automatiquement quelles configurations ont changé ou quels effets ont touché le trafic. Inversement, l’absence d’une décision judiciaire publique sur l’auteur ne dispense pas l’opérateur de conserver les preuves relatives à ses propres systèmes.

L’itinérance internationale répartit les preuves entre plusieurs acteurs

BICS exploitait une infrastructure internationale, et les articles sur l’opération présumée désignaient son environnement GRX comme un objectif. [9][13][16] Dans ce contexte, les preuves de continuité et d’impact ne se trouvent pas nécessairement dans une seule organisation.

L’opérateur du routeur peut détenir l’état logiciel, les configurations et les journaux d’administration. Un partenaire d’itinérance peut observer la disponibilité ou le comportement du service. Un fournisseur peut détenir la provenance d’une image ou les informations sur une vulnérabilité. D’autres acteurs peuvent posséder des observations externes du routage. Aucun de ces éléments ne suffit isolément.

Cette distribution peut renforcer la résilience : des observations indépendantes permettent de vérifier le récit produit par le système examiné. Elle crée également des risques de rupture. Des politiques de rétention différentes, des horloges non alignées, des identifiants incompatibles ou des contraintes juridiques nationales peuvent empêcher de rejoindre les traces.

L’organisation qui formule une assurance reste responsable de son fondement. Elle ne peut considérer le silence d’un partenaire comme une preuve de fonctionnement normal. Elle ne peut pas davantage déduire de la propreté du dépôt d’un fournisseur que le routeur exécutait l’image attendue. Les éléments externes doivent être demandés, préservés et rapprochés de l’état local.

La notification des partenaires peut devoir intervenir avant que l’attribution soit résolue, afin qu’ils conservent leurs propres données. Une telle notification peut rester prudente : préciser les interfaces et la période potentiellement pertinentes, demander une préservation, puis distinguer clairement les faits confirmés des effets non établis.

La continuité opérationnelle ne se résume pas au maintien du trafic. Elle comprend la capacité à reprendre le contrôle dans un état connu, à valider les connexions partenaires et à expliquer la configuration restaurée. Une restauration trop rapide peut préserver la disponibilité tout en détruisant l’unique état forensique. La gestion d’incident doit arbitrer ces objectifs de façon explicite.

L’opérateur agit ici comme le teneur d’un registre, non comme une autorité capable de rendre ses propres affirmations vraies. Ses enregistrements doivent décrire les ressources et surfaces de contrôle placées sous sa responsabilité. Ils doivent ensuite être rapprochés de ceux des pairs, des fournisseurs et, lorsque le cadre légal le permet, des autorités compétentes.

La responsabilité pratique ne doit pas se perdre aux interfaces

Belgacom contrôlait en pratique son environnement informatique d’entreprise, les services partagés concernés, certaines identités et les premiers éléments de la réponse à l’incident. BICS contrôlait son réseau de télécommunications, l’administration de ses routeurs d’itinérance et les preuves soutenant son assurance sur le trafic. Le dossier public permet de distinguer ces domaines sans révéler toutes les dépendances techniques ou contractuelles. [3][4][7][9][10]

Cette cartographie ne constitue pas une répartition juridique définitive des responsabilités. Elle indique plutôt quel acteur était le mieux placé pour produire quelle preuve. Belgacom pouvait conserver les traces des terminaux et identités relevant de son domaine. BICS pouvait conserver l’état des routeurs, les sessions administratives, les observations du trafic et les échanges avec ses partenaires.

Les fournisseurs détenaient d’autres pièces du dossier potentiel : télémétrie de sécurité, provenance des mises à jour, images signées, informations de vulnérabilité ou traces de maintenance. Ils ne pouvaient cependant pas décider seuls si le trafic de BICS avait subi un effet. Leur contribution devait être rapprochée de l’état d’exécution et des mesures de service de l’opérateur.

Les partenaires d’itinérance pouvaient fournir des observations indépendantes. Un fonctionnement apparemment normal chez un partenaire ne réfuterait pas un accès non autorisé au routeur. De même, un indice local dans le logiciel ne prouverait pas que le trafic du partenaire a été manipulé.

Les autorités et organes de contrôle pouvaient exiger une notification, préserver l’indépendance de l’enquête et demander que les assurances soient étayées. Ils ne géraient pas eux-mêmes les routeurs et ne pouvaient reconstruire des données jamais enregistrées. Les enquêteurs, pour leur part, ne pouvaient conclure qu’à partir des éléments disponibles et communicables.

La limite officielle selon laquelle l’usage de l’accès n’a pas pu être établi doit rester une limite, et non devenir une conclusion de substitution. [3][4][7] Elle ne signifie ni que le trafic a été affecté ni qu’il ne l’a pas été. Elle ne prouve pas non plus, sans autre information, qu’un opérateur a manqué à son obligation de conservation.

L’interface la plus dangereuse est celle où chaque acteur suppose qu’un autre détient le registre décisif. Si Belgacom conserve l’événement du terminal mais pas l’identifiant de session BICS, si BICS conserve un journal du routeur sans l’identité du terminal d’origine, et si le fournisseur conserve l’image approuvée sans l’empreinte déployée, la chaîne restera incomplète. Concevoir la responsabilité consiste à fermer ces ruptures avant l’incident.

Le cadre européen éclaire les attentes sans rendre un verdict rétroactif

Les documents de l’ENISA sur l’article 13 bis décrivaient les dispositifs européens relatifs à la sécurité et à l’intégrité des réseaux et services publics de communications, ainsi qu’à la notification des incidents. Ils abordaient les orientations de mise en œuvre et la coordination entre autorités nationales. [20][21]

Ce cadre est pertinent parce que l’affaire Belgacom touchait à la gestion du risque, à la continuité, au périmètre d’un incident et à sa dimension transfrontière. Il montre que la sécurité des télécommunications n’était pas seulement considérée comme une préférence technique interne, mais comme un objet de gouvernance.

Ces documents généraux ne démontrent toutefois pas que l’incident Belgacom ou BICS a franchi un seuil juridique particulier. Ils ne prouvent pas qu’une autorité a constaté une violation nommée, qu’un contrôle précis était obligatoire sur un routeur donné ou qu’une remédiation a été jugée complète. Aucun verdict de ce type ne doit être fabriqué à partir d’orientations générales.

Un cadre réglementaire peut identifier les catégories de preuves attendues : gestion des risques, mesures de sécurité, continuité et notification. Il ne remplace pas l’état réel des équipements. Une organisation peut disposer d’un programme conforme sur le papier et subir malgré tout une intrusion. La question est de savoir si ce programme produisait des inventaires exacts, des chemins privilégiés contrôlés, des changements détectables et des preuves conservées.

Réciproquement, l’existence d’une intrusion ne prouve pas automatiquement une non-conformité. Une obligation de sécurité n’est généralement pas une promesse d’inviolabilité face à tout adversaire sophistiqué. Les sources réunies ici ne permettent pas de rendre une conclusion juridique sur le comportement de Belgacom ou de BICS.

Un test concret de responsabilité pour un opérateur international

La grille suivante ne décide ni de l’attribution ni d’une responsabilité juridique. Elle évalue la reproductibilité des assurances opérationnelles.

Test	Éléments attendus	Signification d’une lacune
Délimitation des systèmes	Carte datée séparant informatique d’entreprise, services partagés, terminaux privilégiés, chemins de gestion, routeurs et observations du trafic	L’opérateur risque de ne pas pouvoir préciser le périmètre réel d’une assurance
Provenance des accès	Postes attestés, identités séparées, passerelles enregistrées, autorisations temporaires et blocage des voies alternatives	Une session non autorisée peut rester sans origine reconstituable
Provenance des routeurs	Image vérifiée, empreintes, mesures de démarrage, modules actifs, historique des configurations et instantanés externes	L’état prévu ne peut être lié à l’état réellement exécuté
Attestation des changements	Auteur, autorisation, justification, état avant et après, appareil, heure et copie indépendante	Un état suspect peut être visible sans que son origine soit explicable
Survivabilité des preuves	Journaux externes en ajout seulement, intégrité temporelle, détection des lacunes et suspension des suppressions	L’absence d’événement dans les traces restantes ne prouve pas l’absence d’activité
Incidence sur le trafic	Hypothèses définies, observations des plans de contrôle et de transfert, mesures de service et corroboration externe	L’accès ne peut être relié ni à un impact démontré ni à une assurance négative forte
Mise à jour des assurances	Déclarations versionnées reliées à leur périmètre, leurs tests, leur niveau de confiance et leurs révisions	Une conclusion provisoire risque d’être comprise comme définitive
Continuité transfrontière	Propriétaires identifiés, notification des partenaires, préservation externe et validation de la restauration	Les preuves et obligations peuvent disparaître aux frontières organisationnelles
Divulgation bornée	Faits confirmés, tests réalisés, inconnues, évolutions et détails sensibles protégés	Le public reçoit soit une assurance invérifiable, soit une divulgation dangereuse

Réussir le test de délimitation ne suppose pas l’absence de services partagés. Il faut savoir ce qui était partagé et comment ce partage affectait les chemins privilégiés. L’aveu par BICS de systèmes internes communs à l’environnement Belgacom doit être rapproché de sa distinction concernant le réseau de télécommunications. [3][9]

Réussir le test des accès ne suppose pas de prouver qu’aucune exploitation de terminal n’était possible. Il faut démontrer que l’administration sensible empruntait une voie limitée et observable. Le ciblage d’ingénieurs rapporté dans les sources rend ce test directement pertinent, sans établir un défaut précis sur chaque poste. [13][16][18][19]

Réussir les tests de provenance et d’attestation signifie pouvoir reconstituer l’état réel des routeurs. Les indices logiciels mentionnés officiellement rendent insuffisant un dépôt de référence non relié aux appareils. [3][4][7]

Réussir le test de survivabilité signifie qu’un compte privilégié compromis ne peut effacer discrètement la seule trace de son activité. Cela ne rend pas les journaux infaillibles. Les lacunes de collecte, les incertitudes temporelles et les erreurs de validation doivent rester visibles.

Réussir le test d’impact ne nécessite pas de publier des données individuelles. L’opérateur doit pouvoir relier sa conclusion à des mesures capables de détecter les effets couverts. Le dossier public ne livre pas assez d’informations pour évaluer rétrospectivement la couverture du test effectué par BICS.

Une lacune dans l’un de ces tests ne constitue pas la preuve d’un dommage ou d’une violation. Elle limite la force de ce que l’opérateur peut démontrer. La responsabilité consiste à ajuster l’assurance à cette force, sans combler le vide par une accusation ou une exonération.

Ce que le dossier permet — et ne permet pas — de conclure

Le socle public confirmé est limité mais significatif. Belgacom a divulgué une intrusion dans son informatique interne. BICS a reconnu l’effet sur certains systèmes internes partagés et a déclaré qu’aucun indice ne signalait alors une atteinte à son réseau de télécommunications distinct ou à l’acheminement du trafic. Des documents officiels belges ultérieurs ont mentionné des indices dans le logiciel de routeurs et l’impossibilité d’établir l’usage de l’accès non autorisé. [3][4][7][9][10]

Le dossier contient aussi des récits opérationnels et des allégations issus de documents divulgués, de travaux parlementaires et d’un article consacré à un rapport confidentiel du parquet. Ils décrivent le ciblage d’ingénieurs, un objectif concernant l’environnement GRX et une implication présumée du GCHQ. Ils ne constituent pas une décision judiciaire publique ni une preuve de chaque étape rapportée. [1][11][12][13][16][17][18][19]

Les recherches sur Regin montrent pourquoi l’enquête devait envisager une menace modulaire et sophistiquée visant les télécommunications. Elles ne fournissent pas une chaîne complète pour chaque artefact de Belgacom. [14][15] Les documents de l’ENISA situent l’affaire dans un contexte européen de sécurité, d’intégrité et de notification des incidents, sans établir une violation propre à cet événement. [20][21]

Aucune source publique citée ici n’établit que des appels, des données d’itinérance, des contenus ou d’autres éléments du trafic client ont été interceptés, modifiés, surveillés ou sabotés. Aucun élément public présenté ne justifie une conclusion de culpabilité individuelle. Une déclaration générale ultérieure ne peut pas non plus prouver à elle seule que l’environnement de 2013 avait été entièrement assaini.

La conclusion défendable porte sur la capacité de preuve. Dès lors que des terminaux privilégiés et le logiciel de routeurs entrent dans le périmètre de l’enquête, l’opérateur doit pouvoir relier l’événement du terminal, l’identité administrative, la session, l’état du routeur, la modification éventuelle et l’observation du trafic. Une chaîne complète peut soutenir une assurance forte. Une chaîne lacunaire oblige à conserver l’incertitude.

Cette exigence ne demande pas l’omniscience. Elle demande des frontières exactes entre les faits observés, l’absence d’indice, les inférences et les questions sans réponse.

La leçon durable tient à la preuve opérationnelle

L’affaire Belgacom ne devrait pas être réduite à un titre spectaculaire sur l’attribution. Son importance pour les infrastructures réside dans une question plus exigeante : l’opérateur pouvait-il démontrer qui avait accédé aux systèmes d’itinérance, ce que les routeurs exécutaient et comment le trafic s’était comporté pendant la période pertinente ?

La déclaration initiale de BICS et les réponses officielles ultérieures fournissent ensemble le bon cadre. Aucun effet sur le réseau de télécommunications ou l’acheminement du trafic n’avait d’abord été indiqué. Des contrôles renforcés ont ensuite révélé des indices dans le logiciel de routeurs. L’usage de l’accès est resté non établi. [3][4][7][9] Aucune de ces propositions ne doit effacer les autres.

La responsabilité repose donc sur une architecture de preuves : isolation des usages privilégiés, segmentation des voies d’administration, provenance vérifiée des logiciels et configurations, attestation des changements, conservation indépendante des journaux, examen spécifique du trafic et versionnement des assurances publiques.

Ces contrôles ne déterminent pas qui aurait autorisé une opération de renseignement. Ils déterminent si un opérateur peut expliquer l’état de sa propre infrastructure et la continuité qu’il revendique.

L’opérateur tient le registre des ressources et surfaces de contrôle placées sous sa responsabilité. Sa qualité de propriétaire ou d’exploitant ne transforme pas ses déclarations en faits. Seules des métadonnées exactes, des traces protégées et des mesures confrontables à des observations indépendantes permettent de faire d’une assurance une preuve.

La limite finale reste nette : le dossier public ne démontre ni interception ni sabotage du trafic et ne fournit pas une attribution judiciaire complète. Il montre en revanche que le périmètre des preuves est passé de systèmes internes partagés à des indices dans le logiciel de routeurs. À partir de ce moment, l’accès privilégié, l’état d’exécution et la continuité vérifiable sont devenus le cœur du test de responsabilité.