Parser-Erweiterungen entwickeln

Unterstützt in:

In diesem Dokument wird beschrieben, wie Sie Parser-Erweiterungen erstellen, um Felder aus Logrohdaten zu extrahieren und sie den UDM-Zielfeldern (Unified Data Model) in der Google Security Operations-Plattform zuzuordnen.

In diesem Dokument wird der Prozess zum Erstellen von Parser-Erweiterungen beschrieben:

Parser-Erweiterungen erstellen

Parser-Erweiterungen bieten eine flexible Möglichkeit, die Funktionen vorhandener Standard- und benutzerdefinierter Parser zu erweitern. Parsererweiterungen bieten eine flexible Möglichkeit, die Funktionen vorhandener Standard- oder benutzerdefinierter Parser zu erweitern, ohne sie zu ersetzen. Mit den Erweiterungen können Sie die Parser-Pipeline anpassen, indem Sie neue Parsing-Logik hinzufügen, Felder extrahieren und transformieren sowie UDM-Feldzuordnungen aktualisieren oder entfernen.

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

Prozess für Parser-Extraktion und ‑Normalisierung

Google SecOps empfängt ursprüngliche Logdaten als Rohlogs. Mit Standard- und benutzerdefinierten Parsern werden wichtige Logfelder extrahiert und in strukturierte UDM-Felder in UDM-Datensätzen normalisiert. Dies entspricht nur einer Teilmenge der ursprünglichen Rohlogdaten. Sie können Parser-Erweiterungen definieren, um Log-Werte zu extrahieren, die nicht von Standard-Parsern verarbeitet werden. Nach der Aktivierung sind Parser-Erweiterungen Teil des Google SecOps-Prozesses zur Datenextraktion und -normalisierung.

Workflow für Aufnahme und Normalisierung

Neue Parser-Erweiterungen definieren

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

  • No-Code-Ansatz

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

    Sie können beispielsweise JSON-Logdaten mit bis zu 10 Feldern extrahieren, indem Sie einfache Gleichheitsvergleiche verwenden.

  • Code-Snippet-Ansatz

    Mit dem Code-Snippet-Ansatz können Sie Anweisungen definieren, um Werte aus dem Rohlog zu extrahieren und zu transformieren und UDM-Feldern zuzuweisen. Code-Snippets verwenden dieselbe Logstash-ähnliche Syntax wie der Standardparser (oder ein benutzerdefinierter Parser).

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

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

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

    In den meisten Fällen empfiehlt es sich, die Datenabgleichsmethode zu verwenden, die 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 die entsprechenden UDM-Felder im entsprechenden UDM-Datensatz eingefügt. Beispiel:

  • Vorhandene Werte überschreiben: Extrahierte Werte überschreiben vorhandene Werte in den UDM-Zielfeldern.

    Die einzige Ausnahme sind wiederholte Felder. Hier können Sie die Parser-Erweiterung so konfigurieren, dass neue Werte angehängt werden, wenn Daten in ein wiederholtes Feld im UDM-Datensatz geschrieben werden.

  • Parsererweiterung hat Vorrang: Datenzuordnungsanweisungen in einer Parsererweiterung haben Vorrang vor denen im Standard- oder benutzerdefinierten Parser für diesen Logtyp. Bei einem Konflikt in den Zuordnungsanweisungen wird der vom Standardwert festgelegte Wert durch die Parsererweiterung überschrieben.

    Wenn der Standardparser beispielsweise ein Rohlogfeld dem UDM-Feld event.metadata.description zuordnet und die Parser-Erweiterung ein anderes Rohlogfeld demselben UDM-Feld zuordnet, überschreibt die Parser-Erweiterung den vom Standardparser festgelegten Wert.

Auswahl für wiederkehrende Felder

Sowohl beim Ansatz „Datenfelder zuordnen (ohne Code)“ als auch beim Ansatz „Code-Snippet schreiben“ können Sie steuern, wie die Parsererweiterung Werte in wiederholten Feldern speichert (Felder, die ein Array von Werten unterstützen, z. B. principal.ip). Verwenden Sie im Bereich Erweiterung (Erweiterungsdefinition) das Feld Wiederholte Felder, das die Optionen Werte anhängen und Werte ersetzen bietet.

Verhalten beim Anhängen im Vergleich zum Ersetzen

In einigen UDM-Feldern wird ein Array mit Werten gespeichert, z. B. im Feld principal.ip. Mit der Auswahl Wiederholte Felder können Sie festlegen, wie Ihre Parsererweiterung neu extrahierte Daten in einem wiederholten 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 wiederholten Feld zuordnen, wenn sich das wiederholte Feld auf der niedrigsten Ebene der Hierarchie befindet. Beispiel:

  • Das Zuordnen von Werten zu udm.principal.ip wird unterstützt, da sich das wiederholte Feld ip auf der untersten Ebene der Hierarchie befindet und principal kein wiederholtes Feld ist.
  • Das Zuordnen von Werten zu udm.intermediary.hostname wird nicht unterstützt, da intermediary ein wiederholtes 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 des Selektors für wiederholte Felder auf den generierten UDM-Datensatz auswirkt.

