Parsererweiterungen verwenden

Unterstützt in:

Google SecOps SIEM

Google Security Operations bietet mehrere Methoden, um zu definieren, wie Daten in ursprünglichen Rohprotokollen gespeichert werden geparst und zu einem UDM-Datensatz (Unified Data Model) normalisiert.

• Standardparser: vordefinierte Anweisungen für die Datenzuordnung, die von Google Security Operations verwaltet werden die ursprünglichen Logrohdaten UDM-Feldern zuordnen.
• Benutzerdefinierte Parser: Benutzerdefinierte Anweisungen für die Datenzuordnung, die von einem die die spezifischen Anforderungen des Kunden beim Parsen von Daten erfüllen.
• Parsererweiterungen: Zusätzliche Anweisungen zur Datenzuordnung, mit denen ein Standard- oder benutzerdefinierten Parser verwenden, um zusätzliche Felder im ursprünglichen Rohlog zuzuordnen. Das bedeutet nicht, einen Standard- oder benutzerdefinierten Parser vollständig ersetzen, aber die vorhandenen Zuordnungsanweisungen erweitern in einem Standardparser oder einem benutzerdefinierten Parser an.

In diesem Dokument wird die Verwendung von Parsererweiterungen beschrieben.

Hinweise

In den folgenden Dokumenten werden die grundlegenden Konzepte erläutert, die Sie bei der Arbeit mit Parsererweiterungen kennen sollten:

• Übersicht über das einheitliche Datenmodell
• Übersicht über das Parsen von Logs
• Parser-Syntaxreferenz

Parsererweiterungen

Mit einer Parsererweiterung können Sie zusätzliche Zuordnungsanweisungen erstellen, die über Parser, die in einem Standard- oder benutzerdefinierten Parser definiert sind, um einen eindeutigen Anwendungsfall zu erfüllen. Diese Funktion dient dazu, einen vorhandenen Standard- oder benutzerdefinierten Parser zu erweitern. Eine Parsererweiterung ersetzt keinen Standard- oder benutzerdefinierten Parser. Sie können keinen neuen Parser mit einer Parsererweiterung erstellen.

Die Parsererweiterung liest das ursprüngliche Rohprotokoll und fügt die extrahierten Werte in bestimmte Felder im UDM-Eintrag. Der UDM-Eintrag enthält Daten, die sowohl vom Standard- als auch vom benutzerdefinierten Parser festgelegt werden und die Parser-Erweiterung.

Anweisungen zur Datenzuordnung in einer Parsererweiterung haben Vorrang vor in einem Standardparser oder einem benutzerdefinierten Parser. Wenn es bei den Zuordnungsanweisungen zu einem Konflikt kommt, überschreibt die Parsererweiterung einen Wert, der vom Standard- oder benutzerdefinierten Parser festgelegt wurde. Wenn der Standardparser z. B. Ein Rohlogfeld in das UDM-Feld event.metadata.description. und die Parser-Erweiterung demselben UDM-Feld ein anderes Rohlogfeld zuordnet, überschreibt die Parsererweiterung den vom Standardparser festgelegten Wert. Eine Ausnahme stellen wiederkehrende Felder dar. Sie können die Parsererweiterung so konfigurieren, und Werte anfügen, wenn Daten in ein wiederkehrendes Feld geschrieben werden.

Sie erstellen eine Parsererweiterung pro Logtyp. Jeder Protokolltyp wird durch ein eindeutiges Aufnahmelabel identifiziert. Eine Liste der Logtypen finden Sie unter Unterstützte Standardparser.

Zum Erstellen einer Parsererweiterung muss Google Security Operations Folgendes können: die ursprünglichen Rohlogs mit einem standardmäßigen oder benutzerdefinierten parser. Die Parsererweiterung extrahiert zusätzliche Daten aus dem ursprünglichen Rohlog. mit dem UDM-Eintrag zusammengeführt.

Parser-Erweiterungen unterstützen die folgenden Arten von Zuordnungsanweisungen:

• Code-Snippet-Typ: Sie schreiben Parser-Code ähnlich wie bei Standard- und benutzerdefinierten Parsern. Die ursprünglichen Rohlogs können jedes der unterstützten Datenformate haben. für den Logtyp aus.
• Datenfeldtyp: Die Felder für Start und Ziel werden in der Anwendungsoberfläche angegeben. Die ursprünglichen Rohprotokolle müssen folgendermaßen formatiert sein:
  • Natives JSON, natives XML oder CSV.
  • Syslog-Header und natives JSON, natives XML oder CSV. Sie können eine Anweisung zur Zuordnung des Datenfeldtyps für eine Teilmenge von „Log“ erstellen Typen unter Unterstützte Standardparser. Suchen Sie nach Werten im Format JSON, XML, CSV, SYSLOG + JSON, SYSLOG + XML und SYSLOG + CSV.

