El séptimo Control CIS ataca lo que, año tras año, es de los vectores de intrusión más usados: las vulnerabilidades sin parchar. Todo software tiene fallas que se van descubriendo con el tiempo, y cada una es una posible entrada. El atacante no necesita que todo esté vulnerable; le basta una falla conocida sin corregir. El Control 7 pide convertir la gestión de vulnerabilidades en un proceso continuo —no un evento anual—: encontrarlas, priorizarlas y taparlas antes de que alguien las use.
Por qué "continuo" es la palabra clave
Se descubren vulnerabilidades nuevas constantemente. Una revisión "de vez en cuando" deja ventanas enormes en las que estás expuesto sin saberlo. Y hay un dato que ordena las prioridades: la explotación de vulnerabilidades conocidas es, según los análisis del sector, uno de los principales caminos de entrada —lo desarrollamos en el parche que no se aplicó—. Lo frustrante es que casi siempre se trata de fallas ya conocidas y con parche disponible: no un ataque genial, sino un parche que nadie aplicó a tiempo.
Qué pide en la práctica
- Escaneo regular de vulnerabilidades: herramientas que revisan tus sistemas buscando fallas conocidas, de forma continua.
- Un proceso de parcheo para sistemas operativos y aplicaciones, que aplique las correcciones en un plazo razonable según la gravedad.
- Priorización: no todas las vulnerabilidades son iguales. Se atienden primero las más críticas y las que ya se están explotando, usando referencias como la puntuación CVSS.
¿Qué salvaguardas incluye el Control 7 en CIS v8?
Son 7 salvaguardas, y a diferencia de otros controles, varias traen frecuencias concretas.
CIS agrupa las salvaguardas en tres grupos de implementación. IG1 es la higiene básica que recomienda para cualquier organización; IG2 suma lo necesario para empresas con más sistemas, personal de TI y datos sensibles; IG3 completa el control para organizaciones con requisitos de seguridad altos.
- IG1 (7.1 a 7.4): un proceso documentado de gestión de vulnerabilidades; un proceso de remediación basado en riesgo; y parcheo automatizado de sistemas operativos y de aplicaciones, con frecuencia mensual o mayor.
- IG2 (7.5 a 7.7): escaneo automatizado de vulnerabilidades en los activos internos al menos cada trimestre; escaneo de los activos expuestos a internet al menos cada mes; y remediación de lo detectado con frecuencia mensual o mayor.
El control no tiene salvaguardas exclusivas de IG3: una empresa en IG2 ya tiene el Control 7 completo.
¿Cómo priorizar cuando el escaneo encuentra cientos de hallazgos?
El primer escaneo suele asustar: cientos o miles de vulnerabilidades. No se atienden por orden de aparición, sino con criterios que se combinan:
- ¿Se está explotando activamente? Las vulnerabilidades con explotación conocida en el mundo real van primero, sin importar su calificación.
- ¿Está expuesto a internet? Una falla media en un equipo publicado pesa más que una alta en un equipo aislado.
- ¿Qué tan crítico es el activo? El servidor del ERP no se prioriza igual que una impresora.
- ¿Cuál es su calificación CVSS? Sirve para ordenar dentro de un mismo grupo, pero por sí sola no decide.
¿Cómo saber si el control funciona?
- Tiempo promedio de remediación por nivel de severidad, contra el plazo que fijaste.
- Porcentaje de equipos con parches al día al cierre de cada mes.
- Vulnerabilidades críticas abiertas por más de 30 días, y el motivo de cada excepción.
¿Qué evidencia pide un auditor para el Control 7?
Si tu empresa busca SOC 2 o ISO 27001, este control no se trabaja dos veces. En la ISO 27001:2022 corresponde a el control 8.8 (gestión de vulnerabilidades técnicas). La evidencia que normalmente se revisa:
- El procedimiento de gestión de vulnerabilidades con los plazos de remediación por severidad.
- Reportes de escaneo de varios meses, que muestren la frecuencia real y no solo una ejecución.
- El reporte de cumplimiento de parches de la herramienta de administración.
- Los tickets de remediación de hallazgos críticos, con su fecha de cierre.
- Las excepciones aprobadas cuando algo no se pudo parchear, con su control compensatorio.
Tener esto organizado desde el principio es lo que convierte el control en algo que se puede demostrar, no solo afirmar. La diferencia entre ambos marcos la explicamos en SOC 2 vs ISO 27001.
El aterrizaje honesto
El obstáculo real no suele ser técnico, sino de disciplina y de miedo: parchar puede romper cosas, así que se pospone... hasta que la falta de parche rompe algo peor. La respuesta no es dejar de parchar, sino hacerlo con método —probar y desplegar por etapas— para no tener que elegir entre estar seguro y estar estable. Este control depende del inventario de software (Control 2): solo parchas lo que sabes que tienes. Un buen punto de partida es un diagnóstico de tu parcheo actual.
Preguntas frecuentes
help ¿Cada cuánto debo escanear en busca de vulnerabilidades?
La recomendación moderna es de forma continua o muy frecuente, no una vez al año, porque las vulnerabilidades nuevas aparecen constantemente y las ventanas de exposición importan. Un escaneo esporádico deja largos periodos ciegos. Lo ideal es un escaneo automatizado y regular, complementado con atención inmediata cuando surge una vulnerabilidad crítica ampliamente explotada.
help ¿Tengo que aplicar cada parche de inmediato?
Lo prudente es priorizar por gravedad y por si la falla ya se está explotando, no aplicar todo con la misma urgencia ni sin pruebas. Los parches críticos de fallas activamente explotadas se atienden con máxima prioridad; el resto sigue un ciclo ordenado que incluye probar antes de desplegar. El objetivo es cerrar rápido lo peligroso sin romper la operación por parchar a ciegas.
help ¿No parchar por miedo a que algo se rompa es razonable?
El miedo es comprensible, pero posponer indefinidamente convierte una vulnerabilidad conocida en una brecha esperando ocurrir. La solución no es evitar el parcheo, sino hacerlo con método: probar los parches en un entorno controlado y desplegarlos por etapas. Así reduces el riesgo de romper algo sin quedarte expuesto. Entre el riesgo de un parche probado y el de una falla sin corregir, el segundo suele ser mucho mayor.
Rubén Espinoza es fundador y Director Técnico de IT Experts de México. Trabaja en la industria de TI desde 1998: diseña y opera soluciones de infraestructura, ciberseguridad, continuidad, automatización y tecnología OT para entornos empresariales e industriales. Escribe desde proyectos reales y sistemas en producción.
Ver perfil y todos sus artículos →