Panne DDoS Belnet 2021: un test de résilience publique

Synthèse

Le rapport annuel 2021 de Belnet indique que l’organisation a subi une attaque majeure par déni de service distribué volumétrique les 3 et 4 mai. Son journal de statut en direct documente des problèmes de connectivité pour les clients, des vagues d’attaque successives, des chemins de trafic alternatifs, des règles d’atténuation, des travaux de stabilisation et la planification d’une protection à plus long terme. [1][2]
Un compte rendu parlementaire fédéral officiel indique qu’environ 200 organisations connectées, dont des universités, des autorités publiques et des établissements de recherche, ont connu des degrés variables de perturbation de l’accès à internet le 4 mai. Il mentionne que Belnet a activé sa procédure de crise, contacté le Centre pour la Cybersécurité Belgique et maîtrisé la situation dans la soirée. [7]
Le diffuseur public belge VRT a relaté des effets concrets sur des sites gouvernementaux, les travaux parlementaires, l’accès à distance et un service de réservation de vaccination. Ces exemples démontrent une dépendance des services publics, mais ils ne prouvent pas que chaque institution connectée a subi la même défaillance ni la même durée. [8]
Belnet exploite un réseau national de recherche et de services publics comprenant une infrastructure IP et optique, des points de présence, des connexions de backbone et un accès redondant optionnel. Son propre énoncé de mission qualifie ce réseau d’élément essentiel des services numériques fédéraux. [9][10][11]
Les sources publiques n’établissent ni attaquant nommé, ni mobile politique, ni volume de trafic exact, ni répartition par protocole, ni taille de botnet, ni lien saturé, ni vulnérabilité exploitée, ni chronologie complète client par client. L’analyse de responsabilité doit préserver ces inconnues.
Les documents ultérieurs de Belnet fournissent des preuves utiles de changement. L’opérateur a explicitement relié un contrôle d’adressage point à point à la résilience après l’attaque de 2021, et un article de surveillance de 2022 indique qu’un centre de nettoyage cloud externe a été mis en œuvre en mai 2021 lorsque le trafic d’attaque menaçait les liaisons montantes du réseau. [3][6]
Les pages actuelles de Belnet sur la sécurité DDoS avancée décrivent le filtrage par routeurs, un centre de nettoyage interne et une couche cloud externe. Elles témoignent de dispositifs ultérieurs ou actuels, et non de l’existence de l’architecture complète avant l’incident. [4][5]
Les documents de l’IETF sur le déni de service, le filtrage d’entrée et la signalisation ouverte de menaces DDoS fournissent un vocabulaire pour la préparation à l’atténuation, la coordination amont et la télémétrie. Ils ne prouvent pas que Belnet a utilisé un protocole ou une configuration particulière en 2021. [12][13][14][15][16][17][18][19]
La responsabilité suit le contrôle concret. Belnet contrôlait l’exploitation du backbone, l’atténuation, le reroutage, l’escalade de crise et les preuves à l’échelle du réseau. Les institutions connectées contrôlaient le basculement local, l’accès secondaire et la continuité applicative. Les fournisseurs amont et de dernier kilomètre contrôlaient les chemins et capacités contractuels. Les autorités publiques contrôlaient les exigences de continuité et la supervision.
Une clôture crédible devrait montrer où le trafic légitime a été contraint, quand l’atténuation et les chemins alternatifs ont pris effet, quel filtrage collatéral a eu lieu, comment le rétablissement des clients a été mesuré et si les dispositifs ultérieurs ont été testés contre la classe de défaillance réelle.

La panne a transformé la connectivité partagée en risque partagé pour les services publics

Une attaque par déni de service distribué est facile à décrire mal. La version simplifiée dit que les attaquants ont envoyé trop de trafic, qu’un réseau est devenu indisponible, que les ingénieurs ont filtré le trafic et que le service est revenu. Cette séquence peut être techniquement exacte tout en masquant les questions de responsabilité qui comptent le plus.

Belnet n’hébergeait pas simplement un site web public. Il fournissait la connectivité utilisée par des ministères, des universités, des organismes de recherche et d’autres institutions publiques. L’énoncé de mission de Belnet décrit un réseau national de recherche et un élément crucial des services numériques fédéraux. Ses pages de service décrivent un réseau hybride IP et optique qui relie les institutions aux réseaux internet et de recherche belges et internationaux. [9][11]

Ce rôle a changé le sens de l’incident de mai 2021.

Une attaque qui contraignait la capacité partagée du réseau pouvait toucher des institutions ayant des applications, des administrateurs et des missions sans rapport entre eux. Une commission parlementaire n’avait pas besoin de partager une base de données applicative avec une université pour que les deux en pâtissent. Un service de réservation de vaccination n’avait pas besoin de fonctionner sur le même serveur qu’un site fiscal. L’accessibilité partagée suffisait.

Le compte rendu parlementaire fédéral indique qu’environ 200 organisations connectées ont connu des niveaux variables de perturbation de l’accès à internet. [7] La VRT a décrit des sites gouvernementaux lents ou indisponibles, des travaux parlementaires annulés ou interrompus, des problèmes d’accès à distance et une période pendant laquelle un service de réservation de vaccination n’a pas pu fonctionner normalement. [8]

Ces effets doivent être rapportés avec prudence. Les preuves ne montrent pas que chaque organisation a perdu toute connectivité pendant la même période. Elles ne montrent pas que tous les services publics belges ont échoué. Elles n’établissent pas que le domaine.be lui-même est devenu indisponible. Les institutions avaient des conceptions d’accès, des dépendances applicatives, des réseaux locaux et des solutions de repli différents.

Le fait commun est plus étroit et plus important: un incident de réseau s’est propagé à plusieurs secteurs parce que ces secteurs dépendaient d’une surface de contrôle de connectivité partagée.

Cela rend la concentration mesurable.

Combien de services critiques dépendaient d’un seul chemin d’accès Belnet? Combien d’institutions disposaient d’un chemin secondaire passant par un autre point de présence, un autre trajet de fibre ou un autre fournisseur? Quels services pouvaient basculer sans modifier le DNS, l’authentification, le pare-feu ou l’état applicatif? Quelles institutions savaient qu’un incident chez un fournisseur partagé pouvait interrompre à la fois l’accès public et l’accès à distance de leur personnel? Quels plans de continuité avaient été testés avec le réseau principal de recherche et de services publics indisponible?

Les réponses déterminent si l’infrastructure partagée produit une résilience efficace ou un risque caché de mode commun.

La protection centralisée du réseau peut être précieuse. Un réseau national de recherche peut mutualiser l’expertise, la capacité, la surveillance et les achats. Il peut se coordonner avec les fournisseurs amont plus efficacement que chaque institution agissant seule. Il peut fournir une infrastructure optique et IP redondante et mettre une atténuation spécialisée à la disposition d’organisations qui ne pourraient pas l’exploiter elles-mêmes.

