deadair v0.4.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

Phase	Was deadair tut
Inventar	liest aktivierte Detections und die von ihnen deklarierten Inputs
Auflösen	verwendet native Index-Auflösung bei Elastic und OpenSearch; bei Sentinel kombiniert es KQL-Analyse mit Tabellen-, Watchlist-, Saved-Function-, ASIM- und gemappten Cross-Workspace-Nachweisen
Messen	prüft Quellenaktualität und -timing sowie Schema und Speicherung, wo das Backend dies unterstützt
Berichten	gibt Terminal-, JSON-, HTML-, Fleet-Rollups und Prometheus-Metriken mit den Nachweisen hinter jedem Urteil aus

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