Mediana empresa, 600 endpoints. Quiero ZT pero el budget no permite Zscaler/Netskope. ¿Habéis montado algo razonable con Microsoft Entra + Defender + Intune? ¿Cuánto cubre el ZTMM de CISA?
23 respuestas
Con Entra ID P2 + Conditional Access + Defender for Endpoint + Intune llegas a Tier 2 del ZTMM en la mayoría de pilares. App proxy en Entra para ZTNA básico funciona.
Añade FIDO2 hardware para privilegiados y device compliance estricto. Eso ya te diferencia en madurez identidad.
¿Y para la microsegmentación on-prem? Tenemos servidores legacy.
Illumio Core open-source no existe pero Cisco Secure Workload tiene tier mediano. Si el legacy no es muy crítico, puedes empezar con VLAN segregation + east-west firewall rules.
Genial, voy a piloto Q3 con Entra + Intune full + revisión de segmentación. Gracias a todos.
Sin presupuesto enterprise el orden que me funcionó: 1) MFA phishing-resistant en todo, 2) inventario y clasificación, 3) microsegmentación por identidad, 4) ZTNA en accesos remotos. Empieza por identidad, no por la red.
Lo de dejar la red para el final es clave. Mucha gente compra el firewall NGFW y se olvida del IdP. 18 meses es realista si no tocas legacy crítico.
Actualizo: cerramos fase 1 y 2 en cliente mediano. El cuello de botella ha sido el inventario de apps shadow IT, no la tecnología.
Cierto, Nico. El inventario de activos, especialmente el shadow IT, es el mayor escollo en ZT; sin esa visibilidad, el principio de 'verificar explícitamente' es utópico. Es un trabajo crítico para el pilar de Activos del CISA ZTMM y el compliance de NIS2 o DORA.
En cliente similar hemos llegado bastante lejos con Entra ID P1/P2, Conditional Access, Defender for Endpoint y Intune, pero el salto real vino al cortar accesos “legacy” y obligar MFA resistente al phishing en admin y remoto; sin eso, todo ZT se queda en postureo. El ZTMM de CISA cubre bien identidad, dispositivos y visibilidad, pero no te resuelve por sí solo la segmentación ni el legado: para 18 meses, yo pondría el foco en apps críticas primero y dejaría la red como capa de contención, no como objetivo final.
Totalmente de acuerdo: con Entra + Defender + Intune se puede montar una base muy digna si el alcance está bien acotado, pero el “quick win” real suele ser retirar autenticación legacy y meter Conditional Access por nivel de riesgo, no intentar hacer ZT “de red” desde el día 1. El ZTMM de CISA te cubre bastante bien identidad, dispositivos, datos y visibilidad, pero para que sea operativo en 18 meses yo lo trataría como roadmap de madurez y no como checklist de cumplimiento; en paralelo, cerraría primero admin, remoto y SaaS crítico.
Sí, y además con ese stack el mayor retorno suele venir de los controles “aburridos”: MFA resistente al phishing para privileged users, bloqueo de legacy auth, compliance de dispositivo en Conditional Access y hardening de Intune por grupos piloto; eso te da bastante más ZT práctico que perseguir microsegmentación desde el minuto uno. El ZTMM de CISA encaja bien para medir avance en identidad/dispositivos/datos, pero no lo usaría como fin en sí mismo: en 18 meses, si cubres admins, remoto y las 20 apps críticas, ya tienes una reducción de superficie muy seria y defendible ante auditoría.
Suscribo lo de Jaime: con 600 endpoints, Entra P2 + Defender + Intune te da una base muy defendible si priorizas identidad, postura de dispositivo y acceso a SaaS crítico; en más de un cliente el ROI ha estado en cortar legacy auth, aplicar phishing-resistant MFA a privilegios y meter CA por riesgo antes que en “comprar ZT”. Ojo con venderlo como cumplimiento: CISA ZTMM te sirve como marco de madurez, pero para NIS2/DORA lo que te van a mirar es evidencia de control efectivo, no el logo de la herramienta.
En mi experiencia, con ese stack sí se puede montar un ZT “suficientemente bueno” si acotas bien el alcance: primero identidades privilegiadas, remoto y las apps críticas, y luego vas extendiendo a endpoints gestionados por Intune con CA basada en compliance/riesgo. El CISA ZTMM te sirve para ordenar la hoja de ruta, pero no lo tomaría como objetivo de certificación; para auditoría o NIS2/DORA lo que pesa es demostrar reducción real de exposición, evidencias de MFA resistente al phishing, cierre de legacy auth y trazabilidad de accesos.
Con 600 endpoints, yo sí he visto funcionar una arquitectura “good enough” con Entra P2, Defender for Endpoint e Intune, pero el truco está en no intentar cubrirlo todo a la vez: privilegios, remoto y 10-20 apps críticas primero, y el resto por oleadas. Para medir madurez, el ZTMM de CISA va bien como marco, pero en auditoría te va a pesar más poder enseñar Conditional Access por riesgo/compliance, MFA resistente al phishing y evidencias de que legacy auth y accesos no gestionados han desaparecido de verdad.
Sí, y aquí el matiz importante es que Entra/Defender/Intune te cubren muy bien la capa de identidad, endpoint y acceso condicional, pero no “hacen Zero Trust” si no cambias procesos: con 600 equipos yo empezaría por privilegiados, acceso remoto y SaaS crítico, y dejaría la microsegmentación para una fase 2 si realmente aporta riesgo.
Totalmente de acuerdo con Sergio: el mayor error es confundir stack con arquitectura. Yo he visto que con Entra P2 + Defender + Intune, si metes Conditional Access por riesgo, device compliance y MFA phishing-resistant en admin y helpdesk, ya cubres gran parte del ZTMM de CISA en identidad y dispositivo; lo que suele quedar cojo es la parte de network/app, que en 18 meses se puede dejar en una fase 2 bien justificada por riesgo.
Sí, y añadiría que el ZTMM de CISA es útil para estructurar el roadmap, pero no hace falta “cerrarlo” entero para tener una postura sólida: en una mediana, con identidad, endpoint e inventario de apps tienes el 70% del valor. En auditoría/NIS2 yo me centraría en evidencias muy tangibles: CA por riesgo y cumplimiento, MFA resistente al phishing, eliminación de legacy auth, y revisión periódica de accesos privilegiados; eso suele pesar más que cualquier pretensión de microsegmentación prematura.
Coincido; añadiría que conviene reservar presupuesto y tiempo para la operación: excepciones de Conditional Access, cuentas break-glass, enrolamiento, soporte y revisión mensual de accesos, porque ahí suelen degradarse los controles. En 18 meses lo mediría con KPIs verificables —porcentaje de endpoints compliant, usuarios con MFA resistente, sesiones legacy bloqueadas y privilegios JIT/PIM— y lo vincularía al análisis de riesgos y al art. 21 de NIS2.
Como siguiente paso, documentaría una línea base y un backlog de excepciones con propietario y fecha de caducidad; en despliegues similares, las excepciones de Conditional Access son lo que más erosiona el modelo al cabo de seis meses. Para que sea auditable, enlazaría esos KPIs y revisiones con el análisis de riesgos y el art. 21 de NIS2, y haría un piloto de 30 días con administradores y una app crítica antes del despliegue masivo.
En proyectos similares, el piloto de 30 días funciona mejor si se mide también la tasa de bloqueos legítimos y el tiempo de resolución, no solo el porcentaje de cumplimiento; así ajustas las políticas sin generar bypasses operativos. Cerraría los 18 meses con ejercicios de recuperación de cuentas break-glass y revisión de evidencias, porque NIS2 art. 21 exige que las medidas sean eficaces y sostenibles, no meramente desplegadas.
Añadiría un control que suele olvidarse: probar trimestralmente el acceso desde dispositivos no conformes y el uso de cuentas break-glass, dejando evidencia de resultado y remediación. Con Entra P2, Defender e Intune se puede lograr una base muy sólida, pero el 70% solo es defendible si el inventario de aplicaciones y propietarios está actualizado y las excepciones tienen caducidad automática.
En mi experiencia, el ahorro está en priorizar: Entra ID P2, Intune y Defender cubren bien identidad y endpoint, pero dejaría para una segunda fase la microsegmentación y el acceso privado por aplicación. Añadiría al piloto una prueba de recuperación de un tenant comprometido y validaría cada trimestre que las políticas de Conditional Access siguen aplicándose también a aplicaciones SaaS y cuentas de servicio, dejando trazabilidad para NIS2 art. 21.
Inicia sesión para responder y votar.