La lección anterior terminó con una observación incómoda: POL-02 dice que el acceso de terceros «debe ser nominal, con MFA y just-in-time» y POL-04 dice que los equipos «deben mantener activo el cifrado de disco», pero ninguna de las dos frases protege nada por sí misma. Alguien tiene que configurar el MFA, comprobar que los 40 portátiles están cifrados de verdad, verificarlo periódicamente y dejar constancia de que lo verificó. Ese «alguien haciendo algo comprobable» es el control, el tercer vértice del triángulo que cierras aquí: el riesgo dice qué puede pasar, la política dice qué exigimos, y el control es lo que hace que sea cierto. Terminarás con las dos clasificaciones que hay que dominar, el catálogo de controles de Nimbus como artefacto reutilizable, las métricas que distinguen un control implantado de uno eficaz, y la matriz de trazabilidad que salva una auditoría.

1. Qué es exactamente un control y cómo cierra el triángulo
2. Clasificación por naturaleza: administrativo, técnico y físico
3. Clasificación por función: de preventivo a compensatorio
4. Por qué un riesgo necesita controles de varias funciones
5. Catálogos de referencia: CIS v8, ISO 27002 y NIST SP 800-53
6. Cómo se selecciona un control, y el coste que todos olvidan
7. Controles compensatorios: legítimos y excusas
8. El catálogo de controles de Nimbus
9. Implantado no es eficaz: evidencias, pruebas y métricas
10. La matriz de trazabilidad riesgo → control → evidencia
11. Deriva de controles: por qué se degradan solos

Un control de seguridad es una medida concreta, con propietario, que reduce la probabilidad o el impacto de un riesgo y cuyo funcionamiento se puede comprobar. Los tres elementos de esa definición son igualmente obligatorios: si no tiene propietario, no se mantiene; si no reduce ningún riesgo identificado, es decoración; y si no se puede comprobar, no sabrás nunca si sigue funcionando.

Y un matiz de vocabulario que evita confusiones: control, medida y salvaguarda son sinónimos en la práctica. ISO 27002 dice «control», CIS dice «salvaguarda» (safeguard) y NIST dice «control». Lo que sí conviene distinguir es control de herramienta: un antivirus es una herramienta; «malware detectado y contenido en el endpoint, con alerta atendida en menos de 4 horas» es un control. La herramienta sin el proceso alrededor no es un control, es una licencia pagada.

Tres observaciones que valen más que la tabla. Los administrativos suelen ser gratis y son los que más se olvidan: de las 12 medidas de mayor retorno de 02-04, varias de coste nulo son administrativas —el procedimiento de verificación de pagos, la revisión trimestral de accesos de terceros o el plan de respuesta escrito—. Un control técnico sin su administrativo no se sostiene: instalar MFA es técnico, pero decidir en qué cuentas es obligatorio, quién autoriza las excepciones y quién revisa la cobertura es administrativo, y sin eso la cobertura baja sola con cada alta nueva. Y Nimbus tiene poca superficie física, no cero: con media plantilla en remoto, el control físico relevante no es la puerta de la oficina, sino que el portátil de Iván esté cifrado y bloqueado en una cafetería de Valencia.

Esta es la clasificación que de verdad cambia decisiones, porque describe en qué momento del incidente actúa el control.

Dos precisiones sobre las que la gente se equivoca. La primera: disuasorio y preventivo no son lo mismo. Un cartel de «zona videovigilada» disuade; la cerradura previene. En sistemas, el aviso de que la sesión queda grabada disuade al técnico de la consultora de hacer lo que no debe, pero no se lo impide. La segunda: correctivo y recuperativo tampoco lo son. El correctivo elimina la causa —rotas la credencial filtrada—; el recuperativo devuelve el estado —restauras la base de datos—. Recuperar sin corregir te deja restaurando el mismo sistema una y otra vez para el mismo atacante.

