Dyn a transformé la dépendance au DNS en un problème de responsabilité pour la continuité des revenus

Résumé

• L'incident Dyn n'était pas une panne applicative classique. De nombreux services en ligne touchés disposaient encore de serveurs, de personnel et de logiciels opérationnels, mais les utilisateurs ne pouvaient pas les atteindre de manière fiable car les attaquants ciblaient la couche DNS faisant autorité, qui indique à Internet où ces services se trouvent.
• Dyn contrôlait son infrastructure DNS faisant autorité, sa réponse aux DDoS, sa communication de statut et son assistance client. Les clients contrôlaient la concentration des fournisseurs, le DNS secondaire, les choix de TTL, la préparation du registraire, la surveillance et les hypothèses de continuité d'activité. Les fabricants d'appareils IoT et les réseaux d'accès contrôlaient une partie du risque de botnet qui a rendu l'attaque à grande échelle possible.
• La question de responsabilité est la continuité des revenus. Un détaillant, un site de médias, un fournisseur SaaS ou un service public peuvent perdre des commandes, de la publicité, des canaux de support et la confiance des utilisateurs même lorsque l'application d'origine est saine, si la résolution de noms dépend trop fortement d'un seul fournisseur attaqué.
• La réparation durable est la preuve que le DNS est conçu comme une dépendance critique: autorité multi-fournisseurs, transfert de zone ou automatisation testés, surveillance indépendante, changements de registraire exercés, TTL réalistes, capacité DDoS, notification de statut et sensibilisation au niveau du conseil d'administration que l'accessibilité fait partie du contrôle des revenus.

Une panne DNS peut rendre un service sain inaccessible

Le DNS est souvent invisible jusqu'à ce qu'il échoue. Les utilisateurs se souviennent de la marque qu'ils ont essayé d'atteindre, pas de la chaîne de services de noms faisant autorité derrière. Le 21 octobre 2016, de grandes parties d'Internet ont connu des problèmes d'accessibilité intermittents parce que Dyn, alors un important fournisseur de DNS géré, a été frappé par des attaques par déni de service distribué soutenues. Lerésumé de l'analyse de l'attaque par Dyna décrit plusieurs vagues d'attaque et un grand nombre d'adresses sources malveillantes associées au botnet Mirai. Ladéclaration publique antérieure de Dyna présenté l'événement comme une attaque contre l'infrastructure DNS gérée plutôt qu'une compromission des applications des clients.

La différence est importante. Si les serveurs web d'un service tombent en panne, le propriétaire du service peut se concentrer sur la récupération applicative. Si la résolution DNS échoue, l'utilisateur peut ne jamais atteindre les serveurs pour apprendre qu'ils sont sains. Le DNS géré se trouve en amont des revenus, du support, de la communication publique, de l'authentification et de la diffusion de contenu. Il ne traite pas chaque transaction, mais il décide si de nombreuses transactions peuvent commencer. Cela fait du DNS une dépendance de continuité des revenus, et pas simplement un carnet d'adresses technique.

L'attaque de 2016 a également rendu visible le problème de concentration. De nombreux services de premier plan utilisaient Dyn pour le DNS. Lorsque Dyn a été attaqué, ces clients partageaient un domaine de défaillance. Certains avaient un DNS secondaire ou d'autres mesures d'atténuation. D'autres dépendaient plus lourdement de la disponibilité de Dyn. L'expérience de l'utilisateur variait selon la géographie, le cache du résolveur, le moment et la configuration du client.

Le public a vu une seule perturbation d'Internet; la carte de responsabilité réelle incluait l'infrastructure de Dyn, l'architecture DNS des clients, les contrôles de registraire, les résolveurs récursifs, les réseaux de transit et les appareils non sécurisés de l'Internet des Objets qui alimentaient le botnet.

L'équipe de préparation aux urgences informatiques des États-Unis (US-CERT) avait déjà averti sur les menaces de type Mirai dans sonalerte d'octobre 2016 sur le risque accru de DDoS posé par Mirai et d'autres botnets. L'avertissement est venu avant l'événement Dyn et décrivait des appareils IoT compromis utilisés dans des attaques DDoS. Ce timing est important. L'attaque Dyn n'a pas créé le problème de botnet IoT; elle a montré comment l'échelle d'un botnet pouvait transformer un fournisseur DNS partagé en un point d'étranglement de l'accessibilité publique.

Le contrôle de Dyn était réel mais pas total

Dyn avait un contrôle direct sur son infrastructure DNS gérée et sa réponse. Elle exploitait le service que les clients achetaient, maintenait les défenses DDoS, coordonnait avec les fournisseurs en amont, informait les clients et rétablissait le service. Les clients pouvaient raisonnablement s'attendre à ce que Dyn défende sa plateforme contre de grandes attaques. En même temps, même les défenses d'un fournisseur majeur peuvent être submergées ou dégradées par un trafic distribué provenant de nombreux réseaux. La question de responsabilité n'est pas de savoir si Dyn aurait dû être invulnérable.

