Page History
SSR2 Implementation - Status of 14 Recommendations | ||
Complete (2 recs.) | Recommendations 4.1, 9.1 | |
In progress (0 recs.) | n/a | |
| Not started (12 recs.) | Recommendations 1.1, 5.1, 5.2, 5.4, 10.1, 16.1, 21.1, 22.1, 22.2, 23.1, 23.2, 24.2 | |
N E W S / U P D A T E S | |
|---|---|
| News | |
|
Rec # | Implementation Status | Prioritization Status | Description | Implementation Update as of 14 April |
The 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: The Board’s action on subject to prioritization, risk assessment and mitigation, costing, and implementation considerations.
- Approve 13 recommendations subject to prioritization, risk assessment and mitigation, costing, and implementation considerations, as noted below.
- 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) into pending status.
The table below includes information relating to the implementation of Board approved recommendations.
Rec #
Status
Description
2022 | |
1.1 | Not started |
Pending prioritization | 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 |
4.1 |
Completed
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. |
ICANN org already has policies, plans and programs in place through which Recommendation 4.1 has already been implemented, and the Board continues its oversight role |
over ICANN org's risk management efforts. The Board is supportive |
of ICANN org in continuing the risk management activities that it is already carrying out. | |||
5.1 | Not started | 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 | Not started | 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 |
9.1
Complete
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.
| 5.4 | Not started | Pending prioritization | 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. | |
9.1 | Complete | N/A | The Contractual Compliance operations that ICANN org |
has in place already met the SSR2 Review Team’s defined measures of success for Recommendation 9.1. | |
10.1 | Not started |
Pending prioritization | 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. | N/A |
16.1 | Not started |
Pending prioritization | 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. | N/A | |
21.1 | Not started |
Pending prioritization | 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 | Not started | Pending prioritization | 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 |
Pending prioritization | 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 | Pending prioritization | 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 | Not started | Pending prioritization | 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.2 | Not started |
Pending prioritization | ICANN org should make the Common Transition Process Manual easier to find by providing links on |
the EBERO website. | N/A |
