Übersicht zur Log-Analyse

Unterstützt in:

Google secops SIEM

In diesem Dokument finden Sie eine Übersicht darüber, wie Google Security Operations Rohlogs in das Unified Data Model-Format (UDM) analysiert.

Google SecOps kann Logdaten aus den folgenden Quellen empfangen:

• Google SecOps-Weiterleitung
• Chronicle API-Feed
• Chronicle Ingestion API
• Technologiepartner von Drittanbietern

Im Allgemeinen senden Kunden Daten als ursprüngliche Rohlogs. Google SecOps identifiziert das Gerät, das die Logs generiert hat, eindeutig anhand des LogType. Der LogType gibt Folgendes an:

• den Anbieter und das Gerät, das das Log generiert hat, z. B. Cisco Firewall, Linux DHCP Server oder Bro DNS.
• welcher Parser das Rohlog in strukturiertes UDM konvertiert. Es besteht eine 1:1-Beziehung zwischen einem Parser und einem LogType. Jeder Parser konvertiert Daten, die von einem einzelnen LogType empfangen werden.

Google SecOps bietet eine Reihe von Standard-Parsern, die ursprüngliche Rohlogs lesen und strukturierte UDM-Datensätze mit Daten aus dem ursprünglichen Rohlog generieren. Google SecOps verwaltet diese Parser. Kunden können auch benutzerdefinierte Datenzuordnungsanweisungen definieren, indem sie einen kundenspezifischen Parser erstellen. Wenn Sie eine mehrzeilige Nutzlast senden, interpretiert das System jede Zeile als separaten Logeintrag.

Der Parser enthält Datenzuordnungsanweisungen. Er definiert, wie Daten aus dem ursprünglichen Rohlog einem oder mehreren Feldern in der UDM-Datenstruktur zugeordnet werden.

Wenn keine Analysefehler auftreten, erstellt Google SecOps einen UDM-strukturierten Datensatz mit Daten aus dem Rohlog. Der Prozess der Konvertierung eines Rohlogs in einen UDM-Datensatz wird als Normalisierung bezeichnet.

Ein Standard-Parser kann eine Teilmenge der Kernwerte aus dem Rohlog zuordnen. In der Regel sind diese Kernfelder die wichtigsten, um Sicherheitsinformationen in Google SecOps zu erhalten. Nicht zugeordnete Werte bleiben im Rohlog, werden aber nicht im UDM-Datensatz gespeichert.

Kunden können auch die Ingestion API verwenden, um Daten im strukturierten UDM-Format zu senden.

Analyse aufgenommener Daten anpassen

Google SecOps bietet die folgenden Funktionen, mit denen Kunden die Datenanalyse für eingehende ursprüngliche Logdaten anpassen können. Weitere Informationen zum Verwalten dieser Parser finden Sie unter Vordefinierte und benutzerdefinierte Parser verwalten.

• Kundenspezifische Parser: Kunden erstellen eine benutzerdefinierte Parserkonfiguration für einen bestimmten Logtyp, die ihren spezifischen Anforderungen entspricht. Ein kundenspezifischer Parser ersetzt den Standard-Parser für den jeweiligen LogType. Weitere Informationen finden Sie unter Vordefinierte und benutzerdefinierte Parser verwalten.
• Parsererweiterungen: Kunden können zusätzlich zur Standard-Parserkonfiguration benutzerdefinierte Zuordnungsanweisungen hinzufügen. Jeder Kunde kann einen eigenen Satz benutzerdefinierter Zuordnungsanweisungen erstellen. Diese Zuordnungsanweisungen definieren, wie zusätzliche Felder aus ursprünglichen Rohlogs in UDM-Felder extrahiert und transformiert werden. Eine Parsererweiterung ersetzt nicht den Standard- oder kundenspezifischen Parser.

Beispiel mit einem Squid-Webproxy-Log

In diesem Abschnitt finden Sie ein Beispiel für ein Squid-Webproxy-Log und eine Beschreibung, wie die Werte einem UDM-Datensatz zugeordnet werden. Eine Beschreibung aller Felder im UDM-Schema finden Sie unter Liste der Felder für einheitliche Datenmodelle (Unified Data Model, UDM).

