Parsererweiterungen verwenden

Unterstützt in:

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

  • Standardparser: Von Google Security Operations verwaltete vordefinierte Datenzuordnungsanweisungen, die die ursprünglichen Roh-Logdaten den UDM-Feldern zuordnen.
  • Benutzerdefinierte Parser: Benutzerdefinierte Datenzuordnungsanweisungen, die von einem Kunden erstellt und verwaltet werden und den spezifischen Anforderungen des Kunden beim Parsen von Daten entsprechen.
  • Parsererweiterungen: Zusätzliche Anweisungen zur Datenzuordnung, mit denen ein Standard- oder benutzerdefinierter Parser erweitert wird, um zusätzliche Felder im ursprünglichen Rohprotokoll zuzuordnen. Dadurch wird ein Standard- oder benutzerdefinierter Parser nicht vollständig ersetzt, sondern die vorhandenen Zuordnungsanweisungen in einem Standard- oder benutzerdefinierten Parser werden erweitert.

In diesem Dokument wird beschrieben, wie Sie Parsererweiterungen verwenden.

Hinweise

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

Parsererweiterungen

Mit einer Parsererweiterung können Sie zusätzliche Zuordnungsanweisungen erstellen, die über die in einem Standard- oder benutzerdefinierten Parser definierten hinausgehen, um einen bestimmten 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 ein. Der UDM-Eintrag enthält Daten, die sowohl vom Standard- oder benutzerdefinierten Parser als auch von der Parsererweiterung festgelegt werden.

Anweisungen zur Datenzuordnung in einer Parsererweiterung haben Vorrang vor denen in einem Standard- oder 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 beispielsweise ein Rohlogs-Feld dem UDM-Feld event.metadata.description zuordnet und die Parsererweiterung ein anderes Rohlogs-Feld demselben UDM-Feld zuordnet, überschreibt die Parsererweiterung den vom Standardparser festgelegten Wert. Eine Ausnahme bilden wiederkehrende Felder. Sie können die Parsererweiterung so konfigurieren, dass Werte angehängt werden, wenn Daten in ein wiederholtes Feld geschrieben werden.

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

Um eine Parsererweiterung zu erstellen, müssen die Sicherheitsteams von Google die ursprünglichen Rohlogs mit einem Standard- oder benutzerdefinierten Parser aufnehmen und normalisieren können. Die Parsererweiterung extrahiert zusätzliche Daten aus dem ursprünglichen Rohprotokoll und fügt sie dann dem UDM-Eintrag hinzu.

Parsererweiterungen unterstützen die folgenden Arten von Zuordnungsanweisungen:

  • Code-Snippet-Typ: Sie schreiben Parser-Code ähnlich wie bei Standard- und benutzerdefinierten Parsern. Die ursprünglichen Rohprotokolle können in einem beliebigen der unterstützten Datenformate für den Protokolltyp vorliegen.
  • Datenfeldtyp: Sie geben die Quell- und Zielfelder in der Anwendungsoberfläche an. Die ursprünglichen Rohprotokolle müssen in einem der folgenden Formate vorliegen:
    • Natives JSON, natives XML oder CSV.
    • Syslog-Header sowie natives JSON, natives XML oder CSV. Unter Unterstützte Standardparser können Sie eine Anleitung zum Zuordnen von Datenfeldtypen für eine Teilmenge der Protokolltypen erstellen. Suchen Sie nach Dateien 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 wiederkehrende Werte unterstützt.
  • 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 ist, werden eingehende Daten geparst. Roh-Logdaten können nicht rückwirkend geparst werden.

Lebenszyklus einer Parsererweiterung

Parsererweiterungen haben einen Lebenszyklus mit den folgenden Status:

  • DRAFT: Eine neu erstellte Parsererweiterung, die noch nicht eingereicht wurde.
  • VALIDATING: Google Security Operations prüft die Zuordnungsanleitung anhand vorhandener Rohlogs, um sicherzustellen, dass Felder ohne Fehler geparst werden.
  • LIVE: Die Parsererweiterung hat die Validierung bestanden und wird jetzt in der Produktionsumgebung verwendet. Es werden Daten aus eingehenden Rohlogs extrahiert und in UDM-Einträge umgewandelt.
  • 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 Parsererweiterungen aufzurufen.

Über die Navigationsleiste

  1. Wählen Sie in der Navigationsleiste Einstellungen, SIEM-Einstellungen und dann Parser aus.
  2. Geben Sie in der Tabelle Parser den Log-Typ an, den Sie erweitern möchten.
  3. Rufen Sie diese Zeile auf und klicken Sie auf das Menü.
  4. Klicken Sie auf Erweiterung erstellen.
  1. Verwenden Sie die Suche in Rohlogs, um nach Einträgen zu suchen, die denen ähneln, die geparst werden sollen.
  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 auf Weiter. Die Seite Parsererweiterungen wird im Bearbeitungsmodus geöffnet. Sie können mit der Definition der Parsererweiterung beginnen.

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 Parsererweiterungen unterscheiden sich je nach Struktur des Rohlogs.

  1. Prüfen Sie im Bereich Raw Log (Raw-Log), ob das Beispiel für ein Rohzeichen repräsentativ für die Logs ist, die von der Parsererweiterung verarbeitet werden. Verwenden Sie das Beispiel-Log als Referenz, wenn Sie die Parsererweiterung erstellen.

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

    • Wenn Sie in der Navigationsleiste die Seite Parsererweiterungen aufgerufen haben, wird ein Beispiel-Nutzungsprotokoll für diesen Protokolltyp angezeigt.

  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 Feld im Rohprotokoll und das Ziel-UDM-Feld zu definieren.

    • Code-Snippet schreiben: Erstellen Sie ein Code-Snippet für alle unterstützten Protokollformate. Für das Code-Snippet wird dieselbe Parser-Syntax wie für Standard- und benutzerdefinierte Parser verwendet. Weitere Informationen zur Parsersyntax finden Sie unter Parsersyntax.

Fahren Sie mit einem der folgenden Abschnitte fort, die speziell auf die ausgewählte Erweiterungsmethode zugeschnitten sind.

Anleitung für die Datenfeldzuordnung erstellen

Erstellen Sie eine Anleitung zur Datenfeldzuordnung, wenn die eingehenden Rohlogs im JSON-, XML-, CSV-, Syslog-Header-plus-JSON-, Syslog-Header-plus-XML- oder Syslog-Header-plus-CSV-Format vorliegen. Definieren Sie in der Anleitung zur Datenzuordnung den Pfad zum ursprünglichen Feldnamen und zum Ziel-UDM-Feld.

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

    • Werte anhängen: Der Wert wird an die im Feld gespeicherten Werte angehängt.
    • Werte ersetzen: Der Wert ersetzt alle zuvor gespeicherten Werte durch den neuen Wert.

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

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

    Wenn das Google Security Operations-Team feststellt, dass das Beispiel-Raw-Log kein natives JSON-, XML- oder CSV-Log ist und einen Syslog-Header hat, werden die Felder Syslog und Ziel angezeigt. Verwenden Sie die folgenden Felder, um Grok- und reguläre Ausdrucksmuster zu definieren, mit denen die Syslog-Header vorverarbeitet und der strukturierte Teil des Logs extrahiert wird. Der strukturierte Teil des Logs kann mithilfe von Datenfeldern zugeordnet werden.

    • Feld Syslog: Geben Sie das Extraktionsmuster mit Grok und regulären Ausdrücken an, das den Syslog-Header und die Rohprotokollnachricht identifiziert.
    • 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ären Ausdrücken finden Sie unter Felder für den Syslog-Extractor definieren.

    Das folgende Bild zeigt ein Beispiel dafür, wie Sie den Feldern Syslog und Ziel jeweils ein Extraktionsmuster und einen Variablennamen hinzufügen.

    Felder des Syslog-Extractors

    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 Ziel eingegeben haben, klicken Sie auf die Schaltfläche Validieren. Bei der Validierung wird sowohl auf Syntax- als auch auf Parsefehler geprüft. Anschließend wird einer der folgenden Werte zurückgegeben:

    • Erfolgreich: Die Felder für die Datenzuordnung werden angezeigt. Definieren Sie den Rest der Parsererweiterung.
    • Fehler: Es wird eine Fehlermeldung angezeigt. Beheben Sie die Fehlerbedingung, bevor Sie fortfahren.

  4. Optional können Sie eine Anweisung für die Vorbedingung definieren.

    Die Anweisung für die Vorbedingung identifiziert nur einen Teil der ursprünglichen Rohprotokolle, die von der Parsererweiterung verarbeitet werden, indem ein statischer Wert mit einem Feld im Rohprotokoll abgeglichen wird. Wenn ein eingehendes Rohprotokoll die Kriterien für die 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.
    • Voraussetzungswert: Geben Sie den Wert ein, der mit den Daten im Voraussetzungsfeld übereinstimmen muss.

  5. Definieren Sie die Datenzuordnungsanweisung:

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

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

  7. Google Security Operations überprüft die Zuordnungsanleitung.

    • Wenn die Validierung erfolgreich ist, ändert sich der Status in Live und die Zuordnungsanleitung beginnt mit der Verarbeitung eingehender Protokolldaten.
    • Wenn der Überprüfungsvorgang fehlschlägt, ändert sich der Status zu Fehlgeschlagen und im Feld „Raw Log“ wird ein Fehler angezeigt.

    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"}

