4. Clasificar las vulnerabilidades
Se recomienda que en esta tarea participen personas con conocimientos de los riesgos de ciberseguridad, de negocio y de la gestión de activos de TI.
El software de evaluación de vulnerabilidades normalmente asignará una clasificación de gravedad a los problemas, la cual es un punto de partida, pero, dado que no toma en cuenta ningún riesgo de negocio o circunstancias atenuantes, no debe tomarse como un resultado definitivo.
Hay que tener en cuenta que la primera vez que se ejecuta un análisis a un sistema, pueden surgir muchas vulnerabilidades. Se debe dedicar tiempo a evaluarlas, basándose en toda la información disponible.
Recomendamos no ignorar los problemas que están marcados como “Críticos” o “Altos”.
El Common Vulnerability Scoring System (CVSS) es un marco abierto para comunicar las características y la gravedad de las vulnerabilidades del software, les asigna puntuaciones numéricas e intenta ayudar en el proceso de clasificación de las mismas. Puede ser una herramienta útil si se usa correctamente, pero hay que asegurarse de:
- No seleccionar una puntuación arbitraria por encima de la cual las vulnerabilidades deban corregirse, ignorando todos los problemas por debajo de ese nivel.
- No tomar puntuaciones CVSS brutas sin tener en cuenta las prioridades o mitigaciones específicas de la empresa.
Se deben clasificar las vulnerabilidades encontradas en tres categorías:
- Corregir
- Reconocer
- Investigar
Las vulnerabilidades a corregir son aquellas para las cuales es necesario aplicar un parche, una reconfiguración o una mitigación. Se debe dar prioridad a estas correcciones y otorgarles una fecha en la cual se implementarán.
Las vulnerabilidades reconocidas son aquellas que se decide que no sean corregidas en lo inmediato. Existen razones válidas para no resolver de inmediato una vulnerabilidad, estas deben registrarse junto con el razonamiento para reconocerla y una fecha de revisión. Si el nivel de riesgo que presentan es suficientemente alto, se debe registrar el problema en una bitácora de riesgos.
El motivo para reconocer un problema y no solucionarlo, debería ser suficiente para justificar la decisión tomada en caso de que la vulnerabilidad explote en el futuro.
Las vulnerabilidades a investigar deben usarse solo como un estado temporal mientras no puedan ser categorizados como “corregir” o “reconocer”. Esto puede deberse a que se desconoce el costo de resolver el problema o que hay varias soluciones posibles y se requiere más tiempo para identificar cuál funciona mejor. El software de evaluación de vulnerabilidades no es infalible y pueden producirse falsos positivos. Cuando se sospeche de un caso se recomienda realizar una investigación antes de eliminar el problema. Los plazos para los problemas de esta categoría dependerán de su potencial gravedad.
La decisión de solucionar o no un problema es, en el fondo, una decisión de negocio y cada organización deberá definirlo.