deadair v0.8.0

deadair verifica se le detection SIEM abilitate dispongono ancora della telemetria di cui hanno bisogno.
Segnala dati mancanti o obsoleti, ritardi di ingest e discrepanze di schema.

Esecuzione locale · Sola lettura · Nessun agente · Nessun caricamento di telemetria

Leggi l'approfondimento tecnico · In evidenza su Detection Engineering Weekly · In evidenza su tl;dr sec #341

_{Campi mancanti ed eventi in ritardo in un lab Elastic usa e getta. Apri l'immagine per la breve registrazione con controlli di riproduzione, oppure riproducila con make record-scan-lab.}

Perché deadair

Una regola può essere abilitata, pianificata e priva di errori dopo che i dati di cui ha bisogno sono scomparsi. deadair legge l'inventario delle regole attive, risolve gli input di ciascuna regola usando la semantica nativa del backend e verifica le fonti concrete che vi stanno dietro.

Rileva:

• regole i cui selettori di indice, alias o data-stream non risolvono a nulla;
• regole con selettori misti in cui un input dichiarato è scomparso mentre un altro si risolve ancora;
• regole le cui fonti corrispondenti sono tutte obsolete o vuote;
• su Elastic, regole in esecuzione con campi dichiarati mancanti;
• su Elastic e sulle regole Sentinel Scheduled idonee, una finestra cieca di ingest-lag;
• su Sentinel, regole le cui fonti note usano un piano di tabella Basic o Auxiliary incompatibile;
• su Elastic e OpenSearch, telemetria sana che nessuna detection abilitata legge.

deadair supporta Elastic Security, OpenSearch Security Analytics e Microsoft Sentinel.

Avvio rapido

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

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

Stampa la configurazione di sola lettura per il tuo SIEM:

deadair setup elastic      # Elastic Security
deadair setup opensearch   # OpenSearch Security Analytics
deadair setup sentinel     # Microsoft Sentinel

Esegui una configurazione, poi verifica ed esegui la scansione:

deadair check   # verifica che la credenziale possa eseguire la scansione
deadair scan    # valuta regole attive e telemetria

I codici di uscita sono stabili: 0 supera il gate configurato, 1 indica finding soggetti a gate e 2 indica che la scansione è fallita.

Per analizzare una fonte e le detection che la consumano:

deadair scan --json-out report.json --html-out report.html
deadair inspect --source CommonSecurityLog report.json

Usa un nome di fonte dal tuo report. La guida all'analisi copre anche i singoli feed Sentinel, la manutenzione e il monitoraggio del ripristino.

Come funziona

Sentinel segue lo stesso modello regola-a-fonte e aggiunge watchlist letterali, saved function, parser ASIM, workspace mappati e lineage delle tabelle di riepilogo. Mostra anche quando una fetta filtrata di una tabella condivisa è diventata silenziosa o una pipeline di riepilogo è rimasta indietro.

La guida all'uso descrive le regole di evidenza, e il registro di validazione documenta la copertura dei test live.

_{Due feed firewall condividono CommonSecurityLog. Uno si ferma; l'altro continua a riportare. La registrazione mostra le scansioni di fallimento e ripristino salvate. Vedi il registro di validazione per le condizioni del lab.}

deadair verifica se la telemetria di una detection è presente e sana. Non convalida la logica della regola né dimostra che un attacco simulato farà scattare un alert. Per questi compiti usa la validazione statica delle regole e i test end-to-end delle detection.

Finding

I finding su produttore e pipeline di riepilogo influenzano lo stato di uscita quando le loro classi sono selezionate nella policy. Un feed di dispositivo silenzioso viene riportato separatamente dagli altri consumatori della sua tabella condivisa.

Ogni verdetto è limitato a ciò che la credenziale configurata può vedere. I report JSON includono le espressioni configurate, le fonti risolte, il metodo di risoluzione, lo stato di 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

Microsoft Sentinel:

az login --tenant <tenant-id>

export DEADAIR_BACKEND=sentinel
export DEADAIR_AZURE_SUBSCRIPTION_ID=<subscription-id>
export DEADAIR_AZURE_RESOURCE_GROUP=<resource-group>
export DEADAIR_SENTINEL_WORKSPACE=<workspace-resource-name>
# Optional: JSON allowlist for literal workspace() targets.
# export DEADAIR_SENTINEL_REMOTES=/restricted/path/sentinel-remotes.json

deadair check
deadair scan

Prima che deadair valuti il workspace remoto mappato di una regola, quel workspace deve avere Sentinel distribuito. Le mappature nella stessa sottoscrizione possono provare la disponibilità della fonte. Le regole cross-subscription richiedono evidenze a runtime legate all'esatta identità della regola. Vedi i dettagli d'uso di Sentinel per le regole di evidenza, i limiti di workspace e regione e le linee guida sulle prestazioni di Microsoft.

Usa i ruoli di sola lettura documentati per Elastic, OpenSearch o Microsoft Sentinel.

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 una regola o detector candidato nativo del backend da un backlog non correlato. diff funziona con report redatti creati con la stessa chiave detenuta dal chiamante. La configurazione della flotta fa riferimento ai segreti tramite variabili d'ambiente anziché memorizzare i valori dei segreti.

La GitHub Action ufficiale incapsula i gate per candidati a istanza singola per Elastic, OpenSearch e Sentinel. Scrive un riepilogo del job, carica un report JSON redatto e può applicare una policy deadair senza installare una regola. I workflow Sentinel autenticano prima il runner su Azure; la Action non definisce input di credenziali Azure.

Vedi comportamento del gate CI, deployment di flotte e MSSP e gli esempi Prometheus per configurazioni da testare nel tuo ambiente.

Backend testati

L'esecuzione di conformità Sentinel è manuale, non CI pianificata.

Modello di sicurezza

• Tutte le chiamate agli adapter sono di sola lettura. Test attendibili su Elastic e OpenSearch più sonde separate di lab Sentinel verificano che le identità di scansione documentate non possano eseguire scritture rappresentative.
• Report, HTML, file di stato e output della flotta vengono scritti con permessi 0600 sui sistemi POSIX.
• Le credenziali possono provenire da variabili d'ambiente o file, evitando segreti negli argomenti di processo.
• --redact sostituisce identificatori di tenant, regole, fonti, pattern, campi, dipendenze, lineage, provenienza, workspace, watchlist, template e package con pseudonimi HMAC con chiave. Le espressioni di sonda delle dipendenze validate e i loro argomenti KQL non vengono mai serializzati. Un --redact-key-file generato da byte casuali abilita anch'esso la redazione e mantiene i nomi stabili tra esecuzioni separate.
• L'exporter si associa al loopback per impostazione predefinita.
• deadair non ha comportamento di phone-home né telemetria d'uso.

Tratta i report come artefatti SOC sensibili: identificano detection cieche, nomi di fonti, lacune di schema e raccolta inutilizzata.

Documentazione

• Guida all'uso — prime scansioni, evidenze dei report, finding, gate CI, stato e flotte
• Analizzare una lacuna di telemetria — consumatori delle fonti, feed attesi e ripristino
• Stato di validazione — percorsi testati e limiti attuali
• Architettura — contratto del backend, modello dati, proprietà di sicurezza e limiti
• Best practice — ordine di rollout, contesto degli alert e routing
• Guida MSSP — segreti, redazione, pianificazione e gestione dei guasti dei tenant
• Detection che girano ma non vedono — il problema e una simulazione riproducibile

Contribuire

Apri una issue per bug, suggerimenti o riproduzioni sanificate. I maintainer gestiscono le modifiche al codice. Vedi CONTRIBUTING.md per i dettagli.

Licenza

Apache-2.0.