Skip to main content

CIIO Perspectives: ICANN’s Incident Response Protocol

As part of our mission to provide secure and stable digital services to the community, the ICANN Information Technology (IT) team takes information security incidents very seriously and thwarts these threats through a variety of measures. We know it's impossible to prevent all security incidents; a decade of breaches across all sectors has proven this. However, I assure you we have robust measures in place to proactively mitigate or swiftly manage such incidents.

Let me tell you a bit more about these processes.

We have a dedicated team in place to manage all security incidents. The ICANN CIRT (Computer Incident Response Team) is comprised of IT security personnel, IT operations engineers and representatives from ICANN's legal and communications advisors, as well as impacted business teams as needed. Once an incident is declared, this CIRT team moves swiftly to respond and manage ICANN's response, following a detailed action plan including: declaring the incident, assembling the team, containing the incident, mitigating the impacts, restoring operations, communicating about it, archiving records and identifying lessons learnt in the cycle.

In some cases, the ICANN CIRT may contract with outside experts to add technical or legal expertise. If, for example, a concentrated forensic effort is required to determine the extent or impact of an incident, outside forensics experts will be brought in to assist. If an incident involves the exposure of personally identifiable information (PII) or other types of sensitive data belonging to the ICANN community, our default and documented action is to call in external security resources or consultants to assist in handling the incident and validate the overall approach taken by ICANN.

A vitally important process in the management of an incident is communication with ICANN stakeholders: staff, Board and community, as well as any impacted individuals. We are guided by three primary practices: (1) the Board governs the corporation, therefore communication with the Board starts very soon after an incident is declared; (2) the ICANN staff and community are notified of an incident as soon as possible, with internal and external notifications coordinated by our Communications team; (3) our communications with the community regarding incidents are guided by ICANN's commitments to openness and transparency. ICANN typically provides more information regarding internal incidents than required by regulatory or statutory requirements, and typically more than what most corporations disclose under similar circumstances.

ICANN IT is committed to continuous improvements. As such, tabletop CIRT exercises are designed to enforce the lessons learned from prior incidents. The CIRT plan is periodically reviewed and re-written to make it more flexible and effective, and we also seek input and critique from community groups such as the Security and Stability Advisory Committee (SSAC) and independent consultants who benchmark our processes using industry accepted standards and guides (such as NIST SP800-61 and the CIS Critical Security Controls). Team members work on improving their skills and capabilities through training, certification and by sharing information with other CIRT teams worldwide as a member of the Forum of Incident Response and Security Teams ( Last but not least, all ICANN staff receives frequent security awareness training to improve their ability to help detect, avoid and respond to incidents.

The CIRT plan and processes are part of ICANN's overall Enterprise Risk Management efforts, which are overseen by the ICANN Board Risk Committee. In high-impact incidents, recovery from a data breach is no longer simply a technical or computing problem. ICANN's CIRT process focuses on how to protect the interests of all its stakeholders, should their data be exposed to unauthorized access.

Bolstering our security efforts is not a destination, but rather a never-ending journey. We are continually improving our efforts and I wish to thank those who shared their expertise and feedback to this plan thus far.


    Domain Name System
    Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as"""" is not an IDN."