Cadre de mesures à mettre en œuvre par les opérateurs de registre pour répondre à des menaces à la sécurité

Objectif

Ce cadre fait suite à l'engagement pris par le Comité du programme des nouveaux gTLD (NGPC) du Conseil d'administration auprès du Comité consultatif gouvernemental (GAC) concernant la demande de l'ICANN à la communauté de participer en vue de développer un cadre contenant les réponses qu'un opérateur de registre (RO) peut mettre en œuvre pour répondre à des menaces à la sécurité identifiées. Ce cadre est un document volontaire et non contraignant visant à articuler la façon dont les registres peuvent répondre à des menaces à la sécurité identifiées.

Ce cadre ne permet pas de régler les situations où un opérateur de registre n'a pas le pouvoir discrétionnaire de répondre (comme lorsqu'il est soumis à un ordre de justice d'un tribunal d'une juridiction dont le registre dépend). Il ne reflète pas une politique de consensus touchant les registres.

Portée

Ce cadre aborde les réponses des registres à des avis de menaces à la sécurité.

Catégories d'actions par les registres en réponse aux menaces de sécurité

Les politiques des noms de domaine génériques de premier niveau pour les opérateurs de registre ou Conditions régissent habituellement les types de réponses à la disposition de l'opérateur de registre. Ces politiques sont élaborées en fonction des exigences légales, opérationnelles et techniques applicables, qui varient suivant les registres et les juridictions. Les politiques peuvent être modifiées à la discrétion du RO, en ligne avec les politiques de consensus et les prescriptions légales, afin de répondre à de nouvelles circonstances et aux leçons tirées des précédentes les menaces à la sécurité.¹

Cette liste, bien que non exhaustive, représente pour un opérateur de registre de nombreuses possibilités de réponses à une malveillance potentielle.

Nom de domaine existant

• Soumettre la question au bureau d'enregistrement.

  Le renvoi est souvent la première réponse employée par un RO parce que c'est le bureau d'enregistrement qui a la relation contractuelle avec le titulaire du nom de domaine. Le bureau d'enregistrement devra se voir offrir une possibilité limitée dans le temps d'enquêter sur la menace à la sécurité et d'y réagir de façon appropriée. Une réponse négative ou inexistante du bureau d'enregistrement ne doit pas empêcher le registre d'agir.

• Mettre en attente pour que la résolution du nom de domaine ne s'effectue pas.

  L'application du statut server Hold supprime le nom de domaine du fichier de zone TLD, avec pour conséquence la non-résolution du nom de domaine sur l'Internet public.² L'autre avantage de cette action est sa facilité à être inversée en cas d'erreur.

• Verrouiller le nom de domaine pour qu'il ne puisse pas être modifié.

  Bien que rarement utilisé pour les menaces à la sécurité, l'utilisation du statut verrouillé³ signifie qu'un domaine ne peut être ni transféré ni supprimé, ni faire l'objet de modifications, mais qu'il peut toujours se résoudre. Ceci peut parfois être rencontré dans le cadre d'une action où un domaine est bloqué en conjonction avec la saisie de ses serveurs de noms.

• Rediriger les services de noms pour le nom de domaine.

  Un registre possède la capacité technique de modifier les serveurs de noms d'un nom de domaine. En changeant les serveurs de noms pour un nom de domaine, les services associés avec ce nom de domaine peuvent être redirigés pour analyse du trafic d'attaque (sinkholing) pour identifier les victimes aux fins de réparation.

• Transférer le nom de domaine.

  Le transfert d'un domaine à un bureau d'enregistrement correctement qualifié peut empêcher son exploitation, tout en permettant la gestion de cycle de vie, des codes de statuts EPP, et de son expiration.

• Supprimer le nom de domaine.

  La suppression est une action radicale et généralement peu recommandée sans diligence raisonnable soigneuse et le soutien des autorités compétentes. La restauration d'un nom de domaine, si la suppression est jugée inappropriée, peut entraîner des charges supplémentaires qui n'existeront pas en plaçant un nom de domaine sur server Hold. La suppression n'est généralement pas aussi efficace que la suspension dans la réduction des menaces à la sécurité, car le titulaire de nom de domaine est libre de réenregistrer son nom de domaine après qu'il a été purgé de la zone.

• Ne pas agir

  Cette option est toujours disponible. La politique de registre peut limiter son action dans des circonstances particulières ou cette option peut être l'action par défaut si aucune autre réponse n'est appropriée. De même, un RO peut arriver à la conclusion qu'une question renvoyée ne constitue pas une menace à la sécurité ou que les conséquences de l'action l'emportent sur la menace elle-même. À titre de courtoisie, le RO devrait répondre à l'auteur d'une menace à la sécurité en indiquant pourquoi ceci est la réponse à la menace à la sécurité signalée.

Nom de domaine non enregistré (Type DGA)

Une menace à la sécurité peut être associée à un nom de domaine qui n'est pas encore enregistré. Cela peut se produire lorsque le nom de domaine est le résultat d'un algorithme de génération de domaine (DGA) automatique associé à l'activité d'un réseau zombie. Souvent la menace impliquera des milliers de noms de domaine.

• Créer le nom de domaine.

  L'enregistrement d'un nom de domaine potentiellement malveillant semble contre-intuitif ; mais s'il est effectué dans des conditions contrôlées, il permet aux chercheurs et aux organismes de sécurité publique tels que les équipes de préparation en cas d'urgence informatique (CERT) à prendre les mesures appropriées (comme analyser le trafic d'attaque ⁴) sur un nom de domaine. Comme pour l'option de transfert ci-dessus, ceci permet d'identifier les ordinateurs victimes en vue d'une atténuation. En outre, l'utilisation du nom de domaine est refusée aux acteurs néfastes comme dans l'option de blocage ci-dessous.⁵

  Le RO dispose d'un pouvoir discrétionnaire sur la délégation de domaines préalablement non enregistrés à un bureau d'enregistrement qualifié de manière adéquate, ou à son propre bureau d'enregistrement interne. Les RO doivent s'assurer d'obtenir de l'ICANN les dérogations appropriées ou nécessaires en ce qui concerne certaines dispositions contractuelles de leurs accords de registre respectifs. Ceci est actuellement réalisé par le processus de demande de sécurité accélérée de registre (ERSR) de l'ICANN. Le calendrier de la réception de la dérogation est tributaire de l'ICANN.

• Bloquer l'enregistrement du nom de domaine.

  En cas d'accord, le RO peut réserver le nom de domaine demandé. Le demandeur devra travailler avec le RO pour définir une durée appropriée du blocage, le cas échéant.

Signaler les menaces à la sécurité

Bien que l'évaluation de la crédibilité d'une source soit un problème pour le RO individuel, il existe une hiérarchie dans la gravité des menaces à la sécurité. Un RO doit également prêter attention à la qualité et au standard de l'information fournie dans un rapport d'une source, pris dans l'ensemble avec les précédents rapports. Un exemple explicite du moment où la priorité devra être donnée et les mesures prises plus rapidement, sous réserve des politiques et décisions du RO, est celui où les rapports sont correctement faits par les autorités légales nationales compétentes (LEA) de l'établissement du RO, ou lorsqu'une demande est déposée par décision judiciaire d'un tribunal ayant juridiction sur le RO.

1. Rapports des autorités légales

   Lorsqu'il est confirmé que la partie notifiante signalante est une autorité légale gouvernementale (y compris les organismes nationaux d'application de la loi ou les autres agences gouvernementales de sécurité publique d'une juridiction dont dépend le RO), ce cadre de de mesure encourage les RO à considérer de tels rapports comme étant d'une plus grande fidélité, et en tant que tels, leur offrir la priorité nécessaire. Bien que les RO puissent procéder avec un degré plus élevé de certitude en ce qui concerne les demandes des LEA, ils doivent tout de même conduire toute enquête qu'ils jugent nécessaire pour s'assurer que le dossier renvoyé constitue proprement une menace à la sécurité et confirmer la validité de la source de renvoi.

2. Rapports de sources reconnues par le RO

   À sa propre discrétion, un RO peut choisir de prioriser les rapports des entités qu'il reconnaît comme ayant l'expertise requise dans le domaine approprié, tels que les CERT nationaux et les organisations d'établissement de rapports sur la sécurité.

3. Rapports provenant d'autres sources

   Les RO sont encouragés à traiter adéquatement les rapports d'utilisation technique malveillante du DNS, selon les cas. Les RO sont en outre encouragés à veiller à ce que des procédures appropriées soient mises en place, de sorte qu'une attention suffisante puisse être accordée à toute menace vérifiée. Ceci inclut les rapports et les demandes d'utilisateurs, de membres du public, ou de ceux qui ont été identifiés par une analyse technique au choix du RO. Pour éviter le doute, aucun des rapports reçus de sources anonymes ne devrait jamais être écarté uniquement parce que le rapport est anonyme. Les RO doivent s'engager à examiner tous les rapports faits de bonne foi, qu'ils soient anonymes ou non, fondés sur les mérites et les éléments de preuve présentés.

Réponse du registre

Pour plus de clarté, le mot « Réponse » dans le contexte suivant est utilisé pour signifier l'action, ou les actions réalisées à la suite de la réception d'un rapport concernant une menace à la sécurité spécifiquement identifiée par le RO comme posant un risque réel de préjudice, ceci en fonction des politiques du RO, dont notamment, mais pas seulement une réponse à l'autorité de sécurité publique ayant signalé la menace à la sécurité, que cette menace fait l'objet d'une enquête par le RO.

Lors de la réception d'un renvoi, les RO sont encouragés à fournir initialement et rapidement un accusé de réception indiquant que la demande est à l'étude. Dans les 24 heures suivant cet accusé de réception, le RO devrait faire des efforts raisonnables pour répondre en fournissant son évaluation de la demande et, lorsque cela est possible et approprié, son plan d'action retenu sur la base de cette évaluation. Si possible, l'inclusion d'un calendrier possible des actions sera bénéfique dans la gestion des attentes des deux côtés.

Les RO peuvent évaluer la demande conformément à leurs politiques et leur réponse subséquente en fonction des facteurs suivants :

1. Niveau de priorité

   Le jugement initial du classement « prioritaire » d'une demande doit être évident et ne nécessite pas de compétences spécifiques afin de déterminer l'articulation avec la sécurité publique. Le classement « prioritaire » doit être accordé à une menace imminente à la vie humaine ou des infrastructures essentielles ou dans les cas d'exploitation d'enfants. Une importante menace de perturbation du DNS peut également être considérée comme « prioritaire ». Les registres doivent utiliser leurs propres politiques internes pour faire ces déterminations. Tout autre incident non classé comme « prioritaire », lié à l'utilisation malveillante technique du DNS sera traité conformément à la politique contre l'utilisation malveillante du registre lorsque celui-ci possède le pouvoir discrétionnaire juridique approprié.

2. Origine du rapport

   Chaque RO doit scruter, questionner ou autrement s'enquérir de la légitimité de l'origine d'une demande, conformément à ses propres politiques et processus internes.

3. Contenu

   Le contenu de chaque demande doit être examiné dans son intégralité, car il peut contenir des informations pouvant la valider, ou des demandes spécifiques destinées au RO. Les rapports de priorité doivent être corroborés par des informations démontrant un potentiel évident de nuisance à la vie humaine, les infrastructures essentielles ou d'exploitation des enfants. Ce type de contenu, y compris toute demande spécifique pour le RO, devra être évalué en se fondant sur les politiques internes de chaque RO et si possible et approprié, contenir l'identification des mesures correctives.

4. Entités responsables

   Les RO ne sont pas nécessairement les meilleures entités pour régler certaines menaces à la sécurité. L'identification des entités considérées comme étant les plus pertinentes et appropriées pour résoudre la menace à la sécurité est cruciale pour la résolution rapide de la question. Par exemple, dans le cas d'enregistrements abusifs, le bureau d'enregistrement ou le revendeur est le mieux placé pour examiner et traiter ces problèmes d'enregistrement. Alors que, dans le cas de systèmes compromis, le titulaire de nom de domaine ou son fournisseur d'hébergement conserve un accès administratif aux systèmes concernés et est le plus à même de régler les problèmes ; toutefois, l'opérateur de registre peut être l'entité la mieux placée pour aborder les menaces à grande échelle qui couvrent de nombreux titulaires ou bureaux d'enregistrement.

   Si et quand les demandes sont classées comme « prioritaires » et d'une origine légitime et crédible, il faut, dès que possible et au plus tard 24 heures après son accusé de réception, que l'opérateur de registre reconnaisse la menace et communique ses mesures prévues pour remédier à la menace à la sécurité. Lorsque des incidents ne sont pas « prioritaires », les RO sont encouragés à y répondre dans un délai de 24 heures avec des détails de ce qu'ils feront pour les résoudre, y compris le fait qu'ils peuvent ne rien entreprendre. Les RO sont encouragés à communiquer l'analyse de la menace au demandeur afin de clarifier les raisons les poussant à prendre ou non d'autres mesures ou le fait que les mesures correctives doivent être traitées par un acteur différent.

   Les RO sont encouragés à rentrer en relation avec une ou plusieurs agences d'application de la loi compétentes dans leur juridiction (p. ex., l'unité nationale contre le crime utilisant les technologies avancées) ou des agences de sécurité publique appropriées qui peuvent :

   • aider à évaluer les rapports sur les menaces à la sécurité.
   • participer à l'identification et la vérification des agences d'application de la loi et celles chargées de la sécurité publique dans leur juridiction.
   • servir de facilitateurs entre les RO et les agents chargés de l'application de la loi.

   Les RO sont encouragés à partager les informations liées à l'utilisation malveillante du DNS avec les autres RO et les agences d'application de la loi compétentes pour prévenir l'utilisation malveillante du DNS.