Beachten Sie beim Erstellen einer Parsererweiterung Folgendes:

• Daten können jedem UDM-Feld zugeordnet werden, das die Standarddatentypen und wiederholte Werte.
• Daten können nicht den folgenden UDM-Feldern zugeordnet werden:
  • event.idm.read_only_udm.additional
  • event.idm.graph.entity.additional
• Bevor Sie eine Anleitung zur Datenzuordnung erstellen, prüfen Sie, ob in Ihrer Google Security Operations-Instanz in den letzten 30 Tagen ursprüngliche Rohlogs für den Logtyp aufgenommen wurden und ob diese Rohlogs das Feld enthalten, das Sie in den Kriterien für die Vorbedingungen definieren möchten. Anhand dieser ursprünglichen Rohprotokolle werden die Anweisungen zur Datenzuordnung validiert.
• Sobald eine Parsererweiterung live geschaltet ist, beginnt sie mit dem Parsen eingehender Daten. Ich Logrohdaten können nicht rückwirkend geparst werden.

Lebenszyklus einer Parsererweiterung

Parser-Erweiterungen haben einen Lebenszyklus mit den folgenden Status:

• DRAFT: Neu erstellte Parsererweiterung, die noch nicht eingereicht wurde.
• VALIDATING: Google Security Operations validiert die Zuordnungsanleitung anhand von um sicherzustellen, dass Felder ohne Fehler geparst werden.
• LIVE: Die Parsererweiterung hat die Validierung bestanden und befindet sich nun in der Produktion. Es ist Daten aus eingehenden Rohdatenlogs extrahieren und in UDM-Einträge umwandeln.
• FAILED: Die Validierung der Parsererweiterung ist fehlgeschlagen.

Seite „Parser-Erweiterungen“ öffnen

Führen Sie die Schritte in einem der folgenden Abschnitte aus, um die Seite Parser-Erweiterungen aufzurufen.

Über die Navigationsleiste beginnen

1. Wählen Sie in der Navigationsleiste Settings (Einstellungen), SIEM Settings (SIEM-Einstellungen) und dann Parsers (Parser).
2. Identifizieren Sie den Logtyp, den Sie in der Tabelle Parsers erweitern möchten.
3. Gehen Sie zu dieser Zeile und klicken Sie auf das Menü.
4. Klicken Sie auf Erweiterung erstellen.

Mit Rohlogsuche beginnen

1. Verwenden Sie die Rohlogsuche für die Suche. für Datensätze, die denen ähneln, die geparst werden.
2. Wählen Sie im Bereich Ereignisse > Zeitachse ein Ereignis aus.
3. Maximieren Sie den Bereich Ereignisdaten.
4. Klicken Sie auf die Schaltfläche Parser verwalten.
5. Wählen Sie im Dialogfeld Parser verwalten die Option Erweiterung erstellen aus und klicken Sie dann auf Weiter. Die Seite Parser-Erweiterungen wird im Bearbeitungsmodus geöffnet. Sie können damit beginnen, parser-Erweiterung.

Neue Parsererweiterung erstellen

In diesem Abschnitt wird beschrieben, wie Sie eine Parsererweiterung erstellen, nachdem Sie die Seite „Parsererweiterungen“ geöffnet haben. Die verfügbaren Felder auf der Seite Parser Extensions unterscheiden sich je nach zur Struktur des Rohprotokolls.

1. Sehen Sie sich das Beispiel-Rohprotokoll im Bereich Raw Log (Raw-Log) an, um sicherzustellen, dass es sich um die für die von der Parser-Erweiterung verarbeiteten Logs stehen. Rohprotokoll aus dem Beispiel verwenden als Referenz verwendet werden.

   • Wenn Sie über die Suche nach Rohlogs zur Seite Parsererweiterungen gelangt sind, wird im Bereich das ursprüngliche Rohprotokoll angezeigt, das Sie in den Suchergebnissen ausgewählt haben.

   • auf der Seite Parser-Erweiterungen in der Navigationsleiste wird ein Rohlogbeispiel für diesen Logtyp angezeigt.

   Hinweis: Sie können Daten im Bereich Raw Log nicht bearbeiten. Sie können den Roh-Logstring über das Menü Ansicht und das Kästchen Text umbrechen formatieren.

2. Wählen Sie die Erweiterungsmethode aus. Entscheiden Sie sich für eine der folgenden Möglichkeiten:

   • Datenfelder zuordnen: Erstellen Sie eine Datenfeldzuordnung. Verwenden Sie die Anwendungsfelder, um das ursprüngliche Rohlogfeld und den „destination“ für UDM.

   • Code-Snippet schreiben: Erstellen Sie ein Code-Snippet für alle unterstützten Protokollformate. Das Code-Snippet verwendet die gleiche Parsersyntax wie Standard- und benutzerdefinierte Parser. Weitere Informationen zur Parsersyntax finden Sie unter Parsersyntax.

   Hinweis: Die Anleitung für die Zuordnung von Code-Snippets darf nicht mit dem Datenfeld kombiniert werden. Anleitung zur Kartenzuordnung.

