Avaliar a eficácia do SIEM

Um SIEM é um sistema complexo que oferece recursos amplos e flexíveis de detecção de ameaças. Por ser complexo, sua eficácia depende muito de como ele é configurado e quais fontes de dados estão conectadas a ele. Configurar o SIEM uma única vez durante a sua implementação não é suficiente: tanto a infraestrutura da organização quanto as técnicas dos atacantes se modificam com o tempo. Para operar com eficiência, o sistema SIEM deve refletir a realidade atual.

Fornecemos aos clientes serviços para avaliar a eficácia do SIEM, ajudando a identificar problemas e oferecendo opções para a otimização do sistema. Neste artigo, examinamos as armadilhas operacionais comuns do SIEM e como lidar com elas. Para cada caso, também incluímos métodos para verificação independente.

Este material é baseado em uma avaliação da eficácia do Kaspersky SIEM; portanto, todos os exemplos, comandos e nomes de campos específicos são retirados dessa solução. No entanto, a metodologia de avaliação, os problemas identificados e as formas de aumentar a eficácia do sistema podem ser adaptados a qualquer outro SIEM.

Metodologia para avaliar a eficácia do SIEM

O relatório de avaliação da eficácia tem como público principal as equipes de operação e suporte de SIEM em uma organização. O objetivo mais relevante é analisar até que ponto o uso do SIEM se alinha com seus objetivos. Por causa disso, o escopo das verificações pode variar dependendo dos objetivos de cada organização. Uma avaliação padrão é conduzida nas seguintes áreas:

• Composição e escopo de fontes de dados conectadas
• Cobertura das fontes de dados
• Fluxos de dados de fontes existentes
• Correção da normalização de dados
• Operabilidade da lógica de detecção
• Precisão da lógica de detecção
• Cobertura da lógica de detecção
• Uso de dados contextuais
• Integração técnica do SIEM em processos do SOC
• Manipulação de alertas pelos analistas do SOC no SIEM
• Encaminhamento de alertas, dados de eventos de segurança e informações de incidentes para outros sistemas
• Arquitetura e documentação da implementação

Ao mesmo tempo, essas áreas são examinadas não apenas de forma isolada, mas também em termos da possível influência que uma exerce sobre a outra. Aqui estão alguns exemplos que ilustram essa interdependência:

• Problemas com a lógica de detecção devido à normalização incorreta de dados. Uma regra de correlação com a condição deviceCustomString1 not contains <string> aciona um grande número de alertas. A lógica de detecção em si está correta: o evento específico e o campo específico visado não devem gerar um grande volume de dados que correspondam à condição. Nossa análise revelou que o problema estava nos dados recebidos pelo SIEM, em que o encoding incorreto fez com que a string visada pela regra fosse transformada em outra. Como consequência, todos os eventos corresponderam à condição e geraram alertas.
• Ao analisar a cobertura de um tipo de fonte específico, descobrimos que o SIEM estava monitorando apenas 5% de todas as fontes implementadas na infraestrutura. No entanto, estender essa cobertura aumentaria a carga do sistema e os requisitos de armazenamento. Portanto, além de conectar fontes adicionais, seria necessário adaptar recursos para módulos específicos (armazenamento, coletores ou o correlacionador).

A avaliação da eficácia consiste em vários estágios:

• Coletar e analisar a documentação, se disponível. Isso permite avaliar os objetivos do SIEM, as configurações de implementação (idealmente, as configurações de implementação no momento da avaliação), os processos associados e assim por diante.
• Entreviste engenheiros de sistema, analistas e administradores. Isso permite avaliar as tarefas atuais e os problemas mais urgentes, bem como determinar com precisão como o SIEM está sendo operado. As entrevistas são normalmente divididas em duas fases: uma entrevista introdutória, realizada no início do projeto para coletar informações gerais, e uma entrevista de acompanhamento, realizada no meio do projeto para discutir questões decorrentes da análise dos dados coletados anteriormente.
• Reúna informações no SIEM e, em seguida, analise-as. Esta é a parte mais extensa da avaliação, durante a qual os especialistas da Kaspersky recebem acesso somente leitura ao sistema ou a uma parte dele para coletar dados factuais sobre sua configuração, lógica de detecção, fluxos de dados e assim por diante.

