Gobernanza de registros DNS huérfanos para NIS2, DORA y GDPR

El CISO recibe el mensaje a las 07:12 de un lunes.

Un investigador de seguridad ha encontrado promo.company.com apuntando a una aplicación en la nube abandonada. El registro DNS sigue activo. El recurso en la nube ya no existe. La instancia SaaS que antes daba servicio a la campaña se eliminó hace seis meses, poco después de que el área de Marketing migrara a otra plataforma. Nadie eliminó el CNAME.

A las 08:30, la pregunta ya no es: “¿Puede alguien tomar el control del subdominio?”. La pregunta es: “¿Por qué nadie sabía que este activo existía?”.

A las 09:15, interviene el área jurídica porque el subdominio recopiló en su día direcciones de correo electrónico para una lista de espera de producto. Interviene Compras porque la plataforma de campaña estaba gestionada por una agencia. Interviene Cumplimiento porque la empresa se está preparando para una auditoría de seguimiento de ISO/IEC 27001:2022, la preparación para NIS2 y cuestionarios de aseguramiento de clientes. El delegado de protección de datos (DPO) pregunta si la exposición podría convertirse en una brecha de seguridad de datos personales conforme a GDPR si el subdominio se utiliza con fines maliciosos. El director financiero (CFO) pregunta si la misma debilidad podría afectar a un portal de pagos dentro del entorno regulado de servicios financieros del grupo.

La corrección técnica puede tardar minutos. El problema de gobernanza puede tardar meses en resolverse si la organización no puede demostrar que todos los activos expuestos a internet se conocen, tienen propietario, se revisan, se supervisan y se retiran mediante un proceso controlado.

Por eso la prevención de registros DNS huérfanos y de la toma de control de subdominios no puede tratarse como una simple tarea de limpieza de DNS. Un registro DNS obsoleto suele ser un síntoma visible de fallos de control más profundos: inventario de activos incompleto, responsabilidades mal asignadas, ausencia de evidencias de retirada, control de cambios deficiente, gestión insuficiente de la salida de proveedores, supervisión inadecuada de la superficie de ataque externa y clasificación de incidentes poco clara.

Para los clientes de Clarysec, los registros DNS huérfanos son una prueba del sistema de gestión. Muestran si las políticas, los controles, los registros, las evidencias y la responsabilidad proactiva funcionan realmente cuando una dependencia de nube olvidada se convierte en una oportunidad para el atacante.

Qué significan realmente los registros DNS huérfanos

La toma de control de un subdominio se vuelve posible cuando un registro DNS, a menudo un CNAME, apunta a un recurso que ya no existe o que la organización ya no controla. Si un atacante puede reclamar o recrear el recurso de destino en la plataforma de nube o SaaS, puede llegar a servir contenido bajo el subdominio de confianza de la organización.

Algunos ejemplos habituales son:

• Un CNAME que apunta a un servicio de aplicación en la nube no reclamado.
• Un nombre de host SaaS personalizado que permanece en DNS después de cancelar la suscripción.
• Una distribución CDN eliminada de la consola del proveedor pero aún referenciada en DNS público.
• Un micrositio de marketing retirado por una agencia sin eliminar el DNS.
• Un endpoint de almacenamiento o una asignación de sitio web estático que puede registrarse de nuevo.
• Un subdominio de desarrollo expuesto a través de un proyecto olvidado de plataforma como servicio.

El impacto en las operaciones de la organización puede ser grave. Los atacantes pueden alojar páginas de phishing, capturar credenciales, distribuir malware, abusar de la reputación del dominio, interceptar datos de sesión o dañar la confianza en la marca. Cuando el subdominio trató anteriormente datos personales, incluso una toma de control de corta duración puede activar un análisis de brecha conforme a GDPR. Cuando el servicio afectado soporta operaciones financieras reguladas, el incidente también puede requerir evaluación conforme a DORA o a marcos internos de gestión del riesgo de las TIC.

