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

Evaluación de la postura 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 de retail, un centro de conferencias o una instalación del sector público - y ha llegado al punto en que verificar 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 de la postura 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 sus 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 de la postura es importante ahora. Durante la última década, la mayoría de los despliegues de WiFi empresariales se han basado en el control de acceso basado en la identidad. Se autentica al usuario - a través de 802.1X, un Captive Portal o una clave previamente compartida - 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 ordenador 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 peligro potencial en el momento en que toca su red. El cambio a la arquitectura Zero Trust ha modificado 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 de la postura del dispositivo. La evaluación de la postura interroga al endpoint en el momento de la autenticación, comprueba un conjunto definido de criterios de salud y transmite ese resultado a la decisión de control de acceso. El resultado es el acceso a la red basado en la postura - 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 tiene una importancia enorme. PCI-DSS versión cuatro punto cero 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 y, en el contexto de EE. UU., HIPAA. Sección dos. Análisis técnico detallado: cómo funciona realmente la evaluación de la postura.Permítame guiarle a través de los aspectos técnicos. En esencia, la evaluación del estado del dispositivo es un proceso que se ejecuta durante o inmediatamente después del protocolo de autenticación, antes de que se conceda el acceso completo a la red. Existen tres modelos de arquitectura principales con los que se 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 plataforma MDM o de respuesta y detección de endpoints - recopila telemetría de salud y la presenta al motor de políticas de NAC. Este es el enfoque más exhaustivo. El agente puede comprobar la versión del sistema operativo, el nivel de parches acumulados, 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 mediante un protocolo como RADIUS CoA - Cambio de Autorización - o a través de 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 de salud 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 indicador 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 analiza el dispositivo que se conecta utilizando técnicas como consultas SNMP, llamadas WMI a través de la red o identificación pasiva de patrones de tráfico. Este es el método menos fiable y, por lo general, solo se utiliza como comprobación complementaria o para entornos heredados en los que no es viable la implementación de agentes. 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 - que es el dispositivo - presenta las credenciales al autenticador, que es su punto de acceso WiFi 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 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 se realiza con éxito, el servidor RADIUS - o un motor de políticas coubicado como Cisco ISE, Aruba ClearPass o Forescout - activa una evaluación del estado. El dispositivo se ubica 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 de Cambio de Autorización de RADIUS al punto de acceso, moviendo el dispositivo a la VLAN de producción adecuada. Si falla, permanece en la VLAN restringida y se le dirige a un portal de corrección. El método EAP es clave 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, lo que confirma 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 menos seguridad a nivel de dispositivo por sí solos. Para que la evaluación de estado de seguridad sea realmente sólida, lo ideal es combinar EAP-TLS con la comprobación de cumplimiento del MDM: esa combinación proporciona tanto la identidad criptográfica del dispositivo como una señal de estado en tiempo real. ¿Qué atributos específicos evalúa normalmente un control de estado de seguridad? La lista de comprobación principal para la mayoría de las implementaciones empresariales abarca: versión del sistema operativo y número de compilación - ¿el dispositivo ejecuta una versión de SO compatible? Nivel de parches - ¿se han aplicado los parches críticos y de alta gravedad en un plazo definido, normalmente 30 días? Estado de antivirus o de detección y respuesta de endpoints - ¿hay algún producto de seguridad reconocido instalado, en ejecución y con firmas actualizadas? Firewall basado en host - ¿está habilitado? Cifrado de disco - ¿está activo BitLocker o FileVault? 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 surge de implementar estos sistemas en entornos de hostelería, retail y sector público. En primer lugar, empiece por la visibilidad antes de aplicar medidas de control. Antes de configurar los controles de estado de seguridad en modo de bloqueo, ejecútelos en modo de solo monitorización durante al menos cuatro semanas. Esto le proporcionará un punto de partida de cómo es realmente su parque de dispositivos: qué porcentaje de dispositivos no cumplen los requisitos, qué atributos de estado de seguridad fallan con más frecuencia y si los umbrales de sus políticas están calibrados correctamente. Pasar directamente a la aplicación de medidas sin este punto de partida es el error más común y suele traducirse en una oleada de solicitudes 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 de seguridad. Necesita como mínimo tres segmentos de red: una VLAN corporativa de acceso total para dispositivos gestionados que cumplen los requisitos, una VLAN de correcció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 estado de seguridad pero que necesitan un acceso limitado a recursos específicos mientras se corrigen sus problemas. Planifique estas VLAN de acuerdo con los resultados del estado de seguridad antes de escribir una sola regla de política. En tercer lugar, gestione explícitamente el problema de los dispositivos BYOD y de invitados. En entornos de hostelería en particular - 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 un 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 los 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 plazos de resolución realistas. Cuando un dispositivo no supera la evaluación de postura y se coloca en la VLAN de resolución, debe definir cuánto tiempo tiene para solucionarlo por sí mismo antes de pasar a cuarentena o ser 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 de endpoint activa representa un riesgo más inmediato. En quinto lugar, pruebe a fondo su flujo de Cambio de Autorización. CoA es el mecanismo que mueve un dispositivo de la VLAN de resolución a la VLAN de producción después de que supera la postura. También es el mecanismo que puede mover un dispositivo de vuelta 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 al respecto - 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 monitorice las tasas de éxito de CoA en sus registros de RADIUS tras el despliegue. Ahora, unas palabras sobre las trampas específicas de los entornos de grandes recintos. En un estadio o centro de conferencias con miles de conexiones simultáneas, la evaluación de la postura añade latencia al flujo de autenticación. Las comprobaciones basadas en agentes que requieren que el agente recopile telemetría e informe de ella pueden añadir de dos a cinco segundos al tiempo de conexión. A gran escala, esto es perceptible. Optimice 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, para que la autenticación repetida no active una evaluació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 una evaluación de postura sin desplegar agentes en cada dispositivo? Sí, mediante la integración de la API de MDM para dispositivos registrados y fingerprinting basado en red para otros, pero su cobertura y precisión serán menores que con agentes. Para un entorno mixto, un enfoque híbrido - agentes en dispositivos corporativos, API de MDM para BYOD registrados, fingerprinting de red como alternativa - es la respuesta pragmática. Pregunta: ¿Funciona la evaluación de postura con WPA3? Sí. WPA3 Enterprise utiliza el mismo marco de autenticación 802.1X que WPA2 Enterprise, por lo que la evaluación de postura se integra de la misma manera. El PMF (Protected Management Frames) más robusto de WPA3 y la autenticación SAE complementan la verificación de postura al reforzar la capa de autenticación sobre la que se asienta la postura. Pregunta: ¿Cuál es la diferencia entre la evaluación de postura y NAC? NAC - Network Access Control - es el marco más amplio para controlar qué dispositivos pueden acceder a qué recursos de red. La evaluación de postura es un factor de entrada en la decisión de NAC, específicamente la señal de estado de salud del dispositivo. Se puede tener NAC sin evaluación de postura (por ejemplo, control de acceso basado únicamente en la identidad), pero no se puede tener un control de acceso basado en la postura sin un marco NAC para aplicar 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 postura es la siguiente capa de control: enriquece la decisión de acceso con datos sobre el estado de salud del dispositivo. Para los operadores preocupados por la seguridad, integrar las señales de postura 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 cumplimiento 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 la postura del dispositivo es la práctica de evaluar el estado de 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 la postura. Los tres resultados de la postura (acceso completo, VLAN de remediación y cuarentena) deben diseñarse y probarse antes de habilitar su aplicación. Comience con el modo de monitorización, cree su línea base y luego pase a la aplicación de políticas. Esto no es opcional si desea un despliegue sin problemas. 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 sensata 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 la postura. Evalúe las capacidades de la API de su plataforma MDM para la exportación de datos de postura. Revise las capacidades de política de postura de su servidor RADIUS o plataforma NAC. Y si empieza de cero, considere un enfoque por fases: despliegue primero 802.1X, añada la comprobación de postura en modo de monitorización y luego 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 WiFi Zero Trust, visite la biblioteca de guías de Purple. Si está evaluando el control de acceso basado en la postura 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.