Concluímos a série de artigos dedicados às regras de correlação elaboradas imediatamente. Estabelecemos uma meta para formular uma abordagem que nos permita criar regras de correlação que possam funcionar "prontas para uso" com o mínimo de falsos positivos.


Imagem: Marketing de Software

Todos os pontos-chave do artigo estão disponíveis na conclusão , no mesmo local em que esta metodologia é apresentada na forma de um diagrama gráfico.

Brevemente sobre o que aconteceu nos artigos anteriores: eles descreveram como deveria ser um conjunto de campos de um evento normalizado - um diagrama ; qual sistema de categorização de eventos usar; como, usando um sistema de categorização e um esquema, para unificar o processo de normalização de eventos. Também examinamos o contexto da implementação de regras de correlação e examinamos o que o SIEM deveria saber sobre o Sistema Automatizado (AS) que está monitorando e por quê.

Todas as abordagens e raciocínios acima são os blocos a partir dos quais a metodologia para o desenvolvimento de regras de correlação é construída. É hora de reuni-los e olhar para o quadro todo.

Toda a metodologia para o desenvolvimento de regras de correlação consiste em quatro blocos:

• preparação de fontes e arredores;
• normalização de eventos e seu enriquecimento;
• adaptação das regras de correlação ao contexto do EA;
• formação de um acordo sobre aspectos positivos.

Preparando fontes e ambientes

As regras de correlação operam em eventos que geram fontes. Nesse sentido, é extremamente importante que as fontes necessárias para as regras de correlação estejam presentes nos alto-falantes e estejam configuradas corretamente.


Preparando fontes e ambientes

Etapa 1 : pense na lógica geral da regra e entenda quais fontes de eventos são necessárias. Se você estiver desenvolvendo do zero ou adotando uma regra de correlação Sigma pronta, precisará entender com base nos eventos a partir dos quais as fontes funcionarão.

Etapa 2 : verifique se todas as fontes necessárias estão na empresa e podem ser coletadas. Uma situação é possível quando uma regra opera em uma cadeia de eventos de várias fontes do formulário (evento A da origem 1) - (evento B da origem 2) - (evento C da origem 3) por 5 minutos. Se sua empresa não tiver pelo menos uma fonte, essa regra se tornará inútil, pois nunca funcionará. Você precisa entender se, em princípio, é possível coletar eventos das fontes necessárias e se o seu SIEM pode fornecê-lo. Por exemplo, a fonte grava eventos em um arquivo, mas o arquivo é criptografado ou um banco de dados não padrão é usado na origem para armazenamento, cujo acesso não pode ser garantido por meio do driver ODBC / JDBC padrão.

Etapa 3 : conectar fontes ao SIEM. Não importa o quão banal possa parecer, mas nesta etapa é necessário implementar a coleção de eventos. Muitas vezes há muitos problemas. Por exemplo, problemas organizacionais, quando o gerenciamento de TI proíbe categoricamente a conexão com sistemas de missão crítica. Ou técnico, quando sem configurações adicionais, o agente SIEM (SmartConnector, Universal Forwarder), ao coletar eventos, simplesmente "mata" a fonte, levando a uma negação de serviço. Isso geralmente pode ser observado ao conectar DBMSs altamente carregados ao SIEM.

Etapa 4 : verifique se a auditoria nas fontes está configurada corretamente, se os eventos necessários para a correlação são recebidos no SIEM. As regras de correlação esperam certos tipos de eventos. Eles devem ser gerados pela fonte. Geralmente, para gerar os eventos necessários para as regras, a fonte deve ser configurada adicionalmente: a auditoria avançada é ativada e a saída de log em um determinado formato é configurada.

A ativação da auditoria estendida frequentemente afeta a quantidade de fluxo de eventos (EPS) recebido no SIEM da fonte. Devido ao fato de a própria fonte e o SIEM estarem na área de responsabilidade de diferentes departamentos, sempre existe o risco de a auditoria estendida ser desativada e, como resultado, os tipos de eventos necessários deixarão de ocorrer no SIEM. Esse problema pode ser parcialmente detectado pelo monitoramento do fluxo de eventos para cada fonte, ou melhor, pelo monitoramento de alterações nos Eventos por Segundo (EPS).