Los auditores consideran cada vez más los registros DNS huérfanos como evidencias de madurez de control. Un único registro obsoleto puede indicar que la organización no sabe qué posee, quién es responsable, cómo se revisan los cambios, cómo se cierran los servicios en la nube o cómo se supervisan los activos expuestos externamente.

Por eso Clarysec mapea este problema con las expectativas de auditoría de ISO/IEC 27001:2022 ISO/IEC 27001:2022, ISO/IEC 27002:2022 ISO/IEC 27002:2022, NIS2, DORA, GDPR, NIST CSF 2.0 y COBIT 2019.

Por qué ISO 27001:2022 es la columna vertebral práctica

La forma más sólida de gobernar los registros DNS huérfanos no consiste en crear programas separados para NIS2, DORA y GDPR. Consiste en usar ISO/IEC 27001:2022 como columna vertebral del sistema de gestión y generar una sola vez evidencias que sirvan para múltiples necesidades de aseguramiento.

Los requisitos relevantes empiezan antes del Anexo A. Las cláusulas 4.1 a 4.4 exigen que la organización comprenda su contexto, los requisitos de las partes interesadas, el alcance del SGSI y las dependencias con otras organizaciones. Para la gobernanza de registros DNS huérfanos, el alcance debe incluir DNS externo, dominios, registradores, servicios en la nube, plataformas SaaS, agencias, alojamiento gestionado, CDN y cualquier tercero que pueda crear o retirar servicios expuestos a internet.

Las cláusulas 5.1 a 5.3 convierten esto en una cuestión de liderazgo y responsabilidad. La dirección debe alinear el SGSI con la orientación estratégica de la organización, proporcionar recursos, comunicar la importancia de la seguridad de la información y asignar responsabilidades. Si Marketing puede lanzar un micrositio, Ingeniería puede crear puntos de conexión en la nube y Compras puede rescindir contratos SaaS, la organización necesita un modelo de gobernanza que asigne claramente la propiedad de DNS y de los servicios entre todos ellos.

Las cláusulas 6.1.1 a 6.1.3 proporcionan la lógica de evaluación de riesgos, tratamiento de riesgos y Declaración de Aplicabilidad. Los registros DNS huérfanos deben registrarse como un escenario de riesgo realista, no solo como la salida de una herramienta de escaneo. Afectan a la confidencialidad, integridad y disponibilidad, y a menudo se mapean con obligaciones legales, regulatorias y contractuales.

Las cláusulas 7.5, 8.1, 8.2 y 8.3 convierten la gobernanza en evidencias. Exigen información documentada controlada, procesos operativos planificados y controlados, consideración de cambios no previstos, control de procesos proporcionados externamente, evaluaciones de riesgos periódicas y resultados documentados del tratamiento.

El Anexo A proporciona después el catálogo de controles. En los proyectos de Clarysec, las relaciones principales de ISO/IEC 27002:2022 suelen ser las siguientes:

La idea es sencilla. ISO/IEC 27001:2022 no pide una limpieza heroica puntual. Pide un modelo operativo controlado que evite la recurrencia.

La visión de Zenith Controls: un riesgo, tres anclajes de control

En Zenith Controls: The Cross-Compliance Guide Zenith Controls, Clarysec utiliza controles relevantes de ISO/IEC 27002:2022 como anclajes de cumplimiento transversal. Para la gobernanza de registros DNS huérfanos y de la toma de control de subdominios, tres controles son centrales.

El control 5.9, Inventario de información y otros activos asociados, se clasifica como preventivo, apoya la confidencialidad, integridad y disponibilidad, se alinea con el concepto de ciberseguridad Identificar y se ubica bajo gestión de activos como capacidad operativa, con gobernanza, ecosistema y protección como dominios de seguridad.

El control 5.23, Seguridad de la información para el uso de servicios en la nube, se clasifica como preventivo, apoya la confidencialidad, integridad y disponibilidad, se alinea con Proteger y se ubica bajo seguridad de las relaciones con proveedores como capacidad operativa, con gobernanza, ecosistema y protección como dominios de seguridad.