5. Respect de la vie privée et confidentialité

   La déclaration d'une menace à la sécurité identifiée et sa résolution supposent en général le traitement d'informations personnelles identifiables (PII) par le RO, les agences d'application de la loi ou une autorité compétente et appropriée. Lorsqu'un RO répond à une menace à la sécurité identifiée, il doit être conscient de ses propres politiques de confidentialité, des meilleures pratiques acceptées en matière de confidentialité, de sécurité des données, de transfert des données, de leur conservation, ainsi que des lois locales, des exigences contractuelles, ou autres exigences contraignantes.

   De futures itérations et des mises à jour de ce cadre de mesures peuvent se produire, le cas échéant, conformément au processus de l'ICANN.

---

¹ Ce cadre ne couvre pas l'obligation des opérateurs de registre de procéder périodiquement à une analyse technique pour déterminer si des domaines dans son gTLD sont utilisés pour perpétrer des menaces à la sécurité, telles que le dévoiement, l'hameçonnage, les programmes malveillants et les réseaux zombies, pas plus qu'il ne couvre l'obligation pour les opérateurs de registre de maintenir des rapports statistiques portant sur le nombre de menaces à la sécurité identifiées et les mesures prises à la suite des contrôles de sécurité périodiques. Par conséquent, le cadre ne couvre pas la réponse à une menace à la sécurité qui peut être découverte par l'opérateur de registre lui-même dans le cadre de l'analyse technique périodique obligatoire. Les opérateurs de registre peuvent toutefois choisir d'appliquer ce cadre-ci lors de leur réponse aux menaces à la sécurité détectées.

² Communément connu sous le nom de « suspension », il aura pour effet d'arrêter les services DNS pertinents qui sont sous le contrôle du RO, sans saisie du domaine.

³ Le statut « verrouillé » du registre est en fait une combinaison de ces trois codes EPP : serverTransferProhibited, serverDeleteProhibited, et serverUpdateProhibited.

⁴ Une technique qui pourrait être utilisée comme un moyen de défense pour diriger le trafic malveillant vers un serveur spécifié.

⁵ Les données enregistrées peuvent contenir des informations personnellement identifiables (PII). Toute action éventuelle doit être menée conformément aux exigences appropriées de la juridiction du RO.