Riesgo, amenazas y vulnerabilidades
Estos términos describen partes diferentes de un mismo problema. Usarlos como sinónimos impide priorizar correctamente.
Modelo mínimo
Sección titulada «Modelo mínimo»| Concepto | Significado | Ejemplo |
|---|---|---|
| Activo | Algo con valor que debe protegerse | Datos de clientes, disponibilidad de un servicio o reputación |
| Amenaza | Circunstancia o evento capaz de causar daño | Un actor, un error humano, un incendio o un fallo de proveedor |
| Vulnerabilidad | Debilidad que una amenaza puede aprovechar | Software sin parchear, permisos excesivos o un proceso incompleto |
| Impacto | Consecuencia si el evento ocurre | Pérdida de datos, interrupción, fraude o sanción |
| Probabilidad | Posibilidad de que el escenario ocurra | Depende de exposición, capacidad del actor y controles existentes |
| Riesgo | Incertidumbre sobre el efecto que un escenario tendría en los objetivos | Combinación contextual de probabilidad e impacto |
Una vulnerabilidad no equivale automáticamente a compromiso. Para que exista un escenario viable hacen falta un activo expuesto, una amenaza con oportunidad suficiente y una consecuencia relevante. Del mismo modo, una amenaza puede existir sin que el riesgo sea alto si los controles reducen suficientemente su probabilidad o impacto.
Cómo formular un escenario de riesgo
Sección titulada «Cómo formular un escenario de riesgo»Una formulación útil conecta todos los elementos:
Debido a una amenaza, podría explotarse una vulnerabilidad sobre un activo, provocando un impacto.
Por ejemplo, debido al robo de credenciales, un tercero podría aprovechar la ausencia de autenticación multifactor (MFA) en el acceso remoto y consultar expedientes. El resultado sería una brecha de confidencialidad con posibles obligaciones de notificación.
Esta formulación es más útil que “hay riesgo de phishing” porque permite decidir si hay que reducir la exposición, la probabilidad de éxito, los privilegios alcanzables o el impacto.
Un identificador CVE da un nombre común a una vulnerabilidad publicada. Sirve para localizar su registro y las referencias asociadas, pero no demuestra que un sistema concreto esté afectado, sea alcanzable o pueda explotarse en sus condiciones actuales. Tampoco expresa por sí solo el riesgo para la organización.
Tratamiento y riesgo residual
Sección titulada «Tratamiento y riesgo residual»El riesgo inherente es el nivel de riesgo antes de considerar los controles aplicados al escenario. Sirve como punto de partida para comparar cuánto reducen esos controles la probabilidad o el impacto.
Las respuestas habituales son:
- Evitar la actividad que origina el riesgo.
- Mitigar probabilidad o impacto mediante controles.
- Transferir o compartir parte de la consecuencia, por ejemplo mediante contratos o seguros.
- Aceptar el riesgo de forma explícita y dentro de la tolerancia definida.
Los controles rara vez eliminan toda incertidumbre. El riesgo que permanece después de aplicarlos es el riesgo residual y también requiere una decisión responsable.
Cómo se convierte una observación en un hallazgo
Sección titulada «Cómo se convierte una observación en un hallazgo»Durante un pentest no basta con reconocer una versión o una configuración potencialmente vulnerable. Para que la observación pueda priorizarse y corregirse, el hallazgo debe incluir:
- activo y alcance afectados
- condición vulnerable comprobada
- camino de explotación razonable
- controles que limitan o agravan el escenario
- impacto técnico y de negocio
- evidencia reproducible y una recomendación proporcionada
La evaluación de vulnerabilidades explica cómo pasar de observaciones a hipótesis y cómo validarlas sin confundir una coincidencia de versión con una vulnerabilidad demostrada.
Preguntas de repaso
Sección titulada «Preguntas de repaso»- ¿Puede existir una vulnerabilidad sin un riesgo material?
- ¿Por qué un identificador CVE no basta para describir el riesgo de un servidor?
- ¿Qué diferencia hay entre riesgo inherente y residual?