Etapa 5 : verifique se os eventos estão em andamento e configure o monitoramento de origem. Em qualquer infraestrutura, mais cedo ou mais tarde, aparecem falhas na rede ou na própria fonte. Nesse ponto, o SIEM perde contato com a fonte e não pode receber eventos. Se a fonte for passiva e gravar seus logs em um arquivo ou banco de dados, os eventos não serão perdidos no caso de uma falha e o SIEM poderá recebê-los quando a comunicação for restaurada. Se a fonte estiver ativa e enviar eventos para o SIEM, por exemplo, via syslog, sem salvá-los adicionalmente em qualquer lugar, em caso de falha, os eventos serão perdidos e sua regra de correlação simplesmente não funcionará, porque o evento desejado não será esperado. Aprofundando, você pode ver que, mesmo ao trabalhar com uma fonte passiva, ao restaurar a comunicação após uma falha, não há garantia de que as regras de correlação funcionem, especialmente aquelas que funcionam com janelas de tempo. Considere o exemplo de regra descrito acima: (evento A da fonte 1) - (evento B da fonte 2) - (evento C da fonte 3) por 5 minutos. Se ocorrer uma falha após o evento B e a conexão for restaurada em uma hora, a correlação não funcionará, pois o evento C não chegará nos 5 minutos esperados.

Mantendo esses recursos em mente, você deve configurar o monitoramento das fontes das quais os eventos são coletados. Esse monitoramento deve monitorar a disponibilidade das fontes, a pontualidade da chegada dos eventos a partir delas, o poder do fluxo de eventos coletados (EPS).

O acionamento do sistema de monitoramento é o primeiro sino que fala da aparência de um fator negativo que afeta o desempenho de todas ou parte das regras de correlação.

Normalização de eventos e seu enriquecimento

Coletar os eventos necessários para a correlação não é suficiente. Eventos que chegam ao SIEM devem ser normalizados estritamente de acordo com as regras aceitas. Escrevemos sobre os problemas de normalização e a formação de uma metodologia de normalização em um artigo separado. Em geral, esse bloco pode ser caracterizado como uma luta contra a entrada e saída de lixo ( GIGO ).


Normalização e enriquecimento de eventos

Etapa 6 e Etapa 7 : Categorização de eventos e normalização de eventos de acordo com a categoria, com base na metodologia. Não iremos nos aprofundar neles em detalhes, pois consideramos essas etapas em detalhes no artigo “Metodologia para normalização de eventos” .

Etapa 8 : Enriquecimento de eventos com informações ausentes e adicionais, de acordo com a categoria. Frequentemente, os eventos recebidos nem sempre contêm informações na medida necessária para que as regras de correlação funcionem. Por exemplo, um evento contém apenas o endereço IP do host, mas não há informações sobre seu FQDN ou nome do host. Outro exemplo: um evento contém um ID do usuário, mas não há nome de usuário no evento. Nesse caso, as informações necessárias devem ser extraídas de fontes externas - bancos de dados, controladores de domínio ou outros diretórios e adicionadas ao evento.

É importante observar que a categorização dos eventos ocorre no início - antes da normalização. Além do fato de a categoria definir as regras para normalizar o evento, também define a lista de dados que devem ser buscados em fontes externas, se não estiverem no próprio evento.

Adaptando Regras de Correlação ao Contexto AS

Depois de preparar os dados de entrada (eventos) e prosseguir com o desenvolvimento de regras de correlação, é necessário levar em consideração as especificidades dos eventos recebidos, o próprio AS e sua variabilidade. Mais sobre isso foi no artigo "Modelo de sistema como um contexto de regras de correlação" .


Adaptando Regras de Correlação ao Contexto AS

Etapa 9 : Entenda a frequência dos eventos de cada fonte, determine a janela de tempo para correlação. Frequentemente, as regras de correlação usam janelas de tempo quando é necessário esperar a chegada de um determinado evento dentro de um determinado intervalo de tempo. Ao desenvolver essas regras, é importante considerar o atraso no recebimento de eventos. Eles geralmente são causados ​​por dois fatores.

Primeiro , a própria fonte não pode gravar imediatamente eventos no banco de dados, em um arquivo ou enviá-lo via syslog. O tempo desse atraso deve ser estimado e levado em consideração na regra.

Em segundo lugar , há um atraso na entrega de eventos ao SIEM. Por exemplo, a coleção de eventos do banco de dados é configurada para que a solicitação de eventos seja realizada a cada 10 minutos, é claro, para que a janela de correlação de 5 minutos não seja a melhor solução nessa situação.

O problema é agravado quando é necessário desenvolver uma regra de correlação que funcione com eventos de várias fontes ao mesmo tempo. Nesse caso, é importante entender que eles podem ter prazos de entrega diferentes. Na pior das hipóteses, os eventos ocorrerão em ordem aleatória, com uma violação da cronologia. Em tal situação, o desenvolvedor das regras de correlação precisa entender claramente a que horas o SIEM realiza a correlação (no horário do evento ou quando o evento chegou no SIEM). Observo que a correlação no horário de chegada dos eventos é a opção tecnicamente mais simples e comum para processar eventos no modo pseudo-em tempo real. No entanto, esta opção apenas exacerba os problemas acima e não os resolve.

Se o seu SIEM fornece uma correlação no horário do evento, provavelmente existem mecanismos para reordenar eventos que podem restaurar a cronologia real dos eventos.

