Entwickeln der Parser für das erweiterte Sicherheitsinformationsmodell (Advanced Security Information Model, ASIM) (Öffentliche Vorschau)

  • Artikel

Benutzer des erweiterten Sicherheitsinformationsmodells (Advanced Security Information Model, ASIM) verwenden vereinheitlichende Parser anstelle von Tabellennamen in ihren Abfragen, um Daten in einem normalisierten Format anzeigen und alle für das Schema relevanten Daten in die Abfrage einschließen zu können. Vereinheitlichende Parser verwenden wiederum quellenspezifische Parser, um die spezifischen Details der einzelnen Quellen zu verarbeiten.

Microsoft Sentinel bietet integrierte quellenspezifische Parser für viele Datenquellen. In den folgenden Situationen kann es sinnvoll sein, diese quellenspezifischen Parser zu ändern oder zu entwickeln:

  • Wenn Ihr Gerät Ereignisse meldet, die zu einem ASIM-Schema passen, aber kein quellenspezifischer Parser für Ihr Gerät und das relevante Schema in Microsoft Sentinel verfügbar ist.

  • Wenn quellenspezifische ASIM-Parser für Ihr Gerät verfügbar sind, ihr Gerät jedoch Ereignisse mit einer Methode oder in einem Format sendet, die oder das nicht von den ASIM-Parsern erwartet wird. Beispiel:

    • Ihr Quellgerät kann so konfiguriert sein, dass Ereignisse auf nicht standardmäßige Weise gesendet werden.

    • Ihr Gerät hat möglicherweise eine andere Version als die vom ASIM-Parser unterstützte.

    • Die Ereignisse werden möglicherweise von einem zwischengeschalteten System gesammelt, geändert und weitergeleitet.

Informationen dazu, wie Parser in die ASIM-Architektur passen, finden Sie im ASIM-Architekturdiagramm.

Wichtig

ASIM befindet sich derzeit in der Vorschauphase. In den zusätzlichen Nutzungsbestimmungen für Microsoft Azure-Vorschauen finden Sie weitere rechtliche Bedingungen, die für Azure-Features gelten, die sich in der Beta- oder Vorschauversion befinden oder anderweitig noch nicht zur allgemeinen Verfügbarkeit freigegeben sind.

Entwicklungsprozess für benutzerdefinierte ASIM-Parser

Der folgende Workflow beschreibt auf hoher Ebene das Vorgehen bei der Entwicklung eines benutzerdefinierten quellenspezifischen ASIM-Parsers:

  1. Sammeln von Beispielprotokollen.

  2. Identifizieren Sie die Schemas, die den von der Quelle gesendeten Ereignissen entsprechen. Weitere Informationen finden Sie in der Schemaübersicht.

  3. Ordnen Sie die Quellereignisfelder dem oder den identifizierten Schema(s) zu.

  4. Entwickeln Sie (mindestens) einen ASIM-Parser für Ihre Quelle. Sie müssen für jedes Schema, das für die Quelle relevant ist, einen Parser für das Filtern und einen Parser ohne Parameter entwickeln.

  5. Testen Sie Ihren Parser.

  6. Stellen Sie die Parser in Ihrem Microsoft Sentinel-Arbeitsbereich bereit.

  7. Aktualisieren Sie den relevanten vereinheitlichenden ASIM-Parser, sodass er auf den neuen benutzerdefinierten Parser verweist. Weitere Informationen finden Sie unter Verwalten von ASIM-Parsern.

  8. Möglicherweise möchten Sie auch Ihre Parser zur primären ASIM-Verteilung beitragen. Beigetragene Parser können auch in allen Arbeitsbereichen als integrierte Parser verfügbar gemacht werden.

Dieser Artikel führt Sie durch die Abläufe beim Entwickeln, Testen und Bereitstellen der Parser.

Tipp

Sehen Sie sich auch das ausführliche Webinar zu normalisierenden Parsern und normalisierten Inhalten in Microsoft Sentinel oder die zugehörigen Folien an. Weitere Informationen finden Sie in den nächsten Schritten.

Sammeln von Beispielprotokollen

Um effektive ASIM-Parser zu erstellen, benötigen Sie eine repräsentative Gruppe von Protokollen, die in den meisten Fällen das Einrichten des Quellsystems und die Verbindung mit Microsoft Sentinel erfordern. Wenn Sie nicht über das Quellgerät verfügen, können Sie Cloud-Dienste basierend auf nutzungsbasierter Bezahlung viele Geräte für die Entwicklung und Tests bereitstellen.

Darüber hinaus können die Suche nach den Lieferantendokumentationen und Beispielen für die Protokolle dazu beitragen, die Entwicklung zu beschleunigen und Fehler zu verringern, indem sie eine breite Protokollformatabdeckung gewährleisten.

Eine repräsentative Gruppe von Protokollen sollte Folgendes umfassen:

  • Ereignisse mit unterschiedlichen Ereignisergebnissen.
  • Ereignisse mit unterschiedlichen Antwortaktionen.
  • Verschiedene Formate für Benutzername, Hostname und IDs und andere Felder, die eine Normalisierung des Werts erfordern.

Tipp

Entwickeln Sie neue benutzerdefinierte Parser auf Grundlage eines vorhandenen Parsers für dasselbe Schema. Die Verwendung eines vorhandenen Parsers ist besonders wichtig bei filternden Parsern, um sicherzustellen, dass sie alle für das Schema erforderlichen Parameter akzeptieren.

Planen der Zuordnung

Bevor Sie einen Parser entwickeln, ordnen Sie die Informationen, die im Quellereignis oder -ereignissen verfügbar sind, dem von Ihnen identifizierten Schema zu:

  • Ordnen Sie alle obligatorischen Felder und vorzugsweise auch empfohlene Felder zu.
  • Versuchen Sie, alle Informationen, die von der Quelle verfügbar sind, normalisierten Feldern zuzuordnen. Wenn sie nicht als Teil des ausgewählten Schemas verfügbar sind, sollten Sie die Zuordnung zu Feldern in anderen Schemas in Betracht ziehen.
  • Ordnen Sie Werte für Felder an der Quelle den normalisierten Werten zu, die von ASIM zulässig sind. Der ursprüngliche Wert wird in einem separaten Feld gespeichert, z. B. EventOriginalResultDetails.

Entwickeln von Parsern

Entwickeln Sie sowohl einen Filter- als auch einen parameterlosen Parser für jedes relevante Schema.

Ein benutzerdefinierter Parser ist eine KQL-Abfrage, die auf der Protokolle-Seite von Microsoft Sentinel entwickelt wurde. Die Parserabfrage besteht aus drei Teilen:

Filterung>Analyse>Vorbereitung von Feldern

Filterung

Filterung der relevanten Datensätze

Tabellen in Microsoft Sentinel enthalten oft mehrere Ereignistypen. Zum Beispiel:

  • Die Syslog-Tabelle enthält Daten aus mehreren Quellen.
  • Benutzerdefinierte Tabellen können Informationen aus einer einzelnen Quelle enthalten, die mehrere Ereignistypen umfasst und für verschiedene Schemas geeignet ist.

Daher sollte ein Parser zunächst nur die für das Zielschema relevanten Datensätze herausfiltern.

Die Filterung in KQL erfolgt mit dem Operator where. Beispiel: Das Sysmon-Ereignis 1 meldet die Prozesserstellung und wird daher mit dem Schema ProcessEvent normalisiert. Das Sysmon-Ereignis 1 ist in der Tabelle Event enthalten, sodass Sie folgenden Filter verwenden würden:

Event | where Source == "Microsoft-Windows-Sysmon" and EventID == 1

Wichtig

Ein Parser sollte nicht nach Zeit gefiltert werden. Die Abfrage, die den Parser verwendet, wendet einen Zeitbereich an.

Filtern nach Quelltyp mithilfe einer Watchlist

In einigen Fällen enthält das Ereignis selbst keine Informationen, die das Filtern nach bestimmten Quelltypen ermöglichen würden.

Beispielsweise werden Infoblox-DNS-Ereignisse als Syslog-Nachrichten gesendet und sind schwer von Syslog-Nachrichten zu unterscheiden, die von anderen Quellen gesendet werden. In solchen Fällen basiert der Parser auf einer Liste von Quellen, die die relevanten Ereignisse definiert. Diese Liste wird in der Watchlist Sources_by_SourceType verwaltet.

Verwenden Sie die _ASIM_GetSourceBySourceType Funktion im Parserfilterabschnitt, um die ASimSourceType-Watchlist in Ihren Parsern zu verwenden. Der Infoblox-DNS-Parser enthält z. B. Folgendes im Filterabschnitt:

  | where Computer in (_ASIM_GetSourceBySourceType('InfobloxNIOS'))

So verwenden Sie dieses Beispiel in Ihrem Parser:

  • Ersetzen Sie Computer durch den Namen des Felds, das die Quellinformationen für Ihre Quelle enthält. Sie können dies als Computer für alle Parser beibehalten, die auf Syslog basieren.

  • Ersetzen Sie das InfobloxNIOS-Token durch einen Wert Ihrer Wahl für Ihren Parser. Informieren Sie die Benutzer des Parsers, dass sie die ASimSourceType-Watchlist mithilfe des von Ihnen gewählten Werts aktualisieren müssen, sowie die Liste der Quellen, die Ereignisse dieses Typs senden.

Filtern anhand von Parser-Parametern

Wenn Sie filternde Parser entwickeln, stellen Sie sicher, dass Ihr Parser die Filterparameter für das entsprechende Schema akzeptiert, wie im Referenzartikel für dieses Schema dokumentiert. Die Verwendung eines vorhandenen Parsers als Ausgangspunkt stellt sicher, dass Ihr Parser die richtige Funktionssignatur enthält. In den meisten Fällen ist der tatsächliche Filtercode auch für filternde Parser für dasselbe Schema ähnlich.

Wenn Sie filtern, stellen Sie sicher, dass Sie:

  • Filtern Sie vor dem Parsen anhand der physischen Felder. Wenn die gefilterten Ergebnisse nicht genau genug sind, wiederholen Sie den Test nach dem Parsen, um eine Feinabstimmung Ihrer Ergebnisse vorzunehmen. Weitere Informationen finden Sie unter Optimierung der Filterung.
  • Nicht filtern, wenn der Parameter nicht definiert ist und noch den Standardwert hat.

