ITDR junto a SIEM y EDR: Arquitectura de Detección 2026

9 min de lectura ·

La detección de identidad es en 2026 la tercera capa en el SOC que ya no se puede posponer. EDR ve el endpoint, SIEM ve el log, ITDR ve el contexto de identidad entre ambos. Quien omite esta capa solo detecta robo de tokens, abuso de OAuth y escalación de privilegios cuando el daño ya llega al SIEM. Gartner afirma que en 2026 el 90 % de las organizaciones empresariales implementarán funciones de ITDR integradas. La pregunta no es si, sino si como capa independiente o como módulo dentro de EDR.

RelacionadoIdentity-Sprawl en pymes  /  MFA adaptativa como estándar NIS2

Qué es ITDR y por qué SIEM y EDR no lo sustituyen

¿Qué es la detección y respuesta de amenazas de identidad? Una capa de detección que identifica patrones de ataque específicos de identidad y responde de forma automatizada. Supervisa eventos de autenticación, cambios de privilegios, uso de tokens OAuth, comportamiento de cuentas de servicio y movimientos entre tenants. Su base de análisis son los logs de proveedores de identidad (Entra ID, Okta, Active Directory), no la telemetría de endpoint ni flujos de red.

La diferencia con EDR y SIEM radica en el contexto, no en el flujo de datos. EDR ve lo que ocurre en el endpoint. SIEM recopila los logs que llegan. ITDR añade la lente de identidad: ¿Qué cuenta usó qué token en qué configuración de tenant? ¿Fue el inicio de sesión riesgoso? ¿Se intentó una escalación de privilegios? ¿Existen consentimientos de OAuth a aplicaciones sospechosas? EDR y SIEM responden a estas preguntas solo indirectamente, a menudo horas después, o nunca.

En 2025, Expel constató en su informe SOC que el 68,6 % del volumen de amenazas observado tenía base en identidad. Okta reportó para el mismo año más de 15.000 millones de intentos de inicio de sesión maliciosos bloqueados en más de 10.000 organizaciones. Estas no son cifras de marketing de proveedores, sino realidad operativa: quien planea detección de seguridad en 2026 sin una capa de identidad, está ignorando el patrón real de ataque.

Concretamente: un atacante que, mediante phishing, roba una cookie de sesión y se autentica como usuario legítimo en Microsoft 365, no deja rastro sospechoso en el endpoint. EDR ve solo una pestaña normal del navegador. En SIEM aparece un inicio de sesión marcado como válido por el motor de MFA. Solo la capa de ITDR detecta que el inicio de sesión proviene de una ubicación geográfica inusual, que la duración del token es anormalmente larga, y que el usuario aceptó inmediatamente un consentimiento de OAuth para una aplicación desconocida. Esta cadena de señales de identidad es la fortaleza de ITDR.

En la práctica, esto también explica por qué la MFA clásica ya no basta en 2026. El robo de tokens, el atacante en el medio y el secuestro de sesión funcionan incluso con MFA activada. La MFA adaptativa y la autenticación basada en riesgo ayudan en la puerta frontal; ITDR complementa en la puerta trasera: ¿qué ocurre tras el inicio de sesión, cuando ya existe la sesión, cuando el token ya fue robado? Ambas capas juntas forman una defensa de identidad moderna.

Tres opciones de arquitectura para 2026

En el mercado se han consolidado tres patrones de arquitectura. Cada uno tiene sus fortalezas y también sus compromisos. La elección no depende de la preferencia del proveedor, sino de la madurez de la identidad, del stack EDR existente y de quién gestiona el SOC.

Las tres opciones no se excluyen entre sí, pero compiten por presupuesto y personal. Quien las implementa todas en paralelo tendrá tres veces el mismo evento de identidad en tres consolas. Quien no implementa ninguna verá el robo de tokens recién en el trabajo de correlación del SIEM a las dos de la madrugada. La respuesta correcta depende de dos variables: ¿cuántos proveedores de identidad están involucrados? ¿Quién tiene el stack principal de detección en casa?

Donde la decisión arquitectónica se toma en la práctica

