Un resultado de cumplimiento siempre tiene una antigüedad
El cumplimiento se basa en evidencia observada en un momento concreto. Después pueden cambiar el cifrado, el heartbeat, la gestión, el riesgo o los datos de parches.
La gestión programada sigue siendo útil, pero toda decisión tiene un límite de vigencia. Hay que conocer fuente, hora, ruta y aplicación.
La verificación casi en tiempo real reduce retrasos, pero no prueba el estado literal actual. El objetivo es la evidencia confiable más reciente con vigencia explícita.
Medir toda la ventana de exposición
La medida útil es el tiempo desde un cambio material hasta el resultado de acceso o remediación verificado.
Ventana total de exposición =
latencia de observación
+ latencia de transmisión
+ latencia de evaluación
+ latencia de aplicación- Observación. Tiempo hasta que endpoint, MDM, agente o atestación detectan el cambio.
- Transmisión. Tiempo hasta que la evidencia llega al servicio de postura.
- Evaluación. Tiempo hasta calcular un nuevo resultado.
- Aplicación. Tiempo hasta que aplicación, gateway, sesión o control responde y se verifica.
Qué significa el ciclo de mantenimiento de Intune
Microsoft documenta un check-in estimado de unas ocho horas para políticas y perfiles, más frecuente tras el registro, y una restricción de un sync de mantenimiento cada 6,5 horas. Es relevante cuando el control depende del refresh ordinario.
No es la única ruta: usuarios y administradores pueden sincronizar, cambios dirigidos pueden impulsar check-in, la protección de aplicaciones evalúa al abrir o reanudar y Defender for Endpoint aporta riesgo a cumplimiento y Conditional Access.
Pregunte por fuente, rutas rápidas y latencia restante cuando no están disponibles.
Las fuentes de postura tienen propiedades distintas
| Fuente | Evidencia | Modelo temporal | Límite |
|---|---|---|---|
| Inventario y cumplimiento MDM | Registro, configuración, cifrado, OS y gestión | Check-in periódico, impulsado o manual | La evidencia no cambia sin conexión o entre evaluaciones |
| EDR | Detecciones, salud del agente y riesgo | Eventos y heartbeats | Un agente comprometido o fallido puede dejar de informar |
| Atestación de plataforma | Arranque y evidencia respaldada por hardware | Registro, acceso o challenge | Solo prueba los claims y vigencia representados |
| Protección de aplicaciones | Integridad, OS y condiciones locales | Inicio, reanudación o acceso a datos | Solo aplicaciones y superficies compatibles |
| Parches y vulnerabilidades | Versiones, exposición y remediación | Inventario, scanner, agente o servicio | Una nueva vulnerabilidad cambia riesgo sin evento local |
Usar un modelo híbrido
- Transiciones por eventos. Emitir cambios compatibles como aumento de riesgo, retirada de gestión o error de control.
- Heartbeats. Las fuentes continuas prueban que siguen activas; un heartbeat vencido pasa a obsoleto o desconocido.
- Conciliación periódica. Comparar estado completo con baseline para encontrar eventos perdidos o no compatibles.
- Verificación bajo demanda. Exigir evidencia dentro del umbral adecuado para accesos sensibles.
- Estado en caché acotado. Guardar postura con fuente, observación, vencimiento y versión, no como booleano sin contexto.
La evidencia rápida no siempre es confiable
- Vincular telemetría a identidades autenticadas de dispositivo y tenant.
- Impedir manipulación y replay con transporte autenticado, integridad, IDs y deduplicación.
- Definir hora de observación confiable y tolerancia de reloj.
- Usar atestación cuando fortalezca el control y documentar qué prueba.
- Correlacionar MDM, EDR, identidad y plataforma; un agente comprometido puede falsearse.
- Definir precedencia de fuentes y política de conflictos.
Modelar estados obsoletos, ausentes, desconocidos y contradictorios
Un dispositivo no debe seguir conforme indefinidamente porque dejó de informar cuando estaba sano. Defina edad máxima por señal.
Separe obsoleto, ausente, desconocido, error, conflicto, no conforme y restaurado. Según el recurso, aplique denegación, sesión limitada, step-up, gracia, aviso, remediación o revisión.
- Dispositivos sin conexión. No pueden enviar eventos; la confianza vence según la última evidencia.
- Fuentes fallidas. Diferencie un dispositivo sano de un servicio MDM o de seguridad caído.
- Recuperación. Restaure acceso solo con evidencia posterior, estable y verificada.
De la evidencia a la aplicación de acceso
Un resultado nuevo no cambia por sí solo las sesiones activas. Hay que correlacionar dispositivo, usuario, tenant, recursos y sesiones, evaluar y verificar la respuesta.
SSF y CAEP pueden transportar cambios. CAEP describe el evento; el receptor decide denegar, revocar, desafiar, limitar u observar.
- Para la ruta de sesión consulte Evaluación continua del acceso ante cambios de postura.
Ejemplo: el heartbeat del agente queda obsoleto
A las 09:00 un portátil informa cifrado sano, protección actual y heartbeat correcto. A las 09:07 deja de informar; la causa aún se desconoce.
Al superar el umbral, la postura pasa de sana a obsoleta. El evento se autentica, correlaciona, deduplica y evalúa. Recursos de bajo riesgo mantienen acceso limitado; código fuente y administración exigen evidencia fresca.
Cuando vuelve el agente, un único heartbeat no restaura acceso. Se concilian controles, se verifica el orden temporal y se registra la recuperación.
Métricas para probar la vigencia
- Medir latencias observación–informe, informe–decisión y decisión–aplicación por plataforma y señal.
- Medir dispositivos dentro de cada umbral de vigencia.
- Registrar eventos perdidos, duplicados y desordenados, backlog, dead letters y hallazgos de conciliación.
- Medir bloqueos erróneos, concesiones inseguras, recuperación, excepciones y recurrencia.
- Probar condiciones normales, offline, red degradada, caída de fuente, reloj y conflictos.
Preguntas a proveedores
- ¿Qué señales son por eventos, periódicas, heartbeat o bajo demanda?
- ¿Qué latencias completas se han medido en condiciones normales y degradadas?
- ¿Cómo recibe la política fuente, hora, vigencia, confianza y versión?
- ¿Qué ocurre offline o si MDM, EDR, atestación o streaming fallan?
- ¿Cómo se gestionan identidad, tenant, integridad, replay, orden, deduplicación y rotación?
- ¿Cómo encuentra la conciliación eventos perdidos o nunca emitidos?
- ¿Qué respuestas afectan solo inicios nuevos y cuáles sesiones activas?
- ¿Qué evidencia confirma convergencia antes de restaurar?
Aplicación en una evaluación de Gideon
Seleccione controles representativos y mida toda la ruta en Gideon Endpoint Management. Confirme fuente, vigencia, datos ausentes, cambio de política, acción y resultado verificado. Use objetivos de latencia por plataforma y señal, no una garantía universal.
Lecturas relacionadas
- Use Gestión zero-touch de endpoints para equipos de seguridad para el ciclo completo.
- Compare responsabilidades en Arquitectura MDM más agente nativo.
- Defina umbrales con Paquete inicial de políticas de postura.
- Descubra Gideon Endpoint Management.
Fuentes primarias
- Microsoft documenta tiempos de check-in en Preguntas sobre políticas y perfiles de Intune.
- Microsoft documenta refresh y sincronización manual en Crear políticas de cumplimiento.
- Microsoft describe riesgo y Conditional Access en Integrar Defender for Endpoint con Intune.
- Microsoft explica estado, gracia y acciones en Configurar acciones para dispositivos no conformes.
Cómo usar este recurso
Elija una señal de alto impacto y mapee observación, transmisión, evaluación, aplicación y recuperación. Defina vigencia y resultado, pruebe condiciones normales y degradadas y conserve las mediciones como evidencia de aceptación.