icannwiki

Second Security, Stability, and Resiliency Review

Revision as of 18:52, 12 May 2022 by Jessica (talk | contribs)

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.[1] 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.[1]

Background edit

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;
  • preserves the security, stability, and resiliency of the DNS;
  • promotes competition, consumer trust, and consumer choice; and
  • enables access to registration data.

ICANN is also charged to periodically review and assess its performance through the lens of each of the above commitments.[2]

ICANN's board enshrined these commitments (and the associated reviews) in its Bylaws in Article 1 (Mission, Commitments, and Core Values)[3] and in Article 4 (Accountability and Review).[4] Article 4.6 deals with "Specific Reviews," each of which are tied to one of the commitments in the Affirmation of Commitments.[5]

The Organizational Effectiveness Committee of the board oversees the conduct of specific reviews.[6] The SSR is one such review. The Bylaws mandate that the review team include independent experts in the field of networking security and stability.[5] The Bylaws also call for SSR reviews to begin no later than five years after the completion of the prior review.[5]

Initiation, Delay, and Suspension of Work edit

The call for volunteer applications was posted in June of 2016.[1] The deadline for applications was extended, in part because the ICANN Board had adopted amendments to the organization's bylaws, some of which affected the selection process for specific reviews such as the SSR.[7] Team selection was delayed until February 2017[1]

The team submitted its Terms of Reference (ToR) on May 11, 2017.[8][9] In June, the Board responded to the review team, noting that the Terms of Reference "in general must provide a clear articulation of work to be done and a basis for how the success of the project will be measured," and expressing some concerns regarding the clarity of the ToR and work objectives.[10] Work continued within the review team and on the listserv, particularly with regard to formulating and refining the team's work plan. However, no formal response issued regarding the board's concerns.

In October 2017, the SSAC submitted a letter to the ICANN Board, advocating for a pause in SSR2 and arguing that the "current approach, if continued without significant change, will ultimately result in a report that does not have the quality expected by the ICANN Community."[11] In the same month, the Board sent objections regarding the scope of the still-evolving work plan, specifically the work of Subgroup 2 and the proposal to conduct a full review of ICANN's internal operational security.[12] Within the review team, reactions were mixed to both letters. A proposed response regarding a planned Los Angeles on-site for Subgroup 2 On October 10-11 (one week from receipt of the letter addressing scope concerns) was not able to obtain consensus, particularly from SSAC-affiliated members of the review team.[13]

In the following weeks, additional actions occurred that were directly or indirectly related to the SSR2 situation. The board had acknowledged their own failure to set expectations for specific review processes, and set about remedying this failure with a proposed operating standards document for public comment.[14] The chairs of other SOs and ACs also reported concerns regarding the direction of the SSR2 review. As a result, on October 28, 2017, the board sent a letter to the review team instructing them to pause all work until meetings could be held between the chairs of the SOs and ACs and board members at ICANN 60.[15] The letter reads in part:

In light of the importance of this effort, the concerns being expressed, and the resources devoted to date, we believe that it is imperative that the community assure itself that the SSR2 is appropriately composed and structured to achieve its purpose. Accordingly, the Board will be meeting with SO/AC Chairs, the SSR2 Review Team, and the community on this topic throughout ICANN 60, and following the meeting will formally ask the SOs and ACs to consider whether they believe there is a need to adjust the scope, terms of reference, work plan, skill set and/or resources allocated to SSR2. Without prejudging the answer to those questions, the Board considers that the most responsible course is to suspend the review team’s work pending responses from the SOs and ACs.[15]

The SSR2 team met with SOs and ACs over the course of ICANN 60, as well as the board.[16] In the aftermath of the meeting between SSR2 and the board, there was a brief discussion between the board and chairs of the SOs and ACs regarding next steps.[17] The result of those meetings was that the SOs and ACs would "do what needed to be done" to correct the trajectory of the review process. There was acknowledgement that there was no existing process for a situation like this, and apologies to chairs and review team members alike regarding potential board or staff contributions to the impasse.[17] The project remained on hold for the SOs and ACs to establish a plan. Board members variously noted that they did not know, and were never informed, that there was a finalized work plan for the team.[17]