Auswahl von wiederkehrenden Feldern Beispiellog Konfiguration der Parsererweiterung Generiertes Ergebnis
Werte anhängen {"protoPayload":{"@type":"type.AuditLog","authenticationInfo":{"principalEmail":""},"requestMetadata":{"callerIp":"1.1.1.1, 2.2.2.2"}}} Vorbedingungsfeld: protoPayload.requestMetadata.callerIp
Vorbedingungswert: " "
Vorbedingungsoperator: 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":""},"requestMetadata":{"callerIp":"2.2.2.2, 3.3.3.3", "name":"Akamai Ltd"}}} Vorbedingung 1:
Vorbedingungsfeld:protoPayload.requestMetadata.callerIp
Vorbedingungswert: " "
Vorbedingungsoperator: NOT_EQUALS
Rohdatenfeld: protoPayload.requestMetadata.callerIp
Zielfeld: event.idm.read_only_udm.principal.ip

Vorbedingung 2:
Rohdatenfeld: protoPayload.requestMetadata.name
Zielfeld: event.idm.read_only_udm.metadata.product_name

 Ereignisse, die vom integrierten Parser generiert wurden, bevor die Erweiterung angewendet wurde.
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":""},"requestMetadata":{"callerIp":"2.2.2.2"}}} Vorbedingungsfeld: protoPayload.authenticationInfo.principalEmail
Vorbedingungswert: " "
Vorbedingungsoperator: NOT_EQUALS
Rohdatenfeld: protoPayload.authenticationInfo.principalEmail
Zielfeld: event.idm.read_only_udm.principal.ip 		UDM-Ereignisse, die vom integrierten Parser vor dem Anwenden 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"}}}

Beschränkungen

  • Eine Parsererweiterung pro Logtyp: Sie können nur eine Parsererweiterung pro Logtyp erstellen.
  • Nur ein Ansatz für die Datenzuordnung: Sie können eine Parsererweiterung entweder mit dem No-Code- oder dem Code-Snippet-Ansatz erstellen, aber nicht mit beiden Ansätzen zusammen.
  • Log-Beispiele für die Validierung: Für die Validierung einer UDM-Parsererweiterung sind Log-Beispiele aus den letzten 30 Tagen erforderlich. Weitere Informationen finden Sie unter Sicherstellen, dass ein aktiver Parser für den Logtyp vorhanden ist.
  • Fehler im Basis-Parser: Fehler im Basis-Parser können nicht in Parser-Erweiterungen identifiziert oder behoben werden.
  • Verarbeitung von Feldern mit mehreren Werten: Sie können in einer bestimmten Erweiterung nur eine Methode verwenden („Append“ oder „Replace“). Seien Sie vorsichtig, wenn Sie ganze wiederholte Objekte ersetzen, um unbeabsichtigte Datenverluste zu vermeiden.
  • Additional.fields wird als eine Gruppe von Schlüssel/Wert-Paaren und nicht als ein wiederholtes Feld interpretiert: Daher können Sie die UDM-Zuweisungen des Parsers und die UDM-Ausgaben der Erweiterung nahtlos kombinieren, indem Sie die entsprechenden Schlüssel/Wert-Paare der Gruppe hinzufügen.
  • Eindeutige Ereignisse: Parsererweiterungen können keine Protokolle mit mehreren eindeutigen Ereignissen in einem einzigen Datensatz verarbeiten, z. B. Google Drive-Arrays.
  • XML und No-Code: Der No-Code-Modus wird für XML nicht unterstützt. Verwenden Sie stattdessen die Methode für Code-Snippets.
  • Parser-Syntax im Vergleich zu YARA-L-Erkennungsregeln: Ingestion-Parser und Parser-Erweiterungen verwenden die Logstash-Grok- und Konfigurationssyntax mit Filtern (z. B. grok, mutate, json, date und base64) zur Aufnahmezeit, um Rohlogs in das Unified Data Model (UDM) zu parsen. Parser können keine YARA-L-Syntax, Ergebnisblöcke oder Generatorfunktionen wie yield verwenden. YARA-L 2.0 ist ausschließlich eine Abfragesprache für die Erkennungs-Engine, die nachgelagert für normalisierte UDM-Ereignisse zur Bedrohungsbenachrichtigung ausgewertet wird. Sie kann keine Rohlogs parsen, UDM-Felder ändern oder eingehenden Log-Traffic verwerfen.
  • Standardmäßig nur für neue Logs: Parsererweiterungen werden standardmäßig nur auf neu aufgenommene Logs ab dem Zeitpunkt der Aktivierung angewendet. Wenn es einen wichtigen geschäftlichen Grund gibt, historische Logs mit aktualisierten Zuordnungen neu zu parsen, können Sie über den Google Cloud Support eine Backend-Aufgabe für die Log-Wiedergabe anfordern. Weitere Informationen finden Sie unter Verlaufsdaten neu parsen (Log Replay).
  • Aufnahmelabels in der Parserlogik nicht zugänglich: Parsererweiterungen können keine Aufnahmelabels (metadata.ingestion_labels) lesen, um Werte UDM-Feldern zuzuordnen, da Parser in einer Sandbox-Ausführungsumgebung ausgeführt werden, in der nur der Rohlogkörper sichtbar ist.
  • Reservierte Keywords beim No-Code-Ansatz: Wenn die Logs eines der folgenden reservierten Keywords enthalten, verwenden Sie den Code-Snippet-Ansatz anstelle des No-Code-Ansatzes:
    • collectionTimestamp
    • createTimestamp
    • enableCbnForLoop
    • event
    • filename
    • message
    • namespace
    • output
    • onErrorCount
    • timestamp
    • timezone
  • Vorhandene Zuordnungen entfernen: Sie können vorhandene UDM-Feldzuordnungen nur mit dem Code-Snippet-Ansatz entfernen.
  • Zuordnung eines UDM-Felds für Hostnamen kann nicht mit einer Erweiterung entfernt werden: Sie können die Zuordnung eines UDM-Felds für Hostnamen (z. B. principal.hostname) nicht mit einer Erweiterung aufheben (entfernen).