Fahren Sie mit einem der folgenden Unterabschnitte fort, die sich auf die ausgewählte Erweiterungsmethode beziehen.

• Anleitung für die Zuordnung von Datenfeldern erstellen
• Anleitung zum Zuordnen von Code-Snippets erstellen

Anleitung für die Datenfeldzuordnung erstellen

Anweisung für die Zuordnung von Datenfeldern erstellen, wenn die eingehenden Rohlogs sind in JSON, XML, CSV, Syslog-Header plus JSON, Syslog-Header plus XML, oder Syslog-Header und CSV-Format. Pfad zum ursprünglichen Feld definieren Name und das UDM-Feld in der Anweisung zur Datenzuordnung.

1. Geben Sie in der Auswahl Wiederkehrende Felder an, wie die Parsererweiterung einen Wert speichert. die ein Array von Werten unterstützen.

   • Werte anfügen: Der Wert wird an das vorhandene Set von gespeicherten Werten angehängt. vor Ort.
   • Replace Values (Werte ersetzen): Der Wert ersetzt alle zuvor gespeicherten Werte durch den neuen Wert.

   Einige UDM-Felder, z. B. principal.ip und entity.asset.hostname ein Array von Werten speichern. Diese wiederkehrenden Felder sind in der Liste der Felder für einheitliche Datenmodelle mit dem Label repeated gekennzeichnet. Weitere Informationen finden Sie unter Auswahl wiederholter Felder.

   Wichtig :Die Anleitung für die Zuordnung von Datenfeldern darf nur dann wiederkehrende Felder enthalten, wenn die Das wiederkehrende Feld befindet sich auf der untersten Hierarchieebene. Sie können beispielsweise Werte dem wiederkehrenden Feld udm.principal.ip zuordnen, da sich ip auf der untersten Ebene der Hierarchie befindet und principal kein wiederkehrendes Feld ist. Sie können udm.intermediary.hostname keine Werte zuordnen, weil „intermediary“ ist ein wiederkehrendes Feld und befindet sich nicht auf der untersten Hierarchieebene.

2. Wenn die Felder Syslog und Target angezeigt werden, zeigt Google Security Operations hat festgestellt, dass das Rohprotokoll einen Syslog-Header enthält.

   Wenn Google Security Operations feststellt, dass das Rohprotokoll des Beispiels nicht nativ ist JSON, natives XML oder CSV und hat einen Syslog-Header, zeigt es das Syslog an. und Ziel. Verwenden Sie die folgenden Felder, um einen Grok und Muster für reguläre Ausdrücke zu definieren, die vorab verarbeitet werden. Syslog-Headers und extrahiert den strukturierten Teil des Protokoll. Der strukturierte Teil des Logs kann mithilfe von Datenfeldern zugeordnet werden.

   • Syslog-Feld: Geben Sie mithilfe von Grok und regulären Ausdrücken das Extraktionsmuster an, das identifiziert den Syslog-Header und die Rohprotokollnachricht.
   • Feld Ziel: Geben Sie im Extrahierungsmuster den Variablennamen an, in dem der strukturierte Teil des Logs gespeichert wird.

   Informationen zum Definieren eines Extraktionsmusters mit Grok und regulärem Ausdrücke finden Sie unter Syslog-Extrahiererfelder definieren.

   In der folgenden Abbildung sehen Sie ein Beispiel für das Hinzufügen eines Extraktionsmusters und eines Variablennamens in die Felder Syslog und Target.

   

   Sowohl das Feld Syslog als auch das Feld Ziel sind erforderlich und werden zusammen verwendet, um den Syslog-Header vom strukturierten Teil des Logs zu trennen.

3. Nachdem Sie Werte in die Felder Syslog und Target eingegeben haben, klicken Sie auf die Schaltfläche Validate (Validieren). Bei der Validierung wird sowohl auf Syntax- als auch auf Parsing-Fehler geprüft und dann eine der folgenden Optionen:

   • Erfolg: Die Datenzuordnungsfelder werden angezeigt. Definieren Sie den Rest der Parsererweiterung.
   • Fehler: Eine Fehlermeldung wird angezeigt. Korrigieren Sie die Fehlerbedingung, bevor Sie fortfahren.

