Akamai Prolexic a fait de la mitigation DDoS routée un test de responsabilité de contournement client

Résumé

• La mise à jour d'Akamai du 17 juin 2021 a indiqué qu'un incident du service Prolexic Routed 3.0 a affecté une partie des clients utilisant le service de mitigation DDoS routé, avec des alertes commençant à 8h47 HE et le trafic client étant rerouté automatiquement ou manuellement jusqu'à la restauration.
• Le problème responsable est la mitigation déléguée. Un client envoie du trafic via un service de nettoyage pour survivre aux attaques DDoS, mais cette route devient une dépendance de continuité d'activité lorsque la validation ou l'état de routage au sein du fournisseur de mitigation échoue.
• Akamai a déclaré que l'incident n'était pas causé par une mise à jour système ou une cyberattaque et a pointé du doigt une valeur de table de routage qui avait été involontairement dépassée. Cela restreint l'analyse à la validation opérationnelle des routes, aux contrôles de capacité/état, au reroutage et à la récupération des clients.
• L'enregistrement de mesure externe de ThousandEyes est important car il a montré des impacts clients variés et la valeur des plans de sauvegarde. Un incident de mitigation routée devrait être jugé sur la capacité des clients à contourner ou à retourner le trafic en toute sécurité lorsque la voie de défense est endommagée.
• Les preuves de réparation durables devraient couvrir les garde-fous de la table de routage, le contournement pré-validé, la notification client, la portée du reroutage automatique, la capacité de support manuel, la sécurité du retour de trafic et la preuve que la voie de mitigation ne peut pas devenir une panne plus grande que l'attaque qu'elle est censée absorber.

La mitigation déléguée change qui contrôle la continuité

La mise à jour publique d'Akamai,Akamai fournit une mise à jour sur l'impact du service Prolexic DDoS, est le compte rendu principal de l'incident. L'entreprise a déclaré que Prolexic Routed 3.0 a connu un incident de service affectant une partie des clients. Elle a indiqué que les alertes ont commencé à 8h47 HE, que le trafic client affecté a été routé automatiquement ou manuellement par les équipes d'Akamai, et que les services ont été restaurés à 12h47 HE. Elle a également déclaré que l'incident n'était pas dû à une mise à jour système ou à une cyberattaque et que le problème était une valeur de table de routage involontairement dépassée.

Cette déclaration rend précise la question de la responsabilité. Le point n'est pas de savoir si Akamai était attaqué. Le point est de savoir comment un service de protection contrôlait le chemin du trafic client et comment les clients pouvaient échapper à ce chemin lorsqu'il échouait. La mitigation DDoS n'est pas seulement une fonctionnalité de sécurité supplémentaire. Dans un modèle routé, elle peut faire partie de la topologie réseau live du client.

Les documents d'Akamai sur Prolexic décrivent le service comme une protection DDoS pour l'infrastructure. Lapage produit Prolexic, lapage de fiche produit Prolexic, et lafiche produit Prolexic PDFexpliquent l'objectif défensif: absorber, inspecter et atténuer le trafic malveillant avant qu'il n'atteigne les origines des clients. Le langage produit ultérieur/actuel ne doit pas être traité comme une conclusion sur l'incident de 2021, mais il clarifie le modèle de service qui crée la dépendance.

La dépendance est facile à comprendre de travers. Un client peut considérer la mitigation DDoS comme un bouclier placé devant le service. Une conception routée est plus qu'un bouclier. Elle modifie la manière dont le trafic atteint le client. Si le trafic est annoncé ou redirigé via des centres de nettoyage, l'état des routes, les tunnels GRE, les connexions directes, les chemins de retour et les opérations du fournisseur deviennent partie intégrante de la disponibilité. Lorsque le chemin de protection échoue, le client peut avoir besoin d'un chemin de contournement déjà conçu, autorisé, testé et compris.

Le mot « contournement » est central. Un contournement n'est pas une improvisation paniquée après que le service de protection est dégradé. C'est une méthode pré-planifiée pour ramener le trafic vers un chemin sûr tout en équilibrant le risque que le client soit à nouveau confronté à un trafic hostile. Le client ne veut pas retirer la protection à la légère pendant une attaque. Mais pendant une panne du fournisseur de mitigation, le client peut devoir choisir entre continuer via un chemin de protection défaillant et exposer une origine via un itinéraire de secours. Cette décision doit être conçue avant l'incident.

La protection routée transforme la validation de route en service client

Les documents de description de service d'Akamai sont importants car ils montrent comment la mitigation routée dépend de mécanismes de contrôle réseau. LePDF de description des services d'Akamaidécrit Prolexic Routé en termes de BGP dirigeant le trafic vers les centres de nettoyage d'Akamai. Le blog d'Akamai surProlexic et Equinix Cloud Exchangeaborde le rapprochement de la défense DDoS de l'origine du client via l'interconnexion. Ces documents ne sont pas des post-mortems de pannes, mais ils expliquent pourquoi le contrôle de routage est le service.