Parserkonzepte

In den folgenden Dokumenten werden wichtige Parserkonzepte erläutert:

Vorbereitung

Voraussetzungen für das Erstellen von Parser-Erweiterungen:

  • Für den Logtyp muss ein aktiver Standard- oder benutzerdefinierter Parser vorhanden sein.
  • Google SecOps muss die Rohlogs mit einem Standard- oder benutzerdefinierten Parser aufnehmen und normalisieren können.
  • Achten Sie darauf, dass mit dem aktiven Standard- oder benutzerdefinierten Parser für Ihren Ziellogtyp in den letzten 30 Tagen Rohlogdaten erfasst wurden. Diese Daten sollten eine Stichprobe der Felder enthalten, die Sie extrahieren oder zum Filtern der Log-Einträge verwenden möchten. Sie wird verwendet, um die neuen Anweisungen für die Datenzuordnung zu validieren.

Jetzt starten

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

  1. Voraussetzungen prüfen:

    Achten Sie darauf, dass ein aktiver Parser für den Logtyp vorhanden ist. Wenn noch kein Parser vorhanden ist, erstellen Sie einen benutzerdefinierten Parser.

  2. Felder identifizieren, die aus den Rohlogs extrahiert werden sollen:

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

  3. Geeignete UDM-Felder auswählen:

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

  4. Ansatz für die Definition von Parser-Erweiterungen auswählen:

    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 Logtyp, den Sie erweitern möchten, ein aktiver Parser vorhanden ist, wie in den folgenden Abschnitten beschrieben:

Achten Sie darauf, dass ein aktiver Parser für den Logtyp vorhanden ist.

Achten Sie darauf, dass für den Logtyp, den Sie erweitern möchten, ein aktiver Standard- oder benutzerdefinierter Parser vorhanden ist.

Suchen Sie in diesen Listen nach Ihrem Logtyp:

Achten Sie darauf, dass für den Logtyp ein benutzerdefinierter Parser vorhanden ist.

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

  1. Wählen Sie in der Navigationsleiste SIEM Settings > Parsers 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 Logtyp aktiv ist:

  1. Wählen Sie in der Navigationsleiste SIEM Settings > Parsers aus.

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

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

Felder identifizieren, die aus den Rohlogs extrahiert werden sollen

Analysieren Sie das Rohlog, 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 Rohlogfelder extrahiert und den entsprechenden UDM-Feldern zuordnet.

So ermitteln Sie die spezifischen Felder, die Sie aus den Rohlogs extrahieren möchten: Verwenden Sie die Suchoptionen, um die Felder zu identifizieren:

  • Um auf das Suchtool zuzugreifen, gehen Sie zu Prüfung > SIEM-Suche. Geben Sie raw= vor Ihrer Suchanfrage ein. Weitere Informationen finden Sie unter Rohlogs durchsuchen.

  • Wenn Sie auf das Legacy-Suchtool zugreifen möchten, klicken Sie oben auf der Seite SIEM Search (SIEM-Suche) auf Go to Legacy search (Zur Legacy-Suche). Weitere Informationen finden Sie unter Legacy-Methode: Raw Log Search-Prompt verwenden.

Weitere Informationen zur Suche in den Rohlogs finden Sie in den folgenden Hilfeartikeln:

Geeignete UDM-Felder auswählen

Nachdem Sie die spezifischen Zielfelder für den Export ermittelt haben, können Sie sie den entsprechenden UDM-Zielfeldern zuordnen. Erstellen Sie eine klare Zuordnung zwischen den Rohlogquellenfeldern und den UDM-Zielfeldern. Sie können Daten jedem UDM-Feld zuordnen, das die Standarddatentypen oder wiederholten Felder unterstützt.

Das richtige UDM-Feld auswählen

Die folgenden Ressourcen können den Prozess vereinfachen:

