Métricas de riesgo cibernético que el consejo entiende

La mayoría de los informes de seguridad al consejo fallan por la misma razón: responden preguntas que nadie en la sala ha hecho. Diapositivas llenas de correos bloqueados, activos escaneados y recuentos de vulnerabilidades por tramo de CVSS describen lo ocupado que está el equipo de seguridad, no si la organización está más segura que el trimestre anterior. Los consejeros salen alarmados por cifras grandes o tranquilizados por gráficos verdes y, en ambos casos, sin la información que necesitan para decidir.

Un consejo necesita un conjunto pequeño de métricas estables, comparables en el tiempo, ligadas a resultados de negocio y explicables en una frase cada una. En esta guía vemos cuáles cumplen ese papel, cuáles no y cómo presentarlas sin jerga.

Métricas de vanidad frente a métricas de resultado

Las métricas de vanidad cuentan actividad. Suben cuando el equipo trabaja más o cuando las herramientas ven más, se haya reducido o no el riesgo:

• Número de ataques o correos bloqueados.
• Número de vulnerabilidades encontradas o parches desplegados.
• Número de alertas procesadas por el SOC.
• Número de activos escaneados.

Tienen valor operativo, pero a nivel de consejo confunden. Que aumenten las vulnerabilidades encontradas puede significar mejor cobertura, no peor seguridad. Que aumenten los ataques bloqueados no dice nada de los que no se bloquearon.

Las métricas de resultado describen el estado del riesgo y si evoluciona en la dirección correcta:

• ¿Cuánto riesgo explotable existe ahora mismo y está bajando?
• ¿Con qué rapidez cerramos lo que más importa?
• ¿Qué parte del entorno vemos y protegemos realmente?
• ¿Hay algo bajo ataque en este momento?

Un índice de riesgo acotado, con factores explicables

Los consejos están acostumbrados a pocos indicadores de cabecera: ingresos, margen, caja, rating crediticio. La seguridad se beneficia de la misma disciplina. Un único índice de riesgo en una escala acotada (por ejemplo, de 0 a 100) da al consejo una cifra que seguir, comparar trimestre a trimestre y sobre la que fijar una tolerancia.

Un índice acotado solo es creíble si es explicable. Nadie debería tener que confiar en una caja negra. Constrúyelo a partir de unos pocos pilares que entienda alguien no especialista:

• Amenaza activa: ¿hay evidencia de ataque ahora mismo —incidentes confirmados, explotación de nuestras vulnerabilidades, credenciales o accesos nuestros a la venta?
• Explotabilidad: ¿cuántas de nuestras debilidades se sabe que se explotan (CISA KEV) o es probable que se exploten (EPSS)?
• Exposición: ¿cuánto de eso está en sistemas alcanzables desde Internet? Consulta por qué la exposición cambia la prioridad.
• Criticidad: ¿qué importancia tienen para el negocio los sistemas afectados?

Después muestra los factores: las dos o tres cosas que más mueven el índice. «El índice subió de 42 a 55 este trimestre, principalmente por un fallo explotado de VPN en tres pasarelas expuestas a Internet; se parcheó dentro del plazo objetivo» es una frase con la que un consejo puede trabajar.

La tendencia vale más que cualquier foto fija

Una cifra aislada invita a la pregunta equivocada («¿55 está bien?»). La tendencia responde a la correcta: ¿estamos mejorando? Muestra el índice durante al menos cuatro trimestres, marca los hechos que explican los saltos (una adquisición, una nueva clase de vulnerabilidad crítica, un gran programa de remediación) y acuerda de antemano una banda de apetito de riesgo. Cuando la línea sale de la banda, el consejo sabe que debe implicarse; cuando se mantiene dentro, la conversación puede ser breve.

MTTR por nivel, no en promedio

El tiempo medio de remediación es uno de los pocos datos operativos que merece llegar al consejo, siempre que se desglose bien. Una única media lo oculta todo: cerrar rápido miles de hallazgos de bajo riesgo puede dejar una media excelente mientras un fallo explotado en un sistema crítico sigue abierto durante meses.

