Zero Trust contra ingeniería social con IA: orden de capas

El modelo Zero Trust suele explicarse en términos de redes. Frente a la ingeniería social asistida por IA, la red resulta irrelevante: nadie está vulnerando un perímetro técnico, sino pidiéndole algo a una persona. La superficie de ataque son la identidad y los procesos, y el principio sigue vigente: verificar de forma explícita y asumir el compromiso.

Lo importante es el orden. Existen tres capas, y la secuencia en la que se aplican es la decisión de diseño fundamental.

El problema

Un administrativo de cuentas a pagar recibe un mensaje de un proveedor con el que lleva años trabajando. La redacción coincide con su estilo habitual y cita correctamente el número de la última factura. Explica un cambio de cuenta bancaria con un motivo creíble y un plazo moderado. No contiene enlaces ni archivos adjuntos.

Todo lo que una persona podría revisar razonablemente parece correcto. La anomalía es la petición en sí misma, ya que el mensaje es impecable. Y a la pregunta de si la petición parece legítima, un empleado bajo presión de tiempo responderá que sí, porque realmente lo parece.

La organización contaba con análisis de correo asistido por IA. El sistema calificó el mensaje con riesgo bajo porque, según cualquier propiedad medible, lo era.

Por qué cambia con la IA

Las tres capas que se detallan a continuación no son nuevas, pero su fiabilidad relativa ha cambiado.

La detección basada en analizar el contenido de un mensaje solía ser una primera línea de defensa razonable, porque el texto del atacante presentaba indicios reconocibles: giros lingüísticos extraños, estructuras de plantilla o infraestructura reutilizada. Esos rastros eran la consecuencia de operar a gran escala, y hoy han desaparecido.

Esa degradación resulta invisible. Un control que bloquea el 95% de lo que detecta no avisa cuando el 5% restante se convierte en la parte decisiva. Los controles deterministas no tienen ese inconveniente: una credencial FIDO completa el inicio de sesión o lo rechaza, y una llamada de confirmación a un número de tus registros comunica con el proveedor real o no lo hace.

Por eso, el orden establecido refleja en qué controles puedes seguir confiando a medida que el atacante perfecciona sus tácticas.

Las tres capas, en orden

Capa 1: verificar la identidad (determinista)

La autenticación resistente al phishing elimina las credenciales como objetivo viable. Las directrices de CISA son rotundas sobre qué cumple este requisito: FIDO/WebAuthn es la única autenticación resistente al phishing disponible de forma generalizada, porque el protocolo vincula la credencial al sitio web legítimo y bloquea el intento cuando un usuario es engañado para introducir sus datos en otra parte [1].

Los códigos de un solo uso y las aprobaciones mediante notificación push suponen una mejora clara frente a usar solo contraseñas, pero no son resistentes al phishing. Un código puede interceptarse y retransmitirse mediante un proxy en tiempo real, y una notificación push puede terminar aprobándose por puro cansancio ante avisos repetidos. CISA destaca que adoptar FIDO erradica este tipo de evasiones, incluidos los bombardeos de notificaciones y la suplantación de contraseñas de un solo uso [1], y aconseja empezar por los colectivos donde un compromiso resulte más perjudicial, como el soporte técnico y los administradores de sistemas [1].

Capa 2: verificar la petición (determinista)

La autenticación protege las cuentas. Sin embargo, no evita que una persona legítima sea convencida para realizar una acción, ni detiene un mensaje enviado desde el buzón genuinamente comprometido de un proveedor.

El control consiste en un procedimiento fijo fuera de banda para una lista estricta de solicitudes: modificar datos bancarios, transferir fondos, cambiar contactos de recuperación o emitir credenciales. La verificación se realiza llamando a un número previamente registrado en tus sistemas, y la confirmación debe darla una persona distinta a quien solicita el cambio.

Dos propiedades garantizan su eficacia. Se activa por el tipo de petición y pasa por alto cómo esté redactado el mensaje, de modo que un correo excepcionalmente persuasivo recibe exactamente el mismo trato. Además, no admite excepciones por urgencia ni por rango jerárquico, que son precisamente las palancas que explota el atacante.

El coste operativo es real. Esta capa añade fricción a transacciones cotidianas, y esa fricción recae sobre personas que intentan sacar su trabajo adelante. Ese intercambio compensa únicamente porque la alternativa es pedirle a un ser humano que detecte algo que ya no se puede detectar leyendo. Mantén la lista de solicitudes sensibles muy acotada, para que la fricción se concentre donde está el dinero y en ningún otro sitio.

Esta capa cubre además una situación que la autenticación no puede mitigar: un proveedor cuyo buzón ha sido comprometido legítimamente. El mensaje es real, la cuenta es real, los registros de autenticación son correctos y, aun así, la solicitud es un fraude. Comprobar quién envió el correo no sirve en este escenario; únicamente sirve verificar la solicitud en sí.

