Olá a todos!!
Há uns anos, “IA na segurança” era basicamente um filtro de spam um bocadinho mais esperto e umas regras de correlação no SIEM a que chamávamos machine learning para soar bem nas reuniões. Hoje a coisa mudou de figura. Já temos modelos de linguagem treinados de raiz para cibersegurança, agentes que fazem reconnaissance e exploração sozinhos, e ferramentas que conseguem ler dez mil alertas por hora e dizer-nos quais valem a pena. O termo que anda a colar para tudo isto é Cybersecurity AI, ou CAI.
A pergunta que interessa não é se isto é útil. É: dá para fazer com ferramentas abertas, sem depender de um fornecedor que cobra por endpoint, e a correr na nossa própria infraestrutura? A resposta curta é que sim, e cada vez mais. A resposta longa, com comandos e exemplos que dá para copiar para um terminal, é este artigo.
Porque é que open source faz especialmente sentido aqui
Em quase qualquer outra área de TI, escolher open source é uma decisão de custo e de gosto. Em segurança é um bocadinho mais do que isso.
Quando uma ferramenta de deteção decide que um processo é malicioso e o mata, queremos perceber porquê. Com uma caixa preta proprietária, a melhor explicação que vamos ter é o que o vendor decidir pôr no relatório. Com código aberto conseguimos abrir o capot, ler a regra, perceber a lógica e, se for preciso, corrigi-la antes de ela nos rebentar com produção a uma sexta-feira à tarde. Essa auditabilidade deixou de ser um luxo de quem gosta de ler código e passou a ser requisito em setores regulados.
Há também a questão do controlo. Ninguém quer descobrir, a meio de uma renovação de contrato, que toda a sua postura de segurança depende de um produto cujo preço triplicou e cujos dados estão num datacenter que não controla. As soluções abertas tiram esse poder de cima da mesa. E, talvez o mais importante para o tema deste artigo, os modelos e frameworks de IA abertos crescem ao ritmo de comunidades enormes, o que significa que uma técnica nova de deteção ou um detetor para uma família de malware recente aparece muitas vezes em dias, não em ciclos de release anuais.
Nada disto é magia. Open source troca a fatura mensal por tempo da equipa, e isso é um custo real. Mais à frente falo disso sem rodeios.
A camada nova: modelos e frameworks de IA feitos para segurança
Esta é a parte que mudou tudo nos últimos dois anos, por isso começo por aqui, e desta vez com as mãos na massa.
Foundation-Sec-8B, da Cisco
Em meados de 2025 a Cisco lançou, através da equipa Foundation AI (que herdou muita gente da aquisição da Robust Intelligence), um modelo de linguagem chamado Foundation-Sec-8B. É um modelo de oito mil milhões de parâmetros, construído sobre o Llama 3.1, mas com continuação de treino sobre dados de segurança: bases de vulnerabilidades, mapeamentos de CVE e CWE, a matriz MITRE ATT&CK, relatórios de threat intelligence e write-ups de exploração.
Os pesos estão no Hugging Face com licença Apache 2.0, e há várias versões a escolher conforme o uso. A Foundation-Sec-8B é o modelo base. As Foundation-Sec-8B-Instruct e Foundation-Sec-1.1-8B-Instruct são as que servem para chat e triagem, sendo que a 1.1 traz uma janela de contexto de 64 mil tokens, ou seja, engole relatórios de incidente e feeds de threat intel inteiros sem se engasgar. Há ainda uma Foundation-Sec-8B-Reasoning para quem quer ver o raciocínio passo a passo.
A forma mais rápida de experimentar, sem GPU topo de gama, é pegar numa versão quantizada e correr com Ollama. A versão Q8 ocupa cerca de 8,5 GB em vez dos 16 GB do modelo em precisão total:
# Descarrega e corre uma versão quantizada diretamente do Hugging Face
ollama run hf.co/fdtn-ai/Foundation-Sec-8B-Q8_0-GGUF \
"Resume o CVE-2021-44228 numa frase, indica o CWE associado e a técnica MITRE ATT&CK mais provável."
Para integrar num pipeline em vez de brincar no terminal, usa-se a versão Instruct via Transformers:
import torch
from transformers import AutoTokenizer, AutoModelForCausalLM
tok = AutoTokenizer.from_pretrained("fdtn-ai/Foundation-Sec-8B-Instruct")
model = AutoModelForCausalLM.from_pretrained(
"fdtn-ai/Foundation-Sec-8B-Instruct",
torch_dtype=torch.bfloat16,
device_map="auto", # usa a(s) GPU(s) disponíveis; uma ou duas A100 chegam
)
alerta = {
"regra": "Múltiplas falhas de autenticação seguidas de login com sucesso",
"origem": "203.0.113.45 (Roménia)",
"utilizador": "svc_backup",
"host": "fileserver-02",
"hora": "03:14 (fora de horas)",
}
prompt = f"""És um analista de SOC nível 1. Recebeste este alerta:
{alerta}
Responde só em JSON com os campos: severidade (baixa/media/alta/critica),
falso_positivo_provavel (true/false), tecnica_attack, e proxima_accao."""
ids = tok(prompt, return_tensors="pt").to(model.device)
out = model.generate(**ids, max_new_tokens=300)
print(tok.decode(out[0], skip_special_tokens=True))
O que isto resolve na prática é a tarefa mais chata do SOC: pegar num alerta cru, perceber o que ele quer dizer, escrever um resumo, sugerir se é falso positivo e propor a ação seguinte. Um analista a fazer isto trezentas vezes por dia fica torrado. O modelo faz a primeira passagem e o humano valida as que interessam. A Deloitte no Japão já leva isto para produção, exatamente para triagem e redução de falsos positivos. E como corre localmente, incluindo em ambientes air-gapped, nenhum log sai do perímetro.
CAI, da Alias Robotics
Do lado mais ofensivo está o CAI (Cybersecurity AI), uma framework open source da Alias Robotics, empresa espanhola, com licença MIT e código no GitHub. A ideia é dar os blocos para montar agentes que fazem trabalho de segurança real: reconnaissance, descoberta de vulnerabilidades, exploração, validação e relatório. A arquitetura é modular e baseada em agentes especializados, suporta mais de trezentos modelos por trás (via LiteLLM, dá para usar GPT, Claude ou um modelo local), e traz guardrails contra prompt injection e execução de comandos perigosos, mais rastreabilidade completa via OpenTelemetry.
Instalar e arrancar é direto. O detalhe importante para quem quer ficar em casa é que dá para correr em modo open source, sem licença da Alias, e apontar a um modelo local através do Ollama, de forma a que nada vá parar a uma API externa:
python3.12 -m venv cai_env
source cai_env/bin/activate
pip install cai-framework
# modo open source, sem necessitar de chave da Alias
export CAI_LICENSE_OFF=1
# apontar a um modelo servido localmente pelo Ollama
export OLLAMA_API_BASE="http://localhost:11434/v1"
# gera um .env com defaults (podes deixar as chaves de cloud vazias)
printf 'OPENAI_API_KEY="sk-xxxx"\nANTHROPIC_API_KEY=""\nOLLAMA=""\nPROMPT_TOOLKIT_NO_CPR=1\n' > .env
cai # abre a CLI interativa; o primeiro arranque pode demorar uns 30 segundos
Já dentro da CLI escolhe-se o modelo com /model e dá-se o objetivo em linguagem natural (“faz reconnaissance ao host 10.0.0.5 e lista serviços expostos”). O agente decide que ferramentas usar (nmap, curl, o que tiver disponível), executa, lê o resultado e decide o passo seguinte.
Não é teoria de slides: o CAI já se portou bem em CTFs da Hack The Box contra humanos e é usado por dezenas de milhares de pessoas. Mas convém uma noção realista do que isto é. É uma ferramenta poderosa para red teams e investigação, que precisa de supervisão e de um ambiente controlado, idealmente o devcontainer baseado em Kali que o projeto fornece, com alvos vulneráveis propositados. Não é algo para apontar a um sistema de produção (ou de terceiros) e ir almoçar. Apontá-la a algo que não nos pertence é crime, e os guardrails não substituem o bom senso.
A camada de plataforma: SIEM, XDR e monitorização
Por baixo dos modelos de IA continua a ser preciso recolher, normalizar e correlacionar dados. É aqui que vivem as plataformas mais maduras.
Wazuh
O Wazuh é provavelmente o ponto de partida mais sensato para a maioria das organizações. É gratuito, open source, e junta XDR e SIEM numa só plataforma, com agentes para endpoints e proteção para cargas em cloud. Nasceu de um fork do velho OSSEC e cresceu muito para lá disso.
Na prática, um agente Wazuh faz file integrity monitoring, análise de logs, deteção de rootkits e avaliação de configurações contra benchmarks. O servidor central correlaciona tudo e os módulos de active response conseguem reagir sozinhos. Vale a pena ver isto com um exemplo concreto, que é também o tipo de regra que se escreve no primeiro dia. Imagina que queremos apanhar um brute force de SSH e bloquear o atacante automaticamente. Primeiro a regra de correlação, em /var/ossec/etc/rules/local_rules.xml:
<group name="local,syslog,sshd,">
<!-- Dispara se a regra base de "falha de autenticação SSH" (5760)
ocorrer 6 vezes em 120 segundos a partir do mesmo IP -->
<rule id="100100" level="10" frequency="6" timeframe="120">
<if_matched_sid>5760</if_matched_sid>
<same_source_ip />
<description>Possível brute force SSH: 6 falhas em 2 minutos do mesmo IP</description>
<mitre>
<id>T1110</id>
</mitre>
</rule>
</group>
Depois, em ossec.conf, dizemos que sempre que essa regra disparar se deve correr a resposta ativa firewall-drop, que bloqueia o IP durante dez minutos:
<active-response>
<command>firewall-drop</command>
<location>local</location>
<rules_id>100100</rules_id>
<timeout>600</timeout>
</active-response>
Reiniciado o serviço, o ciclo fica fechado: deteção, decisão e mitigação sem ninguém à frente do ecrã às três da manhã. A componente analítica do Wazuh acrescenta deteção de anomalias por cima disto, para apanhar o que foge às regras escritas à mão. E como a arquitetura é modular, começa-se com meia dúzia de agentes e cresce-se para milhares sem reescrever nada.
Security Onion
Se a prioridade é a rede, o Security Onion é a escolha clássica. É uma distribuição Linux que junta um arsenal de ferramentas de deteção de intrusões, monitorização de rede e gestão de logs num pacote coerente. Por baixo do capot estão coisas como o Suricata, o Zeek e o Elastic Stack, já integrados e prontos a trabalhar em conjunto. Faz inspeção profunda de pacotes em tempo real, dá aos analistas dashboards para threat hunting proativo (procurar indicadores de compromisso antes de algo rebentar) e apresenta dados densos sem obrigar a ser engenheiro de redes para perceber o que se passa.
UTMStack e Graylog
O UTMStack tenta uma jogada diferente: juntar SIEM, SOAR e compliance numa só plataforma aberta. É atraente para quem não quer gerir cinco ferramentas separadas. Já o Graylog vale a menção como motor de gestão e análise de logs: não é uma suite de segurança completa, mas é excelente a engolir volumes enormes de logs, e a versão de segurança traz correlação e deteção por cima dessa base.
A camada de rede: ver o tráfego em bruto
Vale a pena conhecer estas ferramentas mesmo que venham embutidas noutras suites, porque muitas vezes vamos querer afiná-las à mão.
O Suricata é um motor de IDS, IPS e monitorização de rede que inspeciona tráfego a alta velocidade contra milhares de regras. As regras são legíveis e escrevem-se à mão sem grande cerimónia. Esta, por exemplo, levanta um alerta sempre que vê a assinatura típica de uma tentativa de exploração à boleia do Log4Shell num cabeçalho HTTP:
alert http any any -> $HOME_NET any ( \
msg:"Possivel exploracao Log4Shell (JNDI em header HTTP)"; \
flow:to_server; http.header; content:"jndi:"; nocase; \
classtype:web-application-attack; sid:1000001; rev:1; )
O Suricata escreve tudo o que apanha em eve.json, num formato estruturado que o Wazuh ou o OpenSearch ingerem sem esforço, e é esse o ponto: a rede passa a ser uma fonte de eventos para o resto do stack.
O Zeek (antigo Bro) tem uma filosofia diferente. Em vez de casar assinaturas, transforma o tráfego num registo riquíssimo do que aconteceu na rede, separado por tipo (conn.log, dns.log, http.log, ssl.log, e por aí fora). É ouro para investigação e para alimentar modelos de deteção de anomalias. Uma pergunta simples como “que máquinas mandaram mais dados para fora?”, útil para apanhar exfiltração, responde-se com uma linha:
# Top 10 origens por bytes enviados, a partir do log de conexões do Zeek
cat conn.log | zeek-cut id.orig_h orig_bytes | \
awk '{a[$1]+=$2} END {for (i in a) print a[i], i}' | sort -rn | head
E o Arkime faz captura total de pacotes e indexa-os, para que, quando houver um incidente, seja possível voltar atrás e ver literalmente o que passou no fio. A IA encaixa aqui de forma natural: estas ferramentas geram montanhas de dados estruturados, e dados estruturados são exatamente do que os modelos de deteção de anomalias precisam.
A camada de dados e machine learning
Quase todas as implementações de CAI acabam por assentar num motor de pesquisa e analytics. O Elasticsearch e a sua alternativa totalmente aberta, o OpenSearch (o fork que a comunidade criou quando a licença do Elastic mudou), trazem capacidades de machine learning úteis sem código. O plugin de Anomaly Detection do OpenSearch, por exemplo, aprende o padrão normal de uma métrica e avisa quando algo sai fora. Criar um detetor que vigia picos de autenticações falhadas nos próprios alertas do Wazuh é uma chamada à API:
POST _plugins/_anomaly_detection/detectors
{
"name": "picos-de-login-falhados",
"time_field": "@timestamp",
"indices": ["wazuh-alerts-*"],
"feature_attributes": [{
"feature_name": "falhas_auth",
"aggregation_query": {
"falhas": { "value_count": { "field": "rule.id" } }
}
}],
"detection_interval": { "period": { "interval": 10, "unit": "Minutes" } }
}
A partir daqui o detetor corre sozinho de dez em dez minutos e gera o seu próprio alerta quando o número de falhas dispara face ao histórico, mesmo que nenhuma regra fixa tenha sido violada. É a diferença entre “passaram-se exatamente seis falhas em dois minutos” e “isto não se parece nada com uma terça-feira normal”.
Convém não perder isto de vista: o Elasticsearch e o OpenSearch não são ferramentas de segurança no sentido estrito, são a fundação sobre a qual muita gente constrói a sua. Saber isto evita pagar caro por uma plataforma que, no fundo, é OpenSearch com um logótipo bonito por cima.
A camada de resposta: orquestração e investigação
Detetar é metade do trabalho. A outra metade é responder sem que a equipa morra de exaustão.
O TheHive, em conjunto com o Cortex, dá uma plataforma de gestão de casos onde o Cortex automatiza a análise de observáveis, correndo dezenas de analisadores sobre um hash, um IP ou um domínio de uma só vez. O MISP é o standard de facto para partilhar threat intelligence entre organizações, o que alimenta tudo o resto com indicadores frescos. O Velociraptor é uma ferramenta notável de DFIR e hunting em endpoints, que permite fazer perguntas a milhares de máquinas ao mesmo tempo e obter respostas em minutos. Se acabámos de descobrir um hash malicioso num servidor, uma query VQL como esta diz-nos, em poucos minutos, que outras máquinas da frota têm o mesmo ficheiro:
SELECT Fqdn, FullPath, Hash
FROM hunt(artifact="Windows.Search.FileFinder",
parameters=dict(Hash="e3b0c44298fc1c149afbf4c8996fb924..."))
E o Shuffle é uma plataforma de SOAR aberta para encadear tudo isto em playbooks. Um workflow típico de resposta a um brute force, sem intervenção manual, seria: o alerta do Wazuh entra por webhook, o Shuffle pede ao Cortex e ao MISP para enriquecerem o IP de origem, se o IP for conhecido como malicioso abre automaticamente um caso no TheHive com a severidade certa, manda a ordem de bloqueio ao Wazuh e avisa a equipa no Slack ou por email. O analista acorda com o trabalho já triado, não com um alarme cru.
Para quem trabalha com containers e Kubernetes, o Falco merece destaque: faz deteção de comportamento em runtime, apanhando coisas como uma shell a ser aberta dentro de um container que nunca deveria ter uma.
Um exemplo de ponta a ponta
Tudo isto soa melhor junto do que em peças soltas, por isso aqui fica um incidente a atravessar o stack completo, que é mais ou menos como estas coisas acontecem na vida real.
São três da manhã. Um IP da Roménia começa a martelar o SSH de um servidor de ficheiros. O Suricata vê o padrão de tráfego e levanta a bandeira na rede, enquanto o agente Wazuh no servidor conta as falhas de autenticação. À sexta tentativa em dois minutos, a regra de correlação que escrevemos atrás dispara, e o módulo de active response do Wazuh manda logo a firewall-drop bloquear o IP por dez minutos. A primeira linha de defesa funcionou sem ninguém acordar.
Só que, segundos antes do bloqueio, uma das tentativas acertou na palavra-passe de uma conta de serviço, e há agora um login com sucesso fora de horas. O detetor de anomalias do OpenSearch nota que o número de autenticações naquele host não se parece com nada do histórico recente e gera o seu próprio alerta, independente da regra fixa.
É aqui que a parte de IA ganha o seu lugar. O alerta enriquecido (a sequência de falhas, o login bem-sucedido, a conta, a hora) é passado ao Foundation-Sec-8B com o prompt de triagem lá de cima. O modelo devolve, em segundos, um veredicto estruturado: severidade crítica, provável sucesso de brute force seguido de acesso a uma conta de serviço, técnica MITRE T1110, recomendação de isolar o host e rodar credenciais. Escreve também um resumo em português corrente que o analista lê em dez segundos em vez de reconstruir o puzzle a partir de logs crus.
O Shuffle pega nesse veredicto e executa o playbook: cria o caso no TheHive, pede ao Cortex e ao MISP contexto sobre o IP e a conta, e dispara um hunt no Velociraptor para ver se o atacante já tocou noutras máquinas a partir daquele servidor. Quando o analista de turno chega de manhã, em vez de um alarme solitário tem um caso já documentado, com o ataque resumido, o IP bloqueado, o âmbito do compromisso mapeado pela frota e uma lista clara do que falta validar à mão. O que antes era uma manhã inteira de trabalho ficou reduzido a confirmar e fechar.
Repara que a IA não substituiu ninguém. Tirou o trabalho mecânico do caminho para que a pessoa pudesse julgar o que só uma pessoa julga bem.
Um laboratório que cabe num servidor
Não é preciso um datacenter para começar. Um único servidor com 8 núcleos e 32 GB de RAM aguenta um laboratório completo para aprender e testar. O Wazuh em modo all-in-one (servidor, indexador e dashboard juntos) pede à volta de 4 vCPU e 8 GB. Uma versão quantizada do Foundation-Sec-8B servida por Ollama precisa de mais 8 a 9 GB, e corre em CPU se não houver GPU à mão, mais devagar mas funcional. Sobra folga para um Suricata a ouvir uma interface em modo de espelho e um contentor de CAI para experiências ofensivas contra alvos propositadamente vulneráveis.
Em Docker, isto traduz-se grosso modo em três peças: o stack do Wazuh (que o projeto distribui já com um docker-compose.yml pronto), um contentor de Ollama com o modelo descarregado, e um contentor de CAI a apontar para esse Ollama via OLLAMA_API_BASE. A partir daqui, cada ferramenta nova entra como mais um serviço, e o que se aprende neste laboratório transfere-se quase tal e qual para uma implementação a sério.
Onde isto custa caro (a parte que ninguém gosta de dizer)
Vou ser direto, porque artigos sobre isto costumam pintar um quadro cor de rosa.
Estas ferramentas são gratuitas de licença, não de operação. Montar e manter um stack destes exige gente que saiba de IA, de machine learning e de segurança ao mesmo tempo, e esse perfil é caro e difícil de encontrar. Os recursos computacionais não são triviais: correr análise baseada em LLM sobre logs em volume tem um custo de hardware que muitas empresas hesitam em assumir, sobretudo sem orçamento dedicado. Há manutenção contínua, ou seja, atualizações, monitorização de desempenho e ajuste de regras e de modelos para não se afogarem em falsos positivos. E há a integração, que é onde a maioria dos projetos tropeça: pôr meia dúzia de ferramentas a falar entre si de forma coerente dá muito mais trabalho do que instalar cada uma isoladamente. O exemplo de ponta a ponta lá de cima parece fluido no papel, mas cada seta entre ferramentas foi uma tarde de alguém a afinar formatos de log e a depurar webhooks.
Há ainda um risco específico de meter IA no meio disto: um modelo que erra com confiança. Um LLM que classifica um incidente real como falso positivo é pior do que não ter LLM nenhum. Por isso o humano fica no circuito para o que é crítico, e os vereditos da IA são sugestões, não sentenças.
Quem pesar tudo isto e mesmo assim avançar fá-lo com os olhos abertos, e é assim que estes projetos correm bem.
Para onde isto vai
Algumas tendências que vale a pena ter debaixo de olho. A explicabilidade está a tornar-se obrigatória: já não chega a IA dizer “isto é mau”, é preciso perceber o raciocínio, e não por acaso a própria Cisco lançou uma variante Reasoning do Foundation-Sec. O federated learning promete deixar várias organizações beneficiarem de inteligência coletiva sem partilharem dados sensíveis entre si. O processamento na borda leva a deteção para mais perto do dispositivo, reduzindo latência e melhorando a privacidade. E há a preparação para a era pós-quântica, com a migração para criptografia resistente a computação quântica a começar a sair dos papers e a entrar nos planos reais.
Vale a pena não perder de vista o outro lado. A mesma IA que reforça as defesas também arma os atacantes, e estamos numa corrida onde os dois lados ganham capacidades novas ao mesmo tempo. Frameworks ofensivas como o CAI existem precisamente porque essa realidade não vai desaparecer por a ignorarmos. Mais vale conhecê-la e treinar contra ela.
Por onde começar
Se isto soa bem mas não se sabe por onde pegar, uma abordagem por fases funciona melhor do que tentar tudo de uma vez.
Primeiro, um diagnóstico honesto do que já existe e de onde estão os buracos. Não se instala nada antes de saber o que falta. Depois, um piloto pequeno e controlado: o Wazuh é a sugestão óbvia, porque dá muito valor com pouca fricção e ensina a equipa sem riscos de maior. A seguir, expansão gradual com base no que se aprendeu, em vez de um big bang que ninguém consegue gerir. E, por fim, as capacidades mais sofisticadas: deteção de anomalias no OpenSearch, triagem com um modelo como o Foundation-Sec-8B, e automação de resposta com Shuffle e TheHive. Cada fase só começa quando a anterior estiver estável e a equipa confortável com ela.
Em resumo
A Cybersecurity AI deixou de ser conversa de conferência e passou a ser algo que uma organização de qualquer dimensão consegue montar com ferramentas abertas e a correr em casa. Não por ser fácil, mas porque as peças existem todas, são gratuitas de licença, são auditáveis e não nos prendem a ninguém. E, como espero ter mostrado, não é hand-waving: instala-se, escreve-se, corre-se.
O fator decisivo raramente é a tecnologia. É a capacidade de integrar estas ferramentas nos processos que já existem, de formar a equipa e de manter o esforço ao longo do tempo, em vez de instalar tudo num fim de semana de entusiasmo e abandonar dois meses depois. Quem leva isso a sério tem hoje ao seu dispor um nível de proteção que, há poucos anos, estava reservado a quem tinha orçamento de várias centenas de milhares de euros. Isso, por si só, já muda as regras do jogo para um nivel muito interessante…
Até a próxima semana, e já sabem, se encontrarem algo estranho ou incorrecto sabem onde me encontrar.
Abraço
Nuno