Second Security, Stability, and Resiliency Review: Difference between revisions
| (13 intermediate revisions by 2 users not shown) | |||
| Line 2: | Line 2: | ||
==Background== | ==Background== | ||
The [[Affirmation of Commitments]], an agreement between ICANN and the [[United States Department of Commerce]], | The [[Affirmation of Commitments]], an agreement between ICANN and the [[United States Department of Commerce]], established ICANN's obligations to perform its duties with specific commitments in mind. All of the commitments bear on public and consumer trust of the organization. ICANN is to perform its functions in a manner that: | ||
*ensures accountability and transparency of decision-making; | *ensures accountability and transparency of decision-making; | ||
*preserves the security, stability, and resiliency of the DNS; | *preserves the security, stability, and resiliency of the DNS; | ||
| Line 42: | Line 42: | ||
Later that month, the SOAC chairs again communicated with the review team, presenting a status update and findings from additional communications and a survey of team members.<ref name="febletter">[https://community.icann.org/display/SSR/Correspondence?preview=/60489949/79434947/20180212%20SOAC%20Chair%20Message%20on%20Status%20of%20SSR2.pdf ICANN.org - SOAC Chairs Message on SSR2 Status], February 12, 2018</ref> As forecast at the Intersessional, the letter noted that survey comments from team members led the SO/AC leadership to conclude that there was "insufficient alignment within the SSR2-RT on many issues ranging from mission/scope to process/leadership."<ref name="febletter" /> To address this misalignment, the SOAC chairs requested that the [[OEC]] provide a neutral facilitator to work with the group to identify common ground and re-orient the goals and expectations of the team.<ref>[https://www.icann.org/en/system/files/correspondence/soac-chairs-to-koubaa-15feb18-en.pdf ICANN.org - SOAC letter to OEC], February 15, 2018</ref> The OEC agreed, and set about working with the SOAC chairs to identify the required skills and experience that the facilitator should have.<ref>[https://www.icann.org/en/system/files/correspondence/koubaa-to-soac-chairs-03mar18-en.pdf Letter from Khaled Koubaa to SOAC Chairs], March 3, 2018</ref> | Later that month, the SOAC chairs again communicated with the review team, presenting a status update and findings from additional communications and a survey of team members.<ref name="febletter">[https://community.icann.org/display/SSR/Correspondence?preview=/60489949/79434947/20180212%20SOAC%20Chair%20Message%20on%20Status%20of%20SSR2.pdf ICANN.org - SOAC Chairs Message on SSR2 Status], February 12, 2018</ref> As forecast at the Intersessional, the letter noted that survey comments from team members led the SO/AC leadership to conclude that there was "insufficient alignment within the SSR2-RT on many issues ranging from mission/scope to process/leadership."<ref name="febletter" /> To address this misalignment, the SOAC chairs requested that the [[OEC]] provide a neutral facilitator to work with the group to identify common ground and re-orient the goals and expectations of the team.<ref>[https://www.icann.org/en/system/files/correspondence/soac-chairs-to-koubaa-15feb18-en.pdf ICANN.org - SOAC letter to OEC], February 15, 2018</ref> The OEC agreed, and set about working with the SOAC chairs to identify the required skills and experience that the facilitator should have.<ref>[https://www.icann.org/en/system/files/correspondence/koubaa-to-soac-chairs-03mar18-en.pdf Letter from Khaled Koubaa to SOAC Chairs], March 3, 2018</ref> | ||
After an RFP process, [[Phil Khoury]] was engaged as facilitator in June 2018.<ref>[https://www.icann.org/en/system/files/correspondence/gurnick-to-soac-chairs-05jun18-en.pdf ICANN.org - OEC letter to SOAC Chairs], June 5, 2018</ref> The review's relaunch was was announced shortly thereafter on June 7, 2018.<ref>[https://www.icann.org/en/announcements/details/second-security-stability-and-resiliency-of-the-dns-review-ssr2-restarts-7-6-2018-en ICANN.org - SSR2 Restarts], June 7, 2018</ref> The | After an RFP process, [[Phil Khoury]] was engaged as facilitator in June 2018.<ref>[https://www.icann.org/en/system/files/correspondence/gurnick-to-soac-chairs-05jun18-en.pdf ICANN.org - OEC letter to SOAC Chairs], June 5, 2018</ref> The review's relaunch was was announced shortly thereafter on June 7, 2018.<ref>[https://www.icann.org/en/announcements/details/second-security-stability-and-resiliency-of-the-dns-review-ssr2-restarts-7-6-2018-en ICANN.org - SSR2 Restarts], June 7, 2018</ref> The culmination of Khoury's involvement came in August 2018, when the review team (with five additional appointed members) met in Washington DC and worked on drafting a new Terms of Reference.<ref>[https://www.icann.org/en/blogs/details/ssr2-review-team-re-starts-on-boards-new-members-updates-terms-of-reference-5-9-2018-en ICANN.org - SSR2 Review Team Restarts]</ref> The agenda and notes from the DC meeting indicate that this was the facilitated resolution of outstanding issues and concerns that the SOAC Chairs had requested.<ref>[https://community.icann.org/pages/viewpage.action?pageId=71603683 SSR2 Workspace - August 2018 Meeting Archive]</ref> Records of Khoury's work with the review team are available largely through the SSR2 listserv archive from his appointment in June 2018 to his sharing of his draft report following the DC meeting.<ref>[https://mm.icann.org/pipermail/ssr2-review/attachments/20180910/ca98b3e3/2018_0910ReportreSSR2toSOACChairs.pdf Draft Facilitator Report to SOAC Chairs - SSR2], September 10, 2018</ref> | ||
The team presented a new Terms of Reference to the Board in September 2018.<ref>[https://community.icann.org/download/attachments/66061139/SSR2-Terms%20of%20Reference-Final%202018-Sep-1%5B2%5D.docx SSR2 Terms of Reference], September 4, 2018</ref> The team followed up with a work plan in November 2018.<ref>[https://mm.icann.org/pipermail/ssr2-review/2018-November/001344.html SSR2 Listserv Archive - SSR2 Team Work Plan], November 14, 2018</ref> The team subsequently updated the board in February 2019 on its status subsequent to another multi-day, face to face meeting in Los Angeles.<ref>[https://mm.icann.org/pipermail/ssr2-review/2019-February/001475.html SSR2 Listserv Archive - Update from the Review Team], February 13, 2019</ref> The board acknowledged receipt of the ToR, work plan, and update report at the end of February.<ref>[https://mm.icann.org/pipermail/ssr2-review/2019-February/001507.html SSR2 Listserv Archive - Message from Board to SSR2], February 28, 2019</ref> | The team presented a new Terms of Reference to the Board in September 2018.<ref>[https://community.icann.org/download/attachments/66061139/SSR2-Terms%20of%20Reference-Final%202018-Sep-1%5B2%5D.docx SSR2 Terms of Reference], September 4, 2018</ref> The team followed up with a work plan in November 2018.<ref>[https://mm.icann.org/pipermail/ssr2-review/2018-November/001344.html SSR2 Listserv Archive - SSR2 Team Work Plan], November 14, 2018</ref> The team subsequently updated the board in February 2019 on its status subsequent to another multi-day, face to face meeting in Los Angeles.<ref>[https://mm.icann.org/pipermail/ssr2-review/2019-February/001475.html SSR2 Listserv Archive - Update from the Review Team], February 13, 2019</ref> The board acknowledged receipt of the ToR, work plan, and update report at the end of February.<ref>[https://mm.icann.org/pipermail/ssr2-review/2019-February/001507.html SSR2 Listserv Archive - Message from Board to SSR2], February 28, 2019</ref> | ||
| 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 150: | Line 150: | ||
| Rejected b/c the Board cannot approve the recommendation in full | | Rejected b/c the Board cannot approve the recommendation in full | ||
| 17.2: ICANN Community should develop a clear policy for avoiding and handling new gTLD-related name collisions, and implement this policy before the next round of applications | | 17.2: ICANN Community should develop a clear policy for avoiding and handling new gTLD-related name collisions, and implement this policy before the next round of applications | ||
| Both the [[Policy Development Process for New gTLD Subsequent Procedures|GNSO]] and the [[Name Collision | | Both the [[Policy Development Process for New gTLD Subsequent Procedures|GNSO]] and the [[Name Collision#NCAP|SSAC]] are in the process of studying name collisions and policy development for the next round of applications. The board is not a policy-making body, and has faith in these community efforts<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 278: | Line 278: | ||
* ''Several recommendations repeat, duplicate or significantly overlap with existing ICANN org operations, or recommendations issued by other Specific Review teams.'' The board cited the public comments of [[RySG]], [[RrSG]], [[Public Interest Registry]], and others who commented on specific recommendations that were repetitive or duplicative. | * ''Several recommendations repeat, duplicate or significantly overlap with existing ICANN org operations, or recommendations issued by other Specific Review teams.'' The board cited the public comments of [[RySG]], [[RrSG]], [[Public Interest Registry]], and others who commented on specific recommendations that were repetitive or duplicative. | ||
* ''Some recommendations contemplate that the ICANN Board or ICANN org should unilaterally develop policy outside of the GNSO Council’s Policy Development Process.'' This was also noted during the public comment period by RySG, RrSG, and PIR, along with prominent contracted parties [[Tucows]] and [[Namecheap]]. | * ''Some recommendations contemplate that the ICANN Board or ICANN org should unilaterally develop policy outside of the GNSO Council’s Policy Development Process.'' This was also noted during the public comment period by RySG, RrSG, and PIR, along with prominent contracted parties [[Tucows]] and [[Namecheap]]. | ||
* ''Some recommendations do not clearly address a fact-based problem, or articulate what cost/benefit would be derived or how the desired outcome envisioned by the Review Team would add value and improve security, stability, and resiliency.'' Echoing a common tension between technical attitudes toward security, stability, and resiliency on the one hand, and socially-oriented, policy advocacy stances on the other, the board reiterated its own comments to the previous output of the SSR2 team. Citing both the [[Operating Standards for Specific Reviews]] and the conversations held in the development of the [[ | * ''Some recommendations do not clearly address a fact-based problem, or articulate what cost/benefit would be derived or how the desired outcome envisioned by the Review Team would add value and improve security, stability, and resiliency.'' Echoing a common tension between technical attitudes toward security, stability, and resiliency on the one hand, and socially-oriented, policy advocacy stances on the other, the board reiterated its own comments to the previous output of the SSR2 team. Citing both the [[Operating Standards for Specific Reviews]] and the conversations held in the development of the [[Prioritization Framework]] for community discussion, the board repeated the importance of well-crafted, fact-based recommendations that could articulate specific benefits to the stability, security, and resiliency of the DNS.<ref name="rationale" /> | ||
===Implementation Planning Phase=== | |||
An ICANN Board Caucus has met with the SSR2 implementation shepherds twice as of December 2021.<ref>[https://community.icann.org/display/SSR/SSR2+Implementation+Shepherds SSR2 Workspace - Implementation Shepherds], last updated October 27, 2021</ref> A key focus of the meetings to date is to resolve the "pending" recommendations where additional information from the review team was required. | |||
At its September meeting, [[Danko Jevtovic]] reiterated the Board's commitment to grow its understanding of the review team's recommendations as well as inform and educate the implementation shepherds regarding what is possible.<ref name="septcaucus">[https://icann.zoom.us/rec/play/2kLmaNXcxkb596NJw5jXge1mBQmSbVU6GVnCKqdQ_p53J4aKbFW1NoSVH07A1RGaGBu83fFtXJ7NW--s.GPD82qxnW0dLgBiF?startTime=1632927768000 ICANN Zoom Archives - Board Caucus Meeting with SSR2 Implementation Shepherds], September 29, 2021 (must be logged into Zoom - passcode for meeting is FH3Qc?tC.Q</ref> The September meeting specifically addressed two categories of recommendations: | |||
* Audits, either under ISO 31000 or otherwise, regarding ICANN's security and risk management practices; and | |||
* Recommendations that were contradictory to the ICANN Bylaws (Board implementing policy, additional contractual compliance activity or contract amendments). | |||
In both cases, the conversation tended toward an autopsy of the review team's process and rationales.<ref name="septcaucus" /> | |||
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 285: | Line 302: | ||
[[Category:Specific Reviews]] | [[Category:Specific Reviews]] | ||
[[Category:Featured]] | |||