deadair v0.4.0

Open-Source-SIEM-Erkennungsgesundheit.
Finden Sie aktivierte Erkennungen, die blind sind, weil ihre Telemetrie fehlt, veraltet, verspätet oder schema-inkompatibel ist.

Läuft lokal · Schreibgeschützt · Kein Agent · Kein Telemetrie-Upload

Technischen Bericht lesen · Vorgestellt in Detection Engineering Weekly · Vorgestellt in tl;dr sec #341

_{Echter Scan eines Wegwerf-Elastic-Labors mit absichtlich fehlender, veralteter, verspäteter und ungenutzter Telemetrie. Öffnen Sie das Bild für die kurze Wiedergabe oder reproduzieren Sie es mit make record-scan-lab.}

Warum deadair

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

Es erkennt:

• Regeln, deren Index-, Alias- oder Datenstrom-Selektoren auf nichts auflösen;
• Regeln mit gemischten Selektoren, bei denen eine deklarierte Eingabe verschwunden ist, während eine andere weiterhin auflöst;
• Regeln, deren passende Quellen alle veraltet oder leer sind;
• bei Elastic Regeln, die mit fehlenden deklarierten Feldern laufen;
• bei Elastic und förderfähigen Sentinel-Scheduled-Regeln ein Blindfenster durch Ingest-Verzögerung;
• bei Sentinel Regeln, deren bekannte Quellen einen inkompatiblen Basic- oder Auxiliary-Tabellenplan verwenden;
• bei Elastic und OpenSearch gesunde Telemetrie, die von keiner aktivierten Erkennung gelesen wird.

deadair unterstützt Elastic Security, OpenSearch Security Analytics und Microsoft Sentinel.

Schnellstart

Laden Sie ein Binärpaket für macOS, Linux oder Windows von GitHub Releases herunter oder installieren Sie es mit Go:

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

Drucken Sie das schreibgeschützte Setup für Ihr SIEM:

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

Führen Sie ein Setup aus und verifizieren und scannen Sie dann:

deadair check   # Anmeldedaten verifizieren, dass gescannt werden kann
deadair scan    # Live-Regeln und Telemetrie bewerten

Exit-Codes sind stabil: 0 besteht das konfigurierte Gate, 1 bedeutet Gate-Funde und 2 bedeutet, dass der Scan fehlgeschlagen ist.

So funktioniert es

Sentinel folgt demselben Regel-zu-Quelle-Modell. Sein Adapter versteht auch literale Watchlists, gespeicherte Funktionen, ASIM-Parser, zugeordnete Workspaces und Summary-Tabellen-Abstammung. Wenn Azure genügend Nachweise liefert, kann deadair zeigen, dass ein gefilterter Ausschnitt einer gemeinsamen Tabelle still geworden ist oder dass eine Summary-Pipeline zurückgefallen ist. Diese beiden Prüfungen sind beratend; sie ändern das Gate nicht. Der Nutzungsleitfaden beschreibt die Nachweisregeln, und der Validierungsnachweis dokumentiert die Live-Testabdeckung.

_{Live-Scan eines Wegwerf-Sentinel-Labors, das mit fehlender, veralteter, verspäteter und inkompatibler Telemetrie bestückt ist. Öffnen Sie das Bild für die kurze Wiedergabe. Siehe den separaten Azure-Konformitätsnachweis für die Schreibschutz- und Schreibverweigerungstests.}

deadair prüft, ob die Telemetrie einer Erkennung vorhanden und gesund ist. Es validiert keine Regellogik oder beweist, dass ein simulierter Angriff einen Alert auslöst. Verwenden Sie statische Regelvalidierung und End-to-End-Erkennungstests für diese Aufgaben.

Funde

Jedes Urteil ist auf das beschränkt, was die konfigurierte Anmeldeinformation sehen kann. JSON-Berichte enthalten die konfigurierten Ausdrücke, aufgelösten Quellen, Auflösungsmethode, Bewertungsstatus, Backend-Metadaten und Fähigkeitsnachweise. Siehe den Nutzungsleitfaden für ausgearbeitete Beispiele und Triage.

Ein 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

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 für literale workspace()-Ziele.
# export DEADAIR_SENTINEL_REMOTES=/restricted/path/sentinel-remotes.json

deadair check
deadair scan

