DMARC como prueba de auditoría ISO 27001: el control que los auditores adoran

DKIM, claves criptográficas y la gestión de secretos

DKIM, uno de los dos pilares de alineación de DMARC, se basa en un par de claves criptográficas. La clave privada firma el correo; la clave pública, publicada en DNS, permite a los destinatarios verificar la firma. Esa clave privada es un secreto de primer orden: si se filtra, un atacante puede firmar mensajes en nombre de la organización y franquear sus defensas DMARC haciéndose pasar por ella.

ISO 27001 aborda explícitamente el uso de la criptografía y la gestión de claves entre sus controles tecnológicos. En concreto, un auditor espera que las claves se generen robustas (véase DKIM 1024 o 2048 bits para el dimensionamiento correcto), que se almacenen bajo un control de acceso estricto —y sobre todo no en un archivo de configuración versionado, un ticket o un canal de chat— y que se roten con regularidad. Un gestor de secretos dedicado como Hucency Vault, desarrollado por el especialista en ciberseguridad Hucency, responde precisamente a esta exigencia: centralizar las claves DKIM privadas y los tokens de API bajo acceso controlado y registrado, en lugar de dejarlas dispersarse por la organización. La rotación periódica de esas claves, por su parte, es un control por derecho propio; su implementación se detalla en la rotación de claves DKIM.

Este punto se descuida a menudo porque DKIM «funciona» incluso con una clave mal gestionada. Pero desde el punto de vista de la auditoría, una clave de firma almacenada de cualquier manera es una desviación: convierte el mejor control anti-suplantación en un punto único de fallo.

La prueba, no la promesa

Aquí es donde DMARC brilla en un contexto de certificación. A diferencia de muchos controles internos cuya prueba exige rebuscar en registros o interrogar a los equipos, la postura DMARC es pública y fechable. Un auditor —o cualquiera— lee el registro en unos segundos y comprueba directamente si está en p=none, p=quarantine o p=reject. Ninguna captura de pantalla discutible, ninguna declaración jurada: el dato hace fe.

A esto se suman los informes RUA archivados, que constituyen registros en el sentido de la norma: documentan, mes tras mes, quién emite en nombre del dominio y cómo evoluciona su postura. Conservados con orden, prueban no solo que el control existe, sino que está supervisado, la distinción exacta entre un control vivo y una casilla marcada y olvidada.

De none a reject: lo que el auditor quiere ver de verdad

Un auditor experimentado no se deja engañar por un p=none. Sabe que un dominio en observación únicamente no protege nada: documenta la suplantación sin bloquearla. La prueba que se sostiene es distinta: un dominio en p=reject, un histórico de informes que muestre la subida progresiva, un procedimiento documentado que describa el paso de la observación a la aplicación, y una revisión periódica inscrita en el SGSI. La secuencia operativa completa se describe en llegar a p=reject sin romper el correo; del lado de la auditoría, es ese histórico lo que transforma «tenemos DMARC» en una constatación defendible.

El mismo razonamiento estructura la protección de las marcas más atacadas, desarrollado en DMARC para bancos: lo que cuenta es la aplicación de la política, no la simple publicación.

Una prueba reutilizable para toda la conformidad

La ventaja estratégica de hacer bien este trabajo una vez: la traza de auditoría se reutiliza. El mismo expediente —postura p=reject, informes archivados, procedimiento de subida, gestión de claves— sirve directamente para demostrar la diligencia bajo NIS2 y para responder a la vertiente de seguridad de la autenticación del correo vista por el RGPD. No se construyen tres expedientes separados; se construye un control sólido y se presenta bajo tres ángulos normativos.

Construir el expediente de prueba, paso a paso

Una auditoría ISO 27001 se gana tanto por la calidad del expediente como por la realidad del control. Para la autenticación del correo, un expediente convincente reúne unas cuantas piezas sencillas, todas ellas preparables por adelantado:

• La entrada en la declaración de aplicabilidad que justifica los controles seleccionados en concepto de protección anti-suplantación.
• La línea correspondiente del registro de riesgos, donde la «suplantación del dominio de mensajería» está nombrada, evaluada y vinculada a DMARC como tratamiento.
• La prueba de postura: el registro DMARC actual, con marca de tiempo, mostrando p=reject; basta una simple captura fechada, ya que el dato es público y reproducible a voluntad.
• El archivo de los informes RUA, que materializa la supervisión continua y la evolución de la postura a lo largo del tiempo.
• El procedimiento de gestión de las claves DKIM: dónde se almacenan las claves privadas, quién accede a ellas, con qué frecuencia se rotan, junto con el registro de las rotaciones.
• La cadencia de revisión inscrita en el SGSI: quién verifica la postura, con qué periodicidad y qué desencadena una acción correctiva.

Montado una vez, este expediente se actualiza en unos minutos antes de cada revisión. Transforma una afirmación oral en prueba documental, la única moneda que cuenta de verdad en una auditoría.

Las desviaciones que hacen fruncir el ceño a un auditor

A la inversa, algunas configuraciones clásicas provocan de inmediato una observación, o incluso una no conformidad:

• Presentar p=none como un control implantado. Es la desviación más frecuente: la observación no es la protección, y un auditor avezado ve la diferencia de un vistazo.
• Una clave DKIM privada en un repositorio de código o un ticket. Un secreto criptográfico expuesto anula el beneficio del control y constituye una desviación caracterizada de gestión de claves.
• Ninguna rotación ni ningún registro de rotación. Una clave que no ha rotado en años es un punto de fallo latente.
• Informes que nunca se conservan. Sin archivo, es imposible demostrar la supervisión: quizá el control exista, pero no hay forma de probarlo.
• Solo el dominio corporativo cubierto. Si el dominio de cara al público —el que ven realmente clientes y usuarios— sigue en p=none, la protección exhibida es engañosa.

Ninguna de estas desviaciones es difícil de corregir; casi siempre provienen de un control instalado y luego olvidado, por falta de un responsable claro. Designar a un responsable de la postura de autenticación, aunque sea a tiempo parcial, y darle un panel actualizado suele bastar para hacerlas desaparecer de golpe, y para transformar la auditoría del correo de un motivo de inquietud en un mero trámite.

La postura, comprobada antes que el auditor

El primer paso es gratuito e inmediato. Basta con pasar el dominio por nuestro analizador DMARC gratuito para obtener un veredicto instantáneo sobre la política actual, y luego situar esa postura en el Observatorio DMARC para compararla con la del sector.

Constituir y mantener un expediente de auditoría limpio —postura por dominio, fuentes de envío identificadas, histórico de preparación— es exactamente lo que Thomas, el CISO virtual, automatiza: nombra cada fuente, genera el DNS que hay que publicar, evalúa la preparación por dominio y documenta el camino hacia la aplicación de la política. Analizar un dominio gratis · explorar el Observatorio · empezar con Thomas.