Die folgenden Beispiele zeigen, wie die Filterung für einen String-Parameter, dessen Standardwert normalerweise '*' ist, und für einen Listenparameter, dessen Standardwert normalerweise eine leere Liste ist, implementiert wird.

srcipaddr=='*' or ClientIP==srcipaddr
array_length(domain_has_any) == 0 or Name has_any (domain_has_any)

Filterungsoptimierung

Beachten Sie die folgenden Empfehlungen für die Filterung, um die Leistungsfähigkeit des Parsers zu gewährleisten:

  • Führen Sie die Filterung immer nach integrierten statt nach geparsten Feldern durch. Obwohl es manchmal einfacher ist, mit geparsten Feldern zu filtern, beeinträchtigt dies die Leistung erheblich.
  • Verwenden Sie Operatoren, die eine optimale Leistung liefern. insbesondere ==, has und startswith. Auch die Verwendung von Operatoren wie contains oder matches regex wirkt sich erheblich auf die Leistung aus.

Die Empfehlungen für die Filterung zur Leistungsoptimierung lassen sich nicht immer einfach umsetzen. Beispielsweise ist die Verwendung von has weniger genau als die von contains. In anderen Fällen ist der Abgleich des integrierten Felds, z. B. SyslogMessage, weniger genau als der Vergleich eines extrahierten Felds, z. B. DvcAction. In diesen Fällen empfiehlt es sich, für ein integriertes Feld dennoch eine Vorabfilterung mithilfe eines leistungsoptimierenden Operators durchzuführen und die Filterung nach der Analyse mit genaueren Bedingungen erneut durchzuführen.

Ein Beispiel dafür finden Sie im folgenden Infoblox DNS Parser-Schnipsel. Der Parser überprüft zunächst, ob das SyslogMessage-Feld den Begriff client enthält (has). Der Begriff kann jedoch an einer anderen Stelle der Nachricht verwendet werden, sodass der Parser nach dem Analysieren des Felds Log_Type erneut überprüft, ob das Wort client tatsächlich der Wert des Felds war.

Syslog | where ProcessName == "named" and SyslogMessage has "client"
…
      | extend Log_Type = tostring(Parser[1]),
      | where Log_Type == "client"

Hinweis

Parser sollten nicht nach der Zeit filtern, da die Abfrage, die den Parser verwendet, bereits nach der Zeit filtert.

Analyse

Nachdem bei der Abfrage die relevanten Datensätze ausgewählt wurden, müssen sie möglicherweise analysiert werden. In der Regel ist das Parsen erforderlich, wenn mehrere Ereignisfelder in einem einzelnen Textfeld übermittelt werden.

Die KQL-Operatoren, mit denen die Analyse durchgeführt wird, sind nachfolgend nach ihrer Leistungsoptimierung sortiert aufgeführt. Der erste Operator bietet die am besten optimierte Leistung, der letzte die am wenigsten optimierte Leistung.

Operator BESCHREIBUNG
split Parsen Sie eine Zeichenfolge aus delimitierten Werten.
parse_csv Analysiert eine Zeichenfolge von Werten, die als CSV-Zeile (mit durch Trennzeichen getrennten Werten) formatiert sind
parse-kv Extrahiert strukturierte Informationen aus einem Zeichenfolgenausdruck und stellt die Informationen in Form eines Schlüssels/Werts dar.
parse Analysiert mehrere Werte aus einer beliebigen Zeichenfolge anhand eines Musters, das ein vereinfachtes Muster mit besserer Leistung oder ein regulärer Ausdruck sein kann
extract_all Analysiert einzelne Werte aus einer beliebigen Zeichenfolge anhand eines regulären Ausdrucks. extract_all hat eine ähnliche Leistung wie parse, wenn bei letzterem ein regulärer Ausdruck verwendet wird.
extract Extrahiert einen einzelnen Wert aus einer beliebigen Zeichenfolge anhand eines regulären Ausdrucks.

Die Verwendung von extract ermöglicht eine bessere Leistung als die von parse oder extract_all, wenn ein einzelner Wert abgefragt werden soll. Die Verwendung mehrerer Aktivierungen von extract für dieselbe Quellenzeichenfolge ist jedoch deutlich weniger effizient als eine einzige Aktivierung von parse oder extract_all und sollte daher vermieden werden.
parse_json Analysiert die Werte in einer Zeichenfolge, die als JSON-Code formatiert ist. Wenn nur wenige Werte aus dem JSON-Code benötigt werden, bietet die Verwendung von parse, extract oder extract_all eine bessere Leistung.
parse_xml Analysiert die Werte in einer Zeichenfolge, die als XML-Code formatiert ist. Wenn nur wenige Werte aus dem XML-Code benötigt werden, bietet die Verwendung von parse, extract oder extract_all eine bessere Leistung.

Normalisierung

Zuordnen von Feldnamen

Die einfachste Form der Normalisierung ist das Umbenennen eines ursprünglichen Felds in seinen normalisierten Namen. Verwenden Sie dazu den Operator project-rename. Durch die Verwendung der Funktion zur Projektumbenennung wird sichergestellt, dass das Feld weiterhin als physisches Feld verwaltet wird und dass die Handhabung des Felds effizienter ist. Beispiel:

 | project-rename
    ActorUserId = InitiatingProcessAccountSid,
    ActorUserAadId = InitiatingProcessAccountObjectId,
    ActorUserUpn = InitiatingProcessAccountUpn,

Normalisieren des Formats und des Typs von Feldern

In vielen Fällen muss der extrahierte Originalwert normalisiert werden. In ASIM verwendet eine MAC-Adresse beispielsweise Doppelpunkte als Trennzeichen, während die Quelle möglicherweise eine durch Bindestriche getrennte MAC-Adresse senden kann. Der primäre Operator für die Transformation von Werten ist extend in Verbindung mit einer umfassenden Sammlung von KQL-Zeichenfolgen sowie numerischen und Datumsfunktionen.

Außerdem ist es für das Funktionieren des Parsers von entscheidender Bedeutung, dass Sie sicherstellen, dass die Ausgabefelder des Parsers dem Typ entsprechen, der in dem Schema definiert wurde. Beispielsweise müssen Sie möglicherweise eine Zeichenfolge, die Datum und Uhrzeit darstellt, in ein datetime-Feld konvertieren. In diesen Fällen sind Funktionen wie todatetime und tohex hilfreich.

Beispielsweise kann die ursprüngliche eindeutige Ereignis-ID als ganze Zahl gesendet werden, aber ASIM verlangt, dass der Wert eine Zeichenfolge ist, damit eine umfassende Kompatibilität zwischen den Datenquellen sichergestellt ist. Verwenden Sie daher beim Zuweisen des Quellfelds extend und tostring anstelle von project-rename:

  | extend EventOriginalUid = tostring(ReportId),

Abgeleitete Felder und Werte

Der Wert des Quellfelds muss nach der Extraktion möglicherweise der für das Zielschemafeld angegebenen Gruppe von Werten zugeordnet werden. Die Funktionen iff, case und lookup können hilfreich sein, wenn Sie den Zielwerten verfügbare Daten zuordnen.

Beispielsweise weist der Microsoft DNS-Parser das Feld EventResult basierend auf der Ereignis-ID und dem Antwortcode mithilfe einer iff-Anweisung wie folgt zu:

   extend EventResult = iff(EventId==257 and ResponseCode==0 ,'Success','Failure')

Um mehrere Werte zuzuordnen, definieren Sie die Zuordnung mithilfe des datatable-Operators und verwenden Sie lookup, um die Zuordnung durchzuführen. Einige Quellen melden beispielsweise numerische DNS-Antwortcodes und das Netzwerkprotokoll, während das Schema die häufigere Darstellung von Textbeschriftungen für beides zwingend vorgibt. Im folgenden Beispiel wird veranschaulicht, wie sie die erforderlichen Werte mithilfe von datatable und lookup ableiten:

   let NetworkProtocolLookup = datatable(Proto:real, NetworkProtocol:string)[
        6, 'TCP',
        17, 'UDP'
   ];
    let DnsResponseCodeLookup=datatable(DnsResponseCode:int,DnsResponseCodeName:string)[
      0,'NOERROR',
      1,'FORMERR',
      2,'SERVFAIL',
      3,'NXDOMAIN',
      ...
   ];
   ...
   | lookup DnsResponseCodeLookup on DnsResponseCode
   | lookup NetworkProtocolLookup on Proto

Beachten Sie, dass das Lookup nützlich und effizient ist, wenn die Zuordnung nur zwei mögliche Werte aufweist.

Wenn die Zuordnungsbedingungen komplexer sind, kombinieren Sie iff, case und lookup miteinander. Im unten stehenden Beispiel wird veranschaulicht, wie Sie lookup und case kombinieren. Im Beispiel lookup oben wird ein leerer Wert im Feld DnsResponseCodeName zurückgegeben, wenn der Lookup-Wert nicht gefunden wird. Das Beispiel case erweitert es, indem es das Ergebnis des Vorgangs lookup verwendet, wenn es verfügbar ist, und ansonsten zusätzliche Bedingungen angibt.

   | extend DnsResponseCodeName = 
      case (
        DnsResponseCodeName != "", DnsResponseCodeName,
        DnsResponseCode between (3841 .. 4095), 'Reserved for Private Use',
        'Unassigned'
      )

Microsoft Sentinel bietet praktische Funktionen für allgemeine Nachschlagewerte. Beispielsweise kann der oben genannte DnsResponseCodeName-Nachschlagevorgang mithilfe einer der folgenden Funktionen implementiert werden:


| extend DnsResponseCodeName = _ASIM_LookupDnsResponseCode(DnsResponseCode)

| invoke _ASIM_ResolveDnsResponseCode('DnsResponseCode')

Die erste Option akzeptiert als Parameter den nachzuschlagenden Wert und ermöglicht es Ihnen, das Ausgabefeld auszuwählen und ist daher als allgemeine Nachschlagefunktion hilfreich. Die zweite Option ist stärker auf Parser ausgerichtet, verwendet als Eingabe den Namen des Quellfelds und aktualisiert das erforderliche ASIM-Feld, in diesem Fall DnsResponseCodeName.

Eine vollständige Liste der ASIM-Hilfefunktionen finden Sie unter ASIM-Funktionen.

Anreicherungsfelder

Neben den in der Quelle verfügbaren Feldern enthält das sich ergebende ASIM-Ereignis Anreicherungsfelder, die der Parser generieren soll. In vielen Fällen können die Parser den Feldern beispielsweise einen Konstantenwert zuweisen, zum Beispiel:

  | extend                  
     EventCount = int(1),
     EventProduct = 'M365 Defender for Endpoint',
     EventVendor = 'Microsoft',
     EventSchemaVersion = '0.1.0',
     EventSchema = 'ProcessEvent'

Ein weiterer Typ von Anreicherungsfeldern, die von Ihren Parsern festgelegt werden sollen, sind Typfelder, die den Typ des in einem verwandten Feld gespeicherten Werts bestimmen. Beispielsweise bestimmt das Feld SrcUsernameType den im Feld SrcUsername gespeicherten Werttyp. Weitere Informationen zu Typfeldern finden Sie in der -Entitätsbeschreibung.

In den meisten Fällen wird den Typen auch ein konstanter Wert zugewiesen. In einigen Fällen muss der Typ jedoch basierend auf dem tatsächlichen Wert bestimmt werden, wie z. B.:

   DomainType = iif (array_length(SplitHostname) > 1, 'FQDN', '')

Microsoft Sentinel bietet nützliche Funktionen für die Handhabung der Anreicherung. Verwenden Sie beispielsweise die folgende Funktion, um die Felder SrcHostname, SrcDomain, SrcDomainType und SrcFQDN basierend auf dem Wert im Feld Computer automatisch zuzuweisen.

  | invoke _ASIM_ResolveSrcFQDN('Computer')

Durch diese Funktion werden die Felder wie folgt festgelegt:

Computerfeld Ausgabefelder
server1 SrcHostname: server1
SrcDomain, SrcDomainType, SrcFQDN alle leer
server1.microsoft.com SrcHostname: server1
SrcDomain: microsoft.com
SrcDomainType: FQDN
SrcFQDN:server1.microsoft.com

Die Funktionen _ASIM_ResolveDstFQDN und _ASIM_ResolveDvcFQDN führen eine ähnliche Aufgabe aus, durch die in die zugehörigen Felder Dst und Dvc Werte eingegeben werden. Eine vollständige Liste der ASIM-Hilfefunktionen finden Sie unter ASIM-Funktionen.

Auswählen von Feldern im Resultset

Der Parser kann optional Felder im Resultset auswählen. Durch das Entfernen nicht benötigter Felder kann die Leistung verbessert und für Klarheit gesorgt werden, da es nicht mehr zu Verwirrungen zwischen normalisierten Feldern und verbleibenden Quellfeldern kommt.

Zum Auswählen von Feldern in Ihrem Resultset werden die folgenden KQL-Operatoren verwendet:

Operator BESCHREIBUNG Verwendung in einem Parser
project-away Entfernt Felder. Verwenden Sie project-away für spezifische Felder, die aus dem Resultset entfernt werden sollen. Es wird empfohlen, die ursprünglichen Felder, die nicht aus dem Resultset normalisiert sind, zu entfernen, es sei denn, sie führen zu Verwirrung oder sind sehr groß und haben möglicherweise Auswirkungen auf die Leistung.
project Wählt Felder aus, die vorher existierten oder als Teil der Anweisung erstellt wurden und entfernt alle anderen Felder. Wird nicht für die Verwendung in einem Parser empfohlen, da der Parser keine anderen nicht normalisierten Felder entfernen soll.

Wenn Sie spezifische Felder entfernen möchten, z. B. temporäre bei der Analyse verwendete Werte, verwenden Sie project-away, um sie aus den Ergebnissen zu entfernen.

Verwenden Sie beispielsweise beim Analysieren einer benutzerdefinierten Protokolltabelle Folgendes, um die verbleibenden ursprünglichen Felder, die noch über einen Typdeskriptor verfügen, zu entfernen:

    | project-away
        *_d, *_s, *_b, *_g

Verarbeiten von Analysevarianten

Wichtig

Die verschiedenen Varianten stellen verschiedene Ereignistypen dar, die in der Regel unterschiedlichen Schemas zugeordnet sind und separate Parser entwickeln

In vielen Fällen enthalten Ereignisse in einem Ereignisstream Varianten, die eine andere Analyselogik erfordern. Um verschiedene Varianten in einem einzelnen Parser zu analysieren, verwenden Sie entweder bedingte Anweisungen wie iff und case, oder verwenden Sie eine Vereinigungsstruktur.

Um union zu verwenden, um mehrere Varianten zu behandeln, erstellen Sie eine separate Funktion für jede Variante und verwenden Sie die Vereinigungsanweisung, um die Ergebnisse zu kombinieren:

let AzureFirewallNetworkRuleLogs = AzureDiagnostics
    | where Category == "AzureFirewallNetworkRule"
    | where isnotempty(msg_s);
let parseLogs = AzureFirewallNetworkRuleLogs
    | where msg_s has_any("TCP", "UDP")
    | parse-where
        msg_s with           networkProtocol:string 
        " request from "     srcIpAddr:string
        ":"                  srcPortNumber:int
    …
    | project-away msg_s;
let parseLogsWithUrls = AzureFirewallNetworkRuleLogs
    | where msg_s has_all ("Url:","ThreatIntel:")
    | parse-where
        msg_s with           networkProtocol:string 
        " request from "     srcIpAddr:string
        " to "               dstIpAddr:string
    …
union parseLogs,  parseLogsWithUrls…

Um doppelte Ereignisse und eine übermäßige Verarbeitung zu vermeiden, stellen Sie sicher, dass jede Funktion zu Beginn nur die Ereignisse filtert, die sie analysieren soll, indem Sie systemeigene Felder verwenden. Bei Bedarf können Sie auch vor der Vereinigung in jeder Verzweigung einen project-away verwenden.

Bereitstellen von Parsern

Sie können Parser manuell bereitstellen, indem Sie sie auf die Azure Monitor-Seite „Protokolle“ kopieren und die Abfrage als Funktion speichern. Diese Methode empfiehlt sich bei Tests. Weitere Informationen finden Sie unter Erstellen einer Funktion.

Um eine große Anzahl von Parsern bereitzustellen, empfehlen wir die Verwendung von Parser-ARM-Vorlagen wie folgt:

  1. Erstellen Sie eine YAML-Datei basierend auf der relevanten Vorlage für jedes Schema, und fügen Sie Ihre Abfrage in diese ein. Beginnen Sie mit der YAML-Vorlage, die für Ihren Schema- und Parsertyp relevant ist, filternd oder parameterlos.

  2. Verwenden Sie den ASIM-Yaml-zu-ARM-Vorlagen-Konverter, um Ihre YAML-Datei in eine ARM-Vorlage zu konvertieren.

  3. Wenn Sie ein Update bereitstellen, löschen Sie ältere Versionen der Funktionen über das Portal oder das PowerShell-Tool zum Löschen von Funktionen.

  4. Stellen Sie Ihre Vorlage über das Azure-Portal oder PowerShell bereit.

Sie können auch mithilfe von verknüpften Vorlagen mehrere Vorlagen zu einem einzelnen Bereitstellungsprozess kombinieren.

Tipp

ARM-Vorlagen können verschiedene Ressourcen kombinieren, sodass Parser zusammen mit Connectors, Analyseregeln oder Watchlists bereitgestellt werden können, um nur einige nützliche Optionen zu nennen. Zum Beispiel kann Ihr Parser auf eine Watchlist verweisen, die parallel dazu bereitgestellt wird.

Testparser

In diesem Abschnitt werden die von ASIM bereitgestellten Testtools beschrieben, mit denen Sie Ihre Parser testen können. Allerdings handelt es sich bei Parsern um Code, der mitunter sehr komplex ist, und es wird empfohlen, zusätzlich zu den automatisierten Tests standardmäßige Qualitätssicherungsmaßnahmen wie Code Reviews durchzuführen.

Installieren von ASIM-Testtools

Stellen Sie zum Testen von ASIM das ASIM-Testtool in einem Microsoft Sentinel-Arbeitsbereich bereit, in dem Folgendes gilt:

  • Ihr Parser ist bereitgestellt.
  • Die vom Parser verwendete Quelltabelle ist verfügbar.
  • Die vom Parser verwendete Quelltabelle enthält eine Vielzahl von relevanten Ereignissen.

Validieren des Ausgabeschemas

Um sicherzustellen, dass Ihr Parser ein gültiges Schema erzeugt, verwenden Sie den ASIM-Schematester, indem Sie die folgende Abfrage auf der Protokolle-Seite von Microsoft Sentinel-Protokolle ausführen:

<parser name> | getschema | invoke ASimSchemaTester('<schema>')

Behandeln Sie die Ergebnisse wie folgt:

Fehler Aktion
Fehlendes erforderliches Feld [<Feld>] Fügen Sie das Feld Ihrem Parser hinzu. In vielen Fällen ist dies ein abgeleiteter Wert oder ein konstanter Wert und kein Feld, das bereits in der Quelle verfügbar ist.
Fehlendes Feld [<Feld>] ist obligatorisch, wenn die obligatorische Spalte [<Feld>] vorhanden ist Fügen Sie das Feld Ihrem Parser hinzu. In vielen Fällen gibt dieses Feld die Typen der vorhandenen Spalte an, auf die verwiesen wird.
Fehlendes Feld [<Feld>] ist obligatorisch, wenn die Spalte [<Feld>] vorhanden ist Fügen Sie das Feld Ihrem Parser hinzu. In vielen Fällen gibt dieses Feld die Typen der vorhandenen Spalte an, auf die verwiesen wird.
Fehlender obligatorischer Alias [<Feld>] führt Aliasing für die vorhandene Spalte [<Feld>] aus Fügen Sie den Alias Ihrem Parser hinzu
Fehlender empfohlener Alias [<Feld>] führt Aliasing für die vorhandene Spalte [<Feld>] aus Fügen Sie den Alias Ihrem Parser hinzu
Fehlender optionaler Alias [<Feld>] führt Aliasing für die vorhandene Spalte [<Feld>] aus Fügen Sie den Alias Ihrem Parser hinzu
Fehlender obilgatorischer Alias [<Feld>] führt Aliasing für die fehlende Spalte [<Feld>] aus Dieser Fehler wird von einem ähnlichen Fehler für das per Alias bezeichnete Feld begleitet. Korrigieren Sie den Fehler bezüglich des per Alias bezeichneten Felds und fügen Sie diesen Alias ihrem Parser hinzu.
Typkonflikt für Feld [<Feld>]. Es hat derzeit [<Typ>] und sollte [<Typ>] haben. Stellen Sie sicher, dass der Typ des normalisierten Felds korrekt ist, in der Regel mithilfe einer Konvertierungsfunktion wie tostring.
Info Aktion
Fehlendes empfohlenes Feld [<Feld>] Erwägen Sie das Hinzufügen dieses Felds zu Ihrem Parser.
Info Aktion
Fehlender empfohlener Alias [<Feld>] führt Aliasing für die nicht vorhandene Spalte [<Feld>] aus Wenn Sie dem Parser das per Alias bezeichnete Feld hinzufügen, stellen Sie sicher, dass Sie auch diesen Alias hinzufügen.
Fehlender optionaler Alias [<Feld>] führt Aliasing für die nicht vorhandene Spalte [<Feld>] aus Wenn Sie dem Parser das per Alias bezeichnete Feld hinzufügen, stellen Sie sicher, dass Sie auch diesen Alias hinzufügen.
Fehlendes optionales Feld [<Feld>] Optionale Felder fehlen zwar häufig, aber es lohnt sich, die Liste zu überprüfen, um zu bestimmen, ob eines der optionalen Felder aus der Quelle zugeordnet werden kann.
Zusätzliches nicht normalisiertes Feld [<Feld>] Auch wenn nicht normalisierte Felder gültig sind, lohnt es sich, die Liste zu überprüfen, um zu bestimmen, ob einer der nicht normalisierten Werte einem optionalen Feld zugeordnet werden kann.

Hinweis

Fehler verhindern, dass Inhalte, die den Parser verwenden, ordnungsgemäß funktionieren. Warnungen verhindern nicht, dass Inhalte funktionieren, können jedoch die Qualität der Ergebnisse beeinträchtigen.

Validieren der Ausgabewerte

Um sicherzustellen, dass Ihr Parser gültige Werte erzeugt, verwenden Sie den ASIM-Datentester, indem Sie die folgende Abfrage auf der Protokolle-Seite von Microsoft Sentinel-Protokolle ausführen:

<parser name> | limit <X> | invoke ASimDataTester ('<schema>')

Die Angabe eines Schemas ist optional. Wenn ein Schema nicht angegeben ist, wird das Feld EventSchema verwendet, um das Schema zu bestimmen, dem das Ereignis entsprechen soll. Wenn ein Ereignis kein EventSchema-Feld enthält, werden nur die üblichen Felder überprüft. Wenn ein Schema als Parameter angegeben wird, wird dieses Schema verwendet, um alle Zeilen zu testen. Dies ist nützlich für ältere Parser, die das EventSchema-Feld nicht festlegen.

Hinweis

Auch wenn ein Schema nicht angegeben wird, werden leere Klammern nach dem Funktionsnamen benötigt.

Dieser Test ist ressourcenintensiv und funktioniert möglicherweise nicht für ihr gesamtes Dataset. Legen Sie X auf die größte Zahl fest, für die bei der Abfrage keine Zeitüberschreitung erfolgt, oder legen Sie den Zeitbereich für die Abfrage mithilfe der Zeitbereichsauswahl fest.

Behandeln Sie die Ergebnisse wie folgt:

`Message` Aktion
(0) Fehler: Typkonflikt für Spalte [<Feld>]. Sie hat derzeit [<Typ>] und sollte [<Typ>] haben. Stellen Sie sicher, dass der Typ des normalisierten Felds korrekt ist, in der Regel mithilfe einer Konvertierungsfunktion wie tostring.
(0) Fehler: Ungültige(r) Wert(e) (bis zu 10 aufgeführt) für Feld [<Feld>] des Typs [<Logischer Typ>] Stellen Sie sicher, dass der Parser dem Ausgabefeld das richtige Quellfeld zuordnet. Bei korrekter Zuordnung sollten den Parser anpassen, sodass der Quellwert in den richtigen Typ, Wert oder das richtige Format transformiert wird. Weitere Informationen zu den richtigen Werten und Formaten für jeden logischen Typ finden Sie in der Liste der logischen Typen.

Beachten Sie, dass das Testtool nur 10 der ungültigen Werte auflistet.
(1) Warnung: Leerer Wert im obligatorischen Feld [<Feld>] Erforderliche Felder sollten gefüllt und nicht nur definiert sein. Überprüfen Sie, ob das Feld aus anderen Quellen für Datensätze aufgefüllt werden kann, die es in der aktuellen Quelle nicht gibt.
(2) Info: Leerer Wert im empfohlenen Feld [<Feld>] Empfohlene Felder sollten in der Regel gefüllt sein. Überprüfen Sie, ob das Feld aus anderen Quellen für Datensätze aufgefüllt werden kann, die es in der aktuellen Quelle nicht gibt.
(2) Info: Leerer Wert im optionalen Feld [<Feld>] Überprüfen Sie, ob das per Alias bezeichnete Feld obligatorisch oder empfohlen ist, und in diesem Falle, ob es aus anderen Quellen aufgefüllt werden kann.

Viele der Meldungen geben auch die Anzahl der Datensätze an, die die Meldung generiert haben, sowie deren prozentualer Anteil an der Gesamtstichprobe. Dieser Prozentsatz ist ein guter Indikator für die Bedeutung des Problems. Beispiel für ein empfohlenes Feld:

  • 90 % leere Werte können auf ein allgemeines Analyseproblem hinweisen.
  • 25 % leere Werte können auf eine Ereignisvariante hinweisen, die nicht ordnungsgemäß analysiert wurde.
  • Eine Handvoll leerer Werte kann ein vernachlässigbares Problem sein.

Hinweis

Fehler verhindern, dass Inhalte, die den Parser verwenden, ordnungsgemäß funktionieren. Warnungen verhindern nicht, dass Inhalte funktionieren, können jedoch die Qualität der Ergebnisse beeinträchtigen.

Beitragen von Parsern

Möglicherweise möchten Sie den Parser zur primären ASIM-Verteilung beitragen. Wenn dies akzeptiert wird, stehen die Parser jedem Kunden als integrierte ASIM-Parser zur Verfügung.

So tragen Sie Ihre Parser bei:

Dokumentieren akzeptierter Warnungen

Wenn die von den ASIM-Testtools aufgeführten Warnungen als gültig für einen Parser gelten, dokumentieren Sie die akzeptierten Warnungen in der Parser-YAML-Datei mithilfe des Abschnitts „Ausnahmen“, wie im folgenden Beispiel gezeigt.

Exceptions:
- Field: DnsQuery 
  Warning: Invalid value
  Exception: May have values such as "1164-ms-7.1440-9fdc2aab.3b2bd806-978e-11ec-8bb3-aad815b5cd42" which are not valid domains names. Those are related to TKEY RR requests.
- Field: DnsQuery
  Warning: Empty value in mandatory field
  Exception: May be empty for requests for root servers and for requests for RR type DNSKEY

Die in der YAML-Datei angegebene Warnung sollte eine kurze Form der Warnmeldung sein, die eindeutig identifiziert wird. Der Wert wird verwendet, um Warnmeldungen beim Ausführen automatisierter Tests abzugleichen und sie zu ignorieren.

Richtlinien für die Übermittlung von Beispielen

Um Parserprobleme zu beheben und sicherzustellen, dass zukünftige Updates des Parsers mit älteren Beispielen übereinstimmen, werden Beispieldaten benötigt. Die von Ihnen übermittelten Beispiele sollten jede Ereignisvariante enthalten, die vom Parser unterstützt wird. Stellen Sie sicher, dass die Beispielereignisse alle möglichen Ereignistypen, Ereignisformate und Variationen enthalten, z. B. Ereignisse, die eine erfolgreiche und fehlgeschlagene Aktivität darstellen. Stellen Sie außerdem sicher, dass Variationen in Wertformaten dargestellt werden. Wenn beispielsweise ein Hostname als FQDN oder als einfacher Hostname dargestellt werden kann, sollten die Beispielereignisse beide Formate enthalten.

Führen Sie die folgenden Schritte aus, um die Ereignisbeispiele zu übermitteln:

  • Führen Sie auf dem Logs-Bildschirm eine Abfrage aus, die nur die vom Parser ausgewählten Ereignisse aus der Quelltabelle extrahiert. Verwenden Sie beispielsweise für den Infoblox-DNS-Parser die folgende Abfrage:
    Syslog
    | where ProcessName == "named"

  • Exportieren Sie die Ergebnisse mithilfe der Option In CSV exportieren in eine Datei mit dem Namen <EventVendor>_<EventProduct>_<EventSchema>_IngestedLogs.csv, wobei EventProduct, EventProduct und EventSchema die Werte sind, die vom Parser diesen Feldern zugewiesen werden.

  • Führen Sie auf dem Logs-Bildschirm eine Abfrage aus, die das Schema oder die Parsereingabetabelle ausgibt. Für denselben Infoblox-DNS-Parser lautet die Abfrage beispielsweise:

    Syslog
    | getschema

  • Exportieren Sie die Ergebnisse mithilfe der Option In CSV exportieren in eine Datei mit dem Namen <TableName>_schema.csv, wobei TableName der Name der Quelltabelle ist, die der Parser verwendet.

  • Nehmen Sie beide Dateien in Ihre PR im Ordner /Sample Data/ASIM auf. Wenn die Datei bereits vorhanden ist, fügen Sie dem Namen Ihr GitHub-Handle hinzu, z. B.: <EventVendor>_<EventProduct>_<EventSchema>_SchemaTest_<GitHubHanlde>.csv.

Richtlinien zur Übermittlung von Testergebnissen

Testergebnisse sind wichtig, um die Richtigkeit des Parsers zu überprüfen und alle gemeldeten Ausnahmen zu verstehen.

Führen Sie die folgenden Schritte aus, um Ihre Testergebnisse zu übermitteln:

  • Führen Sie die Parsertests aus, die im Abschnitt Tests beschrieben werden.

  • Exportieren Sie die Testergebnisse mithilfe der Option In CSV exportieren in Dateien mit dem Namen <EventVendor>_<EventProduct>_<EventSchema>_SchemaTest.csv bzw <EventVendor>_<EventProduct>_<EventSchema>_DataTest.csv.

  • Nehmen Sie beide Dateien in Ihre PR im Ordner /Parsers/ASim<schema>/Tests auf.

Nächste Schritte

Dieser Artikel behandelt die Entwicklung von ASIM-Parsern.

Weitere Informationen zu ASIM-Parsern:

Weitere Informationen zur ASIM im Allgemeinen finden Sie hier: