Skip to main content
Resources

Marco para que los Operadores de Registro respondan ante amenazas a la seguridad

Tenga presente que la versión oficial de todos los contenidos y documentos traducidos es la versión en idioma inglés; las traducciones a otros idiomas son solo a título informativo.

Objetivo

El objetivo de esta labor es cumplir el compromiso del Comité para el Programa de Nuevos gTLD (NGPC) de la Junta Directiva de la ICANN (Corporación para la Asignación de Nombres y Números en Internet) ante el Comité Asesor Gubernamental (GAC) respecto de que la ICANN solicite la participación de la comunidad para desarrollar un marco que aborde la manera en la cual un Operador de Registro (RO) puede responder ante amenazas a la seguridad que hayan sido detectadas. Este marco es un documento voluntario y no vinculante diseñado para articular las formas en que los Registros pueden responder a las amenazas de seguridad identificadas.

Este marco no aborda las situaciones en las cuales un Operador de Registro no tiene la facultad de responder (por ejemplo, sujeto a una orden judicial de un tribunal de jurisdicción competente sobre el Registro). El mismo no refleja ninguna política de consenso que afecte a los Registros.

Alcance

Este marco aborda las respuestas de los Registros a las notificaciones de amenazas de seguridad.

Categorías de acciones en respuesta a las amenazas de seguridad por parte de los Registros

Típicamente las políticas de Dominios Genéricos de Alto Nivel (gTLD) o los Términos de Servicio de los Operadores de Registro rigen los tipos de respuestas disponibles para el Operador de Registro. Estas políticas se desarrollan en función de los requisitos legales, operativos y técnicos aplicables, los cuales varían según los Registros y las jurisdicciones. Las políticas pueden modificarse a discreción del RO y de acuerdo con las políticas de consenso y los requisitos legales, con el fin de abordar las nuevas circunstancias y las lecciones aprendidas a partir de las amenazas de seguridad anteriores.1

Mientras que no es taxativa, la lista representa muchas de las opciones de respuesta ante abusos posibles por parte de los RO.

Nombres de dominio existentes

  • Remita el problema al Registrador.

    A menudo ésta es la primera respuesta empleada por un RO, dado que es el Registrador quien tiene la relación contractual con el Registratario del nombre de dominio. El Registrador debe tener una oportunidad de tiempo limitado para investigar la amenaza a la seguridad y responder adecuadamente. Una respuesta negativa o una falta de respuesta por parte del Registrador no debe impedir que el Registro tome medidas.

  • Poner en espera el nombre de dominio para que no se resuelva.

    La aplicación del estado de espera (serverHold) elimina el nombre de dominio del archivo de zona TLD, con la consecuencia de que el nombre de dominio ya no se resolverá en la Internet pública.2 Un beneficio adicional es que, en caso de error, esta acción es fácil de revertir.

  • Bloquear el nombre de dominio para que no pueda ser cambiado

    Aunque rara vez se utiliza para amenazas de seguridad, la aplicación del estado de bloqueo3 significa que un dominio no se puede transferir ni eliminar, y tampoco sus detalles pueden ser modificados, aunque se resolverá. Ocasionalmente se ve como parte de una acción donde un dominio se bloquea junto con la incautación de sus servidores de nombres.

  • Redirigir los servicios de nombre para el nombre de dominio.

    Un Registro tiene la capacidad técnica de cambiar los servidores de nombre de un nombre de dominio. Al cambiar los servidores de nombres para el nombre de dominio, los servicios asociados con el nombre de dominio pueden ser redirigidos por "sink-holing" (tráfico de registro) para identificar a las víctimas a los fines de la corrección.

  • Transferir el nombre de dominio.

    La transferencia de un dominio a un Registrador adecuadamente calificado puede evitar la explotación, al mismo tiempo que permite la gestión del ciclo de vida, de los códigos de estado de EPP y del vencimiento.

  • Eliminar el nombre de dominio.

    La eliminación es una acción extrema y generalmente no se recomienda sin la debida verificación e indicación por parte de las autoridades apropiadas. La restauración de un nombre de dominio, en caso de considerarse que la eliminación ha sido inapropiada, puede implicar cargas adicionales que no se manifiestan al colocar un nombre de dominio en espera (serverHold). En general, la eliminación no es tan efectiva para mitigar las amenazas de seguridad como lo es la suspensión, dado que un Registratario puede volver a registrar el nombre de dominio luego de que el mismo se haya eliminado de la zona.

  • No tomar ninguna medida.

    Esta opción está siempre disponible. Bajo circunstancias específicas, la política del Registro puede limitar la toma de medidas, o ello puede ser la acción predeterminada en caso de no haber otra respuesta apropiada. De manera similar, un RO puede llegar a la conclusión de que un asunto referido no constituye una amenaza de seguridad o que las consecuencias de la acción superan a la amenaza misma. Como una cuestión de cortesía, el RO debería responder a quien haya informado la amenaza de seguridad, mencionando por qué esta es la respuesta a la amenaza de seguridad informada.

