Resumen

  • En RFC 5209, evaluar consiste en reunir postura de ciertas capacidades del endpoint y compararla con una política. El resultado sólo habla por la evidencia, la regla y el instante que lo produjeron.
  • La reevaluación existe porque una máquina antes conforme puede cambiar y porque la propia política puede exigir algo nuevo. El documento usa como ejemplo la desactivación de un cortafuegos obligatorio.
  • El juicio NEA, la autorización y la ejecución en un punto de acceso no son el mismo acto. Un resultado positivo no prueba que la regla se instaló ni que aún deba seguir activa.

Una luz verde con fecha oculta

A las 09:00, un portátil administrado responde a una evaluación. El recolector del cortafuegos informa que la protección funciona; otro confirma el nivel de actualización. Los validadores aplican la política 42. El broker calcula un resultado global conforme y un sistema de acceso concede conectividad ordinaria.

A las 09:17, el usuario desactiva el cortafuegos para una prueba. El recolector detecta el cambio, pero su notificación coincide con el reinicio del broker cliente. El mensaje no llega. A las 09:25, el panel conserva el verde. La evidencia de las 09:00 es auténtica y la decisión de aquel momento fue correcta.

Lo que no existe es evidencia para el presente. El panel ha reducido «considerado conforme a las 09:00, con estas observaciones y la política 42» a «conforme». Al borrar la hora, una decisión histórica parece una propiedad estable del equipo.

El caso es hipotético; no se atribuye a ninguna implantación. Pero el cambio procede del texto de RFC 5209: un endpoint que fue conforme puede dejar de serlo cuando el usuario inhabilita una protección exigida. La reevaluación no corrige una vergüenza del modelo; completa su dimensión temporal.

El alcance está dentro de la definición

RFC 5209, publicado como Informational en 2008, formula el problema de Network Endpoint Assessment, su vocabulario, modelo de referencia, usos y requisitos. No prescribe un producto entero ni convierte todos los eslabones del cumplimiento en un protocolo único.

Assessment significa recoger postura para un conjunto de capacidades y permitir que los validadores apropiados la evalúen contra una política. «Conjunto» no equivale necesariamente a la totalidad. La postura es la configuración o estado relevante para la política de una organización, no una radiografía absoluta del sistema. Y «evaluar» implica reglas locales, versión y propietario.

Los mensajes tampoco son sinónimos. Un Posture Attribute describe algo observado. Un Request Attribute pide información. Un Result Attribute lleva la decisión. Un Remediation Attribute indica cómo corregir. Pedir no prueba recibir; instruir no prueba ejecutar; el resultado no sustituye al dato que lo sustenta.

El RFC dice que el Result Attribute se crea normalmente al concluir la evaluación para indicar si el endpoint fue «considerado» conforme. Esa cautela es exacta. La conclusión pertenece al conjunto de entradas y a la política utilizada, no queda adherida para siempre a la identidad del dispositivo.

Cada componente tiene una ventana distinta

En el lado cliente hay Posture Collectors, un Posture Broker Client y Posture Transport Clients. En el servidor aparecen Posture Validators, un Posture Broker Server y Posture Transport Servers.

El Collector observa una función, entrega atributos y puede avisar de un cambio. El broker cliente mantiene el registro, reparte peticiones, reúne respuestas y maneja el resultado global. El transporte sostiene y protege el canal.

El Validator recibe atributos de una o varias funciones, solicita detalles si hacen falta, aplica la política y produce resultado o remediación. El broker servidor distribuye mensajes y combina decisiones parciales con la política para obtener el juicio global. El transporte servidor mantiene el diálogo.

La separación prohíbe la omnisciencia por asociación. Un transporte protegido no sabe si falta un Collector. Un broker puede sumar cuatro resultados impecables sin saber qué sucede en una quinta función no registrada. Un Validator puede aplicar bien una regla sobre una medición que caduca después.

Por eso el comprobante debería enumerar qué recolectores se esperaban, cuáles estaban registrados, cuáles contestaron, qué observaron y cuándo; luego, qué validador usó qué versión de política y cómo trató el broker las ausencias, excepciones e incógnitas.

El silencio debe conservar su nombre

RFC 5792, el protocolo PA-TNC posterior, muestra por qué la cobertura no puede suponerse. Las partes pueden soportar tipos de atributo propietarios diferentes y aun así deben interoperar. Un tipo no soportado puede producir error. En casos previstos, el Collector puede devolver todos, algunos o ninguno de los atributos solicitados. Hay campos que representan expresamente un valor desconocido o no disponible.

La extensibilidad exige esa tolerancia, pero no autoriza a convertir huecos en aprobaciones. Si una política requiere cinco controles y sólo cuatro recolectores responden, hay cuatro resultados y una incógnita. La quinta ausencia puede deberse a privacidad, incompatibilidad, falla, configuración o falta real de la capacidad.

La organización decide cómo actuar: denegar, aislar, limitar, aceptar temporalmente una assertion previa o aprobar una excepción. Lo importante es no confundir la aceptación de riesgo con la observación de salud. «4/5; excepción firmada hasta las 10:00» contiene más verdad operativa que compliant=true.

El registro necesita separar resultado, cobertura y disposición política. Cuando se funden, el sistema pierde precisamente la información que necesitará al cambiar la política.

La reevaluación sostiene el tiempo presente