El control 8.8, Gestión de vulnerabilidades técnicas, se clasifica como preventivo, apoya la confidencialidad, integridad y disponibilidad, se alinea con Identificar y Proteger y se ubica bajo gestión de amenazas y vulnerabilidades como capacidad operativa, con gobernanza, ecosistema, protección y defensa como dominios de seguridad.

Esto importa porque los registros DNS huérfanos no son solo un fallo de control de activos, ni solo un fallo de control de nube, ni solo una vulnerabilidad. Son las tres cosas. La organización debe demostrar que el inventario de activos, la gobernanza del uso de la nube y la gestión de vulnerabilidades se refuerzan entre sí.

Clarysec suele añadir prácticas de apoyo alrededor de estos anclajes: ISO/IEC 27005 para la disciplina de evaluación y tratamiento de riesgos, ISO/IEC 27017 para la gobernanza de seguridad de servicios en la nube, ISO/IEC 27018 cuando los servicios en la nube tratan PII, ISO/IEC 27701 para la gestión de la privacidad de la información e ISO 22301 cuando la continuidad y la respuesta a crisis son relevantes.

La evidencia de políticas que ya exige controlar el ciclo de vida de DNS

Muchas organizaciones ya tienen políticas que, si se implantaran correctamente, impedirían los registros DNS huérfanos. La brecha consiste en que el control del ciclo de vida de DNS no está conectado explícitamente con esas políticas.

La Asset Management Policy-sme de Clarysec Asset Management Policy-sme - SME, Requisitos de implementación de la política, cláusula 6.6.1, establece:

Los activos basados en la nube (por ejemplo, cuentas de almacenamiento, plataformas SaaS, dominios web) también deben incluirse en el inventario.

La misma política añade en la cláusula 6.6.2:

Deben documentarse la propiedad, la finalidad, los privilegios de acceso y los plazos de renovación.

Para la gobernanza de registros DNS huérfanos, esto significa que cada subdominio de producción y cada subdominio no productivo material debe tener un propietario nominal, una finalidad de negocio, un servicio vinculado, un modelo de acceso y una fecha de revisión.

Lo más importante es que la cláusula 6.6.3 establece:

Los servicios caducados o no utilizados deben desactivarse y eliminarse del inventario.

Para DNS, esto debe interpretarse con cuidado. Eliminar el servicio del inventario no es suficiente. También deben revisarse el registro DNS, la vinculación en la nube, la reclamación de dominio personalizado SaaS, el certificado, la regla WAF, la configuración CDN y la entrada de supervisión.

La versión empresarial refuerza este concepto amplio de activo. La Asset Management Policy de Clarysec Asset Management Policy, Alcance, cláusula 2.2.5, establece:

Activos lógicos: nombres de dominio, licencias, cuentas de usuario, configuraciones de referencia

Los nombres de dominio y las configuraciones no son detalles administrativos menores. Son activos que soportan confianza y pueden convertirse en rutas de ataque.

La conexión con el control de cambios es igualmente importante. La Change Management Policy de Clarysec Change Management Policy, Propósito, cláusula 1.1, establece:

Esta política establece un marco formal para iniciar, evaluar, aprobar, implementar y revisar cambios en los sistemas de información, la infraestructura, las aplicaciones y los procesos relacionados de la organización.

Por tanto, la eliminación de DNS, la terminación de un servicio SaaS, la eliminación de una aplicación en la nube, la migración de una CDN o la retirada de un micrositio de marketing deben generar evidencias de cambio. La ausencia de un ticket de cambio suele ser la primera señal de alerta en auditoría.

La gobernanza de la nube también debe estar conectada. La Cloud Usage Policy de Clarysec Cloud Usage Policy, Requisitos de gobernanza, cláusula 5.5, establece:

El equipo de seguridad de la información debe evaluar de forma rutinaria el tráfico de red, la actividad DNS y los registros para detectar el uso no autorizado de la nube (TI en la sombra). Los incumplimientos detectados deben investigarse con prontitud.