Il s'agit de savoir si Dyn, les clients et l'écosystème plus large ont réduit le rayon de l'explosion qu'un fournisseur attaqué pourrait créer.

Les clients contrôlaient un ensemble différent de faits. Ils choisissaient d'utiliser un DNS faisant autorité à fournisseur unique ou des dispositions multi-fournisseurs. Ils définissaient des TTL qui affectaient le comportement de mise en cache et de basculement. Ils géraient l'accès au registraire et les procédures de gestion de zone. Ils surveillaient le DNS indépendamment de l'état de l'application. Ils pratiquaient ou non le changement d'autorité sous pression. Ils décidaient si la résilience DNS était un problème de revenus au niveau du conseil d'administration ou un détail technique laissé aux équipes d'infrastructure.

Ces choix déterminaient si la panne de Dyn devenait une courte dégradation, une interruption majeure des revenus ou un événement de confiance publique.

Il n'y a pas de réponse universelle car la conception DNS implique des compromis. Un DNS multi-fournisseurs peut améliorer la résilience, mais il ajoute une complexité opérationnelle. Les changements de zone doivent être synchronisés. DNSSEC, les vérifications d'état, le géoroutage, l'orientation du trafic et les fonctionnalités spécifiques au fournisseur peuvent rendre le basculement plus difficile. Des TTL faibles peuvent aider les changements à se propager mais augmentent la charge de requêtes et ne remplacent pas tous les caches.

Les changements de registraire peuvent être lents ou risqués si les identifiants, les verrous ou les approbations ne sont pas prêts. Une architecture responsable reconnaît ces compromis et les teste plutôt que de supposer que "DNS secondaire" est une phrase magique.

L'écosystème plus large avait également le contrôle. Les fabricants d'appareils IoT expédiaient des appareils avec des identifiants par défaut faibles, de mauvaises pratiques de mise à jour et peu de responsabilité pour les externalités d'abus. Les réseaux d'accès pouvaient détecter et limiter une partie du trafic des appareils compromis. Les consommateurs et les petites entreprises avaient souvent peu de capacité pratique à sécuriser les DVR, les caméras et les routeurs. Les forces de l'ordre ont plus tard lié Mirai à des accusés nommés; l'annonce de plaidoyer de culpabilité de 2017 du ministère de la Justicea décrit la création et l'exploitation de Mirai et des botnets de fraude aux clics. Ce dossier juridique est important car il montre la responsabilité malveillante, mais il n'élimine pas les devoirs des fournisseurs et des clients en matière de résilience de l'accessibilité.

La continuité des revenus commence par l'accessibilité

La continuité des revenus est souvent envisagée autour du traitement des paiements, des stocks, du paiement, du support et de la livraison. Le DNS appartient à la même liste. Si les clients ne peuvent pas résoudre le domaine, les pages de vente, les pages de connexion, les API, les portails de support, l'inventaire publicitaire et les pages de statut peuvent tous devenir inaccessibles. Les serveurs d'origine peuvent rester sains tandis que les revenus s'arrêtent à la porte d'entrée. Pour les sociétés de médias, l'accessibilité affecte la publicité et l'audience. Pour les détaillants, elle affecte la conversion.

Pour les fournisseurs SaaS, elle affecte les engagements de disponibilité. Pour les services publics, elle affecte l'accès à l'information et la communication de crise.

L'incident Dyn a montré que la concentration DNS peut convertir le risque du fournisseur en perte de revenus pour le client. Les clients n'avaient pas besoin d'être la cible de DDoS pour être lésés. Ils ont été lésés parce qu'ils dépendaient du fournisseur attaqué. C'est un transfert de coûts: les attaquants ont ciblé Dyn, Dyn a absorbé l'attaque, les clients ont absorbé les pertes d'accessibilité, les utilisateurs ont subi un accès rompu, et les propriétaires ou fabricants d'appareils IoT dont les appareils ont rejoint le botnet ont rarement supporté des coûts équivalents.

La responsabilité exige de voir ce transfert plutôt que de rejeter toute la faute sur la dernière marque visible.

La surveillance doit correspondre à la dépendance. Un contrôle synthétique d'application depuis une seule région peut dire que le site web est en panne, mais il peut ne pas distinguer la défaillance d'origine de la défaillance DNS faisant autorité, de la mise en cache des résolveurs récursifs, de l'accessibilité BGP, du routage CDN ou des problèmes de FAI local. Une organisation mature surveille la réponse DNS faisant autorité depuis plusieurs réseaux, vérifie si les serveurs de noms répondent, observe la validité DNSSEC si utilisée, et sépare la santé de l'application de la santé de la résolution de noms.

Pendant l'attaque Dyn, cette distinction a façonné la réponse. Un client dont l'application était saine avait besoin d'une action DNS et du fournisseur, pas d'un retour en arrière applicatif.

L'enregistrement des revenus devrait également inclure le statut face aux clients. La page de statut principale d'un service peut dépendre du même fournisseur DNS que le service affecté. Si c'est le cas, les utilisateurs peuvent ne pas être en mesure d'atteindre l'explication. Des domaines de statut indépendants, des canaux de communication alternatifs et des avis de service mis en cache peuvent avoir de l'importance. L'incident a rendu visible une question de conception fondamentale: si le fournisseur de services de noms est la défaillance, l'entreprise peut-elle encore dire aux clients ce qui se passe?

