Im Advanced Hunting kann eine KQL-Abfrage mehr Ereignisse finden, als eine Defender-XDR-Custom-Detection als einzelne Alerts meldet. Die Grenze liegt bei 150 Alerts pro Ausführung. Ein erfolgreicher KQL-Test belegt deshalb nur, dass die Abfrage Treffer liefert. Eine Regel gehört erst nach einem Alert-Abgleich in den breiten Einsatz, weil Ausführungsfenster und legitime Treffer das beobachtete Ergebnis verändern.
Voraussetzungen und Grenzen der Preview
Ein Sentinel-Workspace im Defender-Portal bestätigt noch keine Berechtigung zur Bereitstellung von Regeln. Für den beschriebenen Repository-Weg brauchst du die passende Defender-XDR-Lizenzierung und einen mit dem Defender-Portal verbundenen Microsoft-Sentinel-Workspace. Die Rechte für die Zielumgebung werden getrennt geprüft.
Custom Detections in Sentinel-Repositories befinden sich in der Preview. In diesem Bereitstellungsweg werden benutzerdefinierte Ausführungsfrequenzen für Sentinel-Daten und Custom Details nicht unterstützt. Eine Bicep-Eigenschaft kann diese Einschränkungen nicht aufheben.
Eine Sentinel-Analyseregel ist keine Vorlage, die sich unverändert für eine Defender-XDR-Custom-Detection übernehmen lässt. Selbst wenn beide Regelarten im selben Repository liegen, muss die Bicep-Vorlage den jeweils unterstützten Ressourcentyp beschreiben. Vor der Bereitstellung steht deshalb die Prüfung der KQL-Treffer.
KQL-Treffer vor der Bereitstellung prüfen
Ein geplanter PowerShell-Aufruf mit -EncodedCommand kann zu einem regulären Administrationsskript gehören. Für eine Stichprobe werden deshalb Treffer aus mehreren Geräten und Zeitfenstern untersucht. Zu jedem geprüften Ereignis gehört die Begründung, warum der Prozess erwartet oder auffällig war, etwa anhand des aufrufenden Prozesses.
Ereignisse für den Alert-Abgleich erhalten
In DeviceProcessEvents lassen sich Geräteereignisse über Timestamp, DeviceId und ReportId wiederfinden. Diese Spalten bleiben im Abfrageergebnis. Das Beispiel erfasst nur powershell.exe mit ausgeschriebenem Parameter; pwsh.exe und Kurzformen des Schalters sind nicht enthalten.
DeviceProcessEvents
| where FileName =~ "powershell.exe"
| where ProcessCommandLine contains "-EncodedCommand"
| project Timestamp, DeviceId, ReportId, DeviceName,
FileName, ProcessCommandLine, InitiatingProcessFileNameIm Advanced Hunting begrenzt die Zeitauswahl die Stichprobe. Ein festes Testdatum gehört nicht unverändert in die produktive Regelabfrage, weil spätere Ausführungen sonst am vergangenen Zeitraum hängen. Der Anteil legitimer Prozesse in der Stichprobe beschreibt nur diese geprüften Treffer, keine allgemeine Fehlalarmrate.
Treffermengen mit der Alert-Grenze vergleichen
Für den Vergleich zählt die Treffermenge in Zeitfenstern, die zur geplanten Regelausführung passen. Übersteigt sie 150 Ereignisse, kann nicht jeder Treffer als eigener Alert erscheinen. Auch eine kleinere Alert-Zahl beweist für sich genommen keinen Regelfehler: Das Ausführungsfenster und die Verfügbarkeit der Ereignisdaten müssen zum KQL-Vergleich passen.
Ein Gerätefilter oder ein bekanntes Prozessmerkmal kann den Pilot auf eine überprüfbare Treffermenge begrenzen. Die Abfrage, der Prüfzeitraum und die erwarteten Ereignisse werden zusammen festgehalten. Mit dieser Ausgangslage lässt sich die Regeldefinition versionieren.
Bicep-Definition in Git versionieren
Die Versionsgeschichte liegt in Git, nicht in Bicep. Im Repository stehen die Bicep-Vorlage, ihre Parameter und die KQL-Abfrage in einer prüfbaren Fassung. Eine Vorlage für Sentinel-Analyseregeln wird nicht ungeprüft übernommen, weil sie andere Eigenschaften als eine Defender-XDR-Custom-Detection beschreiben kann.
Eine mögliche Aufteilung ist detections/encoded-powershell.bicep für die Regel und detections/pilot.parameters.json für die Pilotwerte. Im Pull Request siehst du, ob sich der Gerätefilter, die Ausführungseinstellungen oder Alert-Metadaten gegenüber der getesteten Fassung ändern. Der fachliche Review der KQL-Abfrage ergänzt die technische Versionsverwaltung, wie sie auch in DevOps Schulungen behandelt wird.
Repository-Synchronisierung und direkte Bereitstellung
Bei einer eingerichteten Sentinel-Repository-Verbindung übernimmt die Synchronisierung die freigegebene Definition. Eine direkte Bereitstellung mit der Azure CLI setzt voraus, dass die Bicep-Vorlage einen in der Zielumgebung unterstützten Azure-Ressourcentyp beschreibt und die nötigen Berechtigungen vorliegen. Die Befehle zeigen den Ablauf für eine solche Vorlage, nicht die vollständige Regeldefinition.
az bicep build --file detections/encoded-powershell.bicep
az deployment group what-if --resource-group <ZIELRESSOURCENGRUPPE> --template-file detections/encoded-powershell.bicep --parameters @detections/pilot.parameters.json
az deployment group create --resource-group <ZIELRESSOURCENGRUPPE> --template-file detections/encoded-powershell.bicep --parameters @detections/pilot.parameters.jsonDie Parameterdatei muss zur Vorlage passen. what-if zeigt die geplante Ressourcenänderung, prüft aber keine späteren Alerts. Nach der Bereitstellung folgt deshalb der fachliche Test im Pilot.
Alerts im begrenzten Pilot abgleichen
Der Gerätefilter in der KQL-Abfrage beschränkt den ersten Lauf auf ausgewählte Testgeräte. Geräte und Zeitfenster stehen vor der Ausführung fest. Falls die Regel Response-Aktionen vorsieht, bleiben sie zunächst deaktiviert, damit ein legitimer Treffer keine automatische Maßnahme auslöst.
Für erwartete Treffer werden Timestamp, DeviceId und ReportId aus dem KQL-Ergebnis festgehalten. Du vergleichst die erzeugten Alerts mit diesen Ereignissen und untersuchst Abweichungen anhand der Regelversion und des Ausführungsfensters. Bleibt ein Alert aus, gehört auch die Grenze von 150 Alerts pro Ausführung zur Prüfung.
- Ein erwarteter Alert lässt sich über Gerät, Ereigniszeit und Prozessdaten einem KQL-Treffer zuordnen
- Ein Alert zu einem legitimen Administrationsprozess wird mit dem auslösenden KQL-Filter dokumentiert
- Fehlende Alerts werden mit Treffermenge und Ausführungsfenster der Regel verglichen
Nach einer Änderung am Filter gelten die Ergebnisse der vorherigen Regelversion nicht mehr als Beleg. Vor einer Ausweitung auf weitere Geräte wird die Treffermenge erneut mit den beobachteten Alerts verglichen. Erst dieser neue Durchlauf liefert Daten für die nächste Freigabe.
Fazit: Regelversion und Alerts gehören zusammen
Der Git-Commit hält fest, welche Regel bereitgestellt wurde; der Pilot zeigt, welche Alerts sie im gewählten Zeitfenster erzeugt hat. Halte für den nächsten Lauf Timestamp, DeviceId und ReportId einiger erwarteter Treffer fest und gleiche sie nach der Ausführung mit den Alerts ab.