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

Ein ASIM-Schema (Advanced Security Information Model) ist eine Reihe von Feldern, die eine Aktivität oder Entität darstellen. Die Verwendung der Felder aus einem normalisierten Schema in einer Abfrage stellt sicher, dass die Abfrage mit jeder normalisierten Quelle funktioniert.

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

Aktivitäts-/Ereignisschemas

Schemaverweise beschreiben die Felder, die jedes Schema umfasst. ASIM definiert derzeit die folgenden Schemas für Ereignisse:

Entitätsschemas

ASIM definiert derzeit die folgenden Schemas für Entitäten:

Informationen zu Entitäten, die Teil anderer ASIM-Schemas sind, finden Sie unter "Ereignisentitäten".

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 Entitätsfeldrichtlinien 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.

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.

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 Ihre Quelle keine Informationen für diesen Wert bereitstellt oder die Daten andernfalls nicht 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.

Ereignisentitä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.

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
• Anwendungsentität

Weitere Informationen zu vollständigen Entitätsschemas finden Sie unter:

• Asset-Entitäts-Schema

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 doppelten Datenspeicher bedeuten 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. Der Arbeitsbereich Log Analytics verfügt über einen begrenzten Satz von Datentypen. Aus diesem Grund verwendet Microsoft Sentinel einen logischen Typ für viele Schemafelder, die Log Analytics nicht erzwingen, aber für die Schemakompatibilität erforderlich ist. Durch logische Feldtypen wird sichergestellt, dass Werte sowie Feldnamen in allen Quellen konsistent sind.

Beispiel von Entitätszuordnung

In diesem Abschnitt werden Windows-Ereignis 4624 als Beispiel verwendet, um zu beschreiben, wie die Ereignisdaten für Microsoft Sentinel normalisiert werden.

Dieses Ereignis umfasst die folgenden Entitäten:

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

Nächste Schritte

Dieser Artikel enthält eine Übersicht über die Normalisierung in Microsoft Sentinel und ASIM.

Weitere Informationen finden Sie unter

• Sehen Sie sich das webinar Deep Dive on Microsoft Sentinel Normalizing Parsers and Normalized Content an, oder überprüfen Sie die slides
• Ü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)