[Ssr2-review] ICANN SSR answers

Jennifer Bryce jennifer.bryce at icann.org
Mon Mar 4 08:12:36 UTC 2019


Dear all,

Below are some ICANN SSR workstream answers. The complete list of questions and answers is here: https://docs.google.com/document/d/14eJwDGP-LvS9ltTmZoh1i19Fi0_pB2nJ4JYMsS7lsco/edit

Review Team volunteers: Russ
Workstream: ICANN SSR
Topic: Perform an assessment of internal security, stability and resiliency of ICANN's operation processes and services.
Subtopic: DAAR

Q: What curated data is now considered publishable?  Is there documentation with version control, is there a permanent link?
A: ICANN has started to publish monthly reports to the public. Those can be found at  https://www.icann.org/octo-ssr/daar. ICANN currently also have plans to report the data behind these reports, number of names in zone, number of names on reputation lists by abuse type to the specific registry operators for each TLD that they manage.
 ----
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.”

Q: What steps are taken to provide this crucial information? What methodology is ICANN following? Is there documentation with version control, is there a permanent link?
A: The steps for curating data are published in the DAAR methodology paper, posted to ICANN.org here: https://www.icann.org/octo-ssr/daar. The direct link is here: https://www.icann.org/en/system/files/files/daar-methodology-paper-30nov17-en.pdf

Outstanding questions in this topic: Yes
----
Review Team volunteers: Denise, Kerry-Ann
Workstream: ICANN SSR
Topic: Perform an assessment how effectively ICANN has implemented its processes to ensure compliance regarding registrar agreements and the consensus policies.
Subtopic: OCTO, open data initiative, and GDPR

Q: Is OCTO going to provide public information on DAAR and its findings and how much will that cost?
A: 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. Note, the answer to the cost part of this question is outstanding.

Outstanding questions in this topic: Yes
---
Review Team volunteers: Matogoro, Alain, Noorul
Workstream: ICANN SSR
Topic: Perform an assessment of ICANN's Information Security Management System

Q: Please also provide information related to lines of communications in the event of a digital incident (e.g. who is ‘first responder’?)
A: The lines of communication for digital incidents are simple and efficient and are always dependent on the incident and potential risk (encompassing impact and likelihood). Generally, and Generically, the first responder will be the ICANN Org internal InfoSec team’s CSIRT, comprised of the ICANN Org InfoSec team. Should triage reveal that a situation should be escalated to the Senior Director of Security and Network Engineering (SaNE). Should that person be unavailable for any reason the issue is escalated to the Chief Information Officer. In either case, upon advice from the InfoSec CSIRT, the Snr Dir of SaNE or the CIO may stand up the ICANN CIRT. The ICANN CIRT is comprised of (or their delegates): ICANN General Counsel, VP of Communications, Director of Security Operations (Physical security), The Snr Director of Security and Network Engineering, the CIO, the responsible business owner of the impacted system, and any other Ad-Hoc subject matter experts as deemed appropriate and relevant by the ICANN CIRT. The ICANN CIRT may/will advise the ICANN CEO at the appropriate time.

Q: Are there any changes in the organization regarding security management since October 2017?
A: In late 2017, the ICANN Engineering and Information Technology went through a reorg and as a part of that the ICANN Cybersecurity Team was moved under the Snr Director of Security and Network Engineering. The Distributed Information Security Management Model (DISMM) was also adopted at that time. In June 2018 the Director of Cybersecurity (Geoff Bickers) left the ICANN organisation. Those responsibilities were transferred to the Snr Director of Security and Network Engineering (Terry Manderson)

Q: Per ICANN org answer to a previous question, “The ICANN org uses a suite of continuous improvement frameworks to drive improvement across the organization. This includes the use of audit and certification frameworks for Engineering and IT, and IANA functions, and EFQM as a holistic framework for assessing and improving the whole organization.”

     *   Are the topics within ISM covered by these frameworks and/or standards? (ICANN should follow an organizational information security management standard like ISO/IEC 27001 or NIST 800-xx to be sure to cover all relevant topics related to an information management security system).
