Después de planificar y ejecutar CIS Controls viene la pregunta que más se esquiva en las reuniones con el directorio: ¿cómo sabemos cuánto hemos avanzado y si el avance es suficiente? La respuesta que más se da es "tenemos implementado el X% de los controles." Y esa respuesta, por sí sola, no sirve para tomar decisiones.
El porcentaje de cumplimiento es un indicador de actividad, no de riesgo. Decirle al directorio que se tiene el 80% de CIS Controls implementado no les dice nada sobre cuáles son el 20% que falta, si ese 20% cubre los vectores de mayor riesgo para la organización, o si el 80% implementado realmente está funcionando en producción o solo está documentado.
Hoy desarrollamos qué medir, cómo reportarlo y por qué la forma en que se presenta la madurez de CIS Controls determina si el directorio toma decisiones de inversión o simplemente asiente y sigue adelante.
¿Por qué el porcentaje de cumplimiento solo no es suficiente?
El porcentaje de cumplimiento responde a la pregunta "¿cuánto hemos implementado?" pero no responde a las preguntas que realmente importan para el directorio: "¿cuánto riesgo hemos reducido?", "¿qué riesgo queda pendiente?", "¿en qué deberíamos invertir primero para reducir más riesgo con los recursos disponibles?"
Un ejemplo concreto: una organización que tiene el 90% del IG1 implementado pero tiene el Control 11 (recuperación de datos) sin verificar en condiciones reales, y el Control 6 (control de acceso) con MFA implementado solo en el 40% de los accesos administrativos, no tiene una postura de seguridad del 90%. Tiene una postura del 90% en papel con brechas críticas activas. El porcentaje agrega y oculta al mismo tiempo.
En TechCorp Latam, después del incidente, el primer cambio en la forma de reportar fue precisamente este: se dejó de reportar el porcentaje global y se empezó a reportar el estado de los controles críticos de forma individual, con su nivel de implementación real verificado, la fecha de la última verificación y el riesgo residual asociado a las brechas existentes. Eso transformó los reportes de ciberseguridad de documentos informativos en herramientas de decisión.
Los indicadores que el directorio sí puede usar
Hay cuatro tipos de indicadores que tienen valor real en el reporte ejecutivo de madurez de CIS Controls. Cada uno responde una pregunta distinta y combinados ofrecen una vista completa de la postura de seguridad:
Indicador de cobertura por grupo de implementación. No el porcentaje global, sino el desglose por IG1, IG2 e IG3, con distinción entre "implementado y verificado", "implementado sin verificar" y "no implementado." Este indicador le dice al directorio en qué nivel de madurez está la organización y qué queda para completar cada nivel. En entornos con Fortinet centralizado, la verificación de muchos controles del IG1 puede documentarse directamente desde FortiManager, lo que hace que el reporte sea más ágil.
Indicador de controles críticos con brecha activa. Una lista corta, máximo cinco, de los controles con mayor impacto potencial que todavía tienen brechas significativas. Con el riesgo residual expresado en términos operacionales, no técnicos. No "el Control 6 tiene cobertura de MFA del 60%." Sino "el 40% de los accesos administrativos a la infraestructura crítica no tiene segundo factor de autenticación; si esas credenciales son comprometidas, el acceso es indetectable." Eso genera una conversación de decisión, no de información.
Indicador de tendencia trimestral. ¿El nivel de madurez subió, bajó o se mantuvo respecto al trimestre anterior? La tendencia es más informativa que el nivel absoluto. Una organización que sube consistentemente del 60% al 70% al 80% en IG1 está mostrando capacidad de ejecución sostenida. Una que se estanca en 75% durante tres trimestres consecutivos tiene un problema de ejecución que merece atención, independientemente del nivel.
Indicador de verificación de controles críticos. Fecha de la última prueba real de cada control crítico, especialmente el Control 11 (recuperación de backups) y el Control 17 (simulacro de respuesta a incidentes). Si el Control 11 no ha sido probado en los últimos 90 días, esa fecha en el reporte es más informativa que cualquier porcentaje de cumplimiento.
¿Cómo TechCorp Latam cambió su modelo de reporte?
Antes del incidente, los reportes de ciberseguridad de TechCorp Latam eran técnicos, densos y orientados al equipo de TI. Número de alertas procesadas, intentos de intrusión bloqueados por el FortiGate perimetral, actualizaciones de firmware aplicadas. Información válida para el equipo técnico, sin utilidad para el directorio.
Después de la implementación de CIS Controls, el modelo de reporte cambió completamente. El reporte mensual al comité de ciberseguridad, con reporte trimestral a la junta directiva, tenía un formato de una página con cuatro secciones: estado de madurez por nivel IG, controles críticos con brecha activa y su impacto operacional potencial, acciones completadas en el período y próximas acciones con responsable y fecha, y estado de las verificaciones de controles críticos, especialmente backups y accesos privilegiados en la infraestructura Fortinet.
Ese cambio de formato produjo dos resultados concretos. Primero, el directorio empezó a hacer preguntas específicas sobre los controles con brecha activa en lugar de preguntas genéricas sobre si "estaban bien." Segundo, las solicitudes de inversión en ciberseguridad dejaron de ser rechazadas por falta de contexto y empezaron a evaluarse como decisiones de riesgo con información suficiente para decidir.
Lo que el Service Delivery Manager puede aportar al modelo de medición
El Service Delivery Manager tiene una perspectiva que complementa directamente el modelo de medición de CIS Controls: la visión sobre los niveles de servicio y el impacto operacional de las brechas de seguridad. Esa perspectiva es exactamente lo que convierte un indicador técnico en un indicador de negocio.
Cuando el Control 11 tiene una brecha porque los backups no han sido verificados en 120 días, el Service Delivery Manager puede cuantificar ese riesgo en términos de SLA: si ocurre un incidente que requiera recuperación de backups no verificados, ¿cuánto tiempo de servicio se perdería? ¿Qué cláusulas contractuales se activarían? ¿Qué impacto operacional tendría para los clientes internos o externos? Esa traducción, de brecha técnica a impacto de servicio, es el puente que el directorio necesita para tomar la decisión correcta.
Mañana cerramos la serie con el post más práctico: pre, durante y post auditoría de CIS Controls. Qué preparar antes, qué esperar durante el proceso, y qué hacer con los hallazgos después para que la auditoría produzca mejora real y no solo un informe.
Mañana: el cierre de la serie con la auditoría completa
Suscríbete al newsletter Cybersecurity Insights en LinkedIn para recibir el último post de la serie directamente.
#CISControls #Ciberseguridad #GestiónDeRiesgos #CIO #ITManager #Fortinet #Cisco #WatchGuard #pfSense #ISO27001 #NISTCSF #TechCorpLatam #Métricas #CyberLeadership #Chile
Comentarios
Publicar un comentario