Schemas für das erweiterte Sicherheitsinformationsmodell (Advanced Security Information Model, ASIM)

Ein Schema für das erweiterte Sicherheitsinformationsmodell (Advanced Security Information Model, ASIM) ist ein Satz von Feldern, die eine Aktivität darstellen. Die Verwendung der Felder eines normalisierten Schemas in einer Abfrage stellt sicher, dass die Abfrage mit jeder normalisierten Quelle verwendet werden kann.

Informationen zu Schemas in der ASIM-Architektur finden Sie im ASIM-Architekturdiagramm.

Schemaverweise beschreiben die Felder, die jedes Schema umfasst. In ASIM sind derzeit die folgenden Schemas definiert:

Schemakonzepte

Die folgenden Konzepte helfen Ihnen, die Schemaverweisdokumente zu verstehen und erweitern das Schema auf normalisierte Weise, falls Ihre Daten Informationen enthalten, die das Schema nicht abdeckt.

Feldbenennung

Der Kern jedes Schemas sind die Feldnamen. Feldnamen gehören zu den folgenden Gruppen:

• Felder, die allen Schemas gemeinsam sind.
• Felder, die für ein Schema spezifisch sind.
• Felder, die Entitäten darstellen, z. B. Benutzer, die am Schema teilnehmen. Felder, die Entitäten darstellen, sind in allen Schemas ähnlich.

Wenn Quellen Felder enthalten, die nicht im dokumentierten Schema angegeben sind, werden sie zur Wahrung der Konsistenz normalisiert. Wenn die zusätzlichen Felder eine Entität darstellen, werden sie basierend auf den Leitfäden für Entitätsfelder normalisiert. Andernfalls wird in den Schemas versucht, die Konsistenz über alle Schemas hinweg zu wahren.

Beispielsweise enthalten die Aktivitätsprotokolle von DNS-Servern keine Benutzerinformationen, während die DNS-Aktivitätsprotokolle eines Endpunkts Benutzerinformationen enthalten können, die entsprechend den Leitfäden für die Benutzerentität normalisiert werden können. |

Feldlogiktypen

Jedem Schemafeld ist ein Typ zugeordnet. Der Log Analytics-Arbeitsbereich verfügt über eine begrenzte Anzahl von Datentypen. Daher wird in Microsoft Sentinel für viele Schemafelder ein logischer Typ verwendet, der in Log Analytics nicht erzwungen wird, jedoch für die Schemakompatibilität erforderlich ist. Durch logische Feldtypen wird sichergestellt, dass Werte sowie Feldnamen in allen Quellen konsistent sind.

Weitere Informationen finden Sie unter Logische Typen.

Feldklassen

Felder verfügen möglicherweise über mehrere Klassen, die definieren, wann die Felder von einem Parser implementiert werden sollen:

• Pflichtfelder müssen in jedem Parser angezeigt werden. Wenn eine Quelle keine Informationen für diesen Wert enthält oder die Daten nicht anderweitig hinzugefügt werden können, werden die meisten Inhaltselemente, die auf das normalisierte Schema verweisen, nicht unterstützt.
• Empfohlene Felder sollten bei Bedarf normalisiert werden. Sie sind jedoch möglicherweise nicht in jeder Quelle verfügbar. Jedes Inhaltselement, das auf dieses normalisierte Schema verweist, sollte die Verfügbarkeit berücksichtigen.
• Optionale Felder können, falls verfügbar, normalisiert oder in der ursprünglichen Form verbleiben. Normalerweise werden sie aus Leistungsgründen durch einen sehr einfachen Parser nicht normalisiert.
• Bedingte Felder sind obligatorisch, wenn das folgende Feld aufgefüllt wird. Bedingte Felder werden in der Regel verwendet, um den Wert in einem anderen Feld zu beschreiben. Beispielsweise beschreibt das allgemeine Feld DvcIdType den Integer-Wert im allgemeinen Feld DvcId und ist daher obligatorisch, wenn letzteres ausgefüllt ist.
• Alias ist ein spezieller Typ eines bedingten Felds und ist obligatorisch, wenn das aliasierte Feld aufgefüllt wird.

Allgemeine Felder

Einige Felder sind in allen ASIM-Schemas enthalten. Jedes Schema kann Richtlinien für die Verwendung einiger der allgemeinen Felder im Kontext des jeweiligen Schemas hinzufügen. Beispielsweise können die zulässigen Werte für das Feld EventType und für das Feld EventSchemaVersion je nach Schema unterschiedlich sein.