La même concentration augmente les enjeux d’une atténuation sous-dimensionnée, d’une escalade lente ou d’un basculement client incomplet. Si des centaines d’institutions dépendent de liaisons montantes et de systèmes d’atténuation partagés, les décisions techniques de l’opérateur font partie de la continuité du service public.

C’est la frontière de responsabilité exposée par la panne. Les attaquants contrôlaient le trafic malveillant. Belnet et ses partenaires contrôlaient la manière dont l’infrastructure partagée détectait, absorbait, redirigeait et documentait ce trafic. Les institutions connectées contrôlaient la part de leur propre continuité de service qui dépendait du chemin commun. Les autorités publiques contrôlaient les exigences de résilience attachées aux services dont l’interruption avait des conséquences sociales.

La responsabilité ne peut donc pas être réduite à l’identité de l’attaquant. Elle doit suivre la répartition du contrôle concret.

Ce que le dossier public établit, et ce qu’il n’établit pas

L’analyse la plus fiable commence par séparer trois types de documents: les mises à jour de statut opérationnelles de Belnet, son rapport annuel ultérieur et les comptes rendus institutionnels ou journalistiques externes.

Le rapport annuel de Belnet situe l’incident les 3 et 4 mai 2021 et le qualifie d’attaque DDoS volumétrique majeure. Il indique que l’événement a fondamentalement changé l’approche de l’organisation en matière de cyberdéfense. [2]

Le journal de statut en direct commence le 4 mai. Il indique que certains clients rencontraient des problèmes de connectivité en raison d’une attaque DDoS. Les mises à jour ultérieures décrivent des vagues successives, la poursuite des travaux d’atténuation, des chemins alternatifs pour le trafic, des règles d’atténuation mises en œuvre, la stabilisation, des incidents résiduels et des travaux sur la protection à plus long terme et les chemins d’escalade. [1]

Le compte rendu parlementaire fédéral donne un récit gouvernemental officiel. Le Premier ministre a décrit une attaque DDoS à grande échelle le 4 mai, indiqué que le réseau ne pouvait pas traiter la demande et précisé que les institutions connectées avaient été touchées à des degrés divers. Le compte rendu mentionne l’activation de la procédure de crise de Belnet et le contact avec le Centre pour la Cybersécurité Belgique. Il indique que la situation était maîtrisée dans la soirée. [7]

La VRT fournit un rapport d’impact contemporain indépendant. Elle a identifié des sites web gouvernementaux, des travaux parlementaires, l’accès au télétravail ou aux étudiants et les réservations de vaccination parmi les fonctions touchées. [8]

Ensemble, ces sources soutiennent plusieurs conclusions.

Premièrement, l’événement était un incident de déni de service contre une infrastructure réseau partagée, et non la simple compromission d’une application.

Deuxièmement, l’impact a varié. Le récit officiel décrit explicitement des degrés de perturbation différents.

Troisièmement, la réponse a été itérative. Belnet n’appliquait pas une règle statique à une inondation inchangée. Ses mises à jour de statut décrivent des vagues, des chemins alternatifs, des règles d’atténuation, une stabilisation et des problèmes résiduels.

Quatrièmement, le point final opérationnel n’était pas un horodatage universel. Dire que la situation était maîtrisée dans la soirée ne prouve pas que chaque client, site, application et chemin d’accès à distance était alors entièrement rétabli.

Le dossier public laisse d’importantes lacunes.

Il ne fournit pas de pic vérifié en bits par seconde ni en paquets par seconde. Il ne fournit pas de répartition par protocole. Il ne dit pas si l’usurpation de source a été déterminante. Il n’identifie ni les chemins d’entrée exacts, ni les liens saturés, ni les routeurs contraints, ni la capacité d’atténuation. Il ne publie pas la chronologie complète de la détection, de l’escalade, du reroutage, du filtrage et du rétablissement client.

Il n’établit pas non plus d’attaquant nommé ni de mobile. Un récit gouvernemental a décrit un trafic piloté par botnet à un niveau général, mais le dossier figé n’identifie ni le contrôleur du botnet, ni la population d’appareils, ni la chaîne d’attribution. Toute spéculation politique serait irresponsable.

L’absence de ces faits n’est pas une excuse pour combler les lacunes. C’est une raison de distinguer les constats des demandes de preuves.

Par exemple, le filtrage d’entrée est un contrôle réseau important, mais l’ensemble de sources n’établit pas que des adresses source usurpées ont provoqué l’inondation de Belnet. Il serait faux d’affirmer que l’adoption universelle d’une seule pratique de filtrage aurait nécessairement empêché cet événement.

De même, un centre de nettoyage externe peut absorber une inondation importante, mais les sources publiques ne divulguent ni la capacité exacte disponible avant l’incident ni les conditions contractuelles pour l’invoquer. Des documents ultérieurs de Belnet indiquent qu’un service cloud externe a été introduit en mai 2021. [6] C’est une preuve de changement, pas une reconstruction complète de l’architecture antérieure à l’incident.

Un article rigoureux doit rendre les inconnues visibles, car elles définissent les questions de responsabilité restantes:

Quelle caractéristique du trafic a créé la contrainte?
Quels liens ou équipements partagés sont devenus des goulots d’étranglement?
Quelles atténuations étaient automatiques, et lesquelles exigeaient une approbation humaine?
Combien de temps chaque escalade a-t-elle pris?
Quels clients étaient protégés individuellement?
Quelles institutions disposaient de chemins indépendants?
Quel trafic légitime a été filtré ou retardé?
Comment Belnet et ses clients ont-ils décidé que le service était rétabli?

Ces questions sont plus utiles qu’une théorie non étayée sur l’attaquant.

Belnet était une surface de contrôle du réseau, pas une simple dépendance cloud générique

La cible de cet article est l’infrastructure réseau. Cette distinction compte, car l’incident pourrait sinon être réduit à une histoire générique de cybersécurité ou d’informatique gouvernementale.

La description de service public de Belnet indique que son réseau combine des connexions IP et optiques et donne accès à l’internet commercial et aux réseaux de recherche. [9] Sa FAQ technique décrit des connexions directes dans les points de présence de Belnet, des options de dernier kilomètre par des tiers, des interfaces de backbone et la possibilité d’une seconde connexion passant par un autre point de présence et un chemin de fibre distinct pour les besoins critiques. [10]

Ces détails identifient plusieurs domaines de contrôle distincts.

Belnet contrôle le backbone et le service fourni à ses points de présence. Il peut observer le trafic entrant dans son réseau, configurer des routeurs, établir des règles d’atténuation, rediriger le trafic et coordonner une réponse à l’échelle du réseau.

Un fournisseur de dernier kilomètre contrôle le circuit entre une institution et Belnet lorsque cette institution n’est pas directement présente dans un point de présence de Belnet. Une défaillance ou une limite de capacité à cet endroit n’est pas automatiquement sous le seul contrôle de Belnet.

L’institution connectée contrôle son réseau local, son pare-feu, ses dépendances DNS, son exposition applicative et l’utilisation d’une connectivité secondaire. Belnet peut proposer un accès redondant, mais l’institution doit encore l’acquérir, le configurer et le tester.