Si solo previenes, no te enteras cuando la prevención falla. Y la prevención siempre falla alguna vez: esa es la premisa del principio «asume la brecha» de 01-03. Aplicado al incidente de ransomware de 02-06, el desglose por funciones muestra exactamente dónde estaba el agujero de Nimbus:

Nimbus tenía cero controles en cinco de las seis funciones, y esa es la explicación completa de por qué un incidente evitable se convirtió en catastrófico. Fíjate en el patrón: cada función compra tiempo o daño distinto. La prevención evita el incidente; la detección reduce su duración —la variable que más determina el daño según la conclusión de 02-06—; la recuperación decide si la empresa sobrevive. De ahí la regla práctica: todo riesgo de banda Alta o Crítica del registro de 04-01 debe tener, como mínimo, un control preventivo, uno detectivo y uno recuperativo. Si al rellenar el catálogo una de esas tres casillas queda vacía para un riesgo Crítico, has encontrado tu siguiente tarea sin más análisis.

Usar un catálogo en vez de inventar controles tiene tres ventajas: no se te olvidan categorías enteras, el vocabulario coincide con el de tus clientes y auditores, y cada control trae su justificación escrita. La desventaja es que ninguno está pensado para 38 personas, así que hay que seleccionar.

Los grupos de implementación de CIS son la aportación más útil para una PYME:

Que Nimbus se marque IG1 completo es una decisión defendible, medible y alcanzable, y suena mucho mejor ante un cliente que «tenemos varias medidas». Sus 18 controles, con los que aplican a Nimbus destacados: inventario de activos (1) y de software (2), protección de datos (3), configuración segura (4), gestión de cuentas (5) y de accesos (6), gestión de vulnerabilidades (7), registros de auditoría (8), protecciones de correo y navegador (9), defensa contra malware (10), recuperación de datos (11), gestión de infraestructura de red (12), monitorización (13), formación y concienciación (14), gestión de proveedores (15), seguridad del software (16), gestión de incidentes (17) y pruebas de penetración (18).

Y una advertencia: el catálogo no sustituye a tu evaluación de riesgos. CIS ordena por lo que le pasa a la mayoría; tu registro ordena por lo que te pasa a ti. Parte del riesgo y usa el catálogo para no olvidar nada, no al revés.

El paso 4 es donde se equivocan casi todas las PYMES, porque solo cuentan la licencia. El coste real de un control tiene cuatro sumandos:

Esas 150 horas anuales son un tercio de las 440 que Lucía tiene disponibles para seguridad. Ese es el coste que hunde los proyectos de seguridad en las PYMES: no el dinero, sino que la persona que tenía que hacer las otras once medidas se pasa el año leyendo alertas. La comparación honesta no es «9.600 € frente a 900 € del MFA», sino «9.600 € más un tercio de la capacidad del equipo, frente a 900 € más dos horas al mes». De ahí la regla derivada: prefiere el control que, una vez implantado, no consume tiempo. El MFA, el cierre de un grupo de seguridad, la inmutabilidad de un bucket o WHERE tenant_id son controles que trabajan solos. La revisión manual de registros o la aprobación caso por caso consumen atención para siempre, y la atención es el recurso más escaso de Nimbus.

Un control compensatorio sustituye a un control exigido que no se puede implantar, proporcionando protección equivalente por otra vía. Es legítimo cuando la imposibilidad es real y está documentada, la protección alternativa es comparable en eficacia, está aprobada al nivel adecuado con caducidad —es una excepción de 04-02— y se verifica como cualquier otro control. El caso de Nimbus: la separación de funciones es imposible. El principio de 01-03 exige que quien desarrolla no despliegue en producción sin supervisión, y que quien administra los sistemas no sea la misma persona que revisa sus propios accesos. Con una única administradora de sistemas, eso no se puede cumplir: Lucía crea cuentas, se las asigna, revisa el registro y aprueba sus propios cambios.

