This is an update on our progress with implementation of the 28 recommendations from the Security, Stability and Resiliency (SSR) Review Team. In October at the ICANN meeting in Toronto, the ICANN Board approved the Final Report and recommendations of the Security, Stability & Resiliency Review Team and instructed staff to proceed with implementation [link: http://www.icann.org/en/groups/board/documents/resolutions-18oct12-en.htm#1.e]. Since Toronto, ICANN staff have been working on the delivery of these recommendations. The community will soon be able to follow our progress on the Security team’s SSR Implementation page, as well as through the Accountability & Transparency webpage. In the interim, this post provides a sense of where we are heading with regular tracking and reporting.
SSR is one of four areas subject to ongoing commitment reviews under the Affirmation of Commitments [link: http://www.icann.org/en/about/agreements/aoc/affirmation-of-commitments-30sep09-en.htm] signed in 2009 between ICANN and the US Department of Commerce. ICANN’s Security team is responsible for delivering on ICANN’s obligations under the SSR review, and is leading the effort to implement the Review Team’s recommendations. ICANN’s progress on all Affirmation of Commitments reviews is available at http://www.icann.org/en/news/in-focus/accountability.
Our approach, as presented to ICANN’s Security & Stability Advisory Committee last month in Los Angeles, has been to take the 28 recommendations and align them to the four areas in ICANN’s Management Delivery structure unveiled by CEO Fadi Chehade in Toronto. These are:
- Affirmation of Purpose [Recommendations 1, 2, 18, 24]
- Operations Excellence [Recommendations 7, 8, 17, 20, 21, 9, 10, 11, 22, 25, 26, 27, 15, 28]
- Internationalization [Recommendations 3, 4, 5, 14, 16]
- Multi-stakeholder Model Evolution [Recommendations 6, 19, 23]
In addition to the alignment below, we have a chart showing all 28 recommendations and timing of activity between FY 13-15.
Affirmation of Purpose – ICANN’s Remit, Mission
| SSR RT Recommendation | Implementation & Status |
| #1 – ICANN should publish a single, clear and consistent statement of its SSR remit and limited technical mission. | Public comment was taken on a draft statement between May-Sept 2012 [link: http://www.icann.org/en/news/public-comment/draft-ssr-role-remit-17may12-en.htm]. The draft statement was revised on 4 Oct 2012 [link: http://toronto45.icann.org/meetings/ toronto2012/presentation-draft-ssr-role-remit-04oct12-en.pdf [PDF, 133 KB]]. |
| #2 – ICANN’s definition and implementation of its SSR remit and limited technical mission should be reviewed in order to maintain consensus and elicit feedback from the Community. | The updated role and remit statement will be reviewed with the next SSR RT in 2015. |
| #24 – ICANN must clearly define the charter, roles and responsibilities of the Chief Security Office Team. | Implemented with updated Security team page [link: https://www.icann.org/security] on 4 October 2012 and publication of the FY 13 SSR Framework. Roles and responsibilities to be further refined with implementation of the new Management Delivery structure in 2013. |
| #18 – ICANN should conduct an annual operational review of its progress in implementing the SSR Framework and include this assessment as a component of the following year’s SSR Framework. | Implemented as part of the FY 13 SSR Framework and will be repeated annually. Next SSR Framework to be developed in Q1 2013. Tracking of progress will be added to a new Dashboard page on the Security team page on the ICANN website. |
Operations Excellence – Objectives
| SSR RT Recommendation | Implementation & Status |
| #7 – ICANN should build on its current SSR Framework by establishing a clear set of objectives and prioritizing its initiatives and activities in accordance with these objectives. | The new Management Delivery structure will be used to align ICANN’s objectives and initiatives with the annual SSR Framework, and support the development of the FY 14 budget, operating plan and next ICANN Strategic Plan. We’re already working to align our objectives and activities to this structure. |
| #8 – ICANN should continue to refine its Strategic Plan objectives, particularly the goal of maintaining and driving DNS availability. Clear alignment of Framework & Strategic Plan. | This is connected with the next Strategic Plan. Staff need to align objectives and activities in Strategic Plan with the annual SSR Framework and the SSR Review Team recommendations. |
Operations Excellence – Transparency
| SSR RT Recommendation | Implementation & Status |
| #17 – ICANN should establish a more structured internal process for showing how activities and initiatives relate to specific strategic goals, objectives and priorities in the SSR Framework. | The Management Delivery structure has already been useful for addressing this recommendation, creating a mechanism for an internal process that will show how ICANN’s SSR activities and initiatives relate to goals, objectives and priorities. More information on this process will be made available to the community through MyICANN and on the ICANN website in advance of the Beijing meeting in 2013. |
| #20 – ICANN should increase the transparency of information about organization and budget related to implementing the SSR Framework and performing SSR-related functions. | This will be implemented through the FY 14 SSR Framework and FY 14 Operating Plan and Budget process. The new Security team Dashboard page will also be used to address this recommendation. |
Operations Excellence – Structure
| SSR RT Recommendation | Implementation & Status |
| #21 – ICANN should establish a more structured internal process for showing how organization and budget decisions relate to the SSR Framework, including the underlying cost-benefit analysis. | We will use the Management Mapping effort as the structured process for identifying the organization and budget decisions and align with SSR activities in the annual Framework. This will be implemented in the FY 14 Operating Plan & Budget. Security with work with the Finance team on this recommendation. |
Operations Excellence – Standards & Compliance
| SSR RT Recommendation | Implementation & Status |
| #9 – ICANN should assess certification options with commonly accepted international standards (e.g. ITIL, ISO and SAS-70) for its operational responsibilities. ICANN should publish a clear roadmap towards certification. | ICANN’s implementation of DNSSEC in the root has achieved SysTrust certification [link: https://www.iana.org/dnssec/systrust and https://cert.webtrust.org/icann.html]. Further certification processes are being led by ICANN’s IANA functions team, IT and DNS Operations teams, with support from Security. |
| #10 – ICANN should continue its efforts to step up contract compliance enforcement and provide adequate resources for this function. ICANN also should develop and implement a more structured process for monitoring compliance issues and investigations. | This recommendation is being led by ICANN’s Compliance team and through implementation of the recommendations from the WHOIS Review Team. |
Operations Excellence – nTLDs
| SSR RT Recommendation | Implementation & Status |
| #11 – ICANN should finalize and implement measures of 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. | Staff is exploring the full implications of this Recommendation. Security team expects this will involve community-staff collaboration for full implementation. As this relates to the Competition, Consumer Trust and Consumer Choice Review and measurements for both new gTLDs and IDN ccTLDs delegated via the IDN ccTLD Fast Track, there will be engagement with stakeholders from across the community. The focus of this recommendation is mechanisms related to mitigating domain name abuse. Staff is supporting efforts in Advisory Committees and community on abuse metrics. |
| #22 – ICANN should publish, monitor and update documentation on the organization and budget resources needed to manage SSR issues in conjunction with introduction of new gTLDs. | This is related to Recommendation 21 (budget and organization decisions) as well as to the development of monitoring with the introduction of new gTLDs. |
Operations Excellence – Risk Management & Threat Mitigation
| SSR RT Recommendation | Implementation & Status |
| #25 – ICANN should put into place mechanisms for identifying both near and longer-term risks and strategic factors in its Risk Management Framework | This is underway and tied to the delivery of a Risk Management Framework under Recommendation 26. |
| #26 – ICANN should prioritize the timely completion of a Risk Management Framework. | This is underway. ICANN has retained Westlake Governance to assist with its DNS Risk Management Framework project. Westlake conducted an open session in Toronto, and will be providing a draft framework in the near future. |
| #27 – ICANN’s Risk Management Framework should be comprehensive within the scope of its SSR remit and limited missions | The Risk Management Framework will be aligned with ICANN’s activities in support of its technical mission and the community. This will be comprehensive in that scope, and will be accomplished with the delivery of the Framework under Recommendation 26. |
| #15 – ICANN should act as a facilitator in the responsible disclosure and dissemination of DNS security threats and mitigation techniques. | Staff is exploring the full implications of this recommendation. We are mindful of the needs to respond to incidents quickly, to assure that information and individuals are protected during and after incidents, and to report accurately and responsibly. Staff collaborates with operators and trusted security community entities on DNS security threats and mitigation techniques. This is related to Recommendation 28. |
| #28 – ICANN should continue to actively engage in threat detection and mitigation, and participate in efforts to distribute threat and incident information. | This recommendation supports a continuation of ICANN efforts, including root zone monitoring, threat detection and mitigation related to ICANN’s DNS Operations and to DNS threats and incidents in general. |
Internationalization – Terminology & Relationships
| SSR RT Recommendation | Implementation & Status |
| #3 – Once ICANN issues a consensus-based statement of its SSR remit and limited technical mission, ICANN should utilize consistent terminology and descriptions of this statement in all materials. | The Security team will work across the organization to use consistent terminology and descriptions related to ICANN’s SSR role and remit in ICANN’s materials. A first step is to conduct training with ICANN staff, then offer a webinar for community participation. We will also use these terminology and description in ICANN presentations and engagement. |
| #4 – ICANN should document and clearly define the nature of the SSR relationships it has within the ICANN Community in order to provide a single focal point for understanding the interdependencies between organizations. | Staff is preparing a documentation exercise related to ICANN’s SSR relationships. There will be opportunity for community participation in this exercise. This will identify existing relationships and points of contact with the community, as well as gaps where relationships should be pursued or enhanced. Based on public comments, implementation of Rec 4 will involve broad outreach within the community, collaboration with ICANN SO/AC/stakeholder groups and partners. |
| #5 – ICANN should use the definition of its SSR relationships to maintain effective working arrangements and to demonstrate how these relationships are utilized to achieve each SSR goal. | The Security team will work with ICANN’s Global Stakeholder Engagement team to maintain and enhance effective working arrangements and relationships. |
Internationalization – Outreach & Engagement
| SSR RT Recommendation | Implementation & Status |
| #14 – ICANN should ensure that its SSR-related outreach activities continuously evolve to remain relevant, timely and appropriate. | Outreach activities have been expanded and will be reviewed annually. The Security team will provide both a service function to ICANN’s Global Stakeholder Engagement team as subject matter experts, and a community function in outreach and engagement in SSR matters. |
| #16 – ICANN should continue its outreach efforts to expand Community participation and input into the SSR Framework development process. ICANN also should establish a process for obtaining more systematic input from other ecosystem participants. | Outreach activities and processes have been expanded and will be reviewed annually. This is related to Recommendations 4, 5 and 14. The Security team supports a variety of capability building initiatives at the request of stakeholders, such as DNSSEC training, ccTLD attack and contingency response training, law enforcement training, outreach at Network Operator Group meetings such as CaribNOG, MENOG, among others. |
Multistakeholder Model Evolution
| SSR RT Recommendation | Implementation & Status |
| #6 – ICANN should publish a document clearly outlining the roles and responsibilities for both the SSAC and RSSAC in order to clearly delineate the activities of the two groups. | This recommendation will require community-staff collaboration. We have divided this into 6A [SSAC] and 6B [RSSAC]. 6A – Roles and Responsibilities of SSAC are defined in SSAC’s Operating Procedures. SSAC is examining its operating procedures for 2013 and is also interested in aligning these the roles and responsibilities of RSSAC. 6B – Roles and Responsibilities for RSSAC are in development. |
| #19 – ICANN should establish a process that allows the Community to track the implementation of the SSR Framework. Information should be provided with enough clarity that the Community can track ICANN’s execution of its SSR responsibilities | The Security team will soon release a Dashboard on its team page to show status tracking of the SSR Framework and ICANN’s SSR initiatives. |
| #23 – ICANN must provide appropriate resources for SSR-related Working Groups and Advisory Committees, consistent with the demands placed upon them. ICANN also must ensure decisions reached by Working Groups and Advisory Committees are reached in an objective manner that is free from external or internal pressure. | Staff is conducting an inventory [23A] of activity in the existing SSR-related working groups and Advisory Committees (SSAC and RSSAC). This will be followed by a description or documentation of the budget process for SO/AC input [23B]. 23C will describe a standard operating process step to show that SO/AC/Working Group decisions are reached in an objective manner. |