Le DNS secondaire est une discipline, pas une case à cocher

La réponse courante après l'attaque Dyn était « utilisez un DNS secondaire ». C'est directionnellement juste et opérationnellement incomplet. Le DNS secondaire nécessite une conception fonctionnelle. Les zones doivent être synchronisées. Les différences entre fournisseurs doivent être comprises. Le comportement des vérifications d'état ne doit pas entrer en conflit. La signature DNSSEC doit être gérée avec soin. La délégation du registraire doit inclure des serveurs de noms indépendants.

Les intervenants en cas d'incident doivent savoir quel fournisseur fait autorité pour quelles zones, quelle automatisation met à jour les enregistrements, et comment éviter de casser la production pendant une urgence.

Ladocumentation BIND sur les transferts de zonede l'Internet Systems Consortium et laRFC 1996 de l'IETF sur DNS NOTIFYillustrent que le DNS multi-serveurs dispose de mécanismes de longue date pour distribuer les changements de zone. Le DNS géré moderne ajoute des API, de la gestion de trafic et des fonctionnalités spécifiques au fournisseur, mais le problème central reste la synchronisation et l'autorité. Une entreprise ne peut pas supposer que l'ajout d'un deuxième fournisseur sans un processus de mise à jour testé fonctionnera pendant une panne.

La stratégie TTL est une autre discipline. Un TTL faible peut faire propager les changements d'enregistrement plus rapidement dans des conditions ordinaires, mais il augmente la charge et ne garantit pas un changement instantané car les caches et les clients se comportent différemment. Un TTL élevé peut protéger les utilisateurs avec des réponses mises en cache pendant une panne de fournisseur, mais il ralentit le basculement délibéré. La bonne réponse dépend du type de service, du modèle de trafic, de la conception du fournisseur et du modèle d'incident.

La responsabilité signifie que l'organisation a fait et testé un choix délibéré plutôt que d'hériter d'une valeur par défaut.

La préparation du registraire est souvent la partie négligée. Si une organisation a besoin de changer les serveurs de noms faisant autorité sous pression, elle doit avoir accès au registraire, une approbation multi-personnes, une protection des identifiants, et une compréhension des verrous de registre ou des délais de changement. Une configuration DNS secondaire parfaite ne sert à rien si l'organisation ne peut pas mettre à jour la délégation en toute sécurité.

À l'inverse, un changement de registraire précipité peut créer une nouvelle panne si les serveurs de noms sont mal saisis, les enregistrements DS de DNSSEC sont erronés ou les approbations bloquent. Un plan de continuité des revenus devrait exercer tout le chemin, pas seulement la console du fournisseur.

La capacité DDoS est un problème d'écosystème

Le botnet Mirai a montré que le risque DDoS est créé loin de la victime. Des caméras, des DVR, des routeurs et d'autres appareils ont été recrutés dans le trafic d'attaque parce qu'ils étaient mal sécurisés et largement déployés. L'analyse de KrebsOnSecurity de 2016 sur la panne Dyna lié la perturbation publique aux appareils grand public compromis, et l'analyse rétrospective ultérieure de Cloudflare sur Miraia expliqué pourquoi les identifiants par défaut et l'exposition des appareils comptaient. Ces sources ne remplacent pas le propre récit de Dyn, mais elles aident à expliquer pourquoi l'échelle de l'attaque était un problème d'infrastructure partagé.

Cela compte pour la responsabilité parce que les incitations économiques sont mal alignées. Un fabricant d'appareils à bas coût peut économiser de l'argent grâce à une sécurité faible. Le propriétaire peut ne pas remarquer la compromission parce que l'appareil continue de fonctionner. Le fournisseur d'accès peut voir le trafic mais ne possède pas l'appareil. Le fournisseur DNS et ses clients absorbent les coûts de l'attaque. Le public perd le service. C'est un problème classique d'incitation à la prévention: les parties les mieux placées pour empêcher le recrutement de botnets peuvent ne pas subir la plus grande perte visible.

Les gouvernements et les organismes de normalisation ont réagi au fil du temps avec des orientations de sécurité IoT. LeNISTIR 8259 du NIST sur les activités de cybersécurité fondamentales pour les fabricants d'appareils IoTet lescritères ultérieurs de cybersécurité IoT grand public du NISTexpriment des bases de sécurité des appareils qui auraient réduit l'exposition de type Mirai s'ils avaient été largement mis en œuvre plus tôt. Leprogramme d'étiquetage de cybersécurité pour les appareils intelligents de la FCCreflète la même orientation politique: rendre les pratiques d'appareils non sécurisées plus visibles pour les acheteurs. Ces mesures ne résolvent pas la concentration des fournisseurs DNS, mais elles traitent la source de trafic qui peut faire échouer les défenses des fournisseurs.

