FENGARDE

Log in. Evidenza in uscita.
Pipeline di sicurezza open source per IT, AI e OT: dai log grezzi a un incidente verificato e a una bozza di notifica NIS2.

Pagina del progetto e demo live · Avvio rapido · Console · Architettura · Stato (SSOT)

I badge riflettono l'ultima esecuzione reale su main, non una promessa. I risultati residui di Scorecard sono compromessi accettati e documentati, non lacune; vedi SSOT.md §1.

FENGARDE collega la telemetria di sicurezza tra IT, AI e OT per mostrare cosa è successo, chi o cosa ha agito, cosa è stato colpito, come gli eventi sono correlati e quali prove supportano la conclusione.

Pensato per il Mittelstand industriale europeo: open source, self-hosted, Apache-2.0, con un percorso di notifica degli incidenti NIS2 in bozza, un generatore di report deterministico in tedesco/inglese, RBAC/MFA/audit-log/multi-tenancy opt-in per distribuzioni in stile MSP, un profilo HA opt-in (testato con live-kill, non solo cablato) e triage AI che non lascia mai la tua rete.

I log vengono raccolti, normalizzati in un unico schema (OCSF), elaborati tramite regole di correlazione su una finestra scorrevole, raggruppati in incidenti con un grafo causale e un pacchetto di evidenze con hash-chain, e indicizzati in OpenSearch. Ogni servizio è indipendente e comunica con gli altri solo tramite un message bus, così ogni componente può essere scalato o sostituito senza riscrivere gli altri.

Perché FENGARDE

• Nativo OCSF, non adattato a posteriori. Ogni sorgente viene normalizzata nello stesso schema aperto fin dal primo giorno, così una regola copre ogni sorgente che emette l'evento: un login SSH, un login Windows e un login Active Directory sono un'unica rilevazione di brute-force, non tre. Nessun lock-in sul formato di log del fornitore.
• OT e IT in un'unica pipeline. OPC UA e Modbus/TCP vengono normalizzati nello stesso schema di Active Directory, Windows e del tuo firewall, così il piano di fabbrica passa attraverso lo stesso motore di rilevamento, console e percorso di report della rete d'ufficio, non una seconda toolchain.
• Triage AI che non lascia mai la tua rete. Ollama locale quando OLLAMA_URL è impostato; altrimenti uno stub deterministico etichettato. I dati degli alert non vengono mai inviati tramite un'API LLM di terze parti, e la console indica quale motore ha effettivamente eseguito. La qualità dei verdetti è scarsa nei due modelli misurati (qwen2.5:3b 1 su 54 alert etichettati corretto, qwen2.5:7b 7 su 54, per lo più risposte suspicious); vedi eval/llm_triage/RESULTS.md.
• Evidenze, non solo alert. Gli incidenti portano un grafo causale tipizzato e un pacchetto di evidenze con hash-chain Merkle che l'API verifica prima di servirlo.
• Stato onesto. Ciò che è dimostrato, ciò che è dichiarato e ciò che è simulato è scritto in SSOT.md e verificato dai test; questo README lo riassume soltanto.

OpenSearch, non Elastic: nessun asterisco di licenza sul motore di archiviazione (ADR 003). Utile da sapere, ma non un elemento distintivo rispetto a Wazuh (anche il suo indexer è un fork di OpenSearch).

Provalo

Avvio rapido

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

Nessun Docker a disposizione? L'intera pipeline di rilevamento funziona senza infrastruttura:

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)

Cosa stai vedendo: 10 login falliti da un singolo IP entro 60 secondi (SSH Failed password o Windows EventID 4625 — entrambi normalizzati nello stesso evento OCSF Authentication) attivano common_bruteforce.yml (threshold: 10, window_seconds: 60, raggruppati per IP di origine), e l'avviso finisce nell'elenco degli avvisi della dashboard, idempotente in caso di riconsegna.

Prerequisiti: Docker Desktop o Docker Engine + Compose v2, ≥4 GB di RAM allocati a Docker; Linux, macOS o Windows tramite WSL2 (container Linux, script POSIX sh). Python 3 solo se stai contribuendo con un parser — non serve Docker per questo (vedi 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

Altri target: