SIEM: correlação e investigação de logs

Entendendo o SIEM e seu papel no SOC - Apresentação

Apresentando o curso e o instrutor

Olá! Já paramos para pensar em como uma operação de SOC consegue analisar centenas ou até milhares de alertas? Como identificamos o que realmente representa uma ameaça, o que é apenas ruído e quais informações consideramos para categorizar corretamente cada caso? Por trás dessas análises, existem conceitos, fundamentos, logs, regras, detecções, correlação, frameworks e, principalmente, o raciocínio lógico da pessoa analista para a tomada de decisão. É justamente isso que vamos aprofundar e estudar neste curso.

Eu sou Gabriel Yamashita, especialista em Cibersegurança há mais de 10 anos, com atuação em empresas de grande, médio e pequeno porte.

Audiodescrição: Sou um homem pardo, com traços orientais, cabelo escuro; estou vestindo uma camisa branca e, atrás de mim, há um ambiente decorado com alguns itens.

Tenho especialização em liderança de SOC, especialização em SIEM, XDR e EDR, sou especialista em C-Search e minha formação é em Análise e Desenvolvimento de Sistemas, com pós-graduação em Segurança Defensiva e Cibersegurança pela FIAP, além da certificação CompTIA Security+ e demais certificações que me ajudam a entender melhor como funciona esta ferramenta, para aprofundarmos mais sobre ela.

Detalhando os conteúdos e as ferramentas do curso

Durante este curso, vamos aprender muito mais sobre os fundamentos do SIEM, os princípios necessários para seu funcionamento, como os logs chegam, como são correlacionados e tudo o que está ao redor desse processo para que ele opere corretamente.

Vamos estudar coleta e análise de logs, aproveitando tudo aquilo que o SIEM nos entrega para que nós consigamos realizar análises mais aprofundadas.

Nós vamos utilizar o Wazuh para entender melhor essa coleta, essa análise e os logs que chegam. Dentro do Wazuh, vamos falar sobre a criação e os ajustes das detecções existentes que vamos criar, bem como melhorias nessas detecções.

Vamos aprender a investigar incidentes, utilizar frameworks e o SIGMA para aprofundar e melhorar a criação de nossas regras. Ao final do curso, veremos como utilizar a IA na triagem, considerando que é uma ferramenta que tem crescido muito; vamos entender como empregá-la melhor em nossas análises.

Descrevendo a estrutura das aulas

A estrutura do curso está dividida em quatro aulas.

• A primeira aula, em que vamos falar sobre o SIEM, entender o papel do SOC e em que momento o SOC entra para a utilização do SIEM.

Na Aula 2, vamos colocar o Wazuh para funcionar, conectando os conceitos técnicos que aprendemos à prática, para consolidar o entendimento do que foi feito.

Na Aula 3, vamos trabalhar engenharia de detecção, aprimoramento dos alertas que temos e o entendimento de como podem operar melhor.

Na Aula 4, vamos abordar a investigação de alertas e, por fim, a utilização de frameworks e IA para aprimorar nossa triagem, facilitando a distinção entre ruído e ameaça no ambiente.

Consolidando os objetivos e encaminhando para a próxima aula

Ao final deste curso, entenderemos o papel do SIEM na operação do SOC e na operação de segurança, bem como as principais fontes de logs que o abastecem e que precisamos dominar. Vamos compreender o caminho do log bruto até o alerta, desde a geração até a visualização no ambiente.

Vamos aprender a operar o Wazuh e a conduzir investigações básicas, entendendo como o Wazuh funciona e como o utilizamos para atender às nossas necessidades.

Vamos criar e ajustar regras de detecção, aprimorando-as para obter melhor entendimento e reduzir ruído.

Vamos diferenciar o que é verdadeiro positivo e o que é falso positivo, algo essencial na operação. Muitas operações falham justamente nesse ponto: eventos benignos que exigem tratamento ou investigação acabam classificados incorretamente como falsos positivos, ou ocorre o inverso.