BGP lui-même est défini dansRFC 4271. GRE, souvent utilisé dans le retour de trafic ou la conception de tunnels dans les architectures de mitigation, est défini dansRFC 2784. Ces normes ne disent pas ce qu'Akamai a fait de mal ou de bien en 2021. Elles clarifient le vocabulaire technique: les annonces de routes, les chemins de trafic, les tunnels et les mécanismes de retour ne sont pas des détails de fond. Ils sont la surface du produit.

Si une valeur de table de routage d'un fournisseur est dépassée, les clients doivent savoir ce que cela signifie pour leur trafic. L'état affecté a-t-il bloqué la programmation de nouvelles routes? A-t-il altéré le trafic de retour? A-t-il affecté uniquement certains clients, certains préfixes, certaines régions ou certaines relations de routage? La déclaration publique d'Akamai était brève, donc une analyse responsable ne doit pas inventer de détails.

Mais la brièveté elle-même pose la question de la réparation: quels garde-fous empêchent désormais un contrôle de mitigation routée de dépasser une valeur d'état d'une manière qui affecte la disponibilité du client?

La validation de route dans ce contexte est un service client. Ce n'est pas simplement un contrôle interne d'ingénierie réseau. La validation du fournisseur protège les revenus des clients, les portails publics, les API, l'accès bancaire, les applications SaaS et les services tournés vers les urgences. Un échec de validation transfère la charge de travail aux équipes opérationnelles du client, qui doivent décider d'attendre, de rerouter, de contourner, de communiquer avec les utilisateurs ou d'escalader via le support.

La RFC 7454,Opérations et sécurité BGP, offre des attentes générales en matière de sécurité opérationnelle autour de la politique de routage, du filtrage et de l'hygiène opérationnelle. Lesactions des opérateurs réseaude MANRS et leSécurisation du routage Internetde CISA fournissent un cadre public et communautaire pour la discipline de routage. Ce sont des références générales, pas des conclusions spécifiques à l'incident. Elles sont importantes car les services de mitigation routée placent la discipline de routage de l'opérateur directement dans la continuité du client.

Note typographique

Les mesures externes montrent des impacts variés

L'analyse de la panne Akamai Prolexic Routé par ThousandEyesest précieuse car elle observe depuis l'extérieur du fournisseur. Elle a observé des différences d'accessibilité, des comportements liés au peering et des variations clients. ThousandEyes a ensuite inclus l'événement dansSept pannes qui ont secoué 2021, soulignant que certaines organisations disposant de plans de sauvegarde préparés ont pu réduire l'impact. C'est exactement la leçon de responsabilité: les défaillances de mitigation routée ne sont pas seulement des défaillances du fournisseur; ce sont des tests de préparation au contournement du client et de capacité de reroutage assisté par le fournisseur.

L'existence d'impacts variés ne doit pas devenir un blâme de la victime. Les clients achètent une mitigation DDoS parce qu'ils veulent qu'un fournisseur spécialisé absorbe un problème qu'ils ne peuvent pas gérer seuls en toute sécurité. Si le chemin de service échoue, le fournisseur reste responsable de la sécurité de la route, de la notification de statut, du reroutage automatique, de la capacité de support et de la réparation post-incident. En même temps, les clients ayant des services publics critiques ont besoin de conceptions de contournement et de repli testées, car aucun chemin de protection n'est à l'abri d'une défaillance.

Les reportages secondaires, notamment celui de SecurityWeekAkamai impute la panne au service de protection DDoSet celui d'iTnewsUne erreur de routage d'Akamai a provoqué des pannes généralisées, ont décrit des perturbations visibles affectant les services publics. Ces rapports peuvent illustrer l'ampleur, mais ils ne doivent pas être utilisés pour prétendre à une durée uniforme ou à une posture de récupération identique pour chaque organisation. La mitigation routée affecte les clients différemment selon les préfixes, les partenaires de routage, les plans de contournement, la conception des applications et la vitesse de communication.

Les preuves de mesure montrent également pourquoi la visibilité publique des routes est nécessaire. Le site web ou l'API d'un client peut être indisponible même si ses serveurs d'origine sont sains. L'utilisateur voit l'application comme étant en panne. Le client peut ne voir aucun problème évident d'origine. Le fournisseur peut être en train de rerouter. Les sondes externes peuvent montrer où le trafic échoue ou revient. Sans cette visibilité, les intervenants perdent du temps à déboguer la mauvaise couche.

Pour les fournisseurs, la leçon est que la communication publique post-incident devrait inclure suffisamment de structure de routage et d'impact client pour rendre la mesure significative. Si la déclaration publique dit seulement « incident de service », les clients ne peuvent pas savoir si leurs propres procédures doivent changer. Si elle indique quel service, quel type d'état de routage a échoué, comment le trafic a été rerouté, quels contrôles automatiques ont fonctionné, quels contrôles manuels ont été nécessaires et quels garde-fous de récurrence ont été modifiés, les clients peuvent améliorer leur propre architecture.

