Sistemas de detección de ataques (SzA)

La obligación de utilizar sistemas de detección de ataques se introdujo con la ley alemana IT-Sicherheitsgesetz 2.0 y era aplicable a los operadores KRITIS desde el 1 de mayo de 2023 (§ 8a, apartado 1a, BSIG, versión anterior). Con la ley de transposición de NIS2 (NIS2-Umsetzungsgesetz), en vigor desde el 6 de diciembre de 2025, figura ahora en el § 31, apartado 2, BSIG: los operadores de instalaciones críticas deben utilizar sistemas que «registren y evalúen de forma continua y automática parámetros y características adecuados de la operación en curso», respetando el estado de la técnica. El § 2 BSIG define los SzA como procesos apoyados en herramientas técnicas e integración organizativa, es decir, expresamente no como un mero producto, sino como la interacción de técnica y organización. Según el § 39 BSIG, la implementación debe acreditarse mediante auditorías de seguridad, revisiones o certificaciones, cada tres años en el nuevo régimen (antes cada dos años según el § 8a, apartado 3, BSIG, versión anterior).

La referencia para la implementación y las auditorías es la guía de orientación del BSI «Orientierungshilfe zum Einsatz von Systemen zur Angriffserkennung» (versión 1.1 del 18.11.2024, revisada editorialmente frente a la primera edición de septiembre de 2022; todavía hace referencia al marco legal anterior). La guía estructura los requisitos en los tres ámbitos de registro (logging), detección y respuesta y los formula, siguiendo el modelo del IT-Grundschutz, como requisitos MUSS, SOLLTE y KANN («debe», «debería», «puede»); como orientación adicional remite, entre otros, a los módulos OPS.1.1.5, DER.1 y DER.2.1. La evaluación se realiza mediante un modelo de grados de implementación de 0 a 5: el grado 3 significa que todos los requisitos MUSS se cumplen en todos los ámbitos; el grado 4 exige además todos los requisitos SOLLTE (excepciones solo con una justificación sólida) y el grado 5 incluye los requisitos KANN. Para la acreditación debe alcanzarse, por regla general, al menos el grado de implementación 3; las desviaciones a la baja solo son admisibles con justificación.

Una detección eficaz comienza con la pregunta de qué datos de registro se recopilan realmente. La guía de orientación exige identificar todos los sistemas relevantes para el servicio crítico, almacenar de forma centralizada los datos de logs y de registro necesarios y ponerlos a disposición para el análisis de forma filtrada, normalizada, agregada y correlacionada. La incorporación de las fuentes debe priorizarse de fuera hacia dentro: de los perímetros de red hacia las zonas internas de la red y, a nivel de sistemas, partiendo de los sistemas críticos centrales, como la tecnología de control de procesos y automatización. El alcance abarca expresamente tanto IT como OT, así como centros de datos y sistemas embebidos. Además, deben respetarse la protección de datos y los plazos legales de borrado, y establecerse un proceso de gestión de cambios que adapte el registro cuando cambie el ámbito de aplicación.

Los contenidos de detección se desarrollan cada vez más como software: versionados, probados y reutilizables. Sigma se ha consolidado como formato de firmas abierto basado en YAML para eventos de log; las reglas pueden convertirse a los lenguajes de consulta de las plataformas SIEM habituales mediante sigma-cli y pySigma e intercambiarse a través del repositorio SigmaHQ, mantenido por la comunidad. Para planificar la cobertura, la guía de orientación del BSI recomienda un método estandarizado como MITRE ATT&CK o ATT&CK for ICS. En su versión 19 (abril de 2026), la matriz Enterprise describe 15 tácticas, 222 técnicas y 475 subtécnicas; un mapeo de las propias reglas sobre ATT&CK hace trazable qué técnicas de ataque se detectan y dónde quedan brechas.

En la práctica, la detección de ataques surge de la interacción de varios componentes. Un SIEM recopila y correlaciona de forma centralizada los datos de logs de fuentes heterogéneas y materializa el análisis continuo y automatizado exigido, con alertas al superarse umbrales. El EDR aporta telemetría detallada y capacidades de respuesta en endpoints y servidores; el NDR detecta anomalías en el tráfico de red y cubre así también áreas en las que no pueden instalarse agentes, como entornos OT o sistemas embebidos. La guía de orientación exige además, de forma concreta, una detección de código malicioso gestionada centralizadamente, así como sistemas de detección de intrusiones basados en red (NIDS) en las transiciones entre redes internas y externas. Ninguna herramienta cumple por sí sola los requisitos; lo decisivo es la cobertura documentada de todo el alcance.

Los casos de uso de detección no son un proyecto puntual, sino una cartera con ciclo de vida: análisis de amenazas y priorización, desarrollo de reglas, prueba y calibración en operación normal (baselining), operación productiva con tuning, y revisión y retirada periódicas. La guía de orientación exige expresamente reajustar los mecanismos de detección a partir de la cualificación de los eventos relevantes para la seguridad y mantener las firmas siempre actualizadas. Las brechas típicas en auditorías y proyectos son una cobertura incompleta de las fuentes de logs, especialmente en redes OT, procesos de respuesta inexistentes o no ensayados, la falta de una regulación sólida para el análisis fuera del horario laboral, la fatiga de alertas por reglas sin calibrar y la falta de documentación de la planificación y de las excepciones justificadas; esto último sale a la luz, a más tardar, al evaluarse el grado de implementación.