MDR vs ITDR para M365: qué herramienta detecta realmente un BEC (y cuál no)

Cuando el ITDR falla exactamente cuando más lo necesitas

Dos incidentes de compromiso de correo empresarial (BEC) en dos clientes distintos, con ITDR activo y correctamente configurado, sin ninguna alerta. No es un problema de configuración ni de falta de inversión: es un problema de tasa de detección real. Y cuando eso ocurre dos veces seguidas, con un intervalo de dos años, la conclusión es razonable: hay que evaluar alternativas.

Este artículo no es una denuncia de ningún proveedor. Es una guía de evaluación práctica para MSPs que gestionan entornos Microsoft 365 Business Premium y necesitan saber qué preguntar, qué probar y qué exigir antes de comprometerse con una plataforma de detección de identidad.

El problema real detrás de los fallos de detección

Antes de comparar herramientas, conviene entender por qué fallan. Uno de los factores más documentados —y menos publicitados— es la latencia en las APIs de Microsoft. Cuando un proveedor de ITDR depende de la Management API de Microsoft para obtener señales de Entra ID, Defender for Office 365 o Exchange Online, queda expuesto a los ciclos de latencia que Microsoft introduce tras sus propios parches y actualizaciones. Esos ciclos pueden durar horas. En un BEC, las primeras horas son exactamente la ventana en la que el atacante actúa.

Esto no es especulación: hay reconocimientos públicos por parte de responsables de producto de al menos uno de los proveedores más usados en el mercado MSP, confirmando que la latencia recurrente con las APIs de Microsoft es inaceptable y que están rediseñando la arquitectura para evitar esa dependencia. Es una señal positiva de responsabilidad. También es una señal de que el problema existe y lleva tiempo sin resolverse.

La lección técnica es clara: un proveedor de ITDR que procesa señales de forma nativa a través de conectores de primera parte con Defender for Endpoint, Defender for Office 365 y Entra ID tiene una ventaja estructural sobre uno que depende de APIs secundarias con latencia variable.

Qué alternativas están siendo evaluadas en la comunidad MSP

Entre los MSPs que han vivido situaciones similares, dos nombres emergen de forma consistente como alternativas al ITDR de Huntress: Petra Security y Field Effect.

Petra Security

Varios MSPs han ejecutado Petra y Huntress ITDR en paralelo durante meses para comparar resultados en condiciones reales. La conclusión que se repite: Petra detecta amenazas que Huntress pierde o detecta con retraso. No es marketing —es el resultado de pruebas lado a lado con tráfico real de clientes.

El perfil de uso que describe mejor la comunidad es este: Huntress sigue siendo valorado para EDR y formación en concienciación, pero para la detección de amenazas de identidad específicamente en M365, Petra cubre mejor ese hueco.

El problema crítico para entornos con obligaciones regulatorias es que Petra no cumple actualmente con RGPD de forma verificable. Sin DPA formal, sin lista transparente de subprocesadores y sin confirmación clara de residencia de datos en la UE, no puede utilizarse con clientes donde el cumplimiento normativo sea un requisito. Y en la práctica, con los volúmenes de datos de usuario que procesa una herramienta ITDR, ese requisito siempre existe.

Field Effect

La otra alternativa que aparece con frecuencia es Field Effect, con una valoración cualitativa consistente: el equipo es accesible, el producto ha superado comparaciones con otras plataformas y el proceso de incorporación es razonable. No hay tantos datos de pruebas lado a lado publicados como con Petra, pero la satisfacción declarada por quienes lo han adoptado es alta.

Para una evaluación honesta, la recomendación que circula en la comunidad es directa: solicitar una demo y activar el periodo de prueba para obtener experiencia práctica con datos propios. Las listas de características no sustituyen a ver qué detecta —y qué no— con tráfico real.

RGPD: más allá de 'nuestros datos están en Europa'

Este punto merece una sección propia porque es donde más marketing vacío circula. Que un proveedor diga que sus servidores están alojados en la UE no es suficiente. El cumplimiento real del RGPD para una herramienta que procesa datos de identidad y correo de tus clientes requiere verificar cuatro cosas concretas:

• DPA formal: un acuerdo de procesamiento de datos firmable, no un checkbox en los términos de servicio.
• Lista de subprocesadores transparente y actualizada: qué terceros acceden a los datos, con qué finalidad y desde dónde.
• Residencia de datos confirmada: no solo almacenamiento, sino también procesamiento. Los datos en reposo en Frankfurt con procesamiento en Virginia no cumplen.
• Ubicación de los analistas del SOC: si el SOC opera 24/7 pero con analistas fuera de la UE accediendo a datos de tus clientes, eso es una transferencia internacional de datos que requiere salvaguardas específicas. Pregunta directamente dónde están los analistas y exige una respuesta escrita.

