La presente es una actualización del progreso que hemos logrado en relación con la implementación de las 28 recomendaciones del Equipo de Revisión de Seguridad, Estabilidad y Flexibilidad (SSR). Durante la reunión de la ICANN realizada en Toronto en el mes de octubre, la Junta Directiva de la ICANN aprobó el Informe Final y las Recomendaciones del Equipo de Revisión de Seguridad, Estabilidad y Flexibilidad y le indicó al personal que procediera a su implementación [ver el siguiente enlace: http://www.icann.org/es/groups/board/documents/resolutions-18oct12-es.htm#1.e]. Dese la reunión realizada en Toronto, el personal de la ICANN estuvo trabajando en la implementación de estas recomendaciones. La comunidad podrá, a la brevedad, hacer un seguimiento de nuestros avances en la página dedicada a la Implementación de SSR del Equipo de Seguridad, como también mediante el sitio web de Responsabilidad & Transparencia. Mientras tanto, esta publicación nos acerca una perspectiva del rumbo que estamos tomando, con seguimientos e informes periódicos.
SSR es una de las cuatro áreas sujetas a revisiones de compromisos en curso, de conformidad con la Afirmación de Compromisos [ver el siguiente enlace: http://www.icann.org/es/about/agreements/aoc/affirmation-of-commitments-30sep09-es.htm] firmada en el 2009 entre la ICANN y el Departamento de Comercio de los Estados Unidos. El Equipo de Seguridad de la ICANN es responsable del cumplimiento de las obligaciones de la ICANN de conformidad con la revisión de SSR, y lidera los esfuerzos de implementación de las recomendaciones del Equipo de Revisión. El progreso de la ICANN respecto de todas las revisiones de la Afirmación de Compromisos puede visualizarse en el siguiente enlace: http://www.icann.org/en/news/in-focus/accountability.
Nuestro enfoque, el cual presentamos ante el Comité Asesor de Seguridad y Estabilidad el mes pasado en Los Ángeles, consistió en tomar las 28 recomendaciones y alinearlas de acuerdo con las cuatro áreas de la Estructura de Entrega de Gestión de la ICANN presentada en Toronto por su Director Ejecutivo, Fadi Chehade. Son las siguientes:
- Afirmación de Propósito [Recomendaciones 1, 2, 18, 24]
- Excelencia Operativa [Recomendaciones 7, 8, 17, 20, 21, 9, 10, 11, 22, 25, 26, 27, 15, 28]
- Internacionalización [Recomendaciones 3, 4, 5, 14, 16]
- Evolución del Modelo de Múltiples Partes Interesadas [Recomendaciones 6, 19, 23]
Además de la alineación que figura a continuación, contamos con un cuadro donde se muestran las 28 recomendaciones y los plazos de las actividades entre los Años Fiscales 2013 y 2015.
Afirmación de Propósito – Ámbito de Competencia y Misión de la ICANN
| Recomendación del Equipo de Revisión de SSR | Implementación y Estado |
| #1 – La ICANN debería publicar una única declaración clara y uniforme de su ámbito de competencia en materia de SSR y de su misión técnica acotada. | Se recibieron comentarios públicos sobre una versión borrador de la declaración entre mayo y septiembre de 2012 [ver el siguiente enlace: http://www.icann.org/en/news/public-comment/draft-ssr-role-remit-17may12-en.htm]. El borrador de la declaración fue revisado el 4 de octubre de 2012 [ver el siguiente enlace: http://toronto45.icann.org/meetings/toronto2012/presentation-draft-ssr-role-remit-04oct12-en.pdf [PDF, 133 KB]]. |
| #2 – La definición e implementación de la declaración de la ICANN sobre su ámbito de competencia en materia de SSR y su misión técnica acotada debería ser revisada para mantener el consenso y obtener la retroalimentación de la comunidad. | La revisión del rol y la declaración actualizados se realizará con el próximo SSR RT en el 2015. |
| #24 – La ICANN debe definir claramente la carta orgánica, los roles y las responsabilidades del Equipo de la Oficina Principal de Seguridad. | Implementadacon la actualización de la página del Equipo de Seguridad [ver el siguiente enlace: https://www.icann.org/security] el 4 de octubre de 2012 y con la publicación del Marco de SSR para el Año Fiscal 2013. Los roles y las responsabilidades se ajustarán nuevamente con la implementación de la nueva Estructura de Entrega de Gestión en el 2013. |
| #18 – La ICANN debería realizar una revisión operativa anual de sus avances en la implementación del Marco de SSR e incluir esta evaluación en el Marco de SSR del año siguiente. | Implementadacomo parte del Marco de SSR del Año Fiscal 2013, y se repetirá anualmente. El próximo Marco de SSR será desarrollado en el primer trimestre del 2013. Se incorporará una nueva página de Tablero de Control dentro de la página del Equipo de Seguridad en el sitio web de la ICANN para visualizar el seguimiento del progreso logrado. |
Excelencia Operativa – Objetivos
| Recomendación del Equipo de Revisión de SSR | Implementación y Estado |
| #7 – La ICANN debería basarse en su Marco de SSR actual al establecer un conjunto claro de objetivos y priorizar sus iniciativas y actividades de acuerdo con dichos objetivos. | Se usará la nueva Estructura de Entrega de Gestión para alinear los objetivos y las iniciativas de la ICANN con el Marco de SSR Actual, y respaldar el desarrollo del Presupuesto y Plan Operativo del Año Fiscal 2014, y el próximo Plan Estratégico. Ya estamos trabajando para alinear nuestros objetivos y actividades con esta estructura. |
| #8 – La ICANN debería continuar perfeccionando los objetivos de su Plan Estratégico; en particular, la meta de mantener e impulsar la disponibilidad del DNS. Clara alineación entre el Marco y el Plan Estratégico. | Este punto guarda relación con el próximo Plan Estratégico. El personal necesita alinear los objetivos y las actividades en el Plan Estratégico con el Marco Anual de SSR y las recomendaciones del Equipo de Revisión de SSR. |
Excelencia Operativa – Transparencia
| Recomendación del Equipo de Revisión de SSR | Implementación y Estado |
| #17 – La ICANN debería establecer un proceso interno más estructurado para mostrar la manera en que las actividades e iniciativas se relacionan con metas, objetivos y prioridades estratégicas específicas en el Marco de SSR. | La Estructura de Entrega de Gestión ya ha resultado útil para abordar esta recomendación, al crear un mecanismo para un proceso interno que indicará como las actividades e iniciativas de la ICANN en materia de SSR se relacionan con metas, objetivos y prioridades. Habrá más información sobre este proceso al alcance de la comunidad a través de MyICANN y en el sitio web de la ICANN con antelación a la reunión a realizarse en Beijing en el 2013. |
| #20 – La ICANN debería incrementar la transparencia de la información sobre organización y presupuesto en relación con la implementación del Marco de SSR y el desempeño de funciones relativas a SSR. | Se implementará a lo largo del proceso del Marco de SSR para el Año Fiscal 2014 y del Plan Operativo y Presupuesto para el Año Fiscal 2014. La nueva página de Tablero de Control del Equipo de Seguridad también se utilizará para abordar esta recomendación. |
Excelencia Operativa – Estructura
| Recomendación del Equipo de Revisión de SSR | Implementación y Estado |
| #21 – La ICANN debería establecer un proceso interno más estructurado para mostrar la manera en que las decisiones en materia de organización y presupuesto se relacionan con el Marco de SSR, incluyendo el análisis subyacente de costo-beneficio. | Utilizaremos la iniciativa de Mapeo de Gestión como proceso estructurado para identificar las decisiones en materia de organización y presupuesto y alinearlas con las actividades de SSR en el Marco anual. Esta medida se implementará dentro del Plan Operativo y Presupuesto para el Año Fiscal 2014. El Equipo de Seguridad trabajará sobre esta recomendación junto al el Equipo de Finanzas. |
Excelencia Operativa – Estándares & Cumplimiento
| Recomendación del Equipo de Revisión de SSR | Implementación y Estado |
| #9 – La ICANN debería evaluar opciones de certificación para sus responsabilidades operativas mediante normas internacionales comúnmente aceptadas (por ejemplo: ITIL, ISO y SAS-70). La ICANN debería publicar una hoja de ruta que indique claramente sus pasos a seguir en pos de la certificación. | La implementación de DNSSEC en la raíz por parte de la ICANN obtuvo la certificación SysTrust [ver los siguientes enlaces: https://www.iana.org/dnssec/systrust y https://cert.webtrust.org/icann.html]. Los equipos de Funciones de la IANA, Tecnología de la Información, y Operaciones del DNS de la ICANN están llevando a cabo más procesos de certificación con el apoyo del Equipo de Seguridad. |
| #10 – La ICANN debería continuar con sus esfuerzos para acelerar la exigibilidad del cumplimento contractual y brindar recursos suficientes para dicha función. Asimismo, la ICANN debería desarrollar e implementar un proceso más estructurado para monitorear las cuestiones e investigaciones relativas al cumplimiento. | Esta recomendación está siendo abordada por el Equipo de Cumplimiento de la ICANN, y mediante la implementación de las recomendaciones del Equipo de Revisión de WHOIS. |
Excelencia Operativa – nTLDs
| Recomendación del Equipo de Revisión de SSR | Implementación y Estado |
| #11 – La ICANN debería finalizar e implementar mediciones del éxito de los nuevos gTLDs y del proceso de avance acelerado de los IDN que se relacionen expresamente con los objetivos relativos a su programa de SSR, incluyendo la medición de la efectividad de los mecanismos para mitigar el abuso de nombres de dominio. | El personal está analizando la totalidad de las implicancias de esta recomendación. El Equipo de Seguridad considera que se requerirá la colaboración entre el personal y la comunidad para una plena implementación. Como este punto guarda relación con la Revisión de Competencia, Confianza y Elección del Consumidor, y con las mediciones de los nuevos gTLDs y los IDN ccTLDs delegados mediante el Proceso de Avance Acelerado de IDN ccTLDs, se trabajará con partes interesadas de toda la comunidad. Esta recomendación se centra en los mecanismos relativos a la mitigación del abuso de nombres de dominio. El personal está brindando apoyo a las iniciativas en materia de criterios de medición de abusos en los Comités Asesores y la comunidad. |
| #22 – La ICANN debería publicar, monitorear y actualizar documentación sobre los recursos organizativos y presupuestarios necesarios para gestionar cuestiones de SSR junto con la introducción de los nuevos gTLDs. | Este punto se relaciona con la Recomendación 21 (decisiones presupuestarias y organizativas) y con el desarrollo del monitoreo a partir de la introducción de los nuevos gTLDs. |
Excelencia Operativa – Gestión de Riesgo & Mitigación de Amenazas
| Recomendación del Equipo de Revisión de SSR | Implementación y Estado |
| #25 – La ICANN debería implementar mecanismos para identificar riesgos a corto y a largo plazo, y factores estratégicos, dentro de su Marco de Gestión de Riesgo. | Esto se encuentra en curso y se relaciona con la entrega del Marco de Gestión de Riesgo de conformidad con la Recomendación 26. |
| #26 – La ICANN debería dar prioridad a la compleción oportuna de un Marco de Gestión de Riesgo. | Esto está en curso. La ICANN contrató a Westlake Governance para que colabore con su proyecto del Marco de Gestión de Riesgo. Westlake realizó una sesión abierta en Toronto, y presentará una versión borrador del Marco en el corto plazo. |
| #27 – El Marco de Gestión de Riesgo de la ICANN debería ser integral, dentro del alcance de su ámbito de competencia y sus misiones acotadas en materia de SSR. | El Marco de Gestión de Riesgos de la ICANN estará alineado con las actividades de la ICANN, en respaldo de su misión técnica y de la comunidad. Esto será integral dentro de dicho alcance, y se logrará mediante la entrega del Marco de conformidad con la Recomendación 26. |
| #15 – La ICANN debería actuar como un facilitador en la divulgación y la difusión responsable de amenazas a la seguridad del DNS y técnicas de mitigación. | El personal está analizando la totalidad de las implicancias de esta recomendación. Somos conscientes de la necesidad de responder rápidamente ante un incidente, para garantizar la protección de la información y los individuos durante y después del incidente, e informar con precisión y responsabilidad. El personal colabora con operadores y entidades confiables en materia de seguridad dentro de la comunidad en el tema de amenazas a la seguridad del DNS y técnicas de mitigación. Esto se relaciona con la Recomendación 28. |
| #28 – La ICANN debería continuar participando activamente en la detección y mitigación de amenazas, y participar en iniciativas de difusión de información sobre amenazas e incidentes. | Esta recomendación respalda una continuidad de iniciativas de la ICANN, las cuales comprenden el monitoreo de la zona raíz, la detección y mitigación de amenazas relativas a las Operaciones del DNS a cargo de la ICANN y a las amenazas e incidentes en relación con el DNS en general. |
Internacionalización – Terminología & Relaciones
| Recomendación del Equipo de Revisión de SSR | Implementación y Estado |
| #3 – Una vez que la ICANN publique una declaración consensuada de su ámbito de competencia y misión técnica acotada en materia de SSR, la ICANN debería utilizar terminología y descripciones uniformes de dicha declaración en todos sus materiales. | El Equipo de Seguridad trabajará transversalmente en la organización en pos del uso de terminología y descripciones uniformes relativas al rol y al ámbito de competencia de la ICANN en materia de SSR. Un primer paso es capacitar al personal de la ICANN, y posteriormente ofrecer un seminario vía web en el cual participe la comunidad. También utilizaremos esta terminología y descripción en las presentaciones y las iniciativas de participación la ICANN. |
| #4 – La ICANN debería documentar y definir claramente la naturaleza de las relaciones de SSR que tiene dentro de la comunidad de la ICANN para brindar un único punto focal que permita entender las interdependencias entre organizaciones. | El personal está preparando un ejercicio de documentación relativo a las relaciones de SSR de la ICANN. La comunidad tendrá la oportunidad de participar en este ejercicio. Se identificarán las relaciones y los puntos de contacto existentes dentro de la comunidad, como también las brechas en las que hace falta promover o mejorar las relaciones. Sobre la base de comentarios públicos, la implementación de la Recomendación 4 implicará una amplia tarea de difusión y alcance dentro de la comunidad, y la colaboración con SOs/ACs/grupos de partes interesadas y socios de la ICANN. |
| #5 – La ICANN debería usar la definición de sus relaciones de SSR para mantener esquemas de trabajo efectivos y demostrar cómo se recurre a estas relaciones para alcanzar cada una de las metas de SSR. | El Equipo de Seguridad trabajará junto al Equipo de Participación Global de la ICANN para mantener y mejorar esquemas y relaciones de trabajo efectivos. |
Internacionalización – Alcance & Participación
| Recomendación del Equipo de Revisión de SSR | Implementación y Estado |
| #14 – La CANN debería garantizar la evolución constante de sus actividades de alcance en materia de SSR para que continúen siendo relevantes, oportunas y apropiadas. | Se han ampliado las actividades de alcance, y se hará una revisión anual de las mismas. Los integrantes del Equipo de Seguridad prestarán sus servicios al Equipo de Participación Global de la ICANN en carácter de expertos en la materia, y también a la comunidad en asuntos de alcance y participación relativos a SSR. |
| #16 – La ICANN debería continuar con sus iniciativas de alcance para incorporar la participación y los aportes de la comunidad al proceso de desarrollo del Marco de SSR. Asimismo, la ICANN debería establecer un proceso para la obtención de más aportes sistemáticos por parte de otros participantes del ecosistema. | Se han ampliado las actividades y los procesos de alcance, y se hará una revisión anual de ambos. Este punto se guarda relación con las Recomendaciones 4, 5 y 14. El Equipo de Seguridad presta su apoyo mediante una serie de iniciativas de creación de capacidades a pedido de las partes interesadas; por ejemplo, capacitación en materia de DNSSEC, capacitación sobre ataques a los ccTLDs y respuestas de contingencia, capacitación sobre cumplimiento de la ley, tareas de difusión y alcance en reuniones de Grupos de Operadores de Redes, como CaribNOG y MENOG, entre otras. |
Evolución del Modelo de Múltiples Partes Interesadas
| Recomendación del Equipo de Revisión de SSR | Implementación y Estado |
| #6 – La ICANN debería publicar un documento en el que se indiquen claramente los roles y las responsabilidades del SSAC y el RSSAC para delinear claramente las actividades de ambos grupos. | Esta recomendación requerirá la colaboración entre la comunidad y el personal. Hemos dividido este punto en dos partes: 6A [SSAC] y 6B [RSSAC]. 6A – Los roles y las responsabilidades del SSAC se encuentran definidos en los Procedimientos Operativos del SSAC. El SSAC está examinando sus procedimientos operativos para el 2013 y también tiene interés en alinear dichos roles y responsabilidades a los del RSSAC. 6B – Los roles y las responsabilidades del RSSAC se encuentran en desarrollo. |
| #19 – La ICANN debería establecer un proceso que permita que la comunidad haga un seguimiento de la implementación del Marco de SSR. La información brindada debería ser lo suficientemente clara como para que la comunidad pueda realizar el seguimiento del cumplimiento de las responsabilidades de SSR de la ICANN. | El Equipo de Seguridad presentará a la brevedad un Tablero de Control en su página en el que se indicará el estado del Marco de SSR y de las iniciativas de SSR de la ICANN. |
| #23 – La ICANN debe brindar los recursos apropiados a los Grupos de Trabajo y Comités Asesores de SSR, en consonancia con las demandas de dichas agrupaciones. Asimismo, la ICANN debe garantizar que los Grupos de Trabajo y los Comités Asesores tomen sus decisiones en forma objetiva, libres de toda presión externa o interna. | El personal está llevando a cabo un inventario de las actividades [23A] en los Grupos de Trabajo y Comités Asesores de SSR existentes (SSAC y RSSAC). Posteriormente, se realizará la descripción o documentación del proceso presupuestario para la obtención de los aportes de las SOs y los ACs [23B]. El ítem 23C contendrá una descripción de un paso dentro de un proceso operativo estándar para indicar que las SOs, los ACs y los Grupos de Trabajo toman sus decisiones en forma objetiva. |