Y el contraste, porque la mitad de los controles compensatorios que se ven en la práctica son excusas:

La diferencia es que el legítimo nombra la imposibilidad concreta, describe una protección específica y tiene fecha; la excusa invoca una molestia y ofrece un control genérico que ya existía de todas formas.

Segundo artefacto reutilizable del módulo. Plantilla de campos:

Cuatro controles desarrollados, uno de cada función principal:

El resto del catálogo, en forma resumida:

Tres lecturas del catálogo en conjunto, que es donde está su valor. Primera: contando estados, solo 7 de los 22 controles están implantados, así que cualquier riesgo residual del registro de 04-01 que asuma los otros 15 está mal calculado —recuerda la regla de 04-01: el residual se puntúa sobre el estado verificado—. Segunda: hay 8 controles con función detectiva y solo 2 implantados (C-07 y C-21), que es exactamente la ceguera que produjo los 20 días de 02-06. Tercera: los controles administrativos son casi todos gratuitos y están casi todos «planificados», lo que confirma la conclusión de 02-04 de que a Nimbus no le falta presupuesto, le falta tiempo asignado.

La diferencia no es académica: el MFA activado en 9 de 14 cuentas privilegiadas no reduce el riesgo un 64 %, lo reduce casi nada, porque el atacante irá a una de las 5 restantes. Los controles se miden por cobertura, no por existencia.

Una evidencia es algo que se puede enseñar y que tiene fecha: la exportación de la lista de cuentas con MFA, el informe de la prueba de restauración, el acta de la revisión mensual. Una prueba es el ejercicio deliberado de comprobar que el control actúa: inyectar una transferencia grande para ver si salta C-08, o restaurar de verdad la base de datos para ver si C-14 funciona y cuánto tarda. De ahí la regla que resume el apartado: un control que nunca ha sido probado está en estado «planificado», digan lo que digan sus responsables, y por eso C-08 figura con ultima_verificacion: null.

Un KPI mide si el control funciona; un KRI avisa de que el riesgo está creciendo. Los cuatro indicadores mínimos de Nimbus:

Tres detalles del código que son decisiones de medición, no de programación. El denominador del cifrado excluye los equipos dados de baja, porque incluirlos maquilla el indicador —y elegir el denominador es donde se falsean casi todas las métricas de seguridad—. El MFA se mide incluyendo cuentas de servicio y de terceros: son precisamente ci-deploy, consultora-01 y backup-svc las que faltan, o sea, exactamente el vector de 02-06. Y el parcheo usa la media, que oculta el caso de 14 días; en un panel real conviene acompañarla del percentil 90 o del peor caso, porque el atacante explota el peor caso, no la media.

La tabla de auditoría append-only de los módulos anteriores permite comprobar que C-07 sigue registrando lo que debe:

La primera consulta es la más importante y la que casi nadie escribe: vigila el vigilante. Un control detectivo que deja de emitir eventos falla en silencio, y el silencio se interpreta como calma. La tercera mide la cobertura del control, que es la diferencia entre implantado y eficaz aplicada al registro.

Esta tabla es lo que se enseña en una auditoría, y es lo que la salva (06-04). No porque impresione, sino porque responde en un folio a las tres preguntas que hace cualquier auditor o cliente: qué riesgos has identificado, qué haces sobre cada uno y cómo lo demuestras. Léela también como herramienta de diagnóstico. La columna «Hueco» se rellena sola aplicando la regla del apartado 4 —preventivo, detectivo y recuperativo para todo riesgo Alto o Crítico— y produce la lista de trabajo del trimestre sin ninguna discusión adicional: R-02 no tiene forma de enterarse de que están borrando las copias, R-05 no tiene forma de saber que alguien ha caído en un fraude, y R-06 tiene un control que nadie ha probado nunca.