Para la prevención de toma de control de subdominios, la supervisión de la actividad DNS no se refiere solo a la TI en la sombra. También se refiere a la TI obsoleta: activos que estuvieron autorizados en su día pero que ya no están controlados.

Un flujo de trabajo práctico de Clarysec para la gobernanza de registros DNS huérfanos

Un programa sólido de registros DNS huérfanos no es complicado. Es disciplinado, repetible y está conectado con el SGSI, la gestión de vulnerabilidades, la gestión de cambios y el ciclo de vida de proveedores.

Para pymes, esto puede empezar como un registro ligero. En organizaciones grandes, normalmente integra exportaciones DNS, gestión de la superficie de ataque externa, inventarios de activos en la nube, registros de CMDB, escáneres de vulnerabilidades, alertas SIEM y sistemas de tickets.

La pregunta de gobernanza sigue siendo la misma: ¿puede demostrar que todos los subdominios accesibles externamente se conocen, tienen propietario, se supervisan y pueden eliminarse mediante un proceso controlado?

El subdominio de campaña abandonado, gestionado correctamente

Volvamos al incidente del lunes. promo.company.com apunta a un sitio de campaña SaaS abandonado.

En primer lugar, el responsable de seguridad de la información crea un registro de vulnerabilidad porque el activo está expuesto externamente. La Vulnerability and Patch Management Policy de Clarysec Vulnerability and Patch Management Policy, Requisitos de implementación de la política, cláusula 6.1.1, establece:

Todos los sistemas deben escanearse al menos mensualmente; los activos de alto riesgo o expuestos externamente deben escanearse semanalmente.

Para pymes, la política equivalente refuerza la priorización. La Vulnerability and Patch Management Policy-sme Vulnerability and Patch Management Policy-sme - SME, Requisitos de implementación de la política, cláusula 6.5.1, establece:

Los sistemas que tratan datos personales, proporcionan acceso remoto o están expuestos externamente deben priorizarse para el escaneo y las actualizaciones.

En segundo lugar, el propietario se identifica mediante el Registro de Activos. Si se desconoce el propietario, eso constituye un fallo de control frente a la gobernanza de activos. El registro se actualiza para incluir el nombre DNS, el proveedor de destino, el propietario de negocio original, la clasificación de datos, el proveedor y el estado.

En tercer lugar, TI comprueba la plataforma de nube o SaaS. Si la cuenta en la nube se eliminó, la Cloud Usage Policy-sme de Clarysec Cloud Usage Policy-sme - SME, Requisitos de implementación de la política, cláusula 6.3.6, es directamente relevante:

Las cuentas en la nube eliminadas deben ser revisadas por el proveedor de TI o el Director General para detectar acceso residual, datos huérfanos o contenido pasado por alto.

En cuarto lugar, el propietario del cambio abre un ticket de cambio de emergencia o acelerado para eliminar el registro DNS o reclamar temporalmente el recurso antes de su eliminación. El ticket incluye evaluación de impacto, plan de reversión, aprobaciones, evidencias de implementación y validación posterior al cambio.

En quinto lugar, el responsable de privacidad evalúa si el subdominio trató o pudo haber expuesto datos personales. La PII Security and Access Control Policy de Clarysec PII Security and Access Control Policy, Configuración segura y gestión de vulnerabilidades, cláusula 4.7.4, establece:

[Ambos] El propietario del sistema / propietario de la aplicación DEBE registrar la cobertura de la evaluación de vulnerabilidades para los sistemas que tratan PII en REG12 al menos trimestralmente y después de un cambio técnico material.

La cláusula 4.7.5 añade:

[Ambos] El responsable de seguridad de la información DEBE registrar en REG12, dentro de los cinco días hábiles posteriores a la validación, las vulnerabilidades de alto riesgo no resueltas que afecten a PII.

Estas cláusulas aplican tanto si la organización actúa como responsable del tratamiento como si actúa como encargado del tratamiento, porque están etiquetadas como [Ambos]. Para un problema de registro DNS huérfano que afecte a PII, las evidencias no deben residir únicamente en un ticket técnico. Deben reflejarse en el registro de evidencias de vulnerabilidades de PII.

