Entwickeln von ASIM-Parsern (Advanced Security Information Model)

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

Microsoft Sentinel bietet integrierte, quellspezifische Parser für viele Datenquellen. Sie können diese quellspezifischen Parser in den folgenden Situationen ändern oder entwickeln:

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

  • Wenn quellspezifische ASIM-Parser für Ihr Gerät verfügbar sind, Ihr Gerät jedoch Ereignisse in einer Methode oder einem anderen Format sendet als von den ASIM-Parsern erwartet. Zum Beispiel:

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

    • Ihr Gerät verfügt möglicherweise über eine andere Version als die, die vom ASIM-Parser unterstützt wird.

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

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

Entwicklungsprozess für benutzerdefinierte ASIM-Parser

Der folgende Workflow beschreibt die allgemeinen Schritte beim Entwickeln eines benutzerdefinierten, quellenspezifischen ASIM-Parsers:

  1. Sammeln von Beispielprotokollen.

  2. Identifizieren Sie die Schemas, die die von der Quelle gesendeten Ereignisse darstellen. Weitere Informationen finden Sie unter Schemaübersicht.

  3. Ordnen Sie die Quellereignisfelder den identifizierten Schemas zu.

  4. Entwickeln Sie einen oder mehrere ASIM-Parser für Ihre Quelle. Sie müssen einen Filterparser und einen parameterlosen Parser für jedes Schema entwickeln, das für die Quelle relevant ist.

  5. Testen Sie Ihren Parser.

  6. Stellen Sie die Parser in Ihren Microsoft Sentinel Arbeitsbereichen bereit.

  7. Aktualisieren Sie den relevanten vereinheitlichenden ASIM-Parser, um auf den neuen benutzerdefinierten Parser zu verweisen. Weitere Informationen finden Sie unter Verwalten von ASIM-Parsern.

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

Dieser Artikel führt Sie durch die Entwicklungs-, Test- und Bereitstellungsschritte des Prozesses.

Tipp

Sehen Sie sich auch das Deep Dive-Webinar zu Microsoft Sentinel Normalisierung von Parsern und normalisierten Inhalten an, oder überprüfen Sie die zugehörige Foliengruppe. Weitere Informationen finden Sie unter: Nächste Schritte.

Sammeln von Beispielprotokollen

Um effektive ASIM-Parser zu erstellen, benötigen Sie einen repräsentativen Satz von Protokollen. In den meisten Fällen müssen Sie das Quellsystem einrichten und es mit Microsoft Sentinel verbinden. Wenn Sie nicht über das Quellgerät verfügen, können Sie mit cloudbasierten Nutzungsbasierten Diensten viele Geräte für Entwicklung und Tests bereitstellen.

Darüber hinaus kann die Suche nach der Herstellerdokumentation und den Beispielen für die Protokolle dazu beitragen, die Entwicklung zu beschleunigen und Fehler zu reduzieren, indem eine breite Protokollformatabdeckung sichergestellt wird.

Ein repräsentativer Satz von Protokollen sollte Folgendes umfassen:

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

Tipp

Starten Sie einen neuen benutzerdefinierten Parser mit einem vorhandenen Parser für dasselbe Schema. Die Verwendung eines vorhandenen Parsers ist besonders wichtig für das Filtern von Parsern, um sicherzustellen, dass sie alle für das Schema erforderlichen Parameter akzeptieren.

Planen der Zuordnung

Bevor Sie einen Parser entwickeln, ordnen Sie die im Quellereignis oder den Quellereignissen verfügbaren Informationen dem von Ihnen identifizierten Schema zu:

  • Ordnen Sie alle Pflichtfelder und vorzugsweise auch empfohlene Felder zu.
  • Versuchen Sie, alle informationen, die aus 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 von ASIM zulässigen normalisierten Werten zu. Der ursprüngliche Wert wird in einem separaten Feld gespeichert, z EventOriginalResultDetails. B. .

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 Seite Microsoft Sentinel-Protokolle entwickelt wurde. Die Parserabfrage umfasst drei Teile:

Filter>Parse>Vorbereiten von Feldern

Filtern

Filtern der relevanten Datensätze

In vielen Fällen enthält eine Tabelle in Microsoft Sentinel mehrere Ereignistypen. Zum Beispiel:

  • Die Syslog-Tabelle enthält Daten aus mehreren Quellen.
  • Benutzerdefinierte Tabellen können Informationen aus einer einzigen Quelle enthalten, die mehr als einen Ereignistyp bereitstellt und für verschiedene Schemas geeignet ist.

