Governação de dangling DNS para NIS2, DORA e GDPR

O CISO recebe a mensagem às 07:12 de uma segunda-feira.

Um investigador de segurança encontrou promo.company.com a apontar para uma aplicação cloud abandonada. O registo DNS continua ativo. O recurso cloud já não existe. A instância SaaS que suportava a campanha foi eliminada há seis meses, pouco depois de o Marketing ter migrado para outra plataforma. Ninguém removeu o CNAME.

Às 08:30, a pergunta já não é “Alguém consegue tomar controlo do subdomínio?”. Passa a ser “Porque é que ninguém sabia que este ativo existia?”.

Às 09:15, o Jurídico está envolvido porque o subdomínio recolheu endereços de correio eletrónico para uma lista de espera de produto. Compras está envolvida porque a plataforma da campanha era gerida por uma agência. Conformidade está envolvida porque a empresa se prepara para uma auditoria de acompanhamento ISO/IEC 27001:2022, para a preparação para NIS2 e para questionários de garantia de clientes. O EPD pergunta se a exposição pode constituir uma violação de dados pessoais ao abrigo do GDPR caso o subdomínio seja utilizado como vetor de ataque. O CFO pergunta se a mesma fragilidade pode afetar um portal de pagamentos no ambiente regulado de serviços financeiros do grupo.

A correção técnica pode demorar minutos. O problema de governação pode demorar meses a resolver se a organização não conseguir demonstrar que todos os ativos expostos à Internet são conhecidos, têm proprietário, são revistos, monitorizados e retirados de serviço através de um processo controlado.

É por isso que dangling DNS e a prevenção da tomada de controlo de subdomínios não podem ser tratados como uma tarefa restrita de limpeza de DNS. Um registo DNS obsoleto é frequentemente um sintoma visível de falhas de controlo mais profundas: inventário de ativos incompleto, propriedade mal definida, ausência de evidência de descomissionamento, controlo de alterações deficiente, gestão inadequada da saída de fornecedores, monitorização insuficiente da superfície de ataque externa e classificação pouco clara de incidentes.

Para os clientes da Clarysec, dangling DNS é um teste ao sistema de gestão. Mostra se políticas, controlos, registos, evidência e responsabilização funcionam de facto quando uma dependência cloud esquecida se transforma numa oportunidade para o atacante.

O que dangling DNS significa realmente

A tomada de controlo de um subdomínio torna-se possível quando um registo DNS, frequentemente um CNAME, aponta para um recurso que já não existe ou que já não é controlado pela organização. Se um atacante conseguir reclamar ou recriar o recurso de destino na plataforma cloud ou SaaS, pode conseguir disponibilizar conteúdo sob o subdomínio de confiança da organização.

Exemplos comuns incluem:

• Um CNAME que aponta para um serviço de aplicação cloud não reclamado.
• Um hostname SaaS personalizado deixado no DNS após o cancelamento da subscrição.
• Uma distribuição CDN removida da consola do fornecedor, mas ainda referenciada no DNS público.
• Um microsite de marketing descomissionado por uma agência sem remoção do DNS.
• Um endpoint de armazenamento ou mapeamento de website estático que pode ser registado novamente.
• Um subdomínio de desenvolvimento exposto através de um projeto platform-as-a-service esquecido.

O impacto no negócio pode ser grave. Atacantes podem alojar páginas de phishing, capturar credenciais, distribuir malware, abusar da reputação do domínio, intercetar dados de sessão ou prejudicar a confiança na marca. Quando o subdomínio tratou anteriormente dados pessoais, mesmo uma tomada de controlo de curta duração pode desencadear uma avaliação de violação de dados pessoais ao abrigo do GDPR. Quando o serviço afetado suporta operações financeiras reguladas, o incidente também pode exigir avaliação ao abrigo de DORA ou de referenciais internos de gestão do risco das TIC.