En sexto lugar, si una agencia o proveedor SaaS alojó la campaña, Compras revisa los registros de terceros. La Processor, Subprocessor and Third-Party Privacy Management Policy de Clarysec Processor, Subprocessor and Third-Party Privacy Management Policy, Identificación y clasificación de relaciones, cláusula 4.1.2, establece:

[Todos] El propietario del proceso / propietario de negocio DEBE identificar en REG08 cada relación propuesta con terceros que vaya a tratar, acceder, recibir, almacenar, transmitir, dar soporte o afectar de otro modo a PII antes de la contratación, la incorporación, la renovación o un cambio material de privacidad con terceros.

La cláusula 4.5.5 exige:

[Ambos] El propietario de proveedores / Compras DEBE registrar las ubicaciones de tratamiento, las ubicaciones de alojamiento y los indicadores de transferencias internacionales en REG08, y vincular las evidencias de transferencia aplicables a REG09 antes de aprobar un encargado del tratamiento, subencargado del tratamiento, cambio de ubicación o cambio de servicio relevante para transferencias.

Por último, el responsable de cumplimiento empaqueta las evidencias. La Audit and Compliance Monitoring Policy de Clarysec Audit and Compliance Monitoring Policy, Objetivos, cláusula 3.4, establece que uno de los objetivos es:

Generar evidencias defendibles y una pista de auditoría en apoyo de requerimientos de autoridades reguladoras, procedimientos judiciales o solicitudes de aseguramiento de clientes.

Ese es el resultado que necesita el CISO cuando un cliente, regulador o auditor pregunta: “¿Cómo saben que esto no volverá a ocurrir?”.

Dónde encaja Zenith Blueprint

Zenith Blueprint: An Auditor’s 30-Step Roadmap de Clarysec Zenith Blueprint convierte los controles en prácticas operativas preparadas para auditoría. Los registros DNS huérfanos se mapean de forma sólida con cuatro áreas.

En la fase Controls in Action, el paso 22 cubre los controles organizativos 5.1 a 5.18, incluido el control 5.9 de ISO/IEC 27002:2022. Zenith Blueprint establece:

Ninguna organización puede proteger aquello que no sabe que tiene. El control 5.9 formaliza este principio fundamental, al exigir el establecimiento y mantenimiento de un inventario actualizado de toda la información y los activos asociados relevantes para el SGSI.

Continúa:

En su forma más estratégica, un inventario de activos actúa como el sistema nervioso central de su SGSI.

El inventario de subdominios no es una lista auxiliar. Alimenta decisiones de acceso, escaneos de vulnerabilidades, registro de eventos, gestión de proveedores, mapeo de privacidad y respuesta a incidentes.

En el paso 20, Zenith Blueprint cubre los controles tecnológicos 8.18 a 8.26. Para el control 8.21, Seguridad de los servicios de red, indica a las organizaciones que validen la seguridad de los servicios de red:

Enumere todos los servicios de red internos y externos (DNS, VPN, SMTP, DHCP, pasarelas API, etc.).

Por eso los proveedores DNS, registradores, DNS en la nube, plataformas CDN y funciones de dominio personalizado SaaS deben estar en el registro de servicios.

En el paso 19, Zenith Blueprint cubre los controles tecnológicos 8.1 a 8.17. Para el control 8.8, establece:

La gestión de vulnerabilidades es una de las áreas más críticas de la higiene cibernética moderna. Aunque los cortafuegos y las herramientas antivirus proporcionan protección, pueden verse comprometidos si quedan expuestos sistemas sin parchear o servicios mal configurados.

Un registro DNS huérfano es una ruta de servicio externo mal configurada. Incluso cuando no hay CVE, debe gestionarse mediante gestión de vulnerabilidades: validar, puntuar, asignar, remediar, repetir las pruebas y cerrar.

