Ir al contenido

Severidad y priorización

Por

Madurezreviewed
Última revisión
Publicado
Última actualización

Las colas de remediación suelen empezar ordenando una columna llamada severity. Es cómodo y también peligroso. Una vulnerabilidad crítica en un componente detenido puede quedar por delante de otra menos severa que está expuesta a Internet, ya se explota en campañas reales y protege una función esencial. La cifra describe una parte del problema. La prioridad nace al combinarla con tiempo, exposición y consecuencias.

El Common Vulnerability Scoring System (CVSS) ofrece un lenguaje común para describir características técnicas. La versión actual es CVSS 4.0. Produce una puntuación entre 0,0 y 10,0 y un vector que conserva las decisiones utilizadas para calcularla.

CVSS 4.0 organiza las métricas en cuatro grupos:

  1. Base. Características intrínsecas de la vulnerabilidad.
  2. Threat. Condiciones que cambian con el tiempo, como madurez o evidencia de explotación.
  3. Environmental. Importancia y controles del entorno consumidor.
  4. Supplemental. Contexto adicional que no modifica la puntuación.

La nomenclatura indica qué grupos participan. CVSS-B usa Base. CVSS-BT añade Threat. CVSS-BE añade Environmental. CVSS-BTE utiliza los tres grupos que modifican la puntuación. Publicar solo 9.8 elimina versión, vector y contexto. Una referencia reproducible conserva algo como CVSS:4.0/... y declara si la cifra es del proveedor, NVD o la organización.

Las métricas de explotabilidad describen la ruta hacia el sistema vulnerable:

  • Attack Vector: Network, Adjacent, Local o Physical
  • Attack Complexity: condiciones de seguridad que deben sortearse
  • Attack Requirements: condiciones de despliegue o ejecución necesarias
  • Privileges Required: privilegios previos del atacante
  • User Interaction: participación necesaria de otra persona

CVSS 4.0 separa el impacto en el Vulnerable System del impacto en Subsequent Systems. Para cada uno considera confidencialidad, integridad y disponibilidad. Esta separación reemplaza el concepto Scope de CVSS 3.1 y hace visible que el fallo puede afectar a sistemas posteriores.

Attack Requirements tampoco es un nuevo nombre para dificultad general. Captura condiciones como una carrera o una posición on-path. Attack Complexity representa la necesidad de superar mecanismos que dificultan la explotación. El tiempo de desarrollo del exploit, la pericia del operador y los controles específicos del cliente pertenecen a otras decisiones.

La métrica Threat Exploit Maturity ajusta la severidad según la evidencia actual de explotación. Su valor puede cambiar después de publicar el CVE. Esa variación obliga a fechar la puntuación.

Environmental adapta las métricas al despliegue. Puede reflejar controles que modifican explotabilidad o impacto y la importancia relativa de confidencialidad, integridad y disponibilidad. La organización conoce esos datos mejor que un proveedor público.

Supplemental aporta atributos como automatización, recuperación, seguridad humana, densidad de valor, esfuerzo de respuesta y urgencia del proveedor. Estas métricas no alteran la puntuación CVSS. Ayudan a otros procesos de decisión.

Feeds, avisos y escáneres todavía muestran CVSS 3.1. Su grupo Base usa Attack Vector, Attack Complexity, Privileges Required, User Interaction, Scope e impactos CIA. Los grupos Temporal y Environmental permiten ajustes posteriores.

No conviertas 3.1 a 4.0 cambiando la cabecera del vector. Las métricas y fórmulas son distintas. Conserva ambas puntuaciones con su versión cuando procedan de fuentes diferentes. Para un hallazgo nuevo, CVSS 4.0 es la referencia actual. CVSS 3.1 mantiene interoperabilidad con datos históricos.

El modelo DREAD tuvo utilidad histórica en threat modeling, pero no debe presentarse como complemento vigente y obligatorio de CVSS ni como el modelo central actual de Microsoft. Si una organización lo usa, documenta su escala y criterios locales.

El Exploit Prediction Scoring System (EPSS) de FIRST estima cada día la probabilidad de que un CVE sea explotado en estado salvaje durante los siguientes 30 días. La puntuación se expresa entre 0 y 1. El percentil indica la posición relativa frente al resto de CVE puntuados.

EPSS responde «¿qué probabilidad observa el modelo?». No mide impacto, criticidad del activo ni riesgo completo. También requiere un CVE. Una configuración insegura sin CVE no recibe EPSS.

La API pública admite una lista de identificadores:

Consultar probabilidad y percentil EPSS
curl --silent --show-error \
'https://api.first.org/data/v1/epss?cve=CVE_ID' |
jq '.data[] | {cve, epss, percentile, date}'

El parámetro cve filtra por CVE_ID. El filtro de jq conserva el identificador, la probabilidad, el percentil y la fecha del modelo. Una puntuación guardada sin fecha pierde significado porque EPSS se recalcula diariamente.

El Known Exploited Vulnerabilities Catalog (KEV) de CISA incluye vulnerabilidades con evidencia de explotación activa. Para agencias federales estadounidenses, la directiva BOD 22-01 añade plazos obligatorios. Para otras organizaciones, KEV es una señal fuerte de priorización.

KEV es binario respecto a la inclusión en el catálogo. No indica que cualquier instancia sea alcanzable, que el exploit funcione contra la configuración local o que la vulnerabilidad ausente del catálogo no se explote. La fecha de incorporación y la acción requerida aportan contexto.

La prioridad de validación y la de remediación pueden diferir. Una detección crítica con evidencia débil quizá necesite validarse pronto. Una condición ya confirmada y expuesta puede exigir remediación inmediata.

Una ficha de priorización conserva:

Dimensión Evidencia
Condición producto, versión, configuración y prerrequisitos
Severidad versión, puntuación y vector CVSS
Amenaza EPSS con fecha, KEV y avisos del proveedor
Exposición Internet, red interna, identidad o ruta necesaria
Activo función, datos, dependencias y propietario
Controles segmentación, mitigaciones y detección
Consecuencia efecto técnico y efecto operativo plausible
Acción validación, mitigación, parche, excepción o retest

Una forma práctica de ordenar sin esconder el razonamiento es crear bandas:

  • Intervención inmediata: condición confirmada, exposición relevante y explotación activa o consecuencia intolerable.
  • Validación prioritaria: señal fuerte pero falta un prerrequisito, una versión o la comprobación del control.
  • Remediación planificada: condición confirmada con exposición limitada o mitigaciones verificadas.
  • Seguimiento: software presente pero componente inactivo, dato insuficiente o dependencia de una actualización futura.
  • Descartado con evidencia: detección refutada mediante una prueba reproducible.

Las bandas necesitan criterios propios y revisión. No se calculan sumando números arbitrarios.

Primer caso: un escáner asigna CVSS 9,8 a una biblioteca instalada. El servicio que la carga está deshabilitado, el paquete del proveedor contiene un backport y la comprobación autenticada no identifica el símbolo vulnerable. El resultado merece documentarse y quizá actualizarse, pero la evidencia no sostiene una vulnerabilidad explotable.

Segundo caso: una interfaz administrativa expuesta utiliza credenciales predeterminadas. No existe CVE y, por tanto, tampoco EPSS. La consecuencia permite administrar el activo. Una cola basada solo en CVE la perdería por completo.

La priorización profesional conserva ambos casos. CVSS organiza severidad. EPSS y KEV enriquecen la amenaza. El inventario y la validación explican el riesgo para este entorno.