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.)