Daher sollte ein Parser zuerst nur die Datensätze filtern, die für das Zielschema relevant sind.

Das Filtern in KQL erfolgt mithilfe des where Operators. Sysmon-Ereignis 1 meldet beispielsweise die Prozesserstellung und wird daher auf das ProcessEvent-Schema normalisiert. Das Sysmon-Ereignis 1 ist Teil der Event Tabelle, sodass Sie den folgenden Filter verwenden würden:

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

Wichtig

Ein Parser sollte nicht nach Zeit filtern. 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 aus 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 Sources_by_SourceType Watchlist verwaltet.

Um die Watchlist ASimSourceType in Ihren Parsern zu verwenden, verwenden Sie die _ASIM_GetSourceBySourceType Funktion im Abschnitt parserfilterung. Der Infoblox-DNS-Parser enthält beispielsweise Folgendes im Filterabschnitt:

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

So verwenden Sie dieses Beispiel in Ihrem Parser:

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

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

Filtern basierend auf Parserparametern

Stellen Sie beim Entwickeln von Filterparsern sicher, dass Ihr Parser die Filterparameter für das relevante 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 das Filtern von Parsern für dasselbe Schema ähnlich.

Stellen Sie beim Filtern sicher, dass Sie:

  • Filtern Sie vor der Analyse mithilfe von physischen Feldern. Wenn die gefilterten Ergebnisse nicht genau genug sind, wiederholen Sie den Test nach der Analyse, um Ihre Ergebnisse zu optimieren. Weitere Informationen finden Sie unter Filteroptimierung.
  • Filtern Sie nicht, wenn der Parameter nicht definiert ist und weiterhin den Standardwert aufweist.

Die folgenden Beispiele zeigen, wie Sie die Filterung für einen Zeichenfolgenparameter implementieren, bei dem der Standardwert normalerweise "*" ist, und für einen Listenparameter, bei dem der Standardwert normalerweise eine leere Liste ist.

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

Weitere Informationen zu den folgenden Elementen finden Sie in der Kusto-Dokumentation:

Filteroptimierung

Beachten Sie die folgenden Filterempfehlungen, um die Leistung des Parsers sicherzustellen:

  • Filtern Sie immer nach integrierten Feldern statt nach analysierten Feldern. Obwohl es manchmal einfacher ist, mithilfe analysierter Felder zu filtern, wirkt sich dies erheblich auf die Leistung aus.
  • Verwenden Sie Operatoren, die eine optimierte Leistung bereitstellen. Insbesondere ==, hasund startswith. Die Verwendung von Operatoren wie contains oder matches regex wirkt sich auch erheblich auf die Leistung aus.

Das Filtern von Empfehlungen für die Leistung ist möglicherweise nicht immer einfach zu befolgen. Beispielsweise ist die Verwendung von has weniger genau als contains. In anderen Fällen ist der Abgleich mit dem integrierten Feld, z SyslogMessage. B. , weniger genau als der Vergleich eines extrahierten Felds, z DvcAction. B. . In solchen Fällen wird empfohlen, dass Sie nach der Analyse weiterhin mithilfe eines leistungsoptimierenden Operators über ein integriertes Feld filtern und den Filter mit genaueren Bedingungen wiederholen.

Ein Beispiel finden Sie im folgenden Infoblox-DNS-Parserausschnitt . Der Parser überprüft zunächst, ob das SyslogMessage-Feld has das Wort enthält client. Der Begriff kann jedoch an einer anderen Stelle in der Nachricht verwendet werden, sodass der Parser nach dem Analysieren des Log_Type Felds 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 Zeit filtern, da die Abfrage, die den Parser verwendet, bereits nach Zeit filtert.

Analyse

Nachdem die Abfrage die relevanten Datensätze ausgewählt hat, müssen sie sie möglicherweise analysieren. In der Regel ist eine Analyse erforderlich, wenn mehrere Ereignisfelder in einem einzelnen Textfeld übermittelt werden.

Die KQL-Operatoren, die die Analyse durchführen, sind unten aufgeführt, geordnet nach ihrer Leistungsoptimierung. Die erste bietet die am stärksten optimierte Leistung, während die letzte die am wenigsten optimierte Leistung bietet.

