Security is at the core of what we do at ICANN to facilitate the global technical coordination of the Internet’s unique identifier systems. This post attempts to provide some clarity and context to the Security terms we use at ICANN. This baseline understanding will help the community improve discussions with ICANN’s counterparts and stakeholders in the greater Internet ecosystem.
In May, Markus Kummer wrote on the Internet Society blog about the history of the term “multistakeholder.” 1 Reading his paper triggered an idea that an article reflecting on the historical context for security terms at ICANN may help provide a basic understanding for how we use these terms and how these uses may differ from others in the ecosystem. If you are interested in the historical perspective, see the inset at the end of the article [click here].
This post focuses on the terms:
- Security – providing the capacity to protect Internet unique identifiers and prevent misuse
- Stability – the capacity to ensure that the system operates as expected, and that users of the unique identifiers have confidence that the system operates as expected.
- Resiliency – the capacity of the unique identifier system to effectively withstand/tolerate/survive malicious attacks and other disruptive events without disruption or cessation of service.
At ICANN “providing capacity” is a particularly important function of the Security Team: we provide expertise and contribute resources to assist, educate, train others in the Internet ecosystem to protect unique identifiers and share practices for preventing their misuse. This is done through Security’s technical engagement function.
A key part of ICANN’s Security role is focused on operational integrity and the mitigation of threats. ICANN has responsibilities for maintaining the security (“safe operation”) of L-root, the DNSSEC key signing functions, IANA functions, new gTLD operations, Time Zone Database Management, and organizational functions such as Finance, Personnel, Facilities and Meetings. This role is proactive toward minimizing risk to these operational functions, including detection and mitigation of threats across these and other areas where identifiers are put at risk.
A related element to Security is the concept of affording grounds for confidence. This element has been incorporated into our definition for stability. Stability relates to consistency, from a technical standpoint with name servers and data, between delegations and the appropriate zone in the name space. Maintaining stability was and remains an important part of ICANN’s mission.
The definitions of resiliency and resilience in the ICANN context relate to the original design objectives of the Internet protocols, i.e., to be adaptive to change and resilient to failure.
Resiliency relates to the overall ecosystem and its “ability to maintain its structure and function over time in the face of external stress.” This is a concept adapted from the discipline of ecological economics. The Stockholm Resilience Centre has a good overview of the concept of resilience 2. A resilient DNS and unique identifier system is one that will help support a healthy and sustainable Internet ecosystem.
Examples of programs to support resilience of the unique identifier system are registrar data escrow and emergency backend registry operators. Resiliency includes continuity and contingency testing and exercises.
ICANN is a signatory to the World Economic Forum’s Principles for Cyber Resilience 3 (pdf). The WEF Principles acknowledge that cyber resilience requires trusted dialogue and collaboration between parties in the Internet ecosystem.
Coordination and Collaboration
ICANN’s coordination and collaboration functions are foundational and relate to ensuring interoperability and preserving the security, stability and resiliency of the Internet’s unique identifier system. ICANN performs a coordinating role for Internet stakeholders, inclusive of governments and private industry, but with an independent governance structure. This function is non-regulatory, providing a distinction from those functions appropriately handled by governments and law enforcement.
Coordination is the heart of allocation processes for the Internet’s unique identifiers, technical engagement and policy making associated with the Internet’s unique identifiers. Coordination among and between different parties and different community functions helps to ensure that decisions related to technical functions are made in the public interest in a clear, fair, accountable and transparent manner.
An example is the coordinated disclosure guidelines published in March 2013. The guidelines define the role ICANN will perform in circumstances where vulnerabilities are reported and explain how a party should disclose information on a vulnerability discovered in a system or network operated by ICANN.
Collaboration is related to coordination but a separate concept. It is often defined as one who works in conjunction with another or others; especially in literary, artistic or scientific work 4. The original Memorandum of Understanding with the US Department of Commerce used “collaborate” to refer to ICANN and the Department of Commerce working together to ensure the functions and procedures for transition of the coordination functions for the Internet’s unique identifiers to ICANN. In the past 15 years, this coordination function has grown to include the broad range of stakeholders in the Internet ecosystem.
Collaboration relates to the activities and ways that ICANN participates as peers with others in the Internet ecosystem as well. For example, ICANN Security team members regularly participate in events such as the Internet Governance Forum and regional IGFs, the annual IISI security forum in Garmisch-Partenkirchen, Germany, at the Interpol Underground Economy Conference, Forum of Incident Response Security Teams, and other events. This also relates to ICANN’s involvement in response to Conficker 5 and other malicious attacks against the DNS.
We hope this provides a common understanding for how these terms are used in ICANN security, and we look forward to continuing dialogue with the Internet community in support of these functions.
The Security terms in this blog post predate the formation of ICANN, and have been associated with the early days of computing to the advent of networking. Computer and information security was identified as a concern with the creation of the ARPANET. As early as the late 1960s, security was viewed in terms of protecting information in resource-sharing systems among a number of simultaneous users 6.
The need for coordination relates to uniqueness of the assignment of identifiers (see the development of the concept of Domain Names 7 and updated through subsequent RFCs).
Evolving from the ARPANET and academic network to the set of functions coordinated by Jon Postel as the Internet Assigned Numbers Authority, the early Internet technical community recognized the need for an organization with the responsibility for gathering and registering information about networks to which identifiers have been assigned and for the Internet to become available for global use 8.
The terms stability and coordination were key principles in the 1998 US Department of Commerce Statement of Policy on the Management of Internet Names and Addresses, (commonly referred to as the White Paper), which recognized that global commercial importance of the Internet necessitated “operation of the DNS and operation of the authoritative root server system should be secure, stable and robust”. 9
The White Paper also describes Coordination as the set of functions to be performed to ensure that the Internet runs smoothly. Coordination was viewed as a mechanism for preserving the stability of the Internet, and also as a process that would be flexible to meet the changing needs of the Internet and global Internet users.
The stability principle was described in connection with private sector coordination “without disruption to the functioning of the DNS” 10.
Security, stability and coordination are reflected in the Bylaws of ICANN as part of the Mission and Core Values, and were adopted into the Affirmation of Commitments.
RFC 1591 published by Jon Postel in March 1994 to describe the Domain Name System’s structure and the delegation for top-level domains, uses the term resilience in describing the duties of a TLD manager. These include “responding to requests in a timely manner, and operating the database with accuracy, robustness and resilience.” 11
There are limited references to resilience between 1999-2008. In November 2001, Bruce Schneier delivered a keynote at the ICANN Meeting devoted to security and stability of the Internet Naming and Address Allocation Systems focused on “Resilient Security”. In 2003, resiliency appeared in the 8th status report to the US Department of Commerce related to an SSAC study of “an evaluation of the redundancy and resiliency of the major domain name servers to withstand distributed denial of service attacks.” 12.
In 2008, ICANN’s Security team was formed, and resiliency became a key term for ICANN in association with security and stability. For more information, ICANN Security team documents can be found in the Security document archive 13.
3 World Economic Forum’s Principles for Cyber Resilience, http://www3.weforum.org/docs/WEF_IT_PathwaysToGlobalCyberResilience_Report_2012.pdf [PDF, 2.09 MB]
5 http://www.icann.org/en/about/staff/security/conficker-summary-review-07may10-en.pdf [PDF, 386 KB]
6 Security Controls for Computer Systems, RAND Report R-609, 1970, http://www.rand.org/pubs/reports/R609-1/index2.html
7 RFC 1034, http://www.ietf.org/rfc/rfc1034.txt, as implemented in RFC 1035, http://www.ietf.org/rfc/rfc1035.txt
8 RFC 1174, http://tools.ietf.org/html/rfc1174
9 1998 US Department of Commerce Statement of Policy on the Management of Internet Names and Addresses, 63 Fed. Reg. 31741 (commonly referred to as the White Paper, see http://www.icann.org/en/about/agreements/white-paper)
10 Memorandum of Understanding with the US Department of Commerce, http://www.icann.org/en/about/agreements/mou-jpa/icann-mou-25nov98-en.htm)
11 RFC 1591, http://www.ietf.org/rfc/rfc1591.txt