Una simulación de phishing se envió a diez mil personas. El informe cerró con nueve mil quinientas aperturas y nueve mil clics. Un 95% de apertura y un 90% de clic no son cifras que produzca un grupo de personas.
Ese resultado apareció más de una vez en los primeros años de SMARTFENSE, cuando las simulaciones se lanzaban sin preparar el entorno. Lo que mostraba era una herramienta de email security que abría y visitaba los correos antes de que llegaran al destinatario. Ese informe medía las defensas de correo de la organización.
Cuando un resultado no cierra, la conversación llega a mi equipo. Y la primera pregunta que hacemos apunta a la entrega de simulaciones de phishing en esa organización antes que a las personas, por dónde entró el correo, quién lo tocó antes del buzón y qué pudo cargar el cliente de correo cuando el colaborador lo abrió. La explicación casi siempre está ahí.
¿Qué mide en realidad una simulación de phishing?
Cada métrica de una simulación es una medición conjunta de dos cosas, la decisión de la persona y el estado del entorno por el que pasó el correo. Poder separar las dos es la condición para interpretar el resultado.
Un 4% de clic puede significar que la organización aprendió a desconfiar. También puede significar que la mitad de los correos nunca llegó a destino. Los dos escenarios producen el mismo número y piden decisiones opuestas.
Conviene aclarar qué se está poniendo a prueba. Las herramientas de email security tienen su propia evaluación y un equipo propio que las vigila. La simulación existe para medir la capa que queda cuando esas herramientas no alcanzan, que es la persona frente al mensaje. Si las barreras frenan la trampa, el ejercicio deja de informar sobre lo que fue a buscar, y ahí vale recordar que una campaña se diseña para cambiar comportamiento y no para auditar la seguridad del correo.
¿Por qué la simulación no llega al buzón?
Entre la plataforma y el buzón del colaborador hay varias capas de control, y cualquiera de ellas puede detener el mensaje. Prepararlas es lo que se conoce como lista blanca, y tiene un detalle del que casi nadie se acuerda: se divide en dos mitades.
La primera mitad es la entrega del correo, que se resuelve declarando las direcciones IP y los dominios de envío en las herramientas que analizan el correo entrante. La segunda es la navegación, porque el colaborador que hace clic termina en un sitio de phishing simulado que también puede estar bloqueado. Esa mitad exige habilitar los dominios de navegación en el navegador, en sus extensiones y en las herramientas de ciberseguridad del puesto de trabajo. Una campaña con la primera mitad resuelta y la segunda pendiente entrega los correos y pierde todos los clics.
Hay tres formas de declararlo, por dirección IP, por dominio y por encabezado del mensaje. La tercera aparece cuando existe una herramienta de seguridad delante del servidor de correo que reescribe la IP de origen. En ese escenario declarar nuestras direcciones no alcanza, porque la que llega al servidor ya es otra, y el correo se identifica por su encabezado.
El listado vigente de IP y dominios vive dentro de la plataforma, en Configuración › Seguridad › Whitelist, y también está en los requisitos mínimos publicados. Conviene consultarlo el día de la campaña y no el del arranque del proyecto, porque cambia cuando cambian los servidores de envío.
¿La inyección directa reemplaza a la lista blanca?
Direct Message Injection es un método alternativo de entrega. En lugar de viajar por SMTP y atravesar todas las capas, el mensaje se inserta de forma directa en la bandeja de entrada mediante una conexión por API con el proveedor de correo, disponible para organizaciones que trabajan con Microsoft o con Google.
Resuelve tres cosas. La primera es la entrega, al punto de que en algunos casos elimina la necesidad de la lista blanca de correo. La segunda son las advertencias que algunos clientes agregan de forma automática sobre el mensaje y que le avisan al colaborador antes de que tenga oportunidad de decidir. La tercera es la fragilidad de la configuración, porque la actualización de una herramienta de seguridad puede invalidar una lista blanca que venía funcionando.
Lo que no resuelve es la segunda mitad. El sitio de phishing simulado sigue del otro lado de las herramientas de navegación, y el filtrado posterior a la entrega puede mover el mensaje una vez depositado. Es la conclusión a la que ya llegaba la pieza que presentó DMI en este blog, y sigue en pie. La inyección directa reduce la superficie de configuración sin hacerla desaparecer.
¿Por qué la apertura es la métrica más frágil?
La plataforma cuenta una apertura cuando el cliente de correo del destinatario muestra el mensaje y carga un píxel transparente que lleva una referencia única a esa persona. De ese píxel dependen las estadísticas de apertura en campañas de newsletters, phishing, ransomware y momentos educativos.
En una implementación nueva el síntoma aparece siempre igual. Los correos llegan bien a la bandeja de entrada, los colaboradores los abren, y la estadística de abierto no se registra. La causa está en el cliente de correo, que no tiene permitido mostrar imágenes, y como el píxel es una imagen nunca se carga. Nuestra propia guía de requisitos mínimos lo dice sin vueltas, si el cliente bloquea imágenes las estadísticas de apertura serán inferiores a las reales.
El ajuste se hace a nivel de toda la organización, con la lista de remitentes seguros aplicada por política central o por línea de comandos, en lugar de pedirle a cada persona que habilite las imágenes en su cuenta.
El desvío también ocurre en la dirección contraria. Las protecciones de privacidad de correo cargan el contenido remoto por su cuenta. Apple documenta que, con esa protección activada, el contenido remoto se descarga en segundo plano al recibir el mensaje y no al abrirlo. El píxel se carga sin que nadie haya leído nada y la apertura queda contada igual.
Con las dos desviaciones en juego, la apertura solo alcanza para confirmar que la entrega funcionó. Las métricas que aguantan una decisión son las que exigen una acción deliberada de la persona, el clic en el enlace, el ingreso de datos en el sitio simulado y el reporte del mensaje. Son las que conviene llevar al tablero cuando se define qué está midiendo el programa.
¿Cuándo el número que sube no es una persona?
Un falso positivo es una estadística generada por un software y registrada a nombre de un usuario. Es lo que había detrás del caso del primer párrafo, y llega por tres vías, las herramientas corporativas que analizan el correo de la organización, las herramientas personales instaladas en los dispositivos que acceden a ese correo y otro software que interviene el mensaje, como extensiones del navegador o la previsualización de enlaces.
A cualquiera que administre el correo de una organización la lista de sospechosos le resulta familiar: filtros antispam, antivirus, DLP, gateways de seguridad, IDS/IPS, análisis continuo de enlaces y complementos de la bandeja de entrada. Ninguno está haciendo nada indebido. Están haciendo su trabajo sobre un correo que parece un ataque, porque fue construido para parecerlo.
La plataforma detecta y filtra estos casos con un algoritmo que destaca las campañas afectadas, informa el origen de las estadísticas generadas por software y permite ajustar sus parámetros a las herramientas de cada organización. Las interacciones detectadas quedan fuera de los resultados finales, así que las estadísticas y los registros de auditoría contienen solo lo que hicieron personas. El origen y las soluciones de los falsos positivos están desarrollados en este blog.
El punto importa aguas abajo. Ese mismo dato alimenta el puntaje de riesgo por persona. Un falso positivo sin filtrar no se queda en el informe mensual. Mueve el puntaje de alguien que no hizo nada, y ese puntaje después decide quién recibe formación adicional.
¿Qué revisar antes de la primera campaña?
Son seis puntos, en el orden en que conviene resolverlos.
- Entrega declarada en las herramientas que analizan el correo entrante, por dirección IP, por dominio o por encabezado según lo que haya delante del servidor de correo.
- Navegación habilitada para los dominios de la plataforma en el navegador, en sus extensiones y en las herramientas de seguridad del puesto de trabajo.
- Listado vigente consultado en Configuración › Seguridad › Whitelist el día de la campaña, no el del arranque del proyecto.
- Imágenes visibles en el cliente de correo, aplicado por política central a toda la organización en lugar de usuario por usuario.
- Detección de falsos positivos activa, con sus parámetros ajustados a las herramientas que la organización tiene instaladas.
- Una campaña piloto a un grupo reducido antes de la primera medición general, revisando los correos entregados, las aperturas y los clics en busca de coincidencias sospechosas.
La revisión no se hace una sola vez. Cada actualización del stack de seguridad puede invalidar una configuración que venía andando, y el mejor momento para descubrirlo es un piloto de cincuenta personas, no la campaña cuyos resultados van al comité.
Preguntas frecuentes
¿Por qué las simulaciones de phishing no llegan al buzón?
Porque entre la plataforma que las envía y el buzón del colaborador hay varias capas de control que analizan el correo entrante y pueden detener el mensaje. Preparar esas capas requiere declarar las direcciones IP y los dominios de envío, y hacerlo por dirección IP, por dominio o por encabezado del mensaje según qué herramienta haya delante del servidor de correo.
¿Hace falta configurar lista blanca si uso inyección directa de mensajes?
Sí, aunque menos. La inyección directa resuelve la entrega del correo, y en algunos casos elimina la necesidad de la lista blanca para esa mitad. La navegación hacia el sitio de phishing simulado sigue necesitando que los dominios estén habilitados en el navegador, en sus extensiones y en las herramientas de seguridad del puesto de trabajo.
¿Por qué no se registra la apertura si el colaborador abrió el correo?
Porque la apertura se cuenta cuando el cliente de correo carga un píxel transparente, y el píxel es una imagen. Si el cliente no muestra imágenes, el correo se lee pero la apertura no queda registrada. Se corrige habilitando la visualización de imágenes por política central en toda la organización.
¿Qué es un falso positivo en una simulación de phishing?
Es una estadística generada por un software y registrada a nombre de un usuario. La producen herramientas corporativas que analizan el correo, herramientas personales instaladas en los dispositivos que acceden a ese correo y otro software que interviene el mensaje, como extensiones del navegador o la previsualización de enlaces.
¿Qué métricas de una simulación sirven para tomar decisiones?
Las que exigen una acción deliberada de la persona, el clic en el enlace, el ingreso de datos en el sitio simulado y el reporte del mensaje. La apertura solo alcanza para confirmar que la entrega funcionó.
Si estás por lanzar la primera campaña, los requisitos mínimos están publicados y el listado vigente de IP y dominios vive dentro de la plataforma. Media hora de revisión antes del envío evita la conversación incómoda sobre si el número del informe se puede creer.
Deja una respuesta