Vamos compreender a proposta do SIGMA e como ele ajuda no nosso dia a dia, especialmente no contexto de engenharia de detecção.

Vamos relacionar os alertas aos principais frameworks de segurança. É importante conhecermos esses frameworks, pois funcionam como referência regulatória e de padronização dos alertas utilizados atualmente; compreendê-los é fundamental para a continuidade das análises.

Por fim, vamos utilizar IA com responsabilidade durante a triagem, discutindo a melhor forma de empregá-la para evitarmos problemas em sua utilização.

Vamos começar. Será uma jornada interessante e reveladora. Esperamos que vocês gostem. Vamos para a próxima aula. Valeu, tchau, tchau!

Entendendo o SIEM e seu papel no SOC - Entendendo o SIEM

Apresentando o curso e objetivos

Fala, pessoal. Meu nome é Gabriel Victor Pereira Yamashita e serei seu instrutor nesse curso chamado SIEM: correlação e investigação de logs.

Neste curso, nós vamos trabalhar a correlação e a investigação de logs (registros) de maneira muito próxima do que ocorre em uma operação de segurança. O intuito é entendermos como funciona o SIEM, de onde vêm os logs (registros), quais são as maneiras como esses registros são analisados, como esse log (registro) bruto é transformado em um alerta e, também, compreendermos algumas ferramentas mais utilizadas — os SIEMs mais utilizados. Em seguida, vamos aprofundar na parte prática, voltada à criação de regras, criação de dashboards (painéis) e demais recursos.

Antes de falarmos propriamente de regras ou desses dashboards (painéis), ou trabalharmos diretamente dentro da própria ferramenta do SIEM, vamos abordar alguns pontos que fazem sentido para o entendimento do funcionamento do SIEM. São tópicos que elucidam melhor aquilo que vamos analisar no dia a dia.

Nesta primeira aula, nós vamos entender como o SIEM funciona, por que ele é relevante, por que traz tantos benefícios à operação de segurança e por que muitos profissionais e empresas escolhem instalar ou configurar um SIEM em sua operação. Nesta introdução, vamos falar sobre logs (registros), correlação, a relação entre logs (registros) e correlação, a geração de alertas e as nossas investigações.

Analisando eventos do Windows e falhas de autenticação

Vamos ao primeiro contexto. Nós temos um log (registro) isolado que mostra apenas um evento. Trata-se de um evento categorizado pelo Event ID 4625 do Windows. Os eventos do Windows possuem categorias representadas por IDs. Para falhas de login (autenticação), qualquer falha que ocorrer dentro do ambiente terá a categorização 4625. O 4624 indica sucesso, e assim por diante. Em geral, são quatro números.

No caso em questão, temos um evento 4625 (falhas de login [autenticação]). Nesse contexto, há um usuário chamado suporte.admin, um host (máquina) identificado como WS023 e uma origem com o IP 203.0.113.45. É um IP público, externo, que aparece como origem. Temos uma janela de 54 segundos. Ou seja, o usuário suporte.admin, no host (máquina) WS023, falhou seis vezes na autenticação em 54 segundos.

Esse evento único não conta uma história completa. Foram seis falhas de login (autenticação) em uma janela de 54 segundos. Essas falhas podem ter ocorrido porque a pessoa que utiliza a conta suporte.admin errou a senha; pode ser alguma configuração incorreta; ou alguma automação que utiliza a conta suporte.admin nesse host (máquina), com credenciais inválidas, registrando essas seis falhas. Nesse contexto, temos apenas eventos de falha, sem muitos elementos para analisar. Não há uma narrativa; há somente um alerta: seis falhas de login (autenticação).

Correlacionando eventos no SIEM

Agora, consideremos um contexto mais abrangente. Temos os seis eventos 4625 (falhas), conforme falamos anteriormente. Em seguida, há um evento de sucesso 4624. Logo após, aparece o evento 4672, que indica sessão com privilégios sensíveis — houve elevação de privilégios para esse usuário, executando com privilégios administrativos. Na sequência, inicia-se um novo processo do PowerShell. Tudo isso ocorre dentro da mesma janela de 54 segundos.