Os auditores veem cada vez mais dangling DNS como evidência da maturidade dos controlos. Um único registo obsoleto pode indicar que a organização não sabe o que possui, quem é o proprietário, como as alterações são revistas, como os serviços cloud são encerrados ou como os ativos expostos externamente são monitorizados.

É por isso que a Clarysec mapeia esta questão face às expectativas de auditoria da ISO/IEC 27001:2022 ISO/IEC 27001:2022, ISO/IEC 27002:2022 ISO/IEC 27002:2022, NIS2, DORA, GDPR, NIST CSF 2.0 e COBIT 2019.

Porque a ISO 27001:2022 é a base prática

A forma mais robusta de governar dangling DNS não é criar programas separados para NIS2, DORA e GDPR. É utilizar a ISO/IEC 27001:2022 como base do sistema de gestão e gerar evidência uma vez para múltiplas necessidades de garantia.

Os requisitos relevantes começam antes do Anexo A. As cláusulas 4.1 a 4.4 exigem que a organização compreenda o seu contexto, os requisitos das partes interessadas, o âmbito do SGSI e as dependências com outras organizações. Para a governação de dangling DNS, o âmbito deve incluir DNS externo, domínios, entidades registadoras, serviços cloud, plataformas SaaS, agências, alojamento gerido, CDNs e qualquer terceiro que possa criar ou retirar serviços expostos à Internet.

As cláusulas 5.1 a 5.3 tornam esta questão um tema de liderança e responsabilização. A gestão deve alinhar o SGSI com a direção do negócio, disponibilizar recursos, comunicar a importância da segurança da informação e atribuir responsabilidades. Se o Marketing pode lançar um microsite, a Engenharia pode criar endpoints cloud e Compras pode cessar contratos SaaS, a organização precisa de um modelo de governação que atribua propriedade clara de DNS e serviços entre todos esses intervenientes.

As cláusulas 6.1.1 a 6.1.3 fornecem a lógica de avaliação de riscos, tratamento de riscos e Declaração de Aplicabilidade. Dangling DNS deve ser registado como um cenário de risco realista, não apenas como uma saída de ferramenta de análise. Afeta a confidencialidade, a integridade e a disponibilidade, e frequentemente mapeia para obrigações legais, regulamentares e contratuais.

As cláusulas 7.5, 8.1, 8.2 e 8.3 transformam a governação em evidência. Exigem informação documentada controlada, processos operacionais planeados e controlados, consideração de alterações não intencionais, controlo de processos fornecidos externamente, avaliações periódicas de risco e resultados documentados do tratamento.

O Anexo A fornece então o catálogo de controlos. Em projetos da Clarysec, as principais relações com a ISO/IEC 27002:2022 costumam ser as seguintes:

O ponto é simples. A ISO/IEC 27001:2022 não exige uma limpeza pontual heroica. Exige um modelo operacional controlado que previna a recorrência.

A perspetiva dos Zenith Controls: um risco, três âncoras de controlo

Em Zenith Controls: The Cross-Compliance Guide Zenith Controls, a Clarysec utiliza controlos relevantes da ISO/IEC 27002:2022 como âncoras de conformidade transversal. Para a governação de dangling DNS e da tomada de controlo de subdomínios, três controlos são centrais.

O controlo 5.9, Inventário de informação e outros ativos associados, é classificado como preventivo, suporta a confidencialidade, a integridade e a disponibilidade, alinha-se com o conceito de cibersegurança Identify e enquadra-se na gestão de ativos como capacidade operacional, tendo governação, ecossistema e proteção como domínios de segurança.

O controlo 5.23, Segurança da informação na utilização de serviços cloud, é classificado como preventivo, suporta a confidencialidade, a integridade e a disponibilidade, alinha-se com Protect e enquadra-se na segurança das relações com fornecedores como capacidade operacional, tendo governação, ecossistema e proteção como domínios de segurança.

O controlo 8.8, Gestão de vulnerabilidades técnicas, é classificado como preventivo, suporta a confidencialidade, a integridade e a disponibilidade, alinha-se com Identify e Protect e enquadra-se na gestão de ameaças e vulnerabilidades como capacidade operacional, tendo governação, ecossistema, proteção e defesa como domínios de segurança.