Les fournisseurs de transit amont et d’atténuation contrôlent la capacité et le filtrage en dehors du domaine administratif de Belnet. Leur efficacité dépend d’une autorité, d’un routage et de contacts opérationnels convenus à l’avance.

Ces frontières comptent pendant la réponse DDoS, car l’endroit où le trafic doit être filtré est souvent hors du contrôle direct du propriétaire de l’application.

Si le trafic malveillant sature un lien d’accès avant d’atteindre un pare-feu local, le filtrage à l’institution est trop tardif. Si une inondation menace la liaison montante d’un fournisseur, celui-ci peut devoir rediriger le trafic vers un service de nettoyage ou demander de l’aide à un réseau amont. Si l’atténuation exige des changements de routage ou de préfixes clients, les entités ont besoin d’une autorité et de procédures testées avant que la congestion ne rende la communication difficile.

Les pages actuelles de Belnet sur la sécurité DDoS avancée décrivent précisément ce type de réponse réseau en couches. Elles mentionnent un filtrage basé sur les routeurs, un centre de nettoyage interne et un centre de nettoyage cloud externe. La FAQ technique indique que le trafic est normalement tenu hors du chemin de nettoyage et qu’il y est redirigé lorsque la détection signale une attaque. Elle décrit aussi un reroutage manuel vers le service externe lorsque le réseau risque la saturation. [4][5]

La conception actuelle ne peut pas être projetée dans le passé sans preuve. Elle clarifie toutefois les décisions concrètes qu’un opérateur doit gouverner:

Quelle anomalie déclenche le filtrage par routeur?
Quelle destination est redirigée?
Quel trafic légitime reste joignable?
Quand la capacité interne est-elle insuffisante?
Qui autorise la redirection externe?
Quelles routes et communautés sont utilisées?
Comment l’action est-elle annulée?
Quelles preuves démontrent que l’atténuation a fonctionné?

Ce sont des questions d’exploitation réseau. Elles concernent les chemins de trafic, l’autorité de contrôle, la capacité partagée et le service observable. L’incident relève de la responsabilité de l’infrastructure réseau parce que le préjudice public a suivi le comportement de ces contrôles.

Les attaques volumétriques sont des épreuves de capacité aux solutions incomplètes

Le RFC 4732 décrit un fait architectural inconfortable: presque tout service internet peut être rendu indisponible si un attaquant peut rassembler assez de trafic ou exploiter assez d’état. [12] Cela ne rend pas la résilience impossible. Cela signifie que les affirmations de prévention doivent être précises.

Une attaque volumétrique tente de consommer une ressource contrainte. La ressource peut être un lien internet, la capacité de transfert d’un routeur, une table d’état de pare-feu, un équilibreur de charge, un service DNS ou une application. La bonne atténuation dépend de l’endroit où la contrainte se produit et du trafic qui peut être distingué.

Si le goulot d’étranglement est une liaison montante, ajouter une règle de pare-feu locale peut ne pas rétablir le service parce que les paquets d’attaque ont déjà consommé le lien. Si le goulot est un traitement avec état, déplacer le filtrage vers une politique de routeur sans état peut aider. Si le trafic est réparti entre de nombreuses sources réelles et ressemble à une demande légitime, un simple blocage par source peut être inefficace ou nuisible.

Le dossier public de Belnet qualifie l’incident de volumétrique et indique que des vagues d’attaque ont menacé la connectivité. [1][2] Il ne divulgue pas la ressource exacte qui a cédé en premier.

Cette incertitude change la manière dont les contrôles doivent être évalués.

La capacité est un contrôle. Un opérateur peut provisionner une marge et diversifier les chemins amont. La capacité seule ne peut garantir la survie contre toute inondation imaginable, mais elle peut relever le seuil et créer du temps pour l’atténuation.

La détection est un autre contrôle. La télémétrie de flux, les compteurs de routeurs et les sondes de service peuvent identifier un trafic inhabituel, des destinations touchées et une saturation. La détection doit continuer de fonctionner lorsque le réseau est sous stress.

Le filtrage est un autre contrôle. Les listes de contrôle d’accès, les spécifications de flux, les routes nulles, les limitations de débit et les systèmes de nettoyage peuvent éliminer le trafic malveillant. Chacun peut aussi bloquer du trafic légitime si la portée ou la correspondance est incorrecte.

La redirection est un autre contrôle. Le trafic peut être envoyé à travers une capacité de nettoyage interne ou externe. Cela exige une autorité de routage, l’acceptation des préfixes, une conception du chemin de retour et assez de capacité propre.

La segmentation client est un autre contrôle. Si une inondation contre une destination peut menacer des liaisons montantes partagées, le fournisseur doit décider quand et comment protéger le reste du réseau, même si le client ciblé n’a pas acheté de service d’atténuation individuel.

La communication est un autre contrôle. Les équipes d’exploitation ont besoin d’un chemin vers les clients, les fournisseurs amont et les autorités pendant que la connectivité de production est dégradée. La page de statut et la procédure de crise de Belnet faisaient partie de ce plan de contrôle. [1][7]

Aucun de ces éléments n’est complet à lui seul. Le RFC 4948 traite du filtrage, des listes d’accès, du routage nul, du provisionnement et des incitations qui peuvent ralentir le déploiement de contrôles dont les bénéfices sont répartis sur tout l’internet. [14] Le problème de responsabilité n’est donc pas de savoir si un opérateur possède un produit appelé protection DDoS. Il est de savoir si les contrôles techniques, contractuels et humains forment une séquence testée.

Un énoncé de résilience utile identifierait:

les ressources surveillées pour épuisement;
les seuils qui déclenchent l’action;
l’autorité d’atténuation;
la capacité interne et externe disponible;
les routes utilisées pour la redirection;
le traitement du trafic légitime;
la solution de repli si le chemin d’atténuation principal échoue;
les preuves conservées pour examen.

Sans cette séquence, « nous avons une protection DDoS » est une description de produit, pas un résultat de résilience.

La concentration peut amplifier les dommages même lorsque les applications sont distinctes

Les institutions touchées par l’intermédiaire de Belnet n’étaient pas une seule organisation. Elles comprenaient des entités ayant des gouvernances, des technologies et des missions publiques différentes. [7][11]

La connectivité partagée reliait ces différences.

Un ministère pouvait héberger des sites web publics dans un environnement et dépendre de Belnet pour l’accès de son personnel. Une université pouvait utiliser le réseau pour le trafic de recherche, la fédération d’identité, l’apprentissage à distance et des services externes. Un hôpital ou un centre de recherche pouvait avoir des flux de données spécialisés. Un organe parlementaire pouvait dépendre de la vidéo, des documents, de l’authentification et des communications publiques.

Les applications n’ont pas besoin de partager du code pour qu’une panne de réseau corrèle leurs défaillances.

C’est pourquoi les registres de dépendances devraient inclure les contrôles réseau externes, et pas seulement les fournisseurs de logiciels.

Une cartographie de service classique peut lister une application, une base de données, un fournisseur d’identité et un hébergeur cloud. Elle peut encore omettre le chemin par lequel les utilisateurs et le personnel atteignent ces composants. Si les applications principale et de secours dépendent du même circuit d’accès, du même résolveur DNS, du même préfixe de fournisseur ou de la même route amont, la redondance apparente peut disparaître lors d’un incident fournisseur.

La FAQ technique de Belnet indique que les institutions ayant des besoins critiques de connectivité peuvent obtenir une seconde connexion passant par un autre point de présence et, lorsque cela est possible, un chemin de fibre distinct. [10] C’est une option importante. Cela ne prouve pas que chaque institution touchée disposait d’une telle diversité ni que chaque chemin secondaire était indépendant du même plan de contrôle DDoS.

Une véritable diversité de chemins exige plus que deux câbles.

Les chemins devraient éviter les fourreaux, équipements d’accès et alimentations communs lorsque cela est faisable. Ils devraient aboutir à des points de présence distincts. La politique de routage devrait permettre au trafic de se déplacer lorsque le chemin principal est dégradé. Les pare-feu et les services d’identité devraient accepter le chemin alternatif. Le DNS public et la configuration d’accès à distance ne devraient pas exiger de modifications manuelles impossibles à réaliser pendant la panne.

Il existe aussi un problème d’achat.

La connectivité redondante coûte de l’argent. Les institutions publiques peuvent optimiser pour la disponibilité ordinaire en supposant que l’opérateur du réseau national absorbera le trafic extraordinaire. L’opérateur peut proposer une connectivité de base et une atténuation individuelle optionnelle, tout en conservant la responsabilité de la stabilité du backbone partagé. Les clients peuvent ne pas savoir si leur service est protégé de manière proactive ou s’ils ne reçoivent qu’une assistance réactive.

L’article de surveillance de Belnet de 2022 rend cette distinction explicite. Il indique que certaines organisations ont acheté un service d’atténuation avec surveillance, tandis que d’autres pouvaient recevoir une aide réactive. Il précise aussi que le nettoyage cloud externe pouvait être invoqué lorsqu’une attaque contre un client menaçait les liaisons montantes du réseau. [6]

Cela crée au moins trois couches de responsabilité:

la protection individuelle du client ciblé;
la protection de l’infrastructure partagée du fournisseur;
les dispositifs de continuité pour les services critiques de chaque institution.

Ces couches ne doivent pas être confondues. Un fournisseur peut protéger son backbone en mettant une cible en blackhole, tandis que la cible reste indisponible. Un client peut acheter un nettoyage, tandis qu’une autre dépendance échoue. Une institution peut maintenir un second circuit, tandis que les deux circuits dépendent de la même décision d’atténuation amont.

La question d’intérêt public est de savoir si les services critiques connaissent le résultat qu’ils achètent.

La séquence de réponse révèle où l’autorité comptait

Les mises à jour de statut en direct de Belnet sont utiles parce qu’elles montrent la réponse comme une séquence plutôt que comme une déclaration unique. [1]

Le message précoce identifiait des problèmes de connectivité et une atténuation active. Les mises à jour ultérieures indiquaient que l’attaque continuait par vagues. Les ingénieurs travaillaient à stabiliser la situation et à construire des chemins alternatifs. Ils ont mis en œuvre des règles d’atténuation et surveillé le réseau. La situation est devenue plus stable, mais des incidents résiduels subsistaient. Belnet a ensuite décrit des mécanismes de protection à plus long terme et des chemins d’escalade.

Chaque étape exigeait un type d’autorité différent.

La surveillance exigeait l’accès à la télémétrie du réseau et aux signalements des clients.

Les chemins alternatifs exigeaient le contrôle du routage et de la connectivité disponible.

Les règles d’atténuation exigeaient l’autorité de modifier le comportement de transfert ou de filtrage, ainsi qu’un jugement sur l’impact collatéral.

L’aide externe exigeait des contacts établis et l’autorisation d’échanger des informations de routage ou d’atténuation.

La remédiation client exigeait une coordination avec des institutions dont Belnet ne contrôlait pas entièrement le trafic et les applications.

Le changement à plus long terme exigeait des décisions d’achat, d’architecture et de gouvernance dépassant l’équipe d’incident.

Le récit fédéral ajoute la coordination de crise avec le Centre pour la Cybersécurité Belgique. [7] Cette étape compte parce qu’un opérateur de réseau ne peut pas déterminer seul la conséquence de service public de chaque panne client. La coordination gouvernementale peut prioriser les dépendances critiques, consolider l’impact et soutenir la communication.

La responsabilité devrait examiner si ces autorités étaient claires avant l’attaque.

Qui pouvait déclarer un incident à l’échelle du réseau? Qui pouvait rediriger le trafic? Qui pouvait invoquer une capacité externe? Un seul ingénieur pouvait-il effectuer un changement de routage à fort impact, ou une double approbation était-elle requise? Comment la vitesse était-elle équilibrée avec le risque de changement? Les contacts d’urgence étaient-ils joignables hors bande? Les clients savaient-ils où signaler des défaillances résiduelles une fois les indicateurs agrégés améliorés?

Ces questions n’impliquent pas que la réponse a été lente ou inappropriée. Les preuves publiques ne suffisent pas pour cette conclusion. Elles définissent les contrôles opérationnels qui devraient pouvoir être examinés après un événement de cette ampleur.

L’expression « sous contrôle » doit aussi avoir une définition mesurable.

Elle pourrait signifier que le trafic d’attaque n’augmentait plus. Elle pourrait signifier que les liaisons montantes partagées n’étaient plus saturées. Elle pourrait signifier que la plupart des clients avaient une connectivité. Elle pourrait signifier que les institutions critiques étaient joignables. Elle pourrait signifier qu’aucune nouvelle vague d’attaque ne produisait d’impact matériel.

Ce sont des conditions différentes.

Un processus de statut responsable devrait relier l’expression publique aux preuves internes. Il devrait aussi séparer la stabilisation du réseau du rétablissement complet des clients. Le journal de statut de Belnet a continué de mentionner des problèmes résiduels et des travaux à plus long terme après avoir signalé la stabilité. [1] Cette séquence soutient un modèle plus précis:

confinement;
stabilisation du réseau;
rétablissement des clients;
clôture des incidents résiduels;
remédiation;
vérification.

Les combiner en un seul horodatage masque la vérité opérationnelle.

Les dispositifs ultérieurs témoignent d’un apprentissage, pas de la conception antérieure

Les preuves post-incident sont souvent plus faibles que le dossier de l’incident. Les organisations annoncent des investissements sans expliquer quelle défaillance elles traitent. Les documents ultérieurs de Belnet sont plus précis que cela, même s’ils exigent encore une datation prudente.

La FAQ sur l’adressage point à point indique que Belnet voulait renforcer la résilience du réseau après l’attaque DDoS majeure de 2021. Elle explique que les adresses point à point ne devraient être utilisées que pour l’interconnexion et le routage, les configurations client étant mises en conformité lorsque nécessaire. [3]

C’est une frontière de contrôle concrète. La discipline d’adressage peut simplifier la protection parce que les adresses d’infrastructure ne sont pas traitées comme des adresses client générales. Elle peut réduire l’ambiguïté du routage et du filtrage. Elle peut faciliter la distinction des fonctions d’interconnexion des destinations qui devraient recevoir le trafic ordinaire.

La FAQ ne prouve pas qu’une mauvaise utilisation des adresses a causé l’incident de 2021. L’affirmation correcte est que Belnet a lié le changement à l’amélioration de la protection après l’incident.

L’article de surveillance de Belnet de 2022 indique qu’un centre de nettoyage cloud externe a été mis en œuvre en mai 2021. Il décrit l’utilisation de cette couche lorsqu’une attaque puissante contre un client menace de saturer le reste du réseau. [6]

Cela est également précis. Cela identifie la ressource protégée comme les liaisons montantes du réseau et distingue la protection individuelle du client de la protection à l’échelle du réseau.

Les pages actuelles de Belnet sur la sécurité DDoS avancée décrivent une structure à trois niveaux utilisant un filtrage automatisé dans les routeurs, un centre de nettoyage interne et un centre de nettoyage cloud externe. [4][5]

La FAQ technique indique que des détecteurs analysent le trafic entrant dans le réseau et peuvent le rediriger vers le nettoyage interne. Elle précise que le reroutage externe est manuel afin de préserver le contrôle lors de l’envoi de trafic à un tiers. Elle décrit aussi un équipement de nettoyage interne redondant. [5]

Ces détails montrent que la résilience implique des compromis.

L’automatisation peut réduire le temps de réponse, mais peut amplifier une mauvaise détection ou un mauvais changement de route.

L’approbation manuelle peut préserver le contrôle humain, mais peut retarder l’atténuation pendant qu’un lien est saturé.

Le nettoyage hors chemin évite des sauts supplémentaires permanents et peut réduire le risque du service ordinaire, mais il dépend du fonctionnement de la détection et de la redirection sous attaque.

Le nettoyage externe ajoute de la capacité et une répartition géographique, mais il introduit un autre fournisseur, une relation de routage et un chemin de données.

La redondance interne protège contre une défaillance d’équipement, mais elle ne protège pas automatiquement une liaison montante externe d’une inondation supérieure à sa capacité.

Le test de responsabilité est de savoir si ces compromis ont été testés contre la classe de défaillance réelle.

Un reçu d’achat n’est pas un test. Un tableau de bord de produit n’est pas un test. Une démonstration réussie à faible volume n’est pas un test.

Les preuves devraient montrer la détection à un volume réaliste, l’autorité de rerouter, la propagation des routes, des chemins de retour propres, la préservation du trafic légitime, une politique propre au client, la télémétrie pendant la saturation, une solution de repli lorsqu’un fournisseur d’atténuation est indisponible et un retrait sûr après l’attaque.

Les pages publiques de Belnet décrivent des mécanismes. Un dossier de responsabilité complet relierait ces mécanismes à des exercices mesurés et à des résultats d’incident.

L’atténuation interdomaine doit être organisée avant que le lien ne sature

Les documents DDoS Open Threat Signaling fournissent un cadre de comparaison utile parce qu’ils traitent un problème structurel: le réseau subissant une attaque peut avoir besoin d’aide d’un autre domaine administratif.

Le RFC 8612 énonce des exigences pour la signalisation d’atténuation DDoS. Le RFC 8811 décrit une architecture dans laquelle un client peut demander de l’aide à un fournisseur d’atténuation et recevoir un statut. Le RFC 8782 définit un canal de signal conçu pour des conditions hostiles. Le RFC 8903 décrit des cas d’usage. Le RFC 9244 traite de la télémétrie, y compris des tuyaux de connectivité partagée. [15][16][17][18][19]

Ces normes ne doivent pas être présentées comme la preuve que Belnet a déployé DOTS. Leur valeur est analytique.

Elles montrent pourquoi un opérateur ne devrait pas inventer la relation de service pendant un incident.

Les parties ont besoin d’identités, d’authentification, d’autorisation, de portée et de chemins de contact. Le fournisseur d’atténuation doit savoir quels préfixes ou services la partie demandeuse peut contrôler. Les changements de routage doivent être acceptés. La télémétrie a besoin d’un sens commun. Le chemin de signal lui-même doit survivre à des conditions dégradées.

Le journal de statut de Belnet mentionnait des chemins d’escalade, et ses documents ultérieurs décrivent le nettoyage cloud externe. [1][6] Les normes aident à transformer ces concepts en questions d’examen.

La relation externe était-elle active avant l’inondation? Les préfixes clients et les politiques de routage étaient-ils préautorisés? Belnet pouvait-il invoquer une protection à l’échelle du réseau sans attendre chaque client? Les clients individuels pouvaient-ils demander une protection? Quelles conditions déclenchaient l’escalade externe? Le chemin de signalisation et de gestion dépendait-il du réseau de production congestionné? Quel statut le fournisseur d’atténuation renvoyait-il? Quelle télémétrie prouvait que le trafic propre était revenu?

La télémétrie des tuyaux partagés est particulièrement importante.

Si plusieurs clients partagent une contrainte de capacité physique ou logique, une attaque contre l’un peut dégrader les autres. Le fournisseur doit identifier la destination attaquée, la ressource partagée, le trafic propre et le point où l’atténuation individuelle devient une protection du réseau.

Cette décision a des conséquences.

Mettre une destination en blackhole peut rétablir le réseau partagé tout en refusant tout service à la cible. Le nettoyage peut préserver le service, mais peut ajouter de la latence ou des faux positifs. La limitation de débit peut répartir la douleur entre les utilisateurs légitimes. Le reroutage peut modifier la longueur et la capacité du chemin. Attendre peut laisser l’inondation toucher des clients sans lien avec la cible.

Il n’existe pas de seuil universel qui résout tous les cas. Le seuil est une décision de gouvernance informée par la conception du réseau, la criticité des clients, la capacité et l’autorité contractuelle.

La responsabilité signifie que l’opérateur peut expliquer cette décision avec des preuves après coup.

Le filtrage d’entrée compte, mais il n’explique pas à lui seul l’événement

Le RFC 2827 décrit le filtrage d’entrée du réseau destiné à réduire les attaques utilisant des adresses source falsifiées. Le RFC 4948 traite de la valeur et de la difficulté de déploiement de ce contrôle. [13][14]

Ces normes appartiennent à un article sur la responsabilité DDoS, car le trafic d’attaque peut exploiter une faible validation des sources sur de nombreux réseaux. Les opérateurs qui autorisent les paquets usurpés externalisent les coûts vers les victimes et les fournisseurs d’atténuation. Une adoption large peut réduire certaines classes d’attaques.

Les preuves relatives à Belnet ne disent pas si l’usurpation a été centrale dans l’inondation de mai 2021.

Cette frontière doit rester explicite.

Si l’attaque a utilisé des appareils compromis avec des adresses source valides, le filtrage d’entrée sur ces réseaux n’aurait peut-être pas pu l’éliminer. Si elle a utilisé la réflexion et l’amplification avec des adresses de victime falsifiées, la validation des sources aurait pu réduire le trafic à l’origine. Si elle a combiné plusieurs vecteurs, différents contrôles s’appliqueraient.

L’ensemble de sources publiques ne choisit pas entre ces possibilités.

L’analyse de responsabilité correcte sépare la politique de contrôle de l’affirmation causale.

Les réseaux devraient mettre en œuvre une validation appropriée des sources parce qu’elle réduit une classe connue d’abus et protège l’internet dans son ensemble. C’est un devoir général soutenu par les normes.

Belnet et ses partenaires devraient aussi conserver une télémétrie d’événement suffisante pour déterminer si l’usurpation, la réflexion, le trafic direct de bots ou les requêtes applicatives ont piloté l’incident. C’est un devoir de preuve propre à l’événement.

La distinction compte parce que les recommandations génériques peuvent créer une fausse clôture.

Si un opérateur répond à une inondation directe de botnet en annonçant un filtrage d’entrée, il se peut qu’il n’ait pas traité la ressource saturée. S’il répond à une attaque par réflexion uniquement en achetant plus de capacité, il peut manquer des occasions de filtrage amont et de validation des sources. S’il déploie des filtres agressifs sans mesurer le trafic légitime, il peut créer un nouveau problème de disponibilité.

La sélection des contrôles devrait suivre les preuves.

C’est également là qu’apparaît la responsabilité économique. Le RFC 4948 note que certains filtrages profitent à d’autres réseaux de manière plus visible qu’au réseau qui paie pour les déployer. [14] Les réseaux publics et les régulateurs peuvent aider à corriger ce problème d’incitation par des exigences d’achat, des attentes de peering, la transparence et des services partagés.

La position de Belnet comme opérateur de réseau public rend la question des incitations particulièrement pertinente. Il peut mutualiser la protection pour des institutions qui auraient du mal à l’acheter individuellement. Il peut aussi exiger des clients et des fournisseurs connectés qu’ils maintiennent une discipline d’adressage et de routage. Le changement d’adressage point à point est un exemple de l’utilisation par l’opérateur de règles de service pour améliorer une surface de contrôle partagée. [3]

La leçon n’est pas qu’une seule bonne pratique aurait arrêté la panne. Elle est que la résilience des réseaux partagés dépend de contrôles déployés au-delà des frontières organisationnelles, et que des preuves sont nécessaires pour choisir les bons.

Les institutions connectées avaient aussi des obligations de continuité

Belnet contrôlait le réseau partagé. Cela ne signifie pas que chaque obligation de continuité appartenait à Belnet.

Les institutions connectées contrôlaient ce qui se passait après la dégradation de la connectivité.

Elles pouvaient identifier les applications critiques, maintenir un accès alternatif, séparer les chemins publics et administratifs, préserver des communications hors bande, tester le repli du télétravail et décider quels services exigeaient des fournisseurs indépendants.

Les options pratiques variaient. Un petit organisme de recherche ne pouvait pas construire un réseau national de nettoyage. Un ministère ne pouvait pas reconfigurer le backbone de Belnet. Une université ne pouvait pas invoquer unilatéralement un fournisseur d’atténuation amont pour des routes appartenant à Belnet.

La responsabilité devrait correspondre à cette réalité.

Les institutions ne devraient pas être blâmées pour des contrôles qu’elles ne pouvaient pas exploiter. Elles devraient être responsables des choix relevant de leur autorité.

Pour un service de réservation de vaccination, cela pouvait inclure un chemin d’accès public secondaire, un basculement DNS testé, des pages d’information en cache, un repli vers un centre d’appels et un canal de statut clair.

Pour les travaux parlementaires, cela pouvait inclure un chemin alternatif de conférence ou de documents et un moyen de poursuivre les travaux essentiels sans le réseau principal.

Pour les universités, cela pouvait inclure des communications d’urgence indépendantes, un accès local aux systèmes critiques et des limites documentées sur les services d’apprentissage à distance ou de recherche.

Pour les ministères, cela pouvait inclure un registre de dépendances montrant quelles fonctions comptent sur Belnet pour l’accès public, l’accès du personnel, l’identité, les échanges interinstitutionnels et la communication d’incident.

Ces contrôles exigent une coordination avec le fournisseur de réseau.

Un second circuit n’est utile que si l’institution sait s’il partage un point de présence, un trajet de fibre, une dépendance amont ou d’atténuation avec le premier. Le basculement DNS n’est utile que si le DNS faisant autorité et l’accès de gestion restent disponibles. Un service d’accès à distance de secours n’est utile que si l’identité et les terminaux peuvent l’atteindre.

La FAQ technique de Belnet décrit des options pour un second point de présence et un chemin de fibre distinct. [10] Les institutions devraient pouvoir traduire ces options en décisions de risque propres à chaque service.

Les achats publics peuvent soutenir cela en posant les questions suivantes:

Quels domaines de défaillance physiques et administratifs sont indépendants?
La protection DDoS est-elle proactive ou réactive?
Quelle capacité est réservée?
Qui peut déclencher l’atténuation?
Quels objectifs de rétablissement s’appliquent au réseau partagé et aux clients individuels?
Quelle télémétrie et quelles preuves post-incident seront fournies?
Comment les changements d’urgence sont-ils autorisés et examinés?

Ces questions empêchent un contrat de réduire la résilience à un pourcentage de disponibilité qui dit peu sur les attaques corrélées.

La communication publique de statut fait partie du plan de contrôle de la reprise

Pendant un incident réseau, la communication n’est pas séparée des opérations. Elle influence les décisions des clients, l’escalade et les preuves.

La page de statut de Belnet a donné des mises à jour répétées à mesure que l’attaque évoluait. [1] Les messages identifiaient des problèmes de connectivité, des vagues en cours, des travaux d’atténuation, des chemins alternatifs, la stabilisation et des problèmes résiduels.

Ce rythme compte pour les institutions qui décident d’invoquer leurs plans de continuité locaux.

Un message vague « enquête en cours » peut laisser les clients attendre pendant que leur propre fenêtre de repli se ferme. Un message trop confiant « résolu » peut amener les institutions à retirer des contrôles temporaires avant que tous les chemins soient stables. Un message technique détaillé peut créer un risque de sécurité ou dérouter les non-spécialistes.

Le bon dossier public devrait répondre aux questions opérationnelles sans exposer de configuration sensible:

Le problème est-il dans le réseau partagé?
Quelle large classe de service est touchée?
Le trafic d’attaque continue-t-il?
L’atténuation est-elle active?
Les clients récupèrent-ils à des rythmes différents?
Les institutions devraient-elles garder leur repli local actif?
Où les incidents résiduels devraient-ils être signalés?
Quand la prochaine mise à jour arrivera-t-elle?

Le journal de statut devient aussi une preuve.

Il peut être comparé à la télémétrie des routeurs, aux journaux du fournisseur d’atténuation, aux tickets clients et aux décisions de crise. Les différences peuvent révéler un retard de détection, une évaluation d’impact incomplète ou des lacunes de reprise.

