← Volver al inicio

Fundamentos de Gestion de Vulnerabilidades

Objetivo

Entender como una organizacion maneja vulnerabilidades de forma continua. Esto es una ruta laboral realista para perfiles junior.

Gestion de vulnerabilidades no es "correr un scanner". Es un proceso para reducir riesgo de forma continua con inventario, contexto, priorizacion, remediacion y verificacion.

Mapa Mental

activo -> exposicion -> vulnerabilidad -> explotabilidad -> impacto -> prioridad -> remediacion -> verificacion

Una vulnerabilidad tecnica puede ser urgente o no dependiendo del activo, exposicion y contexto.

Que es una Vulnerabilidad

Una vulnerabilidad es una debilidad que puede ser explotada para afectar confidencialidad, integridad o disponibilidad.

Ejemplos:

  • Software sin parche.
  • Configuracion insegura.
  • Contraseña debil.
  • Servicio expuesto innecesariamente.
  • Dependencia vulnerable.

Ciclo de Gestion

  1. Inventario.
  2. Identificacion.
  3. Priorizacion.
  4. Remediacion.
  5. Verificacion.
  6. Reporte.
  7. Mejora continua.

Diferencia Entre Severidad y Riesgo

Severidad tecnica describe que tan grave es una vulnerabilidad en general.

Riesgo real depende del contexto.

Ejemplo:

CasoSeveridadRiesgo real
Critica en servidor expuesto a internetAltaMuy alto
Critica en laboratorio apagadoAltaBajo o medio
Media en sistema con datos sensibles y exploit activoMediaAlto

Inventario

No puedes proteger lo que no conoces.

Un inventario debe incluir:

  • Hostname.
  • IP.
  • Owner.
  • Sistema operativo.
  • Criticidad.
  • Ambiente.
  • Exposicion: internet, interna, restringida.
  • Fecha de ultima revision.

Campos recomendados:

  • tipo de activo;
  • tecnologia;
  • version;
  • owner tecnico;
  • owner de negocio;
  • criticidad;
  • dependencia;
  • ubicacion;
  • tags;
  • estado de soporte.

Identificacion

Fuentes:

  • Escaneos autorizados.
  • Reportes de proveedores.
  • SCA de dependencias.
  • Pentests.
  • Bug bounty.
  • Alertas de seguridad.
  • Config reviews.

CVE, CVSS y EPSS

  • CVE identifica una vulnerabilidad publica.
  • CVSS estima severidad tecnica.
  • EPSS estima probabilidad de explotacion.

No uses una sola metrica. Combina datos tecnicos con contexto del activo.

Priorizacion

No todo se corrige al mismo tiempo. Se prioriza por:

  • Criticidad del activo.
  • Exposicion.
  • Severidad.
  • Explotabilidad.
  • Existencia de exploit publico.
  • Impacto.
  • Compensating controls.

Formula practica:

prioridad = severidad + exposicion + criticidad + explotabilidad - controles compensatorios

No es matematica exacta; es una guia para justificar decisiones.

Remediacion

Ejemplos:

  • Aplicar parche.
  • Cambiar configuracion.
  • Deshabilitar servicio.
  • Restringir acceso.
  • Actualizar dependencia.
  • Rotar credenciales.

Una remediacion debe ser verificable.

Mal:

Mejorar seguridad.

Bien:

Actualizar OpenSSL a version corregida, reiniciar servicio y verificar version en host web01.

Verificacion

Despues de corregir:

  • Re-escanear.
  • Revisar version.
  • Validar configuracion.
  • Confirmar que el riesgo bajo.

Excepciones

A veces no se puede corregir de inmediato. Una excepcion debe incluir:

  • razon;
  • owner;
  • fecha de expiracion;
  • control compensatorio;
  • riesgo aceptado;
  • aprobacion.

Una excepcion sin fecha de expiracion suele convertirse en deuda permanente.

Reporte

Un buen reporte incluye:

  • Resumen ejecutivo.
  • Hallazgos por severidad.
  • Activos afectados.
  • Riesgo.
  • Recomendacion.
  • Responsable.
  • Fecha objetivo.
  • Estado.

Ejemplo de Priorizacion

Un CSV ficticio de ejemplo:

hostname,owner,criticality,exposure,vulnerability,severity
web01,web-team,high,internet,nginx outdated,high
db01,data-team,critical,internal,weak password policy,medium
test01,,low,internal,unknown owner,low

El analisis debe aclarar:

  • Cual corriges primero?
  • Por que?
  • Que informacion falta?
  • Que recomendacion daras?

Criterios Para Priorizar Vulnerabilidades

Esta tabla muestra como cambia la prioridad cuando se combinan exposicion, criticidad, severidad y explotabilidad:

ActivoExposicionCriticidadVulnerabilidadSeveridadExploit publicoPrioridadRemediacion
web01internetaltanginx outdatedaltasi
db01internacriticapassword policy weakmediano
dev01internabajaold packagealtano
vpn01internetcriticaauth bypasscriticasi

Al analizarla, la pregunta central no es cual CVE tiene el numero mas alto, sino que activo puede causar mayor impacto si se explota. Un VPN expuesto a internet con bypass de autenticacion debe subir al inicio aunque existan otros hallazgos tecnicamente severos. Un servidor de desarrollo interno puede esperar si no contiene datos sensibles ni ruta directa hacia produccion.

Errores Comunes

  • Priorizar solo por CVSS.
  • No tener inventario confiable.
  • No saber quien es owner del activo.
  • No verificar remediacion.
  • No registrar excepciones.
  • Confundir "parchado" con "riesgo eliminado" sin comprobar.

Criterio de Dominio

Puedes avanzar cuando puedas:

  • Explicar el ciclo completo.
  • Priorizar con contexto.
  • Diferenciar severidad tecnica y riesgo real.
  • Escribir una remediacion verificable.
  • Justificar una excepcion con fecha, owner y control compensatorio.

En esta página