Cuando realizamos un análisis de riesgos o un ejercicio de auditoría —ya sea de cumplimiento o de revisión técnica como un ejercico de pentesting— solemos asignar una criticidad a cada hallazgo y hasta aquí todo correcto pero la criticidad no debería describir únicamente la naturaleza técnica de una vulnerabilidad, sino también reflejar el alcance del análisis, la exposición real, los activos afectados, las condiciones necesarias para explotarla y su posible impacto sobre el negocio pues, de lo contrario, la información pierde significado.
1. La criticidad depende del contexto
Imaginemos que, durante una evaluación sobre toda una organización, descubrimos que un atacante puede acceder desde el perímetro externo a sistemas especialmente sensibles. En ese contexto, resulta razonable clasificar el hallazgo como crítico.
Existe exposición directa, el alcance puede ser amplio y las consecuencias podrían afectar a una parte significativa de la empresa.
Ahora pensemos en una vulnerabilidad técnicamente similar localizada en una aplicación interna. Para explotarla, un atacante tendría que disponer previamente de acceso a la red corporativa, contar con determinados permisos y superar otros controles de seguridad.
¿Debemos clasificarla también como crítica?
Puede que sí desde una perspectiva estrictamente técnica, pero no necesariamente representa el mismo nivel de riesgo para la organización.
El problema no está en utilizar la palabra “crítico” dentro del informe, pero sí cuando ese valor se incorpora directamente a una base de datos corporativa y se mezcla con hallazgos procedentes de otros ámbitos, sin conservar ni transformar el contexto en el que fue calculado.
2. Una misma etiqueta para riesgos diferentes
Cuando agregamos los resultados de varias fuentes y alcances, corremos el riesgo de construir una falsa equivalencia, pues dos hallazgos pueden aparecer como críticos y, sin embargo, representar situaciones completamente distintas:
* Uno puede permitir comprometer la organización desde Internet.
* Otro puede requerir acceso previo a una red interna.
* Uno puede afectar a un sistema esencial para el negocio.
* Otro puede encontrarse en una aplicación con pocos usuarios y datos no sensibles.
* Uno puede ser explotable de forma inmediata.
* Otro puede depender de varias condiciones poco probables.
* Uno puede tener consecuencias operativas, legales o económicas graves.
* Otro puede limitarse a un impacto técnico reducido.
Si ambos registros se almacenan simplemente como “críticos”, hemos eliminado precisamente la información necesaria para tomar decisiones, de forma que la etiqueta deja de representar riesgo y pasa a representar únicamente la valoración realizada dentro de un informe concreto.
3. El problema de normalizar sin transformar
Centralizar los hallazgos de seguridad es positivo pues obtener visibilidad, detectar tendencias, asignar responsables y hacer seguimiento de la remediación, pero centralizar no consiste únicamente en copiar resultados de múltiples herramientas e informes dentro de una misma base de datos, pues antes de agregar los datos, es necesario transformarlos.
Un hallazgo debería conservar, como mínimo, información sobre:
* El alcance del ejercicio.
* La exposición del activo.
* La facilidad de explotación.
* Los privilegios necesarios.
* La sensibilidad de la información afectada.
* La importancia del proceso de negocio.
* La existencia de controles compensatorios.
* El impacto técnico.
* El impacto organizativo.
* El nivel de riesgo residual.
Sin esta información, la criticidad se convierte en un dato plano, incapaz de explicar por qué un hallazgo requiere atención inmediata.
4. Cuando los SLA también pierden sentido
Esta inconsistencia se hace especialmente visible al definir acuerdos de nivel de servicio para la remediación.
Supongamos que la política corporativa establece que todos los hallazgos críticos deben resolverse en un plazo máximo de cinco días.
Sobre el papel, la medida parece exigente y adecuada. Sin embargo, si dentro de la categoría “crítico” se mezclan vulnerabilidades perimetrales, debilidades internas, desviaciones de cumplimiento y hallazgos cuya explotación requiere condiciones muy específicas, el SLA empieza a desvirtuarse y los equipos se ven obligados a tratar como equivalentes problemas que no lo son, lo que puede provocar varias consecuencias:
– Saturación de los equipos técnicos.
Demasiados hallazgos aparecen como urgentes y compiten por los mismos recursos.
– Pérdida de credibilidad.
Cuando todo es crítico, los responsables dejan de interpretar la etiqueta como una señal real de emergencia.
– Priorización incorrecta.
Se puede dedicar tiempo a corregir una vulnerabilidad interna compleja mientras permanece abierta otra con exposición directa desde Internet.
– Incumplimientos artificiales.
Los indicadores muestran que la organización no cumple sus plazos, aunque parte del problema se encuentre en el modelo de clasificación.
– Distorsión de las métricas.
El número de vulnerabilidades críticas deja de representar el riesgo real de la empresa.
Un SLA uniforme solo tiene sentido cuando los elementos incluidos dentro de una categoría son razonablemente comparables.
5. La criticidad técnica no es la prioridad empresarial
Para evitar esta confusión, conviene separar distintos conceptos que habitualmente se mezclan:
– Severidad técnica
Describe qué permite hacer, cuál es su impacto técnico y qué dificultad presenta su explotación.
– Riesgo contextual
Tiene en cuenta dónde se encuentra la vulnerabilidad, qué exposición tiene el activo, qué controles existen y qué condiciones deben cumplirse para que se produzca el impacto.
– Prioridad de remediación
Determina cuándo debe corregirse el hallazgo en comparación con el resto de problemas pendientes. Puede incluir factores técnicos, de negocio, regulatorios y operativos.
Una vulnerabilidad puede tener una severidad técnica crítica y, al mismo tiempo, una prioridad de remediación alta o media debido a su contexto, pero también puede ocurrir lo contrario, que es que una vulnerabilidad técnicamente moderada puede requerir una actuación urgente si afecta a un activo especialmente sensible o si existe una explotación activa.
Y no se trata de rebajar artificialmente los hallazgos, sino describirlos correctamente.
6. El objetivo no es tener menos críticos
Puede parecer que este enfoque busca reducir el número de hallazgos críticos para mejorar los indicadores, cuando el objetivo es que desaparezcan las inconsistencias.
Un hallazgo crítico debe seguir siendo crítico cuando representa una amenaza crítica para la organización, pero esa clasificación debe estar respaldada por criterios que permitan entender su urgencia y compararla con otros riesgos, pues las métricas de seguridad solo son útiles cuando conducen a decisiones adecuadas, porque si todo es crítico, nada lo es.
Y si aplicamos los mismos plazos, los mismos indicadores y la misma prioridad a situaciones que no son equivalentes, no estamos gestionando mejor el riesgo, solo estamos almacenando hallazgos.