deadair v0.5.1

Salute delle rilevazioni SIEM open-source.
Trova le rilevazioni abilitate che sono cieche perché la loro telemetria è mancante, obsoleta, in ritardo o incompatibile con lo schema.

Esegue in locale · Sola lettura · Nessun agente · Nessun upload di telemetria

Leggi l'approfondimento tecnico · In evidenza su Detection Engineering Weekly

_{Scansione reale di un lab Elastic usa e getta con telemetria volutamente mancante, obsoleta, in ritardo e inutilizzata. Riproducila con make record-scan-lab.}

Perché deadair

Una regola può essere abilitata, pianificata e priva di errori mentre i dati di cui ha bisogno non esistono più. deadair legge l'inventario live delle regole, risolve gli input di ciascuna regola usando la semantica nativa del backend e verifica le sorgenti concrete che vi stanno dietro.

Individua:

• regole i cui selettori di indice, alias o data stream non risolvono a nulla;
• regole le cui sorgenti corrispondenti sono tutte obsolete o vuote;
• regole che girano con campi mancanti o una finestra cieca da ritardo di ingestione;
• telemetria sana che nessuna rilevazione abilitata legge.

deadair attualmente funziona con Elastic Security e OpenSearch Security Analytics.

Avvio rapido

Scarica un binario per macOS, Linux o Windows dalle GitHub Releases, oppure installa con Go:

go install github.com/alephnull-sh/deadair/cmd/deadair@latest

Collega una credenziale SIEM di sola lettura:

deadair setup elastic   # print the least-privilege setup
deadair check           # verify the credential can scan
deadair scan            # assess live rules and telemetry

I codici di uscita sono stabili: 0 indica stato sano, 1 indica segnalazioni e 2 indica che la scansione non è riuscita.

Come funziona

deadair dimostra se i prerequisiti di telemetria osservabili di una rilevazione sono presenti e sani. Non dimostra che la logica della regola sia corretta o che un attacco simulato produca un alert. Per questi livelli, abbinalo alla validazione statica delle regole e ai test end-to-end delle rilevazioni.

Segnalazioni

Ogni verdetto è limitato a ciò che la credenziale configurata può vedere. I report JSON includono le espressioni configurate, le sorgenti risolte, il metodo di risoluzione, lo stato della valutazione, i metadati del backend e le evidenze sulle capacità. Vedi la guida all'uso per esempi pratici e triage.

Connetti un SIEM

Elastic:

export DEADAIR_ES_URL=https://es.example.internal:9200
export DEADAIR_KIBANA_URL=https://kibana.example.internal:5601
export DEADAIR_API_KEY=<read-only-api-key>

deadair check
deadair scan --json-out report.json --html-out report.html

OpenSearch:

export DEADAIR_BACKEND=opensearch
export DEADAIR_OPENSEARCH_URL=https://opensearch.example.internal:9200
export DEADAIR_OPENSEARCH_USERNAME=deadair
export DEADAIR_OPENSEARCH_PASSWORD=<password>

deadair check
deadair scan

Usa i ruoli a privilegi minimi documentati per Elastic o OpenSearch. La suite di integrazione affidabile dimostra anche che i tentativi di scrittura effettuati con queste credenziali vengono respinti.

CI, flotte e monitoraggio

# Gate a candidate rule against live source availability.
deadair scan --rule new-rule.json

# Fail only on new regressions between reports.
deadair diff yesterday.json today.json

# Scan multiple SIEM instances from one process.
deadair scan --fleet fleet.json

# Export cached scan results as Prometheus metrics.
deadair serve --interval 5m

scan --rule isola la regola candidata dal backlog non correlato. diff funziona con report oscurati in modo deterministico. La configurazione delle flotte fa riferimento ai segreti tramite variabili d'ambiente anziché memorizzarne i valori.

_{Un gate per la regola candidata e un diff dei report su uno stack Elastic usa e getta.}

Vedi comportamento del gate CI, distribuzione con flotte e MSSP e gli esempi Prometheus per pattern di produzione.

Backend testati

Il workflow di integrazione attualmente testa queste versioni esatte:

Altre versioni potrebbero funzionare ma non sono coperte dalla matrice CI attuale.

Modello di sicurezza

• Tutto l'accesso ai backend è in sola lettura; i test di integrazione affidabili dimostrano che le credenziali documentate non possono scrivere.
• Report, HTML, file di stato e output delle flotte vengono scritti con permessi 0600 sui sistemi POSIX.
• Le credenziali possono provenire da variabili d'ambiente o file, evitando segreti negli argomenti dei processi.
• --redact sostituisce nomi di tenant, regola, sorgente, pattern e campi con digest stabili.
• L'exporter si vincola al loopback per impostazione predefinita.
• deadair non ha comportamenti di phone-home né telemetria d'uso.

Tratta i report come artefatti SOC sensibili: identificano rilevazioni cieche, nomi delle sorgenti, lacune nello schema e raccolte inutilizzate.

Documentazione

• Guida all'uso — prime scansioni, evidenze dei report, segnalazioni, gate CI, stato e flotte
• Validazione e dogfooding — cosa è dimostrato e cosa necessita ancora di evidenze sul campo
• Architettura — contratto del backend, modello dati, proprietà di sicurezza e limiti
• Best practice — ordine di rollout, contesto degli alert e instradamento
• Guida MSSP — segreti, oscuramento, conservazione, dimensionamento e gestione dei guasti dei tenant
• Rilevazioni che girano ma non vedono — il problema e una simulazione riproducibile

Contributi

Segnalazioni di bug, fixture anonimizzate, casi di correttezza, documentazione e proposte per i backend sono benvenuti. Inizia da CONTRIBUTING.md e usa il template RFC per i backend per il lavoro sugli adapter.

Licenza

Apache-2.0.