Le contournement est une conception partagée, pas une décision de dernière minute

Un bon plan de contournement comporte plusieurs éléments. Le client sait quels préfixes et services sont protégés. Le client sait ce qui se passe en modes toujours actif et à la demande. Le fournisseur et le client savent qui peut autoriser les changements de trafic. Les fournisseurs amont savent si des annonces alternatives sont autorisées. Le DNS, TLS, les pare-feux, les contrôles d'accès à l'origine et les limites d'application sont prêts pour des chemins de trafic modifiés. Les équipes de support connaissent les services métier les plus prioritaires. Des modèles de communication sont prêts pour les utilisateurs finaux.

Sans cette conception, le contournement peut créer de nouveaux risques. Envoyer le trafic autour du service de nettoyage peut exposer l'origine à l'attaque que le service était censé absorber. Laisser le trafic à l'intérieur d'un chemin de mitigation défaillant peut prolonger la panne. Annoncer des préfixes plus spécifiques peut créer des effets secondaires sur la politique de routage. Changer le DNS peut être trop lent ou dépendant du cache. Désactiver les restrictions d'origine peut créer une exposition de sécurité. Ces compromis ne peuvent pas être décidés calmement alors que les services publics sont déjà indisponibles.

Le NIST SP 800-61 Révision 2,Guide de traitement des incidents de sécurité informatique, est une directive générale, mais son cycle de vie des incidents est pertinent: préparation, détection, confinement, éradication, récupération et leçons apprises. Dans la mitigation routée, la préparation inclut la manière de déplacer le trafic en toute sécurité. La récupération inclut la restauration du routage protégé normal sans créer de pic, de fuite ou de faille de sécurité.

La question du contournement par le client est également économique. Les petites et moyennes entreprises peuvent ne pas avoir leur propre personnel d'ingénierie réseau. Elles peuvent dépendre entièrement du fournisseur et d'un hébergeur géré. Si la mitigation routée échoue, elles peuvent ne pas savoir quels préfixes sont annoncés, quels contacts peuvent approuver un changement, ou si un contournement existe. Un fournisseur vendant une protection à ces clients devrait fournir un langage pratique de procédures, pas seulement des diagrammes d'architecture de niveau entreprise.

Les grandes entreprises font face à un problème différent. Elles peuvent avoir des réseaux sophistiqués et plusieurs fournisseurs, mais leur gouvernance peut être lente. Si le reroutage d'urgence nécessite des approbations à travers les équipes de sécurité, réseau, juridique, métier et direction, le contournement peut exister sur le papier et rester inutilisable. La communication d'incident du fournisseur devrait donc aider les clients à prendre des décisions rapides et fondées sur des preuves.

Le reroutage automatique nécessite une preuve de couverture

La mise à jour d'Akamai a indiqué que le trafic client affecté était routé automatiquement ou manuellement par les équipes d'Akamai. Cette phrase est importante car elle identifie deux modes de récupération. Le reroutage automatique suggère une logique de basculement pré-construite. Le reroutage manuel suggère une intervention humaine pour les cas que le chemin automatique n'a pas couverts, n'a pas terminés ou qui nécessitaient un traitement spécifique au client. La question de responsabilité est de savoir comment ces catégories ont changé après l'incident.

Le reroutage automatique devrait être testé contre une défaillance réaliste côté fournisseur. Il ne suffit pas de prouver que le reroutage fonctionne lors d'un exercice planifié ou d'une transition demandée par le client. Il devrait fonctionner lorsque l'état de routage du fournisseur lui-même est dégradé, lorsque le volume d'alertes est élevé, lorsque de nombreux clients ont besoin d'aide en même temps et lorsque la communication de statut est sous pression. Le système de récupération d'un fournisseur de mitigation DDoS doit être conçu pour un impact simultané sur plusieurs clients car le service lui-même est une infrastructure partagée.

La capacité de support manuel est importante car les clients ne peuvent pas tous être les premiers en ligne. Un fournisseur peut avoir d'excellents ingénieurs et néanmoins faire face à des files d'attente lorsque de nombreux clients appellent en même temps. Le dossier de réparation public devrait expliquer si les étapes de routage manuel ont été réduites, si plus de clients ont obtenu un reroutage automatique, si les procédures de support ont changé et si la notification est devenue plus précise.

Akamai a déclaré qu'elle veillerait à ce que chaque client dispose d'un reroutage automatique vers son centre de nettoyage le plus proche en cas de défaillance. Cette promesse est un marqueur de réparation, mais les clients ont besoin de preuves ultérieures de sa réalisation.

