Parser-Erweiterungen

Unterstützt in:

In diesem Dokument wird beschrieben, wie Sie Parsererweiterungen erstellen, um Felder aus Rohprotokolldaten zu extrahieren und ihnen Zielfelder für einheitliche Datenmodelle (Unified Data Model, UDM) auf der Google Security Operations-Plattform zuzuordnen.

Im Dokument wird der Prozess zum Erstellen von Parsererweiterungen beschrieben:

Parsererweiterungen erstellen

Mit Parsererweiterungen können Sie die Funktionen vorhandener Standard- und benutzerdefinierter Parser flexibel erweitern. Sie ersetzen keine Standard- (und benutzerdefinierten) Parser, sondern ermöglichen eine nahtlose Anpassung der Parser-Pipeline, neue Parsing-Logik sowie die Extraktion, Manipulation und Zuordnung von Feldern.

Eine Parsererweiterung ist nicht dasselbe wie ein benutzerdefinierter Parser. Sie können einen benutzerdefinierten Parser erstellen, wenn für den Protokolltyp kein Standardparser vorhanden ist, oder Parserupdates deaktivieren.

Parsing, Extraktion und Normalisierung

Google SecOps erhält die ursprünglichen Protokolldaten als Raw-Logs. Standard- und benutzerdefinierte Parser extrahieren und normalisieren wichtige Logfelder in strukturierte UDM-Felder in UDM-Einträgen. Dies ist nur ein Teil der ursprünglichen Rohprotokolldaten. Sie können Parsererweiterungen definieren, um Protokollwerte zu extrahieren, die von den Standardparsern nicht verarbeitet werden. Nach der Aktivierung werden Parsererweiterungen Teil des Datenextraktions- und ‑normalisierungsprozesses von Google SecOps.

Workflow für Datenaufnahme und Normalisierung

Neue Parsererweiterungen definieren

Standardparser enthalten vordefinierte Zuordnungsanweisungen, die angeben, wie Sicherheitsgrundwerte extrahiert, transformiert und normalisiert werden. Sie können neue Parsererweiterungen erstellen, indem Sie Zuordnungsanweisungen entweder mit dem No-Code-Ansatz (Datenfelder zuordnen) oder dem Code-Snippet-Ansatz definieren:

  • No-Code-Ansatz

    Der No-Code-Ansatz eignet sich am besten für einfache Extraktionen aus Rohprotokollen im nativen JSON-, XML- oder CSV-Format. Sie können damit Quellfelder für Rohlogs angeben und entsprechende Ziel-UDM-Felder zuordnen.

    So können Sie beispielsweise JSON-Protokolldaten mit bis zu 10 Feldern mithilfe einfacher Gleichheitsvergleiche extrahieren.

  • Code-Snippet

    Mit dem Code-Snippet-Ansatz können Sie Anweisungen zum Extrahieren und Transformieren von Werten aus dem Rohprotokoll definieren und sie UDM-Feldern zuweisen. Für Code-Snippets wird dieselbe Logstash-ähnliche Syntax wie für den Standard- oder benutzerdefinierten Parser verwendet.

    Dieser Ansatz gilt für alle unterstützten Protokollformate. Sie eignet sich am besten für folgende Szenarien:

    • Komplexe Datenextraktion oder komplexe Logik
    • Unstrukturierte Daten, für die Grok-basierte Parser erforderlich sind.
    • Nicht JSON-Formate wie CSV und XML

    In Code-Snippets werden Funktionen verwendet, um bestimmte Daten aus den Roh-Logdaten zu extrahieren. Beispiele: Grok, JSON, KV und XML.

    In den meisten Fällen empfiehlt es sich, den Datenzuordnungsansatz zu verwenden, der im Standard- oder benutzerdefinierten Parser verwendet wurde.

Neu extrahierte Werte in UDM-Felder zusammenführen

Nach der Aktivierung werden neu extrahierte Werte gemäß vordefinierten Zusammenführungsprinzipien in den entsprechenden UDM-Feldern im entsprechenden UDM-Eintrag zusammengeführt. Beispiel:

  • Vorhandene Werte überschreiben: Mit den extrahierten Werten werden vorhandene Werte in den Ziel-UDM-Feldern überschrieben.

    Die einzige Ausnahme sind wiederkehrende Felder. Hier können Sie die Parsererweiterung so konfigurieren, dass beim Schreiben von Daten in ein wiederkehrendes Feld im UDM-Eintrag neue Werte angehängt werden.

  • Parsererweiterung hat Vorrang: Anweisungen zur Datenzuordnung in einer Parsererweiterung haben Vorrang vor denen im Standard- oder benutzerdefinierten Parser für diesen Protokolltyp. Wenn es einen Konflikt bei den Zuordnungsanweisungen gibt, überschreibt die Parsererweiterung den vom Standard festgelegten Wert.

    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.

Beschränkungen

  • Eine Parsererweiterung pro Protokolltyp: Sie können nur eine Parsererweiterung pro Protokolltyp erstellen.
  • Nur ein Ansatz für die Datenzuordnung: Sie können eine Parsererweiterung entweder mit dem No-Code-Ansatz oder dem Code-Snippet-Ansatz erstellen, aber nicht mit beiden Ansätzen gleichzeitig.
  • Protokollbeispiele zur Validierung: Zur Validierung einer UDM-Parsererweiterung sind Protokollbeispiele aus den letzten 30 Tagen erforderlich. Weitere Informationen finden Sie unter Achten Sie darauf, dass ein aktiver Parser für den Protokolltyp vorhanden ist.
  • Grundlegende Parserfehler: Diese Fehler können nicht innerhalb von Parsererweiterungen erkannt oder behoben werden.
  • Wiederkehrende Felder in Code-Snippets: Seien Sie vorsichtig, wenn Sie ganze wiederkehrende Objekte in Code-Snippets ersetzen, um unbeabsichtigte Datenverluste zu vermeiden. Weitere Informationen finden Sie unter Weitere Informationen zum Selektor für wiederkehrende Felder.
  • Aufgelöste Ereignisse: Parsererweiterungen können keine Protokolle mit mehreren eindeutigen Ereignissen in einem einzelnen Datensatz verarbeiten, z. B. Google Drive-Arrays.
  • XML und No-Code: Der No-Code-Ansatz wird für XML aufgrund potenzieller Codierungsprobleme nicht empfohlen. Verwenden Sie den Code-Snippet-Ansatz für XML.
  • Keine rückwirkenden Daten: Sie können Rohprotokolldaten nicht rückwirkend analysieren.

Parserkonzepte

In den folgenden Dokumenten werden wichtige Parserkonzepte erläutert:

Vorbereitung

Voraussetzungen für die Erstellung einer Parsererweiterung:

  • Für den Protokolltyp muss ein aktiver Standard- oder benutzerdefinierter Parser vorhanden sein.
  • Google SecOps muss die Rohprotokolle mit einem Standard- oder benutzerdefinierten Parser aufnehmen und normalisieren können.
  • Der aktive Standard- oder benutzerdefinierte Parser für den Zielprotokolltyp muss innerhalb der letzten 30 Tage Rohprotokolldaten aufgenommen haben. Diese Daten sollten eine Stichprobe der Felder enthalten, die Sie extrahieren oder zum Filtern der Protokolleinträge verwenden möchten. Sie wird verwendet, um Ihre neue Anleitung zur Datenzuordnung zu validieren.

Jetzt starten

Führen Sie vor dem Erstellen einer Parsererweiterung die folgenden Schritte aus:

  1. Prüfen Sie die Voraussetzungen:

    Prüfen Sie, ob für den Log-Typ ein aktiver Parser vorhanden ist. Wenn noch kein Parser vorhanden ist, erstellen Sie einen benutzerdefinierten Parser.

  2. Felder auswählen, die aus den Rohlogs extrahiert werden sollen:

    Geben Sie die Felder an, die Sie aus den Rohlogs extrahieren möchten.

  3. Wählen Sie die entsprechenden UDM-Felder aus:

    Wählen Sie die entsprechenden UDM-Felder aus, um die extrahierten Roh-Log-Felder zuzuordnen.

  4. Wählen Sie einen Ansatz für die Definition von Parsererweiterungen aus:

    Wählen Sie einen der beiden Erweiterungsansätze (Datenzuordnungsansätze) aus, um die Parsererweiterung zu erstellen.

Voraussetzungen prüfen

Achten Sie darauf, dass für den Log-Typ, den Sie erweitern möchten, ein aktiver Parser vorhanden ist, wie in den folgenden Abschnitten beschrieben:

Prüfen, ob ein aktiver Parser für den Protokolltyp vorhanden ist

Es muss ein aktiver Standard- oder benutzerdefinierter Parser für den Logtyp vorhanden sein, den Sie erweitern möchten.

Suchen Sie in diesen Listen nach Ihrem Logtyp:

Es muss ein benutzerdefinierter Parser für den Log-Typ vorhanden sein.

So prüfen Sie, ob für einen Logtyp ein benutzerdefinierter Parser vorhanden ist:

  1. Wählen Sie in der Navigationsleiste SIEM-Einstellungen > Parser aus.

  2. Suchen Sie in der Tabelle Parser nach dem Logtyp, den Sie erweitern möchten.

Prüfen, ob der Parser für den Logtyp aktiv ist

So prüfen Sie, ob ein Parser für einen Log-Typ aktiv ist:

  1. Wählen Sie in der Navigationsleiste SIEM-Einstellungen > Parser aus.

  2. Suchen Sie in der Tabelle Parser nach dem Logtyp, den Sie erweitern möchten.

    Wenn der Parser für den Protokolltyp nicht aktiv ist, aktivieren Sie ihn:

Felder aus den Rohlogs extrahieren

Analysieren Sie das Rohprotokoll, aus dem Sie Daten extrahieren möchten, um die Felder zu ermitteln, die nicht vom Standard- oder benutzerdefinierten Parser extrahiert werden. Achten Sie darauf, wie der Standard- oder benutzerdefinierte Parser Rohprotokollfelder extrahiert und den entsprechenden UDM-Feldern zuordnet.

Mit den Suchtools können Sie die Felder ermitteln, die Sie aus den Rohlogs extrahieren möchten:

  • Rufen Sie das Suchtool unter Analyse > SIEM-Suche auf. Geben Sie vor Ihrer Suchanfrage raw= ein. Weitere Informationen finden Sie unter Suche in Rohlogs durchführen.

  • Wenn Sie auf das alte Suchtool zugreifen möchten, klicken Sie oben auf der Seite SIEM-Suche auf Zur Legacy-Suche. Weitere Informationen finden Sie unter In Rohlogs mit dem Rohlogs-Scan suchen.

Weitere Informationen zur Suche in den Rohlogs finden Sie unter:

Entsprechende UDM-Felder auswählen

Nachdem Sie die zu extrahierenden Zielfelder ermittelt haben, können Sie sie mit den entsprechenden Ziel-UDM-Feldern abgleichen. Ordnen Sie die Felder der Rohprotokollquelle den Ziel-UDM-Feldern eindeutig zu. Sie können Daten jedem UDM-Feld zuordnen, das die Standarddatentypen oder wiederkehrende Felder unterstützt.

Das richtige UDM-Feld auswählen

Die folgenden Ressourcen können Ihnen dabei helfen:

Die wichtigsten UDM-Konzepte kennenlernen

Datenzuordnung des vorhandenen Parsers verstehen

Es wird empfohlen, die vorhandene Datenzuordnung zu verstehen, die vom Standard- oder benutzerdefinierten Parser zwischen den Quellfeldern der Rohprotokolle und den Ziel-UDM-Feldern verwendet wird.

So rufen Sie die Datenzuordnung zwischen Quellfeldern von Rohlogs und Ziel-UDM-Feldern auf, die im vorhandenen Standard- oder benutzerdefinierten Parser verwendet werden:

  1. Wählen Sie in der Navigationsleiste SIEM-Einstellungen > Parser aus.
  2. Suchen Sie in der Tabelle Parser nach dem Logtyp, den Sie erweitern möchten.

  3. Klicken Sie auf die Zeile und dann auf das Menü > Ansicht.

    Auf dem Tab Parser-Code sehen Sie die Datenzuordnung zwischen den Quellfeldern des Rohlogs und den Ziel-UDM-Feldern, die im vorhandenen Standard- oder benutzerdefinierten Parser verwendet werden.

UDM-Lookup-Tool verwenden

Mit dem UDM-Lookup-Tool können Sie UDM-Felder ermitteln, die mit den Feldern der Rohlogsquelle übereinstimmen.

Google SecOps bietet das UDM-Suchtool, mit dem Sie schnell Ziel-UDM-Felder finden können. Rufen Sie das UDM-Lookup-Tool unter Recherche > SIEM-Suche auf.

Weitere Informationen zur Verwendung des UDM-Lookup-Tools finden Sie in den folgenden Themen:

Beispiel für das UDM-Lookup-Tool

Wenn Sie beispielsweise ein Quellfeld im Rohprotokoll mit dem Namen „packets“ haben, können Sie mit dem UDM-Lookup-Tool nach potenziellen Ziel-UDM-Feldern mit dem Namen „packets“ suchen:

  1. Gehen Sie zu Untersuchung > SIEM-Suche.

  2. Geben Sie auf der Seite SIEM-Suche im Feld Nach UDM-Feldern anhand des Werts suchen „packets“ ein und klicken Sie dann auf UDM-Suche.

    Das Dialogfeld UDM-Suche wird geöffnet. Im Suchtool werden UDM-Felder entweder anhand des Feldnamens oder des Feldwerts abgeglichen:

    • Suche nach Feldnamen: Der eingegebene Textstring wird mit Feldnamen abgeglichen, die diesen Text enthalten.
    • Suche nach Feldwert: Der eingegebene Wert wird mit Feldern abgeglichen, die diesen Wert in ihren gespeicherten Protokolldaten enthalten.

  3. Wählen Sie im Dialogfeld UDM-Suche die Option UDM-Felder aus.

    Die Suchfunktion zeigt eine Liste potenzieller UDM-Felder an, deren UDM-Feldnamen den Text „packets“ enthalten.

  4. Klicken Sie auf die einzelnen Zeilen, um die Beschreibung der einzelnen UDM-Felder aufzurufen.

