deadair v0.4.0

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.

Viene eseguito localmente · Sola lettura · Nessun agente · Nessun caricamento di telemetria

Leggi il documento tecnico · In evidenza su Detection Engineering Weekly · In evidenza su tl;dr sec #341

_{Scansione reale di un lab Elastic usa e getta con telemetria deliberatamente mancante, obsoleta, in ritardo e inutilizzata. Apri l'immagine per la breve replica, 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 live delle regole, risolve gli input di ciascuna regola usando la semantica nativa del backend e verifica le sorgenti concrete dietro di essi.

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 risolve ancora;
• regole le cui sorgenti corrispondenti sono tutte obsolete o vuote;
• su Elastic, regole eseguite con campi dichiarati mancanti;
• su Elastic e sulle regole Sentinel Scheduled idonee, una finestra cieca da ritardo di ingestione;
• su Sentinel, regole le cui sorgenti note usano un piano di tabella Basic o Auxiliary incompatibile;
• su Elastic e OpenSearch, telemetria sana che nessuna rilevazione 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 e scansiona:

deadair check   # verifica che la credenziale possa scansionare
deadair scan    # valuta regole e telemetria live

I codici di uscita sono stabili: 0 supera la soglia configurata, 1 indica risultati filtrati dalla soglia e 2 indica che la scansione è fallita.

Come funziona

Sentinel segue lo stesso modello regola-sorgente. Il suo adattatore comprende anche watchlist letterali, funzioni salvate, parser ASIM, workspace mappati e la discendenza delle tabelle di riepilogo. Quando Azure fornisce prove sufficienti, deadair può mostrare che una singola fetta filtrata di una tabella condivisa è diventata silenziosa o che una pipeline di riepilogo è rimasta indietro. Questi due controlli sono consultivi; non modificano la soglia. La guida all'uso descrive le regole di prova, e il record di validazione documenta la copertura dei test live.

_{Scansione live di un lab Sentinel usa e getta seminato con telemetria mancante, obsoleta, in ritardo e incompatibile. Apri l'immagine per la breve replica. Vedi il record di conformità Azure separato per i test di sola lettura e di negazione delle scritture.}

deadair verifica che la telemetria di una rilevazione sia presente e sana. Non valida la logica delle regole né dimostra che un attacco simulato genererà un avviso. Usa la validazione statica delle regole e i test end-to-end delle rilevazioni per questi compiti.

Risultati

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 prove delle 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>
# Opzionale: allowlist JSON per i target workspace() letterali.
# 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 dimostrare la disponibilità della sorgente. Le regole cross-sottoscrizione richiedono prove a runtime legate all'identità esatta della regola. Vedi i dettagli d'uso di Sentinel per le regole di prova, 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, fleet e monitoraggio

# Applica una soglia a una regola candidata rispetto alla disponibilità live della sorgente.
deadair scan --rule new-rule.json

# Fallisci solo su nuove regressioni tra i report.
deadair diff yesterday.json today.json

# Scansiona più istanze SIEM da un singolo processo.
deadair scan --fleet fleet.json

# Esporta i risultati di scansione memorizzati nella cache come metriche Prometheus.
deadair serve --interval 5m

scan --rule isola una regola o un rilevatore candidato nativo del backend dal backlog non correlato. diff funziona con report oscurati creati con la stessa chiave detenuta dal chiamante. La configurazione fleet fa riferimento ai segreti tramite variabili d'ambiente anziché memorizzare valori segreti.

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

Vedi comportamento della soglia CI, distribuzione fleet 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 degli adattatori sono di sola lettura. I test attendibili Elastic e OpenSearch più le sonde separate del lab Sentinel verificano che le identità di scansione documentate non possano eseguire scritture rappresentative.
• Report, HTML, file di stato e output fleet 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 tenant, regola, sorgente, pattern, campo, dipendenza, discendenza, provenienza, workspace, watchlist, template e identificatori di pacchetto con pseudonimi HMAC con chiave. Le espressioni delle sonde di dipendenza validate e i loro argomenti KQL non vengono mai serializzati. Un --redact-key-file generato da byte casuali abilita anche l'oscuramento e mantiene stabili i nomi tra esecuzioni separate.
• L'exporter si lega 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 di sorgenti, lacune di schema e raccolta inutilizzata.

Documentazione

• Guida all'uso — prime scansioni, prove dei report, risultati, soglie CI, stato e fleet
• Stato di validazione — percorsi testati e limiti attuali
• Architettura — contratto del backend, modello dati, proprietà di sicurezza e limiti
• Best practice — ordine di distribuzione, contesto degli avvisi e instradamento
• Guida MSSP — segreti, oscuramento, pianificazione e gestione dei guasti dei tenant
• Rilevazioni che girano ma non vedono — il problema e una simulazione riproducibile

Contribuire

Segnalazioni di bug, fixture sanificate, casi di correttezza, documentazione e proposte di backend sono benvenuti. Inizia con CONTRIBUTING.md e usa il modello RFC del backend per il lavoro sugli adattatori.

Licenza

Apache-2.0.