Artigo desenvolvido pelo Paulo Deolindo, Consultor da Unirede..

 

Introdução

Enquanto Wazuh é um software open source de Gestão de Eventos de Segurança da Informação (SIEM), o Zabbix é um software open source muito conhecido e usado para monitoramento de métricas relacionadas a infraestrutura de TIC. Bom, acredito firmemente que até aqui, não há novidades em relação a esses conceitos, contudo, vamos explorá-los um pouco mais a fim de nos aprofundarmos em possíveis integrações, principalmente envolvendo ambos. 

Neste artigo, venho propor o cruzamento dos dados coletados por ambas as ferramentas, antes de que uma ou outra assuma o Alerting ou Reporting de forma individual, gerando por exemplo, um ticket para times de Service Desk ou ainda de Segurança da Informação e Compliance sobre algo que não está devidamente avaliado, algo incompleto e mal fundamentado. 

Cruzar os dados das duas ferramentas podem proporcionar uma melhor compreensão do cenário atual de um ativo de rede o qual acaba de passar por um movimento suspeito ou um real incidente de segurança da informação. 

 

Boa leitura! 

Eventos de Segurança

O que é um evento de segurança da informação?  

De forma simplificada, pode ser considerado qualquer evento gerado por um ativo de rede, por exemplo. Quando um usuário realiza um login, gera um evento de segurança, quando um software falha ou ainda um pedaço do hardware, havendo ou não comprometimento de todo o sistema, isso ainda é um evento de segurança. Então, perceba que evento de segurança não é necessariamente um ataque cibernético, mas este por sua vez, é um evento de segurança. Veja abaixo um dashboard do Wazuh, categorizando os eventos de segurança das últimas 24 horas. 

 

A grande questão é que todos esses eventos devem ser registrados, categorizados e sempre que possível ou necessário, correlacionados e analisados, quando não, reportados. Ocorre que quando um evento é gerado e então registrado, nossas ferramentas de monitoramento normalmente tomam como única verdade suas próprias condições para gerar os alertas e notificações. O resultado parcial é que, do outro lado, nossos analistas vão buscar mais dados sobre aquele ativo na tentativa de encontrar mais informações sobre possíveis outros danos que aquele evento pode ter gerado, ou ainda, se aquele evento em particular é apenas um sintoma e daí, vão atrás da latente causa raiz de tudo. 

Nesse ponto, um evento de segurança normalmente não traz tanto contexto e também por esse motivo, apesar de ser um dado valioso, pode facilmente enganar pessoas e até mesmo outros sistemas, levando a um esforço desnecessário e investimento de energia de análise que poderia ter sido já trabalhada, inclusive, pelas tais inteligências artificiais que de tanto falamos hoje em dia. 

 

Indicadores operacionais e de aplicação 

Enquanto isso, uma ferramenta de monitoramento (Zabbix) está coletando dados operacionais ou ainda de performance das aplicações daquele mesmo ativo que gerou um evento de segurança da informação. No entanto, por não ser de sua natureza ou ainda, pelo desconhecimento da necessidade de uma potencial investigação aprofundada em um caso de “Incidente de Segurança”, o Zabbix não foi devidamente preparado (digo, estou generalizando uma implementação mediana) e está agora apenas coletando dados sobre os mais conhecidos sinais vitais (CPU, disco, tráfego de rede, memória, processos, etc…). 

 

A importância de um contexto

Vamos ilustrar um cenário como em uma histórinha: 

1. Uma origem externa e desconhecida tenta acesso ao sistema 
2. O login falha 
3. Uma nova tentativa é realizada 
4. Ocorre nova falha 
5. A 8ª tentativa ocorre em intervalos curtos de tempo (ou espaçados) 
6. O SIEM faz o correlacionamento dos eventos e gera um outro com maior severidade 

Bom, pode não ser o “joaozinho” que esqueceu a senha na volta das férias. Pode sim ser um ataque do tipo “brute force”. Ainda que o espaço entre as tentativas seja maior, o SIEM ainda deve ser capaz de identificar essas tentativas e correlacioná-las devidamente. Ok. O Wazuh faz isso e muito bem. 

Antes de enviar os dados aos analistas, seria uma excelente ideia avaliar se houve no sistema algum outro comportamento anormal, afinal, é o início da investigação e não sabemos quanto dano mais foi causado, ou se realmente houve mais dano ao sistema. Nesse caso, os sinais vitais que monitoramos com o Zabbix pode nos dar insights ou de fato nos revelar informações valiosas para a investigação. 

Considere: 

1. O evento do Wazuh é enviado a uma tecnologia que centralizará esses dados e iniciará um novo fluxo de avaliações. Esse é o SOAR, um orquestrador de fluxos de processos em Segurança da Informação. No nosso caso, o Shuffle 
2. O Shuffle identificará o endpoint do qual se trata o evento de segurança e buscará por ele no Zabbix 
3. Uma vez identificado o endpoint, recuperaremos dados sobre o consumo de CPU, memória, disco, processos, usuários, tráfego de rede das interfaces, conexões abertas aos serviços do sistema, tempos de repostas das aplicações suportadas pelo dispositivo/ativo de rede, etc… 
4. Se os dados no Zabbix tiverem sido bem trabalhados em projeto, enviaremos ao Shuffle dados como o “desvio da baseline” sobre cada uma das métricas citadas, o que por si só, já é um trabalho da aprendizado de padrão comportamental realizado pelo próprio sistema (Machine Learning) 
5. O Shuffle recebe todos os dados solicitados pelo fluxo, juntando toda a informação e enviando um “prompt” à nossa IA preferida (seja qual for) solicitando insights 
6. Nossa IA preferida responde com os insights e dicas sobre o ocorrido, tendo ou não sugestões sobre como lidar com o problema ou simplesmente nos orientando a ignorá-lo (caso não tenha percebido dano significativo) 
7. O Shuffle então, após coletar todas essas respostas em seu fluxo, abre um ticket em nossa ferramenta de chamados com todas as informações coletadas e munindo nosso analista de informações sobre como agir, simplificando seu processo de análise ou, minimamente, o auxiliando no acionamento de algum playbook para lidar com o problema 

 

Variações do mesmo tema 

Neste artigo, tomamos como base o Wazuh e Zabbix, sendo ambas ferramentas orquestradas pelo Shuffle. A ferramenta de tickets poderia ser o GLPI, o OTRS, o JIRA ou ainda qualquer uma outra que tenha uma interface via API para ser consumida. 

Sua IA preferida pode ser o ChatGPT, Google Gemini, Claude ou qualquer uma outra. Não fará diferença. Se for um evento de segurança com IP externo público caracterizado no evento, podemos adicionar uma consulta a alguma das várias fontes de Threat Intelligence disponíveis e enriquecer ainda mais nossos dados para análise. 

Bom, o que mais você gostaria de fazer? 

 

Conclusão

Muitas vezes somos vítimas da facilidade e dos atalhos, ou seja, somos tentados a baixar ferramentas livres e aplicar seus templates padrões, nos equivocando quanto à qualidade do monitoramento.  

Nesse ponto, deixo uma observação que acho importante: isso vai falhar em vários momentos. A questão é quando, e não se. Quando trabalhamos o conceito de SOC (Security Operation Center) precisamos nos atentar às mais variadas fontes de dados ou informação disponíveis e gerar o devido contexto aos nossos eventos. Caso contrário, talvez não estejamos realizando um bom trabalho ou um trabalho diferenciado. 

Zabbix e Wazuh são ferramentas distintas e na minha visão, não concorrem, mas se complementam. Orquestradores como Shuffle são muito bem-vindos e podem realizar a parte difícil do trabalho: as integrações diversas. Se eu pudesse dar alguma outra dica aqui, daria a seguinte: serás tentado a realizar integrações de aplicação para aplicação, amarrando e inflexibilizando os fluxos de dados necessários aos processos de seu negócio. Tente evitar isso. 😊 

Muito mais pode ser feito, além do que foi citado nesse pequeno artigo. Espero poder ajudar-lhe em um futuro não muito distante, se esse tema lhe interessou. 

Fique vigilante!