Wichtige UDM-Hinweise, um Fehler zu vermeiden

  • Ähnlich aussehende Felder: Die hierarchische Struktur von UDM kann zu Feldern mit ähnlichen Namen führen. Weitere Informationen finden Sie unter „Standardparser“. Weitere Informationen finden Sie unter Datenabgleich, der vom vorhandenen Parser verwendet wird.
  • Benutzerdefinierte Feldzuordnung: Verwenden Sie das additional-Objekt für Daten, die nicht direkt einem UDM-Feld zugeordnet werden. Weitere Informationen finden Sie unter Benutzerdefiniertes Feld in UDM.
  • Wiederkehrende Felder: Seien Sie vorsichtig, wenn Sie in Code-Snippets mit wiederkehrenden Feldern arbeiten. Wenn Sie ein ganzes Objekt ersetzen, werden die ursprünglichen Daten möglicherweise überschrieben. Mit dem No-Code-Ansatz haben Sie mehr Kontrolle über wiederkehrende Felder. Weitere Informationen finden Sie unter Weitere Informationen zum Selektor für wiederkehrende Felder.
  • Erforderliche UDM-Felder für UDM-Ereignistypen: Wenn Sie einem UDM-Datensatz ein UDM-metadata.event_type-Feld zuweisen, müssen für jede event_type unterschiedliche zugehörige Felder im UDM-Datensatz vorhanden sein. Weitere Informationen finden Sie unter Weitere Informationen zum Zuweisen von UDM-metadata.event_type-Feldern.
  • Probleme mit dem Basis-Parser: Mit Parsererweiterungen können keine Fehler des Basis-Parsers behoben werden. Der Basisparser ist der Standard- oder benutzerdefinierte Parser, mit dem der UDM-Eintrag erstellt wurde. Sie können beispielsweise die Parsererweiterung verbessern, den Basisparser ändern oder Logs vorab filtern.
Beliebige Feldzuordnung in UDM

Wenn Sie kein geeignetes Standard-UDM-Feld zum Speichern Ihrer Daten finden, verwenden Sie das additional-Objekt, um die Daten als benutzerdefiniertes Schlüssel/Wert-Paar zu speichern. So können Sie wertvolle Informationen im UDM-Eintrag speichern, auch wenn es kein passendes UDM-Feld gibt.

Ansatz für die Definition von Parsererweiterungen auswählen

Bevor Sie eine Definition für Parsererweiterungen auswählen, müssen Sie sich die folgenden Abschnitte durchgelesen haben:

Öffnen Sie als Nächstes die Seite Parsererweiterungen und wählen Sie den Erweiterungsansatz aus, mit dem Sie die Parsererweiterung definieren möchten:

Seite „Parser-Erweiterungen“ öffnen

Auf der Seite Parser-Erweiterungen können Sie die neue Parser-Erweiterung definieren.

Sie haben folgende Möglichkeiten, die Seite Parsererweiterungen zu öffnen: über das Menü „Einstellungen“, über eine Suche in Rohlogs oder über eine alte Suche in Rohlogs:

Über das Menü „Einstellungen“ öffnen

So öffnen Sie die Seite Parsererweiterungen über das Menü „Einstellungen“:

  1. Wählen Sie in der Navigationsleiste SIEM-Einstellungen > Parser aus.

    In der Tabelle Parser finden Sie eine Liste der Standardparser nach Logtyp.

  2. Suchen Sie den Logtyp, den Sie erweitern möchten, klicken Sie auf das Dreistrich-Menü   > Erweiterung erstellen.

    Die Seite Parsererweiterungen wird geöffnet.

So öffnen Sie die Seite Parsererweiterungen über eine Suche in Rohlogs:

  1. Gehen Sie zu Untersuchung > SIEM-Suche.
  2. Fügen Sie dem Suchargument im Suchfeld das Präfix raw = hinzu und setzen Sie den Suchbegriff in Anführungszeichen. Beispiel: raw = "example.com".
  3. Klicken Sie auf Suche ausführen. Die Ergebnisse werden im Bereich Raw Logs angezeigt.
  4. Klicken Sie im Bereich Raw Logs (Raw-Protokolle) auf ein Protokoll (Zeile). Der Bereich Ereignisansicht wird angezeigt.
  5. Klicken Sie im Bereich Ereignisansicht auf den Tab Raw Log (Nativprotokoll). Das Rohprotokoll wird angezeigt.

  6. Klicken Sie auf Parser verwalten > Erweiterung erstellen > Weiter.

    Die Seite Parsererweiterungen wird geöffnet.

So öffnen Sie die Seite Parsererweiterungen über eine alte Suche in Rohlogs:

  1. Verwenden Sie die alte 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 Parser verwalten > Erweiterung erstellen > Weiter.

    Die Seite Parsererweiterungen wird geöffnet.

Seite „Parser-Erweiterungen“

