[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
Giovanni:
Please find the attached response to the questions. All of the implementation shepherds collaborated on the responses, and they represent our consensus.
Russ
= = = = = = = =
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
Rationale?
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
achieved?
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:
https://www.nist.gov/cyberframework/assessment-auditing-resources
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
registrations?
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