Mit den wichtigsten UDM-Konzepten vertraut sein

  • Logische Objekte: Ereignis und Entität

    Im UDM-Schema werden alle verfügbaren Attribute beschrieben, in denen Daten gespeichert werden. Jeder UDM-Datensatz beschreibt ein Ereignis oder eine Entität. Die Daten werden in verschiedenen Feldern gespeichert, je nachdem, ob der Datensatz ein Ereignis oder eine Einheit beschreibt.

    • In einem UDM-Ereignis-Objekt werden Daten zur Aktion gespeichert, die in der Umgebung stattgefunden hat. Im ursprünglichen Ereignisprotokoll wird die Aktion so beschrieben, wie sie vom Gerät aufgezeichnet wurde, z. B. von der Firewall oder dem Webproxy.
    • In UDM Entity-Objekten werden Daten zu den Teilnehmern oder Entitäten gespeichert, die am UDM-Ereignis beteiligt sind, z. B. Assets, Nutzer oder Ressourcen in Ihrer Umgebung.

  • Struktur eines UDM-Ereignisses

  • Struktur einer UDM-Entität

  • UDM-Substantive: Ein Substantiv steht für einen Teilnehmer oder eine Einheit in einem UDM-Ereignis. Ein Nomen kann beispielsweise das Gerät oder der Nutzer sein, der die im Ereignis beschriebene Aktivität ausführt. Ein Nomen kann auch das Gerät oder der Nutzer sein, das bzw. der das Ziel der im Ereignis beschriebenen Aktivität ist.

    UDM-Substantiv Beschreibung
    principal Die Einheit, die für die Einleitung der im Ereignis beschriebenen Aktion verantwortlich ist.
    target Die Entität, die Empfänger oder Objekt der Aktion ist. Bei einer Firewallverbindung wäre der Computer, der die Verbindung empfängt, das Ziel.
    src Eine Quellentität, auf die das Prinzipal angewendet wurde. Wenn ein Nutzer beispielsweise eine Datei von einem Computer auf einen anderen kopiert, werden die Datei und der Computer, von dem sie stammt, als „src“ dargestellt.
    intermediary Jede Einheit, die bei dem Ereignis als Vermittler fungiert, z. B. ein Proxyserver. Sie können die Aktion beeinflussen, z. B. eine Anfrage blockieren oder ändern.
    observer Eine Einheit, die das Ereignis überwacht und darüber berichtet, aber nicht direkt mit dem Traffic interagiert. Beispiele hierfür sind Systeme zur Erkennung von Netzwerkeinbrüchen oder Systeme zur Verwaltung von Sicherheitsinformationen und ‑ereignissen.
    about Alle anderen am Ereignis beteiligten Rechtssubjekte, die nicht in die vorherigen Kategorien passen. Beispiele: E‑Mail-Anhänge oder geladene DLLs beim Start eines Prozesses.

    In der Praxis werden die Haupt- und Ziel-Noun-Objekte am häufigsten verwendet. Die vorangegangenen Beschreibungen stellen die empfohlene Verwendung von Nouns dar. Die tatsächliche Nutzung kann je nach Implementierung eines Standard- oder benutzerdefinierten Basis-Parsers variieren.

Datenzuordnung des vorhandenen Parsers verstehen

Es wird empfohlen, die vorhandene Datenzuordnung des Standard- oder benutzerdefinierten Parsers zwischen den Quellfeldern des Rohlogs und den zugehörigen UDM-Zielfeldern zu verstehen.

So rufen Sie die Datenzuordnung zwischen den Quellfeldern für Rohlogs und den UDM-Zielfeldern auf, die im vorhandenen Standard- oder benutzerdefinierten Parser verwendet werden:

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

  3. Rufen Sie diese Zeile auf und klicken Sie dann auf das Menü > Ansehen.

    Auf dem Tab Vorgefertigt (oder Benutzerdefiniert) wird im Bereich Parser-Code die Datenzuordnung zwischen den Feldern der Rohprotokollquelle und den UDM-Zielfeldern angezeigt, die im vorhandenen Standardparser (oder benutzerdefinierten Parser) verwendet werden.

UDM-Lookup-Tool verwenden

Mit dem UDM Lookup-Tool können Sie UDM-Felder ermitteln, die den Feldern der Rohprotokollquelle entsprechen.

Google SecOps bietet das UDM Lookup tool, mit dem Sie schnell UDM-Zielfelder finden können. Rufen Sie das UDM-Suchtool über Prüfung > 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 Rohlog mit dem Namen „packets“ haben, können Sie mit dem UDM Lookup-Tool nach potenziellen UDM-Zielfeldern suchen, deren Name „packets“ enthält:

  1. Rufen Sie Untersuchung > SIEM-Suche auf.

  2. Klicken Sie auf der Seite SIEM Search (SIEM-Suche) auf UDM Lookup (UDM-Suche).

    Das Dialogfeld UDM Lookup wird geöffnet. Das Suchtool gleicht UDM-Felder entweder nach Feldname oder Feldwert ab:

    • Suche nach Feldname: 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. Geben Sie im Dialogfeld UDM Lookup (UDM-Suche) im Feld Look up UDM fields/values (Nach UDM-Feldern/-Werten suchen) „packets“ (Pakete) ein und wählen Sie UDM Fields (UDM-Felder) aus.

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

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

Wichtige UDM-Aspekte zur Vermeidung von Fehlern

  • Felder mit ähnlichem Aussehen: Die hierarchische Struktur von UDM kann zu Feldern mit ähnlichen Namen führen. Orientieren Sie sich an den Standard-Parsern. Weitere Informationen finden Sie unter Vom vorhandenen Parser verwendete Datenzuordnung.
  • Beliebige Feldzuordnung: Verwenden Sie das additional-Objekt für Daten, die nicht direkt einem UDM-Feld zugeordnet werden. Weitere Informationen finden Sie unter Beliebige Felder in UDM zuordnen.
  • Wiederkehrende Felder: Seien Sie vorsichtig, wenn Sie wiederkehrende Felder in Code-Snippets verwenden. Wenn Sie ein ganzes Objekt ersetzen, werden die ursprünglichen Daten möglicherweise überschrieben. Mit dem No-Code-Ansatz haben Sie mehr Kontrolle über wiederholte Felder. Weitere Informationen finden Sie unter Auswahl für wiederkehrende Felder.
  • Erforderliche UDM-Felder für UDM-Ereignistypen: Wenn Sie einem UDM-Datensatz ein UDM-Feld metadata.event_type zuweisen, ist für jedes event_type eine andere Gruppe zugehöriger Felder im UDM-Datensatz erforderlich. Weitere Informationen finden Sie unter UDM-Felder für metadata.event_type zuweisen.
  • Probleme mit dem Basisparser: Fehler des Basisparsers können nicht durch Parser-Erweiterungen behoben werden. Der Basisparser ist der Standard- oder benutzerdefinierte Parser, mit dem der UDM-Datensatz erstellt wurde. Sie können beispielsweise die Parser-Erweiterung optimieren, den Basis-Parser ändern oder Protokolle 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-Datensatz speichern, auch wenn kein entsprechendes UDM-Feld vorhanden ist.

Ansatz für die Definition der Parser-Erweiterung auswählen

Bevor Sie sich für eine Methode zur Definition von Parsererweiterungen entscheiden, müssen Sie die folgenden Abschnitte durchgearbeitet haben:

Als Nächstes müssen Sie die Seite Parser-Erweiterung öffnen und die Erweiterungsmethode auswählen, mit der die Parser-Erweiterung definiert werden soll:

Seite „Parser-Erweiterung“ öffnen

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

Sie können die Seite Parser-Erweiterung auf folgende Weise öffnen: über das Menü „Einstellungen“, über eine Rohlog-Suche oder über eine alte Rohlog-Suche:

Über das Menü „Einstellungen“ öffnen

So öffnen Sie die Seite Parser-Erweiterung über das Menü „Einstellungen“:

  1. Wählen Sie in der Navigationsleiste SIEM Settings > Parsers aus.

    In der Tabelle Parser wird eine Liste der Standardparser nach Logtyp angezeigt.

  2. Suchen Sie den Log-Typ, den Sie erweitern möchten, klicken Sie auf das Menü > Parser erweitern > Erweiterung erstellen.

    Die Seite Parser-Erweiterung wird geöffnet.

So öffnen Sie die Seite Parser-Erweiterung über eine Rohlog-Suche:

  1. Rufen Sie Untersuchung > SIEM-Suche auf.
  2. Fügen Sie im Suchfeld das Präfix raw = vor Ihrem Suchargument ein und setzen Sie den Suchbegriff in Anführungszeichen. Beispiel: raw = "example.com".
  3. Klicken Sie auf Suche ausführen. Die Ergebnisse werden im Bereich Rohdaten-Logs angezeigt.
  4. Klicken Sie im Bereich Rohdaten-Logs auf ein Log (eine Zeile). Der Bereich Ereignisanzeige wird angezeigt.
  5. Klicken Sie im Bereich Ereignisbetrachter auf den Tab Rohprotokoll. Das Rohlog wird angezeigt.

  6. Klicken Sie auf Parser verwalten > Parser erweitern > Erweiterung erstellen (oder wählen Sie Erweiterung erstellen > Weiter aus).

    Die Seite Parser-Erweiterung wird geöffnet.

So öffnen Sie die Seite Parser-Erweiterung über die alte Rohlogsuche:

  1. Verwenden Sie die alte Rohlog-Suche, um nach Datensätzen zu suchen, die denen ähneln, die geparst werden.
  2. Wählen Sie im Bereich Zeitachse ein Ereignis aus oder klicken Sie auf das Symbol für das Rohlog, um das Rohlog zu öffnen.

  3. Klicken Sie auf Parser verwalten > Parser erweitern > Erweiterung erstellen (oder wählen Sie Erweiterung erstellen > Weiter aus).

    Die Seite Parser-Erweiterung wird geöffnet.

Seite „Parsererweiterung“

Auf der Seite werden die Bereiche Rohlog und Erweiterung (Erweiterungsdefinition) angezeigt:

  • Bereich Rohlog:

    Hier werden Beispiel-Rohlogdaten für den ausgewählten Logtyp angezeigt. Wenn Sie die Seite über die Rohlog-Suche geöffnet haben, sind die Beispieldaten das Ergebnis Ihrer Suche. Sie können das Beispiel über das Menü Anzeigen als (Roh, JSON, CSV, XML oder Hex/ASCII) und das Kästchen Zeilenumbruch formatieren.

    1. Prüfen Sie, ob die angezeigten Rohlogdaten repräsentativ für die Logs sind, die von der Parsererweiterung verarbeitet werden.

    2. Klicken Sie auf UDM-Ausgabe in der Vorschau ansehen (oder UDM-Ausgabe einblenden), um die UDM-Ausgabe für die Beispiel-Rohlogdaten aufzurufen.

  • Bereich Erweiterung (Erweiterungsdefinition):

    So können Sie eine Parsererweiterung mit einer von zwei Mapping-Anweisungen definieren: Datenfelder zuordnen (ohne Code) oder Code-Snippets schreiben (oder Code-Snippet schreiben). Sie können nicht beide Ansätze in derselben Parsererweiterung verwenden.

    Je nach gewählter Methode können Sie entweder die Quellfelder für Logdaten angeben, die aus den eingehenden Rohlogs extrahiert und den entsprechenden UDM-Feldern zugeordnet werden sollen, oder ein Code-Snippet schreiben, um diese und weitere Aufgaben auszuführen.

