CompTIA SY0-701: Gestión de Vulnerabilidades y Gestión de Parches — Guía de estudio
Forma parte de la CompTIA Security+ SY0-701 — Guía de estudio. Practica con respuestas verificadas en el centro de exámenes de CompTIA, o realiza tests cronometrados en ExamRoll.io.
La gestión de vulnerabilidades es el proceso continuo de identificar, clasificar, remediar y verificar las debilidades de seguridad en todo el entorno tecnológico de una organización. No es un proyecto con fecha de finalización, sino una disciplina operativa que debe seguir el ritmo de un panorama de amenazas que produce cientos de nuevos CVE cada semana.
El ciclo de vida de la gestión de vulnerabilidades
El ciclo de vida comienza con el descubrimiento de activos: no puedes proteger lo que no sabes que existe. El escaneo activo (Nessus, Qualys, Rapid7) sondea la red en busca de hosts activos y servicios abiertos. El descubrimiento pasivo (análisis del tráfico de red, registros DHCP, integración con CMDB) detecta activos que los escaneos activos omiten. Los entornos en la nube requieren un descubrimiento basado en API porque el escaneo de red tradicional no enumera funciones sin servidor (serverless), servicios gestionados o contenedores efímeros.
El escaneo sigue al descubrimiento. Los escaneos autenticados proporcionan una visibilidad completa del software instalado, los niveles de parches y las debilidades de configuración. Los escaneos no autenticados son útiles para la evaluación de la superficie de ataque externa, pero omiten la mayoría de las vulnerabilidades. La frecuencia de escaneo debe corresponder al riesgo: activos expuestos a internet semanalmente, servidores internos mensualmente, estaciones de trabajo mensualmente con monitorización continua basada en agentes.
La priorización utiliza CVSS como base, pero debe incorporar contexto. Una vulnerabilidad con CVSS 9.8 en un servidor de desarrollo aislado (air-gapped) es menos urgente que una vulnerabilidad con CVSS 7.5 en un endpoint de autenticación público. Las puntuaciones EPSS, la pertenencia al catálogo KEV, la criticidad del activo y los controles compensatorios ajustan la prioridad efectiva. El objetivo no es parchear todo, sino parchear primero lo correcto.
Las opciones de remediación incluyen la aplicación de parches (preferible), el cambio de configuración (deshabilitar una función vulnerable), el parcheo virtual (regla de WAF que bloquea la explotación), el aislamiento de red o la aceptación formal con justificación documentada. Los SLA de remediación deben definirse y seguirse; las excepciones requieren aprobación y un control compensatorio.
La verificación confirma que la remediación fue efectiva. Un reescaneo después de aplicar el parche confirma que la vulnerabilidad ya no está presente. La verificación a menudo se omite por la presión del tiempo, lo que lleva a situaciones en las que un parche se desplegó pero no se aplicó correctamente, o en las que la vulnerabilidad se remedió en una instancia pero no en otras del mismo nivel (tier).
Operaciones de gestión de parches
La gestión de parches operacionaliza la fase de remediación. Un programa maduro incluye una canalización de prueba de parches: los parches se aplican primero a un entorno de no producción, se validan en cuanto a compatibilidad y funcionalidad, y luego se promueven a producción a través de un proceso de gestión de cambios. Los parches de emergencia para vulnerabilidades activamente explotadas pueden omitir el ciclo completo de pruebas con una aprobación de cambio acelerada.
Windows Server Update Services (WSUS) y Microsoft Endpoint Configuration Manager (MECM/SCCM) son herramientas comunes para gestionar parches de Windows a escala. Los entornos Linux utilizan gestores de paquetes (apt, yum, dnf) combinados con herramientas de automatización (Ansible, Puppet, Chef) para forzar el estado de los parches. Los entornos nativos de la nube utilizan AWS Systems Manager Patch Manager, Azure Update Management o servicios equivalentes.
Los informes de cumplimiento de parches rastrean el porcentaje de activos dentro del SLA para cada nivel de gravedad. Un panel que muestra un 94 % de cumplimiento para parches críticos puede parecer aceptable hasta que te das cuenta de que el 6 % de 10 000 endpoints son 600 sistemas sin parches, cada uno un posible punto de entrada. Los números absolutos importan tanto como los porcentajes.
Gestión de la configuración y líneas base
La gestión de la configuración mantiene los sistemas en un estado conocido y seguro. Las líneas base de configuración definen el estado aprobado para cada tipo de sistema; la detección de desviaciones (drift) identifica las divergencias con respecto a esa línea base. Herramientas como CIS-CAT Pro, OpenSCAP y servicios nativos de la nube (AWS Config, Azure Policy) evalúan continuamente el cumplimiento de la configuración y alertan sobre las desviaciones.
La gestión de cambios gobierna las modificaciones a los sistemas de producción. Cada cambio debe tener una justificación documentada, una evaluación de riesgos, un plan de reversión (rollback) y la aprobación de las partes interesadas apropiadas. Los cambios de emergencia, requeridos fuera de la ventana de cambio normal, siguen un proceso acelerado con una revisión posterior a la implementación. Los cambios no autorizados detectados por las herramientas de gestión de la configuración se tratan como eventos de seguridad hasta que se demuestre lo contrario.
Escenario práctico: Respuesta a Log4Shell bajo presión
Cuando se reveló el CVE-2021-44228 (Log4Shell) el 9 de diciembre de 2021, con una puntuación CVSS de 10.0 y explotación activa a las pocas horas de su divulgación, las organizaciones se enfrentaron a una crisis que puso a prueba todos los aspectos de sus programas de gestión de vulnerabilidades. Una empresa de tecnología con un programa maduro respondió de la siguiente manera: en dos horas, el equipo de seguridad consultó su inventario de activos en busca de todas las aplicaciones Java e identificó 847 sistemas potencialmente afectados. En seis horas, habían confirmado 312 sistemas que ejecutaban versiones vulnerables de Log4j mediante escaneo autenticado. En 24 horas, habían desplegado reglas de WAF que bloqueaban el patrón de cadena ${jndi:} como un control compensatorio temporal en todos los sistemas expuestos a internet. En 72 horas, el 89 % de los sistemas críticos estaban parcheados. El 11 % restante fue aislado en segmentos de red restringidos, a la espera de la aprobación del propietario de la aplicación para las ventanas de aplicación de parches. El éxito del programa dependió de tres requisitos previos de los que carecían muchas organizaciones: un inventario de activos completo y preciso; capacidad de escaneo autenticado; y procedimientos de cambio de emergencia preaprobados que pudieran invocarse sin un ciclo de aprobación de una semana.
← Seguridad de Endpoints · Todos los dominios
Practica estas preguntas → · Práctica cronometrada en ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Aprueba tu examen →