La sécurité est au cœur du travail que nous faisons à l’ICANN pour faciliter la coordination technique mondiale des systèmes d’identifiant unique d’Internet. Cette publication a pour but d’apporter des précisions et de fournir un contexte pour les termes utilisés par l’ICANN en matière de sécurité. Cette base de connaissances aidera la communauté à améliorer ses discussions avec ses homologues de l’ICANN ainsi qu’avec les parties prenantes du vaste écosystème d’Internet.
En mai, Markus Kummer a écrit dans le blog de la société d’Internet sur l’histoire du terme « multipartite ». 1 À partir de la lecture de ce blog, l’idée nous est venue qu’un article sur le contexte historique des termes utilisés par l’ICANN en matière de sécurité pourrait contribuer à mieux faire comprendre l’usage que nous en faisons et les différences pouvant exister par rapport à d’autres usages dans l’écosystème. Si la perspective historique vous intéresse, consultez l’encadré à la fin de l’article [cliquez ici].
Cette publication se focalise sur les termes suivants :
- Sécurité – se doter des moyens pour protéger les identifiants uniques d’Internet et en empêcher l’utilisation abusive.
- Stabilité – capacité à garantir que le système fonctionne conformément aux prévisions et à faire en sorte que les utilisateurs des systèmes d’identification uniques lui fassent confiance.
- Résilience – capacité du système d’identificateurs uniques à supporter/ tolérer / survivre de manière efficace aux attaques malveillantes et à d’autres éléments perturbateurs sans interrompre ou arrêter le service.
Sécurité
Dans le cadre de l’ICANN, la formule « se doter des moyens » concerne une fonction particulièrement importante de l’équipe chargée de la sécurité : nous assurons l’expertise et consacrons des ressources pour aider, éduquer et entraîner d’autres membres de l’écosystème d’Internet à protéger les identifiants uniques et à partager leurs pratiques afin d’éviter tout usage abusif. Cette fonction est assurée par le biais de la participation technique de l’équipe de sécurité.
Une partie clé du rôle de l’ICANN en matière de sécurité porte sur l’intégrité opérationnelle et l’atténuation des menaces. L’ICANN est responsable de veiller à la sécurité (« sécurité de fonctionnement ») de la racine L, des fonctions de signature de clé du DNSSEC, des fonctions IANA, des opérations des nouveaux gTLD, de la gestion de la base de données des zones horaires, ainsi que des fonctions organisationnelles telles que les finances, les ressources humaines, les installations et les conférences. Il s’agit d’un rôle proactif qui vise à minimiser les risques liés à ces fonctions opérationnelles et qui comporte l’identification et l’atténuation des menaces dans ces domaines et dans tout autre domaine où les identifiants soient mis en danger.
Stabilité
Un élément lié à la sécurité est l’idée de donner des gages de confiance. Cet élément a été incorporé dans notre définition de stabilité. La stabilité est liée à la cohérence, du point de vue technique des serveurs de noms et des données, entre les délégations et la zone appropriée dans l’espace de noms. Le maintien de la stabilité a été et reste toujours un volet important de la mission de l’ICANN.
Résilience
La définition de résilience dans le contexte de l’ICANN est liée aux premiers objectifs fixés lors de la conception des protocoles d’Internet, à savoir, leur capacité d’adaptation face aux changements et leur résistance en cas de dysfonctionnement.
La résilience concerne l’ensemble de l’écosystème et sa « capacité à maintenir sa structure et sa fonction au fil du temps face à des perturbations externes ». Il s’agit d’un concept tiré et adapté de l’économie écologique. Le Centre de résilience de Stockholm donne un bon aperçu du concept de résilience 2. Dire d’un système d’identifiant unique et d’un DNS qu’ils sont résilients implique qu’ils sont capables d’assurer un écosystème d’Internet sain et durable.
Des exemples de programmes destinés à renforcer la résilience du système d’identifiant unique sont le dépôt de données des bureaux d’enregistrement et les opérateurs de registre de secours backend. La résilience inclut des exercices et des vérifications de continuité et d’urgence.
L’ICANN a souscrit aux principes du Forum économique mondial sur la cyber-résilience3 (pdf). Les principes du Forum économique mondial reconnaissent que la cyber-résilience s’appuie sur le dialogue franc et la collaboration entre les parties qui intègrent l’écosystème d’Internet.
Coordination et collaboration
La coordination et la collaboration sont des fonctions clé pour l’ICANN et consistent à assurer l’interopérabilité et à préserver la sécurité, la stabilité et la résilience du système d’identifiant unique d’Internet. L’ICANN joue un rôle de coordination auprès des parties prenantes d’Internet, y compris les gouvernements et l’industrie privée, mais avec une structure de gouvernance indépendante. Il ne s’agit pas d’une fonction de régulation, à condition d’établir une distinction vis à vis des fonctions dûment gérées par les gouvernements et les agences d’application de la loi.
La Coordination est au cœur des processus d’allocation des identifiants uniques d’Internet, ainsi que de la participation technique et de l’élaboration de politiques associées aux identifiants uniques d’Internet. La coordination parmi et entre les différentes parties et les différentes fonctions de la communauté contribue à assurer que les décisions liées aux fonctions techniques soient prises en vue de l’intérêt public, de façon claire, équitable, responsable et transparente.
On en trouve un exemple dans les directives sur la communication coordonnée, publiées en mars 2013. Les directives définissent le rôle que jouera l’ICANN au cas où des vulnérabilités seraient identifiées et expliquent la façon dont les parties devraient communiquer les informations relatives à des vulnérabilités identifiées dans un système ou un réseau exploité par l’ICANN.
La collaboration est un concept indépendant, qui est toutefois lié à la coordination. Elle est souvent définie comme un travail mené en concertation avec d’autres parties ; notamment dans le domaine littéraire, artistique ou scientifique 4. Le protocole d’accord initialement conclu avec le Département du commerce des États-Unis utilisait le terme « collaborer » pour faire référence au travail en concertation que devraient réaliser l’ICANN et le Département du commerce afin de mettre en place les fonctions et les procédures destinées à assurer la transition des tâches de coordination des identifiants uniques d’Internet dont l’ICANN serait responsable. Pendant les 15 dernières années, cette fonction de coordination s’est développée pour inclure un vaste éventail de parties prenantes de l’écosystème d’Internet.
La collaboration est liée à la participation et aux activités réalisées par l’ICANN avec ses homologues dans l’écosystème d’Internet. Par exemple, les membres de l’équipe chargée de la sécurité de l’ICANN participent régulièrement à des événements tels que le Forum de gouvernance d’Internet et les Forums de gouvernance d’Internet régionaux, le Forum annuel de sécurité IISI à Garmisch-Partenkirchen, Allemagne, la Conférence d’Interpol sur l’économie souterraine, et le Forum des équipes de réponse aux incidents et de sécurité, entre autres. Ce terme fait également référence à l’implication de l’ICANN dans les mesures de réponse à Conficker 5 ainsi qu’à d’autres attaques malveillantes contre le DNS.
Nous espérons que cet article permettra au lecteur de mieux comprendre l’usage fait par l’ICANN des termes en matière de sécurité et nous attendons avec intérêt de poursuivre le dialogue avec la communauté d’Internet dans le cadre de ces fonctions.
Usages historiques
Les termes en matière de sécurité publiés dans ce blog précèdent la création de l’ICANN et sont associés aux débuts de l’informatique jusqu’à l’avènement des réseaux. La sécurité des ordinateurs et des informations avait été identifiée comme une préoccupation lors de la création d’ARPANET. Dès la fin des années 60, la sécurité a été associée à la protection des informations dans des systèmes de partage de ressources parmi un certain nombre d’usagers simultanés 6.
Le besoin de coordination est lié au caractère unique de l’allocation d’identifiants (voir le développement du concept de noms de domaine 7 et ses mises à jour par le biais des RFC ultérieures).
Après l’évolution d’ARPANET et des réseaux universitaires vers l’ensemble des fonctions coordonnées par Jon Postel au titre de l’autorité chargée de la gestion de l’adressage sur Internet, la communauté technique naissante d’Internet a reconnu la nécessité de se doter d’une organisation capable de collecter et d’enregistrer des informations sur les réseaux à qui les identifiants étaient alloués ainsi que le besoin d’assurer l’accès mondial à Internet 8.
Les termes « stabilité » et « coordination » faisaient partie des principes clé de la déclaration de politiques sur la gestion des noms et des adresses d’Internet établie en 1998 par le Département du commerce des États-Unis (appelée généralement le « Livre blanc ») , où il était indiqué que l’importance commerciale d’Internet au niveau mondial exigeait que « l’exploitation du DNS et le fonctionnement du système officiel de serveur racine soient sûrs, stables et robustes ». 9
Le « Livre blanc » décrivait également la coordination comme étant l’ensemble de fonctions à mettre en place afin d’assurer le bon fonctionnement d’Internet. La coordination était considérée à la fois un mécanisme destiné à préserver la stabilité d’Internet et un processus suffisamment flexible pour répondre aux besoins changeants d’Internet et de ses usagers au niveau mondial.
La description du principe de stabilité faisait référence à la coordination avec le secteur privé « sans perturbation du fonctionnement du DNS » 10.
La sécurité, la stabilité et la coordination figurent également dans les statuts de l’ICANN en tant qu’éléments constitutifs de sa mission et de ses valeurs fondamentales, et ont été adoptés dans l’Affirmation d’engagements.
La RFC 1591, publiée par Jon Postel en mars 1994 pour décrire la structure du système de noms de domaine et la délégation de noms de domaine de premier niveau, utilise le terme « résilience » lorsqu’elle décrit les devoirs d’un gestionnaire de TLD. Parmi ces devoirs, on retrouve celui de « répondre aux requêtes en temps voulu et gérer la base de données avec précision, solidité et résilience». 11
Les références à la résilience sont limitées pendant la période comprise entre 1999 et 2008. En novembre 2001, Bruce Schneier a prononcé un discours inaugural focalisé sur la « sécurité résiliente » lors de la Conférence de l’ICANN consacrée à la sécurité et à la stabilité du système d’allocation de noms et d’adresses d’Internet. En 2003, le terme « résilience » est à nouveau utilisé dans le 8e rapport de situation du Département du commerce des États-Unis pour faire référence à une étude du SSAC consacrée à « l’évaluation de la redondance et de la résilience des principaux serveurs de noms de domaine pour faire face aux attaques par déni de service distribué ». 12.
En 2008, suite à la création d’une équipe de l’ICANN chargée de la sécurité, la résilience est devenue un terme clé pour l’ICANN, associé à la sécurité et à la stabilité. Pour plus d’information, des documents sur l’équipe de sécurité de l’ICANN peuvent être consultés dans l’archive de ressources documentaires de sécurité 13.
1 http://www.internetsociety.org/blog/2013/05/multistakeholder-cooperation-reflections-emergence-new-phraseology-international
2 http://www.stockholmresilience.org/21/research/what-is-resilience.html
3 Principes du Forum économique mondial sur la cyber-résilience, http://www3.weforum.org/docs/WEF_IT_PathwaysToGlobalCyberResilience_Report_2012.pdf [PDF, 2.09 MB]
4 https://en.wikipedia.org/wiki/Collaboration
5 http://www.icann.org/en/about/staff/security/conficker-summary-review-07may10-en.pdf [PDF, 386 KB]
6 Contrôles de sécurité pour des systèmes informatiques, Rapport RAND R-609, 1970, http://www.rand.org/pubs/reports/R609-1/index2.html
7 RFC 1034, http://www.ietf.org/rfc/rfc1034.txt, tel que mise en œuvre dans la RFC 1035, http://www.ietf.org/rfc/rfc1035.txt
8 RFC 1174, http://tools.ietf.org/html/rfc1174
9 Déclaration de politique sur la gestion des noms et des adresses d’Internet du Département du commerce des États-Unis, 1998, 63 Fed. Reg. 31741 (connu généralement sous le nom de « Livre blanc », voir http://www.icann.org/en/about/agreements/white-paper)
10 Protocole d’accord avec le Département du commerce des États-Unis, http://www.icann.org/en/about/agreements/mou-jpa/icann-mou-25nov98-en.htm)
11 RFC 1591, http://www.ietf.org/rfc/rfc1591.txt
12 http://www.icann.org/en/about/agreements/mou-jpa/status-report-01aug03-en.htm