A avaliação gera uma lista de recomendações. Algumas delas podem ser implementadas quase imediatamente, enquanto outras requerem mudanças mais abrangentes conduzidas pela otimização de processos ou por uma transição para uma abordagem mais estruturada no uso do sistema.

Problemas decorrentes das operações do SIEM

Os problemas que identificamos durante uma avaliação de eficácia do SIEM podem ser divididos em três grupos:

• Problemas de desempenho: referem-se a erros operacionais em vários componentes do sistema. Esses problemas geralmente são resolvidos pela equipe de suporte técnico, mas para evitá-los, vale a pena verificar com frequência o status de integridade do sistema.
• Problemas de eficiência: ocorrem quando o sistema funciona conforme o esperado, mas aparentemente agrega pouco valor ou não é usado em todo o seu potencial. Isso geralmente ocorre porque o cliente usa os recursos do sistema de maneira limitada ou incorreta, ou não conforme o previsto pelo desenvolvedor.
• Problemas de detecção: ocorrem quando o SIEM funciona conforme o esperado e se desenvolve de acordo com os processos e abordagens definidos, mas os alertas são, em sua maioria, falsos positivos e o sistema negligencia incidentes. Na maioria das vezes, esses problemas estão relacionados à abordagem adotada no desenvolvimento da lógica de detecção.

Principais observações da avaliação

Inventário de fontes de eventos

Ao criar o inventário de fontes de eventos para um SIEM, seguimos o princípio do monitoramento em camadas: o sistema deve ter informações sobre todos os estágios detectáveis de um ataque. Esse princípio permite a detecção de ataques mesmo que ações maliciosas individuais tenham passado despercebidas e possibilita a reconstrução retrospectiva de toda a cadeia de ataque a partir do ponto de entrada dos atacantes.

Problema: durante as avaliações de eficácia, descobrimos com frequência que o inventário dos tipos de fontes conectadas não é atualizado quando a infraestrutura é alterada. Em alguns casos, ele não foi atualizado desde a implementação inicial do SIEM, o que limita os recursos de detecção de incidentes. Como consequência, certos tipos de fontes permanecem completamente invisíveis para o sistema.

Também encontramos casos incomuns de inventário de fontes incompleto. Por exemplo, uma infraestrutura contém hosts que executam Windows e Linux, mas o monitoramento é configurado para apenas uma família de sistemas operacionais.

Como detectar: para identificar os problemas descritos acima, determine a lista de tipos de fontes conectadas ao SIEM e compare-a com o que realmente existe na infraestrutura. Identificar a presença de sistemas específicos na infraestrutura requer uma auditoria. No entanto, essa tarefa é uma das mais críticas para muitas áreas de cibersegurança e recomendamos executá-la com frequência.

Compilamos uma folha de referência dos tipos de sistema encontrados na maioria das organizações. Dependendo do tipo de organização, infraestrutura e modelo de ameaça, podemos reorganizar as prioridades. No entanto, um bom ponto de partida é o seguinte:

• Prioridade alta: fontes associadas a:
  • Disponibilização de acesso remoto
  • Serviços externos acessíveis pela Internet
  • Perímetro externo
  • Sistemas operacionais do endpoint
  • Ferramentas de segurança da informação
• Prioridade média: fontes associadas a:
  • Gerenciamento de acesso remoto dentro do perímetro
  • Comunicação de rede interna
  • Disponibilidade da infraestrutura
  • Soluções de virtualização e nuvem
• Prioridade baixa: fontes associadas a:
  • Aplicativos corporativos
  • Serviços de TI internos
  • Aplicativos usados por várias equipes especializadas (RH, Desenvolvimento, Relações Públicas, TI, entre outras)

