big-comfy/deadairTrouve les règles de détection de votre SIEM qui sont aveugles.
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.
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 :
deadair prend en charge Elastic Security, OpenSearch Security Analytics et Microsoft Sentinel.
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.
| Étape | Ce que fait deadair |
|---|---|
| Inventaire | lit les détections activées et les entrées qu'elles déclarent |
| Résolution | utilise la résolution native des index sur Elastic et OpenSearch ; sur Sentinel, combine l'analyse KQL avec les preuves de tables, watchlists, fonctions enregistrées, ASIM et cross-workspace mappées |
| Mesure | vérifie la fraîcheur et la temporalité des sources, ainsi que le schéma et le stockage là où le backend les prend en charge |
| Rapport | émet des sorties terminal, JSON, HTML, des agrégations de flotte et des métriques Prometheus avec les preuves derrière chaque verdict |
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.