Nombres de dominio no registrados (tipo DGA)

Una amenaza de seguridad puede estar asociada con un nombre de dominio que aún no está registrado. Esto puede ocurrir cuando el nombre de dominio es el resultado de un Algoritmo de Generación de Dominios (DGA) automático asociado con la actividad de un botnet. A menudo, la amenaza involucrará a miles de nombres de dominio o más.

  • Crear el nombre de dominio.

    La registración de un nombre de dominio potencialmente malicioso parece contradictorio; pero cuando se realiza en condiciones controladas, permite que los investigadores y las organizaciones de seguridad pública ―tal como los Equipos de Respuesta ante Emergencias Informáticas (CERT)― tomen las medidas adecuadas (como el "sink-holing"4) sobre un nombre de dominio. En forma similar a la opción de transferencia anterior, esto ayuda a identificar las computadoras de las víctimas a los fines de la mitigación. Además, y al igual que con la opción de bloqueo a continuación, se niega el uso del nombre de dominio para los malos actores.5

    En general, el RO cuenta con el criterio de decidir si delega los dominios previamente no registrados a un Registrador adecuadamente calificado o a su propio Registrador interno. Los RO deben asegurarse de buscar cualquier exención(es) apropiada o necesaria por parte de la ICANN, en cuanto a ciertas disposiciones contractuales del Acuerdo de Registro del RO respectivo. Actualmente, esto se logra a través del Proceso Expedito para la Solicitud de Seguridad del Registro (ERSR) de la ICANN. El momento en que se recibe la exención depende de la ICANN.

  • Bloquear la registración del nombre de dominio.

    Cuando se acuerde, el RO puede reservar el nombre de dominio solicitado. Si corresponde, el solicitante debe trabajar con el RO para establecer un límite de tiempo apropiado para el bloqueo.

Informar amenazas de seguridad

