deadair v0.8.0

deadair prüft, ob aktivierte SIEM-Detections noch über die benötigte Telemetrie verfügen.
Es meldet fehlende oder veraltete Daten, Ingest-Verzögerungen und Schema-Abweichungen.

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

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

_{Fehlende Felder und verzögerte Events in einem wegwerfbaren Elastic-Lab. Öffne das Bild für die kurze Aufzeichnung mit Wiedergabesteuerung oder reproduziere sie mit make record-scan-lab.}

Warum deadair

Eine Regel kann aktiviert, geplant und fehlerfrei sein, nachdem die benötigten Daten verschwunden sind. deadair liest das Live-Regelinventar, löst die Inputs jeder Regel mithilfe 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 auflösen;
• Regeln mit gemischten Selektoren, bei denen ein deklarierter Input verschwunden ist, während ein anderer noch auflöst;
• Regeln, deren passende Quellen alle veraltet oder leer sind;
• bei Elastic Regeln, die mit fehlenden deklarierten Feldern laufen;
• bei Elastic und geeigneten 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 Detection gelesen wird.

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

Schnellstart

Lade ein Binary für macOS, Linux oder Windows von GitHub Releases herunter oder installiere es mit Go:

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

Gib das schreibgeschützte Setup für dein SIEM aus:

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

Führe ein Setup aus und verifiziere dann und scanne:

deadair check   # überprüfen, ob die Anmeldedaten scannen können
deadair scan    # Live-Regeln und Telemetrie bewerten

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

Um eine Quelle und ihre konsumierenden Detections zu untersuchen:

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

Verwende einen Quellennamen aus deinem Bericht. Der Untersuchungsleitfaden behandelt auch einzelne Sentinel-Feeds, Wartung und Wiederherstellungsverfolgung.

Wie es funktioniert

Sentinel folgt demselben Regel-zu-Quelle-Modell und ergänzt literale Watchlists, Saved Functions, ASIM- Parser, gemappte Workspaces und Summary-Table-Lineage. Es zeigt auch, wenn ein gefilterter Ausschnitt einer gemeinsam genutzten Tabelle verstummt ist oder eine Summary-Pipeline zurückgefallen ist.

Der Nutzungsleitfaden beschreibt die Nachweisregeln und der Validierungsdatensatz dokumentiert die Live-Testabdeckung.

_{Zwei Firewall-Feeds teilen sich CommonSecurityLog. Einer stoppt; der andere berichtet weiter. Die Aufzeichnung zeigt die gespeicherten Fehler- und Wiederherstellungs-Scans. Siehe den Validierungsdatensatz für die Lab-Bedingungen.}

deadair prüft, ob die Telemetrie einer Detection vorhanden und gesund ist. Es validiert nicht die Regellogik und beweist nicht, dass ein simulierter Angriff einen Alarm auslöst. Verwende statische Regelvalidierung und End-to-End-Detection-Tests für diese Aufgaben.

Findings

Producer- und Summary-Pipeline-Findings beeinflussen den Exit-Status, wenn ihre Klassen in der Policy ausgewählt sind. Ein stiller Device-Feed wird getrennt von anderen Konsumenten seiner gemeinsam genutzten Tabelle gemeldet.

Jedes Urteil ist auf das beschränkt, was die konfigurierten Anmeldedaten sehen können. JSON-Berichte enthalten die konfigurierten Ausdrücke, aufgelösten Quellen, Auflösungsmethode, Bewertungsstatus, Backend-Metadaten und Capability-Nachweise. 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 for literal workspace() targets.
# export DEADAIR_SENTINEL_REMOTES=/restricted/path/sentinel-remotes.json

deadair check
deadair scan

Bevor deadair den gemappten Remote-Workspace einer Regel bewertet, muss in diesem Workspace Sentinel bereitgestellt sein. Mappings innerhalb desselben Abonnements können die Quellenverfügbarkeit belegen. 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 Performance-Empfehlungen.

Verwende die dokumentierten schreibgeschützten Rollen für Elastic, OpenSearch oder Microsoft Sentinel.

CI, Flotten 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 eine backend-native Kandidatenregel oder einen Detector von unabhängigem Backlog. diff funktioniert mit redigierten Berichten, die mit demselben vom Aufrufer gehaltenen Schlüssel erstellt wurden. Die Fleet-Konfiguration referenziert Secrets über Umgebungsvariablen, anstatt geheime Werte zu speichern.

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

Siehe CI-Gate-Verhalten, Fleet- und MSSP-Deployment und die Prometheus-Beispiele für Konfigurationen, die du in deiner eigenen Umgebung testen kannst.

Getestete Backends

Der Sentinel-Konformitätslauf ist manuell, keine geplante CI.

Sicherheitsmodell

• Alle Adapter-Aufrufe 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 durchführen können.
• Berichte, HTML, State-Dateien und Fleet-Ausgaben werden auf POSIX-Systemen mit 0600 geschrieben.
• Anmeldedaten können aus Umgebungsvariablen oder Dateien stammen, wodurch Secrets in Prozessargumenten vermieden werden.
• --redact ersetzt Tenant-, Regel-, Quellen-, Muster-, Feld-, Abhängigkeits-, Lineage-, Provenienz-, Workspace-, Watchlist-, Template- und Paket-Identifikatoren durch geschlüsselte HMAC-Pseudonyme. Validierte Dependency-Probe-Ausdrücke und ihre KQL-Argumente werden niemals serialisiert. Eine aus zufälligen Bytes generierte --redact-key-file 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 und keine Nutzungstelemetrie.

Behandle Berichte als sensible SOC-Artefakte: Sie identifizieren blinde Detections, Quellennamen, Schema-Lücken und ungenutzte Erfassung.

Dokumentation

• Nutzungsleitfaden — erste Scans, Berichtsnachweise, Findings, CI-Gates, State und Flotten
• Eine Telemetrie-Lücke untersuchen — Quellenkonsumenten, erwartete Feeds und Wiederherstellung
• Validierungsstatus — getestete Pfade und aktuelle Grenzen
• Architektur — Backend-Vertrag, Datenmodell, Sicherheitseigenschaften und Grenzen
• Best Practices — Rollout-Reihenfolge, Alert-Kontext und Routing
• MSSP-Leitfaden — Secrets, Redaktion, Scheduling und Tenant-Fehlerbehandlung
• Detections, die laufen, aber nichts sehen — das Problem und eine reproduzierbare Simulation

Mitwirken

Eröffne ein Issue für Bugs, Vorschläge oder bereinigte Reproduktionen. Maintainer übernehmen Code-Änderungen. Siehe CONTRIBUTING.md für Details.

Lizenz

Apache-2.0.