[ssr2-implementation-shepherds] SSR2 clarifying questions on Group-3 pending recommendations

Russ Housley housley at vigilsec.com
Mon Jun 20 19:48:41 UTC 2022


Please find the attached response to the questions.  All of the implementation shepherds collaborated on the responses, and they represent our consensus.


= = = = = = = =

Response to
SSR2 Pending - Further Clarification Clarifying Questions
for Implementation Shepherds

20 June 2022

SSR2 Recommendations 3.1, 3.2, 3.3, and 4.3

a. Given that recommendation 2.1 was rejected by the Board, could these
   dependent recommendations be successfully implemented by existing
   ICANN org security, planning and reporting positions and Board Risk
   committee detailed in 22 July 2021 Board Action Scorecard and Board

While the board has decided not to create the C-Suite position.  A single
point of responsibility for SSR-related topics is highly desirable.  The
implementation shepherds observe that having security report to operations
goes against accepted best practices.  The single point of responsibility
was intended to cover strategic security, tactical security, and risk
management.  The suggested way forward does not accomplish this goal.

b. Regarding SSR2 Recommendations 3.1, ICANN org's current plan for
   reporting framework and engagement reflects an annual cycle of
   reporting with two (2) milestones of publication per year. One of
   these two (2) milestones has already been implemented in the form of
   the Appendix D to the Five Year Operating and Financial Plan for
   FY23-27 (pages 262-264). Is this reporting in alignment with the
   SSR2 Implementation Shepherds intended outcomes?

No.  There is no transparency provided by these broad statements.

c. Regarding SSR2 Recommendations 3.2 and 3.3, SSR-related elements are
   included in ICANN’s Five Year Operating & Financial Plan and Annual
   Operating Plan and Budget, and the Five Year Strategic Plan. Extensive
   public consultation activities are in place with regard to these
   documents. See, for example, information about ICANN's strategic planning
   process and the most recent Public Comment proceeding on the draft
   Five-Year Operating & Financial Plan and draft Operating Plan & Budget.
   i.  Do the above mentioned elements generally address the intended
   purpose of recommendations 3.2 and 3.3?

No.  There is no transparency provided by these broad statements.  Further,
simply stating that an activity is "SSR related" does not allow the same
insight as a specific line dedicated to SSR.
   ii. Is there additional work beyond what is already in place to meet
   the requirements of the recommendation?

Yes.  Much greater visibility into the SSR-related activities and the cost
of each SSR-related activity is desired.

SSR2 Recommendation 4.3

a. Recommendation 4.3 suggests the appointment of a dedicated, responsible
   person in charge of security risk management, who will report to the
   C-Suite Security role, and update, report on and guide ICANN org's
   related security activities. ICANN has in place a risk management program
   that reports to the C-suite under the direction of the CFO.  It includes,
   and is significantly broader than, security-related risk management.
   Within this program, identified risks, their assessment rating and
   mitigation plans, including relative to security, are reviewed
   regularly, updated and reported to management and to the Board Risk
   Committee. These existing activities would appear to address the
   intended outcome of the recommendation. While not performed under the
   C-suite responsibility suggested in the recommendation, it is carried
   out under an existing C-suite executive which provides the appropriate
   executive-level visibility and accountability. Considering that even
   broader activities are already being carried out than those in this
   recommendation, and are already under the direction of a C-level
   executive, do the existing activities align with the intended outcomes
   for this recommendation, even if not reporting to a new C-level executive
   requested in dependent recommendation 2.1?

It is the understanding of the implementation shepherds that strategic
security and tactical security do not report to the CFO.  As stated above,
a single point of responsibility was intended to cover strategic security,
tactical security, and risk management.

b. Given that recommendation 2.1 was rejected, can recommendation 4.3 be
   successfully implemented by existing ICANN org security, planning and
   reporting positions and committees detailed in Board Action Scorecard?

At a minimum, placing strategic security, tactical security and risk
management under a single point of responsibility should be done.  The
position needs to have the authority to place security above other demands
of their time and other resources.

SSR2 Recommendation 5.3

a. All services onboarded through the Engineering and Information
   Technology function at ICANN org are required to have a Risk Assessment
   performed and documented. This risk assessment is used for the business
   to assess the risks of using those external services.  Is the intention
   of the recommendation to introduce the risk assessment requirement for
   any external party that provides services to ICANN org?

A risk assessment is only part of appropriate security governance and
management.  The implementation shepherds expect ICANN org to create a
policy that states what is expected from vendors.  A  based tiered approach
(low, medium, high) for risk, criticality, and sensitivity is one method.
Additionally, audit should cover the implementation of the agreed standards,
including follow up on mitigation measures where gaps are identified, as
stated by ICANN's chosen NIST Cybersecurity Framework when it comes to
supply chain security:

   "Suppliers and third-party partners are routinely assessed using
   audits, test results, or other forms of evaluations to confirm
   they are meeting their contractual obligations." (ID.SC-4)

SSR2 Recommendation 7.1, 7.2, 7.3, and 7.5

a. Would the SSR2 Implementation Shepherds consider 7.1, 7.2, 7.3, 7.5 to
   be successfully implemented and effective in the event that the Board
   rejects Recommendation 7.4 regarding opening a non-U.S., non-North
   American site, and that portion of the success measure cannot be

Not fully, but they would be partially implemented.

SSR2 Recommendation 7.1

a. ICANN org reading of this recommendation is that the SSR2 RT has
   conflated the goal of Business Continuity Management for the whole of
   ICANN org, such as what ISO 22301 calls for, with the goals of
   operational plans for systems disaster recovery to support operational
   business continuity.  In light of ICANN org's interpretation, can the
   implementation shepherds please clarify the intent of this recommendation?