En los tres análisis del último trimestre, los mismos argumentos han vuelto una y otra vez. El asegurador con Hybrid AD y Microsoft 365 ha optado por la versión integrada en EDR, porque ya utiliza CrowdStrike Falcon en su SOC y el módulo de identidad era el paso natural de expansión. El fabricante de maquinaria que cuenta con Entra ID y Okta de forma paralela ha creado su propia capa de ITDR, porque ninguno de los proveedores de EDR ofrece soporte profundo para ambos IDPs. El proveedor SaaS con configuración totalmente en la nube y 80 ingenieros ha elegido un paquete de protección nativo para IDP, porque el SOC es demasiado pequeño para un herramienta adicional.

Una observación importante: la elección depende menos del marketing de los proveedores y más de la propia higiene de la identidad. Quien no ha limpiado sus cuentas de servicio durante años, quien nunca ha auditado los consentimientos OAuth o quien no tiene una jerarquía clara de privilegios, enfrenta un problema de identidad que ningún herramienta puede resolver de inmediato. La secuencia correcta es: primero el inventario de identidades, luego la selección de herramientas. Quien invierte en el orden inverso se está comprando una herramienta para una realidad que aún no comprende.

La extensión de Microsoft Defender for Identity a las identidades de Okta en abril de 2026 resulta notable en este contexto. Cambia la manera de pensar para aquellos hogares que hasta ahora contaban con dos IDPs y necesitaban una capa de ITDR propia. Quienes ya tienen Defender for Identity en su stack de Microsoft pueden incluir ahora las identidades de Okta sin necesidad de licenciar una herramienta adicional. Esto permite ahorrar costos de licencia y reducir el número de consolas en el SOC.

Riesgo de deriva: Lo que el despliegue de ITDR no resuelve

Independientemente de la opción elegida, una verdad permanece: ITDR es detección, no un programa de higiene de identidad. Quien no sanea la arquitectura de identidad, quien no delimita claramente las jerarquías de privilegios y quien no audita las cuentas de servicio, obtendrá más alertas con ITDR y menos claridad. Las herramientas detectan anomalías, pero no reparan una arquitectura de identidad mal planificada.

En la prueba práctica realizada con el fabricante de maquinaria sucedió precisamente eso. Tras la implementación de ITDR, el número de alertas se disparó de 30 al día a 380. Tres semanas de triaje mostraron que la mayoría de las alertas no correspondían a ataques, sino a actividades cotidianas que la máquina de ITDR no reconocía: cuentas de servicio con privilegios excesivos, consentimientos OAuth con ámbitos demasiado amplios y accesos desde dispositivos obsoletos, como portátiles ya retirados. Reducir las alertas a 50 al día requirió dos meses de limpieza profunda de la identidad, no simplemente ajustar las configuraciones de la herramienta.

Otro punto práctico surgido de las revisiones: la responsabilidad por las alertas de ITDR suele estar poco clara desde el punto de vista organizativo. Los analistas del SOC están formados principalmente para gestionar eventos en endpoints, mientras que los especialistas en identidad suelen pertenecer al equipo de operaciones de TI. Cuando llega una alerta de ITDR, inicialmente nadie sabe quién debe realizar el triaje. La solución adecuada es que las alertas de ITDR sean primero escaladas al SOC, con puntos claros de transferencia al equipo de identidad para la depuración de privilegios y la higiene de las cuentas de servicio. Quien no defina este punto de transferencia terminará con alertas sin responsable asignado.

Una tercera observación concierne a la gravedad de las alertas. Las herramientas de ITDR proporcionan puntuaciones de riesgo, pero la mayoría de los SOC de medianas empresas no cuentan con una escala establecida para los riesgos de identidad. Un inicio de sesión con “alto” nivel de riesgo procedente de Brasil para un usuario que está de vacaciones en ese país no constituye un ataque. En cambio, un consentimiento OAuth con “riesgo medio” puede serlo si la aplicación es desconocida. Quien activa ITDR debería definir paralelamente un sistema de mapeo de gravedad que vincule la lógica de riesgo de ITDR con el contexto empresarial propio.

La lección es esta: ITDR sin un plan de higiene de identidad genera fatiga por alertas en el SOC. Quien introduce esta capa debe, de forma paralela, poner en marcha un programa de limpieza de la identidad: inventario de cuentas de servicio, auditoría de consentimientos OAuth, revisión de privilegios y mantenimiento de los dispositivos. Estas tareas no son espectaculares, pero marcan la diferencia entre un despliegue útil de ITDR y una consola permanentemente inundada de alertas.

Lo que los equipos de seguridad deben decidir antes del T3 de 2026