Operator/function() Beschreibung
split() -Funktion Analysieren Sie eine Zeichenfolge mit durch Trennzeichen getrennten Werten.
parse_csv() -Funktion Analysieren Sie eine Zeichenfolge von Werten, die als CSV-Zeile (durch Trennzeichen getrennte Werte) formatiert sind.
parse-kv-Operator Extrahiert strukturierte Informationen aus einem Zeichenfolgenausdruck und stellt die Informationen in einer Schlüssel-Wert-Form dar.
parse-Operator Analysieren Sie mehrere Werte aus einer beliebigen Zeichenfolge mithilfe eines Musters, bei dem es sich um ein vereinfachtes Muster mit besserer Leistung oder um einen regulären Ausdruck handeln kann.
extract_all() -Funktion Analysieren Sie einzelne Werte aus einer beliebigen Zeichenfolge mithilfe eines regulären Ausdrucks. extract_all hat eine ähnliche Leistung parse wie bei verwendung eines regulären Ausdrucks.
extract() -Funktion Extrahieren Sie einen einzelnen Wert aus einer beliebigen Zeichenfolge mithilfe eines regulären Ausdrucks.

Die Verwendung von extract bietet eine bessere Leistung als parse oder extract_all , wenn ein einzelner Wert erforderlich ist. Die Verwendung mehrerer Aktivierungen von extract über dieselbe Quellzeichenfolge ist jedoch weniger effizient als eine einzelne parse oder extract_all und sollte vermieden werden.
parse_json() -Funktion Analysieren Sie die Werte in einer Zeichenfolge, die als JSON formatiert ist. Wenn nur wenige Werte aus dem JSON-Code benötigt werden, bietet die Verwendung von parse, extractoder extract_all eine bessere Leistung.
parse_xml() -Funktion Analysieren Sie die Werte in einer Zeichenfolge, die als XML formatiert ist. Wenn nur wenige Werte aus dem XML-Code benötigt werden, bietet die Verwendung von parse, extractoder extract_all eine bessere Leistung.

Normalisierung

Zuordnen von Feldnamen

Die einfachste Form der Normalisierung besteht darin, ein ursprüngliches Feld in seinen normalisierten Namen umzubenennen. Verwenden Sie dafür den -Operator project-rename . Durch die Verwendung von Projektumbenennung wird sichergestellt, dass das Feld weiterhin als physisches Feld verwaltet wird und die Verarbeitung des Felds leistungsfähiger ist. Zum Beispiel:

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

Normalisieren des Feldformats und -typs

In vielen Fällen muss der extrahierte ursprüngliche Wert normalisiert werden. Beispielsweise verwendet eine MAC-Adresse in ASIM Doppelpunkte als Trennzeichen, während die Quelle eine durch Trennzeichen getrennte MAC-Adresse senden kann. Der primäre Operator zum Transformieren von Werten ist extend, zusammen mit einem breiten Satz von KQL-Zeichenfolgen-, numerischen und Datumsfunktionen.

Außerdem ist es wichtig, sicherzustellen, dass parserausgabefelder dem im Schema definierten Typ entsprechen, damit Parser funktionieren. Beispielsweise müssen Sie möglicherweise eine Zeichenfolge, die Datum und Uhrzeit darstellt, in ein datetime-Feld konvertieren. Funktionen wie todatetime und tohex sind in diesen Fällen hilfreich.

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

  | extend EventOriginalUid = tostring(ReportId),

Abgeleitete Felder und Werte

Der Wert des Quellfelds muss nach dem Extrahieren möglicherweise dem Satz von Werten zugeordnet werden, die für das Zielschemafeld angegeben sind. Die Funktionen iff, caseund lookup können hilfreich sein, um verfügbare Daten zielwerten zuzuordnen.

Der Microsoft DNS-Parser weist das Feld beispielsweise basierend auf der EventResult 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 zum Durchführen der Zuordnung. Beispielsweise melden einige Quellen numerische DNS-Antwortcodes und das Netzwerkprotokoll, während das Schema die häufigere Darstellung von Textbezeichnungen für beide vorschreibt. Im folgenden Beispiel wird veranschaulicht, wie die erforderlichen Werte mithilfe von datatable und lookupabgeleitet werden:

   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 die Suche auch dann nützlich und effizient ist, wenn die Zuordnung nur über zwei mögliche Werte verfügt.

Wenn die Zuordnungsbedingungen komplexer sind, kombinieren Sie iff, caseund lookup. Das folgende Beispiel zeigt, wie und casekombiniert lookup werden. Im lookup obigen Beispiel wird ein leerer Wert im Feld DnsResponseCodeName zurückgegeben, wenn der Nachschlagewert nicht gefunden wird. Im case folgenden Beispiel wird es erweitert, indem das Ergebnis des lookup Vorgangs verwendet wird, sofern verfügbar, und andernfalls werden zusätzliche Bedingungen angegeben.

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

Microsoft Sentinel bietet praktische Funktionen für allgemeine Nachschlagewerte. Die obige Suche kann beispielsweise DnsResponseCodeName mithilfe einer der folgenden Funktionen implementiert werden:


| extend DnsResponseCodeName = _ASIM_LookupDnsResponseCode(DnsResponseCode)

| invoke _ASIM_ResolveDnsResponseCode('DnsResponseCode')

Die erste Option akzeptiert als Parameter den nachschlagenden Wert, sodass Sie das Ausgabefeld auswählen können und daher als allgemeine Nachschlagefunktion nützlich sind. Die zweite Option ist eher 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

Zusätzlich zu den aus der Quelle verfügbaren Feldern enthält ein resultierendes ASIM-Ereignis Anreicherungsfelder, die der Parser generieren soll. In vielen Fällen können die Parser den Feldern einen konstanten Wert zuweisen, z. B.:

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

Ein weiterer Typ von Anreicherungsfeldern, den Ihre Parser festlegen sollten, sind Typfelder, die den Typ des in einem verknüpften Feld gespeicherten Werts angeben. Das Feld legt beispielsweise den Werttyp fest, SrcUsernameType der SrcUsername im Feld gespeichert ist. Weitere Informationen zu Typfeldern finden Sie in der Entitätsbeschreibung.

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

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

Microsoft Sentinel bietet nützliche Funktionen für die Verarbeitung der Anreicherung. Verwenden Sie beispielsweise die folgende Funktion, um die Felder SrcHostname, SrcDomainTypeSrcDomainund SrcFQDN basierend auf dem Wert im Feld Computerautomatisch zuzuweisen.

  | invoke _ASIM_ResolveSrcFQDN('Computer')

Diese Funktion legt die Felder wie folgt fest:

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, die die zugehörigen Dst Felder und Dvc auffüllt. 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. Das Entfernen nicht benötigter Felder kann die Leistung verbessern und Klarheit schaffen, indem Verwechslungen zwischen normalisierten Feldern und verbleibenden Quellfeldern vermieden werden.

Die folgenden KQL-Operatoren werden verwendet, um Felder in Ihrem Resultset auszuwählen:

Operator Beschreibung Verwendung in einem Parser
Projekt weg Entfernt Felder. Verwenden Sie für project-away bestimmte Felder, die Sie aus dem Resultset entfernen möchten. Es wird empfohlen, die ursprünglichen Felder, die nicht normalisiert sind, nicht aus dem Resultset zu entfernen, es sei denn, sie führen zu Verwirrung oder sind sehr groß und können Auswirkungen auf die Leistung haben.
Projekt Wählt Felder aus, die zuvor vorhanden waren oder als Teil der Anweisung erstellt wurden, und entfernt alle anderen Felder. Die Verwendung in einem Parser wird nicht empfohlen, da der Parser keine anderen Felder entfernen sollte, die nicht normalisiert sind.

Wenn Sie bestimmte Felder entfernen müssen, z. B. temporäre Werte, die während der Analyse verwendet werden, verwenden Sie project-away , um sie aus den Ergebnissen zu entfernen.

Wenn Sie beispielsweise eine benutzerdefinierte Protokolltabelle analysieren, verwenden Sie Folgendes, um die verbleibenden ursprünglichen Felder zu entfernen, die noch einen Typdeskriptor aufweisen:

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

Behandeln von Analysevarianten

Wichtig

Die verschiedenen Varianten stellen verschiedene Ereignistypen dar, die häufig verschiedenen Schemas zugeordnet sind, entwickeln separate Parser.

In vielen Fällen enthalten Ereignisse in einem Eventstream Varianten, die eine andere Analyselogik erfordern. Um verschiedene Varianten in einem einzelnen Parser zu analysieren, verwenden Sie entweder bedingte Anweisungen wie iff und , caseoder verwenden Sie eine Union-Struktur.

union Um mehrere Varianten zu verarbeiten, erstellen Sie eine separate Funktion für jede Variante, und verwenden Sie die union-Anweisung, 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 übermäßige Verarbeitung zu vermeiden, stellen Sie sicher, dass jede Funktion beginnt, indem sie nur die Ereignisse, die sie analysieren soll, mithilfe nativer Felder filtern. Verwenden Sie bei Bedarf auch project-away in jedem Branch vor der Union.

Bereitstellen von Parsern

Stellen Sie Parser manuell bereit, indem Sie sie auf die Seite Azure Überwachungsprotokoll kopieren und die Abfrage als Funktion speichern. Diese Methode ist für Tests nützlich. 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 schließen Sie Ihre Abfrage darin ein. Beginnen Sie mit der YAML-Vorlage , die für Ihr Schema und Ihren Parsertyp, filtert oder ohne Parameter relevant ist.

  2. Verwenden Sie den ASIM YAML-zu-ARM-Vorlagenkonverter , 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 der Funktion.

  4. Stellen Sie Ihre Vorlage mithilfe der Azure-Portal oder PowerShell bereit.

Sie können auch mehrere Vorlagen zu einem einzelnen Bereitstellungsprozess kombinieren, indem Sie verknüpfte Vorlagen verwenden.

Tipp

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

Testen von Parsern

In diesem Abschnitt wird beschrieben, dass ASIM Testtools bereitstellt, mit denen Sie Ihre Parser testen können. Parser sind jedoch Code, manchmal komplex, und neben automatisierten Tests werden standardmäßige Qualitätssicherungsverfahren wie Codeüberprüfungen empfohlen.

Installieren von ASIM-Testtools

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

  • Ihr Parser wird bereitgestellt.
  • Die vom Parser verwendete Quelltabelle ist verfügbar.
  • Die vom Parser verwendete Quelltabelle wird mit einer unterschiedlichen Auflistung relevanter Ereignisse aufgefüllt.

Überprüfen des Ausgabeschemas

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

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

Behandeln Sie die Ergebnisse wie folgt:

Fehler Maßnahme
Fehlendes Pflichtfeld [<Feld>] Fügen Sie das Feld ihrem Parser hinzu. In vielen Fällen wäre dies ein abgeleiteter Wert oder ein konstanter Wert und kein Feld, das bereits aus 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 es verweist.
Fehlendes Feld [<Feld>] ist obligatorisch, wenn 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 es verweist.
Fehlender obligatorischer Alias [<Feld>] für die vorhandene Spalte [<Feld>] Hinzufügen des Alias zu Ihrem Parser
Fehlender empfohlener Alias [<Feld>] als Alias für vorhandene Spalte [<Feld>] Hinzufügen des Alias zu Ihrem Parser
Fehlender optionaler Alias [<Feld>] für die vorhandene Spalte [<Feld>] Hinzufügen des Alias zu Ihrem Parser
Fehlender obligatorischer Alias [<Feld>] Aliasing fehlender Spalte [<Feld>] Dieser Fehler begleitet einen ähnlichen Fehler für das Feld mit Alias. Korrigieren Sie den Aliasfeldfehler, und fügen Sie diesen Alias ihrem Parser hinzu.
Typkonflikt für Feld [<Feld>]. Es ist derzeit [<Typ>] und sollte [<Typ>] sein. Stellen Sie sicher, dass der Typ des normalisierten Felds richtig ist, in der Regel mithilfe einer Konvertierungsfunktion wie tostring.
Info Aktion
Empfohlenes Feld fehlt [<Feld>] Erwägen Sie, dieses Feld ihrem Parser hinzuzufügen.
Info Aktion
Fehlender empfohlener Alias [<Feld>] Aliasing nicht vorhandener Spalte [<Feld>] Wenn Sie das Aliasfeld zum Parser hinzufügen, müssen Sie auch diesen Alias hinzufügen.
Fehlender optionaler Alias [<Feld>] als Alias für nicht vorhandene Spalte [<Feld>] Wenn Sie das Aliasfeld zum Parser hinzufügen, müssen Sie auch diesen Alias hinzufügen.
Optionales Feld fehlt [<Feld>] Obwohl optionale Felder häufig fehlen, lohnt es sich, die Liste zu überprüfen, um festzustellen, ob eines der optionalen Felder aus der Quelle zugeordnet werden kann.
Zusätzliches nicht normalisiertes Feld [<Feld>] Obwohl nicht normalisierte Felder gültig sind, lohnt es sich, die Liste zu überprüfen, um festzustellen, 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 aber die Qualität der Ergebnisse beeinträchtigen.

