Dear Scott, dear Noorul,
The below answer in highlight has been added to the Q&A Google doc: https://docs.google.com/document/d/14eJwDGP-LvS9ltTmZoh1i19Fi0_pB2nJ4JYMsS7… [docs.google.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_docume…>. Please let us know if you have any questions.
Review Team volunteers: Scott, Noorul
Workstream: ICANN SSR
Topic 4: Perform an assessment of how effectively ICANN has implemented its Security Incident Management and Response Processes to reduce (pro-active and reactive) the probability of DNS-related incidents.
Outstanding questions: 3
Per ICANN org answer to a previous question: ”ICANN Org employs network segmentation strategies designed to reduce the risk of pivoting activity by an attacker. Administrative access to critical services (particularly those managed by IANA) have restrictions beyond internal network access. Periodic network penetration testing is conducted by independent service providers against ICANN Org network defenses, simulating attacks from both outside the network and attempted lateral movement from within the network. The results are used to prioritize network security Improvements.
Q: “ICANN Org employs network segmentation strategies designed to reduce the risk of pivoting activity by an attacker.” Are these segmentation strategies implemented now, how are they implemented?
Q: “Administrative access to critical services (particularly those managed by IANA) have restrictions beyond internal network access.” What are those restrictions, and are they on the same network (topology, in detail -- diagram)?
Q: “Periodic network penetration testing is conducted by independent service providers against ICANN Org network defenses, simulating attacks from both outside the network and attempted lateral movement from within the network.”
* Are industry best practices followed? Please report and link to which ones.
* Are penetration testers being rotated on a regular basis? If there is evidence relating to these processes, please provide a link? Is there version control, is there a permanent link?
Q: “The results are used to prioritize network security Improvements”. Can you provide details on how these findings feed into improvements? Are there any reports on this? Is there version control, is there a permanent link?
A: For all 4 items above we manage these strategies proactively and appropriately, taking into account best practices, and we respond to the information learnt in a proactive and professional manner given the resources available to us. Given the specificity of the questions related to highly sensitive areas we will not be disclosing detailed information from documents, processes, findings, and improvements even under NDA. ICANN Org would like to understand how these very detail orientated questions fall into the scope of the SSR2, but given the level of detail that we are able to provide in any event, we are responding as able.
--
Jennifer Bryce
Senior Reviews Coordinator
Internet Corporation for Assigned Names and Numbers (ICANN)
Email: jennifer.bryce(a)icann.org
Skype: jennifer.bryce.icann
www.icann.org
Dear KC,
The below answer has been added to the Q&A Google doc: https://docs.google.com/document/d/14eJwDGP-LvS9ltTmZoh1i19Fi0_pB2nJ4JYMsS7… [docs.google.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_docume…>. Please let us know if you have any questions.
Review Team volunteers: KC
Workstream: DNS SSR
Topic: Data sharing/data release
Outstanding questions: 0
Q: ITHI - how is it different from ODI, where does it get its data (from internal collection or external data)
A: ODP (Open Data Program), formally ODI is merely a vehicle in which data is published in a raw state so that the consumer can utilize the data in a manner that work for their own needs. This may include recreating statistics or graphs that is displayed within ITHI, but could be used for other methods as well.
ITHI is a collection of data, both raw and aggregated, that is specifically targeted to provide a sense of the “wellness” of certain aspects of the Internet infrastructure and unique identifiers that ICANN ORG and the community may find interesting and valuable.
Objective: publish through ODP (when it will be ready)
- Rely on ODP for future archival
- Maintain ITHI Web portal for partners/outreach/analysis
Develop relevant metrics & pre-process data
- Build expertise in the problem-space
- Define metrics
- Obtain and aggregate data
Act as a privacy filter before ODP
- The partners’ data is not “open data”
- The aggregated, anonymized metric measurements are
--
Jennifer Bryce
Senior Reviews Coordinator
Internet Corporation for Assigned Names and Numbers (ICANN)
Email: jennifer.bryce(a)icann.org
Skype: jennifer.bryce.icann
www.icann.org
Dear SSR2 RT,
The below answers have been added to the Q&A Google doc: https://docs.google.com/document/d/14eJwDGP-LvS9ltTmZoh1i19Fi0_pB2nJ4JYMsS7… [docs.google.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_docume…>. Please let us know if you have any questions.
Review Team volunteers: Norm, Ram
Workstream: ICANN SSR
Topic 6: Perform an assessment of how effectively ICANN has implemented its processes around vetting registry operators and services concerning the New gTSLALD Delegation and Transition process.
Outstanding questions: 1
Q: Referencing the EBERO testing of Fall, 2017 (https://schd.ws/hosted_files/icann60abudhabi2017/08/7%20EBERO%20Arias.pdf
[schd.ws<https://schd.ws/hosted_files/icann60abudhabi2017/08/7%20EBERO%20Arias.pdf>]) Since the ERERO testing in the Fall of 2017, have the issues raised been addressed by the EBERO providers? If so, has a re-test been conducted and, if so, are the results available? If not, is a re-test scheduled and when is it scheduled?
A: ICANN has updated the EBERO Master Services Agreement and updated requirements in the Common Transition Process (the requirements for EBERO Service Providers) in preparation for the EBERO RFP process that is underway. These changes add additional clarity to the process requirements and all providers selected as part of the RFP will be subject to the new requirements. No re-test has been conducted and none is scheduled at this time as the referenced tests were conducted with the permission of terminating gTLDs.
Review Team volunteers: Denise, Kerry-Ann, Zarko
Workstream: ICANN SSR
Topic 7: Perform an assessment how effectively ICANN has implemented its processes to ensure compliance regarding registrar agreements and the consensus policies.
Outstanding questions: 6
Q: In your experience, are the emergence thresholds fit for purpose? If not, are there any plans to revisit them with the community?
A: The emergency thresholds fit the purpose for which they were designed. There are no plans to revise them with the community.
Q: To what extent are the EBERO processes part of ICANN’s risk management framework?
A: EBERO capabilities are considered as part of ICANN's enterprise risk management efforts.
Q: To what extent have the relationships or contracts with EBERO providers been updated to take into account the changing security landscapes, information security requirements?
A: EBERO provider contracts are for 5 years. ICANN is currently running a Request for Proposal (RFP) to find EBERO providers for the next 5 years. Throughout the past five years, EBERO processes have been updated as needed when criteria have changed. The requirements for the next round of EBERO providers, to be identified in 2019, includes several updates to both EBERO processes and contract. It includes lessons learned from experience in EBERO operations as well as new language and amendments to cover data privacy and management (IT Security) of data.
Q: ICANN was not monitoring EPP. Is this still the case?
A: Correct, EPP is not currently being monitored.
Q: Please provide a progress report on the planned webpage with current information on common challenges for registry service providers, and suggested mitigation actions/proactive measures?
A: There is no planned webpage for this service.
Q: Is there a plan to continue research on the abuse of and possible safeguards in the DNS, and in particular with reference to New gTLDs, following the report on DNS abuse (commissioned by CCT Review Team)?
A: ICANN’s Office of the CTO will continue to provide anonymized reports from the Domain Abuse Activity Reporting (DAAR)<https://www.icann.org/octo-ssr/daar> system, which monitors the amount of spam, phishing, malware, and botnet domains in the DNS.
While DAAR is not a result of the CCT-RT’s work, it employs a similar methodology to that used in the DNS abuse study<https://www.icann.org/en/system/files/files/sadag-final-09aug17-en.pdf> they commissioned, and is referenced in the CCTRT’s recommendations regarding DNS abuse. The CCTRT also recommended continuing research on new gTLD safeguards and DNS abuse for future Review Teams. Currently, however, there are no specific plans for a study on gTLD safeguards.
The ICANN Board flagged some of the CCTRT’s recommendations relating to DNS abuse and safeguards as “pending,” to be addressed at a later time when certain pre-requisites have been met. If and when these recommendations are approved, ICANN org may carry out further research on DNS abuse and gTLD safeguards. For details, see the ICANN Board’s scorecard<https://www.icann.org/en/system/files/files/resolutions-final-cct-recs-scor…>.
Review Team volunteers: Eric, Denise, Norm, Boban
Workstream: Future Challenges
Topic: Coalescence of registrars/registry/backend operators for multiple TLDs
Outstanding questions: 0
Q: Is there a complete list of backend registry operators & escrow providers?
A: We do not have the authority to release some of this data. Approved Data Escrow providers are listed at https://newgtlds.icann.org/en/applicants/data-escrow
Q: Are there any measurements/ analysis/ testing of exercising the above functions?
A: There is no service defined for direct testing of RSPs. Data Escrow Agents are monitored via regular, monthly data escrow reports. Measurement or testing of RSP performance is done on a random basis.
Q: Is there a periodic report of domain names (number registrars, etc.)?
A: In terms of periodic summary reports, the Domain Name Marketplace Indicators initiative will shortly release a first wave of relevant indicators such as those identified in the question. This report is intended to be updated semi-annually, and should be accessible via https://www.icann.org/resources/pages/metrics-gdd-2015-01-30-en. The same webpage currently hosts some relevant statistics, albeit with less breadth and depth, under the 'gTLD Marketplace Health Index' heading.
Q: Are there higher security requirements for backend operators running multiple TLD’s?
A: The requirements in the base Registry Agreement apply to the Registry Operator signing the agreement. ICANN does not have a contractual relationship with backend operators, with the exception of backend operator that are also Registry Operators.
Q: Are there any and if so, what are the control mechanisms for operational availability of the TLD’s?
A: The control mechanisms are:
* data escrow, please refer to specification 2 of the base registry agreement.
* registry performance specifications, please refer to specification 10 of the base registry agreement.
* registry continuity, please refer to section 3, specification 6 of the base registry agreement.
* emergency transition (EBERO), please refer to section 2.13 of the base agreement.
* contractual and operational compliance audit, please refer to section 2.11 of the base agreement.
* continued operations instrument, please refer to section 2.12 of the base agreement.
--
Jennifer Bryce
Senior Reviews Coordinator
Internet Corporation for Assigned Names and Numbers (ICANN)
Email: jennifer.bryce(a)icann.org
Skype: jennifer.bryce.icann
www.icann.org
Dear all,
Please see below for a new clarification request, and the 5 outstanding requests for clarification on questions asked to ICANN org.
New request:
Review Team volunteers: Boban, Alain, Žarko
Workstream: ICANN SSR
Topic 2: Perform an assessment of ICANN's Business Continuity Management System.
Clarification requested: What is meant by “inter-org” dependencies? Which orgs? What is meant by “boundaries.”
1. Does ICANN have documented boundaries and processes that have inter-org dependencies? Do they relate back to BC plans?
Outstanding requests:
Review Team volunteers: Scott, Noorul
Workstream: ICANN SSR
Topic 4: Perform an assessment of how effectively ICANN has implemented its Security Incident Management and Response Processes to reduce (pro-active and reactive) the probability of DNS-related incidents.
Clarification requested: Can you please clarify if these questions are specific to the ICANN Managed Root Server or more generally for ICANN?
1. Which certifications is ICANN pursuing for the organisation and staff?
2. Which certifications and compliance frameworks has ICANN completed?
3. Who are ICANN’s auditors, what audits are completed regularly?
Review Team volunteers: Eric, Denise, Norm, Boban
Workstream: Future Challenges
Topic: Coalescence of registrars/registry/backend operators for multiple TLDs
Clarification requested: Can you please provide further context behind the question or clarify the question?
1. Has ICANN identified the issue of coalescence of registrars/registry operators in their risk management and what are the measures be taken?
2. Are there any and if so, what are the control mechanisms for operational availability of the TLD’s?
Best,
Jennifer
--
Jennifer Bryce
Senior Reviews Coordinator
Internet Corporation for Assigned Names and Numbers (ICANN)
Email: jennifer.bryce(a)icann.org
Skype: jennifer.bryce.icann
www.icann.org
Dear SSR2 RT,
The below answers have been added to the Q&A Google doc: https://docs.google.com/document/d/14eJwDGP-LvS9ltTmZoh1i19Fi0_pB2nJ4JYMsS7…. Please let us know if you have any questions.
Review Team volunteers: Laurin, Norm, Denise, Eric, Scott, Matogoro
Workstream: Future Challenges
Topic: Access to data and info: Research on important abuse and attack vectors
Outstanding questions: 0
Q: Does the TEG or some other group provide information about (future) abuse and attack vectors? Where?
A: There is no single and centralized repository for abuse and attack vectors maintained by ICANN.
Review Team volunteers: Russ, Kerry-Ann, Naveed
Workstream: ICANN SSR
Topic 5: Perform an assessment of internal security, stability and resiliency of ICANN's operation processes and services.
Outstanding questions: 0
Q: Previous question to ICANN org “We've been told that this particular contract that supported ICANN's gathering of this data does not allow it to display all of this data. Once ICANN understands what can and cannot be displayed, will they come back to the Board and community with the cost to report on everything? What would a new contract with a new provider potentially, or the same provider, need to look like in order to display more of that particular data publicly, and what would it cost?"
Previous answer from ICANN org “There are two things conflated here. One is the cost of curating and validating the data. This is the major cost and is covered by ICANN's budget transparency. The other is the cost of then defining which of the curated data we can publish and presenting that to the public. It is ICANN's intention to publish as much data that our licensing allows via ODI. This cost is not yet certain as we have not finalized the possible output but it is likely to be minimal."
This was reported on 15 months ago, what is the cost?
A: ICANN is contractually unable to release all data that it receives from its data providers. When this question was raised by the review team earlier, OCTO SSR queried the potential to be able to provide the data in its entirety but the data providers are extremely resistant to do so as it dismantles their own business model.
Review Team volunteers: Denise, Kerry-Ann, Žarko
Workstream: ICANN SSR
Topic 7: Perform an assessment how effectively ICANN has implemented its processes to ensure compliance regarding registrar agreements and the consensus policies.
Oustanding questions: 12
Q: Is OCTO going to provide public information on DAAR and its findings and how much will that cost?
A (updated to include cost information): ICANN started in February 2019, by publishing monthly reports from DAAR. We also intend to publish back dated reports. (Currently published back to June 2018. https://www.icann.org/octo-ssr/daar) Further publications may be possible and will be part of discussions with the community. Regarding cost, ICANN is contractually unable to release all data that it receives from its data providers. When this question was raised by the review team earlier, OCTO SSR queried the potential to be able to provide the data in its entirety but the data providers are extremely resistant to do so as it dismantles their own business model.
--
Jennifer Bryce
Senior Reviews Coordinator
Internet Corporation for Assigned Names and Numbers (ICANN)
Email: jennifer.bryce(a)icann.org
Skype: jennifer.bryce.icann
www.icann.org