In December 2017, the SOs and ACs sent a letter to the SSR2 review team.[18] The letter described the chairs' conclusions regarding the work of SSR2 to date, as well as the responses to a questionnaire submitted to SSR2 review team members.[18] The questionnaire received responses from all but two of the SSR2 members. The chairs concluded that the SSR2 team was made up of dedicated volunteers with a true desire to see the work completed. However, they identified issues of trust, bandwidth, potential conflicts of interest, detail and completeness of the team's work plan, and a challenging and overambitious scope.[18] the chairs summarized their next steps:

The SOAC chairs recognizes [sic] a number of concrete actions for us: first, appoint more members to the SSR2 team and discuss with ICANN Staff what the budget and staffing situation looks like. After these actions have taken place, we are to restart the SSR2 review with some initial concrete items on their agenda: agree internally on updated leadership, COI issues and scope; and work with ICANN Staff and SOAC chairs to agree on communication, milestones, and progress reporting/management of the review.[18]

The letter acknowledged the hard work of the team thus far, and noted that the pause represented an opportunity for team members to assess their bandwidth to continue with the project.[18]

Restart edit

At the beginning February 2018, the NCPH Intersessional meeting took place in Los Angeles. One of the sessions was devoted to SSR2, as well as the planning for and initiation of the Third GNSO Organizational Review.[19] During the plenary session, which was attended by members of the OEC, Susan Kawaguchi from the GNSO Council provided a status update as it related to the GNSO's communication with the other SOs and ACs:

We just finalized a letter to the SO and AC leaders, trying to come to consensus, come to the middle ground to figure out a way to move forward with putting this team back to work un-suspending it and move on, but with the right resources and talent and expertise. So we're taking this very seriously. You know, I'm sort of developing into a process person. If you have a process, it's much easier than designing it on the fly, and unfortunately the board's action has now, you know, everybody sort of had to sit back and go, "Oh, what do we do now?" The GNSO, through Heather, is trying to lead that and has proposed several paths forward. One is the facilitator for the whole team to, review team, to really decide what they need and somebody to work with them. What I don't think they need, and this is a personal opinion, is SO and AC leaders, even Heather as chair as GNSO, saying this is what you need, review team. Having sat - now I'm on my second review team, it's really important to maintain that independence. So that's what the GNSO is leading - is pushing for. We would like to see this, you know, move on. It's important work. And then take the learnings from it and develop a process.[20]

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.[21] 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."[21] 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.[22] The OEC agreed, and set about working with the SOAC chairs to identify the required skills and experience that the facilitator should have.[23]

After an RFP process, Phil Khoury was engaged as facilitator in June 2018.[24] The review's relaunch was was announced shortly thereafter on June 7, 2018.[25] 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.[26] 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.[27] 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.[28]

The team presented a new Terms of Reference to the Board in September 2018.[29] The team followed up with a work plan in November 2018.[30] The team subsequently updated the board in February 2019 on its status subsequent to another multi-day, face to face meeting in Los Angeles.[31] The board acknowledged receipt of the ToR, work plan, and update report at the end of February.[32]

Mid-2019 Setbacks edit

At ICANN 64 in Kobe, the review team requested technical writing support from the ICANN board and organization.[33] ICANN org conducted a search for a technical writer to be assigned to the review team. A writer was hired in May 2019; however, after two weeks, the writer was dismissed by ICANN org.[33] The review team expressed displeasure about this development (and others) in a letter to the board, CEO, and SOAC chairs:

Unfortunately, the SSR2 Team has a history of being under-supported and obstructed: our work was initially delayed by a lack of documentation regarding the incomplete implementation of the 2012 SSR1 recommendations; we were “paused” for about a year by the Board without prior communication with the Team; we saw considerable delays when asking questions to staff, and received multiple insufficient responses; and we have had professional writing and research support for only 15 days. In addition, the Board’s subsequent handling of the CCT Review Team recommendations* further confused and deflated the enthusiasm of our Team.[33]

*The board approved action on only six of thirty-seven recommendations, placing seventeen of the recommendations on hold pending further research into feasibility, cost, and other unknowns.

The letter reported that the team's work had been substantially set back by the loss of technical writing support. The letter concluded "In addition to raising serious concerns about the accountability, transparency and independence of community reviews required by the ICANN bylaws, these unilateral and in transparent [sic] actions are extremely demoralizing to many Review Team members."[33]