Capa 3: asumir que las dos primeras fallaron (probabilística)

Aquí es donde la detección cobra sentido. Un modelo de aprendizaje automático puede sopesar factores que una regla fija no alcanza a ver: si la solicitud encaja con el historial de la relación comercial, si el estilo de redacción difiere del remitente o si el canal y el momento son coherentes. Todo ello se complementa con señales deterministas como la alineación de autenticación, la antigüedad del dominio y si existía correspondencia previa.

Despliégala primero donde un error resulte inocuo. La clasificación del correo reportado por los usuarios no genera perjuicio en caso de fallo, y las acciones posteriores a la entrega pueden revertirse. El bloqueo en línea directo debe dejarse para el final y solo tras medir falsos positivos con tráfico real, ya que el coste de un falso positivo aquí es un pedido perdido y un compañero de trabajo que deja de confiar en la herramienta.

Lo que realmente funciona

Más allá de la secuencia de capas, ciertas prácticas marcan la diferencia.

Haz que la norma sea más breve que la lista de excepciones: una sola página que defina con claridad los tipos de solicitud y el canal de verificación obligatorio. Si requiere un diagrama de flujo, se ignorará bajo momentos de estrés.

Ofrece a los empleados una vía para pausar la operativa que no dependa de su criterio personal. Decir «nuestro protocolo exige una llamada de verificación» resulta mucho más fácil que decir «no confío en ti», y funciona con la misma eficacia ante un proveedor real que ante un atacante.

Monitoriza el proceso en lugar del buzón de entrada. Registra el tiempo transcurrido entre la petición y el pago, cuántos cambios de cuenta bancaria se produjeron en el trimestre y cuántos se comprobaron debidamente. Esos datos reflejan la ruta real que sigue el dinero y, a diferencia del porcentaje de clics en campañas de simulación, no miden simplemente lo bien que el personal reconoce un simulacro.

Ensaya la llamada de confirmación al menos una vez. La mayoría de las organizaciones descubren en pleno incidente que el teléfono de contacto de su contraparte está desactualizado o que nadie sabe en qué base de datos figura el registro oficial. Descubrir esa carencia en una tarde tranquila solo cuesta una hora.

Incentiva y premia los reportes internos, incluso cuando terminen en falsa alarma. Al haber desaparecido los indicios evidentes, la intuición y la inquietud son señales legítimas y a menudo las primeras en manifestarse.

Lo que no funciona

Contratar únicamente un software de detección y dar el trabajo por concluido te deja exclusivamente con la capa 3, que es justo la que falla sin dejar rastro visible.

Las notificaciones push como método único de MFA superan a las contraseñas simples, pero no resisten el phishing; su punto de fallo habitual es una persona agotada pulsando aceptar sin pensar.

Las excepciones para la alta dirección abren una brecha documentada. Un directivo al que no se le puede aplicar la llamada de comprobación es precisamente el nombre que el atacante utilizará para firmar.

Verificar datos utilizando la información de contacto incluida en el propio mensaje (como la firma, el membrete o el teléfono que figura en un PDF adjunto) es el fallo más común que echa por tierra un buen procedimiento.

Dejar fuera de alcance el buzón comprometido de un proveedor ignora el escenario exacto para el que existe la capa 2: una cuenta genuina enviando una petición aparentemente impecable. Si tu procedimiento asume que el remitente es de tu equipo o es un impostor evidente, deja un vacío peligroso en medio.

Por dónde empezar

• Incorpora primero a FIDO a los grupos con mayores privilegios, siguiendo las directrices por fases de CISA [1]: administradores, personal de soporte y cualquier persona con capacidad para autorizar pagos.
• Redacta la norma de verificación fuera de banda en una sola página, detallando las operaciones sujetas a comprobación.
• Audita las modificaciones de datos bancarios del último trimestre y comprueba cuántas se verificaron llamando a un teléfono de tus propios registros. Esa cifra representa tu cobertura real.
• Elimina formalmente por escrito las excepciones basadas en la urgencia y comunícalo a la plantilla para que puedan respaldarse en esa directriz.
• Solo entonces aborda la detección basada en IA, aplicándola primero sobre los correos reportados antes de bloquear tráfico de forma automática.

La conclusión que debemos asumir es que los controles más eficaces frente a la ingeniería social asistida por IA no guardan ninguna relación con la IA. Son un protocolo estricto de autenticación y una llamada telefónica; precisamente por eso siguen funcionando mientras la otra parte continúa mejorando.

Fuentes

1. Implementing Phishing-Resistant MFA, Cybersecurity and Infrastructure Security Agency: https://www.cisa.gov/sites/default/files/publications/fact-sheet-implementing-phishing-resistant-mfa-508c.pdf
2. More than a Password, CISA: https://www.cisa.gov/MFA