Le retour de trafic est une autre partie de la récupération. Une fois le chemin du fournisseur réparé, ramener les clients par la protection peut créer des risques si la convergence des routes, le comportement du cache, l'état du pare-feu, l'état du tunnel ou le trafic d'attaque ne sont pas gérés. Un service peut être techniquement restauré, mais un chemin de retour négligent peut créer des défaillances intermittentes. Le dossier d'incident devrait donc inclure non seulement les heures de début et de fin de panne, mais aussi la manière dont le trafic a été ramené à un état protégé stable.

Le formulaire 10-K 2021 d'Akamai,dépôt auprès de la SEC, fournit un contexte plus large sur les risques métier: Akamai vend des services que les clients utilisent pour la performance, la sécurité et la disponibilité. Le dépôt ne décide pas de l'incident Prolexic. Il montre pourquoi les pannes de fournisseurs dans l'infrastructure de sécurité et de livraison peuvent devenir des problèmes de gouvernance pour les clients. Lorsque le rôle d'un fournisseur est la continuité, ses propres contrôles de continuité font partie du produit.

L'avis de statut doit identifier la dépendance et les points de décision

Pendant un incident de mitigation routée, les clients ont besoin de plus qu'un avis de disponibilité générique. Ils doivent savoir si le service affecté est Prolexic Routé ou une autre fonction d'Akamai, si le problème affecte tous les clients ou un sous-ensemble, si la mitigation d'attaque reste active, si le contournement est recommandé ou risqué, si le reroutage automatique est en cours et quelle action le client doit entreprendre si son application est inaccessible.

Le public peut tolérer une certaine incertitude au début d'un incident. Ce qu'il ne peut pas utiliser, ce sont des assurances vagues qui laissent les clients deviner s'ils doivent changer de routes. L'avis de statut devrait évoluer: d'abord identifier le service affecté et les symptômes; ensuite identifier la dépendance de route ou de nettoyage; puis indiquer si le trafic est rerouté automatiquement ou manuellement; ensuite fournir des conseils pour l'escalade client; enfin publier une note post-incident expliquant ce qui a changé. Cette progression réduit les dommages secondaires.

L'incident Prolexic est un cas où le statut du fournisseur et les procédures du client se croisent. Si le service protégé d'un client est en panne, il doit décider s'il doit attendre le reroutage du fournisseur ou activer son propre repli. Le fournisseur a la meilleure vue de la panne côté service. Le client a la meilleure vue de la priorité métier et de l'impact local de l'application. Un bon avis de statut permet à ces vues de se rencontrer rapidement.

La communication devrait également éviter les affirmations trop larges. Akamai a déclaré que l'incident n'était pas une mise à jour système ou une cyberattaque. Ce fait importait car les clients pouvaient se concentrer sur la récupération opérationnelle du routage plutôt que sur la réponse à une compromission. Mais les clients avaient encore besoin de savoir si leurs propres services étaient affectés, si du trafic d'attaque était présent et si l'intégrité ou la confidentialité des données était en jeu. Les incidents de disponibilité devraient être délimités avec précision afin que les clients ne fassent ni trop peu ni trop.

Pour les services publics critiques, l'avis de statut a une fonction sociale. Les banques, les portails gouvernementaux, les interfaces de santé et les services de communication peuvent avoir besoin de notifier leurs propres utilisateurs. Si l'explication du fournisseur de mitigation amont est spécifique et opportune, les organisations aval peuvent communiquer avec précision. Si elle est tardive ou vague, les avis aval deviennent vagues aussi. Le transfert de coûts voyage souvent à travers l'incertitude avant de voyager à travers l'argent.

Les services de nettoyage ont besoin de transparence sur les domaines de défaillance

Le nettoyage DDoS est intentionnellement abstrait. Les clients ne veulent pas gérer chaque signature d'attaque, pool de capacité mondial, relation de peering, tunnel ou règle de mitigation. Ils achètent un service auprès d'un fournisseur parce que celui-ci peut opérer des défenses spécialisées à grande échelle. Mais l'abstraction ne devrait pas cacher les domaines de défaillance qui affectent la continuité. Les clients doivent comprendre quelle partie du chemin du fournisseur peut échouer et comment ils peuvent réagir.

La documentation produit peut décrire cela en termes contrôlés. Elle peut expliquer le routage toujours actif ou à la demande, les responsabilités d'annonce BGP, les chemins de retour de tunnel, les options de connexion directe, l'échelle de routage maximale, la dépendance à l'hygiène des préfixes clients, les procédures de contournement d'urgence et les contacts de support. Elle peut expliquer ce qui change si le trafic est automatiquement rerouté vers le centre de nettoyage le plus proche. Elle peut décrire les actions du client qui sont dangereuses pendant une attaque active.

Aucune de ces informations ne nécessite de révéler des méthodes de mitigation sensibles.

La transparence sur les domaines de défaillance est particulièrement importante lorsque la sécurité et la disponibilité sont en équilibre. Un client peut choisir un chemin protégé strict qui maximise la résilience DDoS mais augmente la dépendance au fournisseur. Un autre client peut accepter plus d'exposition de l'origine en échange d'un contournement plus rapide. Ce sont des décisions commerciales. Elles devraient être informées par des preuves du fournisseur, pas découvertes pendant une panne.

L'incident de 2021 devrait donc être utilisé comme une leçon d'achat. Les acheteurs de mitigation DDoS routée devraient demander: Que se passe-t-il si le service de nettoyage lui-même a un défaut de routage? Le reroutage automatique est-il activé pour chaque préfixe protégé? Comment le contournement est-il autorisé? À quelle fréquence est-il testé? Le client peut-il voir l'état des routes? Quels détails de statut seront fournis? À quelle vitesse le trafic peut-il revenir à une protection normale? Quels engagements contractuels s'appliquent lorsque le chemin de protection est le chemin de panne?

Les fournisseurs devraient accueillir ces questions s'ils ont des contrôles solides. Ils transforment un incident douloureux en une conception client plus claire. Ils réduisent également la charge de réponse lors du prochain événement car les clients avec des plans de contournement testés appellent avec de meilleures informations et prennent des décisions plus sûres.

Inconnues résiduelles et question de responsabilité

Le dossier public ne révèle pas tous les détails de la valeur de table de routage qu'Akamai a identifiée. Il ne fournit pas une carte client par client des temps d'arrêt, du reroutage automatique, de l'intervention manuelle ou de la préparation au contournement. Il ne vérifie pas indépendamment que chaque client a ensuite bénéficié d'un reroutage automatique vers le centre de nettoyage le plus proche. Il ne montre pas toutes les répartitions contractuelles entre le client, le fournisseur et les réseaux amont. Ces inconnues doivent rester visibles.

Ce qui est connu est suffisant pour définir la responsabilité. Akamai exploitait le service Prolexic Routed 3.0. Le service utilisait des chemins de trafic routés pour protéger les clients des attaques DDoS. Akamai a déclaré qu'une valeur de table de routage avait été involontairement dépassée et que les clients affectés étaient routés automatiquement ou manuellement. Les mesures externes ont montré que l'impact client variait et que les plans de sauvegarde importaient. Les clients et les utilisateurs ont subi les conséquences d'une dépendance de protection devenue indisponible.

La question de responsabilité est de savoir si la mitigation routée est devenue plus sûre après l'incident. Akamai a-t-elle ajouté une validation pour empêcher les limites d'état de route de devenir des pannes clients? Le reroutage automatique a-t-il couvert tous les clients comme promis? La documentation de contournement client est-elle devenue plus claire? Les avis de statut ont-ils identifié les points de décision plus rapidement? Les procédures de retour de trafic se sont-elles améliorées? Les clients ont-ils reçu des preuves de test ou des conseils d'architecture?

Le service a-t-il réduit l'intervention manuelle dans des conditions de défaillance côté fournisseur?

La réponse devrait être jugée sur les preuves. Une déclaration du fournisseur indiquant que les services ont été restaurés n'est que le début. Un dossier de réparation post-incident, des procédures clients, des chemins de contournement testés et le comportement ultérieur du service sont la preuve. Parce que la mitigation DDoS est vendue comme une continuité sous pression hostile, la propre continuité de route du fournisseur doit être tenue à un niveau élevé.

La leçon finale n'est pas que la mitigation DDoS routée est mauvaise. C'est que la protection déléguée crée une dépendance déléguée. Les clients ont besoin du chemin de protection, mais ils ont aussi besoin d'une route sûre autour du chemin de protection lorsque le système de défense est dégradé. L'incident Prolexic d'Akamai a rendu visible cette exigence de conception. Le standard de responsabilité est de savoir si cette visibilité est devenue un contrôle client durable plutôt qu'un souvenir de panne d'un jour.

Les contrôles de capacité côté fournisseur doivent avoir un sens visible pour le client

L'expression « valeur de table de routage » d'Akamai est nécessairement compacte. Elle ne divulgue pas l'architecture interne et ne devrait pas être étirée au-delà de la déclaration de l'entreprise. Mais même une phrase compacte a des conséquences de gouvernance. Les clients doivent comprendre que l'état de route côté fournisseur peut devenir une limite visible pour le client. Si une valeur peut être dépassée d'une manière qui interrompt le service, alors la validation autour de cette valeur fait partie du modèle de résilience du client.

La question de réparation publique n'est pas le nom littéral de la valeur. C'est la classe de contrôle. La valeur était-elle surveillée? Y avait-il une alerte avant l'impact client? La limite était-elle testée sous des conditions de croissance et de défaillance? Y avait-il un garde-fou pour empêcher une programmation de route dangereuse? Y avait-il un repli lorsque la valeur était approchée? La condition pouvait-elle se reproduire dans un autre centre de nettoyage, région ou groupe de clients? Ces questions transforment une déclaration brève en une liste de contrôle pratique de responsabilité.

Les clients peuvent demander ces informations sans exiger une implémentation sensible. Un fournisseur peut dire que les seuils d'état de route sont surveillés, que les versions ou les changements de route sont testés par rapport aux limites, que le reroutage automatique couvre des scénarios définis, que les procédures couvrent les exceptions manuelles et que la notification client identifiera les points de décision. Il peut également fournir aux clients entreprises une assurance plus approfondie sous confidentialité appropriée. Le but n'est pas l'exposition publique du système. Le but est une assurance pertinente pour le client.

Les contrôles de capacité devraient également être testés par rapport à la forme des urgences DDoS. Le trafic d'attaque peut créer des changements brusques de route et de mitigation. Les clients peuvent activer la protection à la demande sous stress. Les fournisseurs peuvent déplacer le trafic entre les centres de nettoyage. Le même contrôle qui fonctionne pendant une fenêtre de maintenance calme peut se comporter différemment lors d'événements clients simultanés. Un service conçu pour le trafic hostile devrait valider l'état de route dans des conditions similaires à une attaque, pas seulement en opérations ordinaires.

L'incident Prolexic a montré qu'une limite interne d'un fournisseur de protection peut être ressentie par des utilisateurs finaux qui n'ont jamais entendu parler du service. Une personne essayant d'atteindre une banque ou un portail public voit le site comme inaccessible. Le client voit un incident fournisseur. Le fournisseur voit un problème d'état de routage interne. La responsabilité nécessite de traduire entre ces vues afin que la partie qui contrôle la limite prouve qu'elle a réduit le symptôme public.

Les clients devraient classer les services protégés par risque de contournement

Tous les services protégés ne devraient pas être contournés de la même manière. Un site marketing public, une API de paiement, une connexion bancaire en ligne, un portail de santé, un plan de contrôle SaaS et un service gouvernemental ont des expositions différentes si la protection DDoS est retirée. Un manuel de contournement qui traite tous les préfixes protégés de manière égale est trop grossier. Les clients devraient classer les services protégés par le risque de rester sur un chemin de mitigation défaillant et le risque de quitter la protection.

Pour les sites d'information à faible risque, le contournement peut être acceptable rapidement si l'origine peut absorber le trafic normal. Pour les systèmes de transaction à haut risque, le contournement peut nécessiter des limites de débit amont, des modifications d'accès à l'origine ou un filtrage régional du trafic. Pour les services déjà sous attaque, le contournement peut être dangereux à moins qu'un autre chemin de mitigation ne soit prêt. Pour les services réglementés, la décision peut nécessiter une approbation métier et un avis public. Cette classification devrait être faite avant la panne du fournisseur, pas au milieu de celle-ci.

Le fournisseur peut aider en fournissant un arbre de décision de contournement. L'arbre peut demander si le client est sous attaque active, si une mitigation alternative existe, si les modifications DNS ou BGP sont plus rapides, si la capacité de l'origine est suffisante, si les règles de pare-feu permettent un accès direct et si le support peut aider au retour en sécurité. Ces conseils ne remplacent pas l'ingénierie client. Ils rendent l'ingénierie client possible sous pression temporelle.

Les clients devraient également tester le retour à la protection. Il est courant de tester le basculement et d'oublier le retour. Après la résolution d'un incident fournisseur, le trafic doit revenir au service de nettoyage sans casser les sessions, perdre la stabilité de la route, exposer les origines ou réintroduire du trafic d'attaque. Si le retour n'est pas répété, les organisations peuvent retarder la restauration de la protection ou créer une seconde panne. Un manuel complet couvre le contournement et le retour comme un seul cycle de vie.

Le dossier Prolexic est donc utile même pour les clients qui n'ont pas été affectés. Toute organisation utilisant une mitigation DDoS routée peut demander si sa classification de contournement est à jour. Elle peut réaliser un exercice sur table: Akamai ou un autre fournisseur signale un défaut de mitigation routée; le reroutage automatique fonctionne pour certains préfixes mais pas tous; les utilisateurs publics échouent; aucune attaque n'est visible; que faisons-nous dans les quinze premières minutes? La réponse révélera si la dépendance à la protection est gouvernée.

La mitigation multi-fournisseurs peut réduire le risque et ajouter de la complexité

Certains clients répondent à un incident de mitigation routée en envisageant plusieurs fournisseurs DDoS. Cela peut réduire la dépendance à un seul fournisseur, mais peut aussi introduire une complexité de politique de routage. Plusieurs fournisseurs peuvent nécessiter des annonces de préfixes, des tunnels, des stratégies DNS, des restrictions d'origine, des contrôles de santé, des contrats et des contacts de support différents. Un plan multi-fournisseur mal conçu peut créer la même confusion qu'il est censé résoudre.