Eine Liste aller möglichen Felder in einer Parsererweiterung finden Sie unter Felder in einer Datenabgleichsanleitung.

Felder in einer Anleitung zum Datenabgleich

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

Feldname Beschreibung
Syslog Ein benutzerdefiniertes Muster, mit dem ein Syslog-Header vorverarbeitet und vom strukturierten Teil eines Rohlogs getrennt wird.
Ziel- Variablenname im Feld Syslog, in dem der strukturierte Teil des Logs gespeichert wird.
Voraussetzungsfeld Feld-ID im Rohprotokoll, die den zu vergleichenden Wert enthält. Wird in einer Anweisung für eine Vorbedingung verwendet.
Voraussetzungsoperator Wählen Sie entweder EQUALS oder NOT EQUALS aus. Wird in einer Anweisung für eine Vorbedingung verwendet.
Wert der Bedingung Der statische Wert, der mit dem Vorbedingungs-Feld im Rohprotokoll verglichen wird. Wird in einer Anweisung für eine Vorbedingung verwendet.
Feld für Rohdaten

Wird in einer Zuordnungsanleitung verwendet.

Wenn das Datenformat JSON ist, definieren Sie den Pfad zum Feld, z. B.: 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.

Zielfeld

Wird in einer Zuordnungsanleitung verwendet.

Geben Sie den vollständigen Pfad zum UDM-Feld an, in dem die Daten gespeichert werden. Beispiel:

udm.network.dhcp.opcode

oder

graph.entity.asset.hostname

Anleitung zum Zuordnen von Code-Snippets erstellen

In einem Code-Snippet wird mit einer Logstash-ähnlichen Syntax definiert, wie Werte im ursprünglichen Rohprotokoll extrahiert und transformiert und dem UDM-Eintrag zugewiesen werden. Ein Code-Snippet verwendet dieselbe Syntax und dieselben Anweisungsabschnitte wie ein Standard- oder benutzerdefinierter Parser. Ein Code-Snippet besteht aus den folgenden Abschnitten:

  • 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.
  • Abschnitt 4. Verknüpfen Sie UDM-Ereignisfelder mit dem 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 ein Beispielcode-Snippet, in dem der Wert in jsonPayload.packets_sent dem UDM-Feld network.sent_bytes zugeordnet wird.

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"
                    }
                }
            }
        }
    }
}

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

  2. Google Security Operations überprüft die Zuordnungsanleitung.

    • Wenn die Validierung erfolgreich ist, ändert sich der Status in Live und die Zuordnungsanleitung beginnt mit der Verarbeitung eingehender Protokolldaten.
    • Wenn der Überprüfungsvorgang fehlschlägt, ändert sich der Status zu Fehlgeschlagen und im Feld „Raw Log“ wird ein Fehler angezeigt.

Vorhandene Parsererweiterung ansehen

  1. Wählen Sie in der Navigationsleiste Einstellungen, SIEM-Einstellungen und dann Parser aus.
  2. Ordnen Sie in der Liste der Parser dem Logtyp eine Parsererweiterung zu. Sie erkennen sie am Text EXTENSION neben dem Namen.
  3. Rufen Sie diese Zeile auf und klicken Sie auf das Menü.
  4. Klicken Sie auf Erweiterung ansehen.
  5. Der Parser Benutzerdefinierte/vordefinierte Parser ansehen > Tab „Erweiterung“ wird mit Details zur Parsererweiterung angezeigt. Im Bereich „Zusammenfassung“ wird standardmäßig die LIVE-Parsererweiterung angezeigt.

Parsererweiterung bearbeiten

  1. Öffnen Sie Benutzerdefinierten/vordefinierten Parser ansehen > Tab „Erweiterung“. Eine Anleitung zum Öffnen der Seite finden Sie unter Vorhandene Parsererweiterung aufrufen.
  2. Klicken Sie auf die Schaltfläche Erweiterung bearbeiten. Die Seite Parsererweiterungen wird angezeigt.
  3. Bearbeiten Sie die Parsererweiterung.
    • 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 einreichen, wird die neue Konfiguration validiert.

Parsererweiterung löschen

  1. Öffnen Sie Benutzerdefinierten/vordefinierten Parser ansehen > Tab „Erweiterung“. Eine Anleitung zum Öffnen dieser Seite finden Sie unter Vorhandene Parsererweiterung aufrufen.

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

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