Auf der Seite werden die Bereiche Raw-Log und Erweiterungsdefinition angezeigt:

  • Bereich Rohlog:

    Es werden Beispieldaten für Rohprotokolle für den ausgewählten Protokolltyp angezeigt. Wenn Sie die Seite über die Suche in Rohprotokollen geöffnet haben, sind die Beispieldaten das Ergebnis Ihrer Suche. Sie können das Beispiel über das Menü Anzeigen als (RAW, JSON, CSV, XML usw.) und das Kästchen Text umbrechen formatieren.

    1. Prüfen Sie, ob die angezeigte Stichprobe der Roh-Logdaten repräsentativ für die Protokolle ist, die von der Parsererweiterung verarbeitet werden.

    2. Klicken Sie auf UDM-Ausgabe in der Vorschau, um die UDM-Ausgabe für die Beispielroh-Logdaten aufzurufen.

  • Bereich Erweiterungsdefinition:

    So können Sie eine Parsererweiterung mit einem der beiden Ansätze für Zuordnungsanweisungen definieren: Datenfelder zuordnen (No-Code) oder Code-Snippet schreiben. Sie können nicht beide Ansätze in derselben Parsererweiterung verwenden.

    Je nach gewähltem Ansatz können Sie entweder die Quellprotokolldatenfelder angeben, die aus den eingehenden Rohprotokollen extrahiert und den entsprechenden UDM-Feldern zugeordnet werden sollen, oder Sie können ein Code-Snippet schreiben, um diese und weitere Aufgaben auszuführen.

Erweiterungsansatz auswählen

Wählen Sie auf der Seite Parser-Erweiterungen im Bereich Erweiterungsdefinition im Feld Erweiterungsmethode eine der folgenden Methoden zum Erstellen der Parsererweiterung aus:

  • Datenfelder zuordnen (No-Code):

    Mit diesem Ansatz können Sie die Felder im Rohprotokoll angeben und ihnen Ziel-UDM-Felder zuordnen.

    Dieser Ansatz funktioniert mit den folgenden Rohprotokollformaten:

    • Natives JSON, natives XML oder CSV.
    • Syslog-Header sowie natives JSON, natives XML oder CSV. Sie können eine Anleitung zum Zuordnen von Datenfeldtypen für Rohlogs in den folgenden Formaten erstellen: JSON, XML, CSV, SYSLOG + JSON, SYSLOG + XML und SYSLOG + CSV.

    Weitere Informationen finden Sie in der Anleitung unter No-Code-Anleitung (Kartendatenfelder).

  • Code-Snippet schreiben:

    Bei diesem Ansatz können Sie mit einer Logstash-ähnlichen Syntax Anweisungen angeben, um Werte aus dem Rohprotokoll zu extrahieren und zu transformieren und sie UDM-Feldern im UDM-Eintrag zuzuweisen.

    • Code-Snippets verwenden dieselbe Syntax und dieselben Abschnitte wie Standard- oder benutzerdefinierte Parser. Weitere Informationen finden Sie unter Parsersyntax.

    • Dieser Ansatz funktioniert mit allen unterstützten Datenformaten für diesen Protokolltyp.

    Weitere Informationen finden Sie in der Anleitung zum Erstellen von Code-Snippets.

Anleitung zum Erstellen von No-Code-Anleitungen (Kartendatenfelder)

Mit dem No-Code-Ansatz (auch Datenfelder zuordnen genannt) können Sie die Pfade der Rohprotokollfelder angeben und sie den entsprechenden Ziel-UDM-Feldern zuordnen.

Bevor Sie eine Parsererweiterung mit dem No-Code-Ansatz erstellen, müssen Sie sich die folgenden Abschnitte angesehen haben:

So definieren Sie die Parsererweiterung:

  1. Auswahl für wiederkehrende Felder festlegen
  2. Definieren Sie für jedes Feld eine Datenzuordnungsanweisung.
  3. Parsererweiterung einreichen und aktivieren

Auswahl für wiederkehrende Felder festlegen

Legen Sie im Bereich Erweiterungsdefinition im Feld Wiederkehrende Felder fest, wie die Parsererweiterung einen Wert in wiederkehrenden Feldern speichern soll (Felder, die ein Array von Werten unterstützen, z. B. principal.ip):

  • Werte anhängen: Der neu extrahierte Wert wird dem vorhandenen Satz von Werten, der im UDM-Array-Feld gespeichert ist, angehängt.
  • Werte ersetzen: Der neu extrahierte Wert ersetzt den vorhandenen Satz von Werten im UDM-Array-Feld, der zuvor vom Standardparser gespeichert wurde.

Einstellungen in der Auswahl Wiederholte Felder wirken sich nicht auf nicht wiederholte Felder aus.

Weitere Informationen finden Sie unter Weitere Informationen zur Auswahl für wiederkehrende Felder.

