Estrutura para operadores de registros responderem a ameaças à segurança

Objetivo

O objetivo desta estrutura é tratar de assuntos do NGPC (New gTLD Program Committee, Comitê do Programa de Novos gTLDs) conforme o compromisso da Diretoria da ICANN com o GAC (Governmental Advisory Committee, Comitê Consultivo para Assuntos Governamentais) referente à solicitação da ICANN de participação da comunidade para desenvolver uma estrutura para os ROs (Registry Operators, Operadores de Registros) responderem a ameaças à segurança identificadas. Esta estrutura é um documento voluntário não vinculativo projetado para articular opções que podem ser usadas pelos registros para responder a ameaças à segurança identificadas.

Esta estrutura não trata de situações em que um operador de registro não pode responder a seu próprio critério (como sujeito a uma Ordem Judicial de um juiz de jurisdição competente do Registro). Ela não reflete nenhuma política de consenso que afete os registros.

Escopo

Esta estrutura aborda as respostas de Registros a notificações de ameaças à segurança.

Categorias de ação de Registros em resposta a ameaças à segurança

Os Termos de Serviço ou as políticas de gTLDs (generic Top-Level Domains, Domínios Genérico de Primeiro Nível) de Operadores de Registros geralmente regem os tipos de respostas disponíveis a eles. Essas políticas são desenvolvidas com base em requisitos técnicos, operacionais e legais aplicáveis, que variam conforme o registro ou a jurisdição. As políticas podem ser alteradas a critério do RO e de maneira consistente com as políticas de consenso e requisitos legais para tratar de novas circunstâncias e lições aprendidas de ameaças à segurança anteriores.¹

Esta lista, embora não seja completa, representa muitas das possíveis opções de resposta a abusos disponíveis aos ROs.

Nomes de domínio existentes

• Encaminhar o problema ao Registrador.

  O encaminhamento é geralmente a primeira resposta enviada por um RO, porque o Registrador é quem tem a relação contratual com o Registrante do nome de domínio. O Registrador deve ter uma oportunidade com prazo limitado para investigar a ameaça à segurança e responder adequadamente. Uma resposta negativa ou não existente do Registrador não deve isentar o Registro de realizar uma ação.

• Interromper o nome de domínio para que ele não seja resolvido.

  Aplicar o status serverHold status remove o nome de domínio do arquivo de zona do TLD. Consequentemente, o nome de domínio não será mais resolvido na Internet pública.² Outro benefício é que esta ação é fácil de ser revertida em caso de erro.

• Bloquear o nome de domínio para que ele não seja alterado.

  Embora essa opção seja raramente usada para ameaças à segurança, aplicar o status de bloqueio³ significa que um domínio não poderá ser transferido, excluído nem ter seus detalhes modificados, mas ainda será resolvido. Às vezes, isso é visto como parte de uma ação em que o domínio é bloqueado juntamente com o confisco dos seus servidores de nomes.

• Redirecionar serviços de nomes para o nome de domínio.

  Um Registro tem a capacidade técnica de alterar os servidores de nomes de um nome de domínio. Ao alterar os servidores de nome do nome de domínio, os serviços associados ao nome de domínio podem ser redirecionados para "sink-holing" (geração de logs de tráfego) para identificar vítimas e proporcionar uma remediação.

• Transferir o nome de domínio.

  A transferência de um domínio para um Registrador adequadamente qualificado pode impedir a exploração, embora permita o gerenciamento do ciclo de vida, códigos de status EPP e expiração.

• Excluir o nome de domínio.

  A exclusão é uma ação extrema e geralmente não é recomendada sem realizar antes uma verificação cuidadosa e obter orientação das autoridades apropriadas. A restauração de um nome de domínio, se a exclusão for determinada como inapropriada, pode envolver outras dificuldades que não se manifestam quando um nome de domínio é colocado em serverHold. Normalmente, a exclusão não é tão eficiente para mitigar as ameaças à segurança quanto a suspensão, pois os registrantes podem registrar o nome de domínio novamente depois que ele for excluído da zona.

• Não realizar nenhuma ação.

  Essa opção está sempre disponível. A política do Registro pode limitar a ação de acordo com circunstâncias específicas ou ser a ação padrão, se nenhuma resposta for apropriada. Da mesma forma, um RO pode concluir que um problema encaminhado não constitui uma ameaça à segurança ou que as consequências de uma ação são piores que a ameaça em si. Como uma questão de cortesia, o RO deve responder ao originador de uma ameaça à segurança indicando o motivo para a resposta escolhida para a ameaça relatada.

Nomes de domínio (tipo DGA) não registrados

Uma ameaça à segurança pode estar associada a um nome de domínio que ainda não foi registrado. Isso pode ocorrer quando o nome de domínio for o resultado de um DGA (Domain Generation Algorithm, Algoritmo de Geração de Domínio) automático associado à atividade de botnets. Geralmente a ameaça envolverá milhares ou mais nomes de domínio.

• Criar o nome de domínio.

  Registrar um nome de domínio potencialmente malicioso parece ser algo incoerente, mas quando feito sob condições controladas, isso permite aos pesquisadores e às organizações de segurança pública, como as CERTs (Computer Emergency Readiness Teams, Equipes de Prontidão para Emergências Computacionais), tomarem a ação apropriada, como usar "sinkholing"⁴) em um nome de domínio. Da mesma forma que a opção de transferência acima, isso ajuda a identificar os computadores de vítimas para fins de mitigação. Além disso, o uso do nome de domínio é negado a agentes negativos, como ocorre com a opção bloqueio abaixo.⁵

  O RO geralmente pode escolher se delegará domínios anteriormente não registrados a um registrador adequadamente qualificado ou a seu próprio registrador interno. Os ROs devem se certificar de buscarem toda(s) a(s) isenção(ões) apropriadas ou necessárias com a ICANN no que diz respeito a certas disposições contratuais do Contrato de Registro respectivo do RO. Atualmente isso é feito pelo processo de ERSR (Expedited Registry Security Request, Solicitação Expressa de Segurança no Registro) da ICANN. O momento do recebimento da isenção depende da ICANN.

• Bloquear o registro do nome de domínio.

  Quando acordado, o RO pode reservar o nome de domínio solicitado. O solicitante deve trabalhar com o RO para estabelecer um limite de tempo apropriado para o bloqueio, se houver.

Comunicar ameaças à segurança

Embora avaliar a credibilidade da fonte seja responsabilidade do RO individual, existe uma hierarquia para a gravidade das ameaças à segurança. O RO também deve prestar atenção à qualidade e ao padrão das informações fornecidas no relatório de uma fonte, juntamente com relatórios anteriores. Um exemplo direto de uma situação que deve ter prioridade e as ações devem ser realizadas mais rapidamente, sujeito às determinações e políticas do RO, é no caso de relatórios elaborados adequadamente por LEAs (Law Enforcement Authorities, Autoridades Legais Fiscalizadoras) relevantes onde o RO está localizado ou quando uma solicitação estiver fundamentada por ordem judicial de um juiz na jurisdição do RO.

1. Relatórios de Autoridades Legais Fiscalizadoras

   Quando for confirmado que a parte notificadora é uma Autoridade Legal Fiscalizadora (incluindo autoridades legais nacionais ou outra agência governamental de segurança pública na jurisdição adequada do RO), esta estrutura recomenda que os ROs considerem esses relatórios com um alto nível de credibilidade e, sendo assim, recebam a devida prioridade. Embora os ROs devam proceder com um alto nível de certeza no que diz respeito aos encaminhamentos de LEAs, eles ainda precisam realizar todas as investigações que considerarem necessárias para garantir que os encaminhamentos constituam realmente uma ameaça à segurança e para confirmar a validade da fonte do encaminhamento.

2. Relatórios de fontes reconhecidas de ROs

   A seu próprio critério, o RO pode escolher priorizar relatórios de entidades que ele reconhece como tendo a experiência necessária na área apropriada, como CERTs nacionais e organizações de relatórios de segurança.

3. Relatórios de outras fontes

   É recomendado que os ROs analisem adequadamente os relatórios de abuso técnico do DNS de fontes públicas, conforme apropriado. Também é aconselhado que os ROs se certifiquem de que os procedimentos apropriados sejam executados, para que a seja dada a devida atenção a qualquer ameaça verificada. Isso inclui relatórios e solicitações de usuários, membros do público ou indivíduos identificados por escolha do próprio RO para análises técnicas. Para não haver dúvida, todos os relatórios recebidos de fontes anônimas nunca devem ser desconsiderados unicamente pelo fato de terem sido enviados anonimamente. Os ROs devem analisar todos os relatórios feitos em boa-fé, sejam eles anônimos ou não, com base no mérito e evidências apresentadas.

Resposta do Registro

Para fins de clareza, "resposta" no contexto a seguir se refere à ação, ou ações, após o recebimento de um relatório sobre uma ameaça à segurança identificada especificamente pelo RO como um risco real de dano, de acordo com as políticas do RO, incluindo, entre outras, uma resposta à Autoridade de Segurança Pública relatora que comunicou a ameaça à segurança sendo investigada pelo RO.

Após o recebimento do encaminhamento, é recomendado que os ROs forneçam uma resposta inicial afirmativa imediatamente, indicando que a solicitação está sendo considerada. Em até 24 horas após a confirmação do recebimento inicial, o RO deve se esforçar de maneira razoável para responder com sua avaliação da solicitação e, quando possível e apropriado, com a ação escolhida, com base nessa avaliação. Se possível, a inclusão de um possível cronograma de ação é importante para administrar as expectativas de ambas as partes.

Os ROs podem avaliar a solicitação, de acordo com suas políticas, e a resposta subsequente com base nos seguintes fatores:

1. Nível de prioridade

   O julgamento inicial de uma solicitação ser de "Alta prioridade" deve ser evidente e não exigir nenhuma habilidade especial para determinar como uma questão de segurança pública. "Alta prioridade" deve ser considerada uma ameaça iminente à vida humana, infraestrutura crítica ou exploração infantil. Um ameaça séria de interrupção do DNS também pode ser considerada como uma questão de "Alta prioridade". Os Registro devem usar suas próprias políticas internas para fazer essas determinações. Qualquer outro incidente categorizado como "Alta prioridade", relacionado a abuso técnico do DNS, será tratado conforme a política Antiabuso do Registro, quando ele tiver a discrição legal apropriada.

2. Origem do relatório

   Cada RO deve investigar, questionar ou duvidar da legitimidade da origem de uma solicitação, de acordo com suas próprias políticas ou processos internos.

3. Conteúdo

   O conteúdo de cada solicitação deve ser revisado completamente, uma vez que pode incluir informações para verificação ou solicitações específicas para o RO. Os relatórios de prioridade devem ser embasados com informações que demonstrem um possível dano evidente à vida humana, infraestruturas críticas ou exploração infantil. Esse conteúdo, incluindo qualquer solicitação específica para o RO, deve ser avaliado com base nas políticas internas de cada RO respectivo e, quando apropriado, identificar quaisquer etapas para a remediação.

