Advanced Security Information Model (ASIM)-Schemas

Ein ASIM-Schema (Advanced Security Information Model) ist ein Satz 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 dazu, wie Schemas in die ASIM-Architektur passen, finden Sie im ASIM-Architekturdiagramm.

Aktivitäts-/Ereignisschemas

Schemaverweise beschreiben die Felder, aus denen die einzelnen Schemas bestehen. 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 für alle 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 schemaübergreifend ähnlich.

Wenn Quellen Über Felder verfügen, die im dokumentierten Schema nicht angezeigt werden, werden sie normalisiert, um die Konsistenz aufrechtzuerhalten. Wenn die zusätzlichen Felder eine Entität darstellen, werden sie basierend auf den Entitätsfeldrichtlinien normalisiert. Andernfalls streben die Schemas die Konsistenz aller Schemas an.

Während beispielsweise DNS-Serveraktivitätsprotokolle keine Benutzerinformationen bereitstellen, können DNS-Aktivitätsprotokolle von einem Endpunkt Benutzerinformationen enthalten, die gemäß den Richtlinien für Benutzerentitäten normalisiert werden können.

Allgemeine Felder

Einige Felder sind für alle ASIM-Schemas gemeinsam. Jedes Schema kann Richtlinien für die Verwendung einiger allgemeiner Felder im Kontext des spezifischen Schemas hinzufügen. Beispielsweise können zulässige Werte für das Feld EventType je nach Schema variieren, ebenso wie der Wert des Felds EventSchemaVersion .

Feldklassen

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

• Pflichtfelder müssen in jedem Parser enthalten sein. Wenn Ihre Quelle keine Informationen für diesen Wert bereitstellt 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 normalisiert werden, sofern verfügbar. 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, sofern verfügbar, normalisiert oder in ihrer ursprünglichen Form belassen werden. In der Regel würde ein minimaler Parser sie aus Leistungsgründen nicht normalisieren.
• Bedingte Felder sind obligatorisch, wenn das Feld, dem sie folgen, 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 Wert int dem allgemeinen Feld DvcId und ist daher obligatorisch, wenn letzteres aufgefüllt wird.
• Alias ist ein spezieller Typ eines bedingten Felds und ist obligatorisch, wenn das Aliasfeld aufgefüllt wird.

Ereignisentitäten

Ereignisse entwickeln sich um Entitäten herum, z. B. Benutzer, Hosts, Prozesse oder Dateien. Jede Entität benötigt möglicherweise mehrere Felder, um sie zu beschreiben. Beispielsweise kann ein Host einen Namen und eine IP-Adresse haben.

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

ASIM definiert, wie Entitäten konsistent beschrieben werden, und Entitäten ermöglichen die Erweiterung der Schemas.

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

Um Entitätsfunktionen zu aktivieren, 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:

• Objektentitätsschema

Aliases

Aliase lassen mehrere Namen für einen angegebenen Wert zu. In einigen Fällen erwarten verschiedene Benutzer, dass ein Feld unterschiedliche Namen hat. In der DNS-Terminologie können Sie beispielsweise ein Feld mit dem Namen DnsQuery erwarten, während es im Allgemeinen einen Domänennamen enthält. Der Alias Domain hilft dem Benutzer, indem er die Verwendung beider Namen zulässt.

In einigen Fällen kann ein Alias den Wert eines von mehreren Feldern aufweisen, je nachdem, welche Werte im Ereignis verfügbar sind. Beispielsweise verwendet der Dvc-Alias entweder die Felder DvcFQDN, DvcId, DvcHostname oder DvcIpAddr oder Ereignisprodukt . Wenn ein Alias mehrere Werte haben kann, muss sein Typ eine Zeichenfolge sein, um alle möglichen Aliaswerte zu berücksichtigen. Stellen Sie daher beim Zuweisen eines Werts zu einem solchen Alias sicher, dass Sie den Typ mithilfe der KQL-Funktion tostring in eine Zeichenfolge konvertieren.

Native normalisierte Tabellen enthalten keine Aliase, da dies imPlizieren von Datenspeichern bedeuten würde. Stattdessen fügen die Stubparser die Aliase hinzu. Um Aliase in Parsern zu implementieren, erstellen Sie mithilfe des Operators eine Kopie des ursprünglichen Werts extend .

Logische Typen

Jedes Schemafeld weist einen Typ auf. Der Log Analytics-Arbeitsbereich verfügt über einen begrenzten Satz von Datentypen. Aus diesem Grund verwendet Microsoft Sentinel einen logischen Typ für viele Schemafelder, den Log Analytics nicht erzwingt, aber für die Schemakompatibilität erforderlich ist. Logische Feldtypen stellen sicher, dass sowohl Werte als auch Feldnamen quellenübergreifend konsistent sind.

Beispiel für entitätszuordnung

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

Dieses Ereignis weist die folgenden Entitäten auf:

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 die Normalisierung in Microsoft Sentinel und ASIM.

Weitere Informationen finden Sie unter:

• Sehen Sie sich das Deep Dive Webinar zu Microsoft Sentinel Normalisierung von Parsern und normalisierten Inhalten an, oder überprüfen Sie die Folien.
• Übersicht über das erweiterte Sicherheitsinformationsmodell (Advanced Security Information Model, ASIM)
• ASIM-Parser (Advanced Security Information Model)
• Inhalt des erweiterten Sicherheitsinformationsmodells (Advanced Security Information Model, ASIM)