Les pratiques des opérateurs de réseau comptent aussi. Des conseils anti-usurpation tels queBCP 38, RFC 2827et la mise à jourBCP 84, RFC 8704traitent de la validation des adresses source, un contrôle qui aide à réduire certaines classes de trafic abusif. Mirai ne dépendait pas seulement de l'usurpation, mais la leçon plus large est que la résilience DDoS est une discipline d'écosystème. Les fournisseurs DNS peuvent acheter de la capacité et construire des centres de nettoyage, mais les réseaux d'accès, les fabricants d'appareils, les fournisseurs cloud et les clients influencent tous l'échelle et l'impact des attaques.

La continuité des services publics ajoute un autre devoir

La clientèle de Dyn incluait des plateformes commerciales et des services que de nombreux utilisateurs considéraient comme faisant partie de la vie quotidienne. Même lorsque le client direct était une entreprise privée, l'accessibilité des services en ligne affectait la communication, les médias, le paiement, le travail et la sensibilisation du public. Une panne DNS peut donc devenir un problème de continuité de service public sans être une panne de système gouvernemental. Lorsqu'un fournisseur partagé soutient de nombreux services largement utilisés, sa résilience devient une partie de l'infrastructure civique.

C'est l'une des raisons pour lesquelles la gouvernance du DNS est importante. La délégation DNS faisant autorité est un point de contrôle dans l'Internet public. Les registres, les bureaux d'enregistrement, les fournisseurs faisant autorité, les résolveurs récursifs, les fournisseurs CDN et les opérateurs de réseau façonnent tous si les utilisateurs peuvent atteindre les services. L'incident Dyn n'était pas une défaillance du protocole DNS, mais il a exposé la conséquence d'une dépendance opérationnelle concentrée à l'intérieur de ce système de gouvernance.

Quelques fournisseurs peuvent devenir très conséquents parce que de nombreux clients leur externalisent la complexité.

Les organisations du secteur public devraient tirer les leçons de ce même événement. Une agence gouvernementale, un organisme de santé, un système judiciaire, un bureau électoral ou un service d'urgence qui dépend d'un seul fournisseur DNS devrait se demander si les citoyens peuvent atteindre les informations critiques pendant une attaque contre le fournisseur. Il devrait tester des canaux de statut indépendants, le DNS multi-fournisseurs, les procédures de registraire, le renouvellement DNSSEC et la communication d'urgence.

Le service public ne peut pas supposer que la résilience du fournisseur privé répond automatiquement aux obligations publiques.

La norme d'intérêt public n'est pas que chaque organisation doit exploiter son propre réseau DNS mondial. Les fournisseurs gérés existent pour de bonnes raisons: expertise, échelle, sécurité, automatisation et support. La norme est que les clients à forte dépendance comprennent le domaine de défaillance qu'ils ont acheté. Un fournisseur peut être excellent et rester un point unique de dépendance si le client n'a pas d'alternative testée. Externaliser l'exploitation n'externalise pas la responsabilité de l'accessibilité publique.

La qualité de la communication compte quand le carnet d'adresses se brise

Pendant les pannes DNS, la communication est inhabituellement difficile car les voies de communication normales du service peuvent dépendre de la même chaîne de noms. Une page de statut sous le domaine affecté peut être inaccessible. Le courriel peut être retardé ou méfié. Les médias sociaux peuvent devenir le canal pratique, mais tous les clients ne suivent pas le compte. Les entreprises qui vendent des services en ligne critiques ont besoin d'un plan de communication qui survive à la défaillance du fournisseur DNS.

Ce plan devrait inclure une infrastructure de statut indépendante, des domaines alternatifs, des canaux sociaux préétablis, des listes de contacts clients et des procédures de support. Il devrait également distinguer les messages du client des messages du fournisseur. Dyn pouvait signaler l'état de l'attaque pour sa plateforme. Chaque client devait encore dire à ses propres utilisateurs si le service du client était affecté, si les données étaient en sécurité, si des transactions étaient perdues, et quand le service normal était attendu.

Le statut du fournisseur est nécessaire mais pas suffisant car l'utilisateur a une relation avec la marque, pas avec le fournisseur DNS invisible.

La qualité de la communication affecte également la récupération des revenus. Si un détaillant ne dit rien aux utilisateurs, certains peuvent supposer que l'application de la marque a échoué et partir définitivement. Si un fournisseur SaaS ne peut pas expliquer que la résolution DNS est affectée alors que les données restent en sécurité, les clients peuvent s'inquiéter d'une violation ou d'une perte de données. Si un service public ne peut pas dire aux citoyens comment trouver des informations alternatives, la confiance s'érode. Une mise à jour technique de statut devient une partie de la preuve de fidélisation de la clientèle.

L'attaque Dyn a montré pourquoi la communication d'incident devrait nommer la dépendance sans surcharger les utilisateurs. Un avis clair peut dire que le service connaît des problèmes d'accessibilité en raison d'une attaque contre le fournisseur DNS, que les données des utilisateurs et les systèmes d'origine ne sont pas connus pour être compromis, que des canaux alternatifs sont disponibles, et que les mises à jour apparaîtront à un endroit spécifique. Ce message réduit l'incertitude. Il préserve également un enregistrement de ce que l'entreprise savait à ce moment-là.

