FENGARDE

Logs in. Evidence out.
Pipeline de segurança open-source para TI, IA e OT: de logs brutos a um incidente verificado e a um rascunho de notificação NIS2.

Página do projeto e demonstração ao vivo · Início rápido · Console · Arquitetura · Status (SSOT)

Os badges refletem a última execução real em main, não uma promessa. As descobertas restantes do Scorecard são trade-offs aceitos e documentados, não lacunas; consulte SSOT.md §1.

O FENGARDE conecta a telemetria de segurança entre TI, IA e OT para mostrar o que aconteceu, quem ou o que agiu, o que foi afetado, como os eventos se relacionam e quais evidências sustentam a conclusão.

Feito para o Mittelstand industrial europeu: open source, auto-hospedado, Apache-2.0, com um caminho de rascunho de notificação de incidentes NIS2, um gerador determinístico de relatórios em alemão/inglês, RBAC/MFA/log de auditoria/multi-tenancy opcionais para implantações no estilo MSP, um perfil de HA opcional (testado com live-kill, não apenas configurado) e triagem por IA que nunca sai da sua rede.

Os logs são coletados, normalizados para um único schema (OCSF), processados por regras de correlação em uma janela deslizante, agrupados em incidentes com um grafo causal e um pacote de evidências encadeado por hash, e indexados no OpenSearch. Cada serviço é independente e se comunica com os demais apenas por meio de um barramento de mensagens, de modo que qualquer peça pode ser escalada ou substituída sem reescrever as outras.

Por que o FENGARDE

• Nativo em OCSF, não adaptado depois. Cada fonte é normalizada para o mesmo schema aberto desde o primeiro dia, então uma regra cobre todas as fontes que emitem o evento: um login SSH, um login Windows e um login do Active Directory são uma única detecção de força bruta, não três. Sem aprisionamento a formatos de log de fornecedores.
• OT e TI em um único pipeline. OPC UA e Modbus/TCP são normalizados para o mesmo schema que o Active Directory, o Windows e o seu firewall, então o chão de fábrica passa pelo mesmo motor de detecção, console e caminho de relatório da rede do escritório, e não por uma segunda cadeia de ferramentas.
• Triagem por IA que nunca sai da sua rede. Ollama local quando OLLAMA_URL está definido; caso contrário, um stub determinístico rotulado. Os dados de alerta nunca passam por uma API de LLM de terceiros, e o console indica qual motor realmente foi executado. A qualidade dos veredictos é ruim nos dois modelos medidos (qwen2.5:3b 1 de 54 alertas rotulados corretos, qwen2.5:7b 7 de 54, em sua maioria respostas suspicious); consulte eval/llm_triage/RESULTS.md.
• Evidências, não apenas alertas. Os incidentes carregam um grafo causal tipado e um pacote de evidências com cadeia de hash Merkle que a API verifica antes de servi-lo.
• Status honesto. O que está comprovado, o que é alegado e o que é um stub está registrado em SSOT.md e verificado por testes; este README apenas o resume.

OpenSearch, não Elastic: sem asterisco de licença no motor de armazenamento (ADR 003). Vale a pena saber, mas não é um diferencial em relação ao Wazuh (seu indexador também é um fork do OpenSearch).

Experimente

Início rápido

git clone https://github.com/supermhel/fengarde.git && cd fengarde
make preflight   # doctor: checks vm.max_map_count, Docker RAM, free ports
make demo        # docker compose up -- a real SSH brute-force alert appears
                 # in the dashboard within ~30-60s, no manual step
# open http://localhost:8080

Sem Docker à mão? Todo o pipeline de detecção funciona sem infraestrutura:

make e2e         # SSH brute-force -> real alert -> idempotent replay, no Docker/Redis/OpenSearch
bash tools/demo.sh   # same test, narrated (Windows: powershell -File tools\demo.ps1)

O que você está vendo: 10 logins com falha de um único IP em 60 segundos (SSH Failed password ou Windows EventID 4625 — ambos normalizados para o mesmo evento OCSF Authentication) acionam common_bruteforce.yml (threshold: 10, window_seconds: 60, agrupados por IP de origem), e o alerta aparece na lista de alertas do dashboard, idempotente sob reentrega.

Pré-requisitos: Docker Desktop ou Docker Engine + Compose v2, ≥4 GB de RAM alocados ao Docker; Linux, macOS ou Windows via WSL2 (contêineres Linux, scripts POSIX sh). Python 3 apenas se você estiver contribuindo com um parser — não é necessário Docker para isso (veja Contributing).

sudo sysctl -w vm.max_map_count=262144
# persist across reboots:
echo 'vm.max_map_count=262144' | sudo tee /etc/sysctl.d/99-fengarde.conf

Outros alvos: