Tudo o que você sempre quis saber sobre as regras da Sigma. Parte 1

Na criação de produtos e no desenvolvimento de conhecimentos, somos guiados principalmente pelo desejo de melhorar a segurança das empresas. No entanto, nossa pesquisa é dirigida por mais do que atendimento ao cliente. Por um longo tempo, tínhamos o desejo de realizar pesquisas para a comunidade de segurança da informação de forma voluntária, e agora estamos fazendo isso ativamente: publicamos ataques de rede de alto perfil no Twitter , fornecemos regras de análise de tráfego para o serviço ANY.RUN e adicionamos regras ETOpen . Existem muitos projetos de código aberto para os quais você pode enviar uma solicitação de recebimento, mas até recentemente, as detecções de host ainda não chegavam a suas mãos.



E então aprendemos que um grupo de entusiastas decidiu organizar um sprint de duas semanassobre como escrever regras para o projeto Sigma , que foi criado para desenvolver um formato unificado para descrever regras para sistemas SIEM e é suportado por mais de 140 participantes. Estávamos interessados ​​nas notícias do evento, pois, como fornecedor do SIEM , acompanhamos de perto o desenvolvimento da comunidade.



Imagine nossa surpresa quando os organizadores entraram em contato conosco e convidaram a equipe do PT Expert Security Center para participar do sprint! Os participantes do evento formaram o Open Security Collaborative Development (OSCD) - uma iniciativa internacional de especialistas em segurança da informação que visa disseminar conhecimento e melhorar a segurança do computador em geral. Aceitamos com prazer participar de forma a aplicar nossa experiência em benefício da segurança comum.

Como este artigo surgiu

Quando começamos a escrever as regras, percebemos que não havia uma descrição exaustiva da sintaxe das regras Sigma, especialmente em russo. As principais fontes de conhecimento são o GitHub e a experiência pessoal. Existem vários bons artigos (em russo e em inglês ), mas neles o foco é deslocado da sintaxe das regras para a análise do escopo de aplicabilidade das regras Sigma ou para a criação de uma regra específica. Decidimos tornar mais fácil para os iniciantes se familiarizarem com o projeto Sigma, compartilharem nossa própria experiência, coletarem em um só lugar informações sobre a sintaxe e os recursos de seu uso. E, é claro, esperamos que isso ajude a expandir a iniciativa OSCD e criar uma grande comunidade no futuro.



Como havia muito material, decidimos publicar uma descrição em uma série de três artigos:

1. , ( ).
2. . , .
3. (, , , , ) .

Sigma

Sigma é um formato unificado para descrever regras de detecção com base nos dados dos logs. As regras são armazenadas em arquivos YAML separados. O Sigma permite que você escreva uma regra usando uma sintaxe unificada uma vez e, em seguida, usando um conversor especial, obtenha a regra na sintaxe de um sistema SIEM suportado. Além da sintaxe das consultas de vários sistemas SIEM, há suporte para a criação de consultas dos seguintes tipos:

• Consulta de Elasticsearch,
• linha de lançamento do utilitário grep com os parâmetros necessários,
• Logs de auditoria do Windows String do PowerShell.

Os dois últimos tipos são notáveis ​​pelo fato de não exigirem software adicional para analisar logs. O utilitário grep e o interpretador do PowerShell são suportados imediatamente no Linux e Windows, respectivamente.



A existência de um formato unificado para descrever detecções com base em logs facilita o compartilhamento de conhecimento, o desenvolvimento de segurança de código aberto e ajuda a comunidade de segurança da informação a combater ameaças emergentes.

Sintaxe geral

Antes de tudo, deve-se dizer que existem partes obrigatórias e opcionais da regra. Isso está documentado no wiki oficial do GitHub. O resumo da regra (fonte: Wiki oficial) é apresentado abaixo:







Quase qualquer regra pode ser dividida em três partes:

1. atributos que descrevem a regra (meta informações);
2. atributos que descrevem fontes de dados;
3. atributos que descrevem as condições para acionar a regra.

Cada uma das peças corresponde ao alto-nível exigido atributos título (para além do título, o último grupo inclui os outros atributos de alto nível opcionais), logsource e detecção .