As indicated by the section heading, the goal is BOTH Business Continuity
and Disaster Recovery.

SSR2 Recommendation 7.2

a. The recommendation states "... includes all relevant systems that
   contribute to the security and stability of the DNS". Since ICANN does
   not own/operate all of the systems that contribute to the security and
   stability of the DNS, can the Implementation Shepherds confirm that the
   scope of this recommendation is meant to only cover systems owned and
   operated by ICANN org?

Correct, this recommendations is aimed at the systems owned and operated by
ICANN org.  The SSR2 RT is asking ICANN org to lead by example!

b. This recommendation calls for a DR plan that is in line with ISO 27031
   but ICANN org is seeking clarification to this approach in recommendations
   7.1 and 7.3.  Once the clarifying questions are answered and a decision
   is made regarding adopting ISO 27031, do the Implementation Shepherds find
   it acceptable for this recommendation to follow the same approach?

The implementation shepherds understand that ICANN will use the NIST
Cybersecurity Framework, and the implementation shepherds think this is
a reasonable alternative as long as the implementation is transparent
to the community, and is regularly audited and attested by a third party.
NIST provides a number of resources regarding audit:


SSR2 Recommendation 7.3

a. The recommendation specifies ISO 27031.  ICANN org has already commenced
   adoption and implementation of applicable NIST standards.  Would the
   Implementation Shepherds consider if other standards such as
   NIST SP 800-34 Rev 1 would meet the requirements of the recommendation?

The implementation shepherds understand that ICANN will use the NIST
Cybersecurity Framework, and the implementation shepherds think this
well accepted standard a reasonable way forward as long as the
implementation is transparent to the community so that there is an
opportunity to identify and remedy gaps. Regular external, attested
audits of the implementation of framework and the resulting controls
is most critical for establishing a constantly evolving security
program and stature.

SSR2 Recommendation 7.5

a. The recommendation proposes publishing information that is potentially
   confidential or may lead to exposure of sensitive operational details.
   Would the Implementation Shepherds accept this item fulfilled if the
   ICANN Org provided such reports to the ICANN Board?

The SSR2 RT used the word "summary" so that the information could be
provided at a level that avoids exposure of sensitive operational details.
Reports to the ICANN Board DO NOT provide the transparency that is desired.

b. The recommendation proposes that the ICANN Org use a 3rd party auditor
   to review the BC and DR plans to some level of "compliance", can the
   Implementation Shepherds provide insight on the expected cadence of such
   audits that would meet the Implementation Shepherd's view as sufficient.

Such audits are common practice.  The implementation shepherds would
expect to see regular audits as part of routine audits performed at
ICANN Org internally and by third-party, independent auditors, as is
common practice.  The sufficient cadence depends on the results of the
previous audit and the associated remedies, if any are needed.

SSR2 Recommendation 9.3

a. What "Compliance activities" do the SSR2 Implementation Shepherds
   intend to be audited?
b. What would be the scope of the audits?

c. What standards would Compliance be audited against?

d. What kinds of information would be requested that is not currently
   already published within the ICANN Contractual Compliance Dashboard, or
   the ICANN Contractual Compliance Twelve-Month Trends Report.

The implementations shepherds agree that the recommendation could have
been more clear.  The ideal would be to follow the ISO 9000, setting goals,
strategies, policies, and so on.  Then, ICANN should have regular, third
party audits conducted against the relevant quality management program to
ensure that all of them are being met in practice.

SSR2 Recommendation 11.1

a. ICANN org notes that this recommendation appears to relate to and be
   in support of SAC097. As the Board notes in the rationale for actions
   taken on Recommendation 11.1, ICANN org is currently in the process of
   implementing recommendations from SAC097, which calls for ICANN org to
   revise "the [Centralized Zone Data Service] CZDS system to address the
   problem of subscriptions terminating automatically by default, for
   example by allowing subscriptions to automatically renew by default."
   ICANN org has provided the Board information regarding a plan to
   approach and accomplish the recommendations in SAC097.  ICANN org also
   provides quarterly updates on the status of implementation via the
   Action Request Register.  Please confirm the correctness of our
   understanding that this recommendation is in support of SAC097.

The SSR2 report points to the overlap with SAC097.  Please keep in
mind that SSR2 RT was concerned about the large number of unaddressed
CZDS-related complaints, and the SSR2 RT metric of effectiveness is
that these complaints stop because CZDS users are satisfied with the
CZDS service.  To that end, the SSR2 RT wants to ensure that access
to CZDS data is available even if all of SAC097 is not implemented by
the ICANN Board.

SSR2 Recommendation 24.1

a. Is the SSR2 Review Team's intent for ICANN org to conduct Emergency
   Back-end Registry Operator (EBERO) testing on "live" gTLDs with

No, EBERO testing on "live" gTLDs is not anticipated.

> On May 18, 2022, at 12:56 PM, Giovanni Seppia via ssr2-implementation-shepherds <ssr2-implementation-shepherds at icann.org> wrote:
> Dear Kerry-Ann, KC, Russ and Laurin,
> I hope this message finds you well.
> Please find attached the next set of SSR2 clarifying questions on Group-3 pending recommendations.
> The scorecard for the whole SSR2 recommendations can be found at https://www.icann.org/en/system/files/files/ssr2-scorecard-22jul21-en.pdf <https://www.icann.org/en/system/files/files/ssr2-scorecard-22jul21-en.pdf>
> It would be great if you could send us your feedback by 20 June 2022 at the latest.
> I remain available for any further information and/or clarification you may need.
> Kind Regards,
> Giovanni
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/ssr2-implementation-shepherds/attachments/20220620/1c004b44/attachment-0001.html>

More information about the ssr2-implementation-shepherds mailing list