Forcepoint Web Security-Logs erfassen

Unterstützt in:

In diesem Dokument wird beschrieben, wie Sie Forcepoint Web Security-Logs mit Bindplane in Google Security Operations aufnehmen.

Hinweise

Prüfen Sie, ob folgende Voraussetzungen erfüllt sind:

  • Eine Google SecOps-Instanz
  • Ein Windows 2016- oder höher- oder Linux-Host mit systemd für den Bindplane-Agent
  • Wenn Sie den Agent hinter einem Proxy ausführen, müssen die Firewallports gemäß den Anforderungen des Bindplane-Agents geöffnet sein.
  • Privilegierter Zugriff auf die Forcepoint Web Security-Verwaltungskonsole oder den Forcepoint Security Manager
  • Netzwerkverbindung zwischen Forcepoint Web Security und dem Bindplane-Agent-Host
  • Forcepoint Web Security Version 7.8 oder höher (empfohlen für die Unterstützung des CEF-Formats)

Authentifizierungsdatei für die Aufnahme in Google SecOps abrufen

  1. Melden Sie sich in der Google SecOps-Konsole an.
  2. Rufen Sie die SIEM-Einstellungen > Collection Agents auf.
  3. Laden Sie die Authentifizierungsdatei für die Aufnahme herunter. Speichern Sie die Datei sicher auf dem System, auf dem BindPlane installiert wird.

Google SecOps-Kundennummer abrufen

  1. Melden Sie sich in der Google SecOps-Konsole an.
  2. Rufen Sie die SIEM-Einstellungen > Profile auf.
  3. Kopieren und speichern Sie die Kunden-ID aus dem Bereich Organisationsdetails.

BindPlane-Agent installieren

Installieren Sie den Bindplane-Agent auf Ihrem Windows- oder Linux-Betriebssystem gemäß der folgenden Anleitung.

Fenstereinbau

  1. Öffnen Sie die Eingabeaufforderung oder PowerShell als Administrator.
  2. Führen Sie dazu diesen Befehl aus:

    msiexec /i "https://github.com/observIQ/bindplane-agent/releases/latest/download/observiq-otel-collector.msi" /quiet
    

Linux-Installation

  1. Öffnen Sie ein Terminal mit Root- oder Sudo-Berechtigungen.
  2. Führen Sie dazu diesen Befehl aus:

    sudo sh -c "$(curl -fsSlL https://github.com/observiq/bindplane-agent/releases/latest/download/install_unix.sh)" install_unix.sh
    

Zusätzliche Installationsressourcen

BindPlane-Agent zum Erfassen von Syslog-Daten und Senden an Google SecOps konfigurieren

Sie können den Bindplane-Agent so konfigurieren, dass er Syslog-Nachrichten über TCP oder UDP empfängt. Wählen Sie das Protokoll aus, das am besten zu Ihrer Umgebung und Ihren Netzwerkanforderungen passt.

Protokoll auswählen

  • TCP (für Zuverlässigkeit empfohlen): Bietet Zustellung und ist für die meisten Umgebungen geeignet. Verwenden Sie TCP, wenn eine zuverlässige Log-Übermittlung wichtig ist und Sie sicherstellen möchten, dass aufgrund von Netzwerkproblemen keine Logs verloren gehen.
  • UDP (für Leistung empfohlen): Bietet eine geringere Latenz und weniger Overhead. Verwenden Sie UDP, wenn ein hoher Durchsatz erforderlich ist und gelegentliche Logverluste akzeptabel sind.

Bindplane-Agent konfigurieren

  1. Konfigurationsdatei aufrufen:

    • Suchen Sie die Datei config.yaml. Normalerweise befindet sie sich unter Linux im Verzeichnis /etc/bindplane-agent/ oder unter Windows im Installationsverzeichnis.
    • Öffnen Sie die Datei mit einem Texteditor (z. B. nano, vi oder Notepad).
  2. Bearbeiten Sie die Datei config.yaml mit der Konfiguration für das von Ihnen ausgewählte Protokoll:

    • Option A: TCP-Konfiguration (empfohlen)

      receivers:
         tcplog:
            # Replace with your desired port and IP address
            listen_address: "0.0.0.0:514"
            # Add operators if specific parsing is needed
            operators: []
      
      exporters:
      chronicle/chronicle_w_labels:
         compression: gzip
         # Adjust the path to the credentials file you downloaded in Step 1
         creds_file_path: '/path/to/ingestion-authentication-file.json'
         # Replace with your actual customer ID from Step 2
         customer_id: <YOUR_CUSTOMER_ID>
         # Replace with the appropriate regional endpoint
         endpoint: <CUSTOMER_REGION_ENDPOINT>
         # Log type for Forcepoint Web Security
         log_type: 'FORCEPOINT_WEBPROXY'
         raw_log_field: body
         # You can optionally add other custom ingestion labels here if needed
         ingestion_labels:
      
      service:
         pipelines:
            logs/forcepoint_tcp_to_chronicle:
               receivers:
                  - tcplog
               exporters:
                  - chronicle/chronicle_w_labels
      
    • Option B: UDP-Konfiguration

      receivers:
         udplog:
            # Replace with your desired port and IP address
            listen_address: "0.0.0.0:514"
            # Add operators if specific parsing is needed
            operators: []
      
      exporters:
         chronicle/chronicle_w_labels:
            compression: gzip
            # Adjust the path to the credentials file you downloaded in Step 1
            creds_file_path: '/path/to/ingestion-authentication-file.json'
            # Replace with your actual customer ID from Step 2
            customer_id: <YOUR_CUSTOMER_ID>
            # Replace with the appropriate regional endpoint
            endpoint: <CUSTOMER_REGION_ENDPOINT>
            # Log type for Forcepoint Web Security
            log_type: 'FORCEPOINT_WEBPROXY'
            raw_log_field: body
            # You can optionally add other custom ingestion labels here if needed
            ingestion_labels:
      
      service:
         pipelines:
            logs/forcepoint_udp_to_chronicle:
               receivers:
                  - udplog
               exporters:
                  - chronicle/chronicle_w_labels
      
      • Ersetzen Sie den Port und die IP-Adresse nach Bedarf in Ihrer Infrastruktur (Standard ist 0.0.0.0:514).

Bindplane-Agent neu starten, um die Änderungen zu übernehmen

  • Führen Sie den folgenden Befehl aus, um den Bindplane-Agent unter Linux neu zu starten:

    sudo systemctl restart bindplane-agent
    
  • Um den Bindplane-Agent unter Windows neu zu starten, können Sie entweder die Konsole Dienste verwenden oder den folgenden Befehl eingeben:

    net stop BindPlaneAgent && net start BindPlaneAgent
    
  • Führen Sie den folgenden Befehl aus, um zu prüfen, ob der Agent unter Linux ausgeführt wird:

    sudo systemctl status observiq-otel-collector
    
  • Führen Sie den folgenden Befehl aus, um zu prüfen, ob der Agent unter Windows ausgeführt wird:

    sc query observiq-otel-collector
    

Syslog-Weiterleitung in Forcepoint Web Security konfigurieren

Konfigurieren Sie Forcepoint Web Security so, dass Logs im CEF-Format (Common Event Format) an den BindPlane-Agenten weitergeleitet werden.

Forcepoint Security Manager verwenden

  1. Melden Sie sich mit Administratoranmeldedaten im Forcepoint Security Manager an.
  2. Rufen Sie die Einstellungen > Logging auf.
  3. Wählen Sie in der linken Navigationsleiste Log Servers (Protokollserver) aus.
  4. Klicken Sie auf Hinzufügen, um eine neue Logserverkonfiguration zu erstellen.
  5. Geben Sie die folgenden Konfigurationsdetails an:
    • Server Type (Servertyp): Wählen Sie Syslog Server (Syslog-Server) oder CEF Server (CEF-Server) aus.
    • Name: Geben Sie einen aussagekräftigen Namen ein, z. B. Google Security Operations Bindplane CEF.
    • Host: Geben Sie die IP-Adresse oder den Hostnamen des Bindplane-Agents ein.
    • Port: Geben Sie die Portnummer des Bindplane-Agents ein, z. B. 514.
    • Protokoll: Wählen Sie das Protokoll aus, das Ihrer Bindplane-Konfiguration entspricht:
      • Wählen Sie TCP aus, wenn Sie den tcplog-Empfänger in Bindplane konfiguriert haben (empfohlen).
      • Wählen Sie UDP aus, wenn Sie den udplog-Empfänger in Bindplane konfiguriert haben.
    • Format: Wählen Sie CEF (Common Event Format) aus.
    • Einrichtung: Wählen Sie Local0 oder eine andere verfügbare Einrichtung aus.
    • Schweregrad: Wählen Sie Informational (Informationen) aus, um alle Logebenen zu erfassen.
  6. Wählen Sie unter Log Categories (Protokollkategorien) oder Event Types (Ereignistypen) die weiterzuleitenden Ereignisse aus:
    • ☑ Web Access Logs (Transaktionsprotokolle)
    • ☑ Sicherheitsereignisse (Bedrohungserkennung)
    • ☑ Authentifizierungsereignisse (Nutzeranmeldung/-abmeldung)
    • ☑ Systemereignisse (System- und Konfigurationsänderungen)
    • Sie können auch Alle Ereignisse auswählen, um alle verfügbaren Protokolltypen weiterzuleiten.
  7. Optional: Konfigurieren Sie zusätzliche Einstellungen:
    • Batchgröße: Auf 1 für die Echtzeitweiterleitung oder höher für die Batchverarbeitung festlegen.
    • Nachrichtenformat: Achten Sie darauf, dass das CEF-Format ausgewählt ist.
    • Nutzerinformationen einbeziehen: Aktivieren Sie diese Option, um die Nutzeridentität in Protokolle aufzunehmen.
  8. Klicken Sie auf Verbindung testen, um die Verbindung zum BindPlane-Agent zu prüfen.
    • In den Bindplane-Agent-Logs sollte eine Testnachricht angezeigt werden.
    • Wenn der Test fehlschlägt, prüfen Sie die Netzwerkverbindung und die Firewallregeln.
  9. Klicken Sie auf Speichern, um die Konfiguration anzuwenden.
  10. Klicken Sie auf Bereitstellen, um die Konfiguration an alle Forcepoint Web Security-Gateways zu übertragen.

