Cómo construir evidencia de auditoría: una guía para equipos empresariales

La brecha de evidencia de auditoría: por qué la configuración por sí sola no basta

La mayoría de los programas de autenticación de correo electrónico alcanzan un estado funcional y se detienen ahí. Se publican los registros SPF. Las claves DKIM se rotan cuando alguien se acuerda. Se configura una política DMARC en p=quarantine o p=reject. El equipo sigue adelante.

El problema sale a la luz en el momento de la auditoría. Un auditor que revise los controles de seguridad del correo electrónico puede solicitar:

• Un inventario actualizado de todos los dominios y su postura de autenticación
• Evidencia de que las políticas se aplican, no solo se declaran
• Registros que muestren actividad de supervisión continua
• Evidencia de que los remitentes no autorizados se detectan y se actúa en consecuencia

Nada de esto existe automáticamente. Requiere una recopilación y un mantenimiento deliberados. Una empresa puede tener una configuración de autenticación técnicamente sólida y aun así fallar una auditoría –simplemente porque no cuenta con evidencia.

Esta es la brecha de evidencia de auditoría. Cerrarla es un problema operativo y de gobernanza, no técnico.

Qué aspecto tiene realmente la evidencia de auditoría

Antes de construir un flujo de trabajo de recopilación de evidencia de auditoría, define qué debe contener cada uno de estos elementos.

Inventario de configuración

Un inventario de configuración es la base de la evidencia de auditoría. Documenta el estado de autenticación actual de cada dominio desde el que la empresa envía correo electrónico.

A efectos de auditoría, esto debe incluir:

• Nombre de dominio
• Registro SPF (valor actual, fecha de última modificación, remitentes autorizados)
• Selectores DKIM en uso (por dominio, por sistema de envío)
• Política DMARC (valor p=, direcciones rua= y ruf=)
• Propietario de la política (departamento o equipo)
• Fecha de última revisión

Este inventario de dominios debe estar versionado. Una instantánea de hoy tiene un valor de auditoría limitado a menos que demuestre una postura constante a lo largo del tiempo.

Documentación de cambios de política

Todo cambio en un registro SPF, una clave DKIM o una política DMARC debe documentarse: qué cambió, cuándo, quién lo autorizó y por qué. Esto importa especialmente al pasar de p=none a p=quarantine y a p=reject. La progresión de la aplicación debe ser deliberada y por etapas, y cada paso debe producir una aprobación documentada.

Registros de supervisión

Los reportes agregados de DMARC muestran, por período de informe, qué fuentes enviaron mensajes que afirman proceder de su dominio y si esas fuentes superaron o no la alineación de SPF y DKIM. Estos reportes contienen datos estructurados sobre cada fuente de envío, no solo sobre los fallos.

Para la evidencia de auditoría, los equipos necesitan:

• Reportes agregados archivados durante un período de revisión definido
• Un registro de cómo se revisaron los informes, quién lo hizo y qué acciones resultaron de ello
• Rutas de escalado documentadas para los fallos de autenticación por encima de un umbral definido

Un informe agregado de DMARC sin leer en una bandeja de entrada no constituye supervisión. Los auditores suelen preguntar si se actuó sobre los reportes, no simplemente si se recibieron.

Escenarios multiempresa y de dominios delegados

Las organizaciones empresariales rara vez operan un único dominio. Las filiales, las empresas adquiridas y las marcas regionales tienen cada una su propia cartera de dominios. En los modelos delegados, cada división puede gestionar su autenticación de forma independiente.

Esto genera dos problemas de evidencia de auditoría.

1. Fragmentación de la visibilidad. Cuando cada dominio se gestiona por separado, ninguna vista única refleja la postura de autenticación de la empresa. Una solicitud sobre el estado de autenticación de correo en todos los dominios no puede responderse con un solo informe.
2. Ambigüedad de propiedad. Cuando un dominio está autenticado pero no hay un equipo designado como responsable de mantenerlo, existe una laguna de gobernanza. Los auditores tratan la propiedad no documentada como un fallo de control, incluso cuando la configuración técnica es sólida.

En entornos multiempresa, el requisito de evidencia se extiende a demostrar que todos los dominios dentro del alcance, incluidos los adquiridos recientemente y los que están bajo gestión delegada, están cubiertos por un proceso de supervisión y revisión coherente. Mantener el cumplimiento de DMARC en todos los dominios requiere una vista centralizada. Las comprobaciones puntuales de dominios individuales no son suficientes.

Cómo construir el flujo de trabajo

Paso 1: inventario de dominios y línea base

Empieza con una lista completa de todos los dominios que posee la empresa, independientemente de si envían correo electrónico. Los dominios que no envían correo igualmente requieren un registro DMARC con una política p=reject para evitar la suplantación. Las lagunas en el inventario de dominios que no envían correo son hallazgos de auditoría.

En el caso de los dominios que envían correo, documenta el inventario completo de remitentes: cada plataforma de terceros, herramienta SaaS, sistema CRM y sistema de tickets que envía en nombre del dominio.

Paso 2: revisión y documentación de la política

Para cada dominio, documenta la política DMARC actual y su justificación. Un dominio en p=none debe tener un motivo documentado, como una remediación activa, un problema de reenvío conocido bajo investigación o un sistema heredado pendiente de retirarse. Las políticas p=none no documentadas se interpretan como inacción por parte de un auditor y se tratan como hallazgos de auditoría.

Paso 3: cadencia de supervisión y revisiones

Establece una cadencia de supervisión formal: quién revisa los reportes agregados, con qué frecuencia y qué abarca la revisión. Una cadencia mensual es práctica para la mayoría de los entornos empresariales. Los dominios de alto riesgo justifican una revisión semanal.

Cada ciclo de revisión debe generar un resultado documentado: un breve registro de lo que se revisó, si aparecieron remitentes nuevos o no autorizados y qué acción, si la hubo, se tomó. No es necesario que sea elaborado.

Paso 4: comprobaciones de verificación entre dominios

Programa verificaciones periódicas en todo el inventario de dominios para confirmar que los registros DNS coinciden con la configuración documentada. Los registros se desactualizan. Se añaden remitentes sin actualizar SPF. Las claves DKIM se rotan, pero los selectores antiguos se dejan activos. La brecha entre lo documentado y lo realmente publicado en el DNS son hallazgos de auditoría.

Paso 5: documentación para partes interesadas no técnicas

El trabajo del equipo de cumplimiento no consiste solo en recopilar evidencia de auditoría, sino en traducirla en documentación que una junta directiva, un comité de auditoría o un regulador externo puedan revisar.

Esto significa:

1. Un informe resumido de la postura de autenticación que cubra toda la cartera de dominios
2. Una ruta de escalado documentada para los fallos de autenticación

Cómo puede ayudarte Sendmarc

Mantener evidencia de auditoría en decenas o cientos de dominios consume un tiempo del que los equipos de seguridad y TI, ya de por sí sobrecargados, no disponen.

Sendmarc ofrece una vista centralizada de la postura de autenticación en toda la cartera de dominios, actualizada de forma continua. Los resultados de SPF, el estado de DKIM y el nivel de aplicación de DMARC son visibles en una sola interfaz.

Para los equipos de cumplimiento y TI que están mapeando la postura de autenticación actual antes de un ciclo de auditoría, empieza por el inventario de dominios. Usa la Plataforma de Sendmarc para ver en qué punto se encuentra hoy tu cartera de dominios.