Com que frequência você ouve a declaração de que as regras de correlação fornecidas pelo fabricante SIEM não funcionam e são excluídas ou desativadas imediatamente após a instalação do produto? Nos eventos de segurança da informação, qualquer seção dedicada ao SIEM aborda esse problema de uma maneira ou de outra.

Vamos dar uma chance e tentar encontrar uma solução para o problema.



Na maioria das vezes, o principal problema é chamado de que as regras de correlação do fabricante SIEM não são inicialmente adaptadas à infraestrutura específica de um cliente específico.
Analisando os problemas expressos em diferentes locais, obtém-se a sensação de que o problema não tem solução. A implementação do SIEM ainda terá que refinar muito o que o fabricante entrega, ou descartar todas as regras e escrever suas próprias regras do zero, enquanto esse problema é inerente a todas as soluções de qualquer parte do quadrante do Gartner.

Involuntariamente, você se pergunta se tudo está realmente tão ruim e esse nó górdio não pode ser cortado? A expressão "Regras de correlação que funcionam imediatamente" é apenas um slogan de marketing que não custa nada?

Um artigo pode lhe interessar se:

• Você já está trabalhando com algum tipo de solução SIEM.
• Apenas planejando implementá-lo.
• Decidimos construir nosso SIEM com blackjack e correlações baseadas na pilha ELK, ou qualquer outra coisa.

Sobre o que serão os artigos

No âmbito desta série de artigos, listamos os principais problemas que impedem a implementação do conceito de "Regras de correlação que funcionam imediatamente" e também tentamos descrever uma abordagem sistemática para resolvê-los.

Devo dizer imediatamente que é este artigo que pode ser caracterizado por especialistas técnicos como: "água", "sobre nada". Tudo é assim, mas não exatamente. Antes de lidar com qualquer tarefa difícil, quero primeiro descobrir por que ela surgiu e qual é sua solução.

Para uma melhor compreensão de toda a gama de questões que serão apresentadas, darei a estrutura geral de toda a série de artigos:

• Artigo 1: Este artigo. Vamos falar sobre a declaração do problema e tentar entender por que geralmente precisamos das regras "Regras de correlação que funcionam imediatamente". O artigo será de natureza ideológica e, se ficar completamente chato, você poderá ignorá-lo. Mas, eu não aconselho fazer isso, porque em artigos futuros, frequentemente vou me referir a ele. Aqui discutiremos os principais problemas que estão em nosso caminho e os métodos para resolvê-los.
• Artigo 2: Hurrah! É aqui que chegamos aos primeiros detalhes da abordagem proposta para solucionar o problema. Vamos descrever como nosso sistema de informações seguras do SIEM deve "ver". Vamos falar sobre qual deve ser o conjunto de campos necessários para normalizar os eventos.
• Artigo 3: Descrevemos o papel da categorização de eventos e como a metodologia para normalização de eventos é construída com base. Mostramos como os eventos de TI diferem dos eventos de SI e por que eles devem ter princípios diferentes de categorização. Damos exemplos ao vivo do trabalho dessa metodologia.
• Artigo 4: Examine atentamente os ativos que compõem nosso sistema automatizado e veja como eles afetam o desempenho das regras. Também garantiremos que não seja tão simples com eles: eles precisam ser identificados e atualizados constantemente.
• Artigo 5: Aquilo para o qual tudo foi iniciado. Descrevemos a abordagem para escrever as regras de correlação, com base em tudo o que foi afirmado em artigos anteriores.

Declaração do problema e por que é importante

Vamos tentar esboçar, em palavras simples, nossa tarefa: "Eu, como cliente que comprou uma solução SIEM, assino para atualizar a base de regras e pago ao fabricante (e às vezes ao integrador) por suporte, quero receber imediatamente as regras de correlação estabelecidas. seria útil no meu SIEM. " Quanto a mim, desejo muito bom, não sobrecarregado com nenhuma limitação técnica arquitetural ou estrutural.

E agora, atenção, vamos supor que já resolvemos todos os problemas e que nossa tarefa já foi concluída. O que isso nos dá?

• Em primeiro lugar , economizamos os custos de mão de obra de nossos especialistas. Agora eles não precisam gastar tempo estudando a lógica de cada nova regra e adaptando-a às realidades de um sistema automatizado específico.
• Em segundo lugar , economizamos o orçamento desde não pedimos ao integrador ou a outra pessoa que escreva ou adapte as regras para uma taxa.
• Em terceiro lugar , todos os participantes significativos do mercado SIEM têm unidades e departamentos de pesquisa focados na análise de ameaças à segurança da informação. É importante usar a experiência deles, principalmente se pagarmos por isso.
• Quarto , estamos diminuindo nossa resposta a novas ameaças. Não vou escrever sobre a eternidade que passa entre o aparecimento de uma ameaça, o desenvolvimento de regras de correlação para sua detecção e implementação em um produto específico para um cliente em particular, muitos artigos já foram escritos sobre esse tópico.
• Em quinto lugar , isso nos aproxima da possibilidade de compartilhar entre nós regras unificadas que funcionarão para qualquer cliente, é claro, dentro da estrutura de uma solução SIEM específica.

Muitos especialistas técnicos que encontraram uma solução para o problema e leram até este ponto objetam imediatamente: "Sim, é claro que há vantagens, mas isso não é tecnicamente viável". Pessoalmente, acredito que a tarefa é bastante "desafiadora" e agora, tanto nos mercados ocidentais quanto russos, existem SIEMs que contêm todos os elementos necessários para resolvê-la. Quero focar sua atenção nisso - os produtos não permitem que você resolva o problema, mas contêm apenas todos os blocos necessários a partir dos quais, como do designer, você pode montar a solução que estamos procurando.

Eu acho isso muito importante, porque tudo o que será descrito posteriormente pode ser implementado em praticamente qualquer SIEM existente e maduro.

Chega de letras, então falaremos mais detalhadamente sobre os problemas que surgem na solução de nosso problema.

Os desafios que enfrentamos

Em busca de uma solução para o problema acima, vamos ver quais problemas temos que enfrentar. Destacar os principais problemas permitirá uma melhor compreensão dos problemas, além de desenvolver uma abordagem sistemática para resolvê-los.
Os problemas que enfrentamos são uma bola de neve, cada um dos quais exacerba drasticamente a situação. Muitos desses problemas levam à criação de “Regras de Correlação que funcionam prontas para uso” é extremamente difícil.

Em geral, os problemas são divididos nos seguintes quatro grandes blocos:

1. Perda de dados durante a normalização associada à transformação de modelos do "mundo".
2. Falta de regras claras e universalmente aceitas para normalizar eventos.
3. A constante "mutação" do objeto de proteção - nosso sistema automatizado.
4. Falta de regras para escrever regras de correlação.

Vamos agora examinar essas questões com mais detalhes.

Transformação do modelo mundial

Esse problema é mais facilmente descrito usando a seguinte analogia.
O mundo ao nosso redor é diversificado e multifacetado, mas nossa audição e visão corrigem apenas um espectro limitado de radiação. Tendo visto ou ouvido algum tipo de fenômeno, construímos em nossas cabeças a imagem desse evento, usando seu modelo truncado. Por exemplo, nosso olho não vê no espectro infravermelho e o ouvido não capta vibrações abaixo de 16 Hz. Esta é a primeira transformação do fenômeno original. Acontece neste modelo que nossa imaginação traz algo que não estava no fenômeno original. Podemos dizer ao interlocutor sobre esse fenômeno usando a fala oral com todas as suas limitações e características. Esta é a segunda transformação do modelo. Por fim, o interlocutor, em nossas palavras, decide escrever sobre esse fenômeno para seu colega no messenger. Esta é a terceira e, provavelmente, a transformação mais dramática do modelo em termos de perda de informações.


No exemplo descrito acima, observamos um problema clássico, para o qual o “modelo conceitual” original ( Sovetov B. Ya., Yakovlev S. A., Modelagem de Sistemas ) por simplificação é transformado em outro modelo, perdendo em detalhes.
Exatamente o mesmo acontece no mundo dos eventos gerados por software ou hardware.

Uma explicação que pode servir aqui é uma imagem tão simplificada da nossa área de assunto:

• A primeira transformação do modelo. Um arquivo executável foi carregado na RAM e o sistema operacional começou a executar as instruções descritas nele. O sistema operacional passa algumas informações sobre esta operação para o serviço daemon / log (auditd, eventlog, etc.). Se você não ativar uma auditoria estendida de ações, algumas das informações não se enquadram nesse daemon. Mas mesmo em uma auditoria prolongada, algumas das informações ainda serão descartadas, porque Os desenvolvedores de sistemas operacionais decidiram que esse volume de informações é suficiente para entender o que está acontecendo.
• A segunda transformação do modelo. E agora o daemon / service cria um evento, grava informações no disco e aqui entendemos que o comprimento da linha de eventos pode ser limitado por um determinado número de bytes. Se o daemon / serviço mantiver um log estruturado, ele conterá algum esquema do evento com determinados campos. O que fazer se houver tanta informação que não se encaixe em um esquema "com fio"? Corretamente, provavelmente essas informações serão simplesmente descartadas.

Agora, o que parece ser parte de nossa tarefa.
Já temos um modelo simplificado (já perdendo muitos detalhes) de algum fenômeno representado por um registro em um arquivo de log - um evento. O SIEM lê esse evento, normaliza-o distribuindo dados entre os campos de seu esquema. O número de campos no esquema a priori não pode contê-los o quanto for necessário para cobrir todas as semânticas possíveis de todos os eventos de todas as fontes, ou seja, nesta etapa o modelo é transformado e os dados são perdidos.


É importante entender que, devido a esse problema, o especialista, analisando os logs no SIEM ou descrevendo a regra de correlação, vê não o evento inicial em si, mas seu modelo pelo menos duas vezes distorcido, que perdeu muitas informações. E, se a informação perdida for extremamente importante na investigação do incidente e, como conseqüência da redação da regra, ela deverá ser extraída de algum lugar. É possível que um especialista encontre as informações ausentes, consultando a fonte original (evento bruto, despejo de memória etc.) ou modelando os dados ausentes em sua cabeça com base em sua própria experiência, o que é praticamente impossível de ser obtido diretamente das regras de correlação.

Um bom indicador desse problema são, se não estranhos, campos como a cadeia de dispositivos do cliente, campo de dados ou outra coisa. Esses campos representam um tipo de "despejo" onde eles colocam dados que eles não sabem onde colocar ou quando todos os outros campos adequados são simplesmente inundados.

O conjunto de campos de taxonomia, como regra, reflete o modelo do "mundo", conforme o desenvolvedor do SIEM vê a área de assunto. Se o modelo for muito "estreito", haverá um pequeno número de campos nele e, após a normalização de alguns eventos, eles simplesmente serão perdidos. O SIEM com um conjunto de campos inicialmente fixo e dinamicamente não expansível geralmente apresenta esse problema.

Por outro lado, se houver muitos campos, surgem problemas devido à falta de entendimento de qual campo você precisa colocar certos dados do evento original. Essa situação implica a possibilidade do aparecimento de duplicação semântica, quando semanticamente os mesmos dados do evento inicial se encaixam imediatamente em vários campos. Isso geralmente é observado em soluções em que o conjunto de campos de esquema pode ser expandido dinamicamente por qualquer módulo de normalização com o suporte de uma nova fonte.

Se você tem um SIEM de “combate” em mãos, veja seus eventos. Com que frequência, durante a normalização, você usa campos adicionais reservados (sequência de dispositivos personalizada, campo de dados etc.)? Muitos tipos de eventos com campos adicionais preenchidos indicam que você está observando o primeiro problema. Agora lembre-se, ou pergunte a seus colegas, com que frequência eles precisavam adicionar um novo campo, com o apoio de uma nova fonte, já que não havia campos reservados suficientes? A resposta a esta pergunta é um indicador do segundo problema.

Metodologia de Normalização de Eventos

É importante lembrar quem e como normaliza os eventos, porque desempenha um papel importante. Parte das fontes é suportada diretamente pelo desenvolvedor de soluções SIEM, parte é o integrador que implementou o SIEM para você e parte é sua. É aqui que o próximo problema nos espera: cada um dos participantes interpreta o significado dos campos do esquema de eventos de sua própria maneira e, portanto, realiza a normalização de maneiras diferentes. Assim, diferentes participantes podem decompor dados semanticamente idênticos em campos diferentes. Obviamente, existem vários campos, cujo nome não permite uma interpretação dupla. Suponha src_ip ou dst_ip, mas mesmo com eles existem dificuldades. Por exemplo, em eventos de rede, é necessário alterar src_ip para dst_ip ao normalizar conexões de entrada e saída na mesma sessão?

