Soy Sergey Rublev, jefe de SOC (Centro de Operaciones de Seguridad) en Infosecurity.
En este artículo, examinaré en detalle el ambicioso proyecto
Sigma Rules , cuyo lema es: "Sigma para los registros es como Snort para el tráfico y Yara para los archivos".
Se tratará de tres aspectos:
- Aplicabilidad de la sintaxis de la regla Sigma para mantener una base de conocimiento de scripts de detección de amenazas
- Capacidades de herramientas de generación de reglas para sistemas SIEM en caja
- Valor para el SOC del contenido actual de los repositorios públicos de reglas Sigma
Érase una vez, en una galaxia muy, muy lejana
Todo comenzó hace unos años cuando los árboles eran grandes, y nuestro equipo de monitoreo aún era pequeño. Nos enfrentamos a muchas preguntas, casi cualquier equipo que se convierta en una línea de tres personas pasa por esto.
Las razones para la aparición de preguntas son diferentes:
- Crecimiento del equipo
- Rotación de personal
- Una gran cantidad de sistemas heterogéneos para el monitoreo.
Si tiene que asumir el soporte ya configurado por alguien SIEM, el número de preguntas crece como una avalancha.
Biblioteca de casos de uso
La experiencia mundial en la construcción de centros de monitoreo ya ha encontrado una solución para organizar el caos y su nombre es la biblioteca de estudios de casos. El propósito de cada caso es describir exhaustivamente la solución a un problema en el marco de la supervisión de la seguridad de la información.
La composición del conocimiento establecido en cada caso puede variar; procedemos del siguiente conjunto:
- Objetivo : la tarea resuelta por el caso
- Amenaza : la amenaza que la regla de detección busca detectar.
- Partes interesadas : personas interesadas en esta regla: IB / IT / Business
- Requisitos de datos : el conjunto de datos requerido para identificar una amenaza
- Lógica : lógica de regla de detección de amenazas
- Prueba : un algoritmo para probar la corrección de la regla de detección
- Prioridad : prioridad del procesamiento de eventos por caso (generalmente calculada a partir del daño potencial de una amenaza implementada con éxito)
- Salida : una lista de acciones para analizar la alerta, una descripción de las salidas correctas del procedimiento de análisis y la composición de los datos registrados en los resultados del análisis.
Ejemplo de caso de uso para la tarea de detectar comunicación con el servidor de administración de botnet (comúnmente conocido como C&C o simplemente C2):
El ejemplo se simplifica enormemente; en realidad, con una descripción adecuada, un caso se convierte en un documento de varias páginas.
En ese momento, cuando el número de casos excedía varias decenas, comenzamos a buscar herramientas preparadas para mantener una base de conocimiento de este tipo, preferiblemente, además de amigable para los humanos, también algún tipo de interfaz amigable para la máquina para el trabajo.
Proyecto Sigma
El proyecto Sigma ciertamente merece consideración en el contexto de la base de conocimiento sobre las reglas de detección de incidentes. Comenzó en 2016, y lo he seguido casi desde el principio.
De hecho, el proyecto consiste en
- Sigma se gobierna a sí misma
- Utilidades para convertir reglas en consultas para varios sistemas SIEM
La lista SIEM es impresionante: casi todas las soluciones populares de análisis de eventos están presentes. Más sobre todo en detalle y en orden.
Sintaxis de la regla
Las reglas de Sigma son documentos de YAML que describen un escenario para detectar un ataque específico. Sintácticamente, las reglas consisten en los siguientes bloques:
Metainformación
Parte descriptiva para estructurar y simplificar la búsqueda de las reglas necesarias.
title: Access to ADMIN$ Share description: Detects access to $ADMIN share author: Florian Roth falsepositives: - Legitimate administrative activity level: low tags: - attack.lateral_movement - attack.t1077 status: experimental
También me gustaría señalar que muchas reglas ya cuentan con enlaces a la técnica de ataque de acuerdo con la metodología MITER ATT & CK.
Declaración de fuente de datos
Descripción de la fuente basada en los eventos de los cuales se implementa la lógica de detección.
logsource: product: windows service: security
Es sintácticamente posible describir tanto el servicio final de un producto en particular como una categoría completa de sistemas.
Declaración lógica de procesamiento
En el nivel lógico de detección, se describe lo siguiente:
- Patrones buscados
- Valores de ciertos campos en el registro
- Marco de tiempo
- Funciones agregadas
La lógica puede ser trivial, por ejemplo, condiciones impuestas en un conjunto de campos:
detection: selection: EventID: 5140 ShareName: Admin$ filter: SubjectUserName: '*$' condition: selection and not filter
y bastante complicado:
detection: selection1: EventID: - 529 - 4625 UserName: '*' WorkstationName: '*' selection2: EventID: 4776 UserName: '*' Workstation: '*' timeframe: 24h condition: - selection1 | count(UserName) by WorkstationName > 3 - selection2 | count(UserName) by Workstation > 3
Los medios expresivos del lenguaje, aunque no son universales, siguen siendo bastante amplios y le permiten describir una gran cantidad de casos para identificar ataques.
Herramientas de desarrollo de reglas
Además de su editor de texto favorito para YAML, la interfaz de usuario web de SOC Prime también está disponible, lo que le permite validar la sintaxis de una regla ya escrita y crear reglas manualmente a partir de bloques gráficos.
Sigma como herramienta de base de conocimiento
Para resumir un breve resumen.
Por el momento, la sintaxis de las reglas se concentra principalmente en la descripción de la lógica de detección de amenazas y no está destinada a una descripción exhaustiva del caso de uso; en consecuencia, no funcionará para mantener una biblioteca completa utilizando solo las Reglas de Sigma.
Para la estructura de caso de uso que hemos elegido, Sigma cierra solo la mitad (Objetivo, Requisitos de datos, Lógica y Prioridad).
Convertir a varios SIEM
Dado que somos un proveedor de servicios de servicios SOC, la idea de mantener todos nuestros desarrollos de acuerdo con las reglas de correlación en algún formato universal y en la etapa de implementación para convertirlos al formato SIEM deseado nos pareció muy atractiva.
El proyecto incluye utilidades de consola para generar solicitudes de eventos en el formato de varios SIEM. Considere qué es la conversión y qué hay debajo de su capucha.
La conversión se realiza en 3 etapas:
- Reglas de análisis: creo que esto está claro: el documento YAML está ordenado en bloques de componentes
- Reducción a la taxonomía SIEM
La necesidad de esta etapa está relacionada con el hecho de que la normalización en los sistemas SIEM se implementa de una manera ligeramente diferente, por lo que las declaraciones de las reglas de Sigma deben reducirse a la taxonomía de los eventos del SIEM seleccionado. - Solicitud de generación para SIEM
Para que esta etapa funcione, se requiere otro componente: un backend para este SIEM.
De hecho, el backend es un complemento para la utilidad de conversión, que contiene la lógica para convertir al formato de solicitud final en SIEM. Los bloques de detección y fuente de registro se convierten teniendo en cuenta la asignación de campos previamente superpuesta, se agrega información adicional específica de SIEM.
Como resultado, el inicio de la utilidad de conversión se ve así:
Se pasan los siguientes parámetros:
- SIEM objetivo
- La regla
- Archivo de mapeo para este SIEM
SOC Prime también tiene una interfaz de usuario lista para
usar para la función de conversión (
uncoder.io )
Errores de conversión
- Después de estudiar la mecánica de la conversión, encontramos limitaciones significativas, que nos impidieron convertir todos los desarrollos al formato Sigma:
- El convertidor funciona solo con una solicitud. La regla de correlación en SIEM afecta más aspectos: ventana de tiempo, agregación, acciones basadas en los resultados de alertas identificadas
- Las características clave de los SIEM individuales, como ActiveLists, no se tienen en cuenta.
- Detalles insuficientes del mapeo de campos: como parte de la configuración del mapeo, se describen los campos de solo unas pocas fuentes; en consecuencia, al tener reglas para varias decenas de diferentes tipos de orígenes de eventos en la base de datos, tendrá que invertir mucho en escribir el mapeo.
Base de reglas
Veamos qué conlleva la base de reglas Sigma disponible públicamente. Actualmente, el contenido se agrega activamente a dos repositorios:
- El repositorio principal del proyecto.
- Mercado de detección de amenazas principales de SOC
Las reglas en los repositorios tienen una intersección distinta de cero.
SOC Prime tiene una serie de reglas que se aplican a las suscripciones pagas; no considero su contenido en este artículo.
Para el análisis, necesitamos la biblioteca de
sigmatools para Python y algunas habilidades de programación.
Para analizar y cargar reglas de un directorio en un diccionario, puede usar el siguiente código:
from sigma.parser.collection import SigmaCollectionParser import pathlib import itertools def alliter(path): for sub in path.iterdir(): if sub.name.startswith("."): continue if sub.is_dir(): yield from alliter(sub) else: yield sub def get_inputs(paths, recursive): if recursive: return list(itertools.chain.from_iterable([list(alliter(pathlib.Path(p))) for p in paths])) else: return [pathlib.Path(p) for p in paths] BASE_PATH = [r'sigma\rules'] path_list = get_inputs(BASE_PATH, True) rules_map = {} for sigmafile in get_inputs(BASE_PATH, True): f = sigmafile.open(encoding='utf-8') parser = SigmaCollectionParser(f) rule = next(iter(parser)) rules_map[rule['title']] = rule
Deduplicando las mismas reglas, emerge la siguiente imagen:
Como parte de una lista única de reglas, obtenemos las siguientes distribuciones:
Por tipo de origen del evento:Estadísticas un poco más grandes
- Windows ~ 80%
- Sysmon ~ 53%
- Proxy ~ 8%
- Linux ~ 4%
Básicamente, el contenido actual se centra en el sistema Windows y Sysmon, en particular, las reglas para el resto de los sistemas son algunas.
Por disponibilidad de contenido:Resulta que los desarrolladores de reglas Sigma marcadas como estables menos del 20% de todas las reglas existentes.
Para resumir
En las fuentes disponibles públicamente hay una gran cantidad de reglas. Se actualizan periódicamente, y las reglas para detectar indicadores, y a veces incluso el técnico de las empresas APT de más alto perfil, aparecen rápidamente.
Existen muchas restricciones para aplicar las reglas en la vida real:
- Hay muchas reglas para Microsoft Sysmon, que rara vez se usa en la empresa.
- Hay muchas reglas que realmente realizan comprobaciones de IoC (hashes, direcciones IP, URL, agentes de usuario). Dichas reglas se vuelven rápidamente obsoletas, y existen mecanismos más efectivos para encontrar IoC que las reglas.
- Una gran cantidad de contenido experimental, respectivamente, se imponen requisitos adicionales en las pruebas de alta calidad antes de la puesta en servicio.
En Infosecurity, utilizamos el contenido de las reglas de Sigma como una fuente adicional de conocimiento para una detección más efectiva de incidentes. Si encontramos algo interesante, ya lo implementaremos dentro del marco de nuestras reglas de correlación, que tienen en cuenta tanto el núcleo en el que funcionan las reglas (Apache Spark) como los detalles de las infraestructuras y los medios de protección que utilizamos.