Erfassungszeitnormalisierung
Abfragezeitanalyse
Wie in der ASIM-Übersicht erläutert, verwendet Microsoft Sentinel sowohl die Abfragezeit- als auch die Erfassungszeitnormalisierung, um von den Vorteilen beider zu profitieren.
Um die Abfragezeitnormalisierung zu verwenden, verwenden Sie die vereinheitlichende Abfragezeitparser, z. B. _Im_Dns
, in Ihren Abfragen. Die Normalisierung mit der Abfragezeitanalyse hat mehrere Vorteile:
- Beibehalten des ursprünglichen Formats: Für die Abfragezeitnormalisierung müssen die Daten nicht geändert werden, sodass das ursprüngliche, von der Quelle gesendete Datenformat beibehalten wird.
- Vermeiden einer möglichen doppelten Speicherung: Da es sich bei den normalisierten Daten nur um eine Sicht der Originaldaten handelt, ist es nicht erforderlich, die ursprünglichen Daten und die normalisierten Daten zu speichern.
- Einfachere Entwicklung: Da Abfragezeitparser eine Sicht der Daten darstellen und die Daten nicht ändern, sind sie einfach zu entwickeln. Das Entwickeln, Testen und Korrigieren eines Parsers kann für vorhandene Daten erfolgen. Darüber hinaus können Parser korrigiert werden, wenn ein Problem erkannt wird. Die Korrektur wird dann auf vorhandene Daten angewendet.
Erfassungszeitanalyse
ASIM-Abfragezeitparser sind zwar optimiert, die Abfragezeitanalyse kann aber Abfragen verlangsamen, insbesondere bei umfangreichen Datasets.
Die Erfassungszeitanalyse ermöglicht die Transformation von Ereignissen in ein normalisiertes Schema, wenn sie in Microsoft Sentinel erfasst werden, und sowie die Speicherung in einem normalisierten Format. Die Erfassungszeitanalyse ist weniger flexibel, und Parser sind schwieriger zu entwickeln. Da die Daten aber in einem normalisierten Format gespeichert werden, bietet sie eine bessere Leistung.
Normalisierte Daten können in den nativen normalisierten Tabellen von Microsoft Sentinel oder in einer benutzerdefinierten Tabelle gespeichert werden, die ein ASIM-Schema verwendet. Eine benutzerdefinierte Tabelle, die über ein Schema verfügt, das einem ASIM-Schema ähnlich, aber nicht damit identisch ist, bietet auch die Leistungsvorteile der Erfassungszeitnormalisierung.
Derzeit unterstützt ASIM die folgenden nativen normalisierten Tabellen als Ziel für die Erfassungszeitnormalisierung:
- ASimAuditEventLogs für das Überwachungsereignisschema.
- ASimAuthenticationEventLogs für das Authentifizierungsschema.
- ASimDnsActivityLogs für das DNS-Schema
- ASimNetworkSessionLogs für das Network Session-Schema
- ASimWebSessionLogs für das Websitzungsschema.
Der Vorteil nativer normalisierter Tabellen besteht darin, dass sie standardmäßig in den vereinheitlichenden ASIM-Parsern enthalten sind. Benutzerdefinierte normalisierte Tabellen können, wie unter Verwalten von Parsern erläutert, in die vereinheitlichenden Parser eingeschlossen werden.
Kombinieren der Erfassungszeit- und Abfragezeitnormalisierung
Abfragen sollten immer die vereinheitlichenden Abfragezeitparser verwenden, z. B. _Im_Dns
, um sowohl die Abfragezeit- als auch die Erfassungszeitnormalisierung zu nutzen. Native normalisierte Tabellen werden mithilfe eines Stubparsers in die abgefragten Daten eingefügt.
Der Stubparser ist ein Abfragezeitparser, der die normalisierte Tabelle als Eingabe verwendet. Da die normalisierte Tabelle nicht geparst werden muss, ist der Stubparser effizient.
Der Stubparser stellt der aufrufenden Abfrage eine Ansicht zur Verfügung, die die native ASIM-Tabelle wie folgt erweitert:
- Aliase: Um keinen Speicher für wiederholte Werte zu verschwenden, werden Aliase nicht in nativen ASIM-Tabellen gespeichert und zur Abfragezeit von den Stubparsern hinzugefügt.
- Konstante Werte: Aus dem gleichen Grund wie bei Aliasen speichern normalisierte ASIM-Tabellen auch keine konstanten Werte wie EventSchema. Der Stubparser fügt diese Felder hinzu. Die normalisierte ASIM-Tabelle wird von vielen Quellen gemeinsam genutzt, und Erfassungszeitparser können ihre Ausgabeversion ändern. Daher sind Felder wie EventProduct, EventVendor und EventSchemaVersion nicht konstant und werden vom Stubparser nicht hinzugefügt.
- Filterung: Der Stubparser implementiert auch eine Filterung. Während native ASIM-Tabellen keine Filterparser benötigen, um eine bessere Leistung zu erreichen, ist eine Filterung erforderlich, um die Einfügung in den vereinheitlichenden Parser zu unterstützen.
- Aktualisierungen und Korrekturen: Mit einem Stubparser können Probleme schneller behoben werden. Bei einer fehlerhaften Datenerfassung kann es beispielsweise vorkommen, dass während der Erfassung keine IP-Adresse aus dem Nachrichtenfeld extrahiert wird. Die IP-Adresse kann vom Stubparser zur Abfragezeit extrahiert werden.
Erstellen Sie Ihren eigenen Stubparser, um diese Funktionalität zu implementieren, wenn Sie benutzerdefinierte normalisierte Tabellen verwenden, und fügen Sie ihn, wie unter Verwalten von Parsern erläutert, zu den vereinheitlichenden Parsern hinzu. Verwenden Sie den Stubparser für die native Tabelle, z. B. den nativen Stubparser für DNS-Tabellen und die zugehörige Filterentsprechung, als Ausgangspunkt. Verwenden Sie bei einer seminormalisierten Tabelle den Stubparser, um die erforderliche zusätzliche Analyse und Normalisierung durchzuführen.
Weitere Informationen zum Schreiben von Parsern finden Sie im Artikel zum Entwickeln von ASIM-Parsern.
Implementieren der Erfassungszeitnormalisierung
Um Daten bei der Erfassung zu normalisieren, müssen Sie eine Datensammlungsregel verwenden. Die Vorgehensweise zum Implementieren der Datensammlungsregel hängt von der Methode ab, die zum Erfassen der Daten verwendet wird. Weitere Informationen finden Sie im Artikel zum Transformieren oder Anpassen von Daten zur Erfassungszeit in Microsoft Sentinel.
Zentrales Element einer Datensammlungsregel ist eine KQL-Transformationsabfrage. Die in Datensammlungsregeln verwendete KQL-Version unterscheidet sich geringfügig von der Version, die an anderer Stelle in Microsoft Sentinel verwendet wird, um die Anforderungen der Pipelineereignisverarbeitung zu erfüllen. Daher müssen Sie einen Abfragezeitparser entsprechend ändern, um ihn in einer Datensammlungsregel verwenden zu können. Weitere Informationen zu den Unterschieden und zum Konvertieren eines Abfragezeitparsers in einen Erfassungszeitparser finden Sie in den KQL-Einschränkungen für Datensammlungsregeln.
Nächste Schritte
Weitere Informationen finden Sie unter