Definieren Sie für jedes Feld eine Datenzuordnungsanweisung.

Definieren Sie eine Datenzuordnungsanweisung für jedes Feld, das Sie aus dem Rohprotokoll extrahieren möchten. Die Anleitung sollte den Pfad des Quellfelds im Rohprotokoll angeben und es dem Ziel-UDM-Feld zuordnen.

  1. Wenn das im Bereich Raw-Log angezeigte Raw-Log-Beispiel einen Syslog-Header enthält, werden die Felder Syslog und Ziel angezeigt. Einige Protokollformate enthalten keinen Syslog-Header, z. B. natives JSON, natives XML oder CSV.

    Google SecOps benötigt die Felder Syslog und Target, um die Syslog-Header vor der Verarbeitung zu bearbeiten und den strukturierten Teil des Logs zu extrahieren.

    1. Definieren Sie die folgenden Felder:

      • Syslog: Dies ist ein benutzerdefiniertes Muster, mit dem ein Syslog-Header vorverarbeitet und vom strukturierten Teil eines Rohlogs getrennt wird.

        Geben Sie das Extraktionsmuster mit Grok und regulären Ausdrücken an, das den Syslog-Header und die Roh-Lognachricht identifiziert. Weitere Informationen finden Sie unter Felder für den Syslog-Extractor definieren.

      • Target: Variablenname im Syslog-Feld, in dem der strukturierte Teil des Logs gespeichert wird.

        Geben Sie im Extrahierungsmuster den Variablennamen an, in dem der strukturierte Teil des Protokolls gespeichert wird.

      Dies ist ein Beispiel für ein Extraktionsmuster und einen Variablennamen für die Felder Syslog und Ziel.

      Felder des Syslog-Extractors

    2. Nachdem Sie Werte in die Felder Syslog und Ziel eingegeben haben, klicken Sie auf die Schaltfläche Validieren.

      Bei der Validierung werden sowohl Syntax- als auch 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.
      • Fehlgeschlagen: Es wird eine Fehlermeldung angezeigt. Beheben Sie die Fehlerbedingung, bevor Sie fortfahren.

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

    Eine Anweisung für die Vorbedingung identifiziert einen Teil der 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 Vorbedingungen erfüllt, wendet die Parsererweiterung die Zuordnungsanweisung an. Wenn die Werte nicht übereinstimmen, wird die Zuordnungsanweisung von der Parsererweiterung nicht angewendet.

    Füllen Sie die folgenden Felder aus:

    • Voraussetzungsfeld: Feld-ID im Rohprotokoll, die den zu vergleichenden Wert enthält. 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 EQUALS oder NOT EQUALS aus.
    • Vorbedingungswert: Der statische Wert, der mit dem Vorbedingungsfeld im Rohprotokoll verglichen wird.

    Ein weiteres Beispiel für eine Anweisung für eine Bedingung finden Sie unter No-Code – Felder mit einem Wert für die Bedingung extrahieren.

  3. Ordnen Sie das Feld mit den Roh-Logdaten dem Ziel-UDM-Feld zu:

    • Feld mit Rohdaten: Geben Sie entweder den vollständigen Pfad zum Feld ein, wenn das Protokolldatenformat JSON (z. B. jsonPayload.connection.dest_ip) oder XML (z. B. /Event/Reason-Code) ist, oder die Spaltenposition, wenn das Datenformat CSV ist. Hinweis: Die Indexpositionen beginnen bei 1.

    • Zielfeld: Geben Sie den voll qualifizierten UDM-Feldnamen ein, in dem der Wert gespeichert werden soll, z. B. udm.metadata.collected_timestamp.seconds.

  4. Wenn Sie weitere Felder hinzufügen möchten, klicken Sie auf Hinzufügen und geben Sie alle Details zur Zuordnungsanleitung für das nächste Feld ein.

Ein weiteres Beispiel für die Zuordnung von Feldern finden Sie unter No-Code – Felder extrahieren.

Parsererweiterung einreichen und aktivieren

Nachdem Sie Anweisungen für die Datenzuordnung für alle Felder definiert haben, die Sie aus dem Rohprotokoll extrahieren möchten, reichen Sie die Parsererweiterung ein und aktivieren Sie sie.

Klicken Sie auf Senden, um die Zuordnungsanleitung zu speichern und zu validieren.

Google SecOps prüft die Zuordnungsanleitung:

  • Wenn die Validierung erfolgreich ist, ändert sich der Status zu Live und die Zuordnungsanleitung beginnt mit der Verarbeitung eingehender Protokolldaten.

  • Wenn der Validierungsprozess fehlschlägt, ändert sich der Status zu Fehlgeschlagen und im Feld „Raw Log“ wird eine Fehlermeldung angezeigt.

    Dies ist ein Beispiel für 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"}

    Lebenszyklusstatus einer Parsererweiterung

    Parsererweiterungen haben die folgenden Lebenszykluszustände:

  • DRAFT: Eine neu erstellte Parsererweiterung, die noch nicht eingereicht wurde.

  • VALIDATING: Google SecOps prüft die Zuordnungsanweisungen anhand vorhandener Rohprotokolle, 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.