No caso de entender que a janela de tempo é muito grande para correlacionar no fluxo, você deve usar o mecanismo de correlação retroativa, no qual os eventos já salvos são selecionados no banco de dados SIEM de acordo com o planejamento e executam as regras de correlação.

Etapa 10 : Estabelecer um Mecanismo de Exceção. No mundo real, sempre haverá um objeto com comportamento especial que não deve ser tratado por uma regra de correlação específica, pois isso leva a um falso positivo. Portanto, no estágio de desenvolvimento das regras, devem ser criados mecanismos para adicionar esses objetos a exceções. Por exemplo, se sua regra funcionar com os endereços IP das máquinas, você precisará de uma lista de tabelas na qual poderá adicionar endereços para os quais a regra não funcionará. Da mesma forma, se uma regra funcionar com logins de usuários ou nomes de processos, é necessário trabalhar preliminarmente com listas de exclusão de tabelas na lógica da regra.

Essa abordagem permitirá que você adicione objetos de maneira automática ou automática a exceções sem precisar reescrever o corpo da regra.

Etapa 11 : Defina os limites físicos e lógicos de aplicabilidade da regra de correlação. Ao desenvolver uma regra de correlação, é importante entender inicialmente os limites de aplicabilidade (escopo) da regra e se eles existem. Ao elaborar a lógica e depurar a regra, é necessário focar nas especificidades dessa área. Se uma regra começar a trabalhar com dados que vão além do escopo dessa área, a probabilidade de falsos positivos aumenta.

Dois tipos de escopo podem ser distinguidos: físico e lógico. O escopo físico são as redes da empresa e adjacentes e a área lógica são as partes do AS, aplicativos de negócios ou processos de negócios. Exemplos da área física: segmento DMZ, sub-redes internas e externas, redes de acesso remoto. Exemplos do escopo lógico das regras: controle de processo, contabilidade, segmento PCI DSS, segmento PD ou apenas funções específicas de equipamento - controladores de domínio, comutadores de acesso, roteadores principais.

Você pode definir escopos para regras de correlação por meio de listas de tabelas. Eles podem ser preenchidos manualmente ou automaticamente. Se você encontrar tempo na sua empresa para o gerenciamento de ativos (gerenciamento de ativos), todos os dados necessários já podem estar contidos no modelo AS criado no SIEM. A geração automática de tais listas tabulares permite incluir dinamicamente no escopo novos ativos que aparecem na empresa. Por exemplo, se você tivesse uma regra que funcionasse exclusivamente com controladores de domínio, a adição de um novo controlador à floresta de domínio será corrigida no modelo e cairá no escopo da sua regra.

Em geral, as listas de tabelas usadas para exceções podem ser consideradas listas negras e as listas responsáveis ​​pelo escopo das regras como listas brancas.

Etapa 12 : use o modelo do alto-falante para esclarecer o contexto. No processo de desenvolvimento de uma regra de correlação que identifique ações maliciosas, é importante garantir que elas possam realmente ser implementadas. Se isso não for levado em consideração, o acionamento da regra que revelou o ataque em potencial será falso, pois esse tipo de ataque pode não ser aplicável à sua infraestrutura. Vou explicar com um exemplo:

1. Suponha que tenhamos uma regra de correlação que detecte conexões RDP remotas com servidores.
2. O firewall apresenta uma tentativa de conectar-se à porta TCP 3389 do servidor myserver.local.
3. A regra é acionada e você começa a analisar um incidente em potencial com alta prioridade.

Durante a investigação, você rapidamente descobre que no myserver.local 3389 ele está fechado e nunca foi aberto por nenhum serviço e o Linux está lá. Este é um falso positivo que levou tempo para investigar.

Outro exemplo: o IPS envia um evento de disparo de assinatura quando é feita uma tentativa de explorar a vulnerabilidade CVE-2017-0144, mas durante a investigação, verifica-se que o patch correspondente está instalado na máquina atacada e não há necessidade de responder a esse incidente com a maior prioridade.
O uso de dados do modelo do alto-falante ajudará a nivelar esse problema.

Etapa 13 : use identificadores de entidade, não suas chaves de origem. Como já descrito no artigo "Modelo de sistema como um contexto de regras de correlação", o endereço IP, o FQDN e até o MAC de um ativo podem mudar. Portanto, se você usar os identificadores de origem do ativo na regra de correlação ou na lista de tabelas, depois de um tempo, haverá uma grande chance de receber falsos positivos por um motivo completamente banal, por exemplo, o servidor DHCP simplesmente emitiu esse IP para outra máquina.

Se o seu SIEM tiver um mecanismo para identificar ativos, rastrear suas alterações e permitir que você opere com seus identificadores, use identificadores, não as chaves de origem do ativo.