Monitoramento do fluxo de dados das fontes

Seja qual for a qualidade da lógica de detecção, ela não pode funcionar sem a telemetria das fontes de dados.

Problema: o núcleo do SIEM não está recebendo eventos de fontes ou coletores específicos. Com base em todas as avaliações realizadas, a proporção média de coletores configurados com fontes, mas que não estão transmitindo eventos, é de 38%. Regras de correlação podem existir para essas fontes, mas elas, é claro, nunca serão acionadas. Também é importante lembrar que um único coletor pode servir centenas de fontes (como estações de trabalho); portanto, a perda do fluxo de dados de um único coletor pode significar a perda da visibilidade do monitoramento para uma parte significativa da infraestrutura.

Como detectar: o processo de localização de fontes que não estão transmitindo dados pode ser dividido em dois componentes.

1. Verificação da integridade do coletor. Encontre o status dos coletores (consulte o site de suporte para descobrir como fazer isso no Kaspersky SIEM) e identifique aqueles com o status Offline, Stopped, Disabled e assim por diante.
2. Verificação do fluxo de eventos. No Kaspersky SIEM, isso pode ser feito coletando estatísticas usando a seguinte consulta (contando o número de eventos recebidos de cada coletor durante um período de tempo específico):

É essencial especificar um intervalo de tempo ideal para coletar essas estatísticas. Um intervalo muito grande pode aumentar a carga no SIEM, enquanto um intervalo muito pequeno pode fornecer informações imprecisas para uma verificação única, especialmente para fontes que transmitem a telemetria com pouca frequência, digamos, uma vez por semana. Portanto, é aconselhável escolher uma janela de tempo menor, como 2 a 4 dias, mas executar várias consultas relativas a diferentes períodos no passado.

Além disso, para uma abordagem mais abrangente, recomendamos usar a funcionalidade integrada ou a lógica personalizada implementada por meio de regras e listas de correlação para monitorar o fluxo de eventos. Isso ajudará a automatizar o processo de detecção de problemas com fontes.

Cobertura da fonte de eventos

Problema: o sistema não está recebendo eventos de todas as fontes de um tipo específico existentes na infraestrutura. Por exemplo, a empresa usa estações de trabalho e servidores que executam o Windows. Durante a implementação do SIEM, as estações de trabalho são imediatamente conectadas para monitoramento, enquanto o segmento do servidor é adiado por algum motivo. Como resultado, o SIEM recebe eventos dos sistemas do Windows, o fluxo é normalizado e as regras de correlação funcionam, mas um incidente no segmento do servidor não monitorado passa despercebido.

Como detectar: abaixo estão várias consultas que podem ser usadas para descobrir fontes desconectadas.

• SELECT count(distinct, DeviceAddress), DeviceVendor, DeviceProduct FROM `events` GROUP BY DeviceVendor, DeviceProduct ORDER BY count(ID)

  1	SELECT count(distinct, DeviceAddress), DeviceVendor, DeviceProduct FROM `events` GROUP BY DeviceVendor, DeviceProduct ORDER BY count(ID)

• SELECT count(distinct, DeviceHostName), DeviceVendor, DeviceProduct FROM `events` GROUP BY DeviceVendor, DeviceProduct ORDER BY count(ID)

  1	SELECT count(distinct, DeviceHostName), DeviceVendor, DeviceProduct FROM `events` GROUP BY DeviceVendor, DeviceProduct ORDER BY count(ID)

Dividimos a consulta em duas variações porque, dependendo da fonte e das configurações de integração de DNS, alguns eventos podem conter um campo DeviceAddress ou DeviceHostName.

Essas consultas ajudarão a determinar o número de fontes de dados exclusivas que enviam logs de um tipo específico. Essa contagem deve ser comparada com o número real de fontes desse tipo, obtido dos proprietários do sistema.

Retenção de dados brutos