Si bien la evaluación de la credibilidad de la fuente es un asunto de cada RO individual, existe una jerarquía de la gravedad de las amenazas de seguridad. Un RO también debe prestar atención a la calidad y al estándar de la información provista en el informe de una fuente, junto con los informes previos. Un ejemplo directo de dónde se debe dar prioridad y tomar acciones rápidamente, sujeto a las políticas y determinaciones del RO, son los informes elaborados adecuadamente por las autoridades nacionales de orden público (LEA) donde se localiza el RO, o bien cuando una solicitud se basa en una orden judicial de un tribunal con jurisdicción sobre el RO.

  1. Informes de las autoridades de orden público

    Cuando la parte notificante sea confirmada como autoridad de orden público gubernamental (incluida la policía nacional u otra agencia gubernamental de seguridad pública con jurisdicción adecuada sobre el RO) este marco alienta al RO a considerar que dichos informes son de mayor fidelidad y, como tales, se les otorgará toda la debida prioridad. Mientras que los RO deben proceder con un mayor grado de certeza con respecto a las referencias de las LEA, aún deben realizar cualquier investigación que consideren necesaria para garantizar que las referencias constituyan realmente una amenaza de seguridad, y para confirmar la validez de la fuente de referencia.

  2. Informes de fuentes reconocidas por el RO

    Según su propio criterio, un RO puede elegir priorizar los informes presentados por entidades que reconoce con la experiencia requerida en el campo apropiado, tal como los CERT nacionales y las organizaciones de informes de seguridad.

  3. Informes de otras fuentes

    Según corresponda, se recomienda a los RO abordar adecuadamente los informes de abuso técnico del DNS presentados por parte de fuentes públicas. Además, se alienta a los RO a garantizar que se implementen los procedimientos adecuados para que se pueda prestar la debida atención a cualquier amenaza verificada. Esto incluye informes y solicitudes de usuarios, miembros del público o aquellos identificados a través del análisis técnico elegido por el RO. Para evitar toda duda, los informes recibidos de fuentes anónimas nunca se deben descartar únicamente debido al hecho de que el informe se realizó de manera anónima. Los RO deben comprometerse a examinar todos los informes realizados de buena fe, ya sea de forma anónima o no, en función de los méritos y la evidencia presentada.

Respuesta del Registro

Para mayor claridad, en el siguiente contexto, 'respuesta' se entiende como la acción o acciones posteriores a la recepción de un informe sobre una amenaza de seguridad identificada específicamente por el RO como un riesgo real de perjuicio, de conformidad con las políticas del RO, aunque sin limitarse a una respuesta para la Autoridad de Orden Público informante que informó la amenaza de seguridad que el RO está investigando.

Una vez recibida la referencia, se alienta a los RO a brindar una pronta respuesta de recepción afirmativa, indicando que la solicitud está siendo considerada. Dentro de las 24 horas posteriores al acuse de recibo inicial, el RO debería hacer todos los esfuerzos razonables para responder con su evaluación de la solicitud y, cuando sea posible y apropiado, el curso de acción elegido sobre la base de esa evaluación. De ser posible, la inclusión de un posible cronograma para las medidas a tomar resultaría beneficiosa para manejar las expectativas de ambas partes.

