deadair v0.4.0

Santé des détections SIEM open source.
Identifiez les détections activées qui sont aveugles parce que leur télémétrie est manquante, obsolète, en retard ou incompatible avec le schéma.

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

Lire l'analyse technique · Présenté dans Detection Engineering Weekly · Présenté dans tl;dr sec #341

_{Analyse réelle d'un laboratoire Elastic jetable avec une télémétrie volontairement manquante, obsolète, en retard et inutilisée. Ouvrez l'image pour la courte rediffusion, ou reproduisez-la avec make record-scan-lab.}

Pourquoi deadair

Une règle peut être activée, planifiée et sans erreur après la disparition des données dont elle a besoin. 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 à sélecteurs mixtes où une entrée déclarée a disparu alors qu'une autre se résout encore ;
• les règles dont toutes les sources correspondantes sont obsolètes ou vides ;
• sur Elastic, les règles exécutées avec des champs déclarés manquants ;
• sur Elastic et les règles Sentinel Scheduled éligibles, une fenêtre aveugle de latence d'ingestion ;
• sur Sentinel, les règles dont les sources connues utilisent un plan de table Basic ou Auxiliary incompatible ;
• sur Elastic et OpenSearch, une télémétrie saine qu'aucune détection activée ne lit.

deadair prend en charge Elastic Security, OpenSearch Security Analytics et Microsoft Sentinel.

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

Affichez la configuration en lecture seule pour votre SIEM :

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

Exécutez une configuration, puis vérifiez et analysez :

deadair check   # vérifier que l'identifiant peut analyser
deadair scan    # évaluer les règles en direct et la télémétrie

Les codes de sortie sont stables : 0 passe le seuil configuré, 1 signifie des résultats bloquants, et 2 signifie que l'analyse a échoué.

Comment ça fonctionne

Sentinel suit le même modèle règle-vers-source. Son adaptateur comprend également les watchlists littérales, les fonctions enregistrées, les analyseurs ASIM, les espaces de travail mappés et la lignée des tables de synthèse. Lorsque Azure fournit suffisamment de preuves, deadair peut montrer qu'une tranche filtrée d'une table partagée est devenue silencieuse ou qu'un pipeline de synthèse a pris du retard. Ces deux vérifications sont indicatives ; elles ne modifient pas le seuil. Le guide d'utilisation décrit les règles de preuve, et le registre de validation consigne la couverture des tests en direct.

_{Analyse en direct d'un laboratoire Sentinel jetable alimenté avec une télémétrie manquante, obsolète, en retard et incompatible. Ouvrez l'image pour la courte rediffusion. Consultez le registre de conformité Azure séparé pour les tests de lecture seule et de refus d'écriture.}

deadair vérifie si la télémétrie d'une détection est présente et saine. Il ne valide pas la logique des règles ni ne prouve qu'une attaque simulée déclenchera une alerte. Utilisez la validation statique des règles et les tests de détection de bout en bout pour ces tâches.

Résultats

Chaque verdict est limité à ce que l'identifiant configuré peut voir. Les rapports JSON incluent les expressions configurées, les sources résolues, la méthode de résolution, l'état 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

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>
# Facultatif : liste d'autorisation JSON pour les cibles workspace() littérales.
# export DEADAIR_SENTINEL_REMOTES=/restricted/path/sentinel-remotes.json

deadair check
deadair scan

Avant que deadair n'évalue l'espace de travail distant mappé d'une règle, cet espace de travail doit avoir Sentinel déployé. Les mappages au sein du même abonnement peuvent prouver la disponibilité des sources. Les règles inter-abonnements nécessitent des preuves d'exécution liées à l'identité exacte de la règle. Consultez les détails d'utilisation de Sentinel pour les règles de preuve, les limites d'espace de travail et de région, et les recommandations de performance de Microsoft.

Utilisez les rôles en lecture seule documentés pour Elastic, OpenSearch ou Microsoft Sentinel.

CI, flottes et supervision

# Bloquer une règle candidate en fonction de la disponibilité des sources en direct.
deadair scan --rule new-rule.json

# Échouer uniquement sur les nouvelles régressions entre les rapports.
deadair diff yesterday.json today.json

# Analyser plusieurs instances SIEM depuis un seul processus.
deadair scan --fleet fleet.json

# Exporter les résultats d'analyse en cache comme métriques Prometheus.
deadair serve --interval 5m

scan --rule isole une règle ou un détecteur candidat natif du backend du backlog non lié. diff fonctionne avec des rapports expurgés créés avec la même clé détenue par l'appelant. La configuration de flotte référence les secrets via des variables d'environnement plutôt que de stocker des valeurs secrètes.

L'action GitHub officielle encapsule les seuils candidats à instance unique pour Elastic, OpenSearch et Sentinel. Elle écrit un résumé de tâche, télécharge un rapport JSON expurgé et peut appliquer une politique deadair sans installer de règle. Les workflows Sentinel authentifient d'abord l'exécuteur auprès d'Azure ; l'action ne définit aucune entrée d'identifiant Azure.

Consultez Comportement du seuil CI, déploiement de flotte et MSSP et les exemples Prometheus pour des configurations à tester dans votre propre environnement.

Backends testés

L'exécution de conformité Sentinel est manuelle, pas une CI planifiée.

Modèle de sécurité

• Tous les appels d'adaptateur sont en lecture seule. Les tests Elastic et OpenSearch de confiance ainsi que les sondes de laboratoire Sentinel séparées vérifient que les identités d'analyse documentées ne peuvent pas effectuer d'écritures représentatives.
• Les rapports, HTML, fichiers d'état et sorties de flotte sont écrits en 0600 sur les systèmes POSIX.
• Les identifiants peuvent provenir de variables d'environnement ou de fichiers, évitant les secrets dans les arguments de processus.
• --redact remplace les identifiants de locataire, règle, source, modèle, champ, dépendance, lignée, provenance, espace de travail, watchlist, modèle et package par des pseudonymes HMAC à clé. Les expressions de sonde de dépendance validées et leurs arguments KQL ne sont jamais sérialisés. Une --redact-key-file générée à partir d'octets aléatoires active également l'expurgation et maintient les noms stables entre les exécutions séparées.
• L'exportateur se lie à loopback par défaut.
• deadair n'a aucun comportement de rappel à la maison 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 de rapport, résultats, seuils CI, état et flottes
• Statut de validation — chemins testés et limites actuelles
• 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, planification 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.