¿Qué controles no pueden desaparecer al eliminar herramientas

Un escenario típico: tres herramientas menos, costes de licencia notablemente reducidos y un departamento de control de gestión satisfecho. Seis semanas después, saltan las primeras alarmas reales. Una cuenta de servicio rota las contraseñas por la noche, el movimiento atraviesa tres segmentos de red. En el SIEM faltan los registros de firewall de la herramienta perimetral que se había dado de baja. La detección estaba ahí, pero no la correlación, porque la fuente de logs nunca se migró a la nueva plataforma al desmantelar el sistema. La consolidación ahorra dinero, pero no debe llevarse por delante funciones obligatorias.

Relacionado:El riesgo en la cadena de suministro es un programa, no una lista de auditoría  /  Por qué el certificado ISO no basta por sí solo para el BSI

Por qué se reduce el stack y dónde está el límite de cumplimiento

¿Qué es la consolidación del stack de seguridad? La consolidación del stack de seguridad consiste en fusionar o desactivar herramientas de seguridad de forma estratégica para reducir costes de licencias, esfuerzos de integración y el ruido de alertas. Varias soluciones individuales se integran en una única plataforma, como la detección y la respuesta en un stack combinado de SIEM y EDR.

La presión para hacerlo es real. Muchos equipos de seguridad acumulan con los años un auténtico «zoo de herramientas», donde cada una aporta sus propios analizadores, interfaces y carga de mantenimiento. A esto se suma la fatiga por alertas: cuando un equipo pasa por alto señales reales en medio del ruido de falsos positivos, a veces menos es más seguro. Por eso, la consolidación suele ser una decisión sensata.

La ley no lo prohíbe. El párrafo 30, apartado 1 de la Bundesamt für Sicherheit in der Informationstechnik Gesetz (BSIG, Ley Federal de Seguridad de la Información de Alemania) exige medidas adecuadas, proporcionadas y eficaces, y menciona los costes de implementación como uno de los factores de proporcionalidad -junto a la exposición al riesgo, el tamaño de la organización y el posible daño-. Así, la presión por reducir costes es un argumento válido. El límite está en otro lugar: el apartado 1 exige eficacia, y el apartado 2, número 6, obliga a contar con conceptos y procedimientos para evaluarla. Reducir gastos está permitido, pero si se desactiva una herramienta y se pierde la funcionalidad obligatoria que ofrecía, se incumple el deber de eficacia.

Un control es una función; una herramienta, solo el vehículo

El error de planteamiento en casi cualquier consolidación fallida es siempre el mismo: se piensa en productos, no en funciones. Un control es una capacidad demostrable, como imponer la autenticación multifactor (MFA) para cuentas privilegiadas, mantener correlacionables los registros durante un período definido o restaurar periódicamente una copia de seguridad a modo de prueba. La herramienta no es más que el soporte de esa capacidad. Consolidar significa reducir el número de soportes y conservar cada función.

En una ocasión, heredé dos escáneres de vulnerabilidades: uno configurado de forma estricta y otro, más laxo. Por motivos de coste, se eliminó el más caro, que era precisamente el estricto. Sobre el papel, la gestión de vulnerabilidades seguía funcionando, pero en la práctica la cobertura disminuyó y los plazos de respuesta se alargaron sin que nadie lo advirtiera. Así es como se abre una brecha: el apagado en sí no es peligroso, pero sí lo es la reducción inadvertida de la profundidad del control.

Hay tres patrones que se repiten una y otra vez. Desaparece una fuente de registros, pero la regla de detección en el sistema SIEM (gestión de eventos e información de seguridad) sigue activa y queda en el vacío. Un EDR (detección y respuesta en endpoints) cubre los puestos de trabajo, pero tras el cambio de herramienta, los servidores o los hosts Linux se quedan sin agente. O un control estricto se sustituye por otro más laxo, como reemplazar un control de acceso condicional por un simple VPN. En todos los casos, la función sigue figurando en el papel, pero desaparece de la operativa real.

Diez medidas obligatorias que ninguna licencia sustituye

El artículo 30, apartado 2 de la Ley de Seguridad de la Información (BSIG, por sus siglas en alemán) enumera diez medidas mínimas. Estas constituyen la piedra de toque para cualquier decisión de reducción de herramientas. La siguiente tabla traduce los aspectos más relevantes al lenguaje operativo e indica qué debe mantenerse al cambiar de solución.

Dos aspectos vinculan legalmente esta tabla. El artículo 30, apartado 1 de la BSIG exige documentar el cumplimiento. Si las evidencias dependen de una herramienta que se desactiva, surge inmediatamente una laguna en la auditoría. Además, para las entidades financieras sujetas a DORA, esta normativa prevalece sobre las obligaciones de la BSIG en materia de gestión de riesgos de las TIC y notificación de incidentes. Una consolidación no altera estos requisitos, solo su implementación técnica.

Contexto DACH: La BSIG es la ley alemana que regula la seguridad de la información para operadores de infraestructuras críticas y empresas de servicios digitales. DORA (Reglamento de Resiliencia Operativa Digital) es una normativa de la UE aplicable al sector financiero, que impone requisitos más estrictos en gestión de riesgos tecnológicos y ciberseguridad.

Cinco trampas que salen a la luz tras la desactivación

Los errores rara vez se manifiestan de inmediato. Aparecen en el siguiente incidente o en la próxima auditoría, cuando el proyecto de ahorro ya se da por concluido.

Interfaces huérfanas. Un playbook de automatización sigue llamando a la interfaz de programación de aplicaciones (API) de una herramienta ya desactivada. La detección funciona, pero la respuesta se queda colgada. El incidente se retrasa justo donde más importa la velocidad.

