deadair v0.5.1

Open-Source-Health für SIEM-Erkennungen.
Finde aktivierte Erkennungen, die blind sind, weil ihre Telemetrie fehlt, veraltet, verspätet oder schema-inkompatibel ist.

Läuft lokal · Nur-Lese · Kein Agent · Kein Telemetrie-Upload

Technischen Artikel lesen · Vorgestellt in Detection Engineering Weekly

_{Echter Scan eines Wegwerf-Elastic-Labors mit absichtlich fehlender, veralteter, verspäteter und ungenutzter Telemetrie. Reproduziere ihn mit make record-scan-lab.}

Warum deadair

Eine Regel kann aktiviert, geplant und fehlerfrei sein, während die Daten, die sie benötigt, fehlen. deadair liest das Live-Regelinventar, löst die Eingaben jeder Regel mit der nativen Semantik des Backends auf und prüft die konkreten Quellen dahinter.

Es erkennt:

• Regeln, deren Index-, Alias- oder Data-Stream-Selektoren zu nichts aufgelöst werden;
• Regeln, deren passende Quellen alle veraltet oder leer sind;
• Regeln, die mit fehlenden Feldern oder einem Blindfenster durch Ingest-Verzögerung laufen;
• gesunde Telemetrie, die von keiner aktivierten Erkennung gelesen wird.

deadair funktioniert derzeit mit Elastic Security und OpenSearch Security Analytics.

Schnellstart

Lade eine Binärdatei für macOS, Linux oder Windows von GitHub Releases herunter oder installiere sie mit Go:

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

Verbinde eine SIEM-Anmeldeinformation mit Nur-Lese-Zugriff:

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

Die Exit-Codes sind stabil: 0 bedeutet gesund, 1 bedeutet, dass Befunde vorliegen, und 2 bedeutet, dass der Scan fehlgeschlagen ist.

So funktioniert es

deadair weist nach, ob die beobachtbaren Telemetrie-Voraussetzungen einer Erkennung vorhanden und gesund sind. Es weist nicht nach, dass die Regellogik korrekt ist oder dass ein simulierter Angriff einen Alert erzeugt. Kombiniere es für diese Ebenen mit statischer Regelvalidierung und End-to-End-Erkennungstests.

Befunde

Jedes Urteil ist auf das beschränkt, was die konfigurierte Anmeldeinformation sehen kann. JSON-Berichte enthalten die konfigurierten Ausdrücke, aufgelöste Quellen, die Auflösungsmethode, den Bewertungsstatus, Backend-Metadaten und Fähigkeitsnachweise. Ausführliche Beispiele und Triage findest du im Nutzungsleitfaden.

Eine SIEM verbinden

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

Verwende die dokumentierten Rollen mit geringsten Rechten für Elastic oder OpenSearch. Die vertrauenswürdige Integrations-Suite belegt außerdem, dass Schreibversuche mit diesen Anmeldedaten abgelehnt werden.

CI, Fleets und Monitoring

# 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 isoliert die Kandidatenregel vom übrigen Backlog. diff funktioniert mit deterministisch geschwärzten Berichten. Die Fleet-Konfiguration referenziert Geheimnisse über Umgebungsvariablen, anstatt geheime Werte zu speichern.

_{Ein Kandidatenregel-Gate und ein Berichts-Diff gegen einen Wegwerf-Elastic-Stack.}

Produktionsmuster findest du unter CI-Gate-Verhalten, Fleet- und MSSP-Bereitstellung und in den Prometheus-Beispielen.

Getestete Backends

Der Integrations-Workflow testet derzeit genau diese Versionen:

Andere Versionen funktionieren möglicherweise, sind aber von der aktuellen CI-Matrix nicht abgedeckt.

Sicherheitsmodell

• Der gesamte Backend-Zugriff ist Nur-Lese; vertrauenswürdige Integrationstests belegen, dass die dokumentierten Anmeldedaten nicht schreiben können.
• Berichte, HTML, Zustandsdateien und Fleet-Ausgaben werden auf POSIX-Systemen mit 0600 geschrieben.
• Anmeldedaten können aus Umgebungsvariablen oder Dateien stammen, sodass Geheimnisse in Prozessargumenten vermieden werden.
• --redact ersetzt Mandanten-, Regel-, Quellen-, Muster- und Feldnamen durch stabile Digests.
• Der Exporter bindet standardmäßig an Loopback.
• deadair hat kein Phone-Home-Verhalten und keine Nutzungstelemetrie.

Behandle Berichte als sensible SOC-Artefakte: Sie identifizieren blinde Erkennungen, Quellnamen, Schema-Lücken und ungenutzte Datensammlung.

Dokumentation

• Nutzungsleitfaden – erste Scans, Berichtsbelege, Befunde, CI-Gates, Zustand und Fleets
• Validierung und Dogfooding – was nachgewiesen ist und was noch Feldnachweise benötigt
• Architektur – Backend-Vertrag, Datenmodell, Sicherheitseigenschaften und Grenzen
• Best Practices – Rollout-Reihenfolge, Alert-Kontext und Routing
• MSSP-Leitfaden – Geheimnisse, Schwärzung, Aufbewahrung, Dimensionierung und Behandlung von Mandantenausfällen
• Erkennungen, die laufen, aber nichts sehen – das Problem und eine reproduzierbare Simulation

Mitwirken

Fehlerberichte, bereinigte Fixtures, Korrektheitsfälle, Dokumentation und Backend-Vorschläge sind willkommen. Beginne mit CONTRIBUTING.md und verwende die Backend-RFC-Vorlage für Adapterarbeiten.

Lizenz

Apache-2.0.