4. Definieren Sie optional eine Vorbedingungsanweisung.

   Mit der Anweisung für die Vorbedingung wird nur eine Teilmenge der ursprünglichen Rohlogs identifiziert, die verarbeitet die Parser-Erweiterung einen statischen Wert mit einem Feld in den Rohdaten Protokoll. Wenn ein eingehendes Rohprotokoll die Kriterien der Vorbedingung erfüllt, d. h. die Werte übereinstimmen, wendet die Parsererweiterung die Zuordnungsanweisung an. Wenn die Werte nicht übereinstimmen, wendet die Parsererweiterung die Zuordnungsanweisung nicht an.

   Füllen Sie die folgenden Felder aus:

   • Voraussetzungsfeld: Geben Sie entweder den vollständigen Pfad zum Feld ein, wenn das Protokolldatenformat JSON oder XML ist, oder die Spaltenposition, wenn das Datenformat CSV ist.
   • Voraussetzungsoperator: Wählen Sie entweder EQUALS oder NOT EQUALS aus.
   • Vorbedingungswert: Geben Sie den Wert ein, der mit den Daten im Feld Vorbedingungsfeld.

5. Definieren Sie die Anweisung für die Datenzuordnung:

   • Feld für Rohdaten: Geben Sie entweder den vollständigen Pfad zum Feld ein, wenn das Protokolldatenformat JSON oder XML ist, oder die Spaltenposition, wenn das Datenformat CSV ist.
   • Zielfeld: Geben Sie den voll qualifizierten UDM-Feldnamen ein, in dem der Wert gespeichert werden soll, z. B. udm.metadata.collected_timestamp.seconds.
   Wichtig: Wenn das ursprüngliche Rohlog im JSON-Format vorliegt, wird der Datentyp des Der ursprüngliche Logwert muss mit dem Datentyp im Ziel-UDM-Feld übereinstimmen. Beispiel: Das ursprüngliche Protokoll zeichnet Pakete auf, die als String gesendet werden. ("packets_sent":"16") und Sie versuchen, dies dem UDM „network.sent_bytes“ zuzuordnen uint64-Datentyp enthält, schlägt die Anweisung fehl. Diese Anforderung gilt nicht für Protokolle im CSV- und XML-Format.

6. Klicken Sie auf Senden, um die Zuordnungsanweisung zu speichern.

7. Google Security Operations validiert die Zuordnungsanweisung.

   • Wenn die Validierung erfolgreich ist, ändert sich der Status in Live und die Zuordnung wird mit der Verarbeitung eingehender Protokolldaten beginnt.
   • Wenn der Überprüfungsprozess fehlschlägt, ändert sich der Status zu Fehlgeschlagen und im Feld „Raw Log“ wird ein Fehler angezeigt.
   Hinweis: Während eine Parsererweiterung validiert wird, können Sie die Daten nicht bearbeiten. Anleitung zur Zuordnung.

   Das folgende Beispiel zeigt einen Validierungsfehler.

   ERROR: generic::unknown: pipeline.ParseLogEntry failed: LOG_PARSING_CBN_ERROR:
   "generic::invalid_argument: pipeline failed: filter mutate (7) failed: copy failure:
   copy source field \"jsonPayload.dest_instance.region\" must not be empty
   (try using replace to provide the value before calling copy)
   
   "LOG: {"insertId":"14suym9fw9f63r","jsonPayload":{"bytes_sent":"492",
   "connection":{"dest_ip":"10.12.12.33","dest_port":32768,"protocol":6,
   "src_ip":"10.142.0.238","src_port":22},"end_time":"2023-02-13T22:38:30.490546349Z",
   "packets_sent":"15","reporter":"SRC","src_instance":{"project_id":"example-labs",
   "region":"us-east1","vm_name":"example-us-east1","zone":"us-east1-b"},
   "src_vpc":{"project_id":"example-labs","subnetwork_name":"default",
   "vpc_name":"default"},"start_time":"2023-02-13T22:38:29.024032655Z"},
   "logName":"projects/example-labs/logs/compute.googleapis.com%2Fvpc_flows",
   "receiveTimestamp":"2023-02-13T22:38:37.443315735Z","resource":{"labels":
   {"location":"us-east1-b","project_id":"example-labs",
     "subnetwork_id":"00000000000000000000","subnetwork_name":"default"},
     "type":"gce_subnetwork"},"timestamp":"2023-02-13T22:38:37.443315735Z"}
   

Unter Felder in einer Datenzuordnungsanweisung finden Sie eine Liste aller möglicher Felder in einer Parser-Erweiterung.

Felder in einer Datenzuordnungsanweisung

In diesem Abschnitt werden alle Felder beschrieben, die in einer Parsererweiterung festgelegt werden können.

