Page History

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

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.

See implementation documentation.

Complete

N/A

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.

See implementation documentation.

Complete

N/A

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.

See implementation documentation.

In progress

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

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.

See implementation documentation.

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.

Complete

N/A

See implementation documentation. 

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. 

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

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

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

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

Complete

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.

Implementation documentation in progress. 

In progress

P4

ICANN org

should make the Common Transition Process Manual easier to find by providing links on

the EBERO website.

See implementation documentation.