La leçon au niveau du conseil n'est pas « achetez plus de DNS »

La leçon au niveau du conseil est de traiter l'accessibilité publique comme un actif commercial. Le DNS, BGP, CDN, la défense DDoS, les certificats TLS, le contrôle du registraire et les communications de statut se trouvent tous en amont des revenus. Ils peuvent être détenus par des équipes techniques, mais leur défaillance crée un préjudice commercial et public. Les conseils n'ont pas besoin de connaître chaque type d'enregistrement. Ils ont besoin de savoir si l'organisation a des dépendances critiques sans alternative testée.

Un rapport utile au conseil après Dyn répondrait à six questions. Quels domaines sont critiques pour les revenus ou le service public? Quels fournisseurs contrôlent leur DNS faisant autorité? Quels domaines ont un DNS secondaire ou un basculement indépendant? Quand le basculement a-t-il été testé pour la dernière fois? Comment l'organisation communiquerait-elle si son domaine principal ne pouvait pas résoudre? Quels processus de revenus, de support ou de sécurité s'arrêteraient si le DNS était dégradé pendant une heure, six heures ou une journée?

Le même rapport devrait inclure les noms des propriétaires et les résultats des exercices. Une conception multi-fournisseurs que personne ne possède est risquée. Un plan de basculement qui n'a pas été testé contre les contraintes réelles du registraire et de DNSSEC est incertain. Une page de statut qui partage la même dépendance est fragile. Un outil de surveillance qui vérifie seulement la réponse de l'application manque la défaillance du service de noms.

La responsabilité au niveau du conseil n'est pas du théâtre technique; c'est un moyen de s'assurer que les personnes qui portent les devoirs financiers et publics voient clairement la dépendance.

L'assurance et les contrats changent également lorsque le DNS est traité de cette façon. Les questions d'assurance cyber devraient inclure la concentration du DNS faisant autorité et les tests de basculement. Les contrats d'entreprise devraient clarifier les dépendances de disponibilité et les avis aux clients lors d'attaques au niveau du fournisseur. La gestion des fournisseurs devrait considérer si un fournisseur DNS peut fournir des journaux, des résumés d'attaque, des données d'impact sur le client et une assistance post-incident. L'objectif n'est pas de punir un fournisseur pour avoir été attaqué.

C'est de faire en sorte que le client et le fournisseur partagent les preuves avant que les revenus ne soient en danger.

La réparation durable signifie réduire le domaine de défaillance partagé

Le bilan de réparation durable après Dyn n'est pas simplement une plus grande capacité DDoS. La capacité aide. L'anycast aide. Le nettoyage aide. La diversité des fournisseurs aide. L'architecture client aide. La sécurité des appareils IoT aide. Le filtrage réseau aide. La communication aide. La question importante est de savoir si le domaine de défaillance partagé a rétréci. Si de nombreux services critiques dépendent encore d'un seul fournisseur, d'un seul compte de registraire, d'un seul domaine de statut et d'une seule procédure d'urgence non testée, la leçon reste incomplète.

Pour Dyn et d'autres fournisseurs de DNS géré, les preuves de réparation devraient inclure la capacité DDoS, la coordination en amont, l'empreinte anycast, la visibilité de l'impact spécifique au client, la transparence du statut et le support pendant les vagues d'attaque. Pour les clients, elles devraient inclure un DNS secondaire testé, une surveillance indépendante, une préparation du registraire, une assurance des processus DNSSEC et une communication alternative. Pour les écosystèmes d'appareils et de réseaux, elles devraient inclure un recrutement réduit de botnets et un trafic abusif réduit.

Pour les utilisateurs du secteur public, elles devraient inclure des exercices de continuité qui supposent une défaillance du fournisseur DNS.

L'attaque rappelle également aux organisations de ne pas confondre redondance et indépendance. Deux serveurs de noms du même fournisseur peuvent fournir une redondance technique mais pas une indépendance vis-à-vis du fournisseur. Un deuxième fournisseur contrôlé par le même compte d'automatisation compromis peut ne pas fournir une indépendance opérationnelle. Une page de statut hébergée sous la même dépendance DNS peut ne pas fournir une indépendance de communication. L'indépendance doit être tracée à travers les fournisseurs, les comptes, les identifiants, les réseaux et les personnes.

L'incident Dyn reste un cas de responsabilité utile car il a exposé une dépendance silencieuse en pleine vue publique. L'Internet n'a pas disparu. Une fonction d'adressage partagée est devenue difficile à utiliser. Cela a suffi à rendre des services majeurs inaccessibles, à déplacer les coûts vers les clients et les utilisateurs, et à forcer les entreprises à se demander si elles avaient traité le DNS comme une infrastructure de revenus. La réponse pour la prochaine panne devrait être démontrable avant l'attaque, pas improvisée après que la première vague frappe.

Un véritable exercice DNS est plus dur qu'un diagramme de basculement