C’est pourquoi les horodatages devraient être conservés sous forme structurée. Un récit ultérieur peut résumer l’événement, mais les intervenants et les superviseurs ont besoin de la séquence originale.

Le compte rendu parlementaire fédéral démontre une autre couche de communication: la supervision publique. [7] Les responsables devaient expliquer l’ampleur, l’impact institutionnel, la coordination et l’action préventive. Un processus de supervision utile devrait demander des preuves sans forcer la divulgation de détails exploitables.

Les questions devraient se concentrer sur le contrôle et la preuve:

Quelle ressource partagée a été contrainte?
Quelle capacité d’atténuation existait?
Qu’est-ce qui a changé pendant la réponse?
Quelles institutions manquaient de chemins indépendants?
Quel dispositif ultérieur traite quelle défaillance observée?
Comment la réparation a-t-elle été testée?

Demander seulement qui a attaqué peut laisser la leçon d’infrastructure sans réponse.

Une affirmation de rétablissement doit être propre à chaque service et vérifiable indépendamment

Les opérateurs de réseau signalent souvent une stabilité agrégée avant que chaque client n’ait récupéré. Cela n’est pas nécessairement trompeur. Un backbone peut être stable pendant que des sessions locales, des routes ou des applications restent dégradées.

Le problème survient lorsque les étapes ne sont pas distinguées.

La séquence de statut de Belnet est passée de vagues actives et de chemins alternatifs à des règles d’atténuation, une stabilisation, des incidents résiduels et des travaux à plus long terme. [1] Cela soutient un modèle de reprise en plusieurs étapes.

Confinement

La croissance de l’attaque est limitée, le trafic dangereux est filtré ou redirigé, et les opérateurs reprennent le contrôle des ressources partagées.

Stabilisation du réseau

L’utilisation du backbone et des liaisons montantes reste dans des limites sûres. Le routage et l’atténuation ne fluctuent plus. La surveillance centrale est fiable.

Rétablissement de la connectivité client

Les institutions connectées peuvent échanger du trafic par les chemins attendus. Les exceptions sont identifiées plutôt que cachées dans des moyennes.

Rétablissement du service

Les sites web publics, l’accès à distance, l’identité, la vidéo, la recherche et d’autres fonctions sont testés depuis l’extérieur de l’institution.

Clôture des incidents résiduels

Les problèmes de route, de filtre, d’état ou de dernier kilomètre propres à un client sont résolus.

Vérification de la remédiation

La classe de défaillance d’origine est rejouée ou simulée contre les contrôles modifiés, avec retour en arrière et preuves.

Chaque étape devrait avoir des critères de sortie.

Pour le confinement, les critères pourraient inclure une perte de paquets réduite, une capacité propre disponible et des ressources de routeurs stables.

Pour la stabilisation du réseau, ils pourraient inclure une utilisation soutenue, une convergence des routes, une cohérence de l’atténuation et une télémétrie saine.

Pour le rétablissement des clients, ils pourraient inclure des sondes représentatives sur les points de présence et les classes de clients.

Pour le rétablissement du service, les institutions ont besoin de contrôles au niveau applicatif. Une interface peut être joignable alors que l’authentification, les transactions ou le travail à distance restent en panne.

Les tests indépendants comptent parce qu’un plan de contrôle endommagé ou surchargé peut se déclarer lui-même sain.

Les sondes externes, les mesures des clients et des chemins de gestion séparés peuvent contester la vue interne de l’opérateur. Elles ne remplacent pas la télémétrie de l’opérateur, mais elles réduisent le risque de déclarer le succès à partir des mêmes systèmes en cours de réparation.

Les orientations DDoS ultérieures de la CISA mettent l’accent sur la planification, la coordination des fournisseurs et la réponse en couches. [20] Elles sont utiles comme comparaison, pas comme preuve de la procédure de Belnet en 2021.

Le principe général reste durable: le rétablissement doit être démontré du point de vue des utilisateurs légitimes et de l’infrastructure partagée, pas seulement depuis un tableau de bord.

Le dossier de preuves qu’un réseau public responsable devrait conserver

Un rapport post-incident n’a pas besoin de publier des configurations sensibles de routeurs. Il devrait tout de même préserver assez de preuves pour que les clients, les autorités et des examinateurs indépendants comprennent ce qui s’est passé.

Le dossier devrait commencer par l’intégrité des octets actuels.

Les extraits de télémétrie, les instantanés de configuration, les règles d’atténuation, les changements de routage et les rapports devraient avoir des horodatages, une propriété et des empreintes cryptographiques. Si une preuve est révisée, la révision devrait identifier la version remplacée et la raison.

Il devrait inclure une carte des dépendances.

La carte devrait identifier les liens de backbone, les points de présence, les fournisseurs amont, les fournisseurs d’atténuation, les chemins de gestion, les canaux de statut et les classes de clients. Elle devrait montrer les capacités partagées sans exposer de détails inutiles sur les équipements.

Il devrait inclure une chronologie de l’événement.

La chronologie devrait distinguer le premier trafic nuisible, la détection, l’impact client, la déclaration d’incident, l’escalade de crise, les chemins alternatifs, le filtrage, le nettoyage interne, le nettoyage externe, la stabilisation, le rétablissement des clients et la clôture.

Il devrait inclure des preuves de ressources.

Quels liens, ressources de transfert ou services ont approché leurs limites? Quelle était la base de référence du trafic propre? Quelles classes d’attaque ont été observées? Quelle télémétrie est restée fiable sous charge?

Il devrait inclure des preuves d’action.

Quelles règles ont changé? Qui les a approuvées? Quelles routes ont bougé? Quels effets collatéraux se sont produits? Comment les changements ont-ils été annulés ou conservés?

Il devrait inclure des preuves client.

Combien d’institutions ont été matériellement touchées? Quelles classes de service ont échoué? Lesquelles avaient un accès indépendant? Comment les incidents résiduels ont-ils été collectés et clôturés?

Il devrait inclure des preuves de communication.

Quand les mises à jour de statut ont-elles été publiées? Quelles informations étaient disponibles à chaque moment? Les institutions critiques ont-elles été contactées hors bande?

Il devrait inclure des preuves de remédiation.

Quels dispositifs ultérieurs traitent quelle défaillance observée? Comment les changements d’adresse point à point ont-ils été vérifiés? Quand le nettoyage externe a-t-il été rendu disponible? Quels tests ont montré que la protection en couches actuelle pouvait protéger à la fois une cible et le réseau partagé?

Il devrait inclure l’incertitude.

L’attribution inconnue, les détails de paquets manquants, les données client incomplètes et les hypothèses devraient être listés plutôt que résolus en silence.

Ce dossier fait passer la responsabilité d’une rhétorique à un processus examinable.

Il protège aussi l’opérateur. Les preuves peuvent montrer que les équipes ont agi rapidement, qu’une attaque a dépassé des hypothèses de conception raisonnables, qu’un client n’avait pas acheté un contrôle ou qu’une action amont a contraint la réponse. La responsabilité n’est pas une présomption de faute de l’opérateur. C’est une méthode pour attribuer la responsabilité selon les preuves et le contrôle.

