icannwiki

Second Security, Stability, and Resiliency Review: Difference between revisions

← Older edit
VisualWikitext
JP (talk | contribs)
Bureaucrats, Check users, lookupuser, Administrators, translator
3,197 edits
Jessica (talk | contribs)
Bureaucrats, Check users, lookupuser, Administrators, translator
14,952 edits
 
(25 intermediate revisions by 2 users not shown)
Line 1: Line 1:
The '''Second Security, Stability, and Resiliency Review''' (SSR2) was initiated in June 2016. The review team's final report was submitted to the [[ICANN Board]] in January 2021.<ref name="dashboard">[https://www.icann.org/resources/reviews/specific-reviews/ssr ICANN.org - SSR Dashboard]</ref> As of May 2021, the report is awaiting board action.<ref name="dashboard" />
The '''Second Security, Stability, and Resiliency Review''' (SSR 2) was initiated in June 2016. The review team's final report was submitted to the [[ICANN Board]] in January 2021.<ref name="dashboard">[https://www.icann.org/resources/reviews/specific-reviews/ssr ICANN.org - SSR Dashboard]</ref> The board took action on the recommendations contained in the SSR 2 final report in July 2021. As of August 2021, the review is in the implementation planning phase.<ref name="dashboard" />


==Background==
==Background==
The [[Affirmation of Commitments]], an agreement between ICANN and the [[United States Department of Commerce]], establishes 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:
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 culminatoin 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>
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 70: Line 70:
There were nineteen public comments submitted on the report; as with the draft report, the comments were diverse and extensive.<ref>[https://mm.icann.org/pipermail/comments-ssr2-final-report-28jan21/ ICANN.org Listserv Archive - SSR2 Final Report]</ref>
There were nineteen public comments submitted on the report; as with the draft report, the comments were diverse and extensive.<ref>[https://mm.icann.org/pipermail/comments-ssr2-final-report-28jan21/ ICANN.org Listserv Archive - SSR2 Final Report]</ref>


As of May 2021, the SSR2 final report is awaiting board action.<ref name="dashboard" />
==Board Action and Implementation Planning==
The board addressed the topic of the final report at its regular meeting on July 22, 2021.<ref name="bdreso">[https://www.icann.org/resources/board-material/resolutions-2021-07-22-en#2.a Resolutions of the Board], July 22, 2021</ref><ref name="dashboard" /> In keeping with its updated processes, the board issued a scorecard<ref name="scorecard">[https://www.icann.org/en/system/files/files/ssr2-scorecard-22jul21-en.pdf ICANN.org Archive - SSR2 Scorecard], July 22, 2021</ref> categorizing the recommendations contained in the report under six headings. The board attached a 53-page rationale for its decisions.<ref name="rationale">[https://www.icann.org/en/system/files/bm/rationale-ssr2-22jul21-en.pdf ICANN.org Archive - Rationale for Resolutions regarding the SSR2 Final Report], July 22, 2021</ref> The six categories in the scorecard were each tied to either approval, rejection, or the placing of recommendations in pending status:
* Recommendations the Board approves, subject to prioritization, risk assessment and mitigation, costing and implementation considerations; and recommendations that the Board approves with the understanding that they are already fully implemented;
* Recommendations the Board rejects because they cannot be approved in full; Maarten Botterman, in his blog post announcing the Board's action on the final report, explains:
<blockquote>The Board does not have the option to selectively approve or reject parts of a single, indivisible community recommendation; they must act on a recommendation as written and not as interpreted by ICANN org or the Board. The Board notes that part of the community intent in incorporating Specific Reviews into the ICANN Bylaws in 2016 was to require the Board to act on recommendations as written, not as interpreted by ICANN org or Board.<ref name="frblog">[https://www.icann.org/en/blogs/details/board-action-and-next-steps-on-the-ssr2-review-26-7-2021-en ICANN.org Blog - Board Action and Next Steps on the SSR 2 Review], July 26, 2021</ref></blockquote>
* Recommendations the Board rejects; Although ten recommendations were rejected, those recommendations were clustered around three top-level recommendations: the creation of a CSO position with ICANN org; the creation of a [[temporary specification]] requiring all contracted parties to keep domains with reported DNS abuse activity below a certain percentage threshold; and an [[Expedited Policy Development Process]] to define and implement an anti-abuse policy.<ref name="scorecard" />
* Recommendations the Board determines to be pending, likely to be approved once further information is gathered to enable approval;
* Recommendations that the Board determines to be pending, holding to seek clarity or further information; and
* Recommendations the Board determines to be pending, likely to be rejected unless additional information shows implementation is feasible.<ref name="scorecard" />
 
===Scorecard Summary Table===
{| class="wikitable"
|-
! Category <br />
! Recommendation(s)
! Board Response<br />
! Next Steps<br />
|-
| Approved/Already Implemented
| 1.1: Review implementation of SSR1 recommendations and develop plan to complete implementation.
| Approved
| ICANN org to review SSR2 findings regarding unimplemented recommendations
|-
| Approved/Already Implemented
| 4.1: Continue centralizing risk management functions; adopt a security risk management framework.<br />
| Already fully implemented
| No action required
|-
| Approved/Already Implemented
| 5.1 - 5.2: Adopt an Information Security Management System (ISMS) and submit to regular audits.
| Will be fully implemented upon completion of transition to NIST Cybersecurity Framework<br />
| No additional action required<br />
|-
| Approved/Already Implemented
| 9.1: Direct the contract compliance team to monitor and strictly enforce compliance of contracted parties to current and future security and risk management requirements.
| Already fully implemented
| No action required
|-
| Approved/Already Implemented
| 10.1: Create a webpage that: defines ICANN's current operational consensus on what constitutes "DNS Abuse;" provides links to excerpts of registry agreements and other contracts that reference DNS Abuse; and distinguishes and defines similar terminology such as "malicious conduct" or "security threats." Update annually and archive past versions.
| To the extent that the recommendation is intended to enhance transparency, accountability, and clarity of ICANN org’s work on Domain Name System (DNS) security threat mitigation through its existing contractual and compliance mechanisms, and thereby facilitate ongoing community discussions around definitions of DNS security threats, the Board approves this recommendation
| Review implementation priority, cost, and other considerations, including whether ICANN's [[Information Transparency Initiative]] should incorporate some or all of this recommendation<br />
|-
| Approved/Already Implemented
| 16.1: Create consistent cross-references across the ICANN.org website to allow easy access to all actions taken in the realm of data privacy and data stewardship, particularly as applied to WHOIS/RDS policy
| Like recommendation 10.1, this may overlap with the [[Information Transparency Initiative]]<br />
| Review implementation priority, cost, and other considerations
|-
| Approved/Already Implemented
| 21.1, 22.1 - 22.2, and 23.1 - 23.2: Accelerate implementation of new Root Zone Management System security measures (particularly encrypted email and multi-factor authentication); create a list of services for which ICANN is responsible and publish operational statistics and metrics on those services on an open data platform; request community feedback on those measurements and metrics on an annual basis; improve PTI operating procedures regarding DNSKEY transitions and update the DNSSEC Practice Statement to allow for transitions between different types of digital signature algorithms
| Actions are already being taken on specific elements of these recommendations<br />
| Review implementation priority, cost, and other considerations<br />
|-
| Approved/Already Implemented
| 24.2: Make the Common Transition Process Manual easier to find by providing links on the [[EBERO]] website
| Like recommendations 10.1 and 16.1, elements of this recommendation may be best handled by ICANN org within the [[Information Transparency Initiative]]
| Review implementation priority, cost, and other considerations
|-
| Rejected b/c the Board cannot approve the recommendation in full
| 4.2: ICANN Org should adopt and implement ISO 31000 "Risk Management" framework and validate its implementation with appropriate, publicly available, independent audits
| Board approves of ICANN Org's current risk management program and does not see a benefit to switching to the ISO standard. ICANN org is encouraged to continue identifying and adapting industry best practices to serve the organization's mission
| Rejected (agree in principle)
|-
| 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 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 />
| Rejected
|-
| Rejected b/c the Board cannot approve the recommendation in full
| 9.4: ICANN Org should task the compliance team with publishing regular reports that enumerate tools that they are missing that would help them enforce the SSR-related elements of ICANN's agreements, including measures that would require changes to the agreements
| Agree in principle that the contractual compliance team should seek and improve tools to do its job; cannot approve the modification of contracts willy-nilly (again, this is impossible under the provisions of the RA and RAA)
| Rejected (agree in principle)
|-
| Rejected b/c the Board cannot approve the recommendation in full
| 10.2 - 10.3: Establish a cross community working group to establish a process for reviewing and evolving the definitions of prohibited DNS Abuse; utilize the developed consensus definitions consistently throughout the organization and in communications regarding abuse [see also recommendation 10.1, above]
| The board/org cannot unilaterally convene a CCWG; the board is aware of and will continue to engage with the conversations about DNS abuse as a term of art and what types of abuse are within ICANN's remit to act upon; agree in principle with consensus definitions, but the recommendation (10.3) is dependent upon 10.2, which cannot be approved<br />
| Rejected (agree in principle)<br />
|-
| 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
| 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
| 2.1 - 2.4: Create a CSO position within ICANN org
| The CEO of ICANN is responsible for the structure of his team - not the board's place to intervene. The board is satisfied that security policy has sufficient oversight and attention at the C-Suite level and in coordination with the Board's risk committee<br />
| Rejected
|-
| Rejected
| 14.1, 14.3 - 14.5, 15.1 - 15.2: Create a Temporary Specification to require contracted parties to keep abuse below a certain threshold; provide incentives for limiting abuse; once the temporary specification is in place, establish an expedited policy development process to create an anti-abuse policy, utilizing the definitions & parameters determined by recommendation 10.2
| Board can only create Temporary Specification in "emergency" situations - no such indication of an emergency here. EPDPs can only be initiated by the GNSO Council.
| 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.
| Too many unanswered questions and details regarding this recommendation make it impossible to approve as written.<br />
| 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
| 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 />
| 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
| 20.2: ICANN org should create a group of stakeholders involving relevant personnel (from ICANN org or the community) to periodically run table-top exercises that follow the Root KSK rollover process.
| This seems feasible and desirable, but more information is needed regarding what the exercise is designed to target
| ICANN org to coordinate with SSR2 Implementation Shepherds to determine the purpose and desired outcomes of this recommendation
|-
| Pending - on hold to seek clarity or further information
| 3.1 - 3.3: Proposed roles and responsibilities for the CSO (recommendation 2)
| Board is rejecting the creation of a CSO position
| ICANN org to coordinate with Implementation Shepherds to see if these roles and responsibilities can be coordinated by other elements of ICANN's risk management staff
|-
| Pending - on hold to seek clarity or further information
| 4.3: Create a risk manager position reporting to the CSO (recommendation 2) with specific duties and responsibilities
| Board is rejecting the creation of a CSO position. Also, the CEO is responsible for the structure and job positions within ICANN org
| Coordinate with Implementation Shepherds to clarify elements of the recommendation that are unclear, and de-couple the recommendation from dependency upon the CSO role<br />
|-
| Pending - on hold to seek clarity or further information
| 5.3: ICANN org should require vendors and contractors to comply with security principles, and document its due diligence regarding screening of security standards
| Engineering & IT team already requires this; unclear whether the recommendation seeks to expand this sort of screening & evaluation to all vendors<br />
| Clarify with Implementation Shepherds
|-
| Pending - on hold to seek clarity or further information
| 7.1 - 7.3, 7.5: Establish business continuity and disaster recovery plans based on ISO 22301; enlist RSSAC and RSOs to ensure that PTI's continuity plans and ICANN's continuity plans include all relevant systems, include root zone management, and are in line with ISO 27031; publish a summary of these continuity plans and conduct periodic audits of compliance with the plans
| Recommendation 7.4 recommends that ICANN have a non-U.S., non-North American colocation site for failovers. This recommendation is being placed in the "pending, likely to be rejected" category. SSR2's guidelines for successful implementation of recommendation 7's parts includes the creation of the colocated site. The board is concerned that successful implementation of the other parts of recommendation 7 will be impossible without approval of 7.4
| Clarify with Implementation Shepherds whether implementation of these constituent parts can be deemed effective without implementation of 7.4
|-
| Pending - on hold to seek clarity or further information
| 9.3: Audit "compliance activities" at least annually and publish results, policy outcomes, and implementation plans
| Unclear what is supposed to be audited
| Clarify with Implementation Shepherds
|-
| Pending - on hold to seek clarity or further information
| 11.1: ensure that the Central Zone Data Service is accessible in a timely matter without unnecessary hurdles
| Unclear how this recommendation is different than the current efforts to implement SAC0097, which has a similar recommendation
| Clarify with Implementation Shepherds
|-
| Pending - on hold to seek clarity or further information
| 12.1 - 12.4, 13.1 - 13.2: Assemble an advisory team to overhaul DNS Abuse Reporting processes and data collection; make the data available to academia & researchers; publish reports on statistical "worst abusers" and actions taken against abuse; and create a central clearinghouse for abuse complaints, designed to pass claims to relevant parties. Mandatory participation by gTLDs, voluntary participation by ccTLDs
| Sounds great - community is already very active on the topic of DNS Abuse. Also, some aspects of these proposals would need to be more fully understood before proposing an implementation plan<br />
| ICANN org to evaluate how this group of recommendations, along with other recommendations pertaining to the security of the DNS, should be considered in a coordinated way, including through ICANN org's DNS Security Threat Mitigation program<br />
|-
| Pending - on hold to seek clarity or further information
| 14.2: Provide lists of domains that have been identified as abusive to the relevant contracted parties
| Open questions regarding how to best implement this<br />
| As above, ICANN org to evaluate how this recommendation fits into a coordinated plan, including its inclusion in ICANN org's DNS Security Threat Mitigation program<br />
|-
| Pending - on hold to seek clarity or further information
| 17.1: Create a framework to characterize the nature and frequency of name collisions and resulting concerns; include metrics and measurements regarding prevention mechanisms; ensure data privacy protections
| This recommendation has dependencies on the outcome of SSAC's [[Name Collision Analysis Project]] - board previously recommended considering passing this recommendation through<br />
| Board still recommends that SSR2 pass this recommendation onto the NCAP
|-
| Pending - on hold to seek clarity or further information
| 18.1 - 18.3: Generate periodic "executive summaries" of peer-reviewed publications, conference proceedings, and other research findings that are germane to ICANN's work and mission; highlight findings or recommendations for process improvement in security protocols, contract provisions, and other areas related to SSR; recommend additional studies and define how ICANN could provide datasets for such studies (i.e. through the Central Zone Data Service)
| "[T]he Board notes that many academic papers published do not reach the level of notice that would impact the work of ICANN and a significant investment of time, money, and effort would be required to sort through these materials. In this manner, Recommendations 18.1 - 18.3 imply unbounded work."<br />
| Evaluate tracking efforts currently underway and assess community appetite for this recommendation
|-
| Pending - on hold to seek clarity or further information
| 20.1: Establish a formal procedure for key rollovers, informed by community input, and updated at least as often as the rollovers
| Likely massively expensive, and it's unclear what benefits would accrue. Alternatives exist to the proposed scheme that might fulfill the same objectives
| Clarify with Implementation Shepherds, and if appropriate, gather community input regarding the proper way forward<br />
|-
| Pending - on hold to seek clarity or further information
| 24.1: Coordinate end-to-end testing of the full [[EBERO]] process at predetermined intervals
| Live test? What data sets? <br />
| Clarify with Implementation Shepherds
|-
| Pending, likely to be rejected unless additional information shows implementation to be feasible
| 6.1: Promote the voluntary adoption of SSR best practices; failing widespread adoption, enforce via contract, MoU, or other agreements
| The specifics of "best practices" are unclear; ICANN cannot unilaterally change its contracts with contracted parties; threshold for shifting to contractual enforcement is unclear; etc.<br />
| Clarify with Implementation Shepherds
|-
| Pending, likely to be rejected unless additional information shows implementation to be feasible
| 6.2: Implement coordinated vulnerability disclosure reporting; disclosures should be passed on to affected parties; ICANN to regularly report on vulnerabilities, including anonymized metrics and ensuring data protection and privacy
| Three recommendations in one; some of this is already done, but creating an omnibus system as well as reporting/pass through to affected parties, is likely impossible
| Clarify with Implementation Shepherds
|-
| Pending, likely to be rejected unless additional information shows implementation to be feasible
| 7.4: Establish a third colocated site for disaster recovery outside of the U.S. & North America, or create such a site with a view toward replacing either the Los Angeles or Culpeper site
| IANA Naming Function contract makes this impossible; no explanation of benefit; Board requested an explanation of the team's cost/benefit analysis in comments to the draft report
| Engage with Implementation Shepherds
|-
| Pending, likely to be rejected unless additional information shows implementation to be feasible
| 9.2: Proactively monitor and enforce registry/registrar contractual obligations to improve accuracy of registration data; establish routine audits of such data, focusing on contracted parties that have received over 50 complaints per year
| ICANN org does not have the power to implement this recommendation under current agreements<br />
| Clarify with Implementation Shepherds what authority they expect the contract compliance staff to rely upon to implement this recommendation
|-
| Pending, likely to be rejected unless additional information shows implementation to be feasible
| 16.2: Create specialized groups within the contract compliance team that understand privacy requirements and principles, and that can facilitate law enforcement needs under the RDS framework as adopted and amended by the community
| The contract compliance team possesses that expertise now, as well as having the Chief Data Protection Officer as a resource; it is unclear what "law enforcement needs" are contemplated; ICANN Org does not have the authority to facilitate whatever those needs are<br />
| Clarify with Implementation Shepherds
|-
| Pending, likely to be rejected unless additional information shows implementation to be feasible
| 16.3: Conduct periodic audits of registrars' adherence to their posted privacy policies; ensure that procedures are in place to address breaches
| As noted in comment to SSR2's draft report, ICANN org's RAA does not require a privacy policy. You can't audit something that isn't required
| Clarify with Implementation Shepherds
|}
 
===Board Rationale===
The Board Rationale document is notable for its length - typically, even in complex situations, the rationale is not so long as to require an attachment to the recorded minutes. The board cited Article 4.6 as the basis for the comprehensive and lengthy rationale document:
<blockquote>The categorization approach allows for additional community consultation and information gathering where necessary, such as where recommendations are not clear or present inconsistencies with advice or other community work and public input. Further, the approach ensures Board accountability to the Bylaws-mandated deadline to take action on the recommendations within six months of receipt of a final report. The Bylaws require that for every Specific Review recommendation that the Board does not accept, the Board must provide a rationale supporting its action.<ref name="rationale" /></blockquote>
The board noted several themes among the recommendations, which in some cases made a particular recommendation impossible to approve as an ''a priori'' matter:
* ''SSR2 recommendations are considerable in number, complex, and have interdependencies with other significant areas of work underway.'' The board noted in its scorecard when such other areas of work were implicated by (or addressed the same subject matter as) a given recommendation.
* ''Some recommendations contain components that the Board cannot approve, along with components that are feasible, and in some cases already being done.'' Per Maarten Botterman's comment, above, the board rejected these recommendations, even in situations where they agreed in principle with the spirit of the recommendation.
* ''Some recommendations are polarizing, with public comments reflecting different, often opposing views.'' The board implied, as well, that some recommendations were inconsistent with advice from within the community.
* ''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 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==
{{reflist}}
{{reflist}}
__NOTOC__
 
 
[[Category:Specific Reviews]]
[[Category:Featured]]
Retrieved from "https://icannwiki.org/Second_Security,_Stability,_and_Resiliency_Review"