Formação de um acordo positivo

Aproximando-se do bloco final de criação da regra de correlação, lembramos que o resultado da regra é um incidente levantado no SIEM. Profissionais responsáveis ​​devem responder a esse incidente. Embora o objetivo desta série de artigos não inclua a consideração do processo de resposta a incidentes, deve-se observar que parte das informações sobre o incidente já é gerada no estágio de criação da regra de correlação correspondente.

A seguir, consideramos os pontos básicos que devem ser levados em consideração ao configurar os parâmetros para acionar a regra de correlação e gerar um incidente.


Formação de um acordo positivo

Etapa 14 : Determine as condições de agregação e desligamento no caso de um grande número de falsos positivos. No estágio de depuração e no processo de funcionamento, se você não aderir a esta técnica :), podem ocorrer alarmes falsos das regras. É bom se houver uma ou duas viagens por dia, mas e se uma regra tiver milhares ou dezenas de milhares de viagens? Obviamente, isso sugere que a regra precisa ser mais desenvolvida. No entanto, é necessário garantir que em tais situações um falso positivo maciço:

1. Não afetou o desempenho do SIEM.
2. Entre a massa de falsos positivos, incidentes realmente importantes não foram perdidos. Existe até um tipo separado de ataque destinado a ocultar a principal atividade maliciosa por trás de muitas atividades falsas.

Problemas desse tipo podem ser resolvidos se, ao criar uma regra de correlação no nível de todo o sistema como um todo ou para cada regra separadamente, condições para a agregação de incidentes e condições para o desligamento de emergência da regra.

O mecanismo de agregação de incidentes permitirá não criar milhões de incidentes idênticos, mas "colar" novos incidentes em um, desde que sejam idênticos. Em casos extremos, quando mesmo a agregação de incidentes gera uma carga significativa, é recomendável definir a regra de correlação para desligar automaticamente quando o número especificado de operações por unidade de tempo for excedido (minuto, hora, dia).

Etapa 15 : defina as regras para gerar o nome do incidente. Esse item geralmente é negligenciado, especialmente se eles não estiverem desenvolvendo regras para sua empresa, por exemplo, se uma empresa terceirizada for responsável por implementar o SIEM e desenvolver regras. O nome da regra de correlação, bem como o incidente gerado, devem ser curtos e refletir claramente a essência de uma regra específica.

Se mais de uma pessoa trabalhar com incidentes e regras de correlação em sua empresa, é recomendável que você desenvolva regras de nomenclatura. Eles devem ser entendidos e aceitos por toda a equipe que trabalha com o SIEM.

Etapa 16 : defina as regras para definir a importância do incidente. A maioria das soluções SIEM no último estágio de criação de um incidente permite definir sua importância e significância. Algumas decisões chegam a calcular a importância automaticamente, com base no contexto do incidente e nos objetos envolvidos.

Caso seu SIEM opere exclusivamente o cálculo automático da importância dos incidentes, vale a pena descobrir com base no que e com que fórmula é calculada. Por exemplo, se a importância é calculada com base na significância dos ativos envolvidos no incidente, é necessário levar a sério os problemas do Asset Management em uma empresa com antecedência.

Se você definir a importância de um incidente manualmente, é recomendável desenvolver uma fórmula de cálculo que leve em consideração pelo menos o seguinte:

1. A importância do escopo em que a regra funciona. Por exemplo, um incidente na zona de missão crítica dos sistemas pode ser mais crítico do que se o mesmo incidente ocorresse exatamente na zona de sistemas críticos de negócios.
2. A importância dos ativos e contas de usuário envolvidos no incidente.
3. A recorrência deste incidente na empresa.

Além disso, como na nomeação de incidentes, é importante que todas as partes interessadas compreendam clara e igualmente as regras pelas quais a importância de um incidente é formada.

Conclusões

Resumindo os resultados de nossa série de artigos, observo que é possível, na minha opinião, criar regras de correlação que funcionem imediatamente. A solução pode ser uma fusão de abordagens organizacionais e técnicas. O próprio SIEM deve ser capaz de fazer algo, mas os especialistas que o operam precisam fazer e saber algo.

Para resumir:

1. O método consiste nos seguintes blocos:
   
   • Preparando fontes e ambientes.
   • Normalização de eventos e seu enriquecimento.
   • Adaptação de regras de correlação ao contexto AS.
   • Formação de um acordo sobre aspectos positivos.
2. Cada unidade possui componentes organizacionais e técnicos.
3. , SIEM, .
4. , , SIEM-.
5. . .

, « »

, , . — . .

---

:

SIEM: « ». 1: ?

SIEM: « ». 2. «»

SIEM: « ». Parte 3.1.

SIEM: « ». 3.2.

SIEM: « ». 4.

SIEM: « ». 5. ( )