Security, Stability, and Resiliency Review (SSR)
Under the Bylaws (Section 4.6(c)), ICANN is committed to a periodic review of ICANN’s execution of its commitment to enhance the operational stability, reliability, resiliency, security, and global interoperability of the systems and processes that are affected by the Internet’s system of unique identifiers that ICANN coordinates.
The ICANN organization (org) has conducted two iterations of the Security, Stability, and Resiliency (SSR) Review and is now in the process of implementing SSR2 recommendations the Board approved in July 2021, May 2022, and November 2022. For more information on SSR2 Review work, see here.
The Board took action on 10 March 2022 to defer the third Security, Stability, and Resiliency (SSR3) Review. See the Board resolution here.
Click here to learn more about ICANN Reviews.
Implementation of SSR2 Recommendations
On 22 July 2021, the Board took action on the 63 SSR2 recommendations as issued in the SSR2 Review Team Final Report. As noted in its resolution and specified in the Scorecard titled "Final SSR2 Review Team Recommendations – Board Action” the Board resolved to:
- Approve 13 recommendations (1.1, 4.1, 5.1, 5.2, 9.1, 10.1, 16.1, 21.1, 22.1, 22.2, 23.1, 23.2 and 24.2), subject to prioritization;
- Reject 16 recommendations (2.1, 2.2, 2.3, 2.4, 4.2, 8.1, 9.4, 10.2, 10.3, 14.1, 14.3, 14.4, 14.5, 15.1, 15.2, 17.2);
- Place 34 recommendations (3.1, 3.2, 3.3, 4.3, 5.3, 5.4, 6.1, 6.2, 7.1, 7.2, 7.3, 7.4, 7.5, 9.2, 9.3, 11.1, 12.1, 12.2, 12.3, 12.4, 13.1, 13.2, 14.2, 16.2, 16.3, 17.1, 18.1, 18.2, 18.3, 19.1, 19.2, 20.1, 20.2, 24.1) in pending status.
On 1 May 2022 the Board took action on three pending recommendations, as specified within the "Scorecard: SSR2 Pending Recommendations-Board Action 1 May 2022." The Board resolved to:
- Approve 1 recommendation (5.4) subject to prioritization;
- Reject 2 recommendations (19.1,19.2).
On 16 November 2022, the Board took action on 21 pending recommendations, as specified within the 16 November 2022 Scorecard. The Board resolved to:
- Approve 2 recommendations (5.3 and 7.5) subject to prioritization;
- Approve 7 recommendations (3.2, 3.3, 7.1, 7.2, 7.3, 11.1, 24.1) as fully implemented;
- Reject 12 recommendations 3.1, 4.3, 6.1, 6.2, 7.4, 16.2, 16.3, 18.1, 18.2, 18.3, 20.1, 20.2.
On 10 September 2023, the Board took action on nine SSR2 pending recommendations, as specified with the Board Action/Rationale on & ICANN org Assessment of Competition, Consumer Trust, Consumer Choice Review (CCT) Pending Recommendations 14 and 15, and Second Security, Stability and Resiliency of DNS Review (SSR2) Recommendations 9.2, 9.3, 12.1, 12.2, 12.3, 12.4, 13.1, 13.2 and 14.2 scorecard. The Board resolved to:
- Approve one SSR2 recommendation (13.2) as fully implemented;
- Reject eight SSR2 recommendations (9.2, 9.3, 12.1, 12.2, 12.3, 12.4, 13.1, 14.2).
Currently, there is one SSR2 recommendation (17.1) in pending status.
Prioritization of Board approved recommendations considered eligible for prioritization was completed in May 2022, October 2022 and May 2023.
The table below provides information relating to the implementation of Board approved recommendations. Implementation status of recommendations should be understood as follows:
- Complete: a recommendation's intent which is considered implemented or addressed and for which implementation documentation is available.
- In progress: a recommendation for which work has started to address deliverables identified during the implementation design. Implementation design is the preparatory phase for implementation during which a cross-functional project team develops guidelines that include deliverables for implementation, costing out resources, risk assessment, as well as an inventory of existing work etc.
- Not started: Work has not started due to, for instance, a dependency on another recommendation and/or process.
Where available, the priority level assigned by the community (where P1 corresponds to the highest priority and P4 to the lowest) is inserted in the table below. For more information on prioritization, see here.
Rec # |
Implementation Status |
Priority Level Assigned by the Community |
Description |
Notes |
1.1 |
In progress |
P4 |
The ICANN Board and ICANN org should perform a further comprehensive review of the SSR1 recommendations and execute a new plan to complete the implementation of the SSR1 Recommendations (see Appendix D: Findings Related to SSR1 Recommendations). |
N/A |
3.2 | Complete | N/A |
The ICANN Board and ICANN org should ensure specific budget items relating to ICANN org’s performance of SSR related functions are linked to specific ICANN Strategic Plan goals and objectives. ICANN org should implement those mechanisms through a consistent, detailed, annual budgeting and reporting process. |
See implementation documentation.
|
3.3 | Complete | N/A |
The ICANN Board and ICANN org should create, publish, and request public comment on detailed reports regarding the costs and SSR-related budgeting as part of the strategic planning cycle. |
See implementation documentation.
|
4.1 |
Complete |
N/A |
ICANN org should continue centralizing its risk management and clearly articulate its Security Risk Management Framework and ensure that it aligns strategically with the organization's requirements and objectives. ICANN org should describe relevant measures of success and how to assess them. |
|
5.1 |
In progress |
Not eligible for prioritization |
ICANN org should implement an ISMS and be audited and certified by a third party along the lines of industry security standards (e.g., ITIL, ISO 27000 family, SSAE-18) for its operational responsibilities. The plan should include a road map and milestone dates for obtaining certifications and noting areas that will be the target of continuous improvement. |
N/A |
5.2 |
In progress |
Not eligible for prioritization |
Based on the ISMS, ICANN org should put together a plan for certifications and training requirements for roles in the organization, track completion rates, provide rationale for their choices, and document how the certifications fit into ICANN org's security and risk management strategies. |
N/A |
5.3 | In progress | P2 |
ICANN org should require external parties that provide services to ICANN org to be compliant with relevant security standards and document their due diligence regarding vendors and service providers. |
N/A |
5.4 |
Not started |
P4 |
ICANN org should reach out to the community and beyond with clear reports demonstrating what ICANN org is doing and achieving in the security space. These reports would be most beneficial if they provided information describing how ICANN org follows best practices and mature, continually-improving processes to manage risk, security, and vulnerabilities. |
N/A |
7.1 |
Complete | N/A |
ICANN org should establish a Business Continuity Plan for all the systems owned by or under the ICANN org purview, based on ISO 22301 "Business Continuity Management," identifying acceptable BC and DR timelines. |
Implementation documentation in progress. |
7.2 | Complete | N/A |
ICANN org should ensure that the DR plan for Public Technical Identifiers (PTI) operations (i.e., IANA functions) includes all relevant systems that contribute to the security and stability of the DNS and also includes Root Zone Management and is in line with ISO 27031. ICANN org should develop this plan in close cooperation with the Root Server System Advisory Committee (RSSAC) and the Root Server Operators (RSO). |
Implementation documentation in progress. |
7.3 | Complete | N/A |
ICANN org should also establish a DR Plan for all the systems owned by or under the ICANN org purview, again in line with ISO 27031. |
Implementation documentation in progress. |
7.5 | In progress | P4 |
ICANN org should publish a summary of their overall BC and DR plans and procedures. Doing so would improve transparency and trustworthiness beyond addressing ICANN org’s strategic goals and objectives. ICANN org should engage an external auditor to verify compliance with these BC and DR plans. |
N/A |
9.1 |
Complete |
N/A |
The ICANN Board should direct the compliance team to monitor and strictly enforce the compliance of contracted parties to current and future SSR and abuse related obligations in contracts, baseline agreements, temporary specifications, and community policies. |
|
10.1 |
Complete |
P1 |
ICANN org should post a web page that includes their working definition of DNS abuse, i.e., what it uses for projects, documents, and contracts. The definition should explicitly note what types of security threats ICANN org currently considers within its remit to address through contractual and compliance mechanisms, as well as those ICANN org understands to be outside its remit. If ICANN org uses other similar terminology -- e.g., security threat, malicious conduct -- ICANN org should include both its working definition of those terms and precisely how ICANN org is distinguishing those terms from DNS abuse. This page should include links to excerpts of all current abuse-related obligations in contracts with contracted parties, including any procedures and protocols for responding to abuse. ICANN org should update this page annually, date the latest version, and link to older versions with associated dates of publication. |
|
11.1 | Complete | N/A |
The ICANN community and ICANN org should take steps to ensure that access to Centralized Zone Data Service (CZDS) data is available, in a timely manner and without unnecessary hurdles to requesters, e.g., lack of auto-renewal of access credentials. |
See implementation documentation. |
13.2 | Complete | N/A |
ICANN org should publish the number of complaints made in a form that allows independent third parties to analyze the types of complaints on the DNS. |
See implementation documentation. |
16.1 |
Complete |
P3 |
ICANN org should provide consistent cross-references across their website to provide cohesive and easy-to-find information on all actions -- past, present, and planned -- taken on the topic of privacy and data stewardship, with particular attention to the information around the RDS. |
See implementation documentation. |
21.1 |
In progress |
P1 |
ICANN org and PTI operations should accelerate the implementation of new RZMS security measures regarding the authentication and authorization of requested changes and offer TLD operators the opportunity to take advantage of those security measures, particularly MFA and encrypted email. |
N/A |
22.1 |
In progress |
P4 |
For each service that ICANN org has authoritative purview over, including root-zone and gTLD-related services as well as IANA registries, ICANN org should create a list of statistics and metrics that reflect the operational status (such as availability and responsiveness) of that service, and publish a directory of these services, data sets, and metrics on a single page on the icann.org web site, such as under the Open Data Platform. ICANN org should produce measurements for each of these services as summaries over both the previous year and longitudinally (to illustrate baseline behavior). |
N/A |
22.2 |
Not started |
P4 |
ICANN org should request community feedback annually on the measurements. That feedback should be considered, publicly summarized after each report, and incorporated into follow-on reports. The data and associated methodologies used to measure these reports' results should be archived and made publicly available to foster reproducibility. |
N/A |
23.1 |
Not started |
P3 |
PTI operations should update the DNSSEC Practice Statement (DPS) to allow the transition from one digital signature algorithm to another, including an anticipated transition from the RSA digital signature algorithm to other algorithms or to future post-quantum algorithms, which provide the same or greater security and preserve or improve the resilience of the DNS. |
N/A |
23.2 |
In progress |
P1 |
As a root DNSKEY algorithm rollover is a very complex and sensitive process, PTI operations should work with other root zone partners and the global community to develop a consensus plan for future root DNSKEY algorithm rollovers, taking into consideration the lessons learned from the first root KSK rollover in 2018. |
N/A |
24.1 | Complete | N/A |
ICANN org should coordinate end-to-end testing of the full EBERO process at predetermined intervals (at least annually) using a test plan that includes datasets used for testing, progression states, and deadlines, and is coordinated with the ICANN contracted parties in advance to ensure that all exception legs are exercised, and publish the results. |
See implementation documentation. |
24.2 |
Complete |
P4 |
ICANN org should make the Common Transition Process Manual easier to find by providing links on the EBERO website. |
See implementation documentation. |
Quarterly Updates on Specific Reviews
- ICANN Specific Reviews Q3 2023 Quarterly Report (30 September 2023)
- ICANN Specific Reviews Q2 2023 Quarterly Report (30 June 2023)
- ICANN Specific Reviews Q1 2023 Quarterly Report (31 March 2023)
- ICANN Specific Reviews Q4 2022 Quarterly Report (31 December 2022)
Review Progress and Milestones
The graphic below illustrates phases and status of the review - a indicates that all activities within a given phase have been completed. The chart that follows the graphic provides further details of key activities and milestones within each phase – you can view these details by clicking on each of the phases in the graphic. The table also contains links to relevant documents.
Phase | Activity | Description | Start Date | Documents |
---|---|---|---|---|
Conduct Review | Call for Volunteers | Public announcement inviting volunteers to submit application | 30 Jun 2016 | |
Call for Volunteers Extension | Application Extended for the Second Security, Stability and Resiliency (SSR-2) Review Team | 12 Aug 2016 | ||
Review Team Announced | Selection of the Second Security, Stability, and Resiliency of the DNS Review Team Members Announced | 14 Feb 2017 | ||
Appointment of Board Designee | Board appoints a member to the Second SSR Review Team | 3 Feb 2017 | ||
Second Security, Stability, and Resiliency of the DNS Review (SSR2) Restarts | The Second Review of the Security, Stability, and Resiliency of the Domain Name System (SSR2) formally restarted 7 June 2018 | 7 Jun 2018 | ||
Additional Funding | Board resolution approving additional funding | 7 Nov 2019 | ||
Draft Report | Draft Report for Public Comment | 24 Jan 2020 | ||
Public Comment on Draft Report | Public comment on Second Security, Stability and Resiliency (SSR2) Review Team Draft Report | 24 Jan 2020 | ||
Public Comment Extended | Public Comment Period Extended: SSR2 Review Team Draft Report | 3 Mar 2020 | ||
Final Report Executive Summary | Executive summary of the SSR2 Final Report | 22 Jan 2021 | ||
Final Report | Second Security, Stability, and Resiliency (SSR2) Review Team Final Report | 25 Jan 2021 | ||
Board Action* | Public Comment on Final Report | Final report and recommendations posted for Public Comment | 28 Jan 2021 | |
Board Receipt of the Final Report | Board receipt of the Final Report | 3 Mar 2021 | ||
Board Action on Recommendations | Board resolution taking action on 63 recommendations | 22 Jul 2021 | ||
Board Blog | Board Action and Next Steps on the SSR2 Review | 26 Jul 2021 | ||
Deferral of Third SSR Review | Deferral of the Third Review of Security, Stability and Resiliency of the Domain Name System | 10 May 2022 | ||
Board Action on Recommendations | Board resolution taking action on three pending recommendations | 1 May 2022 | ||
Board Action on Recommendations | Board resolution taking action on 21 pending recommendations | 16 Nov 2022 | ||
Board Action on Recommendations | Board resolution taking action on nine pending recommendations | 10 Sep 2023 |
*Some recommendations are pending Board consideration and/or prioritization. See above for more information.
For information on the first SSR Review, click here: SSR1