Há mais um recurso da estrutura de regras que vale a pena falar. Como as regras são descritas na linguagem de marcação YAML, os desenvolvedores do Sigma encontraram alguma utilidade para isso, porque o formato YAML permite que vários documentos YAML sejam colocados em um arquivo. E para Sigma - várias regras para combinar em um arquivo, ou seja, criar "coleções de regras". Essa abordagem é conveniente quando existem várias maneiras de detectar um ataque e você não deseja duplicar a parte descritiva (como será descrito na seção correspondente, é possível duplicar não apenas a parte descritiva da regra).



Nesse caso, a regra é convencionalmente dividida em duas partes:

• uma parte com atributos gerais para itens de coleção (geralmente todos os campos, exceto as seções de origem de logs e detecção),
• uma ou várias partes que descrevem a detecção (seções fonte e detecção de logs).

Se o arquivo contiver uma única regra, essa declaração também será verdadeira, pois estamos obtendo uma coleção degenerada de uma regra. Coleções de regras serão discutidas em detalhes na terceira parte desta série de artigos.



A seguir, veremos um exemplo de regra hipotética. Deve-se notar que os comentários neste formulário geralmente não são usados ​​em regras, aqui são apenas para descrever campos.

Descrição da regra típica

Um exemplo de criação de uma regra Sigma

Antes de descrever os detalhes da sintaxe e falar sobre os recursos das regras Sigma, vamos considerar um pequeno exemplo de criação de uma regra para deixar claro de onde, na prática, esses ou esses valores de atributos vêm. Há um bom artigo sobre esse tópico em inglês. Se você já tentou escrever suas próprias regras e descobriu quais dados precisam ser especificados no atributo do arquivo YAML, prossiga para a próxima seção com uma descrição detalhada da seção de fontes de eventos (também chamaremos fontes de log desta seção).



Vamos descrever como criar uma regra que detecta o uso de SettingSyncHost.exe como LIFE (BOLOBIN). A criação de regras geralmente envolve três estágios:

1. realizando um ataque e coletando os logs necessários,
2. descrição da detecção como regra,
3. verificando a regra criada.

Conduzindo um ataque

A idéia para a regra está bem documentada no blog Hexacorn . Após uma leitura cuidadosa, fica claro quais etapas precisam ser seguidas para repetir o resultado descrito no artigo:

1. Copie o programa que você deseja executar para qualquer diretório gravável. O artigo sugere escolher% TEMP%, no entanto, você pode escolher o caminho de sua escolha. Vale a pena considerar que um subdiretório será criado nesse diretório com o nome que você especificar na etapa 4.
2. , , , (wevtutil.exe, makecab.exe, reg.exe, ipconfig.exe, settingsynchost.exe, tracelog.exe). , findstr.exe. , SettingSyncHost.exe Binary Search Order Hijacking (MITRE ATT&CK ID: T1574.008).
3. , ( settingsynchost.exe cmd PowerShell, cd < >).
4. : c:\windows\system32\SettingSyncHost.exe -LoadAndRunDiagScript <___>
5. SettingSyncHost.exe.

O Sysmon é instalado no sistema com um arquivo de configuração do projeto sysmon-modular . Assim, a coleta de logs foi realizada automaticamente. Que tipo de logs são úteis para gravar uma detecção será visto durante a gravação de uma regra.

Descrição da detecção na forma de uma regra Sigma

Nesta etapa, são possíveis duas abordagens: encontre uma regra existente mais próxima da lógica de detecção e modifique-a para atender às suas necessidades ou escreva uma regra do zero. Nos estágios iniciais, recomenda-se manter a primeira abordagem. Para maior clareza, escreveremos uma regra usando a segunda abordagem.



Criamos um novo arquivo e tentamos descrever de forma sucinta e sucinta sua essência no nome. Aqui você deve aderir ao estilo das regras existentes. No nosso caso, escolhemos o nome win_using_settingsynchost_to_run_hijacked_binary.yml. Em seguida, começamos a preenchê-lo com conteúdo. Vamos começar preenchendo as meta informações no início da regra. Já temos todos os dados necessários para isso.

Descrevemos brevemente que tipo de ataque a regra detecta em campotitle, explicações mais detalhadas - no campo de descrição, para novas regras, é habitual definir status: experimental. O identificador exclusivo pode ser gerado de várias maneiras; no Windows, a maneira mais fácil é executar o seguinte código em um intérprete do PowerShell:

PS C:\> "id: $(New-Guid)"
id: b2ddd389-f676-4ac4-845a-e00781a48e5f

O restante dos campos fala por si, apenas observarei que é aconselhável fornecer links para fontes que ajudaram a entender o ataque. Isso ajudará as pessoas que entenderão melhor essa regra e também é uma homenagem aos esforços feitos pelo autor do estudo original para descrever o ataque.



Nossa regra neste estágio é a seguinte:







Em seguida, você precisa descrever as fontes dos logs. Como mencionado acima, contaremos com os logs do Sysmon; no entanto, com o advento de categorias genéricas, é habitual usar a categoria process_creation para criar processos. Mais sobre categorias generalizadas serão discutidas abaixo. Observe que é habitual escrever comentários e conselhos sobre a configuração de fontes no campo de definição, como os recursos de configuração do Sysmon:







Agora é necessário descrever a lógica de detecção. Esta é a parte que consome mais tempo. Esse ataque pode ser detectado por vários critérios; nosso exemplo não pretende abranger todas as formas possíveis de detecção; portanto, descreveremos uma das opções possíveis.



Se você observar os eventos que aconteceram, poderá criar a seguinte cadeia.

Primeiro, iniciamos o processo (PID: 4712) com a linha inicial c: \ windows \ system32 \ SettingSyncHost.exe -LoadAndRunDiagScript join_oscd







Observe que o diretório de trabalho atual do processo é o diretório TEMP do usuário.



Em seguida, o processo em execução cria um arquivo em lotes e inicia sua execução.











O processo de execução de um arquivo em lote de instruções recebeu o identificador 7076. Para uma análise mais aprofundada dos eventos, consulte o arquivo ipconfig.exe de inicialização, que não contém arquivos de sistema inerentes e o meta Plus está localizado na pasta com arquivos temporários:







propõe-se que seja considerado um sinal de processos de inicialização de ataques, executáveis ​​que não mentem no diretório do sistema (C: \ Windows \ System32) e também se a linha de inicialização do processo pai contiver as substrings “cmd.exe / c”, “RoamDiag.cmd” e “-outputpath”. Vamos descrever isso na sintaxe Sigma e obter a regra final (uma análise detalhada das construções que podem ser usadas para descrever a lógica de detecção será fornecida na próxima parte de nossa série de artigos sobre Sigma):

Verificando se a regra funciona

Iniciamos o conversor em uma consulta do PowerShell:







Para o nosso caso, essa consulta não fornecerá o resultado desejado, pois o filtro de exclusão também encontra o caminho para a imagem do arquivo executável do processo pai. Portanto, simplesmente indicamos que não deve haver uma letra t antes da palavra Imagem - o fim da palavra Pai:







Vemos que nosso evento foi encontrado. A regra funciona.



É assim que as regras da Sigma são criadas na prática. A seguir, descreveremos detalhadamente os campos responsáveis ​​pela detecção, ou seja, a descrição das fontes de log.

Detectar descrição

A parte principal da regra é a descrição da detecção, pois é onde as informações estão contidas sobre onde e como procurar sinais de um ataque. Esta informação está contida nos campos dos atributos de origem de logs (onde) e detecção (como). Neste artigo, examinaremos mais de perto a seção de origem de logs e descreveremos a seção de detecção na próxima parte de nossa série.

Descrição da seção de fontes de eventos (atributo de origem de logs)

A descrição das fontes de eventos está contida no valor do campo de origem de logs . Esta seção descreve as fontes de dados das quais os eventos para a seção de detecção serão entregues (o atributo de detecção será discutido na próxima seção). A seção descreve a própria fonte, a plataforma e o aplicativo necessários para a detecção. Ele pode conter três atributos que são processados ​​automaticamente por conversores e um número arbitrário de elementos opcionais. Campos básicos:

• Categoria - descreve as classes de produtos. Exemplos de valores para este campo: firewall, web, antivírus. Além disso, o campo pode conter categorias generalizadas, que serão discutidas abaixo.
• Produto é um produto de software ou sistema operacional que cria logs.
• Serviço - restrição de logs para um determinado subconjunto de serviços, por exemplo "sshd" para Linux ou "Segurança" para Windows.
• Definição - um campo adicional para descrever os recursos da fonte, por exemplo, requisitos para configurar a auditoria (raramente usado, um exemplo de regra com esse campo pode ser encontrado no GitHub ). É recomendável usar esse atributo se a fonte tiver algum detalhe.

 