De nombreuses organisations peuvent dessiner une architecture DNS résiliente. Moins peuvent prouver qu'elle fonctionne un mauvais jour. Un véritable exercice devrait commencer par l'hypothèse que le fournisseur faisant autorité principal est dégradé par le trafic d'attaque, que la console du fournisseur est lente, que les résolveurs récursifs montrent un comportement inégal entre les régions, que la page de statut publique est partiellement affectée, et que les dirigeants d'entreprise demandent une prévision de revenus.

L'exercice devrait ensuite forcer l'équipe à décider de patienter, de changer d'autorité, d'utiliser un fournisseur secondaire, de changer les enregistrements, de modifier les TTL, ou de communiquer la dégradation sans aggraver le problème.

L'exercice devrait inclure les étapes du registraire. Qui peut se connecter? Les verrous de registre sont-ils activés? Les changements sont-ils protégés par une approbation multi-personnes? Les changements d'urgence peuvent-ils être effectués sans désactiver les contrôles de sécurité? Les enregistrements DS de DNSSEC sont-ils compris? Le guide de pratiques opérationnelles de DNSSEC dans laRFC 6781montre pourquoi les zones signées ajoutent des considérations opérationnelles; DNSSEC peut renforcer l'authenticité, mais des changements d'urgence négligents peuvent casser la validation. Une entreprise qui signe des zones devrait savoir comment le basculement interagit avec la signature, la gestion des clés et la délégation avant une panne.

L'exercice devrait inclure les différences de surveillance. Que rapporte le moniteur d'application? Que rapportent les moniteurs DNS faisant autorité? Que rapportent les tests de résolveur récursif de différentes régions? Qu'entend le support client? Que voit le CDN? Que rapportent les systèmes de publicité, de paiement, de connexion et d'API? Si ces signaux ne sont pas séparés, le commandant d'incident peut poursuivre la mauvaise défaillance. Le cas Dyn a montré que l'application peut être saine alors que les utilisateurs ne peuvent pas résoudre le nom.

Une surveillance qui fusionne ces signaux en une seule alarme « site hors service » ralentit la réponse.

L'exercice devrait inclure des choix commerciaux. Déplacer l'autorité DNS peut rétablir certains utilisateurs mais créer un risque pour d'autres si les zones sont obsolètes ou si les fonctionnalités du fournisseur diffèrent. Attendre peut éviter une erreur mais prolonger la perte de revenus. Communiquer par un canal alternatif peut aider les clients mais nécessite un langage préapprouvé. Un programme de résilience au niveau du conseil devrait définir qui peut faire ces compromis et de quelles preuves ils ont besoin. Les équipes techniques ne devraient pas être forcées d'improviser des décisions de risque commercial sous l'attaque.

Le résultat final devrait être mesurable. Combien de temps a-t-il fallu pour diagnostiquer la défaillance DNS faisant autorité? Combien de temps pour atteindre le fournisseur? Combien de temps pour vérifier l'état de préparation du fournisseur secondaire? Combien de temps pour mettre à jour la délégation si nécessaire? Combien de temps avant que l'avis au client apparaisse sur un canal indépendant? Combien de temps avant que les flux critiques pour les revenus soient accessibles depuis plusieurs régions? Ces horloges transforment la résilience DNS d'un discours d'architecture en continuité responsable.

Les contrats devraient exiger des preuves d'incident, pas seulement des chiffres de disponibilité

Les contrats de DNS géré mettent souvent l'accent sur les niveaux de service, les niveaux de support, le volume de requêtes, les fonctionnalités et le prix. Après Dyn, les clients à forte dépendance devraient également demander des devoirs de preuve. Si le fournisseur est attaqué, peut-il fournir une chronologie, les régions affectées, les caractéristiques de l'attaque, les étapes d'atténuation, l'impact spécifique au client si disponible, et les leçons post-incident? Peut-il soutenir un client utilisant un DNS secondaire? Peut-il coordonner avec le CDN, le registraire et l'équipe de réponse aux incidents du client?

Peut-il dire au client quelles informations peuvent être partagées publiquement en toute sécurité?

Le client doit également de la clarté au fournisseur. Quels domaines sont les plus critiques? Quels enregistrements sont automatisés par des systèmes de déploiement? Quelles fonctionnalités du fournisseur sont utilisées? Quels contacts peuvent approuver les changements d'urgence? Quelles obligations de service public ou réglementaires s'appliquent? Un fournisseur ne peut pas soutenir tous les clients de manière égale si la carte de criticité du client est inconnue. Un contrat devrait rendre explicites les domaines critiques et les contacts d'urgence.

Les accords de niveau de service sont utiles mais incomplets. Un crédit après une panne peut rembourser une petite fraction des frais alors que la perte de revenus du client est beaucoup plus grande. Le meilleur outil de prévention est la coopération opérationnelle avant la panne. Le client devrait examiner l'architecture avec le fournisseur, tester le basculement et définir des canaux de statut. Le fournisseur devrait expliquer des limites réalistes, pas simplement promettre une haute disponibilité.