Isto é importante porque dangling DNS não é apenas uma falha de controlo de ativos, nem apenas uma falha de controlo cloud, nem apenas uma vulnerabilidade. É as três coisas. A organização deve demonstrar que o inventário de ativos, a governação da utilização da cloud e a gestão de vulnerabilidades se reforçam mutuamente.

A Clarysec acrescenta frequentemente práticas de apoio em torno destas âncoras: ISO/IEC 27005 para disciplina de avaliação e tratamento de riscos, ISO/IEC 27017 para governação da segurança de serviços cloud, ISO/IEC 27018 quando serviços cloud tratam informações pessoais identificáveis (PII), ISO/IEC 27701 para gestão da informação de privacidade e ISO 22301 quando a continuidade e a resposta a crises são relevantes.

A evidência das políticas que já exigem controlo do ciclo de vida do DNS

Muitas organizações já têm políticas que, se forem implementadas corretamente, preveniriam dangling DNS. A lacuna é que o controlo do ciclo de vida do DNS não está explicitamente ligado a essas políticas.

A Asset Management Policy-sme - SME da Clarysec Asset Management Policy-sme - SME, Requisitos de implementação da política, cláusula 6.6.1, estabelece:

Ativos baseados na cloud (por exemplo, contas de armazenamento, plataformas SaaS, domínios web) também devem ser incluídos no inventário.

A mesma política acrescenta na cláusula 6.6.2:

A propriedade, a finalidade, os privilégios de acesso e os prazos de renovação devem ser documentados.

Para a governação de dangling DNS, isto significa que todos os subdomínios de produção e subdomínios materiais de não produção devem ter um proprietário nomeado, uma finalidade de negócio, um serviço associado, um modelo de acesso e uma data de revisão.

Mais importante ainda, a cláusula 6.6.3 estabelece:

Serviços expirados ou não utilizados devem ser desativados e removidos do inventário.

Para DNS, isto deve ser interpretado com cuidado. Remover o serviço do inventário não basta. O registo DNS, a vinculação cloud, a reivindicação de domínio personalizado SaaS, o certificado, a regra WAF, a configuração CDN e a entrada de monitorização também devem ser revistos.

A versão empresarial reforça este conceito mais amplo de ativo. A Asset Management Policy da Clarysec Asset Management Policy, Âmbito, cláusula 2.2.5, estabelece:

Ativos lógicos: nomes de domínio, licenças, contas de utilizador, configurações de referência

Nomes de domínio e configurações não são pormenores administrativos. São ativos portadores de confiança que podem tornar-se caminhos de ataque.

A ligação ao controlo de alterações é igualmente importante. A Change Management Policy da Clarysec Change Management Policy, Finalidade, cláusula 1.1, estabelece:

Esta política estabelece um quadro formal para iniciar, avaliar, aprovar, implementar e rever alterações aos sistemas de informação, infraestrutura, aplicações e processos relacionados da organização.

Uma remoção de DNS, cessação SaaS, eliminação de aplicação cloud, migração CDN ou retirada de um microsite de marketing deve, por isso, gerar evidência de alteração. A ausência de um ticket de alteração é frequentemente o primeiro sinal de alerta em auditoria.

A governação cloud também deve estar ligada. A Cloud Usage Policy da Clarysec Cloud Usage Policy, Requisitos de governação, cláusula 5.5, estabelece:

A Equipa de Segurança da Informação deve avaliar regularmente o tráfego de rede, a atividade DNS e os logs para detetar utilização não autorizada da cloud (Shadow IT). As violações detetadas devem ser investigadas prontamente.

Para a prevenção da tomada de controlo de subdomínios, a monitorização da atividade DNS não se limita a Shadow IT. Também abrange IT obsoleta, ou seja, ativos que foram autorizados no passado mas já não estão sob controlo.

Um fluxo de trabalho prático da Clarysec para a governação de dangling DNS

Um programa robusto de dangling DNS não é complicado. É disciplinado, repetível e ligado ao SGSI, à gestão de vulnerabilidades, à gestão de alterações e ao ciclo de vida dos fornecedores.

Para PME, isto pode começar como uma ferramenta simplificada de acompanhamento de ativos. Para empresas, normalmente integra exportações DNS, gestão da superfície de ataque externa, inventários de ativos cloud, registos CMDB, analisadores de vulnerabilidades, alertas SIEM e sistemas de tickets.

A pergunta de governação mantém-se: consegue demonstrar que todos os subdomínios alcançáveis externamente são conhecidos, têm proprietário, são monitorizados e podem ser removidos através de um processo controlado?

O subdomínio de campanha abandonado, tratado corretamente

Voltemos ao incidente de segunda-feira. promo.company.com aponta para um site de campanha SaaS abandonado.

Primeiro, o responsável de segurança cria um registo de vulnerabilidade porque o ativo está exposto externamente. A Vulnerability and Patch Management Policy da Clarysec Vulnerability and Patch Management Policy, Requisitos de implementação da política, cláusula 6.1.1, estabelece:

Todos os sistemas devem ser analisados pelo menos mensalmente; ativos de alto risco ou expostos externamente devem ser analisados semanalmente.

Para PME, a política equivalente reforça a priorização. A Vulnerability and Patch Management Policy-sme - SME Vulnerability and Patch Management Policy-sme - SME, Requisitos de implementação da política, cláusula 6.5.1, estabelece:

Sistemas que tratam dados pessoais, disponibilizam acesso remoto ou estão expostos externamente devem ser priorizados para análise e atualizações.

Em segundo lugar, o proprietário é identificado através do Registo de Ativos. Se o proprietário for desconhecido, isso constitui uma falha de controlo na governação de ativos. O registo é atualizado para incluir nome DNS, fornecedor de destino, proprietário original do negócio, classificação de dados, fornecedor e estado.

Em terceiro lugar, a TI verifica a plataforma cloud ou SaaS. Se a conta cloud tiver sido eliminada, a Cloud Usage Policy-sme - SME da Clarysec Cloud Usage Policy-sme - SME, Requisitos de implementação da política, cláusula 6.3.6, é diretamente relevante:

Contas cloud eliminadas devem ser revistas pelo prestador de TI ou pelo Diretor-Geral quanto a acesso residual, dados órfãos ou conteúdo ignorado.

Em quarto lugar, o proprietário da alteração abre um ticket de alteração de emergência ou acelerada para remover o registo DNS ou reclamar temporariamente o recurso antes da remoção. O ticket inclui avaliação de impacto, plano de reversão, aprovações, evidência de implementação e validação pós-alteração.

Em quinto lugar, o responsável de privacidade avalia se o subdomínio tratou ou poderia ter exposto dados pessoais. A PII Security and Access Control Policy da Clarysec PII Security and Access Control Policy, Configuração segura e gestão de vulnerabilidades, cláusula 4.7.4, estabelece:

[Ambos] O Proprietário do sistema / Proprietário da aplicação DEVE registar a cobertura da avaliação de vulnerabilidades para sistemas que tratam informações pessoais identificáveis (PII) no REG12 pelo menos trimestralmente e após alteração técnica material.

A cláusula 4.7.5 acrescenta:

[Ambos] O Líder de Segurança da Informação DEVE registar no REG12, no prazo de cinco dias úteis após a validação, as vulnerabilidades de alto risco não resolvidas que afetem informações pessoais identificáveis (PII).

Estas cláusulas aplicam-se quer a organização atue como responsável pelo tratamento quer como subcontratante, porque estão assinaladas como [Ambos]. Para uma questão de dangling DNS que envolva informações pessoais identificáveis (PII), a evidência não deve ficar apenas num ticket técnico. Deve refletir-se no registo de evidências de vulnerabilidades de PII.