4. Partes responsáveis

   Os ROs não são necessariamente as melhores partes para lidar com certas ameaças à segurança. A identificação das partes consideradas como as mais relevantes e apropriadas para resolver a ameaça à segurança é essencial para a resolução imediata do problema. Por exemplo, no caso de registros abusivos, o registrador ou revendedor é melhor para analisar e resolver problemas de registros. Por outro lado, no caso de sistemas comprometidos, o registrante ou o provedor de hospedagem dele mantém o acesso administrativo aos sistemas afetados e são os mais indicados para resolver esses problemas. No entanto, o Operador do Registro pode ser a melhor parte para solucionar ameaças em grande escala que afetem muitos registrantes ou registradores.

   Se e quando as solicitações forem categorizadas como "Alta prioridade" e de uma fonte legítima e confiável, então, o quanto antes possível e até 24 horas após a confirmação do recebimento, o Operador do Registro pode reconhecer a ameaça e comunicar as etapas planejadas para mitigar a ameaça à segurança. Quando os incidentes não forem de "Alta prioridade", é recomendado que os ROs respondam em até 24 horas com detalhes sobre o que será feito, incluindo o que eles talvez não façam. É recomendado que os ROs comuniquem a análise da ameaça ao solicitante para esclarecer o motivo pelo qual eles talvez realizem ou não uma ação ou que a mitigação deve ser encarregada à outra parte.

   É aconselhado que os ROs entrem em contato com uma ou mais agências legais fiscalizadoras competentes em suas jurisdições (por exemplo, unidade nacional de crimes de alta tecnologia) ou as agências de segurança pública adequadas que possam:

   • ajudar a avaliar os relatórios sobre ameaças à segurança;
   • ajudar na identificação e verificação das agências legais fiscalizadoras ou de segurança pública adequadas;
   • atuar como facilitadores entre os ROs e as autoridades legais fiscalizadoras encarregadas da investigação.

   É recomendado que os ROs compartilhem informações sobre nomes de domínio que sofreram abuso com outros ROs e agências legais fiscalizadoras competentes quando apropriado para evitar abuso no DNS.

5. Respeitar a privacidade e a confidencialidade

   A geração de relatório e resolução de uma ameaça à segurança identificada envolverá o processamento de PII (Personally Identifiable Information, Informações de Identificação Pessoal) por um RO, Autoridade Legal Fiscalizadora ou uma autoridade relevante e competente. Ao responder à uma ameaça de segurança identificada, os ROs devem levar em conta suas respectivas políticas de privacidade, as práticas recomendadas aceitas referentes à confidencialidade, segurança, transferência e retenção de dados, bem como quaisquer leis locais, requisitos contratuais ou outras exigências às quais se encontram vinculados.

   É possível ocorrer futuras iterações e atualizações a essa estrutura conforme apropriado, de acordo com o processo da ICANN.

---

¹ Essa Estrutura não aborda a responsabilidade de Operadores de Registro de realizar uma análise técnica periódica para avaliar se os domínios em seus gTLDs estão sendo usados para cometer ameaças à segurança, como pharming, phishing, malware e botnets, e também não aborda o requisito dos Operadores de Registro de manterem relatórios estatísticos sobre o número de ameaças à segurança identificados e as ações tomadas em decorrência das verificações periódicas de segurança. Sendo assim, a estrutura não aborda a resposta a nenhuma ameaça à segurança que possa ser detectada pelo próprio Operador de Registro durante o processo da análise técnica periódica obrigatória. No entanto, os Operadores de Registro poderão, se quiserem, aplicar a mesma estrutura em suas respostas a essas ameaças à segurança.

² Isso é mais conhecido como "suspensão", o efeito será interromper os serviços relevantes do DNS que estão sob o controle do RO – sem confiscar o domínio.

³ O status de "bloqueio" do Registro é, na realidade, uma combinação destes três códigos de status de EPP: serverTransferProhibited, serverDeleteProhibited e serverUpdateProhibited.

⁴ Uma técnica que pode ser usada como defesa contra o tráfego malicioso direto para um servidor especificado.

⁵ Os dados registrados podem conter PII (Personally Identifiable Information, Informações de Identificação Pessoal). Qualquer ação deve ser realizada de maneira alinhada aos requisitos apropriados da jurisdição do RO.