[council] ATRT2 Security and Stability Review Team input

[Maria Farrell]

Hi all,

I undertook on our last call to pull together some initial thoughts to
guide us on our session with the ATRT2 next week in BA.

I hadn't quite anticipated how long the whole report is...

Now focusing on the GNSO PDP side of it, but in the meantime here are some
possible pointers on the SSR RT draft report - pasted below.

You'll find the reports proper here:
http://www.icann.org/en/news/public-comment/atrt2-recommendations-21oct13-en.htm

All the best, Maria

  ATRT2 Report(s)



*Appendix C – SSR Review Implementation*



Recommendations 1 - 9 largely on definition of terms, role,
responsibilities, priorities of SSR in the ICANN context, possibilities for
external certification of functions including IANA, SSAC key management and
IT, and also about adequately resourcing the SSR function within the
organisation. They all sound supportable and worthwhile, especially on
external and community-wide coordination and continuing the now established
annual reporting requirements for the function.



One question, though, why was budget information on support for SSAC and
RSSAC apparently redacted? (Maybe it’s available elsewhere in the annual
budget – I just haven’t checked and didn’t immediately see why it wasn’t
here. Shouldn't that info be available, and if not, why not?)



*Rec. 10*

“ICANN should continue its efforts to step up contract compliance
enforcement and provide adequate resources for this function. ICANN should
also develop and implement a more structured process for monitoring
compliance issues and investigations.”



Reporting and recommendations on Rec. 10 on compliance seems weak, possibly
because the recommendation is somewhat vague(it just says to ‘increase
enforcement efforts’, so any increase, however small, is implementation).
ATRT2 states several times that the level of compliance or its allocated
resources are adequate are *subjective evaluations*.  It also notes
community concerns that resources may not be sufficient for future
compliance demands of new RAA and RA.



Essentially ATRT2 says improvements have been made but doesn’t attempt to
say if they are enough, as that would be subjective. Given contract
compliance and enforcement are at least partly empirically measurable, and
we have metrics to show and track progress, is the ATRT2 response itself
adequate? If we have no current way of measuring whether compliance work is
sufficient and sufficiently resourced, shouldn’t we look at developing some?



*Rec. 11*

“ICANN should finalize and implement measures f success for new gTLDs and
IDN Fast Track that expressly relate to its SSR-related program objectives,
including measurements for the effectiveness of mechanisms to mitigate
domain name abuse.”



ATRT2 reports that nothing’s yet been done on this and it’s a
community-staff collaboration.



Is this priority being fed into any existing policy or implementation
processes, and, if not, does or should the GNSO have a role in moving it
forward?





*Rec. 12*

“ICANN should work with the community to identify SSR-related best
practices for the community and encouragement for putting those best
practices into contracts, agreements, MOUs and other mechanisms.”



This was supposed to trigger a staff community dialogue on which
SSR-related best practices might be relevant and how they should be
incorporated. Registry input questioned whether contracts were the best way
to do this. No dialogue explicit to the recommendation has happened, though
the ATRT2 report includes law enforcement input to the RAA as part of it.



As the RAA and RA negotiations are not subject to full community dialogue,
should the ATRT2 seem to be accepting that even some indirect progress has
been made on this item? Is there going to be any process to identify best
practices, analyse whether they should be linked to contracts and subjected
to full community dialogue? If not, then perhaps the ATRT2 report should
red flag this one as not begun, not implemented and not having any way
forward currently foreseen.



*Rec. 13*

“ICANN should encourage all SOs to develop and publish SSR-related best
practices for their members.”



The ccNSO is already doing this and the report on actions taken says staff
is ‘reaching out’ to the GNSO.



While this all sounds good and worthwhile, how relevant is the
recommendation to the very heterogeneous GNSO? (I may well be missing the
connection here and would be happy to be corrected.) It may be that this
recommendation isn’t ever going to be implemented fully.



Which raises a larger question; is there a means for ATRT reviews to
suggest previous recommendations for retirement, in a way that includes
public consultation? (I don’t imply that there isn’t such a mechanism –
just asking the question.)



*Rec. 14*

Ensure SSR-related outreach evolves to stay relevant and useful, with
feedback from the community.



>From the report, this seems to be happening and being done increasingly and
well, though I’m not sure what if any the transparent feedback mechanisms
are (or if they are further needed – just raising an open question).



*Rec. 15*

“ICANN should act as facilitator in the responsible disclosure and
dissemination of DNS security threats and mitigation techniques.”



Implementation seems to be going fine, though some concerns expressed about
escalating reports. Coordinated Vulnerability Disclosure guidelines
published to help. Unclear whether ICANN really is a needed locus for this.




 *Rec. 16*

Get more community and ecosystem input into SSR Framework development
process. No process for ecosystem input.



Very few public comments to SSR Framework – despite a lot of effort from
staff to elicit it that I’ve personally noticed. Better explaining ICANN’s
SSR role to outside organisations has helped encourage feedback from them.



Should ICANN have a less informal process for getting input from other
organisations?



*Rec. 17*

More structured internal process to show how SSR work done relates to
priorities in SSR framework, with metrics and milestones.



Implementation underway and slotting into Strategic Plan and project
management organisation-wide.



This is something of a no-brainer for us to encourage, I think, and look
forward to next ATRT reviewing and finding it pretty much embedded.



*Rec. 18*

Do an annual SSR operational review in the annual SSR Framework.



Done & embedded. Great!



*Rec. 19*

Establish something like a dashboard to let community track implementation
of SSR framework.



This will be done through the ‘At Task’ management system. Not yet
implemented, but something we would probably welcome.



 *Rec. 20*

More transparent info on organisation and budget of SSR work.



ccNSO and others said to previous ATRT there needs to be more info on this.
It’s apparently coming in the FY14 budget and plan and related ‘At Task’
tracking.



Registries strongly support more transparency on this. I expect most of
GNSO probably does, too, and we might say so when we meet ATRT2.



*Rec. 21*

More structured internal process to show how organisation and budget
decisions related to SSR Framework, ‘including the underlying cost-benefit
analysis’.



Happening through FY14 op plan and budget, and ‘At Task’ but not yet done.



It’s too early for community feedback on ‘how’ it’s being done, but we may
want to support it being done, and soon.



*Rec. 22*

Publish, monitor and update documentation on organisational and budget
resources to manage SSR issues re. New gTLDs.



Implementation underway as above, too early to see if it’s effective.



Again, perhaps a simple recommendation that this is important and should
get done sooner rather than later, especially if we think that increased
resources may be needed wrt new gTLDs.



*Rec. 23*

Provide enough resources for SSR related working groups and advisory
committees, and ensure they make decisions “in an objective manner that is
free from external or internal pressure.”



Security related work is done across all of ICANN SOs and ACs as well as
SSAC and RSSAC. Previous ATRT report said RSSAC probably had enough support
but SSAC was under resource pressure. Work is being done to inventories SSR
work across SOs and ACs. Results still TBA. RSSAC and SSAC chairs say
requests for funds not turned down but staff support a little thin.



Budget for SSAC and RSSAC redacted – not sure why.



“WRT to ensuring decisions reached objectively and are free from pressure,
this component of the recommendation has yet to be implemented.”

This seems a little dismissive – is / can analysis be done to ensure this?
If not, why not and should it be attempted?



*Rec. 24*

Define role of Chief Security Officer Team.

Implemented in FY13 SSR Framework though with infographics rather than text.



ATRT2 says its happy with the security team taking a ‘somewhat dynamic’
approach so they can respond to emerging issues. Does this sound fair? (It
does to me – but others may differ.)



*Rec. 25*

Put in place mechanisms to identify near and longer term risks and
strategic factors, informed by research, business partnerships SOs and
others. Publish this, recognising some may be too sensitive.



ICANN hired Westlake Governance to develop a DNS Risk Managmenet Framework.
Draft was presented in Beijing and upfor comment in Durban – staff now
working on implementing along with work of DSSA Working Group.



Public comments supported a stronger risk management function at ICANN. In
public comments on Westlake report there was “significant disappointment
that the work of the DSSA WG wasn’t incorporated more fully into the DNS
Risks Framework” and that “the choice of framework architecture (ISO31000
over NIST 800-30) may have been sub-optimal.” And that DNS Risks Framework
too limited in terms of ICANN’s overarching SSR-related responsibilities.
Staff says the DSSA WG work will be incorporated.



ATRT concludes that efforts are underway to meet overall recommendation 25
but that the Westlake controversy hampered it so it’s not yet able to
assess the effectiveness of implementation.



This seems a shame, but I know absolutely nothing about it! If others think
the GNSO has anything useful to say on this one that the SSR RT hasn’t
covered, then please have at it.



*Rec. 26*

Quickly finish the Risk Management Framework with lots of participation and
transparency.



There have been sessions on this in Costa Rica, Prague, Toronto and Beijing
and public comments on the Westlake framework. SSR RT says work to date has
been ‘open and inclusive, and participation has been welcomed’.



As in 25, some unhappiness re. Westlake v the DSSA WG. SSR RT says it looks
like ICANN has prioritised this as recommended, but has been hampered by a
lack of clarity on respective roles of Westlake and DSSA WG.



Is standard of participation sufficiently high?



*Rec. 27*

Risk Management Framework should be comprehensive within scope of SSR remit
and ICANN’s limited missions.



The idea was to be constrained within ICANN’s limited mission but to be
comprehensive within that – but there aren’t any objective criteria on
‘comprehensiveness’.



Public comments from Verisign and ALAC on Westlake’s approach to the Risk
Management Framework were that it wasn’t comprehensive enough, within the
remit. ATRT2 seems to agree with that view though acknowledges that
comprehensiveness is a matter of opinion.



Anyone have anything to add on this?



*Rec. 28*

ICANN should actively do threat detection and mitigation and participate in
efforts to distribute threat and incident information.



An ongoing task with engagement with security conferences and CERTs.
Anecdotal feedback says ICANN work on this is helpful. An important role,
that ICANN needs to go on doing.



Agreed? Has SSR RT missed anything here? (I don’t expect so, just raising
the question.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/council/attachments/20131111/3e4029e7/attachment.html>