Como normalizar adequadamente o evento? Como normalizar eventos semelhantes de diferentes fontes sem esquecer ou confundir nada? Mas e se dois especialistas fizerem isso de forma independente? Neste artigo, compartilharemos uma metodologia de normalização comum que pode ajudar a resolver esse problema.


Imagem: Martinoflynn.com

Na maioria das vezes, as regras de correlação são baseadas em eventos normalizados. Assim, a normalização dos eventos e a correta execução dos mesmos afetam diretamente a precisão das regras de correlação.

Os problemas decorrentes da normalização dos eventos foram formulados no primeiro artigo ( aqui ) e as soluções foram propostas nos artigos subsequentes ( aqui e aqui ). Agora, resumimos o descrito anteriormente e formamos uma abordagem geral para normalizar eventos.

Para começar, lembramos quais ferramentas do nível de normalização desenvolvemos:

1. Esquema de campo genérico necessário para armazenar dados recuperados de eventos. Suas características:
   
   
   • Ele leva em consideração a presença de entidades no evento: Assunto, Objeto, Origem e Transmissor de eventos, bem como Recurso.
   • Fornece normalização correta nos casos em que o evento contém entidades de níveis e aplicativos de rede e quando possui mais de um Assunto e / ou Objeto.
   • Permite identificar e manter explicitamente a estrutura do processo de interação entre o Assunto e o Objeto.
2. Sistema de categorização de eventos capaz de refletir a semântica de um evento de TI ou IB.

Metodologia de Normalização de Eventos

Toda a metodologia para normalizar eventos consiste em três etapas:

1. Avaliação de especialistas do evento.
2. Definição do esquema de interação.
3. Definição de categoria de evento.

Para facilitar o entendimento de como a ferramenta funciona, selecionaremos um evento e consideraremos detalhadamente todas as etapas de normalização de acordo com nossa metodologia.

Suponha que tenhamos uma fonte - DBMS Oracle Database com o seguinte endereçamento de rede:

• IP : 10.0.0.1;
• Nome do host : myoracle;
• FQDN : myoracle.local.

A partir dessa fonte, o agente SIEM descarrega o seguinte evento:

Etapa 1. Avaliação especializada do evento

No início do processo de normalização de um evento, é importante entender do que se trata esse evento. Basta dizer sua essência para si mesmo. Se um especialista, desde o evento inicial, ainda não normalizado, não entende quais processos estão ocorrendo na fonte, estamos falando, com alta probabilidade, de normalizá-lo incorretamente. Então, de que tipo de operação correta das regras de correlação podemos falar?

O problema de quão bem o especialista interpreta corretamente o evento é real. Por exemplo, um especialista pode entender o que significa o próximo evento?



Se no exemplo original a essência puder ser capturada no texto do próprio evento, nesse caso, será necessário entender bem com qual fonte você está trabalhando e em quais casos ela gera um evento semelhante. Às vezes, você precisa implantar um estande separado com uma fonte para reproduzir totalmente a situação em que ele envia um evento complexo e dificilmente interpretado ao SIEM.

Vamos voltar ao exemplo original com um evento do banco de dados Oracle. Nesta fase, o especialista deve pensar assim:

" Como especialista, acredito que o evento inicial descreve o processo de revogação de uma função por um usuário de outro em um banco de dados Oracle ".

Etapa 2. Determinando o Esquema de Interação

A etapa anterior nos permite garantir que possamos entender pelo menos o significado geral do evento. Agora vamos analisar em detalhes como distinguir entidades e determinar o esquema de sua interação.

De acordo com essa metodologia, para cada esquema de interação, é necessário descrever as regras para a distribuição dos identificadores principais de entidades nos campos de um evento normalizado. Ao mesmo tempo, regras são definidas para:

1. Entidades no nível da rede
2. Entidades do nível do aplicativo.

É importante lembrar que existem esquemas nos quais o Sujeito é igual ao Objeto e igual à Fonte. Para tais esquemas, é necessário definir claramente as regras para o preenchimento dos campos das três entidades. Se isso não for feito, no nível das regras de correlação ou na busca de eventos, os problemas começarão e uma lógica adicional aparecerá para a correta interpretação dos campos vazios. Sobre isso - no artigo dedicado aos esquemas de interação .

Vamos ver como esta etapa da metodologia funciona no exemplo inicial:

• Esquema de interação no nível da rede : um esquema completo de coleta direta, sem transmissor.
• Esquema de interação no nível do aplicativo : interação através de um recurso.

Para esses esquemas, as seguintes regras de normalização podem ser definidas:

1. Entidades da camada de rede:
   
   • Assunto :
     
     • Campo: src.ip = <vazio>
     • Campo: src.hostname = alex_host
     • Campo: src.fqdn = <vazio>
   • Object
     
     • Campo: dst.ip = 10.0.0.1
     • Campo: dst.hostname = myoracle
     • Campo: dst.fqdn = myoracle.local
   • Origem (corresponde ao objeto) :
     
     • Campo: event_source.ip = 10.0.0.1
     • Campo: event_source.hostname = myoracle
     • Campo: event_source.fqdn = myoracle.local
   • Transmissor :
     
     • Campo: forwarder.ip = <vazio>
     • Campo: forwarder.hostname = <vazio>
     • Campo: forwarder.fqdn = <vazio>
   • Canal de interação :
     
     • Campo: interação.id = 2342594
     
     
2. Entidades do nível do aplicativo (coleção de elementos):
   
   • Assunto :
     
     • Campo: subject [1] .name = "Alex"
     • Campo: assunto [1] .type = "conta"
   • Object
     
     • Campo: objeto [1] .name = "Bob"
     • Campo: objeto [1] .type = "conta"
   • Recurso :
     
     • Campo: resource [1] .name = "MYROLE"
     • Campo: resource [1] .type = "role"

Etapa 3. Definindo uma categoria de evento

Depois que todas as principais entidades do evento foram identificadas, é necessário descrever a essência do processo refletido no evento e transferi-lo para a linguagem de normalização. Para esses fins, um sistema de categorização de eventos. O sistema de categorização de eventos foi discutido em detalhes em um artigo separado, agora vamos ver como ele funciona na prática.

Para unificar a normalização, o sistema de categorização define as seguintes regras:

1. Para cada categoria de cada nível de eventos de TI e de segurança da informação, um especialista forma um diretório com uma lista das informações que precisam ser encontradas no evento inicial e normalizadas.
2. Se um evento tiver sido atribuído a qualquer categoria, o especialista, de acordo com o diretório, é obrigado a encontrar as informações necessárias e normalizá-las.
3. Cada categoria define um conjunto de campos de esquema de eventos normalizados que precisam ser preenchidos.

Assim, a categoria selecionada para o evento estabelece uma correspondência direta entre:

• semântica de eventos;
• informações importantes a serem extraídas do evento, de acordo com a categoria afixada;
• um conjunto de campos do esquema de um evento normalizado no qual essas informações devem ser "colocadas".

Essa abordagem permite que você entenda claramente da categoria de qualquer evento quais dados estão em quais campos do evento normalizado.

Se, com o suporte de novas fontes, for necessário extrair adicionalmente algumas informações importantes dos eventos de uma determinada categoria, elas serão inseridas no diretório Nesse caso, você precisa de:

• definir regras para preencher os campos do esquema de eventos;
• realizar uma auditoria de normalização para eventos nesta categoria de todas as fontes anteriormente suportadas;
• Adicione novas informações aos eventos anteriormente normalizados.

Dessa forma, a consistência das alterações feitas é mantida. Considere o exemplo original.

De acordo com o sistema de categorização, este evento possui as seguintes categorias:

• Sistema de categorização : eventos de TI
• Categoria de primeiro nível (nível 1) : usuário e direitos
• Categoria de Segundo Nível (Nível 2) : Usuário
• Categoria de terceiro nível (nível 3) : manipulação

O diretório para esta categoria tem a seguinte aparência:

1. Ao normalizar eventos na categoria Usuário e Direitos , é importante entender:
   
   • Se a escalação de privilégios foi usada, em nome de quem o processo é implementado.
     
     • Campo: assunto [i] .assign
   • As ações foram bem-sucedidas.
     
     • Campo: result.status
   • Qual é o código de retorno.
     
     • Campo: result.status.code
   
   