En el paso 23, Zenith Blueprint aborda los controles organizativos 5.19 a 5.37. Para el control 5.23, recomienda:

Enumere todos los servicios en la nube actualmente en uso (5.23), incluida la TI en la sombra cuando se conozca. Identifique quién los aprobó y si se realizó diligencia debida. Desarrolle una lista de verificación ligera de evaluación que cubra la ubicación de los datos, el modelo de acceso, el registro de eventos y el cifrado.

Para la prevención de toma de control de subdominios, añada dominios personalizados, dependencias DNS, propietario de la retirada y evidencias de salida a esa lista de verificación de evaluación de servicios en la nube.

Mapeo con NIS2, DORA y GDPR

NIS2 convierte la gobernanza de registros DNS huérfanos en una cuestión de órgano de dirección para muchas entidades esenciales e importantes. Article 20 exige que los órganos de dirección aprueben las medidas de gestión de riesgos de ciberseguridad, supervisen su implantación y sigan formación en ciberseguridad. Article 21 exige medidas técnicas, operativas y organizativas adecuadas y proporcionadas mediante un enfoque de todos los riesgos. Sus ámbitos mínimos incluyen análisis de riesgos, gestión de incidentes, continuidad del negocio, seguridad de la cadena de suministro, adquisición, desarrollo y mantenimiento seguros, gestión de vulnerabilidades, evaluación de la eficacia, higiene cibernética, formación, control de acceso y gestión de activos.

Un programa de registros DNS huérfanos se mapea claramente con esos ámbitos. Article 21(3) también exige que la seguridad de la cadena de suministro tenga en cuenta las vulnerabilidades específicas de cada proveedor directo o proveedor de servicios. Si una agencia de marketing, proveedor SaaS, proveedor de alojamiento gestionado o plataforma de nube gestiona dominios personalizados, los controles específicos del proveedor deben cubrir la propiedad DNS, la salida del servicio, el soporte ante incidentes y la entrega de evidencias.

Article 23 es relevante si se produce una toma de control o si esta puede causar una perturbación operativa grave, pérdidas financieras o daños materiales o inmateriales considerables. NIS2 utiliza notificación escalonada: alerta temprana en las 24 horas siguientes a tener conocimiento de un incidente significativo, notificación en 72 horas, informes intermedios cuando se soliciten y un informe final en el plazo de un mes desde la notificación del incidente.

Para las entidades financieras, DORA es el régimen sectorial específico de resiliencia operativa digital. Articles 5 y 6 exigen un marco interno de gobernanza y control para la gestión del riesgo de las TIC, con responsabilidad última del órgano de dirección, roles claros de TIC, políticas de disponibilidad, autenticidad, integridad y confidencialidad de los datos, planes de auditoría, recursos, política de servicios de terceros y un marco documentado de gestión del riesgo de las TIC.

Articles 8 a 14 forman el núcleo operativo. Article 8 exige identificar, clasificar y documentar funciones de negocio soportadas por las TIC, activos de información, activos de TIC, dependencias, interconexiones con terceros de TIC, inventarios, escenarios de riesgo y sistemas heredados. Un CNAME huérfano suele ser una dependencia omitida. Article 9 exige protección y prevención. Article 10 exige detectar actividad anómala, incidentes relacionados con las TIC y posibles puntos únicos de fallo. Articles 11 y 12 abordan continuidad, recuperación, copia de seguridad y restauración. Article 13 exige aprendizaje a partir de vulnerabilidades, amenazas, incidentes y pruebas.

Articles 17 a 19 formalizan la gestión, clasificación y notificación de incidentes. Articles 28 a 30 hacen que el riesgo de terceros de TIC se gestione en función del ciclo de vida. Las entidades financieras siguen siendo plenamente responsables cuando utilizan proveedores de servicios de TIC. Para la preparación para DORA, Clarysec recomienda añadir cuatro campos a cada registro de DNS y de servicios en la nube: soporte de función esencial o importante, proveedor tercero de TIC, referencia contractual o de registro, y estado de prueba de salida.

