Qué son las reglas Sigma y por qué las necesitas

Es posible que algunos de vosotros ya habráis oído hablar de las reglas Sigma o Sigma Rules, un enfoque genérico para las firmas utilizadas en los sistemas SIEM. Su objetivo principal es proporcionar una forma estructurada en la que los investigadores o analistas puedan describir sus métodos de detección, una vez desarrollados, y compartirlos con otros.

Hoy me gustaría describir otro caso de uso que nos ayuda a construir las mejores firmas posibles para cualquier aplicación.

En los proyectos típicos de monitorización de seguridad, las personas integran diferentes fuentes de registro y amenazas / casos de uso que desean monitorizar en estos registros. La selección de las fuentes de registro está determinada por la importancia, la disponibilidad y los requisitos operativos.

Pero la pregunta central es:

¿Qué es lo que quiero detectar?

Hay varios libros blancos y guías para las fuentes de registro más comunes, como son los registros de eventos de Windows o SSOO (Luego os pondré algunos ejemplos)

Lo que si debemos hacer es leer los documentos, extraer los métodos de detección interesantes y definir búsquedas y paneles para nuestro sistema SIEM. Uno de los propósitos principales de las reglas Sigma es disminuir los tiempos de este proceso que consume tanto tiempo. Estas descripciones públicas de los métodos de detección ya forman parte de Sigma o estarán integradas por uno de los colaboradores.

Pero hoy me gustaría señalar un caso de uso diferente que veremos más adelante, menos obvio pero muy útil.

Qué son las reglas Sigma

Proveniente de Generic Signature Format for SIEM Systems (Formato genérico de firma para sistemas SIEM) , las reglas Sigma son un formato de firma genérico y abierto que nos permite describir eventos de registros relevantes de una manera directa. El formato de regla es muy flexible, fácil de escribir y aplicable a cualquier tipo de archivo de registro. El objetivo principal de este proyecto es proporcionar una forma estructurada en la que los investigadores o analistas puedan describir sus métodos de detección, una vez desarrollados, y compartirlos con otros.

Sigma es para archivos de registro o logs lo que Snort es para el tráfico de red y YARA es para archivos.

La mejor monitorización posible

Los analistas de seguridad intentan definir búsquedas útiles y análisis estadísticos en los datos de registro de todas las fuentes de logs diferentes. Por lo general, siguen las guías públicas y crean muchas reglas diferentes de "inicio de sesión fallido" para todo tipo de sistemas operativos y aplicaciones.

Pero, ¿qué sucede cuando comienzas a integrar fuentes de registro y tipos que no están cubiertos por directrices públicas?

Hay diferentes enfoques para este problema:

• Cubrir los intentos fallidos de autenticación
• Monitorizar cualquier evento fallido
• Usar desviaciones estadísticas (muchos eventos nuevos de cierto tipo)
• Mirar a través de los datos de registro y seleccionar mensajes "interesantes"
• Hablar con los propietarios / administradores de la aplicación (a menudo de forma bastante decepcionante)
• Hablar con los desarrolladores de la aplicación (en caso de desarrollo interno)

Todos estos métodos son válidos y pueden ayudarnos a configurar búsquedas útiles en los datos disponibles. Sin embargo, para crear las mejores firmas y alertas posibles tenemos que considerar lo siguiente:

• Las condiciones de fallo más interesantes y relevantes no ocurren en condiciones normales y, por lo tanto, no aparecen en los datos de registro cotidianos (los datos de registro que tenemos para seleccionar eventos interesantes)
• Los desarrolladores conocen las condiciones de error más raras o más relevantes y los ID y mensajes de error correspondientes
• Todos los mensajes de error posibles de una aplicación aparecen en su código fuente

Imagina que pudiesemos extraer los mensajes más interesantes que la aplicación puede generar y definir reglas para estas condiciones. Imagina que este proceso es una tarea fácil que cualquier desarrollador puede realizar.

Bueno, pues tenemos a nuestro alcance todas lo que necesitamos para múltiples casos.

Un ejemplo: vsftpd

Un enfoque más claro. En condiciones óptimas, solicitamos a los desarrolladores que extraigan los mensajes de error más relevantes o anormales que las aplicaciones produzcan en condiciones que indiquen una manipulación o ataque. Alternativamente, podemos hacerlo nosotros mismos y verificar los resultados con los datos de registro disponibles para evitar falsos positivos.

Revisamos el código fuente del servidor FTP vsftpd en Github 'para ver los mensajes de error que indican condiciones de error raro y fallas fatales.

Como resultado de dicha observación:

Con ello, la idea es construir una gran base de firmas compartidas para los diferentes tipos de aplicaciones y servicios.

También podríamos tratar de convencer a los desarrolladores para que proporcionen las reglas Sigma de sus aplicaciones para ayudar a las organizaciones a establecer la mejor monitorización posible de los aplicativos. Sería de gran ayuda extrae cadenas de mensajes de error que contienen ciertas palabras clave como "error", "fatal", "permiso denegado", "rechazado" u otros para facilitar este proceso a la hora de crear alertas y escribir reglas.

Porqué empezar con las Reglas Sigma !YA¡

Casos de uso:

• Describir un método de detección que sea compartible
• Escribir reglas homogeneas para el SIEM busca que las reglas Sigma eviten el bloqueo de proveedores
• Compartir las firma en el apéndice de análisis junto con IOCs y reglas YARA
• Compartir la firma en comunidades de inteligencia de amenazas, por ejemplo a través de MISP
• Proporcione firmas Sigma por comportamiento malicioso para nuestras propias aplicaciones

Conclusiones

La primera y más importante, empezar cuanto antes a aplicar todo el catálogo de reglas Sigmas posibles.

Hoy, todos recopilan datos de registro para el análisis. Las personas comienzan a trabajar por su cuenta, procesan numerosos libros blancos, publicaciones de blogs y guías de análisis de registros, extraen la información necesaria y crean sus propias búsquedas y paneles. Algunas de sus búsquedas y correlaciones son geniales y muy útiles, pero carecen de un formato estandarizado en el que puedan compartir su trabajo con otros.

Otros proporcionan análisis excelentes, incluyen IOCs y reglas YARA para detectar los archivos maliciosos y las conexiones de red, pero no tienen forma de describir un método de detección específico o genérico en los eventos de registro. Sigma pretende ser un estándar abierto en el que tales mecanismos de detección se puedan definir, compartir y recopilar a fin de mejorar las capacidades de detección para todos.

Mediante una serie de Especificaciones para Reglas Sigma , podemos encontrar ejemplos maravillosos a implementar ya:

1. Registro de eventos de seguridad de Windows: acceso al proceso LSASS con cierta máscara de acceso / tipo de objeto (experimental) :

2. Sysmon: Creación remota de subprocesos en el proceso LSASS

3. Registros de acceso al servidor web: detección de shell web

4. Sysmon: Detección de Shell Web

5.Registro de eventos de seguridad de Windows: Número sospechoso de inicios de sesión fallidos desde una estación de trabajo de fuente única