O wiki oficial no GitHub define um conjunto de campos que devem ser usados ​​para que as regras sejam produto cruzado. Esses campos estão resumidos na tabela abaixo.





A seguir, descreveremos mais detalhadamente algumas fontes de logs, indicando os campos de eventos usados ​​e dar exemplos de regras nas quais esses campos são usados.

Campos de evento da categoria de proxy

Campos de evento do firewall

Campos de eventos da categoria de servidor da Web

Categorias generalizadas

Como o Sigma é um formato generalizado para descrever regras de detecção baseadas em log, a sintaxe de tais regras deve ser capaz de descrever a lógica de detecção para diferentes sistemas. Alguns sistemas usam tabelas com dados agregados em vez de eventos, e dados de diferentes fontes podem aparecer para descrever a mesma situação. Para unificar a sintaxe e resolver problemas semelhantes, foi introduzido um mecanismo genérico de fontes de log. No momento, uma dessas categorias foi criada - process_creation. Você pode ler mais sobre isso no blog patzke.org . A lista de campos para esta categoria pode ser encontrada na página de taxonomia (esta página também descreve outras categorias suportadas).

Campos de evento de categoria generalizada process_creation

ATUALIZAR

Em preparação para este artigo, novas categorias genéricas foram adicionadas:

• network_connection (exemplo sysmon_powershell_network_connection )
• dns_query (exemplo sysmon_regsvr32_network_activity )
• registro_evento (exemplo sysmon_rdp_settings_hijack )
• file_creation
• process_access (exemplo sysmon_lsass_memdump )
• image_load (exemplo sysmon_mimikatz_inmemory_detection )
• process_terminated

Todos eles envolvem informações duplicadas nos eventos de log do Windows e nos eventos de log do Sysmon. Recomendamos que você use categorias generalizadas existentes ao escrever suas regras. Como o projeto está em desenvolvimento ativo, é aconselhável acompanhar o surgimento de novas categorias e atualizar suas regras de acordo com outras inovações.

Estatísticas de uso da fonte de eventos nas regras existentes

A tabela abaixo mostra as construções mais comuns para descrever fontes de log. Provavelmente, você encontrará entre eles o que melhor se adequa à sua regra.



Estatísticas sobre o uso de uma combinação de campos de descrição para algumas das fontes mais comuns (um traço significa a ausência desse campo):

Dicas para escrever regras

Ao escrever uma nova regra, são possíveis as seguintes situações:

1. A origem correta do evento já foi usada nas regras existentes.
2. Não há uma regra única no repositório que use essa fonte de eventos.

Se você se deparar com o primeiro caso, use uma das regras existentes como modelo. Talvez a fonte de log necessária já esteja sendo usada em outras regras, isso significa que os autores de plug-ins (conversores de back-end) para diferentes sistemas SIEM, provavelmente, levaram isso em consideração em seus mapeamentos e sua regra deve ser processada corretamente imediatamente.



Na segunda situação, é necessário, usando o exemplo de regras existentes, entender como usar os identificadores de categoria, produto e serviço corretamente. Ao criar sua própria fonte de log, é recomendável adicioná-la a todos os mapeamentos de back-end existentes. Outros colaboradores ou até desenvolvedores podem fazer isso, o principal é informar sobre essa necessidade.



Criamos uma visualização da combinação dos campos de descrição da fonte de log nas regras existentes:

Distribuição de fontes de log

Use estatísticas para combinações de subcampos de atributo de origem de log

Neste artigo, demos um exemplo de criação de uma regra simples e falamos sobre a descrição das fontes de eventos. Agora você pode aplicar o conhecimento adquirido, examinar as regras no repositório Sigma e descobrir quais fontes são usadas em uma regra específica. Siga nossas publicações: na próxima parte, examinaremos a parte mais difícil das regras da Sigma - a seção que descreve a lógica de detecção.



Autor : Anton Kutepov, especialista do departamento de serviços especializados e desenvolvimento de tecnologias positivas (PT Expert Security Center)