Überprüfen der Ausgabewerte

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

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

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

Hinweis

Auch wenn kein Schema angegeben ist, sind leere Klammern nach dem Funktionsnamen erforderlich.

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 für die Abfrage kein Timeout ausgeführt wird, 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>] Es ist derzeit [<Typ>] und sollte [<Typ>] sein. Stellen Sie sicher, dass der Typ des normalisierten Felds richtig ist, in der Regel mithilfe einer Konvertierungsfunktion wie tostring.
(0) Fehler: Ungültige Werte (bis zu 10 aufgelistet) für Feld [<Feld>] vom Typ [<Logischer Typ>] Stellen Sie sicher, dass der Parser dem Ausgabefeld das richtige Quellfeld zuordnet. Aktualisieren Sie bei richtiger Zuordnung den Parser, um den Quellwert in den richtigen Typ, Wert oder Format zu transformieren. 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 eine Stichprobe von 10 ungültigen Werten auflistet.
(1) Warnung: Leerer Wert im Pflichtfeld [<Feld>] Pflichtfelder sollten aufgefüllt und nicht nur definiert werden. Überprüfen Sie, ob das Feld aus anderen Quellen für Datensätze aufgefüllt werden kann, für die die aktuelle Quelle leer ist.
(2) Info: Leerer Wert im empfohlenen Feld [<Feld>] Empfohlene Felder sollten in der Regel aufgefüllt werden. Überprüfen Sie, ob das Feld aus anderen Quellen für Datensätze aufgefüllt werden kann, für die die aktuelle Quelle leer ist.
(2) Info: Leerer Wert im optionalen Feld [<Feld>] Überprüfen Sie, ob das Aliasfeld obligatorisch oder empfohlen ist, und wenn ja, ob es aus anderen Quellen aufgefüllt werden kann.

Viele der Nachrichten geben auch die Anzahl der Datensätze an, die die Nachricht generiert haben, und deren Prozentsatz 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 richtig 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 aber die Qualität der Ergebnisse beeinträchtigen.

Beitragen von Parsern

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

So tragen Sie Ihre Parser bei:

Dokumentieren akzeptierter Warnungen

Wenn von den ASIM-Testtools aufgelistete Warnungen als gültig für einen Parser gelten, dokumentieren Sie die akzeptierten Warnungen in der YAML-Parserdatei 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 Kurzform der Warnmeldung sein, die eindeutig identifiziert wird. Der Wert wird verwendet, um Warnmeldungen bei automatisierten Tests abzugleichen und zu ignorieren.

Richtlinien für die Übermittlung von Beispielen

Beispieldaten werden benötigt, um Parserprobleme zu beheben und sicherzustellen, dass zukünftige Updates des Parsers älteren Beispielen entsprechen. Die von Ihnen übermittelten Beispiele sollten eine beliebige Ereignisvariante enthalten, die der Parser unterstützt. Stellen Sie sicher, dass die Beispielereignisse alle möglichen Ereignistypen, Ereignisformate und Variationen enthalten, z. B. Ereignisse, die erfolgreiche und fehlgeschlagene Aktivitäten darstellen. Stellen Sie außerdem sicher, dass Variationen in Wertformaten dargestellt werden. Wenn beispielsweise ein Hostname als FQDN oder 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, EventProductund 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 Vom Parser verwendeten Quelltabelle ist.

  • Schließen Sie beide Dateien in Ihren PR im Ordner /Sample Data/ASIMein. Wenn die Datei bereits vorhanden ist, fügen Sie dem Namen Ihr GitHub-Handle hinzu, z. B.: <EventVendor>_<EventProduct>_<EventSchema>_SchemaTest_<GitHubHandle>.csv

Richtlinien für die Ü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.

  • und 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 .

  • Schließen Sie beide Dateien in Ihren PR im Ordner /Parsers/ASim<schema>/Testsein.

Nächste Schritte

In diesem Artikel wird die Entwicklung von ASIM-Parsern erläutert.

Erfahren Sie mehr über ASIM-Parser:

Weitere Informationen zum ASIM im Allgemeinen:

  • Last updated on