Si un fournisseur ne peut pas partager suffisamment d'informations pour des raisons de sécurité, il devrait définir le niveau d'abstraction qu'il peut partager pendant la crise.

Les contrats devraient également traiter de la gestion des changements. De nombreuses pannes sont aggravées par des changements d'urgence effectués sous pression. Un client utilisant deux fournisseurs DNS doit savoir comment les changements de zone sont synchronisés, si un fournisseur est principal, comment les identifiants API sont protégés, comment les changements sont examinés et comment le retour en arrière fonctionne. Si l'automatisation met à jour les enregistrements DNS pour les déploiements, l'organisation doit savoir si cette automatisation peut écrire sur les deux fournisseurs en toute sécurité.

Un plan DNS d'urgence qui repose sur une copie manuelle d'une zone complexe peut échouer lorsque l'équipe est fatiguée et que l'entreprise panique.

L'économie du DNS rend facile le sous-investissement. Le DNS géré peut être une petite ligne budgétaire par rapport à l'hébergement cloud, au traitement des paiements ou à l'ingénierie logicielle. Pourtant, une panne peut arrêter les revenus avant que la couche applicative ne voie une requête. La valeur du contrat et la valeur de la dépendance peuvent être radicalement différentes. La responsabilité exige de traiter la valeur de la dépendance comme base de l'investissement en résilience.

Les autorités publiques peuvent reproduire le même test

Les autorités publiques supposent parfois que parce que leurs services ne vendent pas de produits, les leçons de continuité des revenus sont moins pertinentes. Le cas Dyn dit le contraire. Remplacez les revenus par l'accès public, et la dépendance est la même. Un portail de prestations sociales, une page d'alerte d'urgence, un service judiciaire, un site d'information sur la santé, une page d'information électorale ou un service municipal peut être inaccessible parce que le DNS échoue en amont. Le citoyen ne se soucie pas de savoir si la cause est le code applicatif, le DNS, le trafic DDoS ou la configuration du registraire.

Le citoyen a besoin du service.

Les organismes publics devraient donc maintenir un registre des dépendances DNS faisant autorité. Quels domaines sont critiques pour la communication d'urgence? Lesquels sont utilisés pour les paiements, les rendez-vous, les délais légaux, les services de santé ou l'identité? Quels fournisseurs DNS les hébergent? Quels registraires contrôlent la délégation? Quelles équipes peuvent apporter des changements le week-end? Quels canaux alternatifs existent si le domaine ne peut pas résoudre? Quels canaux de statut utilisent un fournisseur et un domaine différents?

Ce sont des questions simples, mais elles sont souvent absentes jusqu'à ce qu'un incident les force à apparaître.

Les conseils du NCSC du Royaume-Uni sur lagestion des risques DNSdécrivent le DNS comme une dépendance critique et encouragent les organisations à comprendre la propriété, la configuration et la sécurité du registraire. Ces conseils renforcent la leçon de Dyn: le risque DNS n'est pas seulement un problème de fournisseur. C'est un problème de propriété, de configuration, de surveillance et de continuité pour chaque organisation ayant un service numérique public.

Les exercices du secteur public devraient inclure la communication avec les citoyens. Si le domaine principal échoue, où les citoyens verront-ils les mises à jour? Les centres d'appels peuvent-ils recevoir les mêmes informations? Les bureaux locaux peuvent-ils afficher des avis? Les comptes de médias sociaux peuvent-ils être fiables et mis à jour? Les partenaires peuvent-ils lier vers des domaines alternatifs? Les services d'urgence peuvent-ils communiquer par des canaux préétablis? Ces questions peuvent sembler opérationnelles plutôt que techniques, et c'est le but.

La défaillance DNS devient un problème de service public lorsque le public a besoin d'informations et que l'adresse ordinaire ne fonctionne pas.

Le même registre peut soutenir les achats. Un organisme public qui achète un nouveau service numérique devrait demander comment le DNS du service est hébergé, comment la délégation est contrôlée, quels arrangements secondaires existent, comment DNSSEC est géré et comment la défaillance du fournisseur est testée. Si la réponse est que le fournisseur gère tout, l'organisme public devrait quand même recevoir des preuves. Le DNS externalisé reste une responsabilité publique lorsque le service public en dépend.

La responsabilité devrait s'étendre à la prévention des botnets

L'attaque Dyn a également laissé une leçon pour la politique des appareils. Les défenseurs DDoS et les clients DNS ne peuvent pas résoudre seuls l'échelle des botnets. Les appareils qui ont rejoint Mirai étaient souvent hors du contrôle direct de Dyn ou de ses clients. Cela rend la prévention difficile, mais cela rend également la politique nécessaire. Les fabricants d'appareils devraient éviter les identifiants par défaut, fournir des mécanismes de mise à jour, documenter les périodes de support et rendre la configuration sécurisée réaliste pour les utilisateurs ordinaires.

Les opérateurs de réseau devraient détecter les modèles de trafic abusif et aider les clients à remédier aux appareils compromis. Les détaillants et les services d'achat devraient traiter la sécurité des appareils comme un critère d'achat.

