[Ssr2-review] ICANN SSR and Future Challenges answers

[Jennifer Bryce]

Dear SSR2 RT members,

The below answers has been added to the Q&A Google doc: https://docs.google.com/document/d/14eJwDGP-LvS9ltTmZoh1i19Fi0_pB2nJ4JYMsS7lsco/edit?usp=sharing [docs.google.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_document_d_14eJwDGP-2DLvS9ltTmZoh1i19Fi0-5FpB2nJ4JYMsS7lsco_edit-3Fusp-3Dsharing&d=DwMGaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=VuRMFw6YascG5ysc1jEHBZgGTtD6QSLrFmqdvMx5FM8&m=hxj2juBnL5SI2_a2ShzX2n6QIksiETU2ES0QpYAdac8&s=2ccPlHIHQA6bJ48H2PKPem1o_nHyeaJbMNxUNcVNbg8&e=>. Please let us know if you have any questions.

Review Team volunteers: Boban, Alain, Žarko
Workstream: ICANN SSR
Topic 2: Perform an assessment of ICANN's Business Continuity Management System.
Outstanding questions: 1

Q: What is the frequency of DR testing?
A: As it relates to systems, disaster recovery fail-over between data centers is tested annually.

Q: Was an impact analysis done after PTI separation to asses needed for update to BC plans?
A: PTI, the affiliate with which ICANN contracts for the performance of the IANA Functions, is not separate from ICANN.  As noted through the IANA Stewardship Transition process, a separate contracting entity was created in the event that it was determined that the performance of the IANA Functions needed to be separated.  As anticipated, there is little functional change in how the IANA Functions are actually performed, including the systems through which those services are performed.  ICANN and PTI entered into a shared services agreement (https://www.icann.org/iana_pti_docs/153-services-agreement-v-30sep16), which is common in affiliate and spin-off relationships, through which ICANN commits to provide services to support the IANA activities, as well as commits ICANN to coordinate and maintain business continuity efforts.  As a result, the IANA Stewardship Transition did not have an impact on ICANN’s business continuity plans.

Q: Has ICANN implement the recommendations of the following exercise: IANA Full‐Scale Business Continuity Exercise Conducted 19 January 2010 (https://www.icann.org/en/system/files/files/iana-business-continuity-exercise-aar-23feb10-en.pdf)
A: Yes.  Over time, IANA procedures have matured and evolved to incorporate the types of recommendations in that report.

Q: Does ICANN's top management and /or the responsible person) established and published a documented organization business continuity policy?
A: These documents are confidential and not published publicly for security reasons.  There is an established Disaster Recovery plan for systems, a Continuity Plan for the IANA Functions, and a broader Continuity Plan under development for the wider ICANN organization to be delivered in 2019.

Q: Does ICANN have a documented Policy concerning the procurement, provision and management of outsourced good and services via its supply chain?
A: Yes. See https://www.icann.org/en/system/files/files/procurement-guidelines-21feb10-en.pdf

Q: Does ICANN have a documented business continuity operational planning and control process that enables it to determine, plan, implement and control those actions needed to fulfil its business continuity policy and objectives?
A: These documents are confidential and not published publicly for security reasons.  There is an established Disaster Recovery plan for systems, a Continuity Plan for the IANA Functions, and a broader Continuity Plan under development for the wider ICANN organization to be delivered in 2019.

Q: Does ICANN have a formal documented standard procedure and evaluation process for conducting a Business Impact Analysis (BIA)?\
A: ICANN has carried out a BIA in the past.  Providing detailed information on such results could highlight vulnerabilities to the organization.  The revised Continuity Plan, discussed in response to other questions, will be more focused on resource substitution until a disaster recovery is complete generally, rather than making scenario assumptions.  BIA implies a certain speed of resource recovery which in practice may be much different than expected.  That is, there should be contingency plans for all important resources, dispensing with a detailed analysis based on recovery time assumptions which may not hold in a crisis.

Q: Has ICANN carried out a BIA to identify its prioritized activities? If so, what was the results?
A: ICANN has carried out a BIA in the past.  Providing detailed information on such results could highlight vulnerabilities to the organization.  The revised Continuity Plan, discussed in response to other questions, will be more focused on resource substitution until a disaster recovery is complete generally, rather than making scenario assumptions.  BIA implies a certain speed of resource recovery which in practice may be much different than expected.  That is, there should be contingency plans for all important resources, dispensing with a detailed analysis based on recovery time assumptions which may not hold in a crisis.

Q: Is there a documented Business Continuity Resumption/Recovery Strategy(ies) for the ICANN's prioritized activities their support resources and dependencies that has been signed off by top management?
A: These documents are confidential and not published publicly for security reasons.  There is an established Disaster Recovery plan for systems, a Continuity Plan for the IANA Functions, and a broader Continuity Plan under development for the wider ICANN organization to be delivered in 2019.

ICANN has carried out a BIA in the past.  Providing detailed information on such results could highlight vulnerabilities to the organization.  The revised Continuity Plan, discussed in response to other questions, will be more focused on resource substitution until a disaster recovery is complete generally, rather than making scenario assumptions.  BIA implies a certain speed of resource recovery which in practice may be much different than expected.  That is, there should be contingency plans for all important resources, dispensing with a detailed analysis based on recovery time assumptions which may not hold in a crisis.

Q: Is there a documented Resource Recovery Strategy for critical business activities and their dependencies that has been signed off by top management, which includes the identification of critical assets on a scheduled basis? If so, is the strategy based upon and consistent with the resource recovery requirements identified within the current BIA in respect to ICANN's prioritized activities their support services and dependencies recovery profile?
A: These documents are confidential and not published publicly for security reasons.  There is an established Disaster Recovery plan for systems, a Continuity Plan for the IANA Functions, and a broader Continuity Plan under development for the wider ICANN organization to be delivered in 2019.

ICANN has carried out a BIA in the past.  Providing detailed information on such results could highlight vulnerabilities to the organization.  The revised Continuity Plan, discussed in response to other questions, will be more focused on resource substitution until a disaster recovery is complete generally, rather than making scenario assumptions.  BIA implies a certain speed of resource recovery which in practice may be much different than expected.  That is, there should be contingency plans for all important resources, dispensing with a detailed analysis based on recovery time assumptions which may not hold in a crisis.

Q: Does ICANN have documented business continuity plans in respect of each of the prioritized activities and their dependencies?
A: These documents are confidential and not published publicly for security reasons.  There is an established Disaster Recovery plan for systems, a Continuity Plan for the IANA Functions, and a broader Continuity Plan under development for the wider ICANN organization to be delivered in 2019.

ICANN has carried out a BIA in the past.  Providing detailed information on such results could highlight vulnerabilities to the organization.  The revised Continuity Plan, discussed in response to other questions, will be more focused on resource substitution until a disaster recovery is complete generally, rather than making scenario assumptions.  BIA implies a certain speed of resource recovery which in practice may be much different than expected.  That is, there should be contingency plans for all important resources, dispensing with a detailed analysis based on recovery time assumptions which may not hold in a crisis.

Q: Does each plan contain predefined task checklists that includes mandatory and discretionary tasks together with individuals/roles/teams responsible for their completion and a process for tracking they're completion within an allocated timeframes?
A: No, as previously stated, the plan will focus on resource recovery generally.

Q: Does ICANN have a documented exercise/testing programme and process for business continuity procedures, plans and arrangements? The last available exercise is from 2009: https://www.icann.org/en/system/files/files/gtld-registry-continuity-plan-25apr09-en.pdf
A: The referenced document relates to backup registries, rather than continuity at ICANN itself.  The continuity plan being developed for the organization will include testing.  Systems disaster recovery testing is done annually.

Q: Depth of testing of DR needs to be elaborated on (Table top vs power trip). Are there any results of power trip exercises?
A: Systems disaster recovery tests are actual failover tests. All systems were successfully recovered failing-over from primary to secondary.

Q: Does ICANN conduct performance evaluations of its business continuity procedures, arrangements and capabilities in order to verify their continued suitability, adequacy and effectiveness?
A: The continuity plan will be reviewed periodically, with testing, which would achieve what this question seems to be asking.

Q: Does ICANN have documented boundaries and processes that have inter-org dependencies? Are they relate back to BC plans?
a.                   Clarification requested from Boban, Alain, Zarko: What is meant by “inter-org” dependencies?  Which orgs?  What is meant by “boundaries.”
b.                   ICANN org has asked for clarification as to the meaning of this question, and is awaiting a response.  That said, based on current understanding, ICANN org thinks the answer is no, not beyond the shared services agreement between ICANN and PTI.

Q: Does ICANN conduct internal audits at planned intervals to provide information on whether the Business Continuity Management is effectively implemented and maintained?
A: Periodic testing and validation by the Risk Management function will be an important part of the Continuity Plan being developed this year.


Review Team volunteers: Laurin, Boban, Žarko, Kerry-Ann
Workstream: ICANN SSR
Topic 3: Perform an assessment of ICANN's Risk Management Methodology and Framework.
Outstanding questions: 0

Q: As of Oct 2017, ICANN did not follow formal information security audit frameworks such as ISO 27001. Is that still the case?
A: That statement is incorrect.  ICANN org has carried out assessments based on the CIS20 Cyber Security Framework starting in 2014.  During 2018, ICANN transitioned to the NIST Cyber Security Framework.  The benchmarking assessment has been done annually by a consulting firm with expertise in such assessments.  In addition, two annual information security audits are performed related to the IANA Functions.  The IANA department has been performing SOC3 audits on the Root Zone Key Signing Key Operator System since 2010, and SOC2 audits on the Registry Assignment and Maintenance System since 2013.  Those audits are performed by external auditors.

Q: Are there any plans to adopt a formal framework?  If so, please give details of the framework, timeline for implementation and budget allocated. If not, provide reasoning for pursuing a formal framework.
A: ICANN org has carried out assessments based on the CIS20 Cyber Security Framework starting in 2014.  During 2018, ICANN transitioned to the NIST Cyber Security Framework.  The benchmarking assessment has been done annually by a consulting firm with expertise in such assessments.  In addition, two annual information security audits are performed related to the IANA Functions.  The IANA department has been performing SOC3 audits on the Root Zone Key Signing Key Operator System since 2010, and SOC2 audits on the Registry Assignment and Maintenance System since 2013.  Those audits are performed by external auditors.

Q: Please provide documentation (links/perma-links) about your business continuity and risk management processes.
A: ICANN org is not able to provide links to these processes, as this detailed information is confidential and unable to be shared due the nature of risk management, which may involve vulnerabilities and threats to the organization.  Therefore, it would not be prudent to provide details of those vulnerabilities and threats nor details of the countermeasures ICANN takes or would take to counter vulnerabilities and threats.

In general, however, ICANN org has a risk management policy and risk identification process.  The policy and the process are reviewed by a Risk Management Committee made up of the org executives, approved by the President and CEO, and reviewed by the Board Risk Committee.  Key elements of the policy have been presented to the full Board.
A Continuity Plan is under development for ICANN organization and will be delivered later in 2019.  That Continuity Plan will also be reviewed by a committee of the org executives, approved by the President and CEO, and reviewed by the Board Risk Committee.
ICANN org is planning to develop public risk management reporting in 2019 which would highlight some of our risk management activities.

Q: Is James Caulfield still the person responsible for risk and business continuity management?
A: Yes.


Q: There is a Board Risk Committee which meets at least twice a year, and considers the risk register.  Is this still the case?  The Committee organises an interactive risk workshop at least once a year, is that still the case? Please give dates of meetings since 2016, along with attendees, agendas, and outcome reports.
A: Yes and yes.  Minutes of the Board and Board Committee meetings are a matter of public record and can be found here:  https://www.icann.org/resources/pages/minutes-2014-03-24-en



Q: Please confirm that the risk register is updated on an ongoing basis, and give evidence of these updates.
A: Yes, the Risk Register is updated regularly.  Please refer to the Board Risk Committee minutes.

Q: Relevant managers are responsible for declaring a disaster.  Is this still the case?
A: ICANN organization has a crisis management policy that defines the roles and responsibilities for declaring a crisis.  Per that policy, it is the responsibility of executive management to determine whether a crisis is in progress.


Review Team volunteers: Denise, Žarko, Kerry-Ann
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: 3

Q: Is there are separate risk management framework (including risk register and business continuity plan) for the PTI?
A: There is a separate continuity plan for the IANA Functions, and that plan is also included in the ICANN organization risk management framework.

Q: IANA (PTI) systems (both IT and operational) continue to be dependent on ICANN.  When PTI staff login in the morning, they are on the ICANN secured network, correct?  Is this still the case? Note: may want to address this off the public list/wiki)
A: ICANN org is unable to provide a specific response to this question due to system security concerns.  Further, ICANN org understands that a response has already been provided in the questions answered by the IANA functions regarding the level of network access security.

Q: Within risk classification or scoring, there is no multiplier for potential impact on the internet’s system of unique identifiers.  Is this still the case?
A: Yes, there is no multiplier, and we do not see that as a standard risk management approach.

Review Team volunteers: Noorul, Kerry-Ann, Eric, Laurin, Norm
Workstream: Future Challenges
Topic: Root server system protection: assess the threatscape of top threats (e.g. DDoS to the root system)
Outstanding questions: 0

Q: What does staff and the community already do regarding emerging and future threats, and related issues? We are aware of efforts focused on emerging technologies; are there ones that focus on threats too?
A: Emerging risks are treated in the usual risk management process.  For example the recent DNS threat alert:  https://www.icann.org/news/announcement-2019-02-15-en


--

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/20190412/afef4013/attachment.html>