Je vous présente une mise à jour montrant les progrès réalisés pour la mise en œuvre des 28 recommandations présentées par l’équipe de révision sur la stabilité, la sécurité et la résilience du DNS (SSR). Lors de la réunion de l’ICANN tenue en octobre, à Toronto, le Conseil d’administration a approuvé le rapport final et les recommandations de l’équipe de révision sur la stabilité, la sécurité et la résilience et a donné des instructions au personnel de s’occuper de la mise en œuvre [lien : http://www.icann.org/fr/groups/board/documents/resolutions-18oct12-fr.htm#1.e]. Depuis la réunion de Toronto, le personnel a travaillé pour mettre en place ces recommandations. Prochainement, la communauté pourra suivre nos progrès sur la page de mise en œuvre de l’équipe de sécurité SSR, ainsi qu’à travers la page web sur la responsabilité et la transparence. Entre temps, cette publication montre où nous en sommes en matière de suivi régulier et de reporting.
La sécurité, la stabilité et la résilience est l’un des quatre domaines faisant l’objet de révision des engagements en vertu de l’affirmation des engagements [lien : http://www.icann.org/fr/about/agreements/aoc/affirmation-of-commitments-30sep09-fr.htm] signé en 2009 entre l’ICANN et le Département du commerce des Etats-Unis. L’équipe de sécurité de l’ICANN est le responsable de vérifier les obligations de l’ICANN sous la révision du SSR, et travaille pour mettre en place les recommandations de l’équipe de révision. Les progrès de l’ICANN sur toutes les révisions à l’affirmation des engagements sont disponibles sur http://www.icann.org/en/news/in-focus/accountability.
Dans notre approche, tel qu’elle a été présentée au comité consultatif sur la sécurité et la stabilité de l’ICANN le mois dernier à Los Angeles, nous avons considéré les 28 recommandations et nous les avons organisées suivant les quatre domaines de la structure de gestion présentés par le PDG, Fadi Chehadé, à Toronto. Les voici :
- Affirmation de l’objectif [Recommandations 1, 2, 18, 24]
- Excellence opérationnelle [Recommandations 7, 8, 17, 20, 21, 9, 10, 11, 22, 25, 26, 27, 15, 28]
- Internationalisation [Recommandations 3, 4, 5, 14, 16]
- Évolution du modèle multipartite [Recommandations 6, 19, 23]
Outre l’alignement ci-dessous, il y a un graphique qui montre les 28 recommandations et qui établit une prévision des activités pour les exercices fiscaux 2013-2015.
Affirmation des objectifs – Attributions et mission de l’ICANN
| Recommandation de l’équipe de révision SSR | Mise en œuvre et état |
| #1 – L’ICANN devrait publier une déclaration unique, claire et cohérente concernant ses attributions et sa mission technique limitée en matière de SSR. | Des commentaires publics ont été reçus sur une déclaration préliminaire entre mai et septembre 2012 [lien : http://www.icann.org/en/news/public-comment/draft-ssr-role-remit-17may12-en.htm]. La déclaration préliminaire a été révisée le 4 octobre 2012 [lien : http://toronto45.icann.org/meetings/ toronto2012/presentation-draft-ssr-role-remit-04oct12-en.pdf [PDF, 133 KB]]. |
| #2 – La définition et la mise en œuvre des attributions de l’ICANN et de sa mission technique limitée en matière de SSR devraient être révisées afin de garder le consensus et obtenir l’avis de la communauté. | Le rôle mis à jour et la déclaration des attributions seront révisés par la prochaine équipe de révision SSR en 2015. |
| # 24 – L’ICANN doit définir clairement la charte, les rôles et les responsabilités de l’équipe du service de sécurité. | Mise en œuvre avec la page de l’équipe de sécurité mise à jour https://www.icann.org/security] le 4 octobre 2012 et publication du cadre SSR de l’exercice fiscal 2013. Les rôles et les responsabilités seront définis par la suite, en 2013, avec la mise en œuvre de la structure de gestion. |
| #18 – L’ICANN devrait mener une révision opérationnelle annuelle de ses progrès dans la mise en place du cadre SSR et inclure cette évaluation dans le cadre SSR de l’année suivante. | Mis en œuvre comme une partie du cadre SSR de l’exercice fiscal 2013 et sera répété tous les ans. Le prochain cadre SSR sera développé pendant le premier trimestre 2013. Le suivi du processus sera ajouté à une nouvelle page du tableau de bord dans la page de l’équipe de sécurité, au site Web de l’ICANN. |
Excellence opérationnelle – Objectifs
| Recommandation de l’équipe de révision SSR | Mise en œuvre et état |
| #7 – Sur la base de son cadre SSR actuel, l’ICANN devrait établir un ensemble clair d’objectifs, et conformément à ceux-ci établir les priorités pour ses initiatives et ses activités. | La nouvelle structure de gestion sera utilisée pour mettre en ligne les objectifs et les initiatives de l’ICANN avec la cadre annuel SSR et pour supporter le développement du budget de l’exercice fiscal 2014, le plan opérationnel et le prochain plan stratégique de l’ICANN. Nous sommes déjà en train de travailler pour adapter nos objectifs et nos activités à cette structure. |
| #8 – L’ICANN devrait continuer à peaufiner les objectifs de son plan stratégique, notamment l’objectif de maintenir et de gérer la disponibilité du DNS. Alignement clair du cadre et du plan stratégique. | Ceci est connecté au prochain plan stratégique. Le personnel a besoin d’adapter les objectifs et les activités au nouveau plan stratégique en vertu du cadre SSR annuel et des recommandations de l’équipe de révision SSR. |
Excellence opérationnelle – Transparence
| Recommandation de l’équipe de révision SSR | Mise en œuvre et état |
| #17 – L’ICANN devrait élaborer un processus interne plus structuré permettant de mieux comprendre le rapport existant entre certaines activités et initiatives et les buts, objectifs et priorités spécifiques du cadre SSR. | La structure de gestion a été utile pour aborder cette recommandation en créant un mécanisme pour les processus internes qui montrera comment les activités et les initiatives de l’ICANN en matière de sécurité, stabilité et résilience sont en ligne avec les buts, les objectifs et les priorités. Des informations supplémentaires sur ce processus seront disponibles pour la communauté avant la réunion de Beijing en 2013 à travers MyICANN et sur le site Web de l’ICANN. |
| #20 – L’ICANN devrait accroître la transparence des informations concernant l’organisation et le budget lié à la mise en place du cadre SSR et aux fonctions en matière de SSR. | Ceci sera mis en place dans le cadre SSR de l’exercice fiscal 2014 et dans le processus du plan opérationnel et budget de l’exercice fiscal 2014. La nouvelle page de la feuille de route de l’équipe de sécurité sera aussi utilisée pour aborder cette recommandation. |
Excellence opérationnelle – Structure
| Recommandation de l’équipe de révision SSR | Mise en œuvre et état |
| #21 – L’ICANN devrait élaborer un processus interne plus structuré permettant de mieux montrer le rapport existant entre le cadre SSR et certaines décisions concernant l’organisation et le budget, y compris l’analyse coût/bénéfice sous-jacente. | Nous utiliserons le mapping de gestion comme le processus structuré pour identifier l’organisation et les décisions budgétaires, et pour adapter les activités en matière de sécurité, stabilité et résilience au cadre annuel. Ceci sera mis en place dans le plan opérationnel et budget de l’exercice fiscal 2014. La sécurité travaillera avec l’équipe des finances sur cette recommandation. |
Excellence opérationnelle – Normes et conformité
| Recommandation de l’équipe de révision SSR | Mise en œuvre et état |
| #9 – L’ICAN devrait évaluer les options de certification sous les standards internationaux normalement acceptés (par ex. ITIL, ISO et SAS-70) pour ses responsabilités opérationnelles. L’ICANN devrait publier une feuille de route claire à l’égard de la certification. | La mise en œuvre du DNSSEC par l’ICANN dans la racine a respecté la certification SysTrust [lien : https://www.iana.org/dnssec/systrust et https://cert.webtrust.org/icann.html]. Les futurs processus de certification sont sous la responsabilité de l’équipe des fonctions IANA de l’ICANN, des équipes opérationnelles IT et DNS, avec le soutien de l’équipe de sécurité. |
| #10 – L’ICANN devrait poursuivre ses efforts visant à assurer le respect de la conformité contractuelle et fournir des ressources adéquates pour remplir cette fonction. L’ICANN devrait également élaborer et mettre en place un processus plus structuré de suivi des dossiers et des recherches en matière de conformité. | Cette recommandation est dirigée par l’équipe de conformité de l’ICANN et à travers la mise en place des recommandations de l’équipe de révision du WHOIS. |
Excellence opérationnelle – nTLD
| Recommandation de l’équipe de révision SSR | Mise en œuvre et état |
| #11 – L’ICANN devrait établir et mettre en place des actions visant à mesurer le succès des nouveaux gTLD et des procédures accélérées IDN qui soient expressément en rapport avec les objectifs en matière de SSR, y compris des mesures de l’efficacité des mécanismes destinés à réduire l’utilisation frauduleuse des noms de domaine. | Le personnel étudie toutes les implications de cette recommandation. L’équipe de sécurité s’attend à la collaboration du personnel et de la communauté pour compléter la mise en place. Comme ceci a trait à la concurrence, à la révision de la confiance et du choix du consommateur ainsi qu’aux mesures des nouveaux gTLD et des ccTLD IDN délégués via la procédure accélérée ccTLD IDN, il y aura un engagement avec les parties prenantes de toute la communauté. Cette recommandation est ciblée sur les mécanismes liés à la limitation aux abus des noms de domaine. Le personnel travaille avec les comités consultatifs et la communauté sur les indicateurs d’utilisation frauduleuse. |
| #22 – L’ICANN devrait publier, surveiller et mettre à jour la documentation sur les ressources organisationnelles et budgétaires nécessaires pour gérer les aspects liés à la sécurité, la stabilité et la résilience conjointement avec l’introduction des nouveaux gTLD. | Ceci est lié à la recommandation 21 (décisions budgétaires et organisationnelles) ainsi qu’au développement du contrôle avec l’introduction des nouveaux gTLD. |
Excellence des opérations – Diminution des risques de gestion et des menaces
| Recommandation de l’équipe de révision SSR | Mise en œuvre et état |
| #25 – L’ICANN devrait mettre en place des mécanismes permettant d’identifier à la fois les risques à court et à long terme ainsi que des facteurs stratégiques dans son cadre de gestion des risques. | Ce travail est en cours et il est lié à l’obtention du cadre des risques de gestion sous la recommandation 26. |
| #26 – L’ICANN devrait considérer comme prioritaire l’achèvement dans les délais prévus du travail d’élaboration d’un cadre de gestion des risques. | Ce travail est en cours. L’ICANN a retenu Westlake Governance pour aider à son projet de cadre de gestion des risques du DNS. Westlake a dirigé une session ouverte à Toronto et fournira un cadre préliminaire prochainement. |
| #27 – Le cadre de gestion des risques de l’ICANN doit être exhaustif tout en respectant le champ d’application de ses attributions et de sa mission technique limitée en matière de SSR. | Le cadre de gestion des risques sera en ligne avec les activités de l’ICANN pour soutenir sa mission technique et la communauté. Ce sera un travail exhaustif qui sera complété avec la livraison du cadre sous la recommandation 26. |
| #15 – L’ICANN devrait agir en tant que facilitateur pour la divulgation et la diffusion des menaces à la sécurité du DNS et des techniques de réduction des risques. | Le personnel étudie toutes les implications de cette recommandation. On este conscients du besoin de répondre aux risques rapidement, afin d’assurer que les informations et les individus soient protégés pendant et après les incidents, ainsi que pour informer de manière exacte et responsable. Le personnel collabore avec les opérateurs et les entités communautaires de sécurité fiables en matière de menaces à la sécurité du DNS et de techniques de réduction des risques. Ceci est lié à la recommandation 28. |
| #28 – L’ICANN devrait poursuivre sa participation active dans la détection et la réduction de risques, ainsi que dans les efforts de communication visant à diffuser des informations liées aux menaces et aux incidents. | Cette recommandation soutient la poursuite des initiatives de l’ICANN, y compris la surveillance de la zone racine, la détection et la réduction des menaces liées aux opérations du DNS de l’ICANN, aux menaces au DNS et aux incidents en général. |
Internationalisation – Terminologie et relations
| Recommandation de l’équipe de révision SSR | Mise en œuvre et état |
| #3 – Après avoir publié une déclaration consensuelle sur ses attributions et sa mission technique limitée en matière de SSR, l’ICANN devrait utiliser une terminologie cohérente et inclure des descriptions de cette déclaration dans tous ses documents. | L’équipe de sécurité travaillera au sein de l’organisation pour qu’une terminologie et des descriptions cohérentes liées au rôle et aux attributions SSR de l’ICANN soient utilisées dans tous les documents. En premier lieu, il faut organiser des cours de formation pour le personnel de l’ICANN, et par la suite, offrir un séminaire Web pour la communauté. La terminologie et la description seront également utilisées dans les présentations et dans l’engagement de l’ICANN. |
| #4 – L’ICANN devrait documenter et définir clairement la nature des relations en matière de SSR au sein de la communauté ICANN afin de fournir une référence qui puisse contribuer à une meilleure compréhension des interdépendances entre les organisations. | Le personnel prépare une documentation liée aux relations de l’ICANN et SSR. Ce sera une opportunité pour que la communauté participe de cet exercice. Cela permettra d’identifier les relations existantes et les points de contact avec la communauté ainsi que les cas où les relations devraient être poursuivies ou améliorées. En vertu des commentaires publics, la mise en place de la Rec 4 implique une plus grande sensibilisation de la communauté, la collaboration avec les organisations de soutien, les comités consultatifs, les groupes de parties prenantes et les partenaires de l’ICANN. |
| #5 – L’ICANN devrait utiliser la définition de ses relations en matière de sécurité, stabilité et résilience afin de maintenir des arrangements de travail efficaces et de démontrer la manière dont ces relations sont utilisées pour atteindre chacun des objectifs en matière de SSR. | L’équipe de sécurité travaillera avec l’équipe d’engagement global des parties prenantes de l’ICANN pour maintenir et améliorer les arrangements de travail efficaces et les relations. |
Internationalisation – Sensibilisation et engagement
| Recommandation de l’équipe de révision SSR | Mise en œuvre et état |
| #14 – L’ICANN devrait veiller à ce que ses activités de communication en matière de SSR ne cessent d’évoluer afin qu’elles restent à tout moment opportunes, pertinentes et appropriées. | Il y a davantage d’activités de sensibilisation et elles seront révisées tous les ans. L’équipe de sécurité fournira une fonction de service à l’équipe d’engagement global des parties prenantes de l’ICANN en tant qu’experts, et une fonction communautaire de sensibilisation et d’engagement en matière de SSR. |
| #16 – L’ICANN devrait poursuivre ses efforts de communication afin d’accroître la participation de la communauté au processus de développement du cadre SSR. L’ICANN devrait également établir un processus pour obtenir des avis plus systématiques d’autres membres de l’écosystème. | Il y a davantage d’activités de sensibilisation et elles seront révisées tous les ans. Ceci est lié aux recommandations 4, 5 et 14. L’équipe de sécurité soutient plusieurs initiatives de renforcement des capacités sous demande des parties prenantes ; à savoir la formation DNSSEC, la formation en matière d’attaques et de contingences des ccTLD, la sensibilisation pendant les réunions du groupe d’opérateurs de réseau comme par exemple CaribNOG, MENOG, entre autres. |
Évolution du modèle multipartite
| Recommandation de l’équipe de révision SSR | Mise en œuvre et état |
| #6 – L’ICANN devrait publier un document où soient clairement établis les rôles et les responsabilités du SSAC et du RSSAC afin de bien encadrer les activités des deux groupes. | Cette recommandation demandera la collaboration du personnel et de la communauté. Ceci a été divisé en 6A [SSAC] et 6B [RSSAC]. 6A – Les rôles et responsabilités du SSAC sont établis dans les procédures opérationnelles du SSAC. Le SSAC étudie ses procédures opérationnelles pour 2013 et est également intéressé à mettre cela en ligne avec les rôles et responsabilités du RSSAC. 6B – Les rôles et les responsabilités du RSSAC sont en cours de développement. |
| #19 – L’ICANN devrait élaborer un processus permettant à la communauté de faire un suivi de la mise en place du cadre SSR. L’information devrait être suffisamment claire pour que la communauté puisse faire le suivi de l’exécution de la part de l’ICANN de ses responsabilités en matière de SSR. | Prochainement, l’équipe de sécurité publiera un tableau de bord dans son site Web qui montrera l’état du suivi du cadre SSR et des initiatives de l’ICANN en matière de SSR. |
| #23 – L’ICANN doit fournir des ressources appropriées aux groupes de travail et comités consultatifs travaillant sur des questions liées à la sécurité, la stabilité et la résilience, cohérentes avec les exigences qui leur sont imposées. L’ICANN doit également veiller à ce que les décisions issues des groupes de travail et des comités consultatifs aient été considérées de façon objective et n’aient pas été influencées par des pressions internes ou externes. | Le personnel réalise un inventaire [23A] des activités des groupes de travail liés au SSR et des comités consultatifs (SSAC and RSSAC). Suite à cela, une description ou une documentation des processus budgétaires seront élaborées pour les organisations de soutien et les comités consultatifs [23B]. 23C décrira la démarche du processus opérationnel standard pour montrer que le groupe de travail, les organisations de soutien et les comités consultatifs sont arrivés à prendre leurs décisions de manière objective. |