Forcepoint Web Security Appliance verwenden (direkte Konfiguration)

Wenn Sie die Konfiguration direkt auf der Appliance vornehmen:

  1. Melden Sie sich in der Verwaltungsoberfläche der Forcepoint Web Security Appliance an.
  2. Gehen Sie zu System > Log Server.
  3. Klicken Sie auf Hinzufügen oder Bearbeiten, um einen Protokollserver zu erstellen oder zu ändern.
  4. Geben Sie die folgenden Konfigurationsdetails an:
    • Serveradresse: Geben Sie die IP-Adresse des Bindplane-Agents ein.
    • Port: Geben Sie 514 (oder Ihren benutzerdefinierten Port) ein.
    • Protokoll: Wählen Sie TCP oder UDP aus, damit die Auswahl mit Ihrer Bindplane-Konfiguration übereinstimmt.
    • Format: Wählen Sie CEF oder Common Event Format aus.
    • Einrichtung: Wählen Sie Local0 aus.
  5. Wählen Sie unter Log-Typen die weiterzuleitenden Logs aus:
    • ☑ Zugriffslogs
    • ☑ Sicherheitsprotokolle
    • ☑ Administratorprotokolle
  6. Klicken Sie auf Übernehmen oder Speichern.
  7. Wenn Sie mehrere Geräte verwenden, wiederholen Sie diese Konfiguration für jedes Gerät.

