Un CVE identificado pero sin patch disponible es especialmente peligroso. Ejemplo: Log4Shell fue descubierto y parcheado rápidamente, pero organizaciones sin actualizar durante semanas fueron atacadas. Monitorear vulnerabilidades sin parches conocidas es crítico.
Qué es CVE
CVE (Common Vulnerabilities and Exposures) es un identificador único y estandarizado para vulnerabilidades de seguridad públicamente conocidas. Ejemplos: CVE-2021-44228 (Log4Shell, vulnerabilidad crítica en librería Log4j), CVE-2020-1938 (fallo en Apache Tomcat). Cada CVE tiene un número único (año-secuencial: CVE-2021-44228 es la vulnerabilidad 44.228 de 2021), descripción, afectados, severidad (CVSS), y enlaces a patches. La base de datos de CVE (National Vulnerability Database - NVD) es mantenida por NIST y es el registro público de vulnerabilidades. Para un CISO, conocer CVEs relevantes y priorizar parches es función crítica: una vulnerabilidad con CVE conocida y explotable activamente (como Log4Shell) requiere acción inmediata.
Por qué importa
Para un CISO, CVE es el lenguaje común de vulnerabilidades. Cuando alguien dice 'hemos sido afectados por CVE-2021-44228', todos entienden exactamente qué vulnerabilidad es. Sin CVE, cada vendedor usaría nombres distintos (Log4Shell vs. Log4j Deserialization RCE), causando confusión. CVEs permiten: (1) Automatización: herramientas scanean software buscando CVEs conocidos, (2) Priorización: CVEs tienen puntuación CVSS que ayuda a decidir urgencia, (3) Inteligencia compartida: si un CVE está siendo explotado activamente, organizaciones lo saben rápidamente. El ciclo típico es: se descubre vulnerabilidad, se asigna CVE, se publica en NVD, vendedor crea patch, scanner detecta que tu versión es vulnerable, tu equipo prioritiza parche. Sin este sistema, cada organización operaría aislada.
Puntos clave
Existen CVEs 'conocidos pero no explorados' (poco ataques) vs. 'conocidos y explotados activamente' (ataques frecuentes). Tu priorización debe considerar ambos: severidad técnica (CVSS) + inteligencia de amenazas (¿se está explotando?).
No todos los CVEs afectan tu infraestructura. Una vulnerabilidad en librería PHP no te afecta si no usas PHP. La automatización (scanners) detecta qué CVEs son relevantes para tu stack específico.
El número de CVEs crece exponencialmente. Decenas de CVEs públicos cada día. Es infeasible revisar todos manualmente. Automatización + inteligencia de amenazas para filtrar qué es crítico para ti es la única forma.
Ejemplo: respuesta a CVE crítico (Log4Shell)
Diciembre 2021: se descubre CVE-2021-44228 (Log4Shell) en Log4j, librería de logging ubiqua usada en millones de aplicaciones. Severidad CVSS 10 (máxima). Exploitable remota sin autenticación. Afecta: aplicaciones Java, servidores web (Apache, Tomcat), servicios en cloud. Día 1: se publica el CVE, NVD asigna CVSS 10. Inteligencia de amenazas: ataques activos en internet, botnets intenta explotar. Un CISO implementa: (1) Scan inmediato: identifica qué aplicaciones usan Log4j y qué versiones. Descubre 15 aplicaciones afectadas. (2) Priorización: 5 son críticas (internet-facing), 10 son internas. (3) Patching urgente: las 5 críticas, patcheadas en 4 horas. (4) Las 10 internas, parcheadas en 24 horas. (5) Verificación post-patch: confirmación que parche funcionó. (6) Auditoría: checar logs si fue explotado antes del parche. Sin automatización y priorización clara, la respuesta sería caótica: 'tenemos 1000 componentes, ¿cuáles afectan? No sabemos, déjame revisar manualmente.' La brecha ocurriría en horas.
Errores habituales
- Intentar 'vigilar' todos los CVEs publicados sin priorización. Se publican decenas diarios. La mayoría no te afecta. Usar herramientas para filtrar: escanea qué CVEs afectan TU stack, no todo el internet.
- Asumir que CVSS es la única métrica para priorización. CVSS 10 es grave, pero CVE con CVSS 6 explotado activamente es más urgente que CVSS 10 teórico sin ataques. Combina CVSS + threat intelligence.
- No diferenciar entre 'CVE descubierto' vs. 'CVE parche disponible'. Una vulnerabilidad sin parche requiere controles mitigantes (segregación, WAF, monitoreo de comportamiento). Esperar infinitamente por parche no es opción.
- Negligencia post-parche. Después de aplicar parche, muchas organizaciones asumen el problema está resuelto sin verificar que el parche se aplicó correctamente y que la vulnerabilidad no se explota ya en logs.
Términos relacionados
Servicios relacionados
Este concepto puede tener relación con servicios como:
Preguntas frecuentes
¿Qué significa el número en un CVE (por ejemplo, CVE-2021-44228)?
CVE-YYYY-NNNNN donde YYYY es el año de publicación y NNNNN es número secuencial. CVE-2021-44228 significa publicado en 2021 y fue la vulnerabilidad 44.228 de ese año. El número no indica severidad ni importancia, solo identificación única.
¿Dónde encontrar información sobre un CVE específico?
National Vulnerability Database (NVD - nvd.nist.gov) es la base de datos oficial de NIST. Ahí encontrarás descripción, CVSS, afectados, referencias a patches. También puedes usar cve.mitre.org que es el registro oficial de CVEs.
¿Cuál es la diferencia entre CVE, CVSS y CWE?
CVE identifica vulnerabilidad específica. CVSS califica severidad (0-10). CWE es la categoría de fallo (Cross-Site Scripting es CWE-79). Un CVE tiene una puntuación CVSS y corresponde a una o más categorías CWE.
¿Cuánto tiempo tengo que parar parchear un CVE crítico?
CISA (Cybersecurity and Infrastructure Security Agency) recomienda 6 horas para CVEs críticos explotados activamente, 24 horas para críticos sin exploración activa. En práctica, depende de criticidad de tu sistema: componente internet-facing crítico, parche en 4-6 horas; sistema interno, puede esperar 48 horas.