GDPR aplica cuando el problema implica datos personales. La toma de control de un subdominio no constituye automáticamente una brecha de seguridad de datos personales, pero puede convertirse en una si el subdominio afectado recopila credenciales, captura datos de formularios, suplanta un servicio, expone identificadores de usuario o permite acceso no autorizado a datos personales. GDPR Article 5 exige integridad, confidencialidad y responsabilidad proactiva. Article 32 exige una seguridad adecuada del tratamiento. Article 33 puede exigir notificación a la autoridad de control si es probable que una brecha de seguridad de datos personales entrañe un riesgo para los derechos y libertades de las personas físicas.

La PII Incident and Breach Management Policy de Clarysec PII Incident and Breach Management Policy, Clasificación y evaluación de brechas, cláusula 4.2.6, respalda este análisis de activadores multirrégimen:

[Condicional] El responsable de privacidad / responsable del PIMS DEBE evaluar los activadores de notificación aplicables legales, sectoriales, del sector financiero, de ciberseguridad, contractuales, de clientes y de destinatarios del servicio para cada incidente de PII de alto impacto, y registrar el resultado de aplicabilidad en REG01, REG08 y REG10.

Ese registro de decisión es exactamente lo que se necesita cuando una toma de control de subdominio podría implicar GDPR, NIS2, DORA, contratos y notificación a clientes.

Cómo probarán los auditores sus evidencias

Un SGSI integrado debe permitir responder a distintos auditores con la misma base de evidencias. La redacción de la pregunta cambia, pero la prueba suele ser la misma.

Una perspectiva de aseguramiento más amplia suele incluir NIST CSF 2.0 y COBIT 2019. NIST CSF 2.0 ayuda a expresar el estado objetivo mediante resultados de GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND y RECOVER. Un Perfil Actual podría mostrar revisiones DNS manuales trimestrales y bajas SaaS inconsistentes. Un Perfil Objetivo podría exigir comprobaciones automáticas semanales de toma de control, asignación obligatoria de propietario, evidencias de salida de proveedores e integración con la gestión de cambios.

Un auditor orientado a COBIT 2019 o ISACA normalmente preguntará quién es propietario del proceso, cómo se evalúa y dirige el riesgo, si los cambios se controlan, si los proveedores se gestionan, si la configuración y los activos son fiables, y si las evidencias de aseguramiento respaldan los informes a la dirección. Puede que no pida primero una lista de CNAME. Puede preguntar cómo sabe la dirección que los servicios digitales externos están controlados durante todo su ciclo de vida.

Cómo son unas buenas evidencias de auditoría

Un paquete de auditoría sobre registros DNS huérfanos debe ser lo suficientemente reducido para mantenerse, pero lo bastante completo para defenderse. Clarysec suele recomendar el siguiente conjunto de evidencias:

• Inventario de zonas DNS con fuente, fecha, tipo de registro, destino y propietario.
• Resultados de escaneo de la superficie de ataque externa que muestren comprobaciones de toma de control.
• Entradas del Registro de Activos para dominios, subdominios, servicios en la nube, aplicaciones SaaS y CDN.
• Registro de servicios que muestre la responsabilidad interna o del proveedor.
• Tickets de cambio para la creación, modificación y eliminación de registros DNS.
• Listas de verificación de incorporación de nube y SaaS que incluyan revisión de dominios personalizados y DNS.
• Contratos de proveedores o cláusulas de seguridad que cubran DNS, alojamiento, soporte ante incidentes y salida.
• Tickets de vulnerabilidad con severidad, propietario, fecha de remediación y evidencias de nuevas pruebas.
• Evaluación de PII cuando el subdominio trata o trató anteriormente datos personales.
• Registros de clasificación de incidentes para tomas de control sospechadas o confirmadas.
• Lecciones aprendidas y procedimientos actualizados tras los hallazgos.

Las métricas también importan. La dirección debe ver el número de subdominios externos, el porcentaje con propietarios asignados, el número de hallazgos de DNS huérfanos, el tiempo medio de remediación, los hallazgos de alto riesgo vencidos, los subdominios alojados por proveedores sin referencia contractual vigente y el porcentaje de salidas de nube con evidencias de eliminación de DNS.

Estas métricas convierten la higiene técnica en evidencias de supervisión por la dirección.

Patrones de fallo comunes que encuentra Clarysec

En clientes de SaaS, fintech, tecnología sanitaria, servicios gestionados y comercio electrónico, se repiten los mismos patrones.

Primero, la propiedad de DNS está dividida entre equipos. Ingeniería es responsable de la nube. Marketing es responsable de las campañas. TI controla el acceso al proveedor DNS. Compras gestiona la terminación de SaaS. Nadie es responsable del ciclo de vida completo.

Segundo, la eliminación en la nube se trata como el fin del servicio. En realidad, pueden permanecer DNS, certificados, reglas WAF, supervisión, secretos, documentación y registros de proveedores.

Tercero, los escáneres de vulnerabilidades se centran en hosts activos pero pasan por alto condiciones de toma de control específicas del proveedor. Las organizaciones necesitan comprobaciones de superficie de ataque externa que entiendan estados de error habituales de SaaS y nube.

Cuarto, los procedimientos de salida de proveedores se centran en facturas y devolución de datos, pero no en dominios personalizados, registros DNS y cambios de subencargados del tratamiento.

Quinto, los equipos de privacidad reciben la notificación demasiado tarde. Si un subdominio trató PII, el DPO o el responsable de privacidad debe participar en la clasificación antes de formular supuestos.

Sexto, existen evidencias, pero están dispersas. La exportación DNS está en una herramienta, los tickets de cambio en otra, los contratos de proveedores en Compras, los informes de vulnerabilidades en escáneres y el análisis de privacidad en correo electrónico. Los auditores ven la fragmentación como una debilidad.

El toolkit de Clarysec resuelve esto conectando políticas, registros, controles y flujos de trabajo de evidencias.

Un plan de acción de 30 días para la gobernanza de DNS

Si ha encontrado un registro DNS huérfano, asuma que hay más. Si no ha encontrado ninguno, asegúrese de poder demostrar por qué.

Empiece con este plan de 30 días:

1. Exporte todas las zonas DNS autoritativas.
2. Identifique registros CNAME, ALIAS, A y AAAA que apunten a servicios de nube, SaaS, CDN y servicios gestionados por agencias.
3. Asigne propietarios y finalidades de negocio.
4. Ejecute comprobaciones de toma de control y valide manualmente los registros sospechosos.
5. Cree tickets de vulnerabilidad para los riesgos confirmados.
6. Elimine o reclame los registros expuestos mediante gestión de cambios.
7. Actualice el Registro de Activos, el registro de nube y el registro de proveedores.
8. Revise si algún subdominio afectado trató PII.
9. Añada comprobaciones del ciclo de vida de DNS a la incorporación de nube, la contratación de SaaS y la salida de proveedores.
10. Informe de las métricas a la dirección.

La corrección técnica de los registros DNS huérfanos suele ser sencilla. La corrección de gobernanza es lo que evita la siguiente toma de control.

Clarysec puede ayudarle a operacionalizarlo mediante Zenith Blueprint Zenith Blueprint, Zenith Controls Zenith Controls y nuestro toolkit de políticas para gestión de activos, uso de la nube, gestión de vulnerabilidades, gobernanza de proveedores, seguridad de PII, respuesta a incidentes y evidencias de auditoría.

Si desea un enfoque preparado para auditorías, Clarysec puede ayudarle a crear el paquete de evidencias de exposición DNS y en la nube, mapearlo con ISO/IEC 27001:2022, NIS2, DORA y GDPR, y convertir subdominios olvidados en activos controlados, con propietario y supervisados. Descargue el toolkit de Clarysec correspondiente, solicite una demostración o programe una evaluación de gobernanza de DNS antes de que un pentester, auditor o atacante encuentre el siguiente puntero olvidado.