Un control implantado y verificado hoy no seguirá funcionando dentro de un año si nadie lo mira. No hace falta un atacante: basta con la actividad normal de la empresa.

La conclusión número 2 de los casos de estudio de 02-06 decía que en casi todos los incidentes el control existía y no funcionó: Target tenía alertas, Equifax tenía inspección de tráfico, Colonial tenía VPN. La deriva es el mecanismo por el que eso ocurre, y el antídoto es el campo frecuencia del catálogo. Un control sin frecuencia de verificación no es un control: es un recuerdo de haber hecho algo.

• Confundir herramienta con control. Comprar un EDR no es tener defensa contra malware; es tener una licencia. Consejo: define cada control por el resultado observable, no por el producto.
• Implantar sin propietario. Los controles huérfanos son los primeros en derivar. Consejo: el campo propietario es una persona, y si no hay candidato, el control no está listo para implantarse.
• Puntuar el riesgo residual con controles no verificados. Es el enlace directo con el error equivalente de 04-01. Consejo: estado: Implantado exige ultima_verificacion con fecha.
• Acumular solo controles preventivos. Es la desproporción de Nimbus, con 8 controles detectivos de los que solo 2 están implantados, y la causa de los 20 días de ceguera de 02-06. Consejo: revisa el catálogo por función, no por riesgo.
• Olvidar la carga operativa. Un control que consume 150 horas al año se abandona en el mes cuatro y queda en el catálogo como implantado. Consejo: incluye el coste recurrente en la decisión y prefiere lo que trabaja solo.
• Métricas con denominador conveniente. Medir el cifrado sobre «los portátiles que gestionamos» en vez de sobre todos es maquillaje. Consejo: define el denominador antes de calcular el numerador, y déjalo escrito.
• Confundir cumplir el catálogo con estar seguro. Cubrir IG1 completo es excelente y no significa que tu riesgo principal esté tratado. Consejo: el catálogo evita olvidos; el registro de riesgos ordena prioridades.
• Controles compensatorios sin caducidad. Un compensatorio permanente es una excepción permanente. Consejo: aplica las mismas reglas del registro de excepciones de 04-02.

Para cada control, indica su naturaleza y su función principal, y di qué riesgo del registro de 04-01 trata:

1. Banner que marca los correos procedentes del exterior.
2. Restauración de la base de datos desde la copia inmutable.
3. Revisión semestral en la que cada responsable confirma los accesos de su equipo.
4. Bloqueo automático de la fusión de código si el escáner encuentra un secreto.
5. Rotación inmediata de una clave API publicada por error en el repositorio.
6. Alerta cuando una cuenta administrativa accede fuera de la ventana 08:00-20:00.

Después, toma el riesgo R-05 (fraude BEC) y propón el control detectivo y el recuperativo que le faltan según la matriz del apartado 10.

Nimbus duda entre dos inversiones para tratar R-04 (fuga de adjuntos):

Calcula el coste total anual de cada opción valorando la hora interna en 35 €, calcula el ROSI de cada una con el método de 04-01 y recomienda una. Indica además qué función cubre cada opción y si con ella R-04 cumpliría la regla del apartado 4.

Revisas el catálogo de controles de otra empresa y encuentras: 34 controles, todos con estado: Implantado; ninguno tiene ultima_verificacion; 28 son preventivos, 6 detectivos, 0 recuperativos; el propietario de 30 de ellos es «IT»; y hay 4 controles compensatorios sin caducidad, uno de ellos justificado con «el fabricante no soporta MFA». Indica qué revela cada síntoma, qué preguntarías para confirmarlo y en qué orden lo corregirías.

Ejercicio 1

Fíjate en el 3: es el ejemplo típico de control con dos funciones, y por eso el campo funcion del catálogo es una lista. Y en el 1: mucha gente lo clasificaría como preventivo, pero el banner no impide nada —el usuario puede hacer clic igualmente—; su efecto es cambiar el comportamiento, que es la definición de disuasorio.