A: Until the end of 2017 ICANN was using ISM Controls covered by Center for Internet Security Critical Security Controls (CIS 20), on evaluation it was deemed and accepted that the NIST Cybersecurity Framework (CSF) was (by far) more applicable to ICANN and its business. It is expected that the migration from CIS 20 to NIST CSF will be completed by June 2020 with current resources.

Outstanding questions in this topic: Yes
---
Review Team volunteers: Scott, Noorul
Workstream: ICANN SSR
Topic: 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.


Q: ICANN has engaged HackerOne to run their Vulnerability Disclosure Policy (VDP) and Bug Bounty Program (BBP). However, it appears the onboarding and deployment of such program is still in progress and not complete. (https://www.icann.org/vulnerabilities; https://hackerone.com/icann). What is the timeline for completing, implementing and public launch of the VDP and BBP? Is there resourcing or budget reasons for the delay? Are reports on incidents required? How are they released, and on what schedule?
A: The HackerOne engagement has been completed (as of November 2018). Public reports, by ICANN, are only required if there is a resulting compromise and operational impact on systems or data.

Q: This vulnerability disclosure doc dates back to 2013. https://www.icann.org/en/system/files/files/vulnerability-disclosure-05aug13-en.pdf. Why have there been no obvious updates since 2013, is the process as outlined in the PDF still followed?

A: The vulnerability disclosure published in 2013 has been redacted. A new internal document “InfoSec Best Practice: Vulnerability Reporting“ is used.

Outstanding questions in this topic: Yes

Subtopic: Security Incident Management Process (ICANN Internal)

Q: Is there periodic reporting? How are incidents reported on? Is there version control, is there a permanent link?
A: Public reports are based on the ICANN Transparency Guidelines and reported here: https://www.icann.org/cybersecurityincidentlog (as per above, note that 2013 document vulnerability-disclosure-05aug13-en.pdf has been deprecated and needs to be removed)

Q: Are there formal procedures for SIMP at ICANN, can you provide a document that outlines them? Is there version control, is there a permanent link?
A: The public facing portion of incident reporting can be found here: https://www.icann.org/resources/pages/report-security-issues-2018-05-24-en ( a direct link is available from the ICANN Homepage https://www.icann.org/ under ‘contact us’)

Q: Were there only incidents in 2017, nothing available about 2018 for example? Has an updated report been published?
A: Please see https://www.icann.org/cybersecurityincidentlog

Q: Where is the “single page” you mentioned 15 months ago (see transcript) about the SIMP process? Is there a permanent link?
A: Please see : https://www.icann.org/resources/pages/report-security-issues-2018-05-24-en and https://www.icann.org/cybersecurityincidentlog

Q: Where is that policy that was said to be updated 15 months ago (see transcript)? Is there version control, is there a permanent link?
A: ICANN Org has a new simpler more efficient guideline. “InfoSec Best Practice: Vulnerability Reporting.” (internal doc)

Outstanding questions in this topic: No

Subtopic:  Security Incident Response Process relating to a global, IANA incident (DNS-related)

Q: How is this being done, is there a structure and process? Is there version control, is there a permanent link?
A: The same processes and best practises used at ICANN apply for the systems for IANA. However, a global issue may result in the executive Global Crisis Management Team being convened.

Q: Is there periodic reporting, if so, where? Is there version control, is there a permanent link?
A: The same processes and best practises used at ICANN apply for the systems for IANA. However, a global issue may result in the executive Global Crisis Management Team being convened.

Outstanding questions in this topic: No

Subtopic: ICANN operational responsibilities (L-Root)

Q: What are the processes to secure L-Root, are they being published? As it is the “best practice” case, this appears sensible. Is there version control, is there a permanent link?
A: The ICANN Managed Root Server [IMRS] publishes responses to the appropriate RSSAC publications. (https://www.dns.icann.org/rssac)  to date those are:  RSSAC001, RSSAC002, RSSAC0024, RSSAC0037

Outstanding questions in this topic: Yes
--
Jennifer Bryce
Senior Reviews Coordinator
Internet Corporation for Assigned Names and Numbers (ICANN)

Email: jennifer.bryce at icann.org
Skype: jennifer.bryce.icann
www.icann.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/ssr2-review/attachments/20190304/de43551b/attachment.html>


More information about the Ssr2-review mailing list