deadair v0.8.0

deadair vérifie si les détections SIEM activées disposent toujours de la télémétrie dont elles ont besoin.
Il signale les données manquantes ou obsolètes, les retards d'ingestion et les incohérences de schéma.

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

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

_{Champs manquants et événements retardés dans un lab Elastic jetable. Ouvrez l'image pour la courte capture avec contrôles de lecture, 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 actives, résout les entrées de chaque règle en utilisant 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 data-stream ne résolvent rien ;
• les règles à sélecteurs mixtes où une entrée déclarée a disparu alors qu'une autre résout encore ;
• les règles dont toutes les sources correspondantes sont obsolètes ou vides ;
• sur Elastic, les règles s'exécutant avec des champs déclarés manquants ;
• sur Elastic et les règles Sentinel Scheduled éligibles, une fenêtre aveugle de retard 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 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 lancez un scan :

deadair check   # verify the credential can scan
deadair scan    # assess live rules and telemetry

Les codes de sortie sont stables : 0 passe le seuil configuré, 1 signifie des constats soumis au seuil, et 2 signifie que le scan a échoué.

Pour enquêter sur une source et les détections qui la consomment :

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

Utilisez un nom de source issu de votre rapport. Le guide d'investigation couvre également les flux Sentinel individuels, la maintenance et le suivi de rétablissement.

Comment ça fonctionne

Sentinel suit le même modèle règle-vers-source et ajoute les watchlists littérales, les fonctions enregistrées, les parseurs ASIM, les workspaces mappés et la lignée des tables de résumé. Il montre aussi quand une tranche filtrée d'une table partagée est devenue silencieuse ou qu'un pipeline de résumé a pris du retard.

Le guide d'utilisation décrit les règles de preuve, et le registre de validation consigne la couverture des tests en conditions réelles.

_{Deux flux de pare-feu partagent CommonSecurityLog. L'un s'arrête ; l'autre continue de rapporter. La capture montre les scans d'échec et de rétablissement enregistrés. Voir le registre de validation pour les conditions du lab.}

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

Constats

Les constats sur les producteurs et les pipelines de résumé affectent le statut de sortie lorsque leurs classes sont sélectionnées dans la politique. Un flux d'appareil silencieux est signalé séparément des autres consommateurs de sa table partagée.

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, le statut d'évaluation, les métadonnées du backend et les preuves de capacités. Voir 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>
# Optional: JSON allowlist for literal workspace() targets.
# export DEADAIR_SENTINEL_REMOTES=/restricted/path/sentinel-remotes.json

deadair check
deadair scan

Avant que deadair n'évalue le workspace distant mappé d'une règle, ce workspace doit avoir Sentinel déployé. Les mappings d'un 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. Voir les détails d'utilisation Sentinel pour les règles de preuve, les limites de workspace 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

# 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 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 les valeurs des secrets.

L'Action GitHub officielle encapsule les seuils de candidats mono-instance pour Elastic, OpenSearch et Sentinel. Elle écrit un résumé de job, téléverse un rapport JSON expurgé et peut appliquer une politique deadair sans installer de règle. Les workflows Sentinel authentifient d'abord le runner auprès d'Azure ; l'Action ne définit aucune entrée d'identifiant Azure.

Voir le comportement du seuil CI, le déploiement en 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 de confiance Elastic et OpenSearch, ainsi que des sondes de lab Sentinel distinctes, vérifient que les identités de scan documentées ne peuvent pas effectuer d'écritures représentatives.
• Les rapports, le HTML, les fichiers d'état et la sortie 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 tenant, règle, source, motif, champ, dépendance, lignée, provenance, workspace, watchlist, template 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. Un --redact-key-file généré à partir d'octets aléatoires active aussi la rédaction et garde les noms stables entre des exécutions distinctes.
• L'exportateur se lie à la loopback par défaut.
• deadair n'a aucun comportement de phone-home ni de télémétrie d'usage.

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 — premiers scans, preuves de rapport, constats, seuils CI, état et flottes
• Enquêter sur une lacune de télémétrie — consommateurs de sources, flux attendus et rétablissement
• Statut de validation — chemins testés et limites actuelles
• Architecture — contrat de backend, modèle de données, propriétés de sûreté et limites
• Bonnes pratiques — ordre de déploiement, contexte d'alerte et routage
• Guide MSSP — secrets, rédaction, planification et gestion des défaillances de tenant
• Détections qui s'exécutent mais ne voient rien — le problème et une simulation reproductible

Contribuer

Ouvrez une issue pour les bugs, suggestions ou reproductions assainies. Les mainteneurs gèrent les changements de code. Voir CONTRIBUTING.md pour les détails.

Licence

Apache-2.0.