Das Beispiel für ein Squid-Webproxy-Log enthält durch Leerzeichen getrennte Werte. Jeder Datensatz stellt ein Ereignis dar und speichert die folgenden Daten: Zeitstempel, Dauer, Client, Ergebniscode/Ergebnisstatus, übertragene Byte, Anfragemethode, URL, Nutzer, Hierarchiecode und Inhaltstyp. In diesem Beispiel werden die folgenden Felder extrahiert und einem UDM-Datensatz zugeordnet: Zeit, Client, Ergebnisstatus, Byte, Anfragemethode und URL.

1588059648.129 23 192.168.23.4 TCP_HIT/200 904 GET www.google.com/images/sunlogo.png - HIER_DIRECT/203.0.113.52 image/jpeg

Wenn Sie diese Strukturen vergleichen, sehen Sie, dass nur eine Teilmenge der ursprünglichen Logdaten im UDM-Datensatz enthalten ist. Bestimmte Felder sind erforderlich, andere optional. Außerdem enthalten nur einige Abschnitte im UDM-Datensatz Daten. Wenn der Parser keine Daten aus dem ursprünglichen Log dem UDM-Datensatz zuordnet, wird dieser Abschnitt des UDM-Datensatzes in Google SecOps nicht angezeigt.

Im Abschnitt metadata wird der Zeitstempel des Ereignisses gespeichert. Der Wert wurde von Epoch in das RFC 3339-Format konvertiert. Diese Konvertierung ist optional. Der Zeitstempel kann im Epoch-Format gespeichert werden. Dabei werden die Sekunden und Millisekunden in separate Felder aufgeteilt.

Im metadata.event_type Feld wird der Wert NETWORK_HTTP gespeichert. Dies ist ein Aufzählungswert , der den Ereignistyp angibt. Der Wert von metadata.event_type bestimmt, welche zusätzlichen UDM-Felder erforderlich oder optional sind. Die Werte product_name und vendor_name enthalten nutzerfreundliche Beschreibungen des Geräts, das das ursprüngliche Log aufgezeichnet hat.

Der Wert von metadata.event_type in einem UDM-Ereignisdatensatz ist nicht derselbe wie der log_type, der beim Aufnehmen von Daten mit der Ingestion API definiert wurde. Diese beiden Attribute speichern unterschiedliche Informationen.

Der Abschnitt network enthält Werte aus dem ursprünglichen Logereignis. In diesem Beispiel wurde der Statuswert aus dem ursprünglichen Log aus dem Feld „Ergebniscode/Status“ analysiert, bevor er in den UDM-Datensatz geschrieben wurde. Nur der result_code wurde in den UDM-Datensatz aufgenommen.

Im Abschnitt principal werden die Clientinformationen aus dem ursprünglichen Log gespeichert. Im Abschnitt target werden sowohl die voll qualifizierte URL als auch die IP-Adresse gespeichert.

Im Abschnitt security_result wird einer der Aufzählungswerte gespeichert, um die Aktion darzustellen, die im ursprünglichen Log aufgezeichnet wurde.

Dies ist der UDM-Datensatz im JSON-Format. Nur Abschnitte mit Daten sind enthalten. Die Abschnitte src, observer, intermediary, about und extensions sind nicht enthalten.

{
        "metadata": {
            "event_timestamp": "2020-04-28T07:40:48.129Z",
            "event_type": "NETWORK_HTTP",
            "product_name": "Squid Proxy",
            "vendor_name": "Squid"
        },
        "principal": {
            "ip": "192.168.23.4"
        },
        "target": {
            "url": "www.google.com/images/sunlogo.png",
            "ip": "203.0.113.52"
        },
        "network": {
            "http": {
                "method": "GET",
                "response_code": 200,
                "received_bytes": 904
            }
        },
        "security_result": {
            "action": "UNKNOWN_ACTION"
        }
}

Schritte in Parseranweisungen

Die Datenabgleichanweisungen in einem Parser folgen einem gemeinsamen Muster:

1. Daten aus dem ursprünglichen Log analysieren und extrahieren.
2. Extrahierte Daten bearbeiten. Dazu gehört die Verwendung bedingter Logik, um Werte selektiv zu analysieren, Datentypen zu konvertieren, Teilstrings in einem Wert zu ersetzen, in Groß- oder Kleinbuchstaben zu konvertieren usw.
3. Werte UDM-Feldern zuweisen.
4. Den zugeordneten UDM-Datensatz an den Schlüssel @output ausgeben.

Daten aus dem ursprünglichen Log analysieren und extrahieren

Filteranweisung festlegen

