3,197
edits
Changes
Second Security, Stability, and Resiliency Review (view source)
Revision as of 00:08, 19 August 2021
, 2 years ago→Board Action and Implementation Planning
* Recommendations the Board determines to be pending, likely to be rejected unless additional information shows implementation is feasible.<ref name="scorecard" />
* 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 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 Analysis Project|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
|-
| Pending, likely to be approved after receipt of additional information<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 />
| ICANN org to coordinate with SSR2 Implementation Shepherds to determine the feasibility of implementing this recommendation, based on a stronger understanding of its intent and goals<br />
|-
| Pending, likely to be approved after receipt of additional information<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 />
| ICANN org to coordinate with SSR2 Implementation Shepherds to determine what is intended by this recommendation and collaborate on feasibility.<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===
===Board Rationale===