La supervision devrait relier les mesures correctives à la défaillance observée

La discussion parlementaire fédérale a interrogé sur la prévention, l’évolution technique, l’investissement et l’évaluation. [7] Ce sont des questions appropriées, mais elles peuvent produire des réponses génériques si elles ne sont pas liées au mécanisme de défaillance.

« Nous avons investi dans la cybersécurité » ne suffit pas.

Un dossier de supervision devrait relier chaque dépense à un contrôle:

un nettoyage interne supplémentaire augmente la capacité à un point défini du réseau;
le nettoyage externe protège les liaisons montantes au-delà de la capacité locale;
la détection par routeur réduit le temps pour identifier une destination attaquée;
la discipline d’adressage point à point simplifie le filtrage et le routage;
des chemins de gestion séparés préservent l’autorité de réponse;
des points de présence secondaires réduisent la concentration des chemins d’accès;
des exercices valident l’invocation et le rétablissement.

La FAQ sur le point à point et les descriptions ultérieures des services DDoS rendent cette mise en correspondance possible. [3][4][5][6]

La supervision devrait aussi interroger sur la couverture des services.

Si seuls certains clients achètent une atténuation proactive, quelle protection le réseau partagé fournit-il lorsqu’un client non protégé est ciblé? Quand Belnet peut-il agir sans approbation du client pour protéger d’autres institutions? Qu’advient-il du service ciblé pendant cette action? Les services publics critiques sont-ils soumis à des exigences de base plus strictes?

Ce sont des décisions politiques autant que techniques.

Un réseau public peut choisir de socialiser une partie du coût d’atténuation parce qu’une cible individuelle peut créer des retombées pour des centaines d’institutions. Il peut offrir une protection renforcée aux clients présentant un risque exceptionnel. Il peut exiger une discipline de configuration comme condition de service. Il peut publier des preuves standard après des incidents majeurs.

La conception devrait être explicite.

Sinon, la responsabilité ne devient visible que pendant une panne, lorsque le fournisseur, les clients et les autorités découvrent des hypothèses différentes sur qui absorberait l’inondation.

Le véritable test de responsabilité est la préparation avant la prochaine vague

L’incident de Belnet de 2021 était dynamique. La page de statut décrivait des vagues successives et une atténuation changeante. [1]

C’est un modèle utile pour les tests de résilience.

Un test ne devrait pas envoyer un seul flux prévisible vers un seul service protégé et s’arrêter lorsque le tableau de bord passe au vert.

Il devrait varier les destinations, les protocoles et les volumes dans des limites sûres et contrôlées. Il devrait tester un client protégé et un client non protégé dont le trafic menace la capacité partagée. Il devrait tester le nettoyage interne et externe. Il devrait tester la propagation des routes, les chemins de retour et le retrait. Il devrait tester les faux positifs et les événements légitimes à fort volume.

Il devrait aussi tester les personnes.

Les opérateurs peuvent-ils invoquer l’atténuation externe la nuit? Les contacts sont-ils à jour? Peuvent-ils s’authentifier lorsque le réseau principal est dégradé? Les clients comprennent-ils les messages de statut? Les coordinateurs gouvernementaux peuvent-ils identifier les services critiques? Les ingénieurs peuvent-ils modifier les filtres avec une revue par les pairs lorsque le temps presse?

Il devrait tester les preuves.

La télémétrie et les horodatages survivent-ils? L’opérateur peut-il reconstituer quelle règle a touché quel trafic? Les sondes client peuvent-elles confirmer le rétablissement? Un examinateur indépendant peut-il reproduire la conclusion?

Il devrait tester la défaillance du système d’atténuation lui-même.

Que se passe-t-il si le nettoyeur interne est indisponible? Et si le fournisseur cloud a un incident de plan de contrôle? Et si la redirection de route est retardée? Et si un filtre bloque un trafic légitime critique? Et si la plateforme de statut dépend du chemin touché?

C’est ici que les descriptions d’architecture actuelles deviennent des contrôles responsables. [4][5]

La valeur de trois couches n’est pas le nombre trois. C’est que chaque couche a un rôle défini, une frontière de défaillance, un déclencheur et une solution de repli. Si toutes les couches dépendent du même détecteur, de la même identité de gestion ou du même chemin de routage, la diversité apparente peut encore cacher un mode commun.

Le test devrait donc demander non seulement si le système absorbe le trafic, mais aussi si l’organisation conserve le contrôle et les preuves lorsque les conditions changent.

Conclusion: les réseaux partagés créent un devoir partagé de prouver la résilience

L’incident de Belnet de mai 2021 n’a pas fait de la continuité des services publics une question de réseau. Il a révélé qu’elle l’était déjà.

Le gouvernement, l’éducation, la recherche et d’autres institutions dépendaient d’un réseau partagé. Une vaste attaque volumétrique a produit des problèmes de connectivité dans ces organisations. Belnet a répondu avec des chemins alternatifs, des règles d’atténuation, une coordination de crise et des travaux à plus long terme. Les documents ultérieurs relient la période de l’incident au nettoyage externe, à la discipline d’adressage et à une architecture de protection DDoS plus stratifiée. [1][2][3][4][5][6][7]

Les preuves ne soutiennent ni attaquant nommé, ni volume de trafic exact, ni analyse vectorielle complète, ni conclusion selon laquelle un seul contrôle manquant a causé la panne.

Elles soutiennent un cadre de responsabilité clair.

Belnet avait un contrôle concret sur l’exploitation du backbone, l’atténuation à l’échelle du réseau, le reroutage, l’escalade de crise et les preuves nécessaires pour expliquer la reprise.

Les institutions connectées avaient un contrôle concret sur l’accès secondaire, la continuité applicative, les cartes des dépendances critiques et le repli local.

Les fournisseurs amont, de dernier kilomètre et d’atténuation avaient un contrôle concret sur les chemins contractuels, la capacité et les actions interdomaines.

Les autorités publiques avaient un contrôle concret sur les exigences de continuité, les achats, la coordination et la supervision.

La responsabilité de l’attaquant pour le trafic malveillant ne supprime pas ces devoirs. La responsabilité de l’infrastructure n’implique pas non plus que chaque panne prouve une négligence.

Le bon test est de savoir si chaque partie peut montrer que son contrôle était proportionné au préjudice qu’elle pouvait empêcher ou amplifier.

Pour un réseau public partagé, cette preuve devrait couvrir la capacité, la détection, les chemins alternatifs, le nettoyage, l’autorité d’escalade, la préservation du trafic légitime, le rétablissement des clients et une remédiation testée.

Le retour du service est un accomplissement opérationnel. Montrer pourquoi le réseau est plus résilient, quels risques demeurent et comment cette conclusion a été vérifiée est le résultat de responsabilité.

La panne DDoS de Belnet en 2021 a fait de la résilience des réseaux publics partagés un test de responsabilité

Pourquoi c'est important