Die Anweisung filter ist die erste Anweisung im Satz der Analyseanweisungen. Alle zusätzlichen Analyseanweisungen sind in der Anweisung filter enthalten.

filter {

}

Variablen initialisieren, in denen extrahierte Werte gespeichert werden

Initialisieren Sie in der Anweisung filter Zwischenvariablen, die der Parser zum Speichern von Werten verwendet, die aus dem Log extrahiert wurden.

Diese Variablen werden jedes Mal verwendet, wenn ein einzelnes Log analysiert wird. Der Wert in jeder Zwischenvariablen wird später in den Analyseanweisungen auf ein oder mehrere UDM-Felder festgelegt.

  mutate {
    replace => {
      "event.idm.read_only_udm.metadata.product_name" => "Webproxy"
      "event.idm.read_only_udm.metadata.vendor_name" => "Squid"
      "not_valid_log" => "false"
      "when" => ""
      "srcip" => ""
      "action" => ""
      "username" => ""
      "url" => ""
      "tgtip" => ""
      "method" => ""
    }
  }

Einzelne Werte aus dem Log extrahieren

Google SecOps bietet eine Reihe von Filtern, die auf Logstash basieren, um Felder aus ursprünglichen Logdateien zu extrahieren. Je nach Format des Logs verwenden Sie einen oder mehrere Extraktionsfilter, um alle Daten aus dem Log zu extrahieren. Wenn der String Folgendes ist:

• natives JSON: Die Parser-Syntax ähnelt dem JSON-Filter, der JSON-formatierte Logs unterstützt. Verschachteltes JSON wird nicht unterstützt.
• XML-Format: Die Parser-Syntax ähnelt dem XML-Filter, der XML-formatierte Logs unterstützt.
• Schlüssel/Wert-Paare: Die Parser-Syntax ähnelt dem Kv-Filter, der Nachrichten im Schlüssel/Wert-Format unterstützt.
• CSV-Format: Die Parser-Syntax ähnelt dem Csv-Filter, der Nachrichten im CSV-Format unterstützt.
• alle anderen Formate: Die Parser-Syntax ähnelt dem GROK-Filter mit integrierten GROK-Mustern . Hier werden Extraktionsanweisungen im Regex-Stil verwendet.

Google SecOps bietet eine Teilmenge der in den einzelnen Filtern verfügbaren Funktionen. Google SecOps bietet auch eine benutzerdefinierte Syntax für die Datenzuordnung, die in den Filtern nicht verfügbar ist. Eine Beschreibung der unterstützten Funktionen und benutzerdefinierten Funktionen finden Sie in der Referenz zur Parser-Syntax.

Im Beispiel für das Squid-Webproxy-Log enthält die folgende Datenextraktionsanweisung eine Kombination aus Logstash Grok-Syntax und regulären Ausdrücken.

Die folgende Extraktionsanweisung speichert Werte in den folgenden Zwischenvariablen:

• when
• srcip
• action
• returnCode
• size
• method
• username
• url
• tgtip

In dieser Beispielanweisung wird auch das Schlüsselwort overwrite verwendet, um die extrahierten Werte in jeder Variablen zu speichern. Wenn der Extraktionsprozess einen Fehler zurückgibt, wird mit der Anweisung on_error die Variable not_valid_log auf true gesetzt.

grok {
   match => {
     "message" => [
       "%{NUMBER:when}\\s+\\d+\\s%{SYSLOGHOST:srcip} %{WORD:action}\\/%{NUMBER:returnCode} %{NUMBER:size} %{WORD:method} (?P<url>\\S+) (?P<username>.*?) %{WORD}\\/(?P<tgtip>\\S+).*"
     ]
   }
   overwrite => ["when","srcip","action","returnCode","size","method","url","username","tgtip"]
   on_error => "not_valid_log"
}

Extrahierte Werte bearbeiten und transformieren

Google SecOps nutzt die Funktionen des Logstash Mutate-Filter-Plug-ins, um die Bearbeitung von Werten zu ermöglichen, die aus dem ursprünglichen Log extrahiert wurden. Google SecOps bietet eine Teilmenge der im Plug-in verfügbaren Funktionen. Eine Beschreibung der unterstützten Funktionen und benutzerdefinierten Funktionen finden Sie in der Parser-Syntax, z. B.:

• Werte in einen anderen Datentyp umwandeln
• Werte im String ersetzen
• Zwei Arrays zusammenführen oder einen String an ein Array anhängen. Stringwerte werden vor dem Zusammenführen in ein Array konvertiert.
• In Klein- oder Großbuchstaben konvertieren