Entitäten

Ereignisse entwickeln sich im Zusammenhang mit Entitäten wie Benutzern, Hosts, Prozessen oder Dateien. Für jede Entität können mehrere Felder erforderlich sein, um sie zu beschreiben. Beispielsweise kann ein Host einen Namen und eine IP-Adresse aufweisen.

Ein einzelner Datensatz kann mehrere Entitäten desselben Typs enthalten, z. B. einen Quell- und Zielhost.

ASIM definiert, wie Entitäten konsistent beschrieben werden. Mit Entitäten lassen sich die Schemas erweitern.

Während das Netzwerksitzungsschema beispielsweise keine Prozessinformationen enthält, enthalten einige Ereignisquellen Prozessinformationen, die hinzugefügt werden können. Weitere Informationen finden Sie unter Entitäten.

Decknamen

Aliase ermöglichen mehrere Namen für einen angegebenen Wert. In einigen Fällen erwarten verschiedene Benutzer, dass ein Feld unterschiedliche Namen hat. In der DNS-Terminologie wird z. B. ein Feld mit dem Namen DnsQuery erwartet, während es in allgemeineren Anwendungsfällen einen Domänennamen enthält. Der Alias Domäne hilft Benutzer*innen, indem er die Verwendung beider Namen zulässt.

In einigen Fällen kann ein Alias den Wert eines von mehreren Feldern haben, je nachdem, welche Werte im Ereignis verfügbar sind. Beispielsweise werden mit dem Dvc-Alias entweder die Felder DvcFQDN, DvcId, DvcHostname, DvcIpAddr oder Ereignisprodukt benannt. Da ein Alias mehrere Werte haben kann, muss sein Typ eine Zeichenfolge sein, die alle möglichen Aliaswerte aufnimmt. Achten Sie daher beim Zuweisen eines Werts zu einem solchen Alias darauf, den Typ mithilfe der KQL-Funktion tostring in eine Zeichenfolge zu konvertieren.

Native normalisierte Tabellen enthalten keine Aliase, da diese den Datenspeicher verdoppeln würden. Stattdessen werden Aliase über Stubparser hinzugefügt. Um Aliase in Parsern zu implementieren, erstellen Sie mithilfe des extend-Operators eine Kopie des ursprünglichen Werts. |

Logische Typen

Jedem Schemafeld ist ein Typ zugeordnet. Einige Felder verfügen über integrierte Azure Log Analytics-Typen wie string, int, datetime oder dynamic. Andere Felder verfügen über einen logischen Typ, der angibt, wie die Feldwerte normalisiert werden sollen.

Entitäten

Ereignisse entwickeln sich im Zusammenhang mit Entitäten wie Benutzern, Hosts, Prozessen oder Dateien. Die Entitätsdarstellung ermöglicht, dass mehrere Entitäten desselben Typs Teil eines einzelnen Datensatzes sind, und sie unterstützt mehrere Attribute für dieselben Entitäten.

Zur Ermöglichung von Entitätsfunktionen gelten für die Entitätsdarstellung die folgenden Richtlinien:

Weitere Informationen zu bestimmten Entitätstypen finden Sie unter:

• Benutzerentität
• Geräteentität

Beispiel von Entitätszuordnung

In diesem Abschnitt wird am Beispiel des Windows-Ereignisses 4624 beschrieben, wie die Ereignisdaten für Microsoft Sentinel normalisiert werden.

Dieses Ereignis umfasst die folgenden Entitäten:

Basierend auf diesen Entitäten wird das Windows-Ereignis 4624 wie folgt normalisiert (einige Felder sind optional):

Nächste Schritte

Dieser Artikel bietet eine Übersicht über Normalisierung in Microsoft Sentinel und ASIM.

Weitere Informationen finden Sie unter

• Sehen Sie sich das ausführliche Webinar zu normalisierten Parsern und Inhalten in Microsoft Sentinel oder die Folien an.
• Übersicht über das erweiterte Sicherheitsinformationsmodell (Advanced Security Information Model, ASIM)
• Parser für das erweiterte Sicherheitsinformationsmodell (Advanced Security Information Model, ASIM)
• Inhalte für das erweiterte Sicherheitsinformationsmodell (Advanced Security Information Model, ASIM)