Com base no exposto, é necessário criar uma metodologia clara para fontes de apoio, dentro da estrutura da qual seria claramente indicado:

1. Quais são os campos do circuito para o que é necessário.
2. Quais tipos de dados correspondem a quais campos.
3. Quais informações são importantes para nós dentro da estrutura de cada tipo de evento.
4. Quais são as regras para preencher os campos.

O modelo do objeto de proteção e sua mutação

Como parte da solução da tarefa, o objeto de proteção é o nosso sistema automatizado (AS). Sim, é a UA na definição de GOST 34.003-90 , com todos os seus processos, pessoas e tecnologias. Esse é um ponto importante, retornaremos a ele mais adiante nos seguintes artigos.

A palavra "mutação" não é escolhida por acaso aqui. Lembremos que na biologia a mutação é entendida como mudanças persistentes no genoma. Qual é o genoma da AC? No âmbito desta série de artigos, no genoma do AS, vou entender sua arquitetura e estrutura. E “mudanças duradouras” nada mais são do que o resultado do trabalho diário de administradores de sistemas, engenheiros de rede, engenheiros de segurança da informação. Sob a influência dessas alterações, o CA muda de um estado para outro a cada minuto. Alguns estados são caracterizados por um alto nível de segurança, outros menos. Mas, agora para nós, isso não importa.

É importante entender que o modelo de corrente alternada não é estático, cujos parâmetros estão descritos na documentação técnica e de trabalho, mas um objeto vivo em constante mutação. O SIEM, construindo o modelo do objeto de proteção dentro de si mesmo, deve levar isso em conta e ser capaz de atualizá-lo de maneira oportuna e eficiente, acompanhando a taxa de mutação. E, se queremos tornar as regras de correlação “prontas para uso”, é necessário que elas levem em consideração essas mutações e operem sempre com a imagem mais relevante do “mundo”.

Metodologia para o desenvolvimento de regras de correlação

A partir da “pirâmide” apresentada acima , fica claro que, ao desenvolver regras de correlação, somos forçados a lutar por todos os problemas que se situam em níveis mais baixos. Ao lidar com esses problemas, as regras são dotadas de lógica extra: filtragem adicional de eventos, verificação de valores vazios, conversão de tipos de dados e transformação desses dados (por exemplo, extração de um nome de domínio do nome de usuário totalmente qualificado), isolamento de informações sobre quem interage com quem e com quem estrutura de eventos.

Depois de tudo isso, as regras são cobertas por um número tão grande de frases de efeito, buscam substrings e expressões regulares que a lógica de seu trabalho fica clara apenas para os autores e, até as próximas férias. Além disso, as constantes mudanças no sistema automatizado - mutações requerem atualização regular das regras contra fraudes. Uma imagem familiar?

No final

Como parte desta série de artigos, tentaremos entender como fazer com que as regras de correlação funcionem imediatamente.

Para resolver o problema, temos que enfrentar os seguintes problemas:

1. Perda de dados durante a transformação do modelo “mundo” no estágio de normalização.
2. A falta de uma definição clara de uma metodologia de normalização.
3. Mutação permanente do objeto de proteção sob a influência de pessoas e processos.
4. Falta de metodologia para escrever regras de correlação.

Muitos desses problemas estão no plano de construir o esquema de eventos correto - um conjunto de campos e o processo de normalização de eventos - a base das regras de correlação. Outra parte dos problemas é resolvida por métodos organizacionais e metodológicos. Se conseguirmos encontrar uma solução para esses problemas, o conceito de trabalhar fora das regras da caixa terá um efeito positivo amplo e aumentará a experiência dos fabricantes do SIEM para um novo nível.

O que vem a seguir? No próximo artigo, tentaremos lidar com a perda de dados durante a transformação do modelo “mundo” e pensar sobre como deve ser o conjunto de campos necessários para nossa tarefa - um diagrama.

---

Série de artigos:

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

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

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