Em sexto lugar, se uma agência ou fornecedor SaaS alojou a campanha, Compras verifica os registos de terceiros. A Processor, Subprocessor and Third-Party Privacy Management Policy da Clarysec Processor, Subprocessor and Third-Party Privacy Management Policy, Identificação e classificação da relação, cláusula 4.1.2, estabelece:

[Todos] O Proprietário do processo / Proprietário do negócio DEVE identificar no REG08, antes da aquisição, integração, renovação ou alteração material de privacidade relativa a terceiros, cada relação proposta com terceiros que irá tratar, aceder, receber, armazenar, transmitir, suportar ou de outra forma afetar informações pessoais identificáveis (PII).

A cláusula 4.5.5 exige:

[Ambos] O Proprietário do Fornecedor / Compras DEVE registar no REG08 os locais de tratamento, os locais de alojamento e os indicadores de transferência internacional, e ligar a evidência de transferência aplicável ao REG09 antes de aprovar um subcontratante, subcontratante subsequente, alteração de localização ou alteração de serviço relevante para transferências.

Por fim, o responsável de conformidade organiza o pacote de evidências. A Audit and Compliance Monitoring Policy da Clarysec Audit and Compliance Monitoring Policy, Objetivos, cláusula 3.4, estabelece que um dos objetivos é:

Gerar evidência defensável e um rasto de auditoria em apoio de pedidos de esclarecimento regulamentares, processos judiciais ou pedidos de garantia por parte de clientes.

Esse é o resultado de que o CISO precisa quando um cliente, regulador ou auditor pergunta: “Como sabem que isto não voltará a acontecer?”.

Onde se enquadra o Zenith Blueprint

O Zenith Blueprint: An Auditor’s 30-Step Roadmap da Clarysec Zenith Blueprint converte controlos em práticas operacionais prontas para auditoria. Dangling DNS mapeia fortemente para quatro áreas.

Na fase Controls in Action, a Etapa 22 cobre os controlos organizacionais 5.1 a 5.18, incluindo o controlo 5.9 da ISO/IEC 27002:2022. O Zenith Blueprint afirma:

Nenhuma organização consegue proteger aquilo que não sabe que possui. O controlo 5.9 formaliza este princípio basilar, exigindo a criação e manutenção de um inventário atualizado de toda a informação e ativos associados relevantes para o SGSI.

E prossegue:

Na sua forma mais estratégica, um inventário de ativos funciona como o sistema nervoso central do seu SGSI.

O inventário de subdomínios não é uma lista paralela. Alimenta decisões de acesso, análise de vulnerabilidades, registo de eventos, gestão de fornecedores, mapeamento de privacidade e resposta a incidentes.

Na Etapa 20, o Zenith Blueprint cobre os controlos tecnológicos 8.18 a 8.26. Para o controlo 8.21, Segurança dos serviços de rede, instrui as organizações a validar a segurança dos serviços de rede:

Liste todos os serviços de rede internos e externos (DNS, VPN, SMTP, DHCP, gateways de API, etc.).

É por isso que fornecedores DNS, entidades registadoras, DNS cloud, plataformas CDN e funcionalidades de domínios personalizados SaaS pertencem ao registo de serviços.

Na Etapa 19, o Zenith Blueprint cobre os controlos tecnológicos 8.1 a 8.17. Para o controlo 8.8, afirma:

Gerir vulnerabilidades é uma das áreas mais críticas da higiene de cibersegurança moderna. Embora firewalls e ferramentas antivírus forneçam proteção, podem ser comprometidas se sistemas sem patches ou serviços mal configurados ficarem expostos.

Um registo dangling DNS é um caminho de serviço externo mal configurado. Mesmo quando não existe CVE, deve ser tratado através da gestão de vulnerabilidades: validar, pontuar, atribuir, remediar, retestar e encerrar.

Na Etapa 23, o Zenith Blueprint aborda os controlos organizacionais 5.19 a 5.37. Para o controlo 5.23, recomenda:

Liste todos os serviços cloud atualmente em utilização (5.23), incluindo Shadow IT quando conhecido. Identifique quem os aprovou e se foi realizada diligência prévia. Desenvolva uma lista de verificação de avaliação simplificada que cubra localização dos dados, modelo de acesso, registo de eventos e cifragem.

Para a prevenção da tomada de controlo de subdomínios, acrescente domínios personalizados, dependências DNS, proprietário do descomissionamento e evidência de saída a essa lista de verificação de avaliação de serviços cloud.

Mapeamento para NIS2, DORA e GDPR

A NIS2 torna a governação de dangling DNS uma questão ao nível do órgão de administração para muitas entidades essenciais e importantes. O Article 20 exige que os órgãos de administração aprovem medidas de gestão de riscos de cibersegurança, supervisionem a implementação e recebam formação em cibersegurança. O Article 21 exige medidas técnicas, operacionais e organizativas adequadas e proporcionadas, utilizando uma abordagem multirriscos. As suas áreas mínimas incluem análise de riscos, tratamento de incidentes, continuidade de negócio, segurança da cadeia de fornecimento, aquisição, desenvolvimento e manutenção seguros, tratamento de vulnerabilidades, avaliação da eficácia, higiene de cibersegurança, formação, controlo de acesso e gestão de ativos.

Um programa de dangling DNS mapeia diretamente para essas áreas. O Article 21(3) também exige que a segurança da cadeia de fornecimento considere vulnerabilidades específicas de cada fornecedor direto ou prestador de serviços. Se uma agência de marketing, fornecedor SaaS, prestador de alojamento gerido ou plataforma cloud gerir domínios personalizados, os controlos específicos de fornecedor devem abranger propriedade de DNS, saída do serviço, apoio a incidentes e entrega de evidência.

O Article 23 é relevante se a tomada de controlo ocorrer ou for capaz de causar perturbação operacional grave, perda financeira ou danos materiais ou imateriais consideráveis. A NIS2 utiliza reporte faseado: alerta precoce no prazo de 24 horas após tomar conhecimento de um incidente significativo, notificação no prazo de 72 horas, relatórios intermédios quando solicitados e relatório final no prazo de um mês após a notificação do incidente.

Para entidades financeiras, DORA é o regime setorial específico de resiliência operacional digital. Os Articles 5 e 6 exigem um quadro interno de governação e controlo para a gestão do risco das TIC, com responsabilidade final do órgão de administração, funções claras de TIC, políticas para disponibilidade, autenticidade, integridade e confidencialidade dos dados, planos de auditoria, recursos, política relativa a serviços terceiros e um quadro documentado de gestão do risco das TIC.

Os Articles 8 a 14 formam o núcleo operacional. O Article 8 exige identificação, classificação e documentação de funções de negócio suportadas por TIC, ativos de informação, ativos de TIC, dependências, interligações com terceiros de TIC, inventários, cenários de risco e sistemas legados. Um CNAME em dangling DNS é frequentemente uma dependência não identificada. O Article 9 exige proteção e prevenção. O Article 10 exige deteção de atividade anómala, incidentes TIC e potenciais pontos únicos de falha. Os Articles 11 e 12 abordam continuidade, recuperação, cópia de segurança e restauro. O Article 13 exige aprendizagem a partir de vulnerabilidades, ameaças, incidentes e testes.

Os Articles 17 a 19 formalizam a gestão, classificação e comunicação de incidentes. Os Articles 28 a 30 tornam o risco de terceiros TIC baseado no ciclo de vida. As entidades financeiras mantêm responsabilidade plena quando utilizam prestadores de serviços de TIC. Para preparação para DORA, a Clarysec recomenda acrescentar quatro campos a todos os registos de DNS e serviços cloud: suporte a função crítica ou importante, prestador terceiro de serviços de TIC, referência de contrato ou registo, e estado de testes de planos de saída.

