3. Sigma: formato de firma de registro universal
La mayoría de los ataques a sistemas y redes de TI se manifiestan en registros de eventos, que se almacenan en los sistemas SIEM de muchas organizaciones u otras soluciones de almacenamiento de registros. Esto los convierte en un buen lugar para detectar intrusos en su red. Sin embargo, no hay muchos desafíos.
El primer desafío es comprender y desarrollar una lista distintiva de técnicas de ataque. Esta suele ser una tarea que requiere mucho tiempo porque el ataque debe replicarse en un entorno de laboratorio y los registros específicos del ataque deben identificarse entre el ruido de fondo de los registros. Es posible que alguien de la comunidad de inteligencia de amenazas haya compartido la firma, pero en un formato que es incompatible con el SIEM de la organización. Convertir consultas de diferentes lenguajes de consulta y utilizar diferentes nombres de campos es una tarea propensa a errores.
Otro desafío es que muchas organizaciones almacenan registros en diferentes repositorios. Esto puede deberse a fusiones y adquisiciones, o puede ser la estrategia de una organización. También puede haber razones técnicas o simples razones de licencia, lo que significa que solo se incorporan registros específicos al SIEM, mientras que el resto va a lo que se llama un lago de datos. Diferentes repositorios de registros significan que las firmas de registros deben escribirse en diferentes lenguajes de consulta.
Sigma es un proyecto de código abierto que intenta resolver estos desafíos. Consta de tres partes:
(1) Especificación del lenguaje del formato de regla Sigma universal.
(2) Un repositorio que contiene más de 1.000 reglas técnicas de ataque.
(3) Herramientas para convertir reglas Sigma en varios formatos de consulta.
Es todo de código abierto y se puede encontrar en la organización SigmaHQ GitHub. Se puede clonar localmente usando la siguiente línea de comando:
git clone /SigmaHQ/pySigma.git
Tomemos como ejemplo la regla Sigma de CVE-2020-0688 (Figura 2 ). Esta es la última vulnerabilidad de Exchange Server que los actores de amenazas explotan activamente para afianzarse en las organizaciones que albergan instancias vulnerables de Exchange. La detección de intentos de explotación, que es la base de la regla Sigma, se describe en otra publicación de blog:
Esta regla Sigma tiene cinco componentes:
1. Metadatos, incluido A título, un identificador único y alguna información adicional que permite al analista contextualizar la regla de detección.
2. Definición del origen del registro, vincule la firma a un registro determinado, aquí está el registro del servidor web.
3. Las reglas de detección en sí se definen en definiciones que asocian campos de eventos de registro con valores específicos del intento de explotación.
4. Estos elementos de detección están vinculados con una condición.
5. Finalmente, las reglas contienen información adicional, como atributos de eventos interesantes, incluidos eventos que coinciden con la regla, falsos positivos conocidos, niveles de gravedad y enlaces a tácticas y técnicas de MITRE ATT&CK.
La Figura 3 muestra otra regla de Sigma dirigida a otra vulnerabilidad de Exchange Server, CVE-2021-26857.
Los elementos que componen la regla Sigma son los mismos que el primer ejemplo, pero la lógica de detección es completamente diferente. Esta regla describe un evento de creación de proceso (1) desencadenado por Sysmon o muchos productos EndpointDetection and Response (EDR). El proceso de trabajo de Mensajería unificada de un servidor Exchange normalmente no genera procesos, excepto en el caso de una falla, que a veces genera un proceso de Informe de errores de Windows, como se define en la regla de detección y su condición (2).
A continuación, utilice la herramienta de conversión de Sigma sigmac para convertir las reglas de Sigma al lenguaje de consulta de destino. La herramienta se puede instalar con pip:
pip install sigmatools
O en un entorno virtual Python, todas las dependencias se pueden derivar del repositorio Sigma clonado usando Pipenv:
pipenv shell
Supongamos que la consulta resultante debe usarse en un SIEM basado en elasticsearch que usa el esquema de nomenclatura de campos ECS.
Esto se puede hacer simplemente ejecutando el siguiente comando desde la raíz del clon del repositorio de Sigma: tools/sigmac -t es-qs -c ecs-proxy/web/web_cve_2020_0688_msexchange.yml
El El parámetro -t selecciona el backend del convertidor Sigma, que es responsable de convertir las reglas al lenguaje de consulta de destino. El backend es-qs se convierte en una cadena de consulta de Elasticsearch, que se puede pegar en Kibana. El parámetro -c selecciona una configuración. Configure ECS -proxy viene con el convertidor Sigma e implementa el esquema de nombres ECS para registros de proxy. La consulta resultante será:
(http.request.method:"GET" AND url.original.keyword:(*\/ecp\/* OR *\/owa\/*) AND url. original .keyword:*__VIEWSTATE\=*)
Ahora conviertamos la segunda regla. Esta vez, necesitamos alguna configuración adicional para asignar la fuente de registro general process_creation a una fuente de registro específica. Supongamos que estamos en un entorno que utiliza Elasticsearch como SIEM y Sysmon como fuente de registro para generar eventos para la creación de procesos en el punto final. El comando de conversión es el siguiente:
tools/sigmac -t es-qs -c sysmon -c winlogbeat rule/windows/process_creation/sysmon_cve_2021_26857_msexchange.yml
Se proporcionan dos configuraciones en el línea de comando. Configure sysmon para que corresponda con fuentes de registro e identificadores de eventos específicos. winlogbeat asigna los nombres de los campos en las reglas de Sigma al esquema ECS utilizado por winlogbeat. La consulta resultante es:
((winlog.event_id:"1" AND winlog.channel:"Microsoft\-Windows\-Sysmon\/Operational") AND winlog.event_data.ParentImage.keyword:*UMWorkerProcess .exe AND (NOT (winlog.event_data.Image.keyword:(*wermgr.exe OR *WerFault.exe))))
En un entorno que utiliza el registro de auditoría de Windows, simplemente cambie algunos parámetros de la línea de comandos a convierta las mismas reglas para Splunk SIEM:
tools/sigmac -t splunk -c windows-audit -c splunk-windows rule/windows/process_creation/sysmon_cve_2021_26857_msexchange.yml
Resultará en esta consulta de Splunk:
((EventCode="4688" source="WinEventLog:Security") ParentProcessName="*UMWorkerProcess.exe" NO ((NewProcessName="*wermgr.exe" OR NewProcessName=" *WerFault.exe")))
Debido a que el proyecto Sigma es de código abierto, depende de contribuciones. El proyecto está alojado en GitHub y se pueden contribuir nuevas reglas a través de la interfaz web navegando al directorio de destino y agregando un nuevo archivo:
Sigma Wiki contiene una guía de creación de reglas y una herramienta que puede ser Se utiliza para crear una nueva plantilla de reglas.
No lo dude: se verificarán las reglas y se solucionarán los problemas o se harán sugerencias antes de fusionar la solicitud de extracción.
Los comentarios también son valiosos, por ejemplo, si una regla de detección genera falsos positivos bajo ciertas condiciones, los comentarios pueden abrir un problema o si se ha utilizado activamente como detección y se puede confirmar como útil; entonces, una pequeña solicitud de extracción puede cambiar el estado de una regla de experimental a estable. Actualmente, la mayoría de las reglas aún se encuentran en la etapa experimental y hay mucho margen de mejora.
Otra área donde puedes contribuir es en las herramientas de conversión. Actualmente, se desarrolla una reescritura completa en la biblioteca pySigma. Además, se está desarrollando una nueva CLI, pero aún no se ha lanzado. En el futuro, el backend se mantendrá como un proyecto independiente. Muchos backends del convertidor Sigma actual deberán trasladarse a psigma, o algunos backends que actualmente ya no se mantienen deben ser mantenidos por alguien.