Sie können eine Parsererweiterung beim Bearbeiten jederzeit löschen. Klicken Sie auf eine der folgenden Optionen:

  • Entwurf verwerfen
  • Fehlgeschlagene Erweiterung löschen

Weitere Informationen zur Auswahl für wiederkehrende Felder

In einigen UDM-Feldern wird ein Array von Werten gespeichert, z. B. principal.ip und Entity.asset.hostname. Wenn Sie eine Parsererweiterung zum Speichern von Daten in einem wiederkehrenden Feld erstellen, können Sie mit dieser Option festlegen, ob der Wert an das Array angehängt oder alle vorhandenen Werte ersetzt werden, die vom Standardparser festgelegt wurden. Wiederkehrende Felder werden anhand des Labels identifiziert, das in der Liste der Felder 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. Die Auswahl Wiederkehrende Felder hat keinen Einfluss darauf, wie Daten in Feldern gespeichert werden, die nicht wiederholt werden.

Eine Parsererweiterung kann Daten nur dann einem wiederkehrenden Feld zuordnen, wenn sich das wiederkehrende Feld auf der untersten Ebene der Hierarchie befindet. Beispielsweise wird die Zuordnung von Werten zu udm.principal.ip unterstützt, da sich das wiederholte Feld ip auf der untersten Ebene der Hierarchie befindet und principal kein wiederholtes Feld ist. Die Zuordnung von Werten zu udm.intermediary.hostname wird nicht unterstützt, da intermediary ein wiederkehrendes Feld ist und sich nicht auf der untersten Ebene der Hierarchie befindet.

Die folgende Tabelle enthält Beispiele dafür, wie sich die Konfiguration Wiederkehrende Felder auf den generierten UDM-Datensatz auswirkt.

Auswahl Wiederkehrende Felder Beispiel für ein Protokoll Konfiguration der Parsererweiterung Generiertes Ergebnis
Werte anhängen {"protoPayload":{"@type":"type.AuditLog","authenticationInfo":{"principalEmail":"admin@cmmar.co"},"requestMetadata":{"callerIp":"1.1.1.1, 2.2.2.2"}}} Bedingungsfeld: protoPayload.requestMetadata.callerIp
Bedingungswert: " "
Bedingungsoperator: NOT_EQUALS
Feld mit Rohdaten: 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":"admin@cmmar.co"},"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

Vorbedingung 2:
Feld mit Rohdaten: protoPayload.requestMetadata.name
Zielfeld: event.idm.read_only_udm.metadata.product_name

 Ereignisse, die vom vordefinierten Parser vor der Anwendung der Erweiterung generiert wurden.
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":"admin@cmmar.co"},"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 Feldern für den Syslog-Extractor können Sie den Syslog-Header von einem strukturierten Log trennen. Dazu definieren Sie den Grok-Regulären Ausdruck und ein benanntes Token im regulären Ausdrucksmuster, um die Ausgabe zu speichern.

Felder für den Syslog-Extractor 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 regulärer Ausdruckssyntax. Der Ausdruck enthält einen Variablennamen, der den strukturierten Teil des Rohlogs angibt. Geben Sie diesen Variablennamen im Feld Ziel 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 Rohprotokoll enthält die folgenden Abschnitte:

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

  • JSON-formatiertes Ereignis: {"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"}

Wenn Sie die Syslog-Header vom JSON-Teil des Rohlogs trennen möchten, verwenden Sie im Feld Syslog den folgenden Beispielausdruck: %{TIMESTAMP_ISO8601} %{WORD} %{WORD} ([- ]+)?%{GREEDYDATA:msg}

  • Dieser Teil des Ausdrucks identifiziert den Syslog-Header: %{TIMESTAMP\_ISO8601} %{WORD} %{WORD} ([- ]+)?
  • Mit diesem Teil des Ausdrucks wird das JSON-Segment des Rohlogs erfasst: %{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.

Geben Sie im 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"}

Die folgende Abbildung zeigt die ausgefüllten Felder Syslog und Ziel:

Felder des Syslog-Extractors

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

Beispiel für ein 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 gibt neue Berechtigungen, mit denen festgelegt wird, wer Parsererweiterungen aufrufen und verwalten darf. Standardmäßig können Nutzer mit der Rolle Administrator auf Parsererweiterungen zugreifen. Weitere Informationen zum Verwalten von Nutzern und Gruppen oder zum 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 Löschen Sie Parsererweiterungen.
Parser Bearbeiten Parsererweiterungen erstellen und bearbeiten
Parser Ansehen Parsererweiterungen ansehen