Sou Sergey Rublev, chefe do SOC (Security Operations Center) na Infosecurity.
Neste artigo, examinarei em detalhes o ambicioso projeto
Sigma Rules , cujo lema é: "Sigma para logs é como Snort para tráfego e Yara para arquivos".
Serão cerca de três aspectos:
- Aplicabilidade da sintaxe da regra Sigma para manter uma base de conhecimento de scripts de detecção de ameaças
- Recursos de ferramentas de geração de regras para sistemas SIEM in a box
- Valor para o SOC do conteúdo atual dos repositórios públicos de regras Sigma
Era uma vez, em uma galáxia distante, distante
Tudo começou há alguns anos atrás, quando as árvores eram grandes e nossa equipe de monitoramento ainda era pequena. Enfrentamos muitas perguntas, quase todas as equipes que crescem em uma linha de três pessoas passam por isso.
As razões para o surgimento de perguntas são diferentes:
- Crescimento da equipe
- Rotatividade de pessoal
- Um grande número de sistemas heterogêneos para monitoramento
Se você precisar de suporte já configurado por alguém SIEM, o número de perguntas aumenta como uma avalanche.
Biblioteca de Casos de Uso
A experiência mundial na construção de centros de monitoramento já encontrou uma solução para organizar o caos e seu nome é a biblioteca de estudos de caso. O objetivo de cada caso é descrever de maneira abrangente a solução para um problema na estrutura do monitoramento de segurança da informação.
A composição do conhecimento estabelecida em cada caso pode variar; procedemos do seguinte conjunto:
- Objetivo - a tarefa resolvida pelo caso
- Ameaça - a ameaça que a regra de detecção procura detectar.
- Stakeholders - pessoas interessadas nesta regra: IB / TI / Negócios
- Requisitos de dados - o conjunto de dados necessário para identificar uma ameaça
- Lógica - lógica da regra de detecção de ameaças
- Teste - um algoritmo para testar a correção da regra de detecção
- Prioridade - prioridade do processamento de eventos por caso (geralmente calculada a partir do dano potencial de uma ameaça implementada com sucesso)
- Saída - Uma lista de ações para analisar o alerta, uma descrição das saídas corretas do procedimento de análise e a composição dos dados registrados nos resultados da análise
Exemplo de caso de uso para a tarefa de detectar a comunicação com o servidor de gerenciamento de botnet (vulgarmente conhecido como C&C ou apenas C2):
O exemplo é bastante simplificado: na realidade, com uma descrição adequada, um caso cresce em um documento de várias páginas.
Naquele momento, quando o número de casos excedeu várias dezenas, começamos a procurar ferramentas prontas para manter essa base de conhecimento, de preferência tendo, além de amigável ao ser humano, também algum tipo de interface amigável para o trabalho.
Projeto Sigma
O projeto Sigma certamente merece consideração no contexto da base de conhecimento sobre regras de detecção de incidentes. Tudo começou em 2016, e eu o acompanho quase desde o começo.
De fato, o projeto consiste em
- A Sigma se governa
- Utilitários para converter regras em consultas para vários sistemas SIEM
A lista SIEM é impressionante: quase todas as soluções populares de análise de eventos estão presentes. Mais sobre tudo em detalhes e em ordem.
Sintaxe da regra
Regras Sigma são documentos YAML que descrevem um cenário para detectar um ataque específico. Sintaticamente, as regras consistem nos seguintes blocos:
Meta informação
Peça descritiva para estruturar e simplificar a busca pelas regras necessárias.
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
Também gostaria de observar que muitas regras já são fornecidas com links para a técnica de ataque, de acordo com a metodologia MITRE ATT & CK.
Declaração de fonte de dados
Descrição da fonte com base nos eventos em que a lógica de detecção é implementada.
logsource: product: windows service: security
É sintaticamente possível descrever o serviço final de um produto específico e uma categoria inteira de sistemas.
Declaração de lógica de processamento
No nível da lógica de detecção, são descritos a seguir:
- Padrões pesquisados
- Valores de determinados campos no log
- Prazo
- Funções agregadas
A lógica pode ser trivial, por exemplo, condições impostas a um conjunto de campos:
detection: selection: EventID: 5140 ShareName: Admin$ filter: SubjectUserName: '*$' condition: selection and not filter
e 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
Os meios expressivos da linguagem, embora não sejam universais, ainda são bastante amplos e permitem descrever um grande número de casos para identificar ataques.
Ferramentas de desenvolvimento de regras
Além do seu editor de texto favorito para YAML, a interface WEB da SOC Prime também está disponível, o que permite validar a sintaxe de uma regra já escrita e criar regras manualmente a partir de blocos gráficos.
Sigma como uma ferramenta da base de conhecimento
Para resumir um breve resumo.
No momento, a sintaxe das regras concentra-se principalmente na descrição da lógica de detecção de ameaças e não se destina a uma descrição abrangente do caso de uso; portanto, não funcionará para manter uma biblioteca completa usando apenas regras Sigma.
Para a estrutura de casos de uso que escolhemos, o Sigma fecha apenas metade (Objetivo, Requisitos de dados, Lógica e Prioridade).
Converta para vários SIEM
Como somos prestadores de serviços SOC, a ideia de manter todos os nossos desenvolvimentos de acordo com as regras de correlação em algum formato universal e no estágio de implementação para converter para o formato SIEM desejado nos pareceu muito atraente.
O projeto inclui utilitários de console para gerar solicitações de eventos no formato de vários SIEMs. Considere o que é a conversão e o que está por baixo dela.
A conversão ocorre em 3 etapas:
- Regras de análise - acho que isso está claro: o documento YAML é classificado em blocos de componentes
- Redução à taxonomia SIEM
A necessidade desse estágio está relacionada ao fato de que a normalização nos sistemas SIEM é implementada de uma maneira um pouco diferente; portanto, as declarações das regras Sigma precisam ser reduzidas à taxonomia dos eventos do SIEM selecionado. - Geração de solicitação para SIEM
Para que esta etapa funcione, é necessário outro componente - um back-end para este SIEM.
De fato, o back-end é um plug-in para o utilitário de conversão, que contém a lógica para converter para o formato de solicitação final no SIEM. Os blocos de detecção e de origem de log são convertidos levando em consideração o mapeamento de campos previamente sobrepostos, informações adicionais específicas do SIEM são adicionadas.
Como resultado, iniciar o utilitário de conversão fica assim:
Os seguintes parâmetros são passados:
- Target SIEM
- A regra
- Arquivo de mapeamento para este SIEM
O SOC Prime também possui uma interface pronta para a função de conversão (
uncoder.io )
Armadilhas da conversão
- Depois de estudar a mecânica da conversão, encontramos limitações significativas, o que nos impediu de converter todos os desenvolvimentos para o formato Sigma:
- O conversor opera apenas com uma solicitação. A regra de correlação no SIEM afeta mais aspectos: janela de tempo, agregação, ações com base nos resultados dos alertas identificados
- Os principais recursos de SIEMs individuais, como ActiveLists, não são levados em consideração.
- Detalhamento insuficiente do mapeamento de campo - como parte da configuração do mapeamento, os campos de apenas algumas fontes são descritos; portanto, tendo regras para várias dezenas de tipos diferentes de fontes de eventos no banco de dados, você terá que investir muito na escrita do mapeamento.
Base de regra
Vamos ver o que a base de regras Sigma disponível ao público carrega. Atualmente, o conteúdo está sendo adicionado ativamente a dois repositórios:
- O repositório principal do projeto
- Mercado de detecção de ameaças SOC SOC
As regras nos repositórios têm uma interseção diferente de zero.
O SOC Prime possui várias regras que se aplicam a assinaturas pagas; não considero seu conteúdo neste artigo.
Para análise, precisamos da biblioteca
sigmatools para Python e algumas habilidades de programação.
Para analisar e carregar regras de um diretório em um dicionário, você pode usar o seguinte 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
Desduplicando as mesmas regras, surge a seguinte imagem:
Como parte de uma lista exclusiva de regras, obtemos as seguintes distribuições:
Por tipo de fonte de eventos:Estatísticas um pouco maiores
- Windows ~ 80%
- Sysmon ~ 53%
- Proxy ~ 8%
- Linux ~ 4%
Basicamente, o conteúdo atual se concentra no sistema Windows e Sysmon, em particular, as regras para o restante dos sistemas são poucas.
Por disponibilidade de conteúdo:Acontece que os desenvolvedores das regras da Sigma marcaram como estáveis menos de 20% de todas as regras existentes.
Resumir
Nas fontes publicamente disponíveis, há um grande número de regras. Eles são atualizados regularmente, e as regras para a detecção de indicadores e, às vezes, até as técnicas das empresas de alto nível do APT, aparecem rapidamente.
Existem muitas restrições para a aplicação das regras na vida real:
- Existem muitas regras para o Microsoft Sysmon, que raramente são usadas na empresa.
- Existem muitas regras que realmente executam verificações de IoC (hashes, endereços IP, URLs, agentes do usuário). Essas regras rapidamente se tornam obsoletas e existem mecanismos mais eficazes para encontrar a IoC do que regras.
- Muitos conteúdos experimentais, respectivamente, são impostos a testes de alta qualidade antes do comissionamento.
Na Infosecurity, usamos o conteúdo das regras Sigma como uma fonte adicional de conhecimento para uma detecção mais eficaz de incidentes. Se encontrarmos algo interessante, já o implementaremos dentro da estrutura de nossas regras de correlação, que levarão em consideração o kernel no qual as regras funcionam (Apache Spark) e as especificidades das infraestruturas e os meios de proteção que usamos.