Bevor deadair den zugeordneten Remote-Workspace einer Regel bewertet, muss Sentinel in diesem Workspace bereitgestellt sein. Zuordnungen innerhalb desselben Abonnements können die Quellverfügbarkeit nachweisen. Regeln über Abonnements hinweg benötigen Laufzeitnachweise, die an die exakte Regelidentität gebunden sind. Siehe die Sentinel-Nutzungsdetails für die Nachweisregeln, Workspace- und Regionsgrenzen sowie Microsofts Leistungsleitfaden.

Verwenden Sie die dokumentierten Schreibschutz-Rollen für Elastic, OpenSearch oder Microsoft Sentinel.

CI, Fleets und Überwachung

# Eine Kandidatenregel gegen Live-Quellverfügbarkeit gaten.
deadair scan --rule new-rule.json

# Nur bei neuen Regressionen zwischen Berichten fehlschlagen.
deadair diff yesterday.json today.json

# Mehrere SIEM-Instanzen aus einem Prozess scannen.
deadair scan --fleet fleet.json

# Gecachte Scan-Ergebnisse als Prometheus-Metriken exportieren.
deadair serve --interval 5m

scan --rule isoliert eine backend-native Kandidatenregel oder einen Detektor von unzusammenhängendem Rückstand. diff funktioniert mit redigierten Berichten, die mit demselben vom Aufrufer gehaltenen Schlüssel erstellt wurden. Die Fleet-Konfiguration referenziert Geheimnisse über Umgebungsvariablen, anstatt Geheimniswerte zu speichern.

Die offizielle GitHub Action umschließt Single-Instanz-Kandidaten- Gates für Elastic, OpenSearch und Sentinel. Sie schreibt eine Job-Zusammenfassung, lädt einen redigierten JSON- Bericht hoch und kann eine deadair-Richtlinie anwenden, ohne eine Regel zu installieren. Sentinel-Workflows authentifizieren den Runner zuerst bei Azure; die Action definiert keine Azure-Anmeldedaten-Eingaben.

Siehe CI-Gate-Verhalten, Fleet- und MSSP-Bereitstellung und die Prometheus-Beispiele für Konfigurationen, die Sie in Ihrer eigenen Umgebung testen können.

Getestete Backends

Der Sentinel-Konformitätslauf ist manuell, nicht geplantes CI.

Sicherheitsmodell

• Alle Adapteraufrufe sind schreibgeschützt. Vertrauenswürdige Elastic- und OpenSearch-Tests sowie separate Sentinel-Lab- Sonden verifizieren, dass die dokumentierten Scan-Identitäten keine repräsentativen Schreibvorgänge ausführen können.
• Berichte, HTML, Zustandsdateien und Fleet-Ausgaben werden auf POSIX-Systemen mit 0600 geschrieben.
• Anmeldedaten können aus Umgebungsvariablen oder Dateien stammen, wodurch Geheimnisse in Prozessargumenten vermieden werden.
• --redact ersetzt Mandanten-, Regel-, Quell-, Muster-, Feld-, Abhängigkeits-, Abstammungs-, Herkunfts-, Workspace-, Watchlist-, Vorlagen- und Paketkennungen durch schlüsselgebundene HMAC-Pseudonyme. Validierte Abhängigkeitssonden-Ausdrücke und ihre KQL-Argumente werden niemals serialisiert. Ein --redact-key-file, das aus Zufallsbytes generiert wird, aktiviert ebenfalls die Redaktion und hält Namen über separate Läufe hinweg stabil.
• Der Exporter bindet standardmäßig an Loopback.
• deadair hat kein Phone-Home-Verhalten oder Nutzungstelemetrie.

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

Dokumentation

• Nutzungsleitfaden — erste Scans, Berichtsnachweise, Funde, CI-Gates, Zustand und Fleets
• Validierungsstatus — getestete Pfade und aktuelle Grenzen
• Architektur — Backend-Vertrag, Datenmodell, Sicherheitseigenschaften und Grenzen
• Best Practices — Rollout-Reihenfolge, Alert-Kontext und Routing
• MSSP-Leitfaden — Geheimnisse, Redaktion, Planung und Mandantenfehlerbehandlung
• Erkennungen, die laufen, aber nichts sehen können — das Problem und eine reproduzierbare Simulation

Mitwirken

Fehlerberichte, bereinigte Fixtures, Korrektheitsfälle, Dokumentation und Backend-Vorschläge sind willkommen. Beginnen Sie mit CONTRIBUTING.md und verwenden Sie die Backend-RFC-Vorlage für Adapterarbeit.

Lizenz

Apache-2.0.