Os dados brutos podem ser úteis para desenvolver normalizadores personalizados ou para armazenar eventos não usados em correlações que possam ser necessários durante a investigação de incidentes. No entanto, o uso descuidado dessa configuração pode causar muito mais danos do que benefícios.

Problema: ativar a opção Keep raw event duplica o tamanho do evento no banco de dados, pois duas cópias são armazenadas: a versão original e a versão normalizada. Isso é bastante crítico para coletores de alto volume que recebem eventos de fontes como NetFlow, DNS, firewalls e outros. Vale destacar que esta opção costuma ser usada para testar um normalizador, mas geralmente é esquecida e permanece ativada após a conclusão da configuração.

Como detectar: essa opção é aplicada no nível do normalizador. Portanto, é necessário revisar todos os normalizadores ativos e determinar se a retenção de dados brutos é necessária para sua operação.

Normalização

Assim como a ausência de eventos de fontes, os problemas de normalização levam à falha da lógica de detecção, pois essa lógica depende da localização de informações específicas em um campo de evento específico.

Problema: vários problemas relacionados à normalização podem ser identificados:

• O fluxo de eventos não está sendo normalizado.
• Apenas uma parte dos eventos é normalizada: isso é muito relevante para normalizadores personalizados e que não estão prontos para uso.
• O normalizador utilizado analisa apenas os cabeçalhos, como syslog_headers, colocando todo o conteúdo do evento em um único campo, geralmente Message.
• Um normalizador padrão desatualizado está sendo usado.

Como detectar: identificar problemas de normalização é mais desafiador do que detectar problemas de fonte devido ao alto volume de telemetria e variedade de analisadores. Aqui estão várias abordagens para restringir a pesquisa:

• Primeiro, verifique quais normalizadores fornecidos com o SIEM a organização usa e se suas versões estão atualizadas. Nas nossas avaliações, é comum encontrar eventos auditd sendo normalizados pelo normalizador desatualizado Linux audit and iptables syslog v2 no Kaspersky SIEM. O novo normalizador reformula por completo e otimiza o esquema de normalização para eventos dessa fonte.
• Faça a consulta:

Essa consulta reúne estatísticas sobre eventos de cada coletor, divididas pelos campos DeviceVendor e DeviceProduct. Embora esses campos não sejam obrigatórios, eles estão presentes em quase qualquer esquema de normalização. Portanto, sua ausência completa ou valores vazios podem indicar problemas de normalização. Recomendamos incluir esses campos ao desenvolver normalizadores personalizados.

Para simplificar a identificação de problemas de normalização ao desenvolver normalizadores personalizados, você pode implementar o mecanismo descrito a seguir. Para cada evento normalizado com sucesso, adicione um campo Nome, preenchido por uma constante ou pelo próprio evento. Para um normalizador genérico final que processa todos os eventos não analisados, defina o valor constante: Name = unparsed event. Isso permitirá identificar eventos não normalizados por meio de uma pesquisa simples nesse campo.

Cobertura da lógica de detecção

Na maioria dos casos, os eventos coletados são úteis apenas para investigar um incidente que já foi identificado. Para que um SIEM opere em todo o seu potencial, é necessário desenvolver uma lógica de detecção para identificar prováveis incidentes de segurança.

Problema: a cobertura média das regras de correlação das fontes, determinada em todas as nossas avaliações, é de 43%. Embora esse número seja apenas um valor aproximado (já que diferentes tipos de fonte fornecem informações diferentes), para calculá-lo, definimos “cobertura” como a presença de pelo menos uma regra de correlação para uma fonte. Isso significa que para mais da metade das fontes conectadas, o SIEM não faz uma detecção ativa. Enquanto isso, o esforço e os recursos do SIEM são gastos na conexão, na manutenção e na configuração dessas fontes. Em alguns casos, isso é justificado por lei, por exemplo, se os logs forem necessários apenas para conformidade regulatória. No entanto, isso é uma exceção, e não a regra.

