cve-y-oval-estandares-de-clasificacion-de-vulnerabilidades

CVE y OVAL — Estándares de Clasificación de Vulnerabilidades

CVE — Common Vulnerabilities and Exposures

CVE es un catálogo público de vulnerabilidades de seguridad conocidas, patrocinado por el Departamento de Seguridad Nacional de los Estados Unidos (DHS). Cada vulnerabilidad recibe un identificador único (CVE ID) asignado por una Autoridad de Numeración de CVE (CNA). El objetivo es crear un estándar universal que permita a herramientas, bases de datos y profesionales referirse a la misma vulnerabilidad con el mismo identificador.

Formato del CVE ID

CVE-AÑO-NÚMERO

CVE-2021-34527   →  PrintNightmare (Windows Print Spooler RCE)
CVE-2020-5902    →  BIG-IP TMUI RCE sin autenticación
CVE-2017-0144    →  EternalBlue (SMBv1 — usado por WannaCry)
CVE-2014-0160    →  Heartbleed (OpenSSL)

Criterios para que una vulnerabilidad reciba un CVE ID

Para ser elegible, la vulnerabilidad debe cumplir tres condiciones:

• Puede solucionarse de forma independiente de otras vulnerabilidades
• Afecta a una única base de código (no múltiples productos simultáneamente)
• Es reconocida y documentada por el proveedor correspondiente

Qué contiene un CVE

Cada entrada CVE incluye:

• Descripción — explicación de la vulnerabilidad y su impacto
• CVSS Score — puntuación de severidad calculada
• Referencias — advisories del proveedor, artículos técnicos, PoCs públicos
• CWE — tipo de debilidad de software (ej. CWE-89 = SQL Injection)
• Estado — si está confirmada, analizada o pendiente de revisión

El proceso de obtención de un CVE ID

Cuando un investigador descubre una vulnerabilidad nueva, el proceso hasta obtener el CVE es:

Etapa	Acción
1. Verificar que no existe	Comprobar en la base de datos CVE que no hay ya un ID para esa vulnerabilidad
2. Contactar al proveedor	Notificar al proveedor del software afectado (divulgación responsable)
3. Identificar la CNA	Si el proveedor es CNA participante, solicitar el ID a través de ellos
4. Formulario web CVE	Si no hay CNA correspondiente, usar el formulario oficial en cve.mitre.org
5. Confirmación	El equipo CVE responde por email y puede solicitar información adicional
6. Recepción del ID	Se asigna el CVE ID (aún no público en este punto)
7. Divulgación coordinada	Se acuerda con el proveedor la fecha pública de divulgación
8. Publicación	El CVE se hace público, coordinado con la publicación del parche
9. Actualización de la NVD	La Base de Datos Nacional de Vulnerabilidades del NIST incorpora el CVE con detalles técnicos completos

Divulgación responsable

La divulgación responsable (responsible disclosure) es el principio ético fundamental de la investigación de vulnerabilidades. Consiste en notificar primero al proveedor del software afectado y darle tiempo suficiente para desarrollar y publicar un parche antes de divulgar públicamente los detalles técnicos.

Si una vulnerabilidad se publica sin avisar al proveedor antes de que haya parche disponible, los atacantes pueden explotarla activamente contra usuarios reales antes de que exista solución. Esto se conoce como zero-day o 0-day — una vulnerabilidad conocida para la que no existe parche en el momento de su divulgación pública.

El plazo estándar aceptado en la industria es de 90 días desde la notificación al proveedor hasta la divulgación pública, independientemente de si el parche está listo o no (política de Google Project Zero).

Ejemplos de CVEs relevantes

CVE-2021-34527 — PrintNightmare

Vulnerabilidad de ejecución remota de código en el servicio Windows Print Spooler. El servicio maneja incorrectamente operaciones de archivos con privilegios elevados. Requiere un usuario autenticado pero permite tomar el control completo del sistema de forma local o remota. Especialmente crítica en entornos de Active Directory porque permite comprometer Domain Controllers.

CVSS Base Score: 8.8 (High)
Attack Vector: Network
Privileges Required: Low
Impact: C:H / I:H / A:H

CVE-2020-5902 — BIG-IP TMUI RCE

Vulnerabilidad de ejecución remota de código sin autenticación en la interfaz de administración (TMUI) de F5 BIG-IP. Cuando la interfaz está expuesta en el puerto de administración, un atacante puede ejecutar código, editar archivos y habilitar o deshabilitar servicios — tomando el control completo del sistema.

CVSS Base Score: 9.8 (Critical)
Attack Vector: Network
Privileges Required: None
Impact: C:H / I:H / A:H

---

OVAL — Open Vulnerability and Assessment Language

OVAL es un estándar internacional de seguridad para evaluar y describir el estado de configuración de sistemas. Cuenta con el respaldo del Departamento de Seguridad Nacional de EE.UU. y es utilizado por el NIST dentro del protocolo SCAP (Security Content Automation Protocol).

Para qué sirve OVAL

En lugar de explotar vulnerabilidades para comprobar si existen, OVAL permite identificarlas sin explotación directa, mediante la comprobación de atributos del sistema (versiones de software, configuraciones, parches instalados). Esto permite auditar sistemas de producción de forma segura.

Las cuatro clases de definiciones OVAL

Clase	Función
Vulnerability Definitions	Identifica vulnerabilidades conocidas en el sistema
Compliance Definitions	Verifica si las configuraciones cumplen las políticas de seguridad
Inventory Definitions	Detecta si hay software específico instalado
Patch Definitions	Verifica si un sistema tiene los parches necesarios

Proceso de evaluación OVAL

El proceso tiene tres pasos:

1. Identificar — detectar la configuración actual del sistema mediante consultas en XML
2. Evaluar — comparar el estado del sistema contra las definiciones OVAL
3. Reportar — generar un informe indicando el estado de cada comprobación

Los estados posibles de cada comprobación son: Vulnerable, Non-compliant, Installed Asset y Patched.

Formato del OVAL ID

oval:ORGANIZACIÓN.DOMINIO:TIPO:NÚMERO

Ejemplo: oval:org.mitre.oval:obj:1116

Tipos (TIPO):
def → definition
obj → object
ste → state
var → variable

OVAL en Nessus

Nessus utiliza OVAL internamente para configurar las plantillas de escaneo de cumplimiento de seguridad (compliance scan templates). Cuando se ejecuta un escaneo de cumplimiento como PCI DSS o DISA STIG, Nessus utiliza definiciones OVAL para verificar las configuraciones del sistema sin necesidad de explotación.

Cómo se relacionan CVE, CVSS y OVAL

Se descubre una vulnerabilidad
         ↓
Se le asigna un identificador único → CVE ID
         ↓
Se calcula su gravedad técnica → CVSS Score (0-10)
         ↓
Se describe cómo detectarla sin explotarla → Definición OVAL
         ↓
Las herramientas como Nessus usan todo esto:
→ CVE ID para identificar el hallazgo
→ CVSS para mostrar la severidad
→ OVAL para las plantillas de compliance

Cuando Nessus reporta un hallazgo, el CVE ID es la referencia para buscar información detallada en la NVD (https://nvd.nist.gov), donde se encuentra la descripción completa, el vector CVSS, los sistemas afectados y las referencias al parche oficial.

Que una vulnerabilidad tenga un CVE no significa que sea explotable en todos los entornos. La presencia del CVE confirma que existe el problema — el CVSS indica su gravedad teórica pero el riesgo real depende siempre del contexto: exposición del sistema, controles compensatorios y criticidad del activo.