2. Ao normalizar os eventos da categoria Usuário , é importante entender:
   
   • Existe alguma informação sobre o endereço IP, nome do host ou fqdn da máquina do usuário.
     
     • Campos: src.ip, src.hostname, src.fqdn
     • Campos: dst.ip, dst.hostname, dst.fqdn
   • Em qual conta o usuário se conectou.
     
     • Campos: assunto [i] .name, objeto [i] .name
   • Existe alguma informação sobre sua conta no sistema operacional.
     
     • Campos: assunto [i] .osname, objeto [i] .osname
   • Existe alguma informação de conta de domínio?
     
     • Campos: assunto [i] .domínio, objeto [i] .domínio
   • Existe alguma informação sobre o aplicativo do usuário.
     
     • Campos: assunto [i] .application, objeto [i] .application
   
   
3. Ao normalizar eventos na categoria Manipulação , é importante entender:
   
   • Tipo de operação.
     
     • Campo: transaction.type
   • O que mudou.
     
     • Campo: objeto [i] .name, objeto [i] .type - ao alterar contas
     • Campo: recurso [i] .name, recurso [i] .type - ao alterar os recursos
   • O que mudou.
     
     • Campo: objeto [i] .modify
     • Campo: recurso [i] .modify
   • Se a operação estava em um recurso, quem é o proprietário.
     
     • Campo: resource [i] .owner

Demos este guia para demonstrar o princípio de sua formação; portanto, ele não pretende ser preciso e completo.

Como resultado, o evento normalizado por essa metodologia se parece com o seguinte:


Um exemplo de um evento normalizado na terceira etapa da metodologia.

Conclusões

A experiência mostra que geralmente são erros de normalização e a ausência de regras de normalização uniformes que geralmente levam a falsos positivos nas regras de correlação. Agora, temos uma abordagem que permite, se não se livrar, pelo menos minimizar o impacto do problema.

Então, para resumir - a abordagem inclui três etapas:

• Etapa 1 O especialista tenta entender a essência geral do fenômeno descrito no evento inicial.
• Etapa 2 O especialista identifica as principais entidades da rede e o nível do aplicativo no evento: Assunto, Objeto, Origem, Transmissor, Recurso, Canal de interação. Ele os isola no evento e determina o padrão de interação dessas entidades. Cada esquema gera regras para colocar essas entidades nos campos de um evento normalizado - um esquema. Isso foi descrito em detalhes em um artigo dedicado aos esquemas de interação entre entidades.
• Etapa 3 O especialista determina a categoria do primeiro, segundo e terceiro níveis. Para cada categoria, ele cria um diretório que inclui uma descrição dos dados que são importantes para encontrar no evento durante sua normalização, informações sobre quais campos do evento normalizado é necessário "colocar" os dados encontrados.

Agora, a partir da construção das regras de correlação para “trabalhar fora da caixa”, estamos separados apenas pelo problema de constantes mudanças nas próprias entidades - ativos. Seus endereços mudam, novos ativos são introduzidos, os antigos são desativados, os nós do cluster alternam e as máquinas virtuais mudam de um datacenter para outro e, às vezes, mesmo com uma alteração no endereçamento. Como superar esses problemas, falaremos no próximo artigo do ciclo.

---

Série de artigos:

Profundidades do SIEM: correlações prontas para uso. Parte 1: Marketing puro ou um problema insolúvel?

Profundidades do SIEM: correlações prontas para uso. Parte 2. Esquema de dados como reflexo do modelo "mundo"

Profundidades do SIEM: correlações prontas para uso. Parte 3.1. Categorização de eventos

Profundidades do SIEM: correlações prontas para uso. Parte 3.2 Metodologia de Normalização de Eventos ( Este artigo )

Profundidades do SIEM: correlações prontas para uso. Parte 4. Modelo do sistema como um contexto de regras de correlação

Profundidades do SIEM: correlações prontas para uso. Parte 5. Metodologia para o desenvolvimento de regras de correlação