Ir al contenido principal

¿Cómo medir la madurez de CIS Controls? Serie: CIS Controls — Post 4 de 5

SERIE CIS CONTROLS · POST 4 DE 5 Métricas · Caso de Estudio · TechCorp Latam ¿Cómo medir la madurez de CIS Controls? Métricas e indicadores para el directorio ¿Por qué el porcentaje de cumplimiento solo no es suficiente? y qué indicadores realmente cambian la conversación ejecutiva. IG1 — Implementación 90% IG2 — Implementación 70% IG3 — Implementación 40% LB Luis Bolívar Service Delivery Manager Senior · Cybersecurity Insights #CISControls

Serie CIS Controls — Post 4 de 5: métricas e indicadores que el directorio sí puede usar para tomar decisiones.

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.

La distinción que cambia el reporte: Un control "implementado" puede significar tres cosas muy distintas: existe la política documentada, existe la configuración técnica activa, o existe la configuración técnica activa y verificada con evidencia en producción real. Solo el tercero reduce riesgo real. El reporte de madurez debe distinguir entre estos tres niveles.

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.

El dashboard ejecutivo que funciona: Una sola página con cinco elementos: nivel de madurez por grupo IG (con semáforo verde/ámbar/rojo), lista de controles críticos con brecha activa y riesgo residual, tendencia trimestral en gráfico simple, fecha de última verificación de los controles críticos, y próximas tres acciones con fecha y responsable asignado. Eso es todo lo que el directorio necesita para tomar decisiones informadas sobre inversión en ciberseguridad.

¿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.

El cambio más importante no fue técnico: Fue la decisión de construir el reporte para la audiencia correcta. Un reporte de madurez de CIS Controls diseñado para el equipo técnico tiene valor interno. Un reporte diseñado para el directorio tiene valor estratégico. Los datos son los mismos; la forma de presentarlos determina si generan decisiones o solo generan archivos.

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

Entradas más populares de este blog

¿Por qué CIS Controls antes que cualquier otra cosa? Serie: CIS Controls — Post 1 de 5

SERIE CIS CONTROLS · POST 1 DE 5 Estrategia · Liderazgo en TI ¿Por qué CIS Controls antes que cualquier otra cosa? El argumento estratégico para empezar por donde el riesgo es mayor, no por donde el proceso es más visible. Priorización por riesgo No todos los controles valen lo mismo Lenguaje de negocio Traduce técnica en riesgo medible Complementa ISO 27001 Donde la norma dice qué, CIS dice cómo LB Luis Bolívar IT Manager · Cybersecurity Insights #CISControls #Ciberseguridad Serie CIS Controls — Post 1 de 5: el argumento estratégico para empezar por donde el riesgo es mayor. Cuando TechCorp Latam implementó CIS Controls por primera vez, lo hizo después de un ransomware que comprometió el 65% de sus servidores. No fue una decisión estratégica planificada; fue un...

NIST CSF 2.0 — IDENTIFY: Conoce tus activos antes de protegerlos

NIST CSF 2.0 — IDENTIFY: Conoce tus activos antes de protegerlos Serie · Post 2 de 6 🔍 Función ID — IDENTIFY NIST CSF 2.0 — IDENTIFY: Conoce tus activos antes de protegerlos No puedes proteger lo que no sabes que tienes. IDENTIFY es el mapa que toda organización necesita antes de implementar cualquier control de seguridad. Analizamos sus 3 categorías y construimos el inventario de TechCorp Latam. 📅 Publicación 2 de 6 ⏱ Lectura: ~10 min 🏢 TechCorp Latam · Inventario desde cero El error más costoso en ciberseguridad: proteger sin saber qué tienes Imagina contratar una empresa de seguridad para custodiar tu edificio, pero nadie te da el plano del edificio. ¿Cuántas entradas hay? ¿Dónde están los archivos más valiosos? ¿Qué puertas dan al exterior? Sin ese plano, la seguridad es aleatoria. Exactamente eso ocurre cuando una organización invierte en firewalls, antivirus y monitoreo sin haber hecho antes un trabajo sistemático de identif...

NIST CSF 2.0 — RESPOND: Actuar cuando el incidente ya ocurrió

NIST CSF 2.0 — RESPOND: Actuar cuando el incidente ya ocurrió Serie · Post 5 de 6 🚨 Función RS — RESPOND NIST CSF 2.0 — RESPOND: Actuar cuando el incidente ya ocurrió Todo lo que TechCorp Latam construyó en GOVERN, IDENTIFY, PROTECT y DETECT llegó a su momento de verdad: un ataque de ransomware real. Esta es la historia de cómo respondieron, qué salió bien y qué lección pagaron caro. 📅 Publicación 5 de 6 ⏱ Lectura: ~12 min 🏢 TechCorp Latam · El momento de la verdad El momento para el que todo lo anterior te prepara Llevan cuatro funciones construyendo su programa. Tienen gobernanza, inventario de activos, controles activos y visibilidad de red. Y aun así, el incidente ocurre. Porque esa es la realidad del riesgo cibernético: los controles reducen la probabilidad, no la eliminan . El objetivo de un programa maduro de ciberseguridad no es hacer que los incidentes sean imposibles — es hacer que sean contenibles, detectables y recuper...