Los RO pueden evaluar la solicitud, de acuerdo con sus políticas, y su respuesta posterior sobre la base de los siguientes factores:

  1. Nivel de prioridad

    El juicio inicial de que una solicitud es de "Alta Prioridad" debe ser evidente y no requiere habilidades únicas para determinar un nexo con la seguridad pública. La "Alta Prioridad" se debe considerar como una amenaza inminente para la vida humana, la infraestructura crítica o la explotación infantil. Una amenaza significativa de interrupción del DNS también puede considerarse un problema de "Alta Prioridad". Para hacer estas determinaciones, los Registros deben usar sus propias políticas internas. Cualquier otro incidente no categorizado como de "Alta prioridad" relacionado con el abuso técnico del DNS, será manejado de acuerdo con la política Antiabuso del Registro cuando el mismo cuente con la facultad legal apropiada.

  2. Origen del informe

    Cada RO debe analizar, cuestionar o de otro modo indagar sobre la legitimidad del origen de una solicitud, de conformidad con sus propias políticas y procesos internos.

  3. Contenido

    El contenido de cada solicitud debe examinarse en su totalidad, ya que puede contener información de verificación o incluir peticiones específicas para el RO. Los informes de prioridad deben ser corroborados con información que demuestre un posible perjuicio evidente para la vida humana, la infraestructura crítica o la explotación infantil. Dicho contenido, incluida cualquier petición específica al RO, debe evaluarse en función de las políticas internas de cada RO respectivo y, cuando corresponda, identificar las medidas correctivas.

  4. Partes responsables

    Los RO no son necesariamente las mejores partes para abordar ciertas amenazas de seguridad. La identificación de las partes consideradas como las más relevantes y apropiadas en la resolución de la amenaza de seguridad es fundamental para la pronta resolución del asunto. Por ejemplo, en el caso de registraciones abusivas, el Registrador o el revendedor están en mejor posición de examinar y abordar los problemas de registración. Mientras que, en el caso de sistemas comprometidos, el Registratario o su proveedor de hosting mantienen el acceso administrativo a los sistemas afectados y pueden abordar mejor los problemas; sin embargo, el Operador de Registro puede ser la mejor parte para abordar amenazas a gran escala que abarcan a muchos Registratarios o Registradores.

    Si y cuando las solicitudes se categorizan como de "Alta Prioridad" y tienen un origen legítimo y creíble, tan pronto como sea posible y, a más tardar, 24 horas después del acuse de recibo, el Operador de Registro puede reconocer la amenaza y comunicar los pasos planificados para mitigar la amenaza de seguridad. Cuando los incidentes no sean de "Alta Prioridad", se alienta a los RO a que respondan dentro de las 24 horas con detalles de lo que harán en el futuro, incluso cuando ellos pueden no hacer nada. Se alienta a los RO a que comuniquen el análisis de la amenaza al solicitante, a fin de clarificar por qué pueden o no tomar medidas adicionales o que la mitigación debe ser manejada a través de una parte diferente.

    Se alienta a los RO a que se relacionen con una o más agencias de orden público competentes en su jurisdicción (por ejemplo, la unidad nacional de delitos de alta tecnología) o agencias adecuadas de seguridad pública que puedan:

    • ayudar a evaluar informes sobre amenazas de seguridad.
    • ayudar con la identificación y verificación de las agencias de orden público y de seguridad pública aplicables.
    • servir como facilitadores entre los RO y los funcionarios investigadores de orden público.

    Se alienta a los RO a compartir información sobre nombres de dominio abusados con otros RO y agencias de orden público competentes, cuando sea apropiado, a fin de evitar el uso indebido del DNS.

  5. Respeto de la privacidad y la confidencialidad

    La presentación de informes y la resolución de una amenaza de seguridad identificada normalmente implicará el procesamiento de información de identificación personal (PII) por parte del RO, las autoridades de orden público o una autoridad competente y relevante. Al responder a una amenaza de seguridad identificada, los RO deben tener en cuenta sus respectivas políticas de privacidad, las mejores prácticas aceptadas en cuanto a confidencialidad, seguridad de datos, transferencia de datos y retención de datos, así como cualquier ley local, requisitos contractuales u otros requisitos vinculantes.

    De conformidad con el proceso de la ICANN, podr haber iteraciones y actualizaciones futuras de este marco, según corresponda.


1 Este Marco no cubre el deber de los Operadores de Registro de realizar periódicamente un análisis técnico para evaluar si los dominios en su gTLD son utilizados para perpetrar amenazas a la seguridad, tal como prácticas de pharming, phishing, malware y botnets, ni cubre el requisito de que los Operadores de Registro mantengan informes estadísticos sobre la cantidad de amenazas de seguridad identificadas y las acciones tomadas como resultado de las comprobaciones de seguridad periódicas. Como consecuencia, el marco no cubre la respuesta a ninguna amenaza de seguridad que pueda ser descubierta por el propio Operador de Registro en el proceso del análisis técnico periódico requerido. Sin embargo, los Operadores de Registro pueden optar por aplicar el mismo marco a su respuesta ante esas amenazas de seguridad.

2 Comúnmente conocido como "suspensión", el efecto será detener los servicios del DNS relevantes que están bajo el control del RO, sin incautar el dominio.

3 El estado de 'bloqueo' del registro es, de hecho, una combinación de estos tres códigos de estado de EPP: serverTransferProhibited, serverDeleteProhibited y serverUpdateProhibited.

4 Una técnica que podría usarse como defensa para dirigir el tráfico malicioso a un servidor específico.

5 Los datos registrados pueden contener información de identificación personal (PII). Cualquier acción debe llevarse a cabo de acuerdo con los requisitos apropiados de la jurisdicción del RO.

Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."