Erweiterungsansatz auswählen

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

  • Datenfelder zuordnen (No-Code):

    Bei diesem Ansatz können Sie die Felder im Rohprotokoll angeben und den UDM-Zielfeldern zuordnen.

    Dieser Ansatz funktioniert mit den folgenden Rohlogformaten:

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

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

  • Code-Snippets schreiben (oder Code-Snippet schreiben):

    Bei diesem Ansatz können Sie eine Logstash-ähnliche Syntax verwenden, um Anweisungen zum Extrahieren und Transformieren von Werten aus dem Rohlog anzugeben und sie UDM-Feldern im UDM-Datensatz zuzuweisen.

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

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

    Siehe die nächsten Schritte, Code-Snippet-Anweisungen erstellen.

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

Mit dem No-Code-Ansatz (auch Map Data Fields-Methode genannt) können Sie die Pfade der Rohlogfelder angeben und sie den entsprechenden UDM-Zielfeldern zuordnen.

Bevor Sie eine Parsererweiterung ohne Code erstellen, müssen Sie die folgenden Abschnitte durchgearbeitet haben:

Die nächsten Schritte zum Definieren der Parsererweiterung sind:

  1. Selektor für wiederkehrende Felder festlegen
  2. Für jedes Feld eine Anweisung für die Datenzuordnung definieren
  3. Parser-Erweiterung einreichen und aktivieren

Für jedes Feld eine Anleitung zum Datenabgleich definieren

Definieren Sie für jedes Feld, das Sie aus dem Rohlog extrahieren möchten, eine Anweisung für die Datenzuordnung. In der Anleitung sollte der Pfad des Ursprungsfelds im Rohlog angegeben und dem UDM-Zielfeld zugeordnet werden.

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

    Für die Vorverarbeitung des Syslog-Headers und das Extrahieren des strukturierten Teils des Logs benötigt Google SecOps die Felder Syslog und Target.

    1. Definieren Sie die folgenden Felder:

      • Syslog: Dies ist ein benutzerdefiniertes Muster, das einen Syslog-Header aus dem strukturierten Teil eines Rohlogs vorverarbeitet und trennt.

        Geben Sie das Extraktionsmuster mit Grok und regulären Ausdrücken an, das den Syslog-Header und den Roh-Logeintrag identifiziert. Weitere Informationen finden Sie unter Syslog-Extraktorfelder definieren.

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

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

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

      Syslog-Extraktorfelder

    2. Klicken Sie nach der Eingabe von Werten in die Felder Syslog und Ziel auf die Schaltfläche Validieren.

      Im Rahmen der Validierung wird sowohl nach Syntax- als auch nach Parsing-Fehlern gesucht. Anschließend wird eines der folgenden Ergebnisse zurückgegeben:

      • Erfolgreich: Die Felder für den Datenabgleich werden angezeigt. Definieren Sie den Rest der Parser-Erweiterung.
      • Fehler: Eine Fehlermeldung wird angezeigt. Beheben Sie den Fehler, bevor Sie fortfahren.

  2. Optional können Sie eine Vorbedingungsanweisung definieren.

    Mit einer Precondition-Anweisung wird eine Teilmenge der Rohlogs identifiziert, die von der Parsererweiterung verarbeitet werden. Dazu wird ein statischer Wert mit einem Feld im Rohlog verglichen. Wenn ein eingehendes Rohlog die Vorbedingungen erfüllt, 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:

    • Vorbedingungsfeld (oder Vorbedingungsspalte für CSV): Feld-ID im Rohlog mit dem zu vergleichenden Wert. Geben Sie entweder den vollständigen Pfad zum Feld ein, wenn das Logdatenformat JSON oder XML ist, oder die Spaltenposition, wenn das Datenformat CSV ist.
    • Vorbedingungsoperator: Wählen Sie Gleich oder Nicht gleich aus.
    • Vorbedingungswert: Der statische Wert, der mit dem Vorbedingungsfeld im Rohlog verglichen wird.

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

  3. Ordnen Sie das Feld für Logrohdaten dem UDM-Zielfeld zu:

    • Rohdatenfeld (oder Rohdatenspalte für CSV): Geben Sie entweder den vollständigen Pfad zum Feld ein, wenn das Logdatenformat JSON (z. B. jsonPayload.connection.dest_ip) oder XML (z. B. /Event/Reason-Code) ist, oder die Spaltenposition, wenn das Datenformat CSV ist (Hinweis: 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 Zuordnungsanweisung für das nächste Feld ein.

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

Parser-Erweiterung einreichen und aktivieren

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

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

Google SecOps validiert die Zuordnungsanweisungen:

  • Wenn die Validierung erfolgreich ist, ändert sich der Status in Live und die Mapping-Anweisungen beginnen mit der Verarbeitung eingehender Logdaten.

  • Wenn die Validierung fehlschlägt, ändert sich der Status zu Fehlgeschlagen und im Feld „Rohlog“ wird ein Fehler angezeigt.

    Hier 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

    Parser-Erweiterungen haben die folgenden Lebenszyklusstatus:

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

  • VALIDATING: Google SecOps validiert die Zuordnungsanweisungen anhand vorhandener Rohlogs, um sicherzustellen, dass Felder ohne Fehler geparst werden.

  • LIVE: Die Parser-Erweiterung hat die Validierung bestanden und wird jetzt in der Produktion verwendet. Sie extrahiert und transformiert Daten aus eingehenden Rohlogs in UDM-Datensätze.

  • FAILED: Die Validierung der Parser-Erweiterung ist fehlgeschlagen.

Weitere Informationen zu den Syslog-Extractor-Feldern

Mit den Feldern für den Syslog-Extractor können Sie den Syslog-Header von einem strukturierten Log trennen. Dazu definieren Sie den Grok-Ausdruck, den regulären Ausdruck und ein benanntes Token im Muster des regulären Ausdrucks, um die Ausgabe zu speichern.

Felder für Syslog-Extraktor definieren

Die Werte in den Feldern Syslog und Target definieren gemeinsam, 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 identifiziert. Im Feld Ziel geben Sie den Variablennamen an.

Das folgende Beispiel veranschaulicht, 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 - - -

  • 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 den 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} ([- ]+)?
  • 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 des Rohlogs und weist es der Variablen msg zu.