Feldname	Beschreibung
Syslog	Benutzerdefiniertes Muster, das ein Syslog vorverarbeitet und trennt aus dem strukturierten Teil eines Rohprotokolls.
Ziel-	Variablenname im Feld Syslog, in dem der Wert für strukturierter Teil des Protokolls.
Vorbedingungsfeld	Feldkennung im Rohlog, das den zu vergleichenden Wert enthält. Gebraucht in einer Bedingungsanweisung.
Vorbedingungsoperator	Wählen Sie entweder EQUALS oder NOT EQUALS aus. Gebraucht in einer Bedingungsanweisung.
Vorbedingungswert	Der statische Wert, der mit dem Vorbedingungsfeld im Rohlog verglichen wird. Wird in einer Anweisung für eine Vorbedingung verwendet.
Rohdatenfeld	Wird in einer Zuordnungsanweisung verwendet. Wenn das Datenformat JSON ist, definieren Sie den Pfad zum Feld, zum Beispiel: jsonPayload.connection.dest_ip Wenn das Datenformat XML ist, definieren Sie den vollständigen Pfad zum Feld, z. B.: /Event/Reason-Code. Wenn das Datenformat CSV ist, definieren Sie die Indexposition der Spalte. Indexpositionen beginnen bei 1.
Feld „Ziel“	Wird in einer Zuordnungsanweisung verwendet. Definieren Sie den vollständigen Pfad zum UDM-Feld, in dem die Daten gespeichert werden. Beispiel: udm.network.dhcp.opcode oder graph.entity.asset.hostname

Anleitung für die Zuordnung von Code-Snippets erstellen

Ein Code-Snippet verwendet eine Logstash-ähnliche Syntax, um zu definieren, wie Werte extrahiert und transformiert werden. im ursprünglichen Rohlog und weisen sie dem UDM-Eintrag zu. Ein Code-Snippet verwendet Syntax und Abschnitte der Anweisung wie ein Standard- oder benutzerdefinierter Parser. Ein Code-Snippet enthält die folgenden Abschnitte:

• Bereich 1. Extrahieren Sie die Daten aus dem ursprünglichen Protokoll.
• Bereich 2. Transformieren Sie die extrahierten Daten.
• Bereich 3. Weisen Sie einem UDM-Feld einen oder mehrere Werte zu.
• Bereich 4. Binden Sie UDM-Ereignisfelder an den Schlüssel @output.

Das folgende Beispiel zeigt ein Code-Snippet.

Hier ein Beispiel für ein Rohprotokoll:

{
    "insertId": "00000000",
    "jsonPayload": {
        ...section omitted for brevity...
        "packets_sent": "4",
        ...section omitted for brevity...
    },
    "timestamp": "2022-05-03T01:45:00.150614953Z"
}

Hier ist ein Beispielcode-Snippet, das den Wert in jsonPayload.packets_sent das UDM-Feld network.sent_bytes.

mutate {
 replace => {
    "jsonPayload.packets_sent" => ""
 }
}

filter {
    # Section 1. extract the data from the original JSON log
    json {
        source => "message"
        array_function => "split_columns"
        on_error => "_not_json"
    }

    if [_not_json] {
        drop {
            tag => "TAG_UNSUPPORTED"
        }

    } else {
        # Section 2. transform the extracted data
        if [jsonPayload][packets_sent] not in ["",0] {
            mutate {
                convert => {
                    "jsonPayload.packets_sent" => "uinteger"
                }
            }

            # Section 3. assign the value to a UDM field
            mutate {
                copy => {
                    "udm.network.sent_bytes" => "jsonPayload.packets_sent"
                }
                on_error => "_exception"
            }

            if ![_exception] {
                # Section 4. Bind the UDM fields to the @output key
                mutate {
                    merge => {
                        "@output" => "event"
                    }
                }
            }
        }
    }
}

Hinweis: Wenn Sie im Code-Snippet zwei separate Ereignisse definieren und zwei Ausgabeanweisungen erstellen, speichert die Parsererweiterung Felder in beiden Ereignissen im einzelnen UDM-Eintrag.

1. Klicken Sie auf Senden, um die Zuordnungsanweisung zu speichern.

2. Google Security Operations validiert die Zuordnungsanweisung.

   • Wenn die Validierung erfolgreich ist, ändert sich der Status in Live und die Zuordnung wird mit der Verarbeitung eingehender Protokolldaten beginnt.
   • Wenn der Überprüfungsprozess fehlschlägt, ändert sich der Status zu Fehlgeschlagen und im Feld „Raw Log“ wird ein Fehler angezeigt.
   Hinweis: Während eine Parsererweiterung validiert wird, können Sie die Daten nicht bearbeiten. Anleitung zur Zuordnung.

Vorhandene Parsererweiterung ansehen

1. Wählen Sie in der Navigationsleiste Settings (Einstellungen), SIEM Settings (SIEM-Einstellungen) und dann Parsers (Parser).
2. Ermitteln Sie in der Parser-Liste den Logtyp mit einer Parser-Erweiterung. Dies wird identifiziert mit dem Text EXTENSION neben dem Namen.
3. Rufen Sie diese Zeile auf und klicken Sie auf das  Menü.
4. Klicken Sie auf Erweiterung ansehen.
5. Parser View Custom/Prebuilt > Der Tab „Erweiterung“ mit Details zur Parser-Erweiterung wird angezeigt. Im Bereich „Zusammenfassung“ wird standardmäßig die LIVE-Parsererweiterung angezeigt.