O GDPR aplica-se quando a questão envolve dados pessoais. A tomada de controlo de um subdomínio não é automaticamente uma violação de dados pessoais, mas pode tornar-se uma se o subdomínio afetado recolher credenciais, capturar dados de formulários, personificar indevidamente um serviço, expor identificadores de utilizador ou permitir acesso não autorizado a dados pessoais. O GDPR Article 5 exige integridade, confidencialidade e responsabilização. O Article 32 exige segurança do tratamento adequada. O Article 33 pode exigir notificação à autoridade de controlo se uma violação de dados pessoais for suscetível de resultar num risco para os direitos e liberdades das pessoas singulares.

A PII Incident and Breach Management Policy da Clarysec PII Incident and Breach Management Policy, Classificação e avaliação da violação de dados pessoais, cláusula 4.2.6, apoia esta análise de acionamento multirregime:

[Condicional] O Responsável de Privacidade / Gestor do PIMS DEVE avaliar, para cada incidente de alto impacto relativo a informações pessoais identificáveis (PII), os acionadores de reporte legais, setoriais, do setor financeiro, de cibersegurança, contratuais, de clientes e de destinatários dos serviços aplicáveis, e registar o resultado de aplicabilidade no REG01, REG08 e REG10.

Esse registo de decisão é exatamente o que é necessário quando uma tomada de controlo de subdomínio pode envolver GDPR, NIS2, DORA, contratos e notificação a clientes.

Como os auditores testarão a sua evidência

Um SGSI integrado deve permitir responder a diferentes auditores com a mesma base de evidência. A formulação da pergunta muda, mas a evidência é frequentemente a mesma.

Uma perspetiva de garantia mais ampla inclui frequentemente NIST CSF 2.0 e COBIT 2019. O NIST CSF 2.0 ajuda a expressar o estado-alvo através dos resultados GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND e RECOVER. Um Perfil Atual pode evidenciar revisões manuais trimestrais de DNS e desvinculação SaaS inconsistente. Um Perfil-Alvo pode exigir verificações automatizadas semanais de tomada de controlo, atribuição obrigatória de proprietário, evidência de saída de fornecedores e integração com a gestão de alterações.

Um auditor orientado para COBIT 2019 ou ISACA normalmente perguntará quem é o proprietário do processo, como o risco é avaliado e direcionado, se as alterações são controladas, se os fornecedores são geridos, se a configuração e os ativos são fiáveis e se a evidência de garantia suporta o reporte à gestão. Pode não começar por pedir uma lista de CNAMEs. Pode perguntar como a gestão sabe que os serviços digitais externos são controlados ao longo de todo o ciclo de vida.

Como é boa evidência de auditoria

Um pacote de auditoria de dangling DNS deve ser suficientemente pequeno para manter, mas suficientemente completo para defender. A Clarysec recomenda normalmente o seguinte conjunto de evidências:

• Inventário de zonas DNS com fonte, data, tipo de registo, destino e proprietário.
• Resultados de análise da superfície de ataque externa que demonstrem verificações de tomada de controlo.
• Entradas do Registo de Ativos para domínios, subdomínios, serviços cloud, aplicações SaaS e CDNs.
• Registo de serviços que mostre responsabilidade interna ou de fornecedor.
• Tickets de alteração para criação, modificação e eliminação de registos DNS.
• Listas de verificação de integração cloud e SaaS que incluam domínio personalizado e revisão DNS.
• Contratos com fornecedores ou cláusulas de segurança que cubram DNS, alojamento, apoio a incidentes e saída.
• Tickets de vulnerabilidade com severidade, proprietário, data de remediação e evidência de reteste.
• Avaliação de informações pessoais identificáveis (PII) quando o subdomínio trata ou tratou anteriormente dados pessoais.
• Registos de classificação de incidentes para suspeita ou confirmação de tomada de controlo.
• Lições aprendidas e procedimentos atualizados após constatações.

As métricas também importam. A gestão deve ver o número de subdomínios externos, a percentagem com proprietários atribuídos, o número de constatações de dangling DNS, o tempo médio de remediação, constatações de alto risco vencidas, subdomínios alojados por fornecedores sem referência contratual atual e a percentagem de saídas cloud com evidência de remoção de DNS.