Para R-05 faltan: un control detectivo —alerta automática ante cualquier modificación de datos bancarios de un proveedor o cliente en el sistema de facturación, más la revisión mensual por Sara de los cambios de cuenta bancaria— y uno recuperativo: procedimiento documentado de recuperación de una transferencia fraudulenta, con el contacto directo del banco, el plazo real de reclamación y la denuncia, todo ello escrito antes de necesitarlo. Este último es de coste nulo y es exactamente el tipo de control que nadie tiene hasta el día que le hace falta.

Ejercicio 2

Coste total anual:

• Opción A: 7.200 € + (15 h × 35 €) = 7.725 € el primer año; recurrente = 7.200 € + (3 h/semana × 48 semanas × 35 €) = 7.200 + 5.040 = 12.240 €/año.
• Opción B: (40 h × 35 €) = 1.400 € el primer año; recurrente = (12 h × 35 €) = 420 €/año.

ROSI sobre el ALE de 19.200 €, usando el coste recurrente:

• A: ahorro = 19.200 × 0,45 = 8.640 €. ROSI = (8.640 − 12.240) / 12.240 × 100 = −29 %. El control cuesta más de lo que ahorra.
• B: ahorro = 19.200 × 0,60 = 11.520 €. ROSI = (11.520 − 420) / 420 × 100 = +2.643 %.

Recomendación: opción B, y el margen es tan grande que ninguna corrección razonable de las estimaciones lo cambia. Observa dónde está la diferencia: no en la licencia, sino en las 3 horas semanales de la opción A, que suman 5.040 € anuales de tiempo de Lucía —y, lo que es peor, 144 horas de sus 440 disponibles—. Es exactamente el error del apartado 6.

Funciones: la opción A es principalmente detectiva (ve la salida de datos y avisa); la opción B es mixta, porque las pruebas de autorización en el CI son preventivas y la alerta SQL sobre la tabla de auditoría es detectiva. Con B, R-04 tendría preventivo (C-05, C-06 y las nuevas pruebas) y detectivo (C-07 más la alerta), pero seguiría sin control recuperativo, y en una fuga de datos el recuperativo no es restaurar nada: es el plan de respuesta y notificación de 04-05. Así que la respuesta completa es «B, y además hay que escribir el procedimiento de notificación».

Ejercicio 3

Orden de corrección: 1 → 2 → 3 → 4 → 5. Primero verifica una muestra, porque hasta que no sepas qué es cierto todo lo demás es especulación —y probablemente descubras que varios «implantados» no existen—. Después cubre la recuperación, que es lo que decide si la empresa sobrevive a un incidente. Luego la detección, que reduce su duración. Después asigna propietarios, sin los cuales lo anterior derivará en un año. Y por último, formaliza los compensatorios con caducidad. Sobre el que dice «el fabricante no soporta MFA»: puede ser legítimo, pero solo si va acompañado de credenciales de corta duración con ámbito mínimo, alerta ante uso anómalo y fecha de sustitución del sistema; sin eso, es la excusa del apartado 7.

Has cerrado el triángulo. Sabes que un control es una medida concreta, con propietario, que reduce probabilidad o impacto y cuyo funcionamiento se puede comprobar, y que sin esos tres elementos a la vez lo que tienes es decoración. Sabes también distinguir control de herramienta: un antivirus es una licencia; «malware contenido con alerta atendida en menos de 4 horas» es un control.

Dominas las dos clasificaciones. Por naturaleza —administrativo, técnico y físico—, con la observación de que los administrativos suelen ser gratis, son los que más se olvidan y son los que sostienen a los técnicos. Y por función —disuasorio, preventivo, detectivo, correctivo, recuperativo y compensatorio—, con las dos distinciones que casi todos confunden: disuadir no es impedir, y corregir la causa no es recuperar el estado. De ahí la regla que reorganiza el trabajo de Nimbus: todo riesgo Alto o Crítico necesita al menos un preventivo, un detectivo y un recuperativo, porque cada función compra algo distinto —evitar el incidente, acortar su duración o sobrevivir a él— y porque el desglose del ransomware de 02-06 mostró cero controles en cinco de las seis funciones.