Fuentes de registro ausentes. Tras el cambio, no se vuelven a integrar los registros del firewall, el proxy, los protocolos en la nube o los logs de identidad. La correlación se interrumpe sin que nadie detecte un error. Simplemente, ya no llega nada.

Controles duplicados con distinto nivel de exigencia. Dos vías para lo mismo, pero una más estricta. Se elimina la más cara, a menudo sin migrar antes la política de seguridad. Lo que queda es la versión más laxa, convertida en el nuevo estándar.

Pruebas vinculadas a la herramienta. Los informes de exportación, las evidencias de auditoría y los informes de pruebas de penetración hacen referencia a nombres de productos antiguos. El auditor pregunta por la continuidad y no hay respuesta.

Evaluación de eficacia omitida. La consolidación se da por finalizada como proyecto sin verificar antes y después su eficacia. Así, falta la prueba que exigen los conceptos y procedimientos según el § 30, apartado 2, número 6 [normativa alemana de protección de datos, equivalente a evaluar el cumplimiento de medidas técnicas y organizativas en el RGPD].

El camino correcto: inventario de controles antes que inventario de herramientas

El orden determina el resultado. Quien empieza por la lista de licencias, ahorra en controles. Quien comienza por el inventario de controles, ahorra en herramientas. Seis pasos mantienen la funcionalidad mientras la herramienta se reemplaza.

Primero: traducir cada medida obligatoria del artículo 30 (Reglamento de Protección de Datos alemán, que exige documentación de procesos de tratamiento de datos) a funciones operativas y métricas medibles, como el porcentaje de activos con EDR, la cobertura de MFA en cuentas de administrador o el tiempo medio hasta la detección. Segundo: crear una matriz que muestre qué herramienta cubre qué función, con qué nivel de robustez y para qué clase de activo. Tercero: dar de baja solo aquellas herramientas cuyas funciones estén completamente implementadas y probadas en el sistema objetivo, no solo presentes según la lista del proveedor.

Cuarto: definir una ruta de migración para cada función obligatoria, desde el reenvío de logs hasta las reglas de detección y los trabajos de copia de seguridad, incluyendo un plan de contingencia. Quinto: demostrar la eficacia con mediciones antes y después, una prueba de restauración y un simulacro de respuesta a incidentes. Sexto: fechar la documentación en el momento de la migración del control. Lo decisivo es la fecha en que la función se trasladó, no el día en que se canceló la licencia. Para funciones críticas como el registro de logs, EDR y copias de seguridad, conviene mantener un funcionamiento en paralelo durante algunas semanas. Aunque suponga un coste a corto plazo, evita la fase de incertidumbre en la que nadie sabe si la detección sigue siendo efectiva.

Preguntas frecuentes

Cada pregunta está cerrada. Un clic revelará la respuesta.

¿Puedo combinar herramientas de seguridad bajo NIS2 y la Ley de Servicios de Confianza Digital (BSIG) para ahorrar costes?

Sí. El párrafo 30, apartado 1 de la BSIG menciona explícitamente los costes de implementación como criterio de proporcionalidad. Sin embargo, el ahorro no justifica eliminar una función obligatoria. Las medidas deben mantener su eficacia y esta debe poder demostrarse.

¿Qué controles del párrafo 30 de la BSIG están vinculados a herramientas específicas?

Ninguno. La ley define medidas, no productos. La autenticación multifactor (MFA), el registro de eventos (*logging*), las copias de seguridad (*backup*) y la gestión de vulnerabilidades deben funcionar. Que lo haga un proveedor u otro es una cuestión de implementación.

¿Qué ocurre con nuestras pruebas de auditoría si reemplazamos el SIEM o la plataforma GRC?

Los registros históricos deben archivarse. A partir de la consolidación, surgirán nuevas pruebas de eficacia desde la herramienta objetivo. Una brecha en esta cadena será problemática al presentar los registros a los supervisores.

¿Aplica DORA en lugar de NIS2 si somos una entidad financiera?

Para la gestión de riesgos en tecnologías de la información y la comunicación (TIC) y la notificación de incidentes significativos, DORA (Digital Operational Resilience Act) tiene prioridad como normativa más específica. Una consolidación de herramientas debe seguir cumpliendo los requisitos del marco de riesgo TIC.

Recomendaciones de lectura

Recomendación
Gestionar riesgos en la cadena de suministro: un proceso, no una lista de auditoría







Recomendación
NIS2 tras el plazo: comienza la supervisión del BSI







Recomendación
NIS2 para pymes: pasos viables y errores evitables

Más del ecosistema MBF Media

Digital Chiefs
Geopolítica y planificación de centros de datos: qué deben asegurar los CIOs ahora

Lectura adicional

Actualidad · 21 de julio de 2026

WithSecure: Del pionero del antivirus al especialista en seguridad en la nube

WithSecure es desde el 1 de julio de 2022 la escisión B2B de F-Secure. Elements, Co-Security y un enfoque europeo en protección de datos …

Estrategia y Gobernanza · 21 de julio de 2026

AI sombra: 40% ya se evitan por permisos inútiles

AI sombra: 40% ya se evitan por permisos inútiles. Patricia Leppert (TeamViewer) en entrevista sobre riesgos, IA falsa y medidas del CISO.

Estrategia y Gobernanza · 17 de julio de 2026

NIS2: Cuatro países demandados ante el Tribunal de la UE

La Comisión Europea demanda a Irlanda, España, Francia y Países Bajos por incumplir la directiva NIS2. Impacto para los CISO en Alemania.

WordPress multilingüe con WPML