Tres movimientos intensifican la cuestión de la ITDR. Primero: Microsoft amplió Defender for Identity a Okta en abril de 2026, lo que abarata la detección multi-IDP. Segundo: las auditorías NIS2 en la región DACH exigen desde principios de 2026 cada vez más pruebas de detección de identidad, especialmente para operadores de infraestructuras críticas (KRITIS). Tercero: los ataques basados en tokens aumentaron significativamente en 2025; los patrones clásicos de elusión de MFA, como el robo de cookies de sesión, siguen funcionando en 2026.

Quien inicie esta hoja de ruta en el T2 de 2026 tendrá una capa ITDR operativa al cambio de año. Este es el requisito previo para la próxima ola de auditorías NIS2 y para cubrir la brecha de detección que los ataques basados en identidad dejan abierta en cualquier configuración sin ITDR. Quien espere mantendrá la brecha abierta en 2027, con la complicación adicional de una presión de auditoría más estricta.

Una recomendación concreta de las revisiones prácticas: quien comience en el T2 de 2026 debería completar el inventario de identidades en las primeras cuatro semanas. Esto incluye una lista de todos los IDP con IDs de tenant, una lista de todas las cuentas de servicio con propietario y privilegios, una evaluación de consentimientos OAuth por IDP y un perfil de privilegios por rol privilegiado. Estas cuatro listas cuestan entre 15 y 25 días-persona, dependiendo del tamaño del entorno de identidad. Son la base sobre la que se sustenta cualquier elección de ITDR.

Lo que no pertenece a esta hoja de ruta: un cambio de herramienta sin higiene de identidad. Quien active la ITDR sin higiene de cuentas de servicio, sin revisión de consentimientos OAuth, sin revisión de privilegios, generará basura de alertas. La pregunta más honesta en cada revisión de seguridad de los próximos dos trimestres no es, por tanto, «qué herramienta ITDR», sino «cómo es nuestra realidad de identidad antes de implementar una herramienta sobre ella». Esta es la respuesta aburrida. Es la correcta. Y ahorra la costosa corrección dentro de doce meses, cuando llegue el próximo informe de auditoría del BSI.

Preguntas frecuentes

¿Necesitamos ITDR si ya tenemos EDR y SIEM?

Sí, en la mayoría de las configuraciones. El EDR ve el endpoint, el SIEM correlaciona logs, pero ambos ven el contexto de identidad solo indirectamente. El robo de tokens, el abuso de OAuth y los movimientos cross-tenant suelen aparecer en ambos sistemas horas más tarde. La ITDR cubre esta brecha, ya sea como capa propia o como módulo en la pila existente.

¿Cuál es la diferencia entre ITDR e ISPM?

La ITDR es detección más respuesta, el ISPM (Identity Security Posture Management) es higiene del inventario. El ISPM muestra qué está mal configurado en la pila de identidad, la ITDR detecta cuando alguien explota activamente la configuración. Ambos se complementan, no se sustituyen.

¿Es suficiente Microsoft Entra ID Protection como solución ITDR?

Para entornos puramente de Microsoft, a menudo sí; para entornos multi-IDP, no. Entra ID Protection cubre bien las identidades de Entra, pero no ve dentro de los tenants de Okta, Workspace o AD on-premise. Quien tenga varios proveedores de identidad necesita o bien la licencia ampliada de Defender for Identity o una capa ITDR propia.

¿Qué tan profundo debe ser el inventario de identidades antes de la implementación de ITDR?

Al menos cuentas de servicio, consentimientos OAuth y roles privilegiados. Sin estos tres inventarios, ITDR produce principalmente ruido de alertas, ya que los procesos diarios normales aparecen como anomalías. Con los tres inventarios, la carga de triaje se reduce en un factor de cinco a diez durante las primeras tres semanas.

¿Qué herramientas ITDR son relevantes para pymes en la región DACH?

Microsoft Defender for Identity (para hogares afines a M365, desde abril de 2026 con cobertura Okta), CrowdStrike Falcon Identity (configuraciones consolidadas EDR), Silverfort y Semperis para configuraciones multi-IDP, Okta Identity Threat Protection para hogares centrados en Okta. La selección depende del stack de identidad existente, no del marketing del proveedor.

Fuente imagen principal: Generada por IA con Google Imagen 4 Fast, verificada con SynthID

Sobre el autor: Alec Chizhik

Más artículos de Alec Chizhik