Reporta el MTTR por nivel de riesgo, frente al SLA de cada nivel: explotado y expuesto, alto, medio, bajo. El titular es el nivel superior: «Las vulnerabilidades explotadas conocidas en sistemas expuestos se cierran en una mediana de N días, frente a un objetivo de M». Nuestra guía sobre SLA de remediación y MTTR profundiza en cómo fijar esos objetivos.

Cobertura: protegido frente a no protegido

Todas las métricas anteriores son tan fiables como la visibilidad que hay detrás. Si un tercio del entorno no está monitorizado, un índice de riesgo a la baja puede reflejar simplemente puntos ciegos. Por eso la cobertura es una métrica de consejo por derecho propio:

• Dispositivos con protección y monitorización frente a dispositivos sin ella.
• Cuentas cloud conectadas frente a las que se sabe que existen.
• Aplicaciones cuyo código se analiza frente al total en producción.

Presentada como «protegido frente a no protegido», se entiende al instante y da al consejo una palanca clara: financiar y exigir cobertura. El debate entre agente y sin agente es, en la práctica, un debate sobre cómo cerrar esta brecha.

Amenaza activa: lo único que no puede esperar

Por último, el consejo debe ver si está pasando algo ahora: incidentes confirmados en investigación, vulnerabilidades de tu entorno explotándose hoy, credenciales filtradas o acceso inicial a la empresa anunciado a la venta. Es la métrica que justifica una conversación fuera de calendario, y su ausencia tranquiliza de verdad cuando la detección que hay detrás es sólida.

Cómo presentarlo sin jerga

• Empieza por la respuesta. Primera diapositiva: índice, tendencia, banda de apetito y tres factores principales.
• Traduce sin vaciar de contenido. Di «un fallo que los atacantes ya están usando, en un sistema accesible desde Internet» en lugar de «una CVSS 9.8 incluida en KEV en un activo expuesto».
• Compárate contigo mismo y con tus objetivos, no con supuestas medias del sector.
• Acompaña cada rojo de una decisión: qué estás haciendo, para cuándo y qué necesitas del consejo (presupuesto, aceptación de riesgo, política).
• Mantén estable el conjunto. Cambiar de métricas cada trimestre destruye la tendencia, que es lo más valioso.
• Muestra el riesgo aceptado de forma explícita. Las decisiones de no corregir deben ser visibles, tener responsable y fecha.
• Vincúlalo a obligaciones cuando proceda: marcos como NIS2 y DORA atribuyen de forma explícita la responsabilidad del riesgo cibernético a los órganos de dirección.

Preguntas frecuentes

¿Debemos mostrar el número de vulnerabilidades? Solo como contexto, y preferiblemente filtrado a lo explotable o expuesto. Los totales en bruto miden sobre todo la cobertura del escáner.

¿Cuántas métricas son demasiadas? Si no cabe en una página con espacio para comentarios, son demasiadas para la vista principal. Deja el detalle en un anexo.

¿Se puede manipular un índice único? Cualquier métrica se puede. Por eso los factores, la cobertura y la tendencia deben mostrarse junto a él.

Cómo ayuda priorIQ.ai

BoardIQ es el cockpit ejecutivo pensado para esta conversación: un único índice de riesgo de 0 a 100 construido a partir de cuatro pilares —amenaza activa, explotabilidad, exposición y criticidad— con los factores detrás de cada movimiento, además de KPIs como hallazgos abiertos, dispositivos vulnerables, CVEs explotadas ahora, incidentes activos, parches aplicados y fallidos, y dispositivos protegidos frente a no protegidos, con histórico de tendencia y estado de las fuentes para saber que los datos están completos.

Las cifras proceden de PriorIQ Core, que reconcilia y prioriza los hallazgos de todos los módulos y de tus herramientas actuales, y genera informes en PDF y CSV. Descubre el cockpit o solicita una demo.