RFC 5209 coloca la reevaluación como segundo uso importante tras el control inicial. La postura y las políticas cambian. Junto al ejemplo del cortafuegos desactivado, menciona una actualización que pasa a ser obligatoria: lo aceptable ayer deja de cumplir cuando entra en vigor la nueva regla.

El impulso puede originarse en el endpoint. Un Collector observa un cambio y el broker cliente inicia otro diálogo. También puede venir del servidor: un Validator recibe fuera de banda una nueva política o noticia de amenaza. Un despliegue puede añadir temporizadores, accesos a aplicaciones sensibles o acciones administrativas.

Así, el camino de los disparadores es parte de la evidencia. ¿El Collector estaba suscrito? ¿La notificación sobrevivió al reinicio? ¿La reevaluación entró en cola, empezó y terminó? ¿La nueva política alcanzó a todos los validadores? Una base que retiene los éxitos pero no los disparadores fallidos guarda una historia inclinada hacia el verde.

Las Assertion Attributes tampoco hacen eterno el pasado. RFC 5209 contempla una afirmación fechada y firmada sobre una evaluación previa que puede aceptarse durante un periodo. Para reutilizarla hacen falta emisor, vínculo al endpoint, funciones y políticas cubiertas, emisión, vencimiento y cambios que obligan a medir de nuevo.

Proteger el mensaje no expande su significado

El modelo asigna protección criptográfica al diálogo y considera ataques de intermediario, modificación, repetición o robo de atributos. Evitar que un resultado viejo se reproduzca como nuevo es esencial.

Pero un atributo recién transmitido sólo habla de lo que ve su Collector. Autenticar al endpoint no garantiza que sus sensores sean completos. Integridad de transporte no significa que el proceso local esté sano. La criptografía conserva autoría, contenido y orden bajo un modelo de confianza; no rellena observaciones ausentes.

La secuencia defendible es:

endpoint y sesión vinculados → recolectores esperados → atributos observados → broker entrega → validadores juzgan → resultado global → autorización → regla aplicada → cambio vigilado → reevaluación terminada.

En cada flecha cambia la autoridad. Si falta el recibo siguiente, el estado siguiente es desconocido, no verde por herencia.

Evaluar no mueve por sí solo el punto de control

RFC 5209 señala que el resultado puede influir en una decisión de acceso que se provisiona a mecanismos de ejecución. A la vez, deja fuera de alcance los mecanismos y protocolos de enforcement, así como la representación del resultado para las tecnologías de acceso.

La asignación es saludable. NEA evalúa. Un sistema de autorización interpreta. Un punto de control instala y conserva una regla. La observación de tráfico muestra el efecto.

El razonamiento no funciona al revés. Un resultado conforme no asegura acceso porque otra condición podría bloquearlo. Un endpoint con acceso no prueba que todas las posturas aprobaron: puede existir un segmento limitado, una excepción o señales externas. Recibir instrucciones de remediación no prueba que se ejecutaron.

Quien quiera afirmar enforcement necesita registrar consumidor, resultado de entrada, mapeo de decisión, vínculo a endpoint y sesión, punto ejecutor, regla, acuse de instalación, hora y efecto. Sin ese recibo, sólo puede afirmar que la evaluación llegó hasta su frontera.

Un comprobante que no pierde el reloj

El expediente empieza por assessment ID, session ID, identidad vinculada, conexión, disparador y tiempos. Compara el inventario esperado con Collectors y Validators registrados y respondientes, sus versiones y huellas de configuración. Conserva peticiones, atributos, instantes de observación, tipos no soportados, incógnitas, omisiones y errores.

Cada resultado parcial cita Validator, política, entradas, regla y razón. El global añade el método de agregación, excepciones y tratamiento de lo desconocido. Si se acepta una assertion previa, se conserva alcance, emisor, ventana y condiciones de revocación.

Luego sólo se agregan hechos de sistemas externos cuando éstos aportan su propia evidencia: decisión de autorización, regla instalada, remediación ejecutada, nueva medición. Al final quedan el último cambio de postura, el último cambio de política, la última reevaluación, disparadores fallidos y edad de la evidencia.

En el caso construido, el estado útil sería: «aprobó a las 09:00; cortafuegos cambiado a las 09:17; disparador perdido; cumplimiento actual desconocido; regla anterior aún activa». Ya no es una luz, sino un diagnóstico.

La fecha no debilita el aprobado; lo vuelve creíble

Una lectura limitada de RFC 5209 no resta valor al modelo. El intercambio de observaciones, validación, agregación y remediación resuelve una necesidad real. RFC 5792, RFC 5793, RFC 6876 y RFC 7171 concretan capas diferentes.

La fragilidad aparece cuando el sistema de aseguramiento convierte un juicio histórico en identidad permanente. Sin hora, cobertura ni política, «conforme» adquiere poder simbólico: la etiqueta puede imponerse al código que corre. La observación actual parece una anomalía contra la base, en vez de ser la base la que ha envejecido.

Debe prevalecer la realidad operativa: Collector presente, cola de reevaluación, versión de política y acuse de enforcement. El aprobado de las 09:00 puede conservarse íntegro, siempre que mantenga su fecha.

A las 09:25, la respuesta rigurosa quizá no sea «no conforme», sino «no reevaluado después de un cambio relevante; estado actual desconocido». Admitir ese desconocido es el primer control que permite medir de nuevo.

Fuentes