La bonne question n'est pas simplement « Combien de fournisseurs? » C'est « Quels domaines de défaillance sont séparés? » Si deux fournisseurs dépendent du même chemin amont, du même contrôle DNS, du même goulot d'étranglement d'origine ou du même processus d'approbation interne, le gain de résilience pratique peut être plus faible que ne le suggère le nombre de fournisseurs. Si le client ne peut pas opérer le second fournisseur sous stress, le second fournisseur peut devenir une documentation plutôt qu'une continuité.

La diversification des fournisseurs change également la gestion des attaques. Un événement DDoS est adversarial. Changer de fournisseur de mitigation pendant une attaque peut exposer les adresses d'origine, réinitialiser le contexte de filtrage ou nécessiter une traduction de règles. Le client doit savoir quel fournisseur a l'autorité, comment le trafic se déplace, qui coordonne avec les amonts et comment la télémétrie est comparée. Ces détails sont trop importants pour être improvisés.

Néanmoins, la diversification peut aider si elle est conçue et testée. Un client peut maintenir un chemin de nettoyage secondaire, un repli basé sur le cloud pour le trafic moins sensible, ou une stratégie DNS d'urgence. Il peut diviser les services par criticité et attribuer différents modèles de mitigation. Il peut contracter une assistance fournisseur pendant le contournement. La leçon de l'incident d'Akamai n'est pas que chaque client a besoin de deux fournisseurs complets. C'est que chaque client a besoin d'une stratégie de domaine de défaillance choisie consciemment.

Les fournisseurs peuvent soutenir cette stratégie en étant transparents sur la manière dont leur service routé échoue, comment les clients peuvent partir et revenir, et quels composants appartenant au client sont des prérequis. Lorsqu'un fournisseur résiste à toute discussion sur le contournement, il demande aux clients de faire confiance à un chemin unique de manière absolue. L'événement Prolexic a montré pourquoi la confiance absolue en un seul chemin de protection n'est pas un plan de résilience.

Le contrat de protection devrait inclure la coopération en cas de panne

Les contrats de mitigation DDoS se concentrent souvent sur la capacité d'attaque, le temps de réponse, la disponibilité du service, le support et le prix. L'incident Prolexic suggère des questions supplémentaires. Le contrat définit-il les responsabilités du fournisseur lorsque la route de mitigation est dégradée? Exige-t-il un reroutage automatique lorsque disponible? Précise-t-il comment le reroutage manuel est priorisé? Identifie-t-il les obligations du client concernant les données de préfixes, la configuration des tunnels, les contacts d'urgence et l'approbation de contournement? Inclut-il des preuves post-incident?

Les termes contractuels ne peuvent pas résoudre tous les problèmes opérationnels, mais ils peuvent forcer la préparation. Si le contrat exige des contacts d'urgence à jour, les deux parties ont une raison de les maintenir. S'il exige des tests de basculement périodiques, le contournement est moins susceptible d'être théorique. S'il exige des mises à jour de statut avec des informations actionnables, les clients peuvent planifier la communication aval. S'il exige une revue post-incident, les engagements de réparation sont plus difficiles à oublier.

Le contrat devrait également aborder les données et la télémétrie. Pendant une panne de mitigation routée, les clients ont besoin de journaux ou de rapports montrant quand le trafic a échoué, quand il a été rerouté, quelles régions ou préfixes ont été affectés et quand la protection normale a repris. Sans ces preuves, les clients ne peuvent pas expliquer l'événement à leurs propres utilisateurs, auditeurs ou régulateurs. La télémétrie du fournisseur fait partie de la responsabilité du client.

Pour les services essentiels tournés vers le public, la coopération contractuelle devrait inclure la communication publique. Une banque, une agence gouvernementale ou un service de santé peut avoir besoin d'informer ses utilisateurs qu'un fournisseur de mitigation amont est dégradé. Le libellé du fournisseur peut aider à prévenir la désinformation. Il peut également confirmer que l'événement est un problème de disponibilité et de routage plutôt qu'une compromission de données là où cela est soutenu. Un langage clair du fournisseur réduit la charge du client.

La leçon générale est que la mitigation déléguée est une relation, pas une boîte noire. Le fournisseur contrôle des défenses spécialisées. Le client possède la mission du service. Pendant une défaillance côté fournisseur, ces responsabilités se rencontrent. De bons contrats, procédures, avis de statut et tests rendent cette rencontre prévisible. Sans eux, une valeur de table de routage dans un environnement fournisseur peut devenir une panne publique avec des droits de décision flous.

Les preuves de chemin de retour devraient faire partie de l'assurance de mitigation

La mitigation routée a deux faces publiques: le chemin vers le service de nettoyage et le chemin de retour vers le client. Les acheteurs se concentrent souvent sur le premier car il est plus facile à comprendre. Le trafic d'attaque entre dans le réseau défensif du fournisseur, le fournisseur le filtre, et le trafic propre atteint l'origine. Le côté retour peut être tout aussi important. Les tunnels, les connexions directes, les préférences de route, les règles de pare-feu et les restrictions d'origine déterminent tous si les utilisateurs protégés reçoivent réellement le service.