In diesem Abschnitt finden Sie Beispiele für die Datentransformation, die auf dem zuvor vorgestellten Squid-Webproxy-Log basieren.

Zeitstempel des Ereignisses transformieren

Alle Ereignisse, die als UDM-Datensatz gespeichert werden, müssen einen Zeitstempel haben. In diesem Beispiel wird geprüft, ob ein Wert für die Daten aus dem Log extrahiert wurde. Anschließend wird die Grok Datumsfunktion verwendet, um den Wert mit dem UNIX Zeitformat abzugleichen.

if [when] != "" {
  date {
    match => [
      "when", "UNIX"
    ]
   }
 }

Wert von username transformieren

Die folgende Beispielanweisung konvertiert den Wert in der Variablen username in Kleinbuchstaben.

mutate {
   lowercase => [ "username"]
   }

Wert von action transformieren

Im folgenden Beispiel wird der Wert in der Zwischenvariablen action ausgewertet und in ALLOW, BLOCK oder UNKNOWN_ACTION geändert. Dies sind gültige Werte für das UDM-Feld security_result.action. Das UDM-Feld security_result.action ist ein Aufzählungstyp, in dem nur bestimmte Werte gespeichert werden.

if ([action] == "TCP_DENIED" or [action] == "TCP_MISS" or [action] == "Denied" or [action] == "denied" or [action] == "Dropped") {
      mutate {
        replace => {
          "action" => "BLOCK"
        }
      }
   } else if ([action] == "TCP_TUNNEL" or [action] == "Accessed" or [action] == "Built" or [action] == "Retrieved" or [action] == "Stored") {
     mutate {
        replace => {
          "action" => "ALLOW"
        }
     }
   } else {
      mutate {
        replace => {
          "action" => "UNKNOWN_ACTION" }
      }
   }

Ziel-IP-Adresse transformieren

Im folgenden Beispiel wird nach einem Wert in der Zwischenvariablen tgtip gesucht. Wenn ein Wert gefunden wird, wird er mit einem vordefinierten Grok-Muster mit einem IP-Adressmuster abgeglichen. Wenn beim Abgleich des Werts mit einem IP-Adressmuster ein Fehler auftritt, wird mit der Funktion on_error die Eigenschaft not_valid_tgtip auf true gesetzt. Wenn der Abgleich erfolgreich ist, wird die Eigenschaft not_valid_tgtip nicht festgelegt.

if [tgtip] not in [ "","-" ] {
   grok {
     match => {
       "tgtip" => [ "%{IP:tgtip}" ]
     }
     overwrite => ["tgtip"]
     on_error => "not_valid_tgtip"
   }

Datentyp von returnCode und size ändern

Im folgenden Beispiel wird der Wert in der Variablen size in uinteger und der Wert in der Variablen returnCode in uinteger umgewandelt. Dies ist erforderlich, da die Variable size im UDM-Feld network.received_bytes gespeichert wird, das den Datentyp int64 enthält. Die Variable returnCode wird im UDM-Feld network.http.response_code gespeichert, das den Datentyp int32 enthält.

mutate {
  convert => {
    "returnCode" => "integer"
    "size" => "uinteger"
  }
}

Werte UDM-Feldern in einem Ereignis zuweisen

Nachdem Werte extrahiert und vorverarbeitet wurden, weisen Sie sie Feldern in einem UDM-Ereignisdatensatz zu. Sie können sowohl extrahierte als auch statische Werte einem UDM-Feld zuweisen.

Wenn Sie event.disambiguation_key ausfüllen, muss dieses Feld für jedes Ereignis eindeutig sein, das für das angegebene Log generiert wird. Wenn zwei verschiedene Ereignisse denselben disambiguation_key haben, führt dies zu unerwartetem Verhalten im System.

Die Parserbeispiele in diesem Abschnitt basieren auf dem vorherigen Beispiel für das Squid-Webproxy-Log.

Zeitstempel des Ereignisses speichern

Für jeden UDM-Ereignisdatensatz muss ein Wert für das UDM-Feld metadata.event_timestamp festgelegt sein. Im folgenden Beispiel wird der Zeitstempel des Ereignisses, der aus dem Log extrahiert wurde, in der integrierten Variablen @timestamp gespeichert. Google Security Operations speichert diesen Wert standardmäßig im UDM-Feld metadata.event_timestamp.

mutate {
  rename => {
    "when" => "timestamp"
  }
}

Ereignistyp festlegen

Für jeden UDM-Ereignisdatensatz muss ein Wert für das UDM-Feld metadata.event_type festgelegt sein. Dieses Feld ist ein Aufzählungstyp. Der Wert dieses Felds bestimmt, welche zusätzlichen UDM-Felder ausgefüllt werden müssen, damit der UDM-Datensatz gespeichert werden kann. Die Analyse und Normalisierung schlagen fehl, wenn eines der erforderlichen Felder keine gültigen Daten enthält.

replace => {
    "event.idm.read_only_udm.metadata.event_type" => "NETWORK_HTTP"
   }
}

Werte für username und method mit der Anweisung replace speichern

Die Werte in den Zwischenfeldern username und method sind Strings. Im folgenden Beispiel wird geprüft, ob ein gültiger Wert vorhanden ist. Wenn ja, wird der username Wert im principal.user.userid UDM-Feld und der method Wert im network.http.method UDM-Feld gespeichert.

if [username] not in [ "-" ,"" ] {
  mutate {
    replace => {
      "event.idm.read_only_udm.principal.user.userid" => "%{username}"
    }
  }
}

if [method] != "" {
  mutate {
    replace => {
      "event.idm.read_only_udm.network.http.method" => "%{method}"
    }
  }
}

action im UDM-Feld security_result.action speichern

Im vorherigen Abschnitt wurde der Wert in der Zwischenvariablen action ausgewertet und in einen der Standardwerte für das UDM-Feld security_result.action transformiert.

In den UDM-Feldern security_result und action wird jeweils ein Array von Elementen gespeichert. Daher müssen Sie beim Speichern dieses Werts etwas anders vorgehen.

Speichern Sie zuerst den transformierten Wert in einem Zwischenfeld security_result.action. Das Feld security_result ist ein übergeordnetes Feld von action.

mutate {
   merge => {
     "security_result.action" => "action"
   }
}

Speichern Sie dann das Zwischenfeld security_result.action im security_result UDM-Feld. Im UDM-Feld security_result wird ein Array von Elementen gespeichert. Der Wert wird also an dieses Feld angehängt.

 # save the security_result field
mutate {
  merge => {
    "event.idm.read_only_udm.security_result" => "security_result"
  }
}

Ziel-IP-Adresse und Quell-IP-Adresse mit der Anweisung merge speichern

Speichern Sie die folgenden Werte im UDM-Ereignisdatensatz:

• Wert in der Zwischenvariablen srcip im UDM-Feld principal.ip.
• Wert in der Zwischenvariablen tgtip im UDM-Feld target.ip.

In den UDM-Feldern principal.ip und target.ip wird jeweils ein Array von Elementen gespeichert. Die Werte werden also an jedes Feld angehängt.

In den folgenden Beispielen werden verschiedene Ansätze zum Speichern dieser Werte veranschaulicht. Im Transformationsschritt wurde die Zwischenvariable tgtip mit einem vordefinierten Grok-Muster mit einer IP-Adresse abgeglichen. Die folgende Beispielanweisung prüft, ob die Eigenschaft not_valid_tgtip auf „true“ gesetzt ist. Das bedeutet, dass der Wert von tgtip nicht mit einem IP-Adressmuster abgeglichen werden konnte. Wenn sie auf „false“ gesetzt ist, wird der Wert von tgtip im UDM-Feld target.ip gespeichert.

if ![not_valid_tgtip] {
  mutate {
    merge => {
      "event.idm.read_only_udm.target.ip" => "tgtip"
    }
  }
 }

Die Zwischenvariable srcip wurde nicht transformiert. Die folgende Anweisung prüft, ob ein Wert aus dem ursprünglichen Log extrahiert wurde. Wenn ja, wird der Wert im UDM-Feld principal.ip gespeichert.

if [srcip] != "" {
  mutate {
    merge => {
      "event.idm.read_only_udm.principal.ip" => "srcip"
    }
  }
}

Werte von url, returnCode und size mit der Anweisung rename speichern

Die folgende Beispielanweisung speichert die Werte mit der Anweisung rename:

• Die Variable url wird im UDM-Feld target.url gespeichert.
• Die Zwischenvariable returnCode wird im UDM-Feld network.http.response_code gespeichert.
• Die Zwischenvariable size wird im UDM-Feld network.received_bytes gespeichert.

mutate {
  rename => {
     "url" => "event.idm.read_only_udm.target.url"
     "returnCode" => "event.idm.read_only_udm.network.http.response_code"
     "size" => "event.idm.read_only_udm.network.received_bytes"
  }
}

UDM-Datensatz an die Ausgabe binden

Die letzte Anweisung in der Datenzuordnungsanweisung gibt die verarbeiteten Daten in einem UDM-Ereignisdatensatz aus.

mutate {
    merge => {
      "@output" => "event"
    }
  }

Vollständiger Parsercode

Dies ist das vollständige Parsercodebeispiel. Die Reihenfolge der Anweisungen entspricht nicht der Reihenfolge in den vorherigen Abschnitten dieses Dokuments, führt aber zur gleichen Ausgabe.

filter {

# initialize variables
  mutate {
    replace => {
      "event.idm.read_only_udm.metadata.product_name" => "Webproxy"
      "event.idm.read_only_udm.metadata.vendor_name" => "Squid"
      "not_valid_log" => "false"
      "when" => ""
      "srcip" => ""
      "action" => ""
      "username" => ""
      "url" => ""
      "tgtip" => ""
      "method" => ""
    }
  }

  # Extract fields from the raw log.
    grok {
      match => {
        "message" => [
          "%{NUMBER:when}\\s+\\d+\\s%{SYSLOGHOST:srcip} %{WORD:action}\\/%{NUMBER:returnCode} %{NUMBER:size} %{WORD:method} (?P<url>\\S+) (?P<username>.*?) %{WORD}\\/(?P<tgtip>\\S+).*"
        ]
      }
      overwrite => ["when","srcip","action","returnCode","size","method","url","username","tgtip"]
      on_error => "not_valid_log"
    }

  # Parse event timestamp
  if [when] != "" {
    date {
      match => [
        "when", "UNIX"
      ]
     }
   }

   # Save the value in "when" to the event timestamp
   mutate {
     rename => {
       "when" => "timestamp"
     }
   }

   # Transform and save username
   if [username] not in [ "-" ,"" ] {
     mutate {
       lowercase => [ "username"]
        }
      }
     mutate {
       replace => {
         "event.idm.read_only_udm.principal.user.userid" => "%{username}"
       }
     }


if ([action] == "TCP_DENIED" or [action] == "TCP_MISS" or [action] == "Denied" or [action] == "denied" or [action] == "Dropped") {
      mutate {
        replace => {
          "action" => "BLOCK"
        }
      }
   } else if ([action] == "TCP_TUNNEL" or [action] == "Accessed" or [action] == "Built" or [action] == "Retrieved" or [action] == "Stored") {
     mutate {
        replace => {
          "action" => "ALLOW"
        }
     }
   } else {
      mutate {
        replace => {
          "action" => "UNKNOWN_ACTION" }
      }
   }

  # save transformed value to an intermediary field
   mutate {
      merge => {
        "security_result.action" => "action"
      }
   }

    # save the security_result field
    mutate {
      merge => {
        "event.idm.read_only_udm.security_result" => "security_result"
      }
    }

   # check for presence of target ip. Extract and store target IP address.
   if [tgtip] not in [ "","-" ] {
     grok {
       match => {
         "tgtip" => [ "%{IP:tgtip}" ]
       }
       overwrite => ["tgtip"]
       on_error => "not_valid_tgtip"
     }

     # store  target IP address
     if ![not_valid_tgtip] {
       mutate {
         merge => {
           "event.idm.read_only_udm.target.ip" => "tgtip"
         }
       }
     }
   }

   # convert  the returnCode and size  to integer data type
   mutate {
     convert => {
       "returnCode" => "integer"
       "size" => "uinteger"
     }
   }

   # save  url, returnCode, and size
   mutate {
     rename => {
        "url" => "event.idm.read_only_udm.target.url"
        "returnCode" => "event.idm.read_only_udm.network.http.response_code"
        "size" => "event.idm.read_only_udm.network.received_bytes"
     }

     # set the event type to NETWORK_HTTP
     replace => {
        "event.idm.read_only_udm.metadata.event_type" => "NETWORK_HTTP"
     }
   }

   # validate and set source IP address
   if [srcip] != "" {
     mutate {
       merge => {
         "event.idm.read_only_udm.principal.ip" => "srcip"
       }
     }
   }

  # save  event to @output
   mutate {
     merge => {
       "@output" => "event"
     }
   }

} #end of filter

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