Versions Compared

Old Version 5

changes.mady.by.user Negar Conrad

Saved on

compared with

New Version Current

changes.mady.by.user Alice Jansen

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.


Image Removed

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,

    SSR2 Implementation - Status of 24 Board Approved Recommendations

    Complete 

    17 Recommendations: 3.2, 3.3, 5.1, 5.2, 5.3,

    7.1, 7.2, 7.3,

    7.

    4

    , 7

    .

    5

    1, 9.

    2

    1,

    9.3,

    11.1,

    12

    10.1,

    12

    13.2,

    12

    16.

    3

    1,

    12

    24.

    4, 13.

    1,

    13

    23.2,

    14.2, 16.2, 16.3, 17.1, 18

    24.2

    In progress  

    4 Recommendations 1.1,

    18

    5.

    2

    4,

    18

    7.

    3

    5,

    19

    21.1,

    19

    22.

    2, 20.1, 20

    1

    Not started  

    Recommendations 22.2,

    24.1) into pending status.

    ICANN Org is working on the pending recommendations in groups: 1) pending/likely to be approved, 2) pending/likely to be rejected, and 3) pending/additional clarification and information is needed.

    ICANN Org has initiated the Q&A phase on group 1 recommendations, pending/likely to be approved, with the SSR2 Implementation Shepherds, while continuing to work on other pending category recommendations in parallel. 

    The table below includes information relating to the implementation of Board approved recommendations.

    23.1


    Quarterly Updates


    Status
    colourGrey
    titleJUn 24

    Image Added


    Progress by Quarter


    Status
    colourGrey
    titleApR 2022

    Status
    titleJUN 2022

    Status
    colourGrey
    titleSEPT 22

    Status
    colourGrey
    titleDEC 22

    Q4 2022

    Status
    colourGrey
    titleMar 23

    Q1 2023

    Status
    colourGrey
    titleJUNE 23

    Q2 2023

    Status
    colourGrey
    titleSEPT 23

    Q3 2023

    Status
    colourGrey
    titleDEC 23

    Q4 2023

    Status
    colourGrey
    titleMAR 24

    Q1 2024

    Status
    colourGrey
    titleJUn 24

    Q2 2024

    Complete22210111213131617
    In progress0566788865
    Not started12767533322



    Rec #

    Implementation Status

    Priority level assigned by the community 

    (where P1 corresponds to the highest priority and P4 to the lowest - see here for more information)

    Description

    Notes

    1.1

    In progress

    P4

    The ICANN Board and ICANN org

    Rec #

    Status

    Description

    Implementation Update as of 17 February 2022

    1.1

    Not started

    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
    3.
    1

    Completed

    2CompleteN/AThe 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.3CompleteN/AThe 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

    ICANN org should

    continue centralizing its risk management and clearly articulate

    its Security Risk

    its Security Risk Management Framework and ensure that it aligns strategically with the organization’s requirements and objectives.

     ICANN org

     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

    See implementation documentation.

    5.1

    Not started

    I

    Complete

    N/A

    ICANN

    CANN

    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

     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

    See implementation documentation.

    5.2

    Not started

    Complete

    N/A

    Based on the ISMS,

     ICANN org

     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

    into ICANN org’s security and risk management strategies.

    See implementation documentation.

    5.3Complete P2ICANN 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.See implementation documentation.

    5.4

    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

    7.1CompleteN/AICANN 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.See implementation documentation.
    7.2CompleteN/AICANN 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).See implementation documentation.
    7.3CompleteN/AICANN 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.See implementation documentation.
    7.5In progressP4ICANN 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

    The ICANN Board

    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.

    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.

    See implementation documentation.

    10.1

    Complete

    Not started

    ICANN org

    P1

    ICANN org should post a web page that includes their working definition

    of DNS abuse

    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

    threats ICANN org currently considers within its remit to address through contractual and compliance mechanisms, as well as

    those ICANN org

    those ICANN org understands to be outside its remit.

    If ICANN org

    If ICANN org uses other similar terminology—e.g., security threat, malicious

    conduct—ICANN org

    conduct—ICANN org should include both its working definition of those terms and precisely

    how ICANN org

    how ICANN org is distinguishing those terms

    from DNS abuse

    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

     ICANN org should update this page annually, date the latest version, and link to older versions with associated dates of publication.

    See implementation documentation. 

    11.1CompleteN/AThe ICANN community and ICANN org should take steps to ensure that access to 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


    See implementation documentation. 

    16.1

    Complete

    Not started

    P3

    ICANN org

    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

    See implementation documentation. 

    21.1

    Not started

    ICANN org

    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

    offer TLD operators the opportunity to take advantage of those security measures, particularly MFA and encrypted email.

    N/A

    22.1

    Not started

    In progress

    P4

    For each service

    that ICANN org

    that ICANN org has authoritative purview over, including root-zone

    and gTLD

    and gTLD-related services as well

    as IANA registries, ICANN org

    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

     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

    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

    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

    the DNS.

    N/A

    23.2

    Not started

    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. 

    24.1CompleteN/AICANN 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

    Not started

    In progress

    P4

    ICANN org

    ICANN org

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

    the EBERO website

    the EBERO website.

    N/A

    See implementation documentation.