Reduzindo o Tempo de Detecção de Violações: Disponibilidade dos Dados de Log

Olá novamente! No artigo anterior, já estabelecemos que muitas coisas podem fugir do controle quando você está construindo um SOC virtual ou em escala completa, especialmente quando se trata de operacionalizar o SIEM como a tecnologia central de qualquer SOC. Também estabelecemos que a automação é o caminho a seguir se alguém quiser acompanhar as ameaças modernas e a sobrecarga que é produzida pelas tecnologias SIEM e SOC. Hoje começamos a analisar cada implantação e operações do SIEM peça por peça, a primeira que vem à mente é a disponibilidade de dados. Existem muitos fatores que impactam o tempo de detecção de violação e, em 2015, ele ainda está acima da média de 200 dias, mas isso não ocorre porque o SIEM é a tecnologia escolhida para detecção de violações. Um SIEM só pode fornecer o resultado com base nas entradas que recebe, e se perdermos algo na entrada, não devemos esperar que a saída seja completa, acionável e, às vezes, não teremos saída alguma.É realmente culpa do SIEM por perder logs (e incidentes)? Bem, isso novamente depende de muitos fatores e para esclarecer essa confusão e manter o SIEM operacional continuamente, uma pessoa responsável por sua administração/manutenção (sua empresa tem uma, certo?) precisa ter informações suficientes em qualquer momento para responder a estas duas perguntas: “Todos os dados de log no escopo estão sendo coletados?” e se a resposta for NÃO “O problema está do lado do SIEM ou fora dele?”. Se a resposta para a primeira pergunta for NÃO, tenha certeza de que você está perdendo coisas importantes que têm impacto direto no seu tempo e precisão de detecção de incidentes. E a verdade é que nenhuma solução SIEM responde a isso de fábrica – sempre é um esforço manual responder a essa questão.Você já viu algum SIEM que diga “A disponibilidade de dados de log da sua rede é 85%”? Eu não vi. No entanto, ainda temos uma segunda pergunta que obviamente também não é respondida pelo sistema, já que ele não pode responder à primeira. Mas, nem tudo está perdido e as respostas estão lá se alguém fizer pesquisa ou se dedicar tempo e esforço suficientes para buscá-las manualmente.Vamos considerar alguns exemplos com base em como se coleta dados de log e começar com o mecanismo de coleta de log mais comum – syslog. É improvável que alguém possa nomear uma implementação SIEM que não use syslog. Existem muitas maneiras de que dados possam ser perdidos com syslog: um daemon no método de coleta de pipe perde dados quando o componente de coleta é interrompido; um protocolo syslog UDP (padrão) não garante a entrega de pacotes, alto volume de tráfego syslog (tanto UDP quanto TCP) pode ser prejudicado por limites de tamanho de buffer e limitações de largura de banda e até mesmo especificações de processamento de taxa de pacotes de uma NIC concreta. Mesmo no caso de leitura de dados de log de um arquivo, deve-se considerar rotação e integridade do arquivo. Diagnósticos desses problemas são sempre uma tarefa de rotina manual que envolve ler logs de diagnóstico dos próprios componentes do SIEM. Se ele tiver dados de diagnóstico para começar! Mesmo os dados de diagnóstico mais feios são melhores do que nenhum dado de diagnóstico e uma desculpa barata de “oh, nosso SIEM é tão mágico que não tem erros!”. Em seguida, estaríamos ocupados construindo (ou reutilizando?) conteúdo de correlação que estabelece quantidades de fluxo de log e desvios (Alguém realmente está satisfeito com os resultados de tal conteúdo? E quanto aos recursos que ele consome?), executando TCPdump para verificar taxas de perda de pacotes, monitorando disponibilidade de componentes através de fontes externas… Espere, acho que inventamos pelo menos 3 ferramentas adicionais que precisam ser adicionadas ao SIEM para monitorar a si próprio, só para responder a uma simples pergunta “Qual é a % de disponibilidade de dados de log da minha rede?”. Se falarmos de tentativas concretas de automatizar isso, digamos, Splunk on Splunk, elas são realmente eficientes? Quanto $$ extra de custo de licença é necessário adicionar para ser capaz de autodiagnosticar a plataforma SIEM/Gerenciamento de Logs e quanto de sobrecarga de desempenho essa aplicação mais popular produz?.. Microsoft Windows Event Log. Para manter os problemas curtos: rotação de log, largura de banda de rede, erros de autenticação / bloqueios de senha, instabilidade de WMI e JCIFS, alta carga de servidores Windows ocupados (auditoria de arquivos, Active Directory etc.). Monitorar isso exigiria novamente um conjunto completo de ferramentas e essas ferramentas serão diferentes quando comparadas com ferramentas de monitoramento syslog! Podemos continuar com uma longa lista incluindo bancos de dados, firewalls/ngfw/ips/ngips/utm (olá OPSEC & SDEE) e descobriremos ainda mais coisas que acontecem fora do SIEM, sobre as quais o SIEM não tem efeito, mas deve saber(!) e ele deve fornecer essas informações de forma rápida e precisa ao administrador. No entanto, para aqueles que leram até aqui, há boas notícias, já que o SIEM (ou a maioria dos SIEMs) possui logs de diagnóstico legíveis (quase). Esses arquivos de diagnóstico difíceis de encontrar, chamadas de API ocultas ou rastreamentos de pilha Java multilinha têm bits e bytes de informação que podem fornecer respostas para muitas das questões levantadas acima. E ao combiná-los e aplicando métricas de perfil significativas podemos responder a essas duas simples perguntas que fazem toda a diferença entre saber que sua plataforma de detecção de segurança crítica para a missão está funcionando conforme o esperado ou ignorar o problema / consertá-lo meia-boca com mais FTE no problema. A automação está aqui para todos que querem garantir que seus dados de log estejam disponíveis conforme planejado no projeto, exigido pela organização/cliente e que eles obtenham um retorno adequado sobre o investimento em SIEM. Espero que isso lhe deixe com algo para pensar. Fique ligado!

p.s. Caso você seja um dos especialistas do HPE ArcSight, há mais boas novas! Como parte de uma iniciativa global para fazer com que as plataformas SIEM entreguem valor e economizem tempo de especialistas SIEM em todo o mundo, a SOC Prime fornece um serviço gratuito de verificação de saúde instantânea do SIEM online, que pode consumir arquivos agent.log e fornecer as 5 questões críticas e soluções para elas em menos de 5 minutos. Tem um agent.log? Jogue aqui e veja por si mesmo!