Weitere Informationen zur Auswahl für wiederkehrende Felder

In einigen UDM-Feldern wird ein Array von Werten gespeichert, z. B. im Feld principal.ip. Mit der Auswahl Wiederkehrende Felder können Sie festlegen, wie Ihre Parsererweiterung neu extrahierte Daten in einem wiederkehrenden Feld speichert:

  • Werte anhängen:

    Die Parsererweiterung hängt den neu extrahierten Wert an das Array der vorhandenen Werte im UDM-Feld an.

  • Werte ersetzen:

    Die Parsererweiterung ersetzt das Array der vorhandenen Werte im UDM-Feld durch den neu extrahierten Wert.

Eine Parsererweiterung kann Daten nur dann einem wiederkehrenden Feld zuordnen, wenn sich das wiederkehrende Feld auf der untersten Ebene der Hierarchie befindet. Beispiel:

  • Das Zuordnen von Werten zu udm.principal.ip wird unterstützt, da sich das wiederkehrende Feld ip auf der untersten Ebene der Hierarchie befindet und principal kein wiederkehrendes Feld ist.
  • Das Zuordnen 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.

In der folgenden Tabelle finden Sie Beispiele dafür, wie sich die Konfiguration der Auswahl 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 für 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 den folgenden Beispielausdruck im Feld Syslog: %{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 Datenzuordnungsanweisung 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"}

Im Folgenden sind die ausgefüllten Felder Syslog und Ziel zu sehen:

Felder des Syslog-Extractors

Die folgende Tabelle enthält weitere Beispiele mit Beispielprotokollen, dem Syslog-Extraktionsmuster, dem Variablennamen 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.

Weitere Informationen zum Zuweisen von UDM-metadata.event_type-Feldern

Wenn Sie einem UDM-Eintrags ein UDM-metadata.event_type-Feld zuweisen, wird geprüft, ob die erforderlichen zugehörigen Felder im UDM-Eintrags vorhanden sind. Für jede UDM-metadata.event_type sind unterschiedliche zugehörige Felder erforderlich. Ein USER_LOGIN-Ereignis ohne user ist beispielsweise nicht sinnvoll.

Wenn ein erforderliches zugehöriges Feld fehlt, gibt die UDM-Validierung einen Fehler zurück:

  "error": {
    "code": 400,
    "message": "Request contains an invalid argument.",
    "status": "INVALID_ARGUMENT"
  }

Ein Grok-Parser gibt einen detaillierteren Fehler zurück:

  generic::unknown: 
  invalid event 0: LOG_PARSING_GENERATED_INVALID_EVENT: 
  "generic::invalid_argument: udm validation failed: target field is not set"

Informationen zu den Pflichtfeldern für eine UDM-event_type, die Sie zuweisen möchten, finden Sie in den folgenden Ressourcen:

  • Google SecOps-Dokumentation: UDM-Nutzungsleitfaden – Erforderliche und optionale UDM-Felder für jeden Ereignistyp

  • Unbestätigte Ressourcen von Drittanbietern: UDM-Ereignisvalidierung

    Wenn die UDM-Nutzungsanleitung nicht ausreichend detailliert ist, ergänzt dieses Dokument die offizielle Dokumentation. Es enthält die Mindestanzahl an Pflichtfeldern für UDMs, die zum Ausfüllen einer bestimmten UDM-metadata.event_type erforderlich sind.

    Öffnen Sie beispielsweise das Dokument und suchen Sie nach dem Ereignistyp GROUP_CREATION.

    Sie sollten die folgenden UDM-Felder als UDM-Objekt sehen:

    {
    "metadata": {
        "event_timestamp": "2023-07-03T13:01:10.957803Z",
        "event_type": "GROUP_CREATION"
    },
    "principal": {
        "user": {
            "userid": "pinguino"
        }
    },
    "target": {
        "group": {
            "group_display_name": "foobar_users"
        }
    }
}

Anleitung für Code-Snippets erstellen

Mit dem Code-Snippet-Ansatz können Sie mit einer Logstash-ähnlichen Syntax festlegen, wie Werte aus dem Rohprotokoll extrahiert und transformiert und UDM-Feldern im UDM-Eintrag zugewiesen werden.

Bevor Sie eine Parsererweiterung mithilfe des Code-Snippet-Ansatzes erstellen, müssen Sie sich die folgenden Abschnitte durchgelesen haben:

So definieren Sie die Parsererweiterung:

  1. Tipps und Best Practices finden Sie unter Tipps und Best Practices zum Erstellen von Code-Snippet-Anleitungen.
  2. Anleitung für ein Code-Snippet erstellen
  3. Anleitung für ein Code-Snippet einreichen

Tipps und Best Practices für das Schreiben von Code-Snippet-Anleitungen

Anleitungen für Code-Snippets können aufgrund von Problemen wie falschen Grok-Mustern, fehlgeschlagenen Umbenennungs- oder Ersetzungsvorgängen oder Syntaxfehlern fehlschlagen. Hier finden Sie Tipps und Best Practices:

Anleitung für ein Code-Snippet erstellen

Für Code-Snippets werden dieselbe Syntax und dieselben Abschnitte wie für den Standard- oder benutzerdefinierten Parser verwendet:

  • Bereich 1. Daten aus dem Rohprotokoll extrahieren
  • 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.

So erstellen Sie eine Parsererweiterung mithilfe des Code-Snippet-Ansatzes:

  1. Geben Sie auf der Seite Parser-Erweiterungen im Bereich CBN-Snippet ein Code-Snippet ein, um die Parser-Erweiterung zu erstellen.
  2. Klicken Sie auf Validieren, um die Zuordnungsanleitung zu validieren.

Beispiele für Code-Snippet-Anweisungen

Das folgende Beispiel zeigt ein Code-Snippet.

Hier ein Beispiel für das Rohprotokoll:

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

Hier ein Beispiel für ein Code-Snippet, mit dem der Wert in jsonPayload.packets_sent dem UDM-Feld network.sent_bytes zugeordnet wird:

mutate {
 replace => {
    "jsonPayload.packets_sent" => ""
 }
}
filter {
    # Section 1. extract data from the raw 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"
                    }
                }
            }
        }
    }
}

Anleitung für Code-Snippets einreichen

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

  2. Google SecOps prüft die Zuordnungsanleitung.

    • Wenn die Validierung erfolgreich ist, ändert sich der Status zu Live und die Zuordnungsanleitung beginnt mit der Verarbeitung eingehender Protokolldaten.
    • Wenn der Validierungsprozess fehlschlägt, ändert sich der Status zu Fehlgeschlagen und im Feld „Raw Log“ wird eine Fehlermeldung angezeigt.

Vorhandene Parsererweiterungen verwalten

Sie können vorhandene Parsererweiterungen aufrufen, bearbeiten, löschen und den Zugriff darauf verwalten.

Vorhandene Parsererweiterung ansehen

  1. Wählen Sie in der Navigationsleiste SIEM-Einstellungen > Parser aus.
  2. Suchen Sie in der Liste der Parser nach dem Parser (Logtyp), den Sie ansehen möchten. Parser mit einer Parsererweiterung sind durch den Text EXTENSION neben dem Namen gekennzeichnet.

  3. Klicken Sie in dieser Zeile auf das Dreipunkt-Menü  Menü > Erweiterung ansehen.

    Der Tab Benutzerdefinierten/vordefinierten Parser ansehen > Tab „Erweiterung“ wird angezeigt. Dort finden Sie Details zur Parsererweiterung. Im Bereich „Zusammenfassung“ wird standardmäßig die Parsererweiterung LIVE angezeigt.

Parsererweiterung bearbeiten

  1. Öffnen Sie Benutzerdefinierten/vordefinierten Parser ansehen > Tab „Erweiterung“, wie unter Vorhandene Parsererweiterung ansehen beschrieben.

  2. Klicken Sie auf die Schaltfläche Erweiterung bearbeiten.

    Die Seite Parsererweiterungen wird angezeigt.

  3. Bearbeiten Sie die Parser-Erweiterung.

    • Wenn Sie die Bearbeitung abbrechen und die Änderungen verwerfen möchten, klicken Sie auf Entwurf verwerfen.

    • Wenn Sie die Parsererweiterung jederzeit löschen möchten, klicken Sie auf Fehlgeschlagene Erweiterung löschen.

    • Wenn Sie die Parsererweiterung fertig bearbeitet haben, klicken Sie auf Senden.

      Die neue Konfiguration wird validiert.

Parsererweiterung löschen

  1. Öffnen Sie Benutzerdefinierten/vordefinierten Parser ansehen > Tab „Erweiterung“, wie unter Vorhandene Parsererweiterung ansehen beschrieben.

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

Zugriff auf Parsererweiterungen steuern

Standardmäßig können Nutzer mit der Rolle Administrator auf Parsererweiterungen zugreifen. Sie können festlegen, wer Parsererweiterungen ansehen und verwalten darf. Weitere Informationen zum Verwalten von Nutzern und Gruppen oder zum Zuweisen von Rollen finden Sie unter Rollenbasierte Zugriffssteuerung.

Die neuen Rollen in Google SecOps 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

Benötigen Sie weitere Hilfe? Antworten von Community-Mitgliedern und Google SecOps-Experten erhalten