Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Wichtig
Benutzerdefinierte Erkennungen sind jetzt die beste Möglichkeit, neue Regeln in Microsoft Sentinel SIEM-Microsoft Defender XDR zu erstellen. Mit benutzerdefinierten Erkennungen können Sie Erfassungskosten reduzieren, unbegrenzte Echtzeiterkennungen erhalten und von der nahtlosen Integration in Defender XDR Daten, Funktionen und Wartungsaktionen mit automatischer Entitätszuordnung profitieren. Weitere Informationen finden Sie in Benutzerdefinierte Erkennungen sind jetzt die einheitliche Oberfläche zum Erstellen von Erkennungen in Microsoft Defender XDR.
Obwohl Microsoft Sentinel Daten aus verbundenen Datenquellen aufnehmen kann, kann die Aufnahmezeit für jede Datenquelle je nach Fall unterschiedlich sein.
In diesem Artikel wird beschrieben, wie sich die Erfassungsverzögerung auf Ihre geplanten Analyseregeln auswirken kann und wie Sie sie beheben können, um diese Lücken zu schließen.
Warum die Verzögerung signifikant ist
Sie könnten zum Beispiel eine benutzerdefinierte Erkennungsregel schreiben, die Abfrage alle ausführen und Daten aus den letzten Feldern nachschlagen, damit die Regel alle fünf Minuten ausgeführt wird und Daten aus den letzten fünf Minuten nachschlägt:
Die Nachschlagedaten aus dem letzten Feld definieren eine Einstellung, die als Rückblickzeitraum bezeichnet wird. Wenn es keine Verzögerung gibt, werden bei dieser Erkennung im Idealfall keine Ereignisse übersehen, wie im folgenden Diagramm dargestellt:
Das Ereignis tritt beim Generieren ein und ist im Lookbackzeitraum enthalten.
Nehmen wir nun an, dass es bei Ihrer Datenquelle zu einer Verzögerung kommt. In diesem Beispiel nehmen wir an, dass das Ereignis zwei Minuten nach der Generierungerfasst wurde. Die Verzögerung beträgt zwei Minuten:
Das Ereignis wird innerhalb des ersten Lookback-Zeitraums generiert, aber nicht bei der ersten Ausführung in Ihren Microsoft Sentinel-Arbeitsbereich aufgenommen. Wenn die geplante Abfrage das nächste Mal ausgeführt wird, erfasst sie das Ereignis, aber der zeitgenerierte Filter entfernt das Ereignis, da es vor mehr als fünf Minuten aufgetreten ist. In diesem Fall löst die Regel keine Warnung aus.
Umgang mit Verzögerungen
Verwenden Sie den folgenden Ansatz, um die Erfassungsverzögerung in geplanten Analyseregeln zu berücksichtigen.
Hinweis
Sie können das Problem entweder mit dem unten beschriebenen Prozess lösen oder die REGELN für die Erkennung nahezu in Echtzeit (NRT) von Microsoft Sentinel implementieren. Weitere Informationen finden Sie unter Schnelles Erkennen von Bedrohungen mit Analyseregeln nahezu in Echtzeit (NRT) in Microsoft Sentinel.
Um das Problem zu beheben, müssen Sie die Verzögerung für Ihren Datentyp kennen. In diesem Beispiel wissen Sie bereits, dass die Verzögerung zwei Minuten beträgt.
Für Ihre eigenen Daten können Sie die Verzögerung mithilfe der Kusto-Funktion ingestion_time() verstehen und den Unterschied zwischen TimeGenerated und der Erfassungszeit berechnen. Weitere Informationen finden Sie unter Berechnen der Erfassungsverzögerung.
Nachdem Sie die Verzögerung ermittelt haben, können Sie das Problem wie folgt beheben:
Verlängern Sie die Rückblickphase: Die Grundintuition sagt Ihnen, dass eine Vergrößerung der Größe der Rückblickperiode hilft. Da Ihr Rückblickzeitraum fünf Minuten und Ihre Verzögerung zwei Minuten beträgt, hilft ihnen das Festlegen des Rückblickzeitraums auf sieben Minuten, um dieses Problem zu beheben. Beispiel: In Ihren Regeleinstellungen:
Das folgende Diagramm zeigt, dass der Look-Pack-Zeitraum nun auch das verpasste Ereignis umfasst:
* Duplikation übernehmen: Nur eine Erhöhung des Look-Back-Zeitraums kann zu Duplizierungen führen, da sich die Lookbackfenster jetzt überlappen. Beispielsweise kann ein anderes Ereignis wie im folgenden Diagramm dargestellt aussehen:
Da der Ereigniswert TimeGenerated in beiden Rückblickperioden gefunden wird, löst das Ereignis zwei Alarme aus. Sie müssen einen Weg finden, um die Duplizierung zu beheben.
Verknüpfen Sie das Ereignis mit einem bestimmten Rückblickzeitraum: Im ersten Beispiel haben Sie Ereignisse verpasst, weil Ihre Daten nicht eingelesen wurden, als die geplante Abfrage ausgeführt wurde. Sie haben den Rückblickzeitraum erweitert, um das Ereignis einzuschließen, wodurch Duplikate entstanden sind. Sie müssen das Ereignis dem Fenster zuordnen, das Sie erweitert haben, um es zu enthalten.
Legen Sie dazu
ingestion_time() > ago(5m)anstelle der ursprünglichen Regellook-back = 5mfest. Diese Einstellung ordnet das Ereignis dem ersten Look-Back-Fenster zu. Zum Beispiel:
Die Zeitbeschränkung für die Einnahme wird nun um die zusätzlichen zwei Minuten gekürzt, die Sie zum Look-back-Zeitraum hinzugefügt haben. Und für das erste Beispiel erfasst der zweite Look-back-zeitraum nun das Ereignis:
Die folgende Beispielabfrage fasst die Lösung zur Behebung von Erfassungsverzögerungen zusammen:
let ingestion_delay = 2min;
let rule_look_back = 5min;
CommonSecurityLog
| where TimeGenerated >= ago(ingestion_delay + rule_look_back)
| where ingestion_time() > ago(rule_look_back)
Weitere Informationen zu den folgenden Elementen im vorherigen Beispiel in der Kusto-Dokumentation finden Sie:
Aufnahmeverzögerung berechnen
Standardmäßig sind die geplanten Alarmregeln von Microsoft Sentinel so konfiguriert, dass sie eine fünfminütige Rückblickperiode haben. Jede Datenquelle kann jedoch ihre eigene, individuelle Aufnahmeverzögerung haben. Wenn Sie mehrere Datentypen verknüpfen, müssen Sie die unterschiedlichen Verzögerungen für jeden Datentyp kennen, um den Lookbackzeitraum richtig konfigurieren zu können.
Der Arbeitsbereichsnutzungsbericht, der in Microsoft Sentinel sofort verfügbar ist, enthält eine Dashboard, die Latenz und Verzögerungen für die verschiedenen Datentypen anzeigt, die in Ihren Arbeitsbereich fließen.
Zum Beispiel:
