deadair v0.5.1

Santé de la détection SIEM open-source.
Trouvez les détections activées qui sont aveugles parce que leur télémétrie est manquante, obsolète, tardive ou incompatible avec le schéma.

S'exécute localement · Lecture seule · Aucun agent · Aucun envoi de télémétrie

Lisez l'article technique · Mis en avant dans Detection Engineering Weekly

_{Vraie analyse d'un lab Elastic jetable avec une télémétrie volontairement manquante, obsolète, tardive et inutilisée. Reproduisez-la avec make record-scan-lab.}

Pourquoi deadair

Une règle peut être activée, planifiée et exempte d'erreurs alors que les données dont elle a besoin ont disparu. deadair lit l'inventaire des règles en direct, résout les entrées de chaque règle à l'aide de la sémantique native du backend et vérifie les sources concrètes qui les sous-tendent.

Il détecte :

• les règles dont les sélecteurs d'index, d'alias ou de flux de données ne résolvent rien ;
• les règles dont toutes les sources correspondantes sont obsolètes ou vides ;
• les règles qui s'exécutent avec des champs manquants ou une fenêtre aveugle de latence d'ingestion ;
• la télémétrie saine qu'aucune détection activée ne lit.

deadair fonctionne actuellement avec Elastic Security et OpenSearch Security Analytics.

Démarrage rapide

Téléchargez un binaire pour macOS, Linux ou Windows depuis GitHub Releases, ou installez-le avec Go :

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

Connectez une habilitation SIEM en lecture seule :

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

Les codes de sortie sont stables : 0 indique un système sain, 1 indique des constatations et 2 indique que l'analyse a échoué.

Comment ça fonctionne

deadair prouve si les prérequis de télémétrie observables d'une détection sont présents et sains. Il ne prouve pas que la logique de la règle est correcte ni qu'une attaque simulée produira une alerte. Associez-le à une validation statique des règles et à des tests de détection de bout en bout pour ces aspects.

Constatations

Chaque verdict se limite à ce que l'habilitation configurée peut voir. Les rapports JSON incluent les expressions configurées, les sources résolues, la méthode de résolution, le statut d'évaluation, les métadonnées du backend et les preuves de capacité. Consultez le guide d'utilisation pour des exemples concrets et le triage.

Connecter 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

Utilisez les rôles de privilèges minimaux documentés pour Elastic ou OpenSearch. La suite d'intégration de confiance prouve également que les tentatives d'écriture effectuées avec ces habilitations sont rejetées.

CI, flottes et supervision

# 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 isole la règle candidate du backlog non lié. diff fonctionne avec des rapports expurgés de manière déterministe. La configuration de flotte référence les secrets par des variables d'environnement plutôt que de stocker les valeurs secrètes.

_{Un portail de règle candidate et un diff de rapport contre une pile Elastic jetable.}

Consultez le comportement du portail CI, le déploiement en flotte et MSSP et les exemples Prometheus pour les modèles de production.

Backends testés

Le workflow d'intégration teste actuellement ces versions exactes :

D'autres versions peuvent fonctionner, mais elles ne sont pas couvertes par la matrice CI actuelle.

Modèle de sécurité

• Tout accès au backend est en lecture seule ; les tests d'intégration de confiance prouvent que les habilitations documentées ne peuvent pas écrire.
• Les rapports, le HTML, les fichiers d'état et la sortie de flotte sont écrits en mode 0600 sur les systèmes POSIX.
• Les habilitations peuvent provenir de variables d'environnement ou de fichiers, évitant ainsi les secrets dans les arguments de processus.
• --redact remplace les noms de locataire, de règle, de source, de modèle et de champ par des condensés stables.
• L'exportateur se lie à loopback par défaut.
• deadair n'a aucun comportement de type phone-home ni télémétrie d'utilisation.

Traitez les rapports comme des artefacts SOC sensibles : ils identifient les détections aveugles, les noms de sources, les lacunes de schéma et la collecte inutilisée.

Documentation

• Guide d'utilisation — premières analyses, preuves des rapports, constatations, portails CI, état et flottes
• Validation et dogfooding — ce qui est prouvé et ce qui nécessite encore des preuves de terrain
• Architecture — contrat backend, modèle de données, propriétés de sécurité et limites
• Bonnes pratiques — ordre de déploiement, contexte d'alerte et routage
• Guide MSSP — secrets, expurgation, conservation, dimensionnement et gestion des pannes de locataire
• Détections qui s'exécutent mais ne voient rien — le problème et une simulation reproductible

Contribuer

Les rapports de bogues, les fixtures assainies, les cas de correction, la documentation et les propositions de backend sont les bienvenus. Commencez par CONTRIBUTING.md et utilisez le modèle RFC backend pour le travail d'adaptateur.

Licence

Apache-2.0.