Aqui temos o que chamamos de correlação. O SIEM correlacionou todos os eventos do usuário suporte.admin no host (máquina) WS023. A sequência correlacionada foi: falhas (4625), sucesso (4624), sessão com privilégios sensíveis (4672) e novo processo PowerShell. Agora a história começa a ser contada de maneira mais abrangente e detalhada, com início, meio e fim. É isso que entendemos por correlação: a sequência temporal e contextual dos eventos que exigem atenção.

O nosso SIEM nos ajuda exatamente nisso. Em vez de analisarmos um evento isolado, ele amplia o escopo para correlacionar tudo que merece atenção. A partir do momento em que o usuário suporte.admin falha seis vezes, depois obtém sucesso, eleva privilégios e, na sequência, abre um processo no PowerShell, isso gera um alerta dentro do nosso SIEM com toda essa história para que façamos a análise.

Em um painel de correlação, isso aparece, por exemplo, da seguinte forma: às 14h32 e 01 segundo, seis eventos de falha; às 14h32 e 37 segundos, um logon (autenticação) com sucesso; às 14h32 e 38 segundos, privilégios elevados; e às 14h32 e 55 segundos, um processo do PowerShell executado. A partir daqui, iniciamos nossa ação e nossa análise com base no que o SIEM nos apresenta.

Entendendo o papel do SIEM na investigação

O objetivo do funcionamento do SIEM é exatamente esse: agregar as correlações que merecem atenção, sinalizar o que requer investigação e fornecer contexto para que realizemos a análise, entendendo se o comportamento é malicioso ou legítimo.

Por meio dessas correlações, nós, analistas, vamos tomar a ação de categorizar um evento como falso positivo, como legítimo ou de nos aprofundarmos nas análises. O SIEM funciona para transformar todos aqueles logs (registros), conforme vimos anteriormente, em um contexto para nossa investigação. Ele agrega tudo, organiza em um contexto e, a partir daí, precisamos observar os atores e os acontecimentos daquela narrativa com base na análise e nas sinalizações emitidas pelo SIEM.

O SIEM nos ajuda com a centralização, reunindo todos os logs (registros) do nosso Windows (Windows), Linux (Linux), firewall (firewall) e da nossa nuvem. Ele reúne tudo isso para aprimorar a narrativa de investigação. Em vez de relatar algo básico como “falhou”, passamos a descrever que houve falha, depois sucesso, em seguida uma elevação de privilégios e, na sequência, a execução do comando PowerShell (PowerShell). Todas as camadas se integram para que a narrativa ganhe profundidade e apoie a investigação.

Outro ponto em que o SIEM atua é a normalização: ele consolida os dados e, em seguida, transforma as relações entre eventos em alertas com contexto. Assim, a “história” ganha mais camadas e aprimoramentos para que tenhamos contexto suficiente e possamos decidir se precisamos analisar algo com maior profundidade.

Diferenciando sinalização, alerta e incidente

Precisamos, além disso, separar dois conceitos. A função do SIEM é sinalizar. Ele sinaliza todo comportamento para o qual estiver configurado, seja pelas configurações que já vêm no produto, seja por regras que criamos para sinalizar comportamentos específicos. Isso é configurável por quem manuseia a ferramenta. O SIEM sinaliza tudo o que é categorizado como malicioso dentro dele e, muitas vezes, também o que é apenas diferente do padrão, gerando alertas. Consequentemente, ele pode gerar uma enxurrada de falsos positivos e até mesmo sinalizações de comportamentos legítimos, produzindo muito material para analisarmos.

O alerta indica uma condição que precisa de análise e direciona a triagem. Em vez de procurarmos manualmente por ocorrências, o SIEM, com base nos comportamentos configurados, pode sinalizar, por exemplo, todas as falhas de login, facilitando a triagem para entendermos as falhas de autenticação no nosso ambiente. Ainda assim, um alerta, por si só, não comprova a existência de um incidente.

