3. Formato de firma de registro universal de Sigma
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 del departamento de inteligencia de amenazas haya disfrutado de la firma, pero el formato 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 una estrategia de la organización. También puede haber razones técnicas o simplemente de licencia, lo que significa que solo ciertos registros se incorporan al SIEM, mientras que el resto va a lo que se llama un lago de datos. Diferentes repositorios de registros significan que se deben utilizar diferentes lenguajes de consulta para escribir firmas de registros.
Sigma es un proyecto de código abierto diseñado para resolver estos desafíos. Consta de tres partes:
(1) Especificación del lenguaje para el formato general de la regla Sigma.
(2) Una biblioteca de recursos que contiene más de 1000 reglas de tecnología de ataque.
(3) Herramientas para convertir reglas Sigma en varios formatos de consulta.
Todo esto es de código abierto y se puede encontrar en la organización SigmaHQ GitHub. Puede clonar localmente usando la siguiente línea de comando:
git clone /SigmaHQ/pySigma.git
Tomemos la regla Sigma para CVE-2020-0688 como ejemplo (Figura 2) . Esta es la última vulnerabilidad de Exchange Server que los actores de amenazas están explotando 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 las reglas de Sigma, se describe en otra publicación del blog:
Las reglas de Sigma tienen cinco componentes:
1. Metadatos, que incluyen un título, un identificador único y alguna información adicional que permita al analista contextualizar la regla de detección.
2. Una definición de origen de registro que vincula la firma a un registro específico, en este caso un registro de servidor web.
3. La regla de detección en sí se define en una definición que asocia campos de eventos de registro con valores específicos para el intento de explotación.
4. Estas pruebas están asociadas a 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, gravedad y enlaces a tácticas y técnicas de MITRE ATTamp;CK.
La Figura 3 muestra otra regla Sigma para otra vulnerabilidad de Exchange Server (CVE-2021-26857).
Los elementos que componen la regla Sigma son los mismos que en 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 uno de los muchos productos Endpoint Detección y Respuesta (EDR). El proceso de trabajo de mensajería unificada de Exchange Server 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 las reglas de detección y sus condiciones (2).
El siguiente paso es convertir las reglas de Sigma al lenguaje de consulta de destino utilizando la herramienta de conversión de Sigma sigmac.
Puede instalar la herramienta usando pip:
pip install sigmatools
O, en un entorno virtual de Python, use Pipenv para exportar todas las dependencias desde un repositorio Sigma clonado:
pipenv shell
Supongamos que la consulta resultante debe estar en un SIEM basado en elasticsearch utilizando el esquema de nombres de campos ECS. Simplemente ejecute el siguiente comando en el directorio raíz del clon de la biblioteca Sigma:
tools/sigmac -t es-qs -c ecs-proxy/web/web_cve_20_20_0688_msexchange.yml
-t selecciona el convertidor Sigma como backend, que es responsable de convertir las reglas al lenguaje de consulta de destino. El backend es-qs convierte las reglas en cadenas de consulta de Elasticsearch que se pueden pegar en Kibana. El parámetro -c selecciona la configuración. Configure el proxy ECS, proporcionado con el convertidor Sigma, e implemente el esquema de nombres ECS para los registros del proxy. La consulta resultante será:(http.request.method: "GET" AND url.original.keyword: (*\/ecp\/* OR *\/owa\/*) AND url. palabra clave original: *__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 crear eventos de generación para los procesos en los puntos finales. 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
Hay dos tipos de líneas de comando proporcionado en la configuración de la línea de comando. Configure sysmon para que corresponda a fuentes de registro e identificadores de eventos específicos. winlogbeat asigna nombres de campos en reglas Sigma al esquema ECS utilizado por winlogbeat.
La consulta de resultado 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 registros de auditoría de Windows, la única forma de cambiar la palabra clave es cambiar algunos parámetros de la línea de comando para convertir 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
Dará como resultado la siguiente consulta de Splunk:
((EventCode="4688" source="WinEventLog:Security") ParentProcessName="* UMWorkerProcess.exe" NOT ((NewProcessName=") *wermgr .exe" OR NewProcessName="*WerFault.exe")))
Dado que el proyecto Sigma es de código abierto, depende de las contribuciones.
Sigma Wiki contiene guías de creación de reglas y plantillas para crear nuevas reglas. No lo dude: revisaremos las reglas y solucionaremos problemas o haremos sugerencias antes de fusionar una solicitud de extracción.
La retroalimentación también es valiosa, por ejemplo, si una regla de detección causa falsos positivos bajo ciertas condiciones, la retroalimentación puede identificar problemas o si la regla se ha utilizado activamente como prueba y se considera útil, entonces una pequeña cantidad; La solicitud de extracción puede cambiar el estado de la 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, la biblioteca pySigma está pasando por una reescritura completa. Además, se está desarrollando una nueva CLI, pero aún no se ha lanzado. En el futuro, los backends se mantendrán como un proyecto separado, muchos de los backends actualmente en el convertidor Sigma deberán trasladarse a psigma, o algunos de los backends que actualmente ya no se mantienen deberán recibir mantenimiento.