Detecções do Elastic SIEM
Com o lançamento do Elastic Security 7.6, anunciamos a criação de um moderno mecanismo de detecção que fornece às equipes do SOC uma experiência unificada de regras de SIEM por meio das detecções do Elastic SIEM. O mecanismo de detecção utiliza um conjunto específico de mecanismos de análise de dados do Elasticsearch e opera com uma nova plataforma de execução distribuída no Kibana. Neste post, fornecemos uma breve visão geral do fluxo de detecções no Elastic SIEM e discutimos os novos recursos de UI e de backend que ajudam essas detecções a funcionar perfeitamente para os nossos usuários.
Antes de entrarmos nas detecções, uma observação rápida: se você está pronto(a) para experimentar o app do SIEM, confira a nossa série de posts do blog sobre SIEM para pequenas empresas e para uso pessoal. A série aborda a configuração na nuvem com a nossa avaliação do Elasticsearch Service gratuita, usando os Beats para coletar e transmitir dados com segurança dos seus sistemas para o SIEM e muito mais (é muito mais fácil do que você imagina). Também oferecemos um guia de introdução para implantações híbridas.
Fluxo de trabalho da UI para gerenciamento de sinais
Os elementos básicos das detecções do Elastic SIEM são os sinais, que são documentos do Elasticsearch criados quando as condições de uma regra de detecção de sinais são atendidas. No caso mais simples, um documento de sinal é criado para cada evento correspondente à consulta definida na regra. O documento de sinal contém uma cópia dos campos do documento correspondente e é mantido em um índice de sinais separado. Os eventos originais não são modificados quando um sinal é criado.
Os sinais são apresentados no app do SIEM. Quando um profissional vê um novo sinal pela primeira vez, ele está em estado aberto. Após a análise e a determinação das próximas etapas, o profissional o altera para o estado fechado. Todas essas alterações podem ser gerenciadas na visualização Detections (Detecções) no app do SIEM.
O histograma de contagem de sinais mostra os sinais abertos e permite comparações rápidas entre os principais atributos:
- Pontuação, gravidade, tipo, nome ou nome de tática do MITRE ATT&CK™
- Endereço IP de origem ou destino
- Ação ou categoria do evento
- Nome de host ou usuário
A próxima etapa é a investigação de sinais na linha do tempo:
Se você não especificou um modelo de linha do tempo ao criar uma regra, a linha do tempo é preenchida com um documento de sinal. Se você especificou um modelo de linha do tempo, a linha do tempo é preenchida com o que o usuário salvou, agilizando as investigações para certos tipos de regras.
Os profissionais podem visualizar alertas de sistemas externos, como Elastic Endpoint Security, Suricata ou Zeek, na guia “External alerts” (Alertas externos) dedicada. Muitas organizações também implementam regras que geram sinais para a emissão de valiosos alertas externos. Dessa forma, elas podem se beneficiar do fluxo de trabalho investigativo aprimorado para sinais.
Depois que um sinal ou um conjunto de sinais tiver sido investigado até o analista ficar satisfeito, ele poderá fechar os sinais individualmente ou em massa. Os sinais também podem ser reabertos se necessário. Estamos trabalhando para criar maneiras de automatizar o fechamento dos sinais em versões futuras.
Fluxo de trabalho da UI para criação de regras
Para que os sinais comecem a aparecer, as detecções precisam que regras sejam executadas. A criação de uma regra para detecções de SIEM é simples e direta. Tudo se resume a três etapas básicas:
1) Gere a consulta a ser usada sempre que a regra for executada. Essa consulta pode ser a sintaxe Lucene, KQL ou uma busca salva. Além disso, a consulta pode ser importada de uma linha do tempo salva (com muitas outras opções para consultas de regras atualmente em desenvolvimento para um futuro lançamento):
2) Adicione algumas informações que descrevem a regra (título, descrição etc.):
3) Programe o intervalo em que a regra deve ser executada e um tempo de lookback adicional para verificações de integridade. Geralmente, recomendamos um certo tempo de lookback para levar em conta os atrasos que podem ocorrer no pipeline de ingestão de um determinado usuário. Também recomendamos algum tempo de lookback por não ser garantido que as regras sejam executadas exatamente no intervalo programado; assim, pode haver um atraso entre as execuções. Uma fila de workers do gerenciador de tarefas sobrecarregado ou recursos de computação insuficientes podem causar esses atrasos.
Esses são os três componentes básicos que compõem uma regra de detecções. Também fornecemos configurações para classificar essa regra de acordo com as táticas e técnicas do MITRE ATT&CK, além de links para referências adicionais.
Os usuários também podem executar ações nas regras existentes individualmente ou em massa, como duplicar (para customizações), desativar, exportar e excluir regras. Também temos um guia para mais informações sobre gerenciamento geral de regras.
Regras pré-criadas
As regras podem ser difíceis de serem desenvolvidas e demorar muito para serem testadas. Por esse motivo, as detecções começaram com 92 regras pré-criadas, desenvolvidas pela equipe de Inteligência e Analítica do Elastic Security, e têm sido usadas extensivamente na Elastic em um ambiente de produção. Novas regras que respondem às ameaças críticas mais recentes estão sendo desenvolvidas continuamente. Para carregá-las e deixá-las prontas para serem executadas, basta clicar em um botão! Você pode ler mais sobre como usar e ajustar as regras pré-criadas aqui.
Detalhes da implementação de detecções
Logo após o Alerting no Elastic Stack chegar ao Kibana para fornecer suporte para alertas como entidades de primeira classe, o Elastic SIEM utilizou o alerta como base para as detecções. Por trás da UI, o Detections usa uma API em camadas sobre a API de alerta. A API de detecções do SIEM proporciona comodidade, fluxos de trabalho (como a abertura e o fechamento de sinais), as especificidades de segurança do domínio (como a identificação do MITRE ATT&CK) e o suporte para KQL.
As regras são executadas nos bastidores criando uma chave de API e, em seguida, utilizando-a para fazer solicitações em nome do usuário. Usa-se search after para encontrar eventos correspondentes e bulk create para copiar as informações do evento para um documento de sinal no índice de sinais. Um sinal é composto pelos detalhes da regra e pelos detalhes do documento do evento original correspondido pela regra.
Se mais de 100 documentos correspondentes forem encontrados em uma única execução de regra, apenas as últimas 100 correspondências — por ordem de classificação `@timestamp` decrescente — serão copiadas para o índice de sinais. O índice de sinais é criado automaticamente em cada espaço do Kibana na primeira vez que você visita a página de regras de detecção de sinais. O formato do nome do índice é `.siem-signals-
O mapeamento do índice de sinais de SIEM é uma combinação do Elastic Common Schema (ECS) e de um mapeamento customizado da nossa definição do que é um sinal. Quando um documento correspondente for detectado na consulta de regra, ele copiará os campos dos índices de origem, e os campos de sinal resultantes serão pesquisáveis se os campos no documento de origem forem compatíveis com o ECS. Se os campos dos índices de origem não fizerem parte do ECS, eles ainda serão armazenados no `_source` do sinal e poderão ser visualizados na linha do tempo e em outras partes da aplicação. No entanto, não serão pesquisáveis.
Escalabilidade
A UI do Detections é criada sobre o framework de Alerting do Kibana recém-desenvolvido e o gerenciador de tarefas do Kibana. Esses dois fornecem recursos de ampliação horizontal e vertical, proporcionando flexibilidade para melhor adaptação a qualquer hardware disponível no momento. Os workers do gerenciador de tarefas do Kibana podem ter sua quantidade aumentada para tirar proveito da ampliação vertical ou podem ser replicados em instâncias separadas do Kibana e ampliados horizontalmente.
Quando várias instâncias do Kibana estiverem em execução, os gerenciadores de tarefas farão a coordenação para balancear as tarefas entre as instâncias. Atualizando o número de max_workers dentro do arquivo kibana.yml de seu padrão de 10, você pode fazer uma ampliação ou redução vertical para alocar recursos de maneira mais eficiente e apropriada por nó do Kibana.
Desduplicação de sinal
Quando uma regra está em execução, ela gera sinais com base nos eventos encontrados que correspondem à consulta da regra. Às vezes, sinais duplicados podem ser criados pela sobreposição de consultas em regras separadas ou por uma regra executada duas vezes seguidas que captura o mesmo sinal devido a um longo tempo adicional de lookback. Para impedir que um sinal duplicado apareça na tabela de sinais, identificamos sinais com base no índice de onde provém o evento, no ID do documento do evento de origem, no número da versão do evento de origem e no ID da regra em execução. Usando hash nessas propriedades, garantimos que apenas sinais únicos sejam adicionados ao índice de sinais.
Erros
Às vezes, os erros aparecem devido a um erro de sintaxe na consulta de uma regra ou a algum outro problema durante o período de execução da regra. Apresentamos esses itens na guia Failure History (Histórico de falhas) na página de detalhes da regra. Planejamos expandir a visibilidade das informações de execução e do monitoramento geral das regras no futuro.
E aqui podemos ver o histórico de falhas, que exibe os últimos cinco erros que ocorreram durante a execução da regra:
Detections do SIEM no futuro
A parte mais empolgante de trabalhar nessa versão beta do Detections do Elastic SIEM e lançá-la, é o feedback inicial e contínuo da comunidade no fórum de discussão do Elastic SIEM e na nossa lista de controle de recursos abertos.
Temos grandes planos para tornar as detecções ainda mais poderosas. A expansão das consultas de regras para incluir agregações, trabalhos de machine learning e EQL são apenas algumas delas. Se você pensar em algo que seja um ótimo caso de uso de segurança ou quiser fazer uma ou duas perguntas sobre o que está acontecendo, junte-se a nós!