In October 2019, the review team requested an additional $250,000 to complete the work of the review. The request cited the technical writing issue as well as other delays.[34] The Board approved the additional funding in November 2019.[35]

Draft and Final Report edit

The team published its draft report for public comment in January 2020.[1] The report contained 31 recommendations, with many recommendations including multiple action items to fully implement each recommendation.[36] The public comment period on the draft report was extended from March 4 to March 20, 2020. The ICANN Board's response to the report was posted on March 20.[37] Several comments were received after the close of the comment period.[38]

A total of eighteen comments were received.[39] The report on public comments identified four common themes among the comments:

  1. Prioritization - commenters noted that many recommendations were designated high priority, and recommended increased clarity and justifications for prioritization decisions.
  2. Outside of Remit/Scope - commenters noted that some recommendations were beyond the Board's power to enact, or were in their opinion beyond the scope of review.
  3. Clarity of Recommendations - a number of commenters asked for additional specifics, background, or expected outcomes of recommendations within the report.
  4. DNS Abuse - commenters had opinions and objections regarding the definitions of DNS abuse and related terms, as well as the proposed methods of dealing with abuse. There was again concern that some of the policy proposals were more properly addressed to a GNSO policy development process.[39]

The final report was submitted to the board and published for public comment in January 2021.[1] The report contained twenty-four issue areas, with a number of recommendations within each issue area. The review team noted that some recommendations were removed because of lack of alignment with the Board's five-year strategic plan.[40]

There were nineteen public comments submitted on the report; as with the draft report, the comments were diverse and extensive.[41]

Board Action and Implementation Planning edit

The board addressed the topic of the final report at its regular meeting on July 22, 2021.[42][1] In keeping with its updated processes, the board issued a scorecard[43] categorizing the recommendations contained in the report under six headings. The board attached a 53-page rationale for its decisions.[44] 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:

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.[45]

  • 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.[43]
  • 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.[43]

Scorecard Summary Table edit

Category
Recommendation(s) Board Response
 Next Steps
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.
 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
 No additional action required
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
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
 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
 Review implementation priority, cost, and other considerations
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 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
 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
 Rejected (agree in principle)
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 GNSO and the 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
 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
 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
 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.
 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.[46]
Rejected
 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
 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[47]
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
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
 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
 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
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
 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
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
 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."
 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
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?
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.
 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
 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
 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 edit

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:

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.[44]

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.[44]

Implementation Planning Phase edit

An ICANN Board Caucus has met with the SSR2 implementation shepherds twice as of December 2021.[48] 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.[49] 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.[49]

In December 2021, ICANN org submitted its first series of clarifying questions to the implementation shepherds listserv.[50] 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.[51] ICANN org hoped to receive answers to these questions by January 14, 2022[50]

