Detección como código, para que tus reglas sobrevivan a cambiar de SIEM

Dos problemas aparecen en todas las operaciones de seguridad que revisamos. Las reglas de detección viven en la interfaz web del SIEM, escritas por gente que ya se ha ido, sin constancia de por qué existe ninguna de ellas. Y nadie sabe cuáles siguen funcionando, porque una regla que dejó de coincidir con nada se parece exactamente a una regla para algo que dejó de ocurrir.

Los dos son el mismo problema: la detección se trata como configuración en vez de como código.

Qué es Sigma y qué no

Sigma es un formato en YAML para expresar lógica de detección sobre datos de registro, con conversores que compilan una regla al lenguaje de consulta de una plataforma concreta. Escribes la lógica una vez y generas la consulta para el backend que ejecutes.

El valor no es principalmente la portabilidad entre proveedores, aunque importa cuando migras. Es que la regla se convierte en un fichero: revisable en un pull request, versionado, comprobable, y con metadatos que explican qué detecta y por qué.

Existe además un repositorio público grande de reglas, que es un punto de partida genuinamente útil y un mal punto de llegada. Las reglas públicas están escritas contra entornos genéricos y serán ruidosas en el tuyo, que es el mismo problema que se describe en Falco te dice qué hizo un contenedor.

Lo que no es: un motor de detección, un sustituto de tu SIEM, ni una forma de evitar entender tus fuentes de registro. La conversión vale lo que valga la correspondencia entre los campos que la regla espera y la forma en la que tus registros llegan de verdad, y esa correspondencia es el trabajo real.

El pipeline que lo hace funcionar

La forma es la de cualquier pipeline de código, que es justo la idea.

Las reglas viven en un repositorio, un fichero por regla, organizadas por fuente de registro. Un pull request añade o cambia una regla. La integración continua valida la sintaxis, convierte la regla a todos los backends a los que apuntas para confirmar que compila, y la ejecuta contra un conjunto de eventos de ejemplo con veredictos conocidos. Fusionar la despliega en el SIEM a través de la API de la plataforma.

El paso de pruebas es el que los equipos se saltan y el que importa. Mantén un corpus pequeño de eventos de registro, algunos que deberían coincidir y otros que no, y comprueba el veredicto de la regla en cada uno. Sin eso, la primera prueba de un cambio de regla es producción, que en detección significa que te enteras cuando se le escapa algo.

Los metadatos van en el fichero de la regla: qué técnica cubre, cuáles son las fuentes de falsos positivos, qué severidad lleva, y qué debería hacer quien responda. Una regla con una nota de respuesta adjunta es una regla sobre la que alguien puede actuar a las tres de la madrugada.

El ciclo de vida que nadie construye

Las reglas no se escriben una vez. Necesitan un ciclo de vida con un dueño con nombre, y la mayoría de las operaciones no lo tienen.

Cobertura. Mapea tus reglas contra un marco de técnicas de ataque y mira qué no está cubierto. El hallazgo honesto suele ser que la cobertura es profunda en un área, normalmente el puesto de trabajo, y ausente en otras, normalmente el plano de control de la nube y la identidad.

Validación. Una regla que no se ha disparado nunca o es excelente o está rota, y no puedes distinguirlo desde fuera. Pruébala a propósito generando el comportamiento que busca, que es para lo que sirve la emulación de adversario, como en emulación de adversario y equipos morados.

Ajuste. Sigue la tasa de verdaderos positivos por regla. Una regla que produce falsos positivos constantes es peor que ninguna regla, porque consume la atención que habría cazado algo real.

Retirada. Borra las reglas de sistemas que ya no ejecutas. Un conjunto de reglas que solo crece se convierte en un conjunto de reglas en el que nadie confía.

Revisa cada trimestre: qué se disparó, qué no, qué fue verdadero positivo, qué hay que borrar.

Las detecciones de nube son donde casi todas las operaciones están flojas

Las detecciones que importan en un entorno cloud no son las clásicas de puesto de trabajo, y son donde más a menudo encontramos huecos.

La identidad es la fuente de más valor. Credencial nueva creada para una identidad privilegiada, un rol asumido desde una ubicación inusual, un cambio en una política de permisos, doble factor desactivado, una cuenta dormida que de pronto se activa. Casi todas las intrusiones en la nube son visibles aquí antes que en ningún otro sitio.

Después el plano de control: registro desactivado, configuración de una herramienta de seguridad modificada, una instantánea compartida con una cuenta externa, un cubo de almacenamiento hecho público, un borrado masivo de objetos de copia de seguridad. Este último es la detección que se defiende en una copia que el atacante puede borrar, y es de alto valor porque ocurre antes del daño visible.

El requisito previo es que los registros existan. El registro de acceso a datos está con frecuencia desactivado por defecto, y el coste de encenderlo en todas partes es real, que es la tensión de los costes de Cloud Logging y Cloud Storage. Decide a conciencia qué fuentes valen su coste de ingesta, en vez de quedarte por defecto con todo o con nada.

Detección como código y cumplimiento son el mismo artefacto

Esta es la parte que paga el trabajo dos veces.

Un auditor que pregunta cómo detectas el acceso no autorizado quiere evidencia. Un repositorio versionado con reglas, historial de revisión, resultados de pruebas y un mapa de cobertura es una respuesta mucho mejor que una captura de pantalla de una consola, y es la misma evidencia que ibas a montar igualmente para los marcos de un conjunto de controles para cuatro marcos.

Varios marcos exigen capacidad de vigilancia y detección y, cada vez más, evidencia de que se mantiene y no solo de que está. Un historial de git que muestra reglas añadidas, ajustadas y retiradas es exactamente esa evidencia, producida como efecto secundario de hacer el trabajo bien.

Lo que se olvida

• La correspondencia de campos es la parte difícil. Dos fuentes que describen el mismo evento usan nombres de campo distintos, y una regla que convierte limpiamente puede no coincidir con nada.
• Normalizar los registros aguas arriba ahorra complejidad en las reglas. Decidir un esquema en la ingesta vale más que reglas ingeniosas aguas abajo.
• La detección depende de la retención. Una regla que mira siete días atrás es inútil si los registros se guardan tres.
• Los cambios de volumen rompen las suposiciones. Una regla con un umbral ajustado el año pasado se dispara constantemente cuando el servicio crece.
• El encaminamiento de la alerta es parte de la regla. La severidad, el destino y la nota de respuesta van en el fichero, no en otro sistema.
• Las reglas públicas necesitan atribución y revisión. Importar un repositorio entero produce ruido y una falsa sensación de cobertura.

Qué hacer esta semana

Exporta tus reglas de detección actuales desde tu SIEM a un repositorio de git, tal cual, sin conversión. Ese único acto te da una línea base comparable y normalmente revela dos cosas de inmediato: cuántas reglas existen que nadie puede explicar, y cuántas referencian sistemas que ya no ejecutas. Borrar el segundo grupo es la mejora más rápida disponible. Arrancamos la línea de detección de un proyecto de seguridad con exactamente esa exportación.