Parsererweiterung bearbeiten

1. Öffnen Sie View Custom/Prebuilt Parser (Benutzerdefinierten/vordefinierten Parser anzeigen) > Tab „Erweiterung“: Weitere Informationen finden Sie unter Vorhandene Parsererweiterung ansehen für wie die Seite geöffnet werden kann.
2. Klicken Sie auf die Schaltfläche Erweiterung bearbeiten. Die Seite Parser Extensions wird angezeigt.
3. Bearbeiten Sie die Paser-Erweiterung.
   • Wenn Sie die Bearbeitung abbrechen und die Änderungen verwerfen möchten, klicken Sie auf Entwurf verwerfen.
4. Wenn Sie die Parsererweiterung fertig bearbeitet haben, klicken Sie auf Senden.

5. Wenn Sie die Änderung senden, wird die neue Konfiguration validiert.

   Hinweis: Während eine Parsererweiterung validiert wird, können Sie keine Daten bearbeiten. Anleitung zur Kartenerstellung.

Parsererweiterung löschen

1. Öffnen Sie View Custom/Prebuilt Parser (Benutzerdefinierten/vordefinierten Parser anzeigen) > Tab „Erweiterung“: Eine Anleitung finden Sie unter Vorhandene Parsererweiterung aufrufen. zum Öffnen dieser Seite.

2. Klicken Sie auf die Schaltfläche Erweiterung bearbeiten. Die Seite Parser Extensions wird angezeigt.

3. Klicken Sie auf die Schaltfläche Erweiterung löschen.

Wenn Sie eine Parsererweiterung bearbeiten, können Sie sie jederzeit löschen. Klicken Sie auf eine der folgenden Optionen:

• Entwurf verwerfen
• Fehlgeschlagene Erweiterung löschen

Weitere Informationen zur Auswahl für wiederkehrende Felder

Einige UDM-Felder speichern ein Array von Werten, z. B. principal.ip und Entity.asset.hostname Wenn Sie eine Parsererweiterung erstellen, um Daten in einem wiederholten Feld zu speichern, können Sie steuern, ob der Wert an das Array angehängt wird ersetzt alle vorhandenen Werte, die vom Standardparser festgelegt wurden. Wiederkehrende Felder werden identifiziert durch das Label, das in der Feldliste für einheitliche Datenmodelle wiederholt wird.

Wenn Werte anhängen ausgewählt ist, hängt die Parsererweiterung den extrahierten Wert an das Array der vorhandenen Werte im UDM-Feld an. Wenn Werte ersetzen ausgewählt ist, ersetzt die Parsererweiterung das Array der vorhandenen Werte im UDM-Feld durch den extrahierten Wert. Bei der Auswahl Wiederkehrende Felder beeinflussen, wie Daten in Feldern gespeichert werden, die sich nicht wiederholen.

Eine Parsererweiterung kann nur dann Daten einem wiederkehrenden Feld zuordnen, wenn der Das wiederkehrende Feld befindet sich auf der untersten Hierarchieebene. Zum Beispiel ist die Zuordnung wird als Wert für udm.principal.ip unterstützt, da sich das wiederholte Feld ip an dieser Position befindet: der untersten Hierarchieebene und principal ist kein wiederkehrendes Feld. Die Zuordnung von Werten zu udm.intermediary.hostname wird aus folgendem Grund nicht unterstützt: „intermediary“ ist ein wiederkehrendes Feld und befindet sich nicht auf der untersten Hierarchieebene.

Die folgende Tabelle enthält Beispiele für die Konfiguration von Wiederkehrenden Feldern. wirkt sich auf den generierten UDM-Eintrag aus.

Auswahl von Wiederkehrenden Feldern	Beispielprotokoll	Konfiguration der Parsererweiterung	Generiertes Ergebnis
Werte anhängen	{"protoPayload":{"@type":"type.AuditLog","authenticationInfo":{"principalEmail":"[e-mail]"},"requestMetadata":{"callerIp":"1.1.1.1, 2.2.2.2"}}}	Vorbedingungsfeld: protoPayload.requestMetadata.callerIp Vorbedingungswert: " " Operator für Vorbedingung: NOT_EQUALS Rohdatenfeld: protoPayload.requestMetadata.callerIp Zielfeld: event.idm.read_only_udm.principal.ip	metadata:{event_timestamp:{}.....}principal:{Ip:"1.1.1.1, 2.2.2.2"} } }
Werte anhängen	{"protoPayload":{"@type":"type.AuditLog","authenticationInfo":{"principalEmail":"[e-mail]"},"requestMetadata":{"callerIp":"2.2.2.2, 3.3.3.3", "name":"Akamai Ltd"}}}	Bedingung 1: Bedingungsfeld:protoPayload.requestMetadata.callerIp Bedingungswert: " " Bedingungsoperator: NOT_EQUALS Feld mit Rohdaten: protoPayload.requestMetadata.callerIp Zielfeld: event.idm.read_only_udm.principal.ip Voraussetzung 2: Rohdatenfeld: protoPayload.requestMetadata.name Zielfeld: event.idm.read_only_udm.metadata.product_name	Vom vordefinierten Parser generierte Ereignisse, bevor die Erweiterung angewendet wird. metadata:{event_timestamp:{} ... principal:{ip:"1.1.1.1"}}} Ausgabe nach Anwendung der Erweiterung timestamp:{} idm:{read_only_udm:{metadata:{event_timestamp:{} .... product_name: "Akamai Ltd"}principal:{ip:"1.1.1.1, 2.2.2.2, 3.3.3.3"}}}
Werte ersetzen	{"protoPayload":{"@type":"type..AuditLog","authenticationInfo":{"principalEmail":"[e-mail]"},"requestMetadata":{"callerIp":"2.2.2.2"}}}	Bedingungsfeld: protoPayload.authenticationInfo.principalEmail Bedingungswert: " " Bedingungsoperator: NOT_EQUALS Feld mit Rohdaten: protoPayload.authenticationInfo.principalEmail Zielfeld: event.idm.read_only_udm.principal.ip	UDM-Ereignisse, die vom vordefinierten Parser vor der Anwendung der Erweiterung generiert wurden. timestamp:{} idm:{read_only_udm:{metadata:{event_timestamp:{} ... principal:{ip:"1.1.1.1"}}} UDM-Ausgabe nach Anwendung der Erweiterung timestamp:{} idm:{read_only_udm:{metadata:{event_timestamp:{} ....} principal:{ip:"2.2.2.2"}}}

Weitere Informationen zu den Feldern des Syslog-Extractors

Mit den Syslog-Extraktorfeldern können Sie den Syslog-Header von einem strukturierten Protokoll trennen indem Sie den regulären Ausdruck „Grok“ sowie ein benanntes Token im Muster des regulären Ausdrucks definieren, um die Ausgabe zu speichern.

Syslog-Extraktorfelder definieren

Die Werte in den Feldern Syslog und Target legen gemeinsam fest, wie die Parsererweiterung den Syslog-Header vom strukturierten Teil eines Rohlogs trennt. Im Feld Syslog definieren Sie einen Ausdruck mit einer Kombination aus Grok und Syntax für reguläre Ausdrücke. Der Ausdruck enthält einen Variablennamen, der den Teil des Rohprotokolls. Geben Sie im Feld Ziel den Namen der Variablen an.

Das folgende Beispiel zeigt, wie diese Felder zusammenwirken.

Hier ein Beispiel für ein Rohprotokoll:

<13>1 2022-09-14T15:03:04+00:00 fieldname fieldname - - - {"timestamp": "2021-03-14T14:54:40.842152+0000","flow_id": 1885148860701096, "src_ip": "10.11.22.1","src_port": 51972,"dest_ip": "1.2.3.4","dest_port": 55291,"proto": "TCP"}

Das Rohlog enthält die folgenden Abschnitte:

• Syslog-Header: <13> 2022-09-14T15:03:04+00:00 fieldname fieldname - - -

• Ereignis im JSON-Format: {"timestamp": "2021-03-14T14:54:40.842152+0000","flow_id": 1885148860701096, "src_ip": "10.11.22.1","src_port": 51972,"dest_ip": "1.2.3.4","dest_port": 55291,"proto": "TCP"}

So trennen Sie den Syslog-Header vom JSON-Teil des Rohlogs: Beispielausdruck im Feld Syslog: %{TIMESTAMP_ISO8601} %{WORD} %{WORD} ([- ]+)?%{GREEDYDATA:msg}

• Dieser Teil des Ausdrucks identifiziert den Syslog-Header: %{TIMESTAMP\_ISO8601} %{WORD} %{WORD} ([- ]+)?
• Dieser Teil des Ausdrucks erfasst das JSON-Segment des Rohlogs: %{GREEDYDATA:msg}

Dieses Beispiel enthält den Variablennamen msg. Sie wählen den Variablennamen aus. Die Parsererweiterung extrahiert das JSON-Segment aus dem Rohprotokoll und weist es der Variablen msg zu.

Wichtig: Der Wert message ist reserviert und kann nicht als Variablenname verwendet werden. Beim Validieren des Ausdrucks wird ein Fehler zurückgegeben.

Geben Sie in das Feld Ziel den Variablennamen msg ein. Der in der Variablen msg gespeicherte Wert wird in die Anweisungen zur Datenfeldzuordnung eingegeben, die Sie in der Parsererweiterung erstellen.

Anhand des Beispiel-Log wird das folgende Segment in die Anweisung zum Datenabgleich eingegeben:

{"timestamp": "2021-03-14T14:54:40.842152+0000","flow_id": 1885148860701096, "src_ip": "10.11.22.1","src_port": 51972,"dest_ip": "1.2.3.4","dest_port": 55291,"proto": "TCP"}

In der folgenden Abbildung sind die ausgefüllten Felder Syslog und Target zu sehen:

Die folgende Tabelle enthält weitere Beispiele mit Beispielprotokollen, dem Syslog-Extraktionsmuster, dem Variablennamen Target und dem Ergebnis.

Beispiel-Rohprotokoll	Syslog-Feld	Zielfeld	Ergebnis
<13>1 2022-07-14T15:03:04+00:00 suricata suricata - - - {\"timestamp\": \"2021-03-14T14:54:40.842152+0000\",\"flow_id\": 1885148860701096,\"in_iface\": \"enp94s0\",\"event_type\": \"alert\",\"vlan\": 522,\"src_ip\": \"1.1.2.1\",\"src_port\": 51972,\"dest_ip\": \"1.2.3.4\",\"dest_port\": 55291,\"proto\": \"TCP\"}"	%{TIMESTAMP_ISO8601} %{WORD} %{WORD} ([- ]+)?%{GREEDYDATA:msg}	msg	field_mappings { field: "msg" value: "{\"timestamp\": \"2021-03-14T14:54:40.842152+0000\",\"flow_id\": 1885148860701096,\"in_iface\": \"enp94s0\",\"event_type\": \"alert\",\"vlan\": 522,\"src_ip\": \"1.1.2.1\",\"src_port\": 51972,\"dest_ip\": \"1.2.3.4\",\"dest_port\": 55291,\"proto\": \"TCP\"}" }
<13>1 2022-07-14T15:03:04+00:00 suricata suricata - - - {\"timestamp\": \"2021-03-14T14:54:40.842152+0000\"} - - - {\"timestamp\": \"2021-03-14T14:54:40.842152+0000\",\"flow_id\": 1885148860701096,\"in_iface\": \"enp94s0\",\"event_type\": \"alert\",\"vlan\": 522,\"src_ip\": \"1.1.2.1\",\"src_port\": 51972,\"dest_ip\": \"1.2.3.4\",\"dest_port\": 55291,\"proto\": \"TCP\"}	%{TIMESTAMP_ISO8601} %{WORD} %{WORD} ([- ]+)?%{GREEDYDATA:msg1} ([- ]+)?%{GREEDYDATA:msg2}	msg2	field_mappings { field: "msg2" value: "{\"timestamp\": \"2021-03-14T14:54:40.842152+0000\",\"flow_id\": 1885148860701096,\"in_iface\": \"enp94s0\",\"event_type\": \"alert\",\"vlan\": 522,\"src_ip\": \"1.1.2.1\",\"src_port\": 51972,\"dest_ip\": \"1.2.3.4\",\"dest_port\": 55291,\"proto\": \"TCP\"}" }
"<13>1 2022-07-14T15:03:04+00:00 suricata suricata - - - {\"timestamp\": \"2021-03-14T14:54:40.842152+0000\"} - - - {\"timestamp\": \"2021-03-14T14:54:40.842152+0000\",\"flow_id\": 1885148860701096,\"in_iface\": \"enp94s0\",\"event_type\": \"alert\",\"vlan\": 522,\"src_ip\": \"1.1.2.1\",\"src_port\": 51972,\"dest_ip\": \"1.2.3.4\",\"dest_port\": 55291,\"proto\": \"TCP\"}"	%{TIMESTAMP_ISO8601} %{WORD} %{WORD} ([- ]+)?%{GREEDYDATA:message} ([- ]+)?%{GREEDYDATA:msg2}	msg2	Error - message already exists in state and not overwritable.

Zugriff auf Parsererweiterungen steuern

Es sind neue Berechtigungen verfügbar, die steuern, wer den Parser aufrufen und verwalten kann Erweiterungen. Standardmäßig können Nutzer mit der Rolle Administrator auf Parsererweiterungen zugreifen. Weitere Informationen zum Verwalten von Nutzern und Gruppen oder das Zuweisen von Rollen finden Sie unter Rollenbasierte Zugriffssteuerung .

Die neuen Rollen in Google Security Operations sind in der folgenden Tabelle zusammengefasst.

Feature	Aktion	Beschreibung
Parser	Löschen	Parsererweiterungen löschen.
Parser	Bearbeiten	Parsererweiterungen erstellen und bearbeiten.
Parser	Ansehen	Sehen Sie sich Parsererweiterungen an.