O incidente é aquilo que é confirmado por evidências. A partir do que foi alertado e sinalizado pelo SIEM, passamos pela etapa de triagem, realizamos a validação de segurança, delimitamos o escopo identificado e nos aprofundamos na análise. A partir daí, decidimos se tomamos uma ação ou não. Todo incidente exige uma resposta: se ele for comprovado, existe um perigo real no nosso ambiente, e precisamos agir para contê-lo — por exemplo, isolando a máquina afetada e executando outras medidas de contenção. Com isso, entenderemos se o evento é ou não malicioso.

Relacionando logs, contexto e investigação

Como aprendizado relevante desta aula: os logs (registros) enviados ao nosso SIEM são a matéria-prima da investigação. Eles são o ponto de maior relevância dentro do SIEM; é a partir deles que vamos esmiuçar as evidências.

Sobre contexto: eventos isolados — logs (registros) isolados — ganham significado quando são relacionados. Quando correlacionamos, por exemplo, um log (registro) no horário X com outro no horário Y, obtemos contexto, e esse contexto conta melhor o que está acontecendo.

Nosso SIEM centraliza os logs (registros), traz contexto e normaliza as informações. Ele funciona como um centralizador do ambiente e, além disso, normaliza e correlaciona. A partir dessa normalização e correlação, começa a sinalizar — destacando o que merece atenção.

Por fim, o ponto mais importante, que será muito abordado nesta aula e ao longo deste curso, é a investigação. Os alertas gerados existem para que nós, analistas, possamos investigar: o alerta sinaliza e as evidências confirmam ou descartam a hipótese. Que evidências? Aquelas que nós, como analistas, vamos reunir, analisar e aprofundar. Com isso, confirmaremos ou descartaremos a hipótese de incidente.

Encerrando a aula

Encerramos esta aula sobre o funcionamento do SIEM. Na próxima aula, vamos detalhar a origem dos logs (registros) e nos aprofundar nas ferramentas e nos contextos que os trazem para o ambiente.

Até a próxima.

Entendendo o SIEM e seu papel no SOC - De onde vem os logs

Apresentando a aula e objetivos

Olá, pessoal. Tudo bem?

Dando seguimento ao nosso curso "SIEM: correlação e investigação de logs". Na Aula 1, nós falamos sobre o SIEM, como ele funciona e por que é relevante para nossa operação. Nesta Aula 2, nós vamos explicar de onde vêm os logs e nos aprofundar no que alimenta o SIEM para a geração de eventos e para nossa análise. Vamos nos aprofundar nesse contexto.

Listando as principais fontes de logs

Quais são as fontes que alimentam o SIEM? O que torna o SIEM uma ferramenta robusta para o nosso dia a dia? São elas:

• Endpoints (pontos finais): Windows e Linux, incluindo estações de trabalho e servidores. Em uma organização, normalmente há servidores e serviços como o Active Directory. Nesses equipamentos, configuramos agentes ou conectores do SIEM para coletar os logs locais e enviá-los ao SIEM. Essa é uma das fontes mais relevantes.

• Identidade e autenticação: o Active Directory também envia logs ao SIEM, abastecendo-o com informações relacionadas ao gerenciamento de usuários e autenticação.

• Microsoft Entra ID: o gerenciamento de identidades no ambiente de nuvem. Por exemplo, ao ingressar em uma organização, criamos credenciais como “gabriel.yamashita@algo”. Essas contas são gerenciadas no Microsoft Entra ID, onde configuramos permissões e funções, como administrador. Essas informações também abastecem o SIEM, ampliando a camada de monitoramento.

• Logins e privilégios: eventos relacionados a autenticações, perfis de usuários, administradores e privilégios em geral também são enviados para abastecer o SIEM.

• Nuvem Microsoft 365: Excel, Word, Outlook e demais ferramentas do Microsoft 365 enviam informações ao SIEM, enriquecendo os dados de monitoramento.

• AWS: toda a camada de nuvem pode ser direcionada ao SIEM, aprofundando e enriquecendo os logs enviados.

• Firewall e rede: o firewall no ambiente protege o perímetro, aplica configurações de VLAN e controla o tráfego. Essas informações também são enviadas ao SIEM. Entre as mais importantes estão conexões, bloqueios e tráfego:

  • Conexões: toda comunicação com o ambiente pode ser enviada ao SIEM.
  • Bloqueios: bloqueios de software ou de sites específicos também são enviados.
  • Tráfego: por exemplo, quando um usuário acessa o YouTube e acompanha uma transmissão ao vivo, esse fluxo gera tráfego constante, que pode ser visualizado no SIEM quando ele está devidamente configurado.

• Aplicações: autenticações, erros e acessos de aplicações no ambiente geram eventos. Tudo o que envolve o uso de uma aplicação envia logs para o SIEM, abastecendo e enriquecendo continuamente a plataforma.

• EDR: a nomenclatura EDR significa Endpoint Detection and Response (Detecção e Resposta em Pontos Finais). Em geral, são ferramentas que atuam como antivírus (com algumas exceções). Se há um antivírus no ambiente, nós o configuramos para integrar com o SIEM, de modo que alertas de processos, malware e comportamentos suspeitos sejam enviados ao SIEM e visualizados em um só lugar. É comum as organizações utilizarem seus antivírus integrados ao SIEM, de forma que o SOC faça a análise centralizada. Em vez de acessar o antivírus e verificar alerta por alerta, monitoramos por meio do SIEM, que recebe os dados de processos e facilita o acompanhamento pelo SOC.

Todos esses logs e eventos são enviados via telemetria. Nós vamos nos aprofundar mais na próxima aula, abordando os logs brutos: como são enviados, que tipos de logs são gerados e como ocorre essa coleta. Por ora, é importante reforçar que tudo é enviado via telemetria para o SIEM, que realiza correlações e apoia nossa investigação para entender os comportamentos observados.

Correlacionando camadas para construir contexto

Precisamos compreender as fontes de dados e outro ponto muito importante: essas fontes enxergam apenas uma parte pequena da história. Quando todas as fontes se comunicam com o nosso SIEM (gerenciamento de informações e eventos de segurança), começamos a identificar os autores dessa história. Passamos a categorizar, por exemplo: se temos o nosso AD (Active Directory), teremos identidade e quem autenticou. Teremos o registro do usuário Gabriel acessando determinado recurso. Quando temos um log (registro) de identidade, sabemos disso.

Quando temos um log (registro) de endpoint (dispositivo final), que vem do EDR (detecção e resposta em dispositivos finais), saberemos o que foi executado. Por exemplo, que Gabriel executou um comando em PowerShell (shell de automação da Microsoft). Entretanto, isso só é visível quando essa camada de EDR (detecção e resposta em dispositivos finais) abastece o nosso SIEM (gerenciamento de informações e eventos de segurança).

Se temos também a camada de rede, com o nosso firewall (barreira de rede) funcionando, sabemos com quem o host (máquina) se comunicou. Supondo que Gabriel abriu uma sessão via acesso remoto para outra máquina, conseguiremos visualizar o computador de Gabriel acessando o servidor, a partir do momento em que as camadas de rede e de firewall (barreira de rede) são visualizadas dentro do nosso SIEM (gerenciamento de informações e eventos de segurança). Por isso é importante ter as camadas de rede e de firewall (barreira de rede) integradas ao ambiente.

Na camada de aplicação, veremos o que aconteceu dentro do serviço. Saberemos o que Gabriel executou no PowerShell (shell de automação da Microsoft), qual script (roteiro de comandos) foi utilizado e como ele acessou a máquina, se usou o cliente de Área de Trabalho Remota do Windows, isto é, o comando/executável MSTSC (cliente de Área de Trabalho Remota do Windows), ou uma ferramenta como o AnyDesk (ferramenta de acesso remoto), por exemplo, para acessar esse servidor de forma remota. Com a camada de aplicação monitorada, entendemos isso também dentro do ambiente.

Destacando a importância do contexto e as limitações do siem

Temos, portanto, diferentes visões que convergem para um único propósito: apoiar nossa investigação. Esse conjunto de fontes facilita nosso dia a dia e nosso monitoramento, reunindo diferentes perspectivas e gerando contexto — o elemento mais importante para o trabalho. Sem contexto, não temos o que contar; sem o que contar, não temos o que analisar. Assim, não teremos hipótese alguma para afirmar se algo é malicioso ou legítimo.

O que ocorre quando não temos uma fonte de log (registro) dentro do nosso SIEM (gerenciamento de informações e eventos de segurança)? Diferentemente de outras ferramentas, o SIEM (gerenciamento de informações e eventos de segurança) não infere dados que não recebe. Existem ferramentas de XDR (detecção e resposta estendida), cuja detecção é correlacionada e estendida ao evento, que basicamente capturam tudo por telemetria: configuramos o domínio e elas coletam os dados. O SIEM (gerenciamento de informações e eventos de segurança) não funciona assim. Ele opera de maneira precisa: se temos um log (registro), temos o que mostrar; se não temos um log (registro), não temos o que mostrar.

Vamos analisar um exemplo em tela. Temos os logs (registros) de endpoint (dispositivo final), de firewall (barreira de rede) e de identidade disponíveis, mas não temos log (registro) de aplicação. Basicamente, teremos um ponto cego. Conseguiremos saber qual foi o endpoint (dispositivo final), o endereço IP e quem utilizou o recurso, mas não saberemos qual aplicação foi executada, pois a camada de aplicação, isto é, o serviço de aplicação, não está sendo monitorada. Reforçando: é uma ciência exata. Se temos um log (registro), temos o que mostrar; se não temos um log (registro), não temos o que mostrar. A investigação e a análise chegarão até um ponto e não conseguirão avançar, pois os logs (registros) necessários não estão sendo coletados.

Infelizmente ou felizmente, o SIEM (gerenciamento de informações e eventos de segurança) funciona assim. Precisamos que todas as camadas tenham plena comunicação para que seja possível obter contexto e apresentar essas informações para a pessoa analista trabalhar dentro do ambiente. Somente assim teremos visibilidade completa. O SIEM (gerenciamento de informações e eventos de segurança) correlaciona apenas o que recebe; o que não recebe, não correlaciona. Portanto, a correlação vai até certo ponto. Se, a partir dali, não há mais dados, não haverá o que correlacionar: o evento termina, a história termina, sem mais informações a serem contadas, e a análise fica incompleta.

Encerrando a aula e reforçando o escopo do monitoramento

Essas são as camadas e os serviços mais importantes que se comunicam com o SIEM (gerenciamento de informações e eventos de segurança). Existem outras fontes, mas, neste momento, elas não são tão relevantes. Vamos nos concentrar nessas, pois são as mais comuns e representam o que normalmente ocorre na operação de um SOC (Centro de Operações de Segurança). Em muitos ambientes de SOC (Centro de Operações de Segurança), há um escopo menor: às vezes monitora-se somente endpoints (dispositivos finais), somente servidores ou apenas o firewall (barreira de rede). Em outros, toda a gama de camadas é monitorada. Por isso é importante termos todas elas integradas, para que os contextos não fiquem incompletos.

Basicamente, era isso que tínhamos para apresentar nesta aula. Na próxima aula, vamos detalhar os logs (registros), explicar como eles chegam, e organizar melhor a ideia de como são recebidos e quais pontos serão coletados para a nossa análise.

Falamos na próxima aula. Tchau, tchau!

Sobre o curso SIEM: correlação e investigação de logs

O curso SIEM: correlação e investigação de logs possui 189 minutos de vídeos, em um total de 30 atividades. Gostou? Conheça nossos outros cursos de Blue Team & SOC em Cibersegurança, ou leia nossos artigos de Cibersegurança.

Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:

• Entendendo o SIEM e seu papel no SOC
• Colocando o Wazuh para funciona
• Engenharia de detecção
• Investigação de alertas com frameworks e IA