L'action de la Federal Trade Commission contre D-Link, résumée dans l'annonce de plainte de 2017 de la FTC, ne découlait pas spécifiquement du cas Dyn, mais elle illustre la direction de la responsabilité pour les appareils en réseau non sécurisés. La sécurité des appareils grand public n'est pas seulement un problème de confidentialité pour les propriétaires d'appareils. À grande échelle, les appareils faibles deviennent une capacité d'attaque d'infrastructure contre des victimes non liées. Cette externalité est la raison pour laquelle la sécurité des appareils appartient à un article sur la continuité DNS.

Un dossier public mature relierait la prévention des botnets à la continuité de service. Si des appareils non sécurisés alimentent des attaques qui rendent les services publics inaccessibles, alors les normes pour les appareils, l'étiquetage, la divulgation des vulnérabilités et la réponse aux abus de réseau font partie de la résilience. La partie qui gère un service DNS a encore besoin de défenses solides. Le client a encore besoin de basculement. Mais la surface d'attaque à l'échelle de la société doit également rétrécir. Sinon, chaque fournisseur achète simplement plus de capacité contre un pool croissant de terminaux faibles.

Les poursuites Mirai ont fourni un type de responsabilité: les créateurs du botnet ont été identifiés et punis. C'est nécessaire et insuffisant. La responsabilité pénale après coup ne restaure pas les ventes perdues pendant une panne ou les rendez-vous manqués parce que les services étaient inaccessibles. La responsabilité préventive demande pourquoi tant d'appareils pouvaient être recrutés en premier lieu et qui bénéficie d'un déploiement non sécurisé. Ces questions déplacent l'analyse d'une seule attaque vers un problème de marché et de gouvernance.

Le prochain événement de type Dyn pourrait être plus fragmenté

Le prochain grand événement d'accessibilité DNS pourrait ne pas ressembler à un seul fournisseur sous une attaque évidente. Il pourrait impliquer un compromis de registraire, des fuites de route affectant l'infrastructure DNS, des erreurs DNSSEC, des problèmes de contrôle du fournisseur cloud, des interactions CDN, le comportement des résolveurs récursifs ou un filtrage régional. Le modèle de responsabilité reste le même: les clients découvriront que la résolution de noms est une dépendance commerciale seulement quand elle échoue.

Les organisations qui ont pratiqué l'indépendance des fournisseurs, le contrôle du registraire et la communication alternative pourront répondre avec des preuves. Les organisations qui ont traité le DNS comme un paramètre par défaut auront plus de mal.

Les événements fragmentés sont plus difficiles à expliquer publiquement. Si certains utilisateurs peuvent atteindre le service et d'autres non, le support client peut rejeter les signalements comme des problèmes locaux. Si les caches cachent le problème pour certains utilisateurs, les dirigeants peuvent sous-estimer l'impact. Si la surveillance provient du mauvais réseau, les intervenants peuvent manquer les régions affectées. Si une page de statut fonctionne pour le personnel mais pas pour les clients, la communication devient trompeuse.

Un plan de continuité DNS mature devrait supposer une visibilité incohérente et concevoir la surveillance pour la détecter.

L'impact commercial de la fragmentation peut être sévère. Un détaillant mondial peut perdre le paiement seulement sur certains marchés. Un fournisseur SaaS peut échouer pour les clients derrière certains résolveurs. Un site gouvernemental peut être accessible au niveau national mais pas à l'étranger, ou l'inverse. Les outils de publicité, d'analyse et de support peuvent rapporter des données partielles. Si l'organisation ne peut pas séparer l'accessibilité DNS de la performance applicative, elle ne peut pas calculer le préjudice avec précision ni notifier les clients honnêtement.

C'est pourquoi le dossier Dyn devrait rester dans la mémoire des conseils. C'est un rappel que les surfaces de contrôle de l'Internet ne sont pas toujours là où les propriétaires de marques pensent qu'elles sont. Une entreprise peut investir massivement dans des serveurs résilients et rester fragile à la couche de noms. Un organisme public peut durcir les applications et rester inaccessible par une défaillance de registraire ou de fournisseur DNS. Un fournisseur peut construire un réseau solide et faire face au trafic de millions de terminaux faibles. La responsabilité est la discipline de voir ces dépendances avant le public.

La norme pratique est simple: si un domaine est assez critique pour porter des revenus, des soins, des informations publiques ou la confiance des clients, son chemin de défaillance devrait être testé avant que les attaquants ne le testent pour tout le monde.

Typographie

La typographie est l'art et la technique d'arranger les caractères pour rendre le langage écrit lisible, compréhensible et visuellement attrayant. Elle implique la sélection de polices de caractères, de tailles de points, de longueurs de ligne, d'espacement des lignes et d'espacement des lettres.

• La typographie est née avec l'invention des caractères mobiles par Johannes Gutenberg au XVe siècle.
• Les éléments clés incluent la sélection de la police, le crénage, l'approche et l'interlignage.
• Une bonne typographie améliore la lisibilité et transmet l'ambiance ou le ton dans la conception.