Second Security, Stability, and Resiliency Review: Difference between revisions
| (6 intermediate revisions by 2 users not shown) | |||
| Line 134: | Line 134: | ||
|- | |- | ||
| Rejected b/c the Board cannot approve the recommendation in full | | Rejected b/c the Board cannot approve the recommendation in full | ||
| 8.1: ICANN Org should commission a negotiating team that includes abuse and security experts to represent the interests of noncontracted parties during renegotiation of agreements with contracted parties | | 8.1: ICANN Org should commission a negotiating team that includes abuse and security experts to represent the interests of noncontracted parties during the renegotiation of agreements with contracted parties | ||
| That's not how ICANN's contracts work. Although the community has expressed concerns regarding how agreements are negotiated & renegotiated, ICANN org represents the global public interest in its contract negotiations, and not a particular group of stakeholders. Also impossible under the current [[Registry Agreement]] and [[Registrar Accreditation Agreement]]<br /> | | That's not how ICANN's contracts work. Although the community has expressed concerns regarding how agreements are negotiated & renegotiated, ICANN org represents the global public interest in its contract negotiations, and not a particular group of stakeholders. Also impossible under the current [[Registry Agreement]] and [[Registrar Accreditation Agreement]]<br /> | ||
| Rejected | | Rejected | ||
| Line 163: | Line 163: | ||
| Rejected | | Rejected | ||
|- | |- | ||
| | | Approved<br /> | ||
| 5.4: 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. | | 5.4: 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. | ||
| Too many unanswered questions and details regarding this recommendation make it impossible to approve as written.<br /> | | Too many unanswered questions and details regarding this recommendation make it impossible to approve as written.<br /> | ||
| ICANN | | directed ICANN President and CEO to discuss with any firm producing an audit for ICANN to implement appropriate additional disclosures within the publicly available reports.<ref>[https://www.icann.org/en/system/files/files/ssr2-scorecard-01may22-en.pdf Scorecard: SSR2 Pending Recommendations - Board Action 1 May 2022]</ref><br /> | ||
|- | |- | ||
| | | Rejected<br /> | ||
| 19.1 - 19.2: ICANN org should complete the development of a suite for DNS resolver behavior testing, and ensure that that capability to conduct functional testing of different configurations and software versions is implemented and maintained | | 19.1 - 19.2: ICANN org should complete the development of a suite for DNS resolver behavior testing, and ensure that that capability to conduct functional testing of different configurations and software versions is implemented and maintained | ||
| The final report mentions three testing suites: a "DNS testbed," a "regression test suite," and a "suite for DNS resolver testing." Any of these may be feasible, but we need clarity as to which is being recommended. The board notes also that an always-on testbed of any type would need to be properly budgeted and resourced<br /> | | The final report mentions three testing suites: a "DNS testbed," a "regression test suite," and a "suite for DNS resolver testing." Any of these may be feasible, but we need clarity as to which is being recommended. The board notes also that an always-on testbed of any type would need to be properly budgeted and resourced<br /> | ||
| ICANN | | to maintain the existing ICANN testbed in perpetuity for public use, to broaden ICANN's testbed, to implement functional testing of different configurations and software versions go beyond ICANN's remit<ref>[https://www.icann.org/en/system/files/files/ssr2-scorecard-01may22-en.pdf Scorecard: SSR2 Pending Recommendations - Board Action 1 May 2022]</ref><br /> | ||
|- | |- | ||
| Pending, likely to be approved after receipt of additional information | | Pending, likely to be approved after receipt of additional information | ||
| Line 290: | Line 290: | ||
In December 2021, ICANN org submitted its first series of clarifying questions to the implementation shepherds listserv.<ref name="decemail">[https://mm.icann.org/pipermail/ssr2-implementation-shepherds/2021-December/000017.html Email to SSR2 Implementation Shepherds: 'Pending/Likely to Be Approved' Recommendations - Clarifying Questions], December 7, 2021</ref> The questions dealt with the recommendations in the "Pending - Likely to be Approved" category, and sought clarification based on the scorecard assessments and board rationales for those recommendations.<ref>[https://mm.icann.org/pipermail/ssr2-implementation-shepherds/attachments/20211207/489d314e/SSR2ISESQuestions-Group1-Likelytobeapproved-Final-0001.pdf SSR2 Questions - Group 1: Pending/Likely to be Approved], December 7, 2021 (PDF)</ref> ICANN org hoped to receive answers to these questions by January 14, 2022<ref name="decemail" /> | In December 2021, ICANN org submitted its first series of clarifying questions to the implementation shepherds listserv.<ref name="decemail">[https://mm.icann.org/pipermail/ssr2-implementation-shepherds/2021-December/000017.html Email to SSR2 Implementation Shepherds: 'Pending/Likely to Be Approved' Recommendations - Clarifying Questions], December 7, 2021</ref> The questions dealt with the recommendations in the "Pending - Likely to be Approved" category, and sought clarification based on the scorecard assessments and board rationales for those recommendations.<ref>[https://mm.icann.org/pipermail/ssr2-implementation-shepherds/attachments/20211207/489d314e/SSR2ISESQuestions-Group1-Likelytobeapproved-Final-0001.pdf SSR2 Questions - Group 1: Pending/Likely to be Approved], December 7, 2021 (PDF)</ref> ICANN org hoped to receive answers to these questions by January 14, 2022<ref name="decemail" /> | ||
==Implementation== | |||
By April 2023, the [[ICANN Board]] had deemed 11 of the 23 recommendations complete based on whether the recommendation was fully or partially implemented, the level of community input and involvement, and whether more work was needed. Recommendations 3.2 and 3.3 on budgeting and transparency were complete based on the existing transparency and public comment framework for the organization's planning and budgeting cycle. Recommendation 4.1 on risk management was implemented with ICANN Org’s risk management policies, plans, and programs. Recommendations 7.1, 7.2, and 7.3 on business continuity and disaster recovery plans were considered implemented with ICANN org's existing approach and policies. Recommendation 9.1 was complete as its success measures align with [[Contractual Compliance]]’s existing work. To implement Recommendation 16.1, which required cross-referencing ICANN org to streamline information and improve access to privacy and data stewardship, ICANN org reviewed www.icann.org for updates and internal alignments needed. | |||
Recommendation 24.1 was complete with the inclusion of provisions in ICANN org's agreements with [[EBERO]] service providers allowing for annual EBERO readiness exercises. Recommendation 24.2 was completed when ICANN Org linked to the Common Transition Process Manual on ICANN org’s EBERO webpage.<ref>[https://www.icann.org/en/system/files/files/specific-reviews-q1-2023-report-31mar23-en.pdf Q1 2023 Specific Reviews Report, ICANN Files]</ref> | |||
[[ICANN Organization]] has made progress on recommendations about reviewing implementation, compliance with security standards for external service providers, publishing contingency and continuity plans, updating information on DNS security threats, and developing a Time-Based One-Time Password and new RZMS security measures for authentication and authorization of requested changes, such as Multi-Factor Authentication (MFA) and encrypted email (Rec 21.1). Specifically, ICANN Org is creating a new webpage for information transparency (ITI) featuring statistics and metrics that reflect the operational status of services (root zone, gTLD, IANA registries; Rec 22.1). ICANN org is engaging subject matter experts to review SSR1 implementation and execute a new plan of action (Rec 1.1) and will include a compliance clause with security standards in its one-year-based contracts with external service-provider parties (Rec 5.3). There is now a project team to publish a summary of the Contingency and Continuity Plan and the DR plan (Rec 7.5). The [[DNS Security Threat Mitigation Program]] page and the ICANN Acronyms and Terms page now link to key terms, and the webpage will include comprehensive information on abuse-related obligations within the RAA and RA by Q4 2023 (Rec 10.1). The work on five recommendations has not started yet, two of which depend on other recommendations' completion. Recs 5.1 and 5.2 will be complete when ICANN org migrates to the [[NIST#Cybersecurity Framework|NIST Cybersecurity Framework]].<ref>[https://www.icann.org/en/system/files/files/specific-reviews-q1-2023-report-31mar23-en.pdf Q1 2023 Specific Reviews Report, ICANN Files]</ref> | |||
==References== | ==References== | ||
| Line 296: | Line 302: | ||
[[Category:Specific Reviews]] | [[Category:Specific Reviews]] | ||
[[Category:Featured]] | |||