Geben Sie im Feld Ziel den Variablennamen msg ein. Der in der Variablen msg gespeicherte Wert wird als Eingabe für die Anweisungen zur Zuordnung von Datenfeldern verwendet, die Sie in der Parsererweiterung erstellen.

Anhand des Beispiel-Rohlogs 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"}

Unten sehen Sie die ausgefüllten Felder Syslog und Target:

Syslog-Extraktorfelder

Die folgende Tabelle enthält weitere Beispiele mit Beispiellogs, dem Extraktionsmuster Syslog, 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 metadata.event_type-Feldern für UDM

Wenn einem UDM-Datensatz ein UDM-Feld metadata.event_type zugewiesen wird, wird geprüft, ob die erforderlichen zugehörigen Felder im UDM-Datensatz vorhanden sind. Für jedes 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, wird bei der UDM-Validierung ein Fehler zurückgegeben:

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

Die erforderlichen Felder für die Zuweisung eines UDM-event_type finden Sie in den folgenden Ressourcen. Die Einführungsanleitungen ergänzen die UDM-Anleitung und enthalten die mindestens erforderlichen UDM-Felder, die zum Ausfüllen eines bestimmten UDM-metadata.event_type benötigt werden.

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

Sie sollten die folgenden UDM-Mindestfelder 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 zum Erstellen von Code-Snippets

Mit dem Code-Snippet-Ansatz können Sie Logstash-ähnliche Syntax verwenden, um zu definieren, wie Werte aus dem Rohlog extrahiert und transformiert und UDM-Feldern im UDM-Datensatz zugewiesen werden.

Bevor Sie eine Parsererweiterung mit dem Code-Snippet-Ansatz erstellen, müssen Sie die folgenden Abschnitte durchgearbeitet haben:

Die nächsten Schritte zum Definieren der Parsererweiterung sind:

  1. Tipps und Best Practices finden Sie unter Tipps und Best Practices zum Schreiben von Anweisungen für Code-Snippets.
  2. Anleitung für Code-Snippet erstellen
  3. Anleitung für Code-Snippet einreichen

Tipps und Best Practices für das Schreiben von Anweisungen für Code-Snippets

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-Snippet-Anweisungen werden dieselbe Syntax und dieselben Abschnitte wie für den Standardparser (oder einen benutzerdefinierten Parser) verwendet:

  • Section 1. Daten aus dem Rohprotokoll extrahieren
  • Section 2. Extrahierte Daten transformieren
  • Section 3. Weisen Sie einem UDM-Feld mindestens einen Wert zu.
  • Section 4. UDM-Ereignisfelder an den @output-Schlüssel binden

So erstellen Sie eine Parser-Erweiterung mit dem Code-Snippet-Ansatz:

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

Beispiele für Anweisungen für Code-Snippets

Das folgende Beispiel veranschaulicht 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 ist ein Beispiel für ein Code-Snippet, mit dem der Wert in jsonPayload.packets_sent dem UDM-Feld network.sent_bytes zugeordnet wird:

filter {
  mutate {
    replace => {
      "jsonPayload.packets_sent" => ""
    }
  }
  # 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"
        }
        on_error => "_exception1"
      }
      # Section 3. assign the value to a UDM field
      mutate {
        Replace => {
          "event.idm.read_only_udm.network.sent_bytes" => "jsonPayload.packets_sent"
        }
        on_error => "_exception2"
      }
      if ![_exception1] and![_exception2] {
        # Section 4. Bind the UDM fields to the @output key
        mutate {
          merge => {
            "@output" => "event"
          }
        }
      }
    }
  }
}

Anleitung für Code-Snippet einreichen

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

  2. Google SecOps validiert die Zuordnungsanweisungen.

    • Wenn die Validierung erfolgreich ist, ändert sich der Status in Live und die Mapping-Anweisungen beginnen mit der Verarbeitung eingehender Logdaten.
    • Wenn die Validierung fehlschlägt, ändert sich der Status zu Fehlgeschlagen und im Feld „Rohlog“ wird ein Fehler angezeigt.

Vorhandene Parsererweiterungen verwalten

Sie können vorhandene Parsererweiterungen ansehen, bearbeiten, löschen und den Zugriff darauf steuern.

