Parser-Erweiterungen
In diesem Dokument wird beschrieben, wie Sie Parsererweiterungen erstellen, um Felder aus Roh-Logdaten zu extrahieren und ihnen Zielfelder des einheitlichen Datenmodells (Unified Data Model, UDM) auf der Google Security Operations-Plattform zuzuordnen.
Im Dokument wird der Prozess zum Erstellen von Parsererweiterungen beschrieben:
- Parsererweiterungen erstellen
- Voraussetzungen und Einschränkungen
- Quellenfelder in den Rohprotokolldaten identifizieren
- Wählen Sie die entsprechenden UDM-Zielfelder aus.
Wählen Sie den geeigneten Ansatz für die Definition der Parsererweiterung aus:
Das Definieren einer Parsererweiterung umfasst das Entwerfen der Parselogik zum Filtern von Roh-Logdaten, zum Transformieren der Daten und zum Zuordnen der Daten zu Ziel-UDM-Feldern. Google SecOps bietet zwei Möglichkeiten zum Erstellen von Parsererweiterungen:
- Erstellen Sie Parsererweiterungen mit dem No-Code-Ansatz (Datenfelder zuordnen).
- Erstellen Sie Parsererweiterungen mithilfe des Code-Snippets.
Illustrative parser extension creation examples für verschiedene Protokollformate und ‑szenarien. Dazu gehören beispielsweise No-Code-Beispiele mit JSON und Code-Snippets für komplexe Logik oder andere Formate als JSON (CSV, XML, Syslog).
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
Das Google SecOps-Team erhält die ursprünglichen Protokolldaten als Raw-Logs. Standard- und benutzerdefinierte Parser extrahieren und normalisieren wichtige Protokollfelder 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.
Neue Parser-Erweiterungen 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 Rohlogs im nativen JSON-, XML- oder CSV-Format. Sie können Quellfelder für Rohprotokolle 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 angefügt werden.
Parser-Erweiterung hat Vorrang: Die Datenzuordnungsanweisungen in einer Parser-Erweiterung haben Vorrang vor denen im Standard- oder benutzerdefinierten Parser für diesen Protokolltyp. Wenn es einen Konflikt in den Zuordnungsanweisungen gibt, überschreibt die Parsererweiterung den vom Standard festgelegten Wert.
Wenn der Standardparser beispielsweise ein Rohlogfeld dem UDM-Feld
event.metadata.description
zuordnet und die Parsererweiterung ein anderes Rohlogfeld 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.
- Reservierte Keywords mit dem No-Code-Ansatz: Wenn die Protokolle 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
Parserkonzepte
In den folgenden Dokumenten werden wichtige Parserkonzepte erläutert:
- Übersicht über das einheitliche Datenmodell
- Übersicht über das Log-Parsing
- Referenz zur Parsersyntax
Vorbereitung
Voraussetzungen für die Erstellung einer Parsererweiterung:
- Für den Logtyp 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 Ihren Ziel-Log-Typ muss innerhalb der letzten 30 Tage Roh-Log-Daten 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:
Prüfen Sie die Voraussetzungen:
Prüfen Sie, ob für den Protokolltyp ein aktiver Parser vorhanden ist. Wenn noch kein Parser vorhanden ist, erstellen Sie einen benutzerdefinierten Parser.
Felder aus den Rohlogs extrahieren:
Geben Sie die Felder an, die Sie aus den Rohlogs extrahieren möchten.
Wählen Sie die entsprechenden UDM-Felder aus:
Wählen Sie die entsprechenden UDM-Felder aus, um die extrahierten Roh-Log-Felder zuzuordnen.
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 Protokolltyp, 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:
Unterstützte Logtypen mit einem Standardparser
- Wenn für den Protokolltyp ein Standardparser vorhanden ist, prüfen Sie, ob der Parser aktiv ist.
- Wenn für den Logtyp kein Standardparser vorhanden ist, muss ein benutzerdefinierter Parser für den Logtyp vorhanden sein.
Unterstützte Protokolltypen ohne Standardparser
- Wenn für den Logtyp kein Standardparser vorhanden ist, muss ein benutzerdefinierter Parser für den Logtyp vorhanden sein.
Es muss ein benutzerdefinierter Parser für den Logtyp vorhanden sein.
So prüfen Sie, ob für einen Logtyp ein benutzerdefinierter Parser vorhanden ist:
- Wählen Sie in der Navigationsleiste SIEM-Einstellungen > Parser aus.
Suchen Sie in der Tabelle Parser nach dem Logtyp, den Sie erweitern möchten.
- Wenn für diesen Logtyp noch kein Standard- oder benutzerdefinierter Parser vorhanden ist, klicken Sie auf PARSER ERSTELLEN und folgen Sie der Anleitung unter Benutzerdefinierten Parser anhand der Zuordnungsanleitung erstellen.
- Wenn für diesen Logtyp bereits ein benutzerdefinierter Parser vorhanden ist, prüfen Sie, ob der Parser aktiv ist.
Prüfen, ob der Parser für den Protokolltyp aktiv ist
So prüfen Sie, ob ein Parser für einen Log-Typ aktiv ist:
- Wählen Sie in der Navigationsleiste SIEM-Einstellungen > Parser aus.
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:
- Informationen zu Standardparsern finden Sie unter Vorab erstellte Parser-Updates verwalten.
- Informationen zu benutzerdefinierten Parsern finden Sie unter Benutzerdefinierte Parser-Updates verwalten.
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 Rohlogfelder 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 Untersuchung > SIEM-Suche auf. Geben Sie vor der 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:
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 Rohlog-Quellfelder 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
- Datenzuordnung des vorhandenen Parsers verstehen
- Mit dem UDM-Suchtool können Sie potenzielle UDM-Felder finden, die mit Ihren Quellfeldern übereinstimmen.
- Der Leitfaden Wichtige UDM-Felder für die Parserdatenzuordnung enthält eine Zusammenfassung und Erklärung der am häufigsten verwendeten Felder des UDM-Schemas.
- Die Liste der Felder für einheitliche Datenmodelle enthält eine Liste aller UDM-Felder und deren Beschreibungen. Wiederkehrende Felder sind in den Listen mit dem Label „repeated“ gekennzeichnet.
- Wichtige UDM-Hinweise, um Fehler zu vermeiden
Die wichtigsten UDM-Konzepte kennenlernen
- Logische Objekte: Ereignis und Entität
- Struktur eines UDM-Ereignisses
- Struktur einer UDM-Entität
- UDM-Subjekte: Ein Substantiv steht für einen Teilnehmer oder eine Entität in einem UDM-Ereignis. Ein Nomen kann beispielsweise das Gerät oder ein Nutzer sein, der die in einem Ereignis beschriebene Aktivität ausführt, oder das Gerät oder der Nutzer, der das Ziel einer solchen Aktivität ist, die im Ereignis beschrieben wird.
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:
- Wählen Sie in der Navigationsleiste SIEM-Einstellungen > Parser aus.
- Suchen Sie in der Tabelle Parser nach dem Logtyp, den Sie erweitern möchten.
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 Ziel-UDM-Felder schnell finden können. Rufen Sie das UDM-Lookup-Tool auf, indem Sie auf Untersuchung > SIEM-Suche klicken.
Weitere Informationen zur Verwendung des UDM-Suchtools finden Sie in den folgenden Themen:
- UDM-Feld suchen
- UDM-Suchanfrage eingeben
- Zeitfilter für die Suche festlegen
- Beispiele für UDM-Suchanfragen
- UDM-Suchanfragen mit Gemini generieren
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:
Klicken Sie auf Untersuchung > SIEM-Suche.
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 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.
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.
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 des vorhandenen Parsers.
- 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 jedeevent_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: Parsererweiterungen können keine Fehler des Basis-Parsers beheben. Der Basis-Parser 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“:
Wählen Sie in der Navigationsleiste SIEM-Einstellungen > Parser aus.
In der Tabelle Parser finden Sie eine Liste der Standardparser nach Logtyp.
Suchen Sie den Log-Typ, den Sie erweitern möchten, klicken Sie auf das Dreistrich-Menü > Erweiterung erstellen.
Die Seite Parsererweiterungen wird geöffnet.
Über eine Rohlogsuche öffnen
So rufen Sie die Seite Parsererweiterungen über eine Suche in Rohlogs auf:
- Klicken Sie auf Untersuchung > SIEM-Suche.
- Fügen Sie dem Suchargument im Suchfeld das Präfix
raw =
hinzu und setzen Sie den Suchbegriff in Anführungszeichen. Beispiel:raw = "example.com"
. - Klicken Sie auf Suche ausführen. Die Ergebnisse werden im Bereich Raw Logs angezeigt.
- Klicken Sie im Bereich Raw Logs (Raw-Protokolle) auf ein Protokoll (Zeile). Der Bereich Ereignisansicht wird angezeigt.
- Klicken Sie im Bereich Ereignisansicht auf den Tab Raw-Log. Das Rohprotokoll wird angezeigt.
Klicken Sie auf Parser verwalten > Erweiterung erstellen > Weiter.
Die Seite Parsererweiterungen wird geöffnet.
Über eine alte Rohlogsuche öffnen
So öffnen Sie die Seite Parsererweiterungen über eine alte Suche in Rohlogs:
- Verwenden Sie die alte Suche in Rohlogs, um nach Einträgen zu suchen, die denen ähneln, die geparst werden sollen.
- Wählen Sie im Bereich Ereignisse > Zeitachse ein Ereignis aus.
- Maximieren Sie den Bereich Ereignisdaten.
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.
Prüfen Sie, ob die angezeigte Stichprobe der Rohprotokolldaten repräsentativ für die Protokolle ist, die von der Parsererweiterung verarbeitet werden.
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
undSYSLOG + CSV
.
Weitere Informationen finden Sie in der Anleitung unter Kartendatenfelder ohne Code erstellen.
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 Karten ohne Code (Felder für Kartendaten)
Mit dem No-Code-Ansatz (auch Datenfelder zuordnen genannt) können Sie die Pfade der Rohprotokollfelder angeben und ihnen entsprechende Ziel-UDM-Felder zuordnen.
Bevor Sie eine Parsererweiterung mit dem No-Code-Ansatz erstellen, müssen Sie sich die folgenden Abschnitte angesehen haben:
- Parsererweiterungen erstellen
- Jetzt starten
- Wählen Sie den Ansatz für die Erweiterung aus und dann die Option Datenfelder zuordnen.
So definieren Sie die Parsererweiterung:
- Auswahl für wiederkehrende Felder festlegen
- Definieren Sie für jedes Feld eine Datenzuordnungsanweisung.
- 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.
Für jedes Feld eine Datenzuordnungsanweisung definieren
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.
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. native JSON-, native XML- oder CSV-Dateien.
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.
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.
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.
Sie können optional eine Anweisung für die Vorbedingung definieren.
Eine Anweisung für die Vorbedingung identifiziert eine Teilmenge 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 Logdatenformat JSON oder XML ist, oder die Spaltenposition, wenn das Datenformat CSV ist.
- Vorbedingungs-Operator: Wählen Sie
EQUALS
oderNOT 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.
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 Logdatenformat JSON (z. B.
jsonPayload.connection.dest_ip
) oder XML (z. B./Event/Reason-Code
) ist, oder die Spaltenposition, wenn das Datenformat CSV ist. Die Indexpositionen beginnen bei 1.Zielfeld: Geben Sie den voll qualifizierten Namen des UDM-Felds ein, in dem der Wert gespeichert werden soll, z. B.
udm.metadata.collected_timestamp.seconds
.
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 wiederkehrender Felder
In einigen UDM-Feldern wird ein Array mit Werten gespeichert, z. B. das 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:
- Die Zuordnung von Werten zu
udm.principal.ip
wird unterstützt, da sich das wiederkehrende Feldip
auf der untersten Ebene der Hierarchie befindet undprincipal
kein wiederkehrendes Feld ist. - Das Zuordnen von Werten zu
udm.intermediary.hostname
wird nicht unterstützt, daintermediary
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"}}} |
Feld für die Bedingung: protoPayload.requestMetadata.callerIp
Wert der Bedingung: " "
Bedingungsoperator: NOT_EQUALS
Feld für 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:
|
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
|
Werte ersetzen | {"protoPayload":{"@type":"type..AuditLog","authenticationInfo":{"principalEmail":"admin@cmmar.co"},"requestMetadata":{"callerIp":"2.2.2.2"}}} |
Feld für die Bedingung: protoPayload.authenticationInfo.principalEmail
Wert der Bedingung: " "
Bedingungsoperator: NOT_EQUALS
Feld für 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
|
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 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 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:
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"
Die Pflichtfelder 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 mindestens erforderlichen UDM-Felder, 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:
- Parsererweiterungen erstellen
- Jetzt starten
- Wählen Sie den Ansatz für die Erweiterung aus und dann die Option Code-Snippet schreiben.
So definieren Sie die Parsererweiterung:
- Tipps und Best Practices finden Sie unter Tipps und Best Practices zum Erstellen von Code-Snippet-Anleitungen.
- Anleitung für ein Code-Snippet erstellen
- 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 Umbenennen- oder Ersetzen-Vorgä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:
- Geben Sie auf der Seite Parser-Erweiterungen im Bereich CBN-Snippet ein Code-Snippet ein, um die Parser-Erweiterung zu erstellen.
- 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
Klicken Sie auf Senden, um die Zuordnungsanleitung zu speichern.
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
- Wählen Sie in der Navigationsleiste SIEM-Einstellungen > Parser aus.
- 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. 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
Öffnen Sie Benutzerdefinierten/vordefinierten Parser ansehen > Tab „Erweiterung“, wie unter Vorhandene Parsererweiterung ansehen beschrieben.
Klicken Sie auf die Schaltfläche Erweiterung bearbeiten.
Die Seite Parsererweiterungen wird angezeigt.
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
Öffnen Sie Benutzerdefinierten/vordefinierten Parser ansehen > Tab „Erweiterung“, wie unter Vorhandene Parsererweiterung ansehen beschrieben.
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 die Parser-Erweiterungen. |
Parser | Bearbeiten | Parsererweiterungen erstellen und bearbeiten |
Parser | Ansehen | Parser-Erweiterungen ansehen |
Benötigen Sie weitere Hilfe? Antworten von Community-Mitgliedern und Google SecOps-Experten erhalten