References edit

  1. ↑ 1.0 1.1 1.2 1.3 1.4 1.5 1.6 ICANN.org - SSR Dashboard
  2. ↑ ICANN.org - Affirmation of Commitments, September 30, 2009
  3. ↑ ICANN Bylaws, Article 1
  4. ↑ ICANN Bylaws, Article 4
  5. ↑ 5.0 5.1 5.2 ICANN Bylaws, Article 4.6
  6. ↑ ICANN.org - Organizational Effectiveness Committee
  7. ↑ ICANN.org - Application Deadline Extended for SSR2, August 12, 2016
  8. ↑ SSR2 Workspace - Correspondence
  9. ↑ Terms of Reference, SSR2, May 11, 2017 (Word document)
  10. ↑ Board Response to SSR2 Terms of Reference, June 23, 2017
  11. ↑ ICANN.org - Faltstrom letter to ICANN Board, October 3, 2017
  12. ↑ ICANN.org Listserv Archive - Board Letter regarding Subgroup 2's scope, October 3, 2017
  13. ↑ ICANN Listserv Archive - Email Replying to the Board, October 5 2017 (and subsequent replies)
  14. ↑ ICANN.org, Draft Operating Standards for Specific Reviews, October 17, 2017
  15. ↑ 15.0 15.1 ICANN.org - Letter from Steve Crocker to SSR2, October 28, 2017
  16. ↑ SSR2 Workspace - ICANN 60 Meetings
  17. ↑ 17.0 17.1 17.2 SSR2 Workspace - Meeting with Board Caucus & Community Leadership, November 2, 2017
  18. ↑ 18.0 18.1 18.2 18.3 18.4 ICANN.org - SO/AC Letter to SSR2, December 21, 2017
  19. ↑ NCPH Workspace - 2018 Intersessional Meeting Agenda, February 2018
  20. ↑ Meeting Transcript - 2018 Intersessional, February 2, 2018
  21. ↑ 21.0 21.1 ICANN.org - SOAC Chairs Message on SSR2 Status, February 12, 2018
  22. ↑ ICANN.org - SOAC letter to OEC, February 15, 2018
  23. ↑ Letter from Khaled Koubaa to SOAC Chairs, March 3, 2018
  24. ↑ ICANN.org - OEC letter to SOAC Chairs, June 5, 2018
  25. ↑ ICANN.org - SSR2 Restarts, June 7, 2018
  26. ↑ ICANN.org - SSR2 Review Team Restarts
  27. ↑ SSR2 Workspace - August 2018 Meeting Archive
  28. ↑ Draft Facilitator Report to SOAC Chairs - SSR2, September 10, 2018
  29. ↑ SSR2 Terms of Reference, September 4, 2018
  30. ↑ SSR2 Listserv Archive - SSR2 Team Work Plan, November 14, 2018
  31. ↑ SSR2 Listserv Archive - Update from the Review Team, February 13, 2019
  32. ↑ SSR2 Listserv Archive - Message from Board to SSR2, February 28, 2019
  33. ↑ 33.0 33.1 33.2 33.3 Letter to Board, CEO, and SOAC Chairs, June 26, 2019
  34. ↑ SSR2 Listserv Archive - Message to Board, CEO, October 9, 2019]
  35. ↑ Resolution of the Board, November 7, 2019
  36. ↑ SSR2 Draft Report, January 24, 2020
  37. ↑ ICANN.org Listserv Archive - SSR2 Public Comments, First Quarter, 2020
  38. ↑ ICANN.org Listserv Archive - SSR2 Draft Report Public Comments
  39. ↑ 39.0 39.1 Staff Report on Public Comment Proceeding, April 22, 2020
  40. ↑ SSR2 Final Report, January 25, 2021
  41. ↑ ICANN.org Listserv Archive - SSR2 Final Report
  42. ↑ Resolutions of the Board, July 22, 2021
  43. ↑ 43.0 43.1 43.2 ICANN.org Archive - SSR2 Scorecard, July 22, 2021
  44. ↑ 44.0 44.1 44.2 ICANN.org Archive - Rationale for Resolutions regarding the SSR2 Final Report, July 22, 2021
  45. ↑ ICANN.org Blog - Board Action and Next Steps on the SSR 2 Review, July 26, 2021
  46. ↑ Scorecard: SSR2 Pending Recommendations - Board Action 1 May 2022
  47. ↑ Scorecard: SSR2 Pending Recommendations - Board Action 1 May 2022
  48. ↑ SSR2 Workspace - Implementation Shepherds, last updated October 27, 2021
  49. ↑ 49.0 49.1 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
  50. ↑ 50.0 50.1 Email to SSR2 Implementation Shepherds: 'Pending/Likely to Be Approved' Recommendations - Clarifying Questions, December 7, 2021
  51. ↑ SSR2 Questions - Group 1: Pending/Likely to be Approved, December 7, 2021 (PDF)

Security and Stability Advisory Committee. Advises the ICANN community and Board on matters relating to the security and integrity of the Internet's naming and address allocation systems (ICANN Bylaws).

Generic Names Supporting Organization. Develops and recommends to the Board substantive policies relating to generic top-level domains and other responsibilities set forth in the Bylaws (ICANN Bylaws).

Root Server System Advisory Committee. Advises the ICANN community and Board on matters relating to the operation, administration, security, and integrity of the Internet's Root Server System (ICANN Bylaws).

Retrieved from "https://icannwiki.org/index.php?title=Second_Security,_Stability,_and_Resiliency_Review&oldid=1343742"