Evaluación del estado del dispositivo para el control de acceso a la red

Evaluación del estado del dispositivo para el control de acceso a la red. Un informe técnico de Purple. Bienvenido. Soy su anfitrión para el informe de hoy, y si está escuchando esto, probablemente sea un arquitecto de seguridad de TI, un ingeniero de redes o un CTO al que se le ha pedido que refuerce el control de acceso a la red en toda su organización. Es posible que gestione un complejo hotelero, una cadena de tiendas, un centro de conferencias o una instalación del sector público, y haya llegado al punto en que comprobar simplemente quién se conecta a su red ya no es suficiente. Necesita saber qué se está conectando y si ese dispositivo está en un estado adecuado para ser de confianza. Eso es exactamente lo que vamos a tratar hoy. Evaluación del estado del dispositivo para el control de acceso a la red: qué es, cómo funciona a nivel técnico, cómo se integra con su infraestructura RADIUS existente y plataformas MDM y, lo que es más importante, qué hacer con los dispositivos que no superan la comprobación. Comencemos. Sección uno. Contexto y por qué la evaluación del estado del dispositivo es importante ahora. Durante la última década, la mayoría de las implementaciones de WiFi empresariales han dependido del control de acceso basado en la identidad. Se autentica al usuario (a través de 802.1X, un Captive Portal o una clave precompartida) y, si las credenciales son correctas, se concede el acceso. El problema es que la verificación de la identidad por sí sola no dice nada sobre el estado de seguridad del propio dispositivo. Se puede introducir un nombre de usuario y una contraseña válidos en un portátil que funcione con un sistema operativo sin parches de hace tres años y sin antivirus, conectado a su VLAN corporativa. Ese dispositivo es un riesgo en el momento en que toca su red. El cambio hacia la arquitectura Zero Trust ha cambiado fundamentalmente el cálculo aquí. Zero Trust opera bajo el principio de nunca confiar, siempre verificar, y esa verificación debe extenderse más allá de la identidad para abarcar la salud del dispositivo. Aquí es donde entra en juego la evaluación del estado del dispositivo. La evaluación del estado interroga al endpoint en el momento de la autenticación, comprueba un conjunto definido de criterios de salud y traslada ese resultado a la decisión de control de acceso. El resultado es el acceso a la red basado en el estado del dispositivo: un modelo en el que lo que se puede hacer en la red se determina no solo por quién es usted, sino por el estado de seguridad del dispositivo que está utilizando. Desde el punto de vista del cumplimiento normativo, esto es de enorme importancia. La versión 4.0 de PCI DSS exige explícitamente que las organizaciones controlen qué dispositivos pueden acceder a los entornos de datos de los titulares de tarjetas. El principio de responsabilidad proactiva de GDPR exige que las organizaciones implementen medidas técnicas adecuadas para proteger los datos personales, y permitir que dispositivos sin parches y sin gestionar accedan a redes que transportan datos personales es cada vez más difícil de defender en una auditoría. Para los entornos sanitarios, se aplica la misma lógica bajo los requisitos de Cyber Essentials del NHS y, en el contexto de EE. UU., HIPAA. Sección dos. Inmersión técnica: cómo funciona realmente la evaluación del estado del dispositivo. Permítame guiarle a través de su funcionamiento. En esencia, la evaluación del estado del dispositivo (device posture assessment) es un proceso que se ejecuta durante o inmediatamente después del saludo de autenticación, antes de que se conceda el acceso completo a la red. Existen tres modelos arquitectónicos principales que encontrará. El primero es la evaluación basada en agentes. Un agente de software ligero —instalado en el endpoint, a menudo como parte de su MDM o plataforma de detección y respuesta de endpoints— recopila telemetría de estado y la presenta al motor de políticas NAC. Este es el enfoque más completo. El agente puede comprobar la versión del sistema operativo, el nivel de parches acumulativos, la vigencia de las firmas de antivirus, el estado del firewall, el estado de cifrado del disco, si se están ejecutando aplicaciones prohibidas específicas y si el dispositivo está registrado en su MDM. El agente comunica estos datos al servidor RADIUS o a un motor de políticas dedicado a través de un protocolo como RADIUS CoA —Change of Authorisation— o mediante una integración de API específica del proveedor. El segundo modelo es la evaluación sin agentes. En este caso, el sistema NAC intenta inferir el estado del dispositivo sin un agente local, normalmente consultando directamente a su plataforma MDM. Cuando un dispositivo se conecta y se autentica, el motor de políticas realiza una llamada a Microsoft Intune, Jamf o VMware Workspace ONE a través de una API, recupera el registro de cumplimiento del dispositivo y lo utiliza como señal de estado. Esto funciona bien para dispositivos corporativos gestionados que ya están registrados en el MDM. La limitación es obvia: los dispositivos no gestionados o BYOD no tendrán un registro de MDM, por lo que necesitará una política de respaldo para ellos. El tercer modelo es la evaluación basada en la red. El sistema NAC escanea el dispositivo que se conecta utilizando técnicas como consultas SNMP, llamadas WMI a través de la red o huellas dactilares pasivas (passive fingerprinting) de los patrones de tráfico. Este es el método menos fiable y generalmente se utiliza solo como comprobación complementaria o para entornos heredados donde la implementación de agentes no es viable. Ahora, hablemos específicamente de la integración con RADIUS y 802.1X, porque aquí es donde la arquitectura se vuelve interesante. En una implementación estándar de 802.1X, el suplicante —es decir, el dispositivo— presenta las credenciales al autenticador, que es su punto de acceso inalámbrico o switch, el cual reenvía la solicitud de autenticación al servidor RADIUS. El servidor RADIUS valida las credenciales y devuelve un Access-Accept o un Access-Reject. En una implementación que tiene en cuenta el estado del dispositivo, se amplía este flujo. Una vez que la autenticación inicial tiene éxito, el servidor RADIUS —o un motor de políticas coubicado como Cisco ISE, Aruba ClearPass o Forescout— activa una evaluación de estado. El dispositivo se coloca inicialmente en una VLAN restringida —a veces llamada VLAN de estado o VLAN de cuarentena— mientras se ejecuta la evaluación. Si el dispositivo supera todas las comprobaciones de estado, se envía un mensaje RADIUS Change of Authorisation al punto de acceso, moviendo el dispositivo a la VLAN de producción correspondiente. Si falla, permanece en la VLAN restringida y se le redirige a un portal de remediación. El método EAP es fundamental en este punto. EAP-TLS, que utiliza autenticación mutua mediante certificados, es el estándar de oro para el acceso de dispositivos corporativos porque permite al servidor RADIUS validar no solo al usuario, sino también el certificado del dispositivo, confirmando que se trata de un endpoint conocido y gestionado. EAP-PEAP o EAP-TTLS con MSCHAPv2 son habituales para la autenticación basada en credenciales de usuario, pero ofrecen por sí mismos una menor garantía a nivel de dispositivo. Para que la evaluación de estado sea realmente sólida, lo ideal es combinar EAP-TLS con la comprobación de conformidad de MDM; esta combinación proporciona tanto la identidad criptográfica del dispositivo como una señal de estado de salud en tiempo real. ¿Qué atributos específicos evalúa normalmente un control de estado? La lista de comprobación básica para la mayoría de las implementaciones empresariales abarca: la versión del sistema operativo y el número de compilación (¿ejecuta el dispositivo una versión de SO compatible?); el nivel de parches (¿se han aplicado los parches críticos y de alta gravedad dentro de un plazo definido, normalmente de 30 días?); el estado del antivirus o de la detección y respuesta de endpoints (¿está instalado un producto de seguridad reconocido, en ejecución y con firmas actualizadas?); el firewall de host (¿está activado?); el cifrado de disco (¿está activo BitLocker o FileVault?); el registro en MDM (¿está el dispositivo registrado en su plataforma de gestión?). Y, cada vez más, las organizaciones añaden comprobaciones de software prohibido (¿existe alguna aplicación con vulnerabilidades conocidas?) y de validez de certificados. Sección tres. Recomendaciones de implementación y errores comunes. Permítame ofrecerle la orientación práctica que se deriva de desplegar estos sistemas en entornos de hostelería, retail y sector público. En primer lugar, empiece por la visibilidad antes de la aplicación de políticas. Antes de activar los controles de estado en modo de bloqueo, ejecútelos en modo de solo monitorización durante al menos cuatro semanas. Esto le proporcionará una línea de base de cómo es realmente su parque de dispositivos: qué porcentaje de dispositivos no cumplen las políticas, qué atributos de estado fallan con más frecuencia y si los umbrales de sus políticas están calibrados correctamente. Pasar directamente a la aplicación de políticas sin esta línea de base es el error más común, y se traduce en una oleada de incidencias en el servicio de soporte y usuarios frustrados desde el primer día. En segundo lugar, diseñe su segmentación de VLAN antes de configurar las políticas de estado. Necesita como mínimo tres segmentos de red: una VLAN corporativa de acceso total para dispositivos gestionados que cumplan las políticas, una VLAN de remediación con acceso a internet y acceso a su infraestructura de gestión de parches y MDM (pero a nada más), y una VLAN de invitados para dispositivos personales no gestionados. Algunas organizaciones añaden una cuarta: una VLAN corporativa restringida para dispositivos gestionados que no superan el control de estado pero que necesitan acceso limitado a recursos específicos mientras se corrigen sus problemas. Asocie estas VLAN a sus resultados de estado antes de escribir una sola regla de política. En tercer lugar, aborde el problema de los dispositivos BYOD y de invitados de forma explícita. Especialmente en entornos de hostelería —y esto se aplica por igual a hoteles, centros de conferencias y zonas de descanso del personal de retail—, tendrá una población significativa de dispositivos personales que nunca se registrarán en el MDM. Su política de postura debe tener una ruta definida para estos dispositivos. El enfoque típico es redirigir automáticamente los dispositivos no registrados a una VLAN de invitados, con controles de ancho de banda y filtrado de contenido adecuados, en lugar de bloquearlos por completo. Bloquear los dispositivos personales en un hotel o entorno de conferencias crea un problema operativo inmediato que su equipo de recepción sentirá antes que su equipo de seguridad. En cuarto lugar, establezca tiempos de espera de remediación realistas. Cuando un dispositivo no supera la evaluación de postura y se coloca en la VLAN de remediación, debe definir cuánto tiempo tiene para autorremediarse antes de ser trasladado a cuarentena o bloqueado. Para fallos relacionados con parches, un plazo de 24 a 48 horas es razonable para un dispositivo corporativo gestionado: lo suficientemente largo para que el dispositivo descargue las actualizaciones y lo suficientemente corto para mantener la urgencia. Para fallos de antivirus, el plazo debería ser más corto —de cuatro a ocho horas—, porque un dispositivo sin protección activa de endpoint representa un riesgo más inmediato. En quinto lugar, pruebe a fondo su flujo de Cambio de Autorización (CoA). El CoA es el mecanismo que traslada un dispositivo de la VLAN de remediación a la VLAN de producción después de que supera la evaluación de postura. También es el mecanismo que puede devolver un dispositivo a cuarentena si falla una comprobación periódica. Los fallos de CoA —donde el servidor RADIUS envía el mensaje CoA pero el punto de acceso no actúa en consecuencia— son una fuente común de quejas de los usuarios. Pruebe esto de extremo a extremo en su laboratorio antes del despliegue en producción y supervise las tasas de éxito de CoA en sus registros de RADIUS después del despliegue. Ahora, unas palabras sobre los errores habituales específicos de los entornos de grandes recintos. En un estadio o centro de conferencias con miles de conexiones simultáneas, la evaluación de postura añade latencia al flujo de autenticación. Las comprobaciones basadas en agentes que requieren que el agente recopile telemetría y envíe un informe pueden añadir de dos a cinco segundos al tiempo de conexión. A gran escala, esto es perceptible. Optimícelo prealmacenando en caché los resultados de la postura: la mayoría de los motores de políticas le permiten almacenar en caché el resultado de la postura de un dispositivo durante un período definido, normalmente de una a cuatro horas, de modo que la reautenticación no active una reevaluación completa cada vez. Esta es una optimización de rendimiento crítica para entornos de alta densidad. Sección cuatro. Preguntas rápidas. Pregunta: ¿Puedo realizar la evaluación de postura sin desplegar agentes en cada dispositivo? Sí, a través de la integración de la API de MDM para dispositivos registrados y mediante huella digital basada en red para otros, pero su cobertura y precisión serán menores que con agentes. Para un entorno mixto, la respuesta pragmática es un enfoque híbrido: agentes en dispositivos corporativos, API de MDM para BYOD registrados y huella digital de red como alternativa. Pregunta: ¿Funciona la evaluación de estado con WPA3? Sí. WPA3 Enterprise utiliza el mismo marco de autenticación 802.1X que WPA2 Enterprise, por lo que la evaluación de estado se integra de la misma manera. El PMF (marcos de gestión protegidos) más sólido de WPA3 y la autenticación SAE en realidad complementan la comprobación de estado al reforzar la capa de autenticación sobre la que se asienta dicha evaluación. Pregunta: ¿Cuál es la diferencia entre la evaluación de estado y el NAC? El NAC (control de acceso a la red) es el marco más amplio para controlar qué dispositivos pueden acceder a qué recursos de la red. La evaluación de estado es una entrada en la decisión del NAC, concretamente la señal de salud del dispositivo. Se puede tener NAC sin evaluación de estado (por ejemplo, control de acceso basado únicamente en la identidad), pero no se puede tener un control de acceso basado en el estado del dispositivo sin un marco NAC que aplique los resultados. Pregunta: ¿Cómo se integra esto con una plataforma como Purple? La plataforma de Purple gestiona la identidad de los dispositivos y las políticas de acceso en la capa de WiFi. La evaluación de estado es la siguiente capa de control: enriquece la decisión de acceso con los datos de salud del dispositivo. Para los operadores preocupados por la seguridad, la integración de las señales de estado de su MDM en el motor de políticas de Purple le permite aplicar un acceso diferenciado basado tanto en la identidad como en el estado de conformidad del dispositivo. Sección cinco. Resumen y próximos pasos. Para resumir los puntos clave de la sesión de hoy. La evaluación de estado del dispositivo es la práctica de evaluar la salud del endpoint (versión del sistema operativo, nivel de parches, estado del antivirus, registro en el MDM) en el momento de la autenticación, y utilizar esa señal de salud para determinar los derechos de acceso a la red. La arquitectura combina la autenticación 802.1X, un motor de políticas RADIUS, la integración de la API del MDM y la segmentación de VLAN para crear un sistema de control de acceso basado en el estado. Los tres resultados del estado (acceso completo, VLAN de remediación y cuarentena) deben diseñarse y probarse antes de activar la aplicación de políticas. Comience con el modo de monitorización, cree su línea de base y luego pase a la aplicación de políticas. Esto no es opcional si desea un despliegue sin contratiempos. Para los operadores de recintos, la población de dispositivos BYOD y de invitados requiere una gestión de políticas explícita: redirigir a una VLAN de invitados en lugar de bloquear es la opción predeterminada más sólida desde el punto de vista operativo. Sus próximos pasos inmediatos: audite su arquitectura VLAN actual y confirme que dispone de los segmentos necesarios para el enrutamiento basado en el estado. Evalúe las capacidades de la API de su plataforma MDM para la exportación de datos de estado. Revise las capacidades de política de estado de su servidor RADIUS o plataforma NAC. Y si empieza desde cero, considere un enfoque por fases: despliegue primero 802.1X, añada la comprobación de estado en modo de monitorización y, a continuación, pase a la aplicación de políticas en un plazo de 90 días. Gracias por su atención. Para obtener más información sobre la arquitectura de autenticación 802.1X y el despliegue de Wi-Fi Zero Trust, visite la biblioteca de guías de Purple. Si está evaluando el control de acceso basado en el estado para la red de su recinto, el equipo de Purple puede guiarle a través de una evaluación de despliegue. Hasta la próxima.