La responsabilidad aquí no es solo del proveedor. Como MSP eres responsable ante tus clientes de la cadena de custodia de sus datos. Un fallo de detección es un problema operacional. Un fallo de RGPD es un problema legal.

Qué debe hacer una plataforma MDR/ITDR para M365 Business Premium

Si partes de un entorno Business Premium ya desplegado, el criterio de evaluación más importante no es qué añade la herramienta, sino cómo se integra con lo que ya tienes. Agregar otro agente en cada endpoint cuando ya tienes Defender for Endpoint activo no aporta valor proporcional a la complejidad operacional que genera.

Una plataforma bien diseñada para este contexto debería:

• Operar sobre las señales nativas de Defender for Endpoint, Defender for Office 365 y Entra ID sin requerir agentes adicionales o con un agente ligero estrictamente necesario.
• Ofrecer respuesta activa real, no solo alertas: revocar sesiones activas, deshabilitar cuentas comprometidas, eliminar reglas de bandeja de entrada maliciosas creadas por el atacante, aislar endpoints.
• Contar con un SOC 24/7 que actúe, no que notifique. La diferencia entre recibir una alerta a las 2 de la madrugada y que alguien ya haya revocado la sesión es la diferencia entre un incidente contenido y un BEC completo.
• Proporcionar una consola multiinquilino para la gestión MSP, con facturación mensual por usuario y sin mínimos anuales por cliente. El modelo de negocio de una pyme de 8 puestos no puede cargar con compromisos de volumen anuales.

Cómo estructurar la evaluación antes de comprometerte

La comunidad de MSPs que ha pasado por este proceso coincide en un punto: las pruebas prácticas valen más que cualquier hoja de especificaciones. Dicho esto, hay una forma de estructurar la evaluación para que sea eficiente:

• Prueba en paralelo: si es posible, activa dos plataformas en el mismo entorno durante cuatro a ocho semanas. Los resultados en condiciones reales eliminarán más dudas que cualquier demo.
• Simula un BEC: existen herramientas de simulación de ataques que puedes usar en un entorno de prueba. Verifica si la plataforma detecta inicio de sesión desde IP inusual, creación de reglas de reenvío automático y exportación de correo. Son los tres patrones más frecuentes en un BEC real.
• Revisa el historial de incidentes del proveedor: un proveedor que reconoce públicamente sus fallos, explica la causa raíz y describe el cambio técnico que va a implementar genera más confianza que uno que no tiene historial de incidentes declarados. El silencio no es ausencia de problemas.
• Exige documentación RGPD antes de contratar: no después. Si el proveedor no puede facilitar un DPA borrador y la lista de subprocesadores en la fase de evaluación, esa respuesta ya es información.

La pregunta que queda sin responder del todo

Las tres preguntas más difíciles de responder en este mercado son precisamente las más importantes: ¿cuál es la tasa real de falsos negativos en BEC para cada plataforma? ¿Qué arquitectura mitiga de forma demostrable la latencia de las APIs de Microsoft? ¿Qué proveedores cumplen RGPD con DPA formal, residencia confirmada y SOC en la UE?

Ningún proveedor publica tasas de falsos negativos auditadas de forma independiente. Es comprensible —es información competitiva sensible— pero también significa que la única forma de obtener esos datos es con pruebas propias. Para la latencia de APIs, la arquitectura correcta es la integración nativa de primera parte sobre Microsoft Graph con conectores certificados, y es algo que puedes preguntar directamente en una demo técnica. Para el RGPD, la lista de verificación del apartado anterior es el filtro mínimo.

La responsabilidad ante un BEC no detectado no es solo técnica. Para un MSP, significa una conversación difícil con un cliente, una revisión del contrato de servicio y, en el peor caso, una notificación a la AEPD si hubo exposición de datos personales. Esa cadena de consecuencias hace que la evaluación rigurosa de herramientas ITDR no sea una decisión técnica opcional —es parte del modelo de negocio.

Si gestionas entornos M365 y nunca has comprobado qué detectaría tu ITDR actual ante una regla de reenvío maliciosa creada a las 3 de la madrugada, ahora es un buen momento para averiguarlo.