Vorhandene Parsererweiterung ansehen

  1. Wählen Sie in der Navigationsleiste SIEM Settings > Parsers aus.
  2. Suchen Sie in der Liste „Parser“ nach dem Parser (Logtyp), den Sie aufrufen möchten. Parser mit einer Parsererweiterung sind durch den Text EXTENSION (oder EXTN) neben ihrem Namen gekennzeichnet.

  3. Klicken Sie in dieser Zeile auf das  Menü > Parser erweitern > Erweiterung ansehen.

    Der Tab Benutzerdefinierten/vorgefertigten Parser ansehen > Erweiterung (oder der Tab Erweiterungen) wird angezeigt und enthält Details zur Parsererweiterung. Im Zusammenfassungsbereich wird standardmäßig die LIVE-Parsererweiterung angezeigt.

Parser-Erweiterung bearbeiten

  1. Öffnen Sie den Tab Benutzerdefinierten/vorgefertigten Parser ansehen > Erweiterung (oder den Tab Erweiterungen), wie unter Vorhandene Parsererweiterung ansehen beschrieben.

  2. Klicken Sie auf den Button Erweiterung bearbeiten (oder Bearbeiten).

    Die Seite Parser-Erweiterung wird angezeigt.

  3. Bearbeiten Sie die Parser-Erweiterung.

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

    • Wenn Sie die Parser-Erweiterung jederzeit löschen möchten, klicken Sie auf Fehlerhafte Erweiterung löschen (oder Erweiterung löschen).

    • Wenn Sie mit der Bearbeitung der Parser-Erweiterung fertig sind, klicken Sie auf Senden.

      Der Validierungsprozess wird ausgeführt, um die neue Konfiguration zu validieren.

Parser-Erweiterung löschen

  1. Öffnen Sie den Tab Benutzerdefinierten/vorgefertigten Parser ansehen > Erweiterung (oder den Tab Erweiterungen), wie unter Vorhandene Parsererweiterung ansehen beschrieben.

  2. Klicken Sie auf den Button Erweiterung löschen.

Zugriff auf Parser-Erweiterungen steuern

Standardmäßig können Nutzer mit der Rolle Administrator auf Parser-Erweiterungen zugreifen. Sie können festlegen, wer Parsererweiterungen sehen 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 Parser-Erweiterungen löschen
Parser Bearbeiten Parser-Erweiterungen erstellen und bearbeiten
Parser Ansehen Parser-Erweiterungen ansehen

UDM-Feldzuordnungen mit Parsererweiterungen entfernen

Mit Parsererweiterungen können Sie eine vorhandene UDM-Feldzuordnung entfernen.

  1. Klicken Sie auf SIEM-Einstellungen > Parser.
  2. Sie haben zwei Möglichkeiten, die Seite Parser-Erweiterung aufzurufen:
    • Klicken Sie bei einer vorhandenen Erweiterung auf  Menü > Parser erweitern > Erweiterung ansehen.
    • Klicken Sie für neue Parsererweiterungen auf  Menü > Parser erweitern > Erweiterung erstellen.

  3. Wählen Sie Code-Snippets schreiben (oder Code-Snippet schreiben) als Erweiterungsmethode aus, um ein benutzerdefiniertes Code-Snippet hinzuzufügen, mit dem Werte für bestimmte UDM-Felder entfernt werden.

    Klicken Sie bei einer vorhandenen Erweiterung auf dem Tab Erweiterung (oder Erweiterungen) auf Erweiterung bearbeiten (oder Bearbeiten) und fügen Sie dann den Code-Snippet hinzu.

    Beispiel-Snippets finden Sie unter Code-Snippet – Vorhandene Zuordnungen entfernen.

  4. Folgen Sie der Anleitung unter Code-Snippet-Anweisung einreichen, um die Erweiterung einzureichen.

Zeitzonenbehandlung und Zeitstempelformatierung

Google SecOps standardisiert und serialisiert Zeitstempel im RFC 3339-UTC-Format mit Mikrosekundenpräzision (YYYY-MM-DDTHH:MM:SS.ffffffZ). Wenn Quelllogs nur eine Präzision auf Sekundenebene bieten, füllt die Plattform fehlende Nachkommastellen automatisch mit nachgestellten Nullen auf (.000000Z), um die Einheitlichkeit des Schemas zu gewährleisten.

Wenn ein Ereigniszeitstempel vor der Erfassungszeit (ingested_timestamp < event_timestamp) liegt, tritt die Abweichung in der Regel auf, wenn eine Quelle lokale Wanduhrzeitstempel ohne ISO-Zeitzonen-Offsets (die standardmäßig auf UTC festgelegt sind) ausgibt oder es zu einer Zeitabweichung kommt. Sie haben folgende Möglichkeiten, Zeitzonenabweichungen zu beheben:

  • Zeitstempel in einer Parsererweiterung anpassen: Verwenden Sie den Filter date in einer Parsererweiterung für Code-Snippets, um die Quellzeitzone anzugeben:

    if [raw_log] =~ /EST/ {
  date {
    match => [ "timestamp_str", "MMM dd HH:mm:ss" ]
    timezone => "America/New_York"
    target => "event.metadata.event_timestamp"
  }
}

  • Zeitzonenüberschreibung für Forwarder-Collector konfigurieren: Gehen Sie zu SIEM-Einstellungen > Forwarder, bearbeiten Sie den Ziel-Collector, aktivieren Sie Zeitzone überschreiben und wählen Sie die IANA-Quellzeitzone aus dem Menü Zeitzone aus (z. B. Europe/Paris), um Zeitstempel während der Aufnahme automatisch anzupassen.

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