Conoces los catálogos de referencia y para qué sirve usar uno: CIS v8 con sus grupos de implementación y IG1 como objetivo realista y suficiente para Nimbus este año; ISO 27002 con sus cuatro temas cuando aparece la certificación; NIST SP 800-53 como opción desproporcionada para una PYME. Y la advertencia que los acompaña: el catálogo evita olvidos, pero es tu registro de riesgos el que ordena prioridades. Sabes seleccionar un control valorando eficacia, impacto en el usuario, dependencias y sobre todo coste total, incluida la carga operativa recurrente que es lo que de verdad hunde los proyectos de seguridad en una PYME: 150 horas anuales de alertas son un tercio de la capacidad de Lucía. De ahí la preferencia por los controles que, una vez puestos, trabajan solos. Y sabes cuándo un compensatorio es legítimo —imposibilidad real, protección comparable, aprobación con caducidad y verificación— y cuándo es una excusa, con el caso honesto de Nimbus: la separación de funciones es imposible con una sola administradora, y se compensa con revisión mensual de Marta, aprobación de altas privilegiadas, despliegue exclusivo por el CI y auditoría externa anual.

Te llevas el catálogo de controles de Nimbus con sus 22 entradas mapeadas a CIS IG1, cuyas tres lecturas de conjunto valen más que cualquier entrada suelta: solo 7 están implantados, de los 8 detectivos solo 2 lo están, y los administrativos son gratis y están casi todos pendientes. Y te llevas la distinción decisiva entre control implantado y control eficaz, con sus métricas calculadas —57 % de MFA, 92 % de cifrado, 7,3 días de parcheo, 23 días desde la última restauración—, con las tres decisiones de medición que esconde el código (el denominador honesto, incluir las cuentas de servicio que son justo el vector de 02-06, y que la media de parcheo oculta el peor caso que es el que explota el atacante), y con la consulta SQL que vigila al vigilante, porque un control detectivo que deja de emitir eventos falla en silencio y el silencio se lee como calma. Cierran la lección la matriz de trazabilidad riesgo → control → evidencia, que es lo que se enseña y lo que salva una auditoría porque responde en un folio a las tres preguntas de cualquier auditor, y la deriva: un control implantado se degrada solo por crecimiento, cambio técnico, excepciones olvidadas, rotación, fatiga o fallo silencioso, y el único antídoto es la frecuencia de verificación.

Pero repasa el catálogo una vez más y verás que hay controles cuya eficacia no depende de Nimbus. C-03 exige acceso just-in-time a una consultora que tiene sus propios procesos y su propia seguridad. C-19 replica copias a una región de un proveedor cuyas decisiones nadie de Nimbus controla. El código que despliega el CI arrastra cientos de dependencias escritas por desconocidos. Y el vector del incidente de 02-06 no fue un fallo de Nimbus: fue una brecha en la consultora que Nimbus ni siquiera llegó a conocer.

En la siguiente lección, Riesgo de Terceros y Cadena de Suministro (04-04), verás por qué el perímetro incluye empresas que no controlas y por qué se puede externalizar la ejecución pero nunca la responsabilidad: el mapa de terceros de Nimbus, el regreso de la consultora de 02-06 con el análisis completo de lo que debería haber existido y su coste real, el ciclo de vida del proveedor incluida la fase de salida que todo el mundo olvida, un cuestionario de diligencia debida proporcionado al tamaño del proveedor, las cláusulas contractuales imprescindibles, el modelo de responsabilidad compartida en la nube y la cadena de suministro de software con SBOM y fijación de dependencias.