Estas métricas transformam a higiene técnica em evidência de supervisão pela gestão.

Padrões comuns de falha que a Clarysec encontra

Em clientes SaaS, fintech, tecnologia de saúde, serviços geridos e comércio eletrónico, os mesmos padrões repetem-se.

Primeiro, a propriedade do DNS está dividida entre equipas. A Engenharia é proprietária da cloud. O Marketing é proprietário das campanhas. A TI é proprietária do acesso ao fornecedor DNS. Compras é proprietária da cessação SaaS. Ninguém é proprietário de todo o ciclo de vida.

Segundo, a eliminação cloud é tratada como o fim do serviço. Na realidade, DNS, certificados, regras WAF, monitorização, segredos, documentação e registos de fornecedores podem permanecer.

Terceiro, os analisadores de vulnerabilidades concentram-se em hosts ativos, mas falham condições de tomada de controlo específicas de fornecedores. As organizações precisam de verificações da superfície de ataque externa que compreendam estados de erro comuns em SaaS e cloud.

Quarto, os procedimentos de saída de fornecedores concentram-se em faturas e devolução de dados, mas não em domínios personalizados, registos DNS e alterações de subcontratantes subsequentes.

Quinto, as equipas de privacidade são notificadas demasiado tarde. Se um subdomínio tratou informações pessoais identificáveis (PII), o EPD ou responsável de privacidade deve participar na classificação antes de se assumirem conclusões.

Sexto, a evidência existe, mas está dispersa. A exportação DNS está numa ferramenta, os tickets de alteração noutra, os contratos de fornecedores em Compras, os relatórios de vulnerabilidades em ferramentas de análise e a análise de privacidade no correio eletrónico. Os auditores veem a fragmentação como uma fragilidade.

O toolkit da Clarysec resolve isto ligando políticas, registos, controlos e fluxos de trabalho de evidência.

Um plano de ação de 30 dias para governação de DNS

Se encontrou um registo dangling DNS, assuma que existem mais. Se não encontrou nenhum, certifique-se de que consegue demonstrar porquê.

Comece com este plano de 30 dias:

1. Exporte todas as zonas DNS autoritativas.
2. Identifique registos CNAME, ALIAS, A e AAAA que apontam para serviços cloud, SaaS, CDN e serviços geridos por agências.
3. Atribua proprietários e finalidades de negócio.
4. Execute verificações de tomada de controlo e valide manualmente registos suspeitos.
5. Crie tickets de vulnerabilidade para riscos confirmados.
6. Remova ou reclame registos expostos através de controlo de alterações.
7. Atualize o Registo de Ativos, o Registo de Serviços Cloud e o Registo de Fornecedores.
8. Reveja se algum subdomínio afetado tratou informações pessoais identificáveis (PII).
9. Acrescente verificações do ciclo de vida do DNS à integração cloud, à aquisição SaaS e à saída de fornecedores.
10. Reporte métricas à gestão.

A correção técnica de dangling DNS é frequentemente simples. A correção de governação é o que previne a próxima tomada de controlo.

A Clarysec pode ajudar a operacionalizar isto usando Zenith Blueprint Zenith Blueprint, Zenith Controls Zenith Controls e o nosso toolkit de políticas para gestão de ativos, utilização da cloud, gestão de vulnerabilidades, governação de fornecedores, segurança de informações pessoais identificáveis (PII), resposta a incidentes e evidência de auditoria.

Se pretende uma abordagem pronta para auditoria, a Clarysec pode ajudar a criar o pacote de evidências de exposição DNS e cloud, mapeá-lo para ISO/IEC 27001:2022, NIS2, DORA e GDPR, e transformar subdomínios esquecidos em ativos controlados, com proprietário e monitorizados. Descarregue o toolkit Clarysec relevante, solicite uma demonstração ou agende uma avaliação de governação de DNS antes que um testador de intrusão, auditor ou atacante encontre o próximo apontador esquecido.