En esta segunda parte bajamos a tierra como una criticidad técnica no siempre representa el riesgo real para la organización y, para ello, necesitamos una forma sencilla de ajustarla antes de convertirla en una prioridad.
No se trata de discutir si el informe tiene razón cuando califica un hallazgo como crítico, pues puede tenerla desde el punto de vista técnico, si bien debemos tratar de decidir qué significa ese hallazgo para la organización.
1. El dato técnico no debe desaparecer
Como veníamos hablando, una vulnerabilidad puede permitir ejecución remota de código, escalada de privilegios, acceso a información o modificación de una configuración sensible y el informe debe reflejarlo y la organización debe conservar esa valoración original.
Pero esa severidad no debería trasladarse directamente a la base de riesgos, ni activar de forma automática el SLA más crítico, pues severidad responde a una pregunta concreta:
> ¿Qué podría conseguirse si alguien explota esta vulnerabilidad en las condiciones evaluadas?
Mientras que la criticidad organizativa responde a otra:
> ¿Qué riesgo representa realmente este hallazgo para la organización y con qué urgencia debe tratarse?
Ambos valores son necesarios, pero no significan lo mismo.
La severidad técnica debe conservarse como evidencia y la criticidad de la organización debe calcularse después, aplicando un contexto común a todos los hallazgos.
2. El scope como factor de ajuste
El scope de un test indica desde qué posición se ha realizado la prueba. Puede tratarse de una revisión de la superficie externa Internet, de un pentest interno, de una prueba autenticada con una cuenta de usuario o de un ejercicio que parta de permisos administrativos proporcionados por la propia organización.
Y ese dato es importante porque permite entender qué pasos ha tenido que completar el atacante simulado antes de explotar la vulnerabilidad, de forma que si un hallazgo se descubre en una aplicación interna, el escenario no empieza en el hallazgo, pues antes de llegar a ella, un atacante real tendría que haber superado alguna barrera previa:
– Obtener acceso a la red corporativa.
– Comprometer un equipo interno.
– Disponer de una cuenta válida.
– Conectarse mediante VPN.
– Llegar al segmento de red correspondiente.
– Contar con los permisos necesarios.
Por tanto, una vulnerabilidad técnicamente crítica identificada en una aplicación interna no representa, por defecto, el mismo riesgo que una vulnerabilidad crítica accesible directamente desde Internet y la diferencia no está en que una sea grave y la otra no, sino en la posición que ocupa cada una dentro de la cadena de ataque.
El scope no debe utilizarse de manera automática o ciega, pues un pentest interno no demuestra por sí solo que una aplicación no esté expuesta desde el exterior, pues la exposición debe validarse con la arquitectura real del entorno. Sin embargo, una vez confirmada esa condición, la posición de acceso se convierte en un factor de ajuste objetivo y fácil de aplicar.
3. Sin inventar la rueda
La metodología puede funcionar con tres datos y una única regla de cálculo:
– Severidad técnica original.
La severidad técnica se conserva exactamente como aparece en el informe.
Crítica | 4 |
Alta | 3 |
Media | 2 |
Baja | 1 |
Este valor no se corrige ni se sustituye porque si una vulnerabilidad es crítica técnicamente, seguirá siendo crítica técnicamente aunque, después de aplicar contexto, se clasifique como alta desde una perspectiva corporativa.
– Exposición real del activo.
Accesible desde Internet sin autenticación | 0 |
Accesible desde Internet con autenticación | -1 |
Accesible solo desde red interna o VPN corporativa | -1 |
Requiere acceso local, privilegios elevados o un segmento muy restringido | -2 |
El ajuste no pretende valorar la dificultad técnica de la vulnerabilidad, pues representa los controles y condiciones que un atacante necesita superar antes de llegar a ella.
Un activo accesible desde Internet sin autenticación no recibe ajuste porque la vulnerabilidad se encuentra en el punto de entrada inicial, mientras que una aplicación interna recibe un ajuste de menos uno porque un atacante necesita haber comprometido previamente otra capa del entorno.
– Esencialidad del servicio
Esencial para clientes, operaciones, obligaciones regulatorias o continuidad de negocio | +1 |
Relevante para la organización | 0 |
Auxiliar o con impacto limitado | -1 |
Residual, de pruebas, en retirada o sin información relevante | -2 |
Un servicio es esencial cuando su compromiso puede afectar directamente a clientes, pagos, operaciones, identidad corporativa, información especialmente sensible, continuidad de negocio o una obligación regulatoria relevante.
4. El cálculo
La fórmula es la siguiente:
\[Criticidad\ de la org =
Severidad\ técnica +
Ajuste\ de\ exposición + Ajuste\ de\ importancia\]
El resultado se limita a una escala entre uno y cuatro.
Por ejemplo, si una vulnerabilidad es crítica desde el punto de vista técnico, pero se encuentra en una aplicación interna que soporta un servicio relevante, el cálculo sería:
\[4 – 1 + 0 = 3\]
5. Los otros ajustes
Como toda regla útil, esta necesita una excepción muy concreta.
Un hallazgo interno puede mantenerse como crítico si permite comprometer un elemento transversal cuyo impacto alcance a una parte relevante de la organización.
Por ejemplo:
– Un directorio corporativo o servicio central de identidad.
– Una plataforma de administración de infraestructura.
– Un repositorio de secretos, certificados o claves de acceso.
– Un sistema con capacidad de controlar múltiples entornos.
– Un componente que permita modificar operaciones financieras.
En estos casos, el problema ya no es únicamente una vulnerabilidad en una aplicación interna, sino la posibilidad de obtener una capacidad de control que afecte a múltiples activos, usuarios o procesos.
Con esto, la organización puede establecer SLA coherentes, donde los hallazgos críticos corporativos se reservarán para situaciones con exposición directa o alcance transversal real, mientras que los hallazgos altos incluirán vulnerabilidades graves en entornos internos que requieren acceso previo, pero que deben tratarse con prioridad.