CEF-Formatüberprüfung

  • Forcepoint Web Security sendet Logs im CEF-Format mit der folgenden Struktur:

    CEF:0|Forcepoint|Web Security|<version>|<event_id>|<event_name>|<severity>|<extensions>
    
    • Beispiel für ein CEF-Log:

       CEF:0|Forcepoint|Web Security|8.5|100|Web Request|5|src=192.168.1.100 dst=93.184.216.34 spt=54321 dpt=80 requestMethod=GET request=http://example.com/ cs1=Allow cs1Label=Action cs2=News and Media cs2Label=Category suser=john.doe@company.com
       ```
      

Der Google SecOps-Parser erwartet das CEF-Format und extrahiert die folgenden Schlüsselfelder:

  • src – Quell-IP-Adresse
  • dst – IP-Adresse des Ziels
  • spt: Quellport
  • dpt – Zielport
  • requestMethod – HTTP-Methode
  • request oder url – angeforderte URL
  • cs1 – Aktion (Zulassen/Blockieren)
  • cs2 – URL-Kategorie
  • suser – Nutzername

Prüfen, ob Logs aufgenommen werden

Prüfen Sie nach der Konfiguration, ob Logs von Forcepoint Web Security an Google SecOps übertragen werden:

  1. Prüfen Sie in der Forcepoint-Konsole, ob Logs gesendet werden:

    • Gehen Sie zu Einstellungen > Logging > Log Servers (Log-Server).
    • Prüfen Sie in der Spalte Status, ob für den konfigurierten Server Aktiv oder Verbunden angezeigt wird.
    • Unter Statistiken sehen Sie die Anzahl der gesendeten Logs.
  2. Prüfen Sie auf dem BindPlane-Agent-Host die Agent-Logs auf eingehende Syslog-Nachrichten:

    • Linux:

       sudo journalctl -u observiq-otel-collector -f
      
      • Suchen Sie nach Logeinträgen mit Nachrichten im CEF-Format:

           CEF:0|Forcepoint|Web Security|...
        
    • Windows:

      1. Wählen Sie die Windows-Ereignisanzeige unter Anwendungs- und Dienstprotokolle > observIQ aus.

      2. Prüfen Sie in Google SecOps, ob Logs angezeigt werden:

        • Klicken Sie auf Suche > UDM-Suche.
        • Verwenden Sie die folgende Abfrage:
        metadata.vendor_name = "Forcepoint" AND metadata.product_name = "Forcepoint Webproxy"
        
        • Stellen Sie den Zeitraum auf die letzten Stunden ein, z. B. Letzte Stunde.
        • Prüfen Sie, ob Ereignisse in den Ergebnissen angezeigt werden.
      3. Prüfen Sie, ob bestimmte Felder richtig geparst werden:

        metadata.vendor_name = "Forcepoint" AND principal.ip != "" AND target.url != ""
        
      4. Rufen Sie die SIEM-Einstellungen > Collection Agents auf, um Statistiken zur Aufnahme anzusehen:

        • Wählen Sie die Anzahl der Empfangenen Ereignisse aus.
        • Prüfen Sie, ob der Zeitstempel unter Zuletzt erfolgreich am aktuell ist.

Fehlerbehebung

In Google SecOps werden keine Logs angezeigt

Symptome: Der Bindplane-Agent wird ausgeführt, es werden jedoch keine Logs in Google SecOps angezeigt.

Mögliche Ursachen:

  1. Probleme mit der Netzwerkverbindung zwischen Forcepoint und dem Bindplane-Agent.
  2. Die Firewall blockiert den Syslog-Port.
  3. Protokoll stimmt nicht überein (TCP in Bindplane konfiguriert, aber UDP in Forcepoint oder umgekehrt).
  4. Falsche Bindplane-Agent-IP-Adresse oder ‑Port in der Forcepoint-Konfiguration.
  5. In Bindplane ist ein falscher regionaler Endpunkt konfiguriert.
  6. Das CEF-Format ist in Forcepoint nicht aktiviert.

Lösung:

  1. Netzwerkverbindung prüfen:

    # From Forcepoint gateway, test connectivity to BindPlane host
    telnet <BINDPLANE_IP> 514
    # Or for UDP
    nc -u <BINDPLANE_IP> 514
    
  2. Firewallregeln auf dem Bindplane-Host prüfen:

    # Linux - Allow port 514 TCP
    sudo ufw allow 514/tcp
    # Or for UDP
    sudo ufw allow 514/udp
    
    # Verify firewall status
    sudo ufw status
    
  3. Protokollübereinstimmung prüfen:

    • Prüfen Sie in BindPlane config.yaml auf tcplog oder udplog.
    • Prüfen Sie die Forcepoint-Logserverkonfiguration auf ein passendes Protokoll.
  4. Prüfen, ob das CEF-Format aktiviert ist:

    • Rufen Sie in Forcepoint Security Manager Einstellungen > Protokollierung > Protokollserver auf.
    • Prüfen Sie, ob Format auf CEF oder Common Event Format festgelegt ist.
  5. Regionalen Endpunkt prüfen:

  6. Prüfen Sie die Bindplane-Agent-Logs auf Fehler:

    sudo journalctl -u observiq-otel-collector -n 100 --no-pager
    

    Suchen Sie nach Fehlermeldungen wie:

    • connection refused – Netzwerk-/Firewallproblem
    • authentication failed – Problem mit Anmeldedaten
    • invalid endpoint – Problem mit regionalem Endpunkt

Fehler aufgrund von Protokollabweichungen

Symptome: Protokolle werden nicht empfangen, Verbindungsfehler im Forcepoint-Test oder Connection refused-Fehler in Bindplane-Protokollen.

Lösung:

  1. Das in Bindplane konfigurierte Protokoll (tcplog oder udplog) muss mit dem in Forcepoint konfigurierten Protokoll (TCP oder UDP) übereinstimmen.
  2. Wenn Sie TCP verwenden und Verbindungsprobleme auftreten, prüfen Sie, ob der Bindplane-Agent auf Anfragen wartet:

    # Linux - Check if port is listening
    sudo netstat -tuln | grep 514
    # Or
    sudo ss -tuln | grep 514
    
  3. Wenn der Port nicht überwacht wird, starten Sie den Bindplane-Agent neu.

Authentifizierungsfehler

Symptome: In den Bindplane-Agent-Logs werden Authentifizierungsfehler bei Google SecOps angezeigt.

Mögliche Ursachen:

  1. Falsche Kundennummer.
  2. Die Datei für die Authentifizierung der Aufnahme ist ungültig oder abgelaufen.
  3. Falscher Pfad zur Datei für die Authentifizierung bei der Aufnahme.
  4. Falscher regionaler Endpunkt.

Lösung:

  1. Prüfen Sie, ob die Kunden-ID in config.yaml mit der ID in den SIEM-Einstellungen > Profil übereinstimmt.
  2. Laden Sie die Datei für die Aufnahmeauthentifizierung noch einmal unter SIEM-Einstellungen > Erfassungs-Agents herunter.
  3. Prüfen Sie, ob der Pfad in config.yaml auf den richtigen Speicherort verweist.
  4. Prüfen Sie, ob der regionale Endpunkt mit der Region Ihrer Google SecOps-Instanz übereinstimmt.
  5. Prüfen Sie, ob der Bindplane-Agent Leseberechtigungen für die Authentifizierungsdatei hat:

    sudo chmod 644 /path/to/ingestion-authentication-file.json
    sudo chown root:root /path/to/ingestion-authentication-file.json
    

Logs werden angezeigt, Felder aber nicht geparst

Symptome: Protokolle werden in Google SecOps angezeigt, aber Felder wie principal.ip und target.url sind leer.

Mögliche Ursachen:

  1. Die Protokolle haben nicht das CEF-Format.
  2. Das CEF-Format ist fehlerhaft oder nicht standardisiert.
  3. Der Logtyp stimmt in der Bindplane-Konfiguration nicht überein.

Lösung:

  1. CEF-Format in Rohprotokollen prüfen:

    • Klicken Sie in Google SecOps auf Suchen > Rohlogsuche.
    • Suchen Sie nach aktuellen Forcepoint-Logs.
    • Prüfen Sie, ob die Logs mit CEF:0|Forcepoint|Web Security| beginnen.
  2. Wenn Protokolle nicht im CEF-Format vorliegen:

    • Ändern Sie in Forcepoint Format in CEF oder Common Event Format.
    • Stellen Sie die Konfiguration noch einmal bereit.
  3. Protokolltyp in BindPlane config.yaml prüfen:

    • Prüfen Sie, ob log_type: 'FORCEPOINT_PROXY' richtig eingestellt ist.
  4. Nach CEF-Feldnamensvarianten suchen:

    • In einigen Forcepoint-Versionen werden möglicherweise andere CEF-Feldnamen verwendet.
    • Prüfen Sie, ob die Feldnamen mit den erwarteten CEF-Erweiterungen in der UDM-Zuordnungstabelle übereinstimmen.

Hohe Latenz oder Verzögerungen bei Protokollen

Symptome: Logs werden in Google SecOps mit erheblicher Verzögerung (mehr als 5 Minuten) angezeigt.

Mögliche Ursachen:

  1. Netzwerklatenz zwischen Forcepoint und dem Bindplane-Agent.
  2. Ressourcenbeschränkungen für Bindplane-Agenten (CPU/Arbeitsspeicher).
  3. Die Batchverarbeitung ist in Forcepoint aktiviert.
  4. Google SecOps-Aufnahme-Backlog.

Lösung:

  1. Netzwerklatenz prüfen:

    ping <BINDPLANE_IP>
    # Check for high latency (>50ms) or packet loss
    
  2. Bindplane-Agent-Ressourcennutzung prüfen:

    top
    # Look for observiq-otel-collector process
    # Verify CPU < 80% and memory is available
    
  3. Passen Sie die Batcheinstellungen in Forcepoint an:

    • Gehen Sie zu Einstellungen > Logging > Log Servers (Log-Server).
    • Legen Sie für die Weiterleitung in Echtzeit Batch Size auf 1 fest.
    • Sie können das Batchintervall auch verkürzen, um die E-Mails häufiger zu senden.
  4. Wenn Ressourcen knapp sind, sollten Sie den Bindplane-Agent-Host skalieren (mehr CPU/Arbeitsspeicher).

  5. Wenn Sie UDP verwenden, prüfen Sie, ob die Netzwerkinfrastruktur den erforderlichen Durchsatz ohne Paketverlust unterstützt.

Forcepoint-Testverbindung schlägt fehl

Symptome: Wenn Sie in Forcepoint auf Test Connection (Verbindung testen) klicken, schlägt der Test fehl.

Lösung:

  1. Prüfen Sie, ob der Bindplane-Agent ausgeführt wird:

    sudo systemctl status observiq-otel-collector
    
  2. Prüfen Sie, ob der Bindplane-Agent den konfigurierten Port überwacht:

    sudo netstat -tuln | grep 514
    
  3. So deaktivieren Sie die Firewall vorübergehend, um einen Test durchzuführen:

    # Linux
    sudo ufw disable
    # Test connection from Forcepoint
    # Then re-enable
    sudo ufw enable
    
  4. Bindplane-Agent-Logs während des Tests prüfen:

    sudo journalctl -u observiq-otel-collector -f
    
    • Sie sollten einen eingehenden Verbindungsversuch sehen.
  5. Wenn der Test weiterhin fehlschlägt, prüfen Sie, ob IP-Adresse und Port in der Forcepoint-Konfiguration korrekt sind.

UDM-Zuordnungstabelle

Logfeld UDM-Zuordnung Logik
action security_result.summary Wenn action_msg nicht leer ist, wird sie security_result.summary zugeordnet. Andernfalls wird action, sofern es nicht leer ist, security_result.summary zugeordnet. Andernfalls wird act, sofern es nicht leer ist, security_result.summary zugeordnet.
action_msg security_result.summary Wenn action_msg nicht leer ist, wird sie security_result.summary zugeordnet. Andernfalls wird action, sofern es nicht leer ist, security_result.summary zugeordnet. Andernfalls wird act, sofern es nicht leer ist, security_result.summary zugeordnet.
app target.application Wenn destinationServiceName nicht leer ist, wird sie app_name zugeordnet. Andernfalls wird app, wenn es nicht leer ist und nicht „http“ oder „HTTP“ enthält, app_name zugeordnet. Schließlich wird app_name target.application zugeordnet.
bytes_in network.received_bytes Wenn in nicht leer ist, wird sie bytes_in zugeordnet. Schließlich wird bytes_in network.received_bytes zugeordnet.
bytes_out network.sent_bytes Wenn out nicht leer ist, wird sie bytes_out zugeordnet. Schließlich wird bytes_out network.sent_bytes zugeordnet.
cat security_result.category_details Wenn cat nicht leer ist, wird sie category zugeordnet. Schließlich wird category security_result.category_details zugeordnet.
category_no security_result.detection_fields.value Wenn category_no nicht leer ist, wird sie mit dem Schlüssel Category Number auf security_result.detection_fields.value abgebildet.
cn1 security_result.detection_fields.value Wenn cn1 nicht leer ist, wird sie mit dem Schlüssel Disposition Number auf security_result.detection_fields.value abgebildet.
ContentType target.file.mime_type Wenn contentType nicht leer ist, wird sie ContentType zugeordnet. Schließlich wird ContentType target.file.mime_type zugeordnet.
cs1 target_role.description cs1 ist target_role.description zugeordnet.
cs2 security_result.category_details Wenn cs2 nicht leer und nicht 0 ist, wird es mit dem Präfix Dynamic Category: auf security_result.category_details abgebildet.
cs3 target.file.mime_type cs3 ist target.file.mime_type zugeordnet.
description metadata.description Wenn description nicht leer ist, wird sie metadata.description zugeordnet.
destinationServiceName target.application Wenn destinationServiceName nicht leer ist, wird sie app_name zugeordnet. Schließlich wird app_name target.application zugeordnet.
deviceFacility metadata.product_event_type Wenn product_event und deviceFacility nicht leer sind, werden sie mit - verkettet und metadata.product_event_type zugeordnet. Andernfalls wird product_event auf metadata.product_event_type abgebildet.
disposition security_result.detection_fields.value Wenn disposition nicht leer ist, wird sie mit dem Schlüssel Disposition Number auf security_result.detection_fields.value abgebildet.
dst target.ip Wenn dst nicht leer und dvchost leer ist, wird dst dst_ip zugeordnet. Schließlich wird dst_ip target.ip zugeordnet.
dst_host target.hostname Wenn dst nicht leer und dvchost leer ist, wird dst dst_host zugeordnet. Schließlich wird dst_host target.hostname zugeordnet.
dst_ip target.ip Wenn dst nicht leer und dvchost leer ist, wird dst dst_ip zugeordnet. Schließlich wird dst_ip target.ip zugeordnet.
dst_port target.port Wenn dst nicht leer und dvchost leer ist, wird dst dst_port zugeordnet. Schließlich wird dst_port target.port zugeordnet.
duration network.session_duration.seconds Wenn duration nicht leer und nicht 0 ist, wird es network.session_duration.seconds zugeordnet.
dvchost intermediary.ip Wenn dvchost nicht leer ist, wird sie int_ip zugeordnet. Schließlich wird int_ip intermediary.ip zugeordnet, wenn es sich um eine gültige IP-Adresse handelt. Andernfalls wird es intermediary.hostname zugeordnet.
file_path target.file.full_path Wenn file_path nicht leer ist, wird sie target.file.full_path zugeordnet.
host principal.ip Wenn host nicht leer ist, wird sie src zugeordnet. Schließlich wird src principal.ip zugeordnet.
http_method network.http.method Wenn requestMethod nicht leer ist, wird sie http_method zugeordnet. Andernfalls wird method, sofern es nicht leer ist, http_method zugeordnet. Schließlich wird http_method network.http.method zugeordnet.
http_proxy_status_code network.http.response_code Wenn http_response leer oder 0 oder - ist und http_proxy_status_code nicht leer ist, wird es network.http.response_code zugeordnet.
http_response network.http.response_code Wenn http_response nicht leer und nicht 0 und nicht - ist, wird es network.http.response_code zugeordnet.
http_user_agent network.http.user_agent Wenn http_user_agent nicht leer und nicht - ist, wird es network.http.user_agent zugeordnet.
in network.received_bytes Wenn in nicht leer ist, wird sie bytes_in zugeordnet. Schließlich wird bytes_in network.received_bytes zugeordnet.
int_host intermediary.hostname Wenn int_ip nicht leer ist und int_host nicht leer ist und sich von int_ip unterscheidet, wird es intermediary.hostname zugeordnet.
int_ip intermediary.ip Wenn dvchost nicht leer ist, wird sie int_ip zugeordnet. Schließlich wird int_ip intermediary.ip zugeordnet, wenn es sich um eine gültige IP-Adresse handelt. Andernfalls wird es intermediary.hostname zugeordnet.
level target_role.name Wenn level nicht leer und role leer ist, wird level role zugeordnet. Schließlich wird role target_role.name zugeordnet.
log_level security_result.severity Wenn severity 1 ist oder log_level info enthält oder message notice enthält, wird security_result.severity auf INFORMATIONAL festgelegt. Wenn severity 7 ist, wird security_result.severity auf HIGH gesetzt.
loginID principal.user.userid Wenn loginID nicht leer ist, wird sie user zugeordnet. Wenn user nicht leer und nicht - ist und LDAP nicht enthält, wird es principal.user.userid zugeordnet.
method network.http.method Wenn requestMethod nicht leer ist, wird sie http_method zugeordnet. Andernfalls wird method, sofern es nicht leer ist, http_method zugeordnet. Schließlich wird http_method network.http.method zugeordnet.
NatRuleId security_result.detection_fields.value Wenn NatRuleId nicht leer ist, wird es mit dem Schlüssel NatRuleId auf security_result.detection_fields.value abgebildet.
out network.sent_bytes Wenn out nicht leer ist, wird sie bytes_out zugeordnet. Schließlich wird bytes_out network.sent_bytes zugeordnet.
pid target.process.pid Wenn pid nicht leer ist, wird sie target.process.pid zugeordnet.
policy target_role.description Wenn Policy nicht leer ist, wird sie policy zugeordnet. Wenn policy nicht leer und nicht - ist, wird es target_role.description zugeordnet.
Policy target_role.description Wenn Policy nicht leer ist, wird sie policy zugeordnet. Wenn policy nicht leer und nicht - ist, wird es target_role.description zugeordnet.
product_event metadata.product_event_type Wenn product nicht leer ist, wird sie product_event zugeordnet. Wenn product_event und deviceFacility nicht leer sind, werden sie mit - verkettet und metadata.product_event_type zugeordnet. Andernfalls wird product_event auf metadata.product_event_type abgebildet.
proxyStatus-code network.http.response_code Wenn http_response leer oder 0 oder - ist und http_proxy_status_code leer und proxyStatus-code nicht leer ist, wird es network.http.response_code zugeordnet.
refererUrl network.http.referral_url Wenn refererUrl nicht leer und nicht - ist, wird es network.http.referral_url zugeordnet.
requestClientApplication network.http.user_agent Wenn requestMethod nicht leer ist, wird sie http_user_agent zugeordnet. Schließlich wird http_user_agent network.http.user_agent zugeordnet.
requestMethod network.http.method Wenn requestMethod nicht leer ist, wird sie http_method zugeordnet. Schließlich wird http_method network.http.method zugeordnet.
role target_role.name Wenn level nicht leer und role leer ist, wird level role zugeordnet. Schließlich wird role target_role.name zugeordnet.
RuleID security_result.rule_id Wenn RuleID nicht leer ist, wird sie security_result.rule_id zugeordnet.
serverStatus-code network.http.response_code Wenn http_response leer oder 0 oder - ist und http_proxy_status_code leer und proxyStatus-code nicht leer ist, wird es network.http.response_code zugeordnet.
severity security_result.severity Wenn severity 1 ist oder log_level info enthält oder message notice enthält, wird security_result.severity auf INFORMATIONAL festgelegt. Wenn severity 7 ist, wird security_result.severity auf HIGH gesetzt.
spt principal.port Wenn spt nicht leer ist, wird sie src_port zugeordnet. Schließlich wird src_port principal.port zugeordnet.
src principal.ip Wenn src_host nicht leer ist, wird sie source_ip_temp zugeordnet. Wenn source_ip_temp eine gültige IP-Adresse und src leer ist, wird sie src zugeordnet. Wenn host nicht leer ist, wird sie src zugeordnet. Schließlich wird src principal.ip zugeordnet.
src_host principal.hostname Wenn src_host nicht leer ist, wird sie source_ip_temp zugeordnet. Wenn source_ip_temp keine gültige IP-Adresse ist, wird sie principal.hostname zugeordnet. Wenn source_ip_temp eine gültige IP-Adresse und src leer ist, wird sie src zugeordnet. Schließlich wird src principal.ip zugeordnet.
src_port principal.port Wenn src_port nicht leer ist, wird sie principal.port zugeordnet.
suser principal.user.userid Wenn loginID nicht leer ist, wird sie user zugeordnet. Wenn suser nicht leer ist, wird sie user zugeordnet. Wenn user nicht leer und nicht - ist und LDAP nicht enthält, wird es principal.user.userid zugeordnet.
url target.url Wenn url nicht leer ist, wird sie target.url zugeordnet.
user principal.user.userid Wenn loginID nicht leer ist, wird sie user zugeordnet. Wenn suser nicht leer ist, wird sie user zugeordnet. Andernfalls wird usrName, sofern es nicht leer ist, user zugeordnet. Wenn user nicht leer und nicht - ist und LDAP nicht enthält, wird es principal.user.userid zugeordnet.
usrName principal.user.userid Wenn loginID nicht leer ist, wird sie user zugeordnet. Wenn suser nicht leer ist, wird sie user zugeordnet. Andernfalls wird usrName, sofern es nicht leer ist, user zugeordnet. Wenn user nicht leer und nicht - ist und LDAP nicht enthält, wird es principal.user.userid zugeordnet.
when metadata.event_timestamp Wenn when nicht leer ist, wird es geparst und metadata.event_timestamp zugeordnet.
metadata.log_type Der Wert FORCEPOINT_WEBPROXY ist in metadata.log_type hartcodiert.
metadata.product_name Der Wert Forcepoint Webproxy ist in metadata.product_name hartcodiert.
metadata.vendor_name Der Wert Forcepoint ist in metadata.vendor_name hartcodiert.
network.application_protocol Wenn dst_port 80 ist, wird network.application_protocol auf HTTP gesetzt. Wenn dst_port 443 ist, wird network.application_protocol auf HTTPS gesetzt.
principal.user.group_identifiers Wenn user nicht leer und nicht - ist und LDAP enthält, wird der OU-Teil des Nutzerstrings extrahiert und principal.user.group_identifiers zugeordnet.
principal.user.user_display_name Wenn user nicht leer und nicht - ist und LDAP enthält, wird der Nutzername aus dem Nutzerstring extrahiert und principal.user.user_display_name zugeordnet.
security_result.action Wenn action_msg, action oder act nicht leer sind, wird sec_action basierend auf ihren Werten auf ALLOW oder BLOCK festgelegt. Schließlich wird sec_action security_result.action zugeordnet.
security_result.detection_fields.key Der Wert Disposition Number ist in security_result.detection_fields.key fest codiert, wenn disposition oder cn1 zugeordnet werden. Der Wert NatRuleId ist in security_result.detection_fields.key hartcodiert, wenn NatRuleId zugeordnet wird. Der Wert Category Number ist in security_result.detection_fields.key hartcodiert, wenn category_no zugeordnet wird.

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