L'incident Prolexic fait des preuves de chemin de retour une partie de l'assurance. Si un fournisseur reroute le trafic automatiquement ou manuellement, les clients doivent savoir si les chemins de retour sont valides, si les tunnels sont sains, si les listes d'autorisation d'origine correspondent toujours et si le retour préservera la protection. Un service routé peut être techniquement restauré au niveau du fournisseur alors qu'un client a toujours une inadéquation côté origine. Cette inadéquation peut ressembler à une panne continue du fournisseur, à une mauvaise configuration client ou à un problème de récupération partielle.

Les clients devraient donc demander des cas de test de route et de chemin de retour lors de l'intégration. Le premier test devrait prouver le fonctionnement protégé ordinaire. Le second devrait prouver le reroutage côté fournisseur. Le troisième devrait prouver le contournement autorisé par le client. Le quatrième devrait prouver le retour sûr à la protection. Le cinquième devrait prouver la communication: qui reçoit les alertes, ce qu'elles disent et quelle action est attendue. Un plan qui n'a jamais déplacé de trafic dans un exercice contrôlé n'est pas un plan de contournement fiable.

La déclaration d'Akamai selon laquelle le trafic était routé automatiquement ou manuellement fournit un point de départ utile, mais les clients ont besoin de preuves locales. Leurs préfixes protégés ont-ils participé au reroutage automatique? Leur application a-t-elle nécessité un support manuel? Les journaux montrent-ils quand les changements de route ont eu lieu? Les utilisateurs ont-ils récupéré lorsque le statut du fournisseur indiquait restauré? Le client a-t-il dû modifier les contrôles d'origine? Ces questions rendent l'incident fournisseur actionnable sans spéculer au-delà du dossier public.

L'assurance du chemin de retour est également importante pour les petites organisations. Une grande entreprise peut avoir des équipes réseau capables d'inspecter BGP, GRE et l'état du pare-feu. Un client plus petit peut seulement savoir que le site est en panne. Les tableaux de bord du fournisseur, le langage simple et les procédures de l'équipe de compte peuvent combler cet écart. Si le fournisseur vend une mitigation avancée à des organisations sans personnel réseau avancé, le fournisseur devrait rendre les états de récupération compréhensibles.

Le standard de responsabilité est la preuve que la protection peut être quittée et réintégrée en toute sécurité. La mitigation DDoS est inhabituelle car les décisions de défaillance ont des conséquences de sécurité dans les deux sens. Rester sur un chemin défaillant peut refuser le service. Quitter le chemin peut exposer l'origine. Revenir trop rapidement ou sans validation peut réintroduire un risque. C'est pourquoi l'assurance de mitigation routée devrait inclure la preuve de l'entrée du trafic, du retour du trafic, du contournement et du retour comme une famille de contrôles.

La communication client devrait distinguer la panne de l'attaque

Un client de protection DDoS peut raisonnablement supposer que tout problème de disponibilité près du service de mitigation est une attaque. La mise à jour d'Akamai a déclaré que l'incident Prolexic Routé n'était pas causé par une cyberattaque. Cette distinction est opérationnellement précieuse. Si un client croit qu'une panne est due à une attaque, il peut éviter le contournement, renforcer les contrôles, activer des communications de crise ou escalader vers la direction de la sécurité. Si le fournisseur peut confirmer un problème de service de routage interne, le chemin de décision du client change.

Le fournisseur devrait faire cette distinction rapidement lorsque les preuves le soutiennent. « Nous enquêtons » est approprié au début. Une fois connu, « il s'agit d'un problème de routage de service, pas d'un trafic d'attaque observé contre votre origine » ou « le statut d'attaque reste en cours d'examen » donne aux clients une meilleure base pour agir. La communication devrait également indiquer si le client doit s'abstenir de changements de route, préparer un contournement ou contacter le support pour un reroutage manuel.

C'est là que l'avis de statut devient un document de contrôle partagé. Le fournisseur connaît l'état du service. Le client connaît la criticité métier. Les deux ont besoin d'un langage commun. Si l'avis du fournisseur est trop technique, les équipes métier peuvent ne pas agir. S'il est trop vague, les équipes réseau peuvent deviner. Un bon avis identifie le produit affecté, les symptômes clients, la catégorie de cause connue, l'action recommandée et l'heure de la prochaine mise à jour.

Les utilisateurs aval bénéficient de cette clarté. Une banque, une entreprise SaaS ou une agence publique peut dire à ses utilisateurs qu'un fournisseur de mitigation DDoS amont rencontre un problème de disponibilité plutôt que d'impliquer une brèche ou un défaut d'application. Une formulation précise réduit les rumeurs, la charge de support et la panique de sécurité inutile. Cela aide également le fournisseur à éviter d'être blâmé pour des préjudices non soutenus par les preuves tout en possédant la dépendance de service qu'il contrôle.