Não recomendamos resolver esse problema deixando de conectar fontes ao SIEM. Pelo contrário, as fontes devem ser conectadas, mas isso deve ser feito junto com o desenvolvimento da lógica de detecção correspondente. Caso contrário, isso pode ser esquecido ou adiado indefinidamente, enquanto a fonte consome inutilmente os recursos do sistema.

Como detectar: isso nos leva de volta à auditoria, um processo que pode se beneficiar da criação e da manutenção de um registro da lógica de detecção desenvolvida. Como nem toda regra de lógica de detecção declara explicitamente o tipo de fonte da qual espera a telemetria, sua descrição deve ser adicionada a esse registro durante a fase de desenvolvimento.

Se as descrições das regras de correlação não estiverem disponíveis, você pode consultar o seguinte:

• O nome da lógica de detecção. Com uma abordagem padronizada para a nomeação de regras de correlação, o nome pode indicar a fonte associada ou pelo menos fornecer uma breve descrição do que ela detecta.
• O uso de campos nas regras, como DeviceVendor, DeviceProduct (outro argumento para incluir esses campos no normalizador), Name, DeviceAction, DeviceEventCategory, DeviceEventClassID e outros. Eles podem ajudar a identificar a fonte real.

Alertas excessivos gerados pela lógica de detecção

Um critério para a eficácia das regras de correlação é uma taxa baixa de falsos positivos.

Problema: a lógica de detecção gera um número muito alto de alertas que são fisicamente impossíveis de processar, seja qual for o tamanho da equipe de SOC.

Como detectar: em primeiro lugar, a lógica de detecção deve ser testada durante o desenvolvimento e refinada para alcançar uma taxa aceitável de falsos positivos. No entanto, mesmo uma regra de correlação bem ajustada pode começar a produzir alertas excessivos devido a alterações no fluxo de eventos ou na infraestrutura conectada. Para identificar essas regras, recomendamos executar periodicamente a seguinte consulta:

No Kaspersky SIEM, um valor de 3 no campo Type indica um evento de correlação.

Para cada regra identificada com uma contagem de alertas anômala, verifique a correção da lógica usada e a integridade do fluxo de eventos que causou seu acionamento.

Dependendo do problema identificado, a solução pode envolver modificar a lógica de detecção, adicionar exceções (por exemplo, geralmente 99% do spam se origina de apenas 1 a 5 objetos específicos, como um endereço IP, um parâmetro de comando ou uma URL) ou ajustar a coleta e a normalização de eventos.

Falta de integração com indicadores de comprometimento

As integrações do SIEM com outros sistemas geralmente são uma parte crítica do processamento de eventos e do enriquecimento de alertas. Em pelo menos um caso específico, sua presença afeta diretamente o desempenho da detecção: integração com dados técnicos do Threat Intelligence ou com IoCs (indicadores de comprometimento).

Um SIEM permite a verificação conveniente de objetos em relação a vários bancos de dados de reputação ou listas de bloqueio. Além disso, há várias fontes desses dados que estão prontas para serem integradas nativamente com um SIEM ou que exigem um esforço mínimo para serem incorporadas.

Problema: não há integração com dados de TI.

Como detectar: geralmente, os IoCs são integrados em um SIEM no nível de configuração do sistema durante a implementação ou a otimização subsequente. O uso de TI em um SIEM pode ser implementado em vários níveis:

• No nível da fonte de dados. Algumas fontes, como NGFWs, adicionam essas informações a eventos envolvendo objetos relevantes.
• No nível de funcionalidade nativa do SIEM. Por exemplo, o Kaspersky SIEM se integra com os indicadores CyberTrace, que adicionam informações de reputação do objeto no momento do processamento de um evento de uma fonte.
• No nível da lógica de detecção. As informações sobre os IoCs são armazenadas em várias listas ativas e as regras de correlação comparam os objetos com elas para enriquecer o evento.

Além disso, os dados de TI não aparecem em um SIEM do nada. Eles são fornecidos por fornecedores externos (comercialmente ou em um formato aberto) ou como parte da funcionalidade integrada das ferramentas de segurança em uso. Por exemplo, vários sistemas NGFW podem verificar a reputação de endereços IP externos ou dos domínios que são acessados pelos usuários. Portanto, a primeira etapa é determinar se você está recebendo informações sobre indicadores de comprometimento e de que forma isso ocorre (se os feeds de provedores externos foram integrados e/ou as ferramentas de segurança implementadas têm esse recurso). Vale destacar que o recebimento de dados de TI somente no nível da ferramenta de segurança nem sempre abrange todos os tipos de IoCs.

Se os dados estiverem sendo recebidos de alguma forma, a próxima etapa será verificar se eles estão sendo utilizados pelo SIEM. Para eventos relacionados a TI provenientes de ferramentas de segurança, o SIEM precisa de uma regra de correlação desenvolvida para gerar alertas. Portanto, verificar a integração nesse caso envolve determinar os recursos das ferramentas de segurança, procurar os eventos correspondentes no SIEM e identificar se há uma lógica de detecção associada a esses eventos. Se os eventos das ferramentas de segurança estiverem ausentes, a configuração de auditoria da fonte deve ser avaliada para verificar se o tipo de telemetria em questão está sendo encaminhado ao SIEM. Se a normalização for o problema, você deve avaliar a precisão da análise e reconfigurar o normalizador.

Se os dados de TI vierem de fornecedores externos, determine como eles são processados na organização. Há um sistema centralizado para agregar e gerenciar dados de ameaças (como o CyberTrace) ou as informações são armazenadas em, digamos, arquivos CSV?

No primeiro caso (há um sistema de agregação e gerenciamento de dados de ameaças), você deve verificar se ele está integrado ao SIEM. Para o Kaspersky SIEM e o CyberTrace, essa integração é tratada pela interface do SIEM. Depois disso, os fluxos de eventos do SIEM são direcionados para o sistema de agregação e gerenciamento de dados de ameaças, onde as correspondências são identificadas e os alertas são gerados e, em seguida, ambos são enviados de volta ao SIEM. Portanto, verificar a integração envolve assegurar-se de que todos os coletores que recebem eventos que possam conter IoCs estejam encaminhando esses eventos para o sistema de gerenciamento e agregação de dados de ameaças. Também recomendamos verificar se o SIEM tem uma regra de correlação que gera um alerta com base na correspondência de objetos detectados com IoCs.

No último caso (as informações sobre ameaças são armazenadas em arquivos), você deve confirmar se o SIEM tem um coletor e um normalizador configurados para carregar esses dados no sistema como eventos. Além disso, verifique se a lógica está configurada para armazenar esses dados dentro do SIEM para uso na correlação. Isso normalmente é feito com a ajuda de listas que contêm os IoCs obtidos. Por fim, verifique se há uma regra de correlação que compare o fluxo de eventos com essas listas de IoC.

Conforme ilustrado pelos exemplos, a integração com a TI em cenários padrão se resume ao desenvolvimento de uma regra de correlação final que aciona um alerta ao detectar uma correspondência com IoCs conhecidos. Devido ao grande número de métodos de integração, é difícil criar e fornecer uma regra universal pronta para uso. Portanto, na maioria dos casos, para garantir que os IoCs estejam conectados ao SIEM, você precisa determinar se a empresa desenvolveu essa regra (a existência da regra) e se ela foi configurada corretamente. Se não houver nenhuma regra de correlação no sistema, recomendamos criar uma com base nos métodos de integração de TI implementados na sua infraestrutura. Se uma regra existir, sua funcionalidade deve ser verificada: se nenhum alerta tiver sido gerado por ela, analise suas condições de acionamento em relação aos dados de eventos visíveis no SIEM e ajuste-a conforme a necessidade.

O SIEM não é atualizado

Para que um SIEM funcione com eficiência, ele deve conter dados atuais sobre a infraestrutura monitorada e as ameaças detectadas. Ambos os elementos mudam com o tempo: novos sistemas e softwares, usuários, políticas de segurança e processos são introduzidos na infraestrutura, enquanto novas técnicas e ferramentas são desenvolvidas pelos atacantes. É seguro presumir que um sistema SIEM perfeitamente configurado e implantado não será mais capaz de enxergar totalmente a infraestrutura alterada ou as novas ameaças após funcionar por cinco anos sem configurações adicionais. Portanto, quase todos os componentes devem ser gerenciados e atualizados, desde a coleta de eventos até a detecção, integrações adicionais para informações contextuais e exclusões.

Além disso, é importante reconhecer que é impossível cobrir todas as ameaças. A pesquisa contínua de ataques, o desenvolvimento de métodos de detecção e a configuração de regras correspondentes são imprescindíveis. O próprio SOC também se modifica. À medida que ele atinge determinados níveis de maturidade, surgem novas oportunidades de crescimento para a equipe, exigindo a utilização de novos recursos.

Problema: o SIEM não se modificou desde sua implementação inicial.

Como detectar: compare a declaração de trabalho original ou outra documentação relativa à implementação com o estado atual do sistema. Se não houver alterações, ou se elas forem mínimas, é muito provável que existam áreas para crescimento e otimização no seu SIEM. Qualquer infraestrutura é dinâmica e requer adaptação contínua.

Outros problemas com a implementação e a operação do SIEM

Neste artigo, descrevemos os principais problemas que identificamos durante as avaliações de eficácia do SIEM, mas esta lista não é exaustiva. Também encontramos com frequência:

• Incompatibilidade entre a capacidade da licença e a carga real do SIEM. O problema é quase sempre a ausência de eventos das fontes, em vez de uma avaliação inicial incorreta das necessidades da organização.
• Falta de gerenciamento de direitos de usuário no sistema (por exemplo, a cada usuário é atribuída a função de administrador).
• Má organização de recursos personalizáveis do SIEM (regras, normalizadores, filtros e assim por diante). Os exemplos incluem convenções de nomenclatura caóticas, agrupamento não ideal e conteúdo obsoleto ou de teste misturado com conteúdo ativo. Encontramos recursos com nomes confusos como [dev] test_Add user to admin group_final2.
• Uso de recursos prontos para uso sem adaptação à infraestrutura da organização. Para maximizar o valor de um SIEM, é essencial, no mínimo, preencher listas de exceções e especificar os parâmetros da infraestrutura: listas de administradores e serviços e hosts críticos.
• Integrações nativas desativadas com sistemas externos, como LDAP, DNS e GeoIP.

A maioria dos problemas relativos à eficácia do SIEM geralmente decorre da degradação natural (acúmulo de erros) dos processos implementados no sistema. Portanto, na maioria dos casos, manter a eficácia envolve estruturar esses processos, monitorar a qualidade do envolvimento do SIEM em todos os estágios (integração da fonte, desenvolvimento da regra de correlação, normalização e assim por diante) e realizar revisões frequentes de todos os componentes e recursos do sistema.

Conclusão

Um SIEM é uma ferramenta poderosa para monitorar e detectar ameaças, capaz de identificar ataques em vários estágios em quase todas as partes da infraestrutura de uma organização. No entanto, se for mal configurado e operado, ele pode se tornar ineficaz ou até mesmo inútil, ao mesmo tempo em que consome recursos significativos. Portanto, é essencial fazer auditorias periódicas dos componentes, das configurações, das regras de detecção e das fontes de dados do SIEM.

Se um SOC estiver sobrecarregado ou for incapaz de identificar problemas operacionais no SIEM de forma independente, oferecemos aos usuários da plataforma Kaspersky SIEM um serviço que visa avaliar sua operação. Após a avaliação, fornecemos uma lista de recomendações para resolver os problemas que identificamos. Dito isso, é importante esclarecer que essas não são instruções rígidas e prescritivas, mas sim um destaque de áreas que exigem atenção e análise para melhorar o desempenho do produto, aprimorar a precisão da detecção de ameaças e permitir uma utilização mais eficiente do SIEM.