Forcepoint Web Security-Logs erfassen
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
systemdfü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
- Melden Sie sich in der Google SecOps-Konsole an.
- Rufen Sie die SIEM-Einstellungen > Collection Agents auf.
- 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
- Melden Sie sich in der Google SecOps-Konsole an.
- Rufen Sie die SIEM-Einstellungen > Profile auf.
- 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
- Öffnen Sie die Eingabeaufforderung oder PowerShell als Administrator.
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
- Öffnen Sie ein Terminal mit Root- oder Sudo-Berechtigungen.
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
- Weitere Installationsoptionen finden Sie in diesem Installationsleitfaden.
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
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,vioder Notepad).
- Suchen Sie die Datei
Bearbeiten Sie die Datei
config.yamlmit 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_labelsOption 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_labelsErsetzen 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-agentUm 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 BindPlaneAgentFühren Sie den folgenden Befehl aus, um zu prüfen, ob der Agent unter Linux ausgeführt wird:
sudo systemctl status observiq-otel-collectorFü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
- Melden Sie sich mit Administratoranmeldedaten im Forcepoint Security Manager an.
- Rufen Sie die Einstellungen > Logging auf.
- Wählen Sie in der linken Navigationsleiste Log Servers (Protokollserver) aus.
- Klicken Sie auf Hinzufügen, um eine neue Logserverkonfiguration zu erstellen.
- 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.
- Wählen Sie TCP aus, wenn Sie den
- 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.
- 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.
- Optional: Konfigurieren Sie zusätzliche Einstellungen:
- Batchgröße: Auf
1fü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.
- Batchgröße: Auf
- 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.
- Klicken Sie auf Speichern, um die Konfiguration anzuwenden.
- 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:
- Melden Sie sich in der Verwaltungsoberfläche der Forcepoint Web Security Appliance an.
- Gehen Sie zu System > Log Server.
- Klicken Sie auf Hinzufügen oder Bearbeiten, um einen Protokollserver zu erstellen oder zu ändern.
- 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.
- Wählen Sie unter Log-Typen die weiterzuleitenden Logs aus:
- ☑ Zugriffslogs
- ☑ Sicherheitsprotokolle
- ☑ Administratorprotokolle
- Klicken Sie auf Übernehmen oder Speichern.
- 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-Adressedst– IP-Adresse des Zielsspt: Quellportdpt– ZielportrequestMethod– HTTP-Methoderequestoderurl– angeforderte URLcs1– Aktion (Zulassen/Blockieren)cs2– URL-Kategoriesuser– Nutzername
Prüfen, ob Logs aufgenommen werden
Prüfen Sie nach der Konfiguration, ob Logs von Forcepoint Web Security an Google SecOps übertragen werden:
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.
Prüfen Sie auf dem BindPlane-Agent-Host die Agent-Logs auf eingehende Syslog-Nachrichten:
Linux:
sudo journalctl -u observiq-otel-collector -fSuchen Sie nach Logeinträgen mit Nachrichten im CEF-Format:
CEF:0|Forcepoint|Web Security|...
Windows:
Wählen Sie die Windows-Ereignisanzeige unter Anwendungs- und Dienstprotokolle > observIQ aus.
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.
Prüfen Sie, ob bestimmte Felder richtig geparst werden:
metadata.vendor_name = "Forcepoint" AND principal.ip != "" AND target.url != ""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:
- Probleme mit der Netzwerkverbindung zwischen Forcepoint und dem Bindplane-Agent.
- Die Firewall blockiert den Syslog-Port.
- Protokoll stimmt nicht überein (TCP in Bindplane konfiguriert, aber UDP in Forcepoint oder umgekehrt).
- Falsche Bindplane-Agent-IP-Adresse oder ‑Port in der Forcepoint-Konfiguration.
- In Bindplane ist ein falscher regionaler Endpunkt konfiguriert.
- Das CEF-Format ist in Forcepoint nicht aktiviert.
Lösung:
Netzwerkverbindung prüfen:
# From Forcepoint gateway, test connectivity to BindPlane host telnet <BINDPLANE_IP> 514 # Or for UDP nc -u <BINDPLANE_IP> 514Firewallregeln 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 statusProtokollübereinstimmung prüfen:
- Prüfen Sie in BindPlane
config.yamlauftcplogoderudplog. - Prüfen Sie die Forcepoint-Logserverkonfiguration auf ein passendes Protokoll.
- Prüfen Sie in BindPlane
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.
Regionalen Endpunkt prüfen:
- Prüfen Sie, ob der
endpointinconfig.yamlmit der Region Ihrer Google SecOps-Instanz übereinstimmt. - Weitere Informationen finden Sie in der Dokumentation zu regionalen Endpunkten.
- Prüfen Sie, ob der
Prüfen Sie die Bindplane-Agent-Logs auf Fehler:
sudo journalctl -u observiq-otel-collector -n 100 --no-pagerSuchen Sie nach Fehlermeldungen wie:
connection refused– Netzwerk-/Firewallproblemauthentication failed– Problem mit Anmeldedateninvalid 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:
- Das in Bindplane konfigurierte Protokoll (
tcplogoderudplog) muss mit dem in Forcepoint konfigurierten Protokoll (TCP oder UDP) übereinstimmen. 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 514Wenn 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:
- Falsche Kundennummer.
- Die Datei für die Authentifizierung der Aufnahme ist ungültig oder abgelaufen.
- Falscher Pfad zur Datei für die Authentifizierung bei der Aufnahme.
- Falscher regionaler Endpunkt.
Lösung:
- Prüfen Sie, ob die Kunden-ID in
config.yamlmit der ID in den SIEM-Einstellungen > Profil übereinstimmt. - Laden Sie die Datei für die Aufnahmeauthentifizierung noch einmal unter SIEM-Einstellungen > Erfassungs-Agents herunter.
- Prüfen Sie, ob der Pfad in
config.yamlauf den richtigen Speicherort verweist. - Prüfen Sie, ob der regionale Endpunkt mit der Region Ihrer Google SecOps-Instanz übereinstimmt.
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:
- Die Protokolle haben nicht das CEF-Format.
- Das CEF-Format ist fehlerhaft oder nicht standardisiert.
- Der Logtyp stimmt in der Bindplane-Konfiguration nicht überein.
Lösung:
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.
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.
Protokolltyp in BindPlane
config.yamlprüfen:- Prüfen Sie, ob
log_type: 'FORCEPOINT_PROXY'richtig eingestellt ist.
- Prüfen Sie, ob
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:
- Netzwerklatenz zwischen Forcepoint und dem Bindplane-Agent.
- Ressourcenbeschränkungen für Bindplane-Agenten (CPU/Arbeitsspeicher).
- Die Batchverarbeitung ist in Forcepoint aktiviert.
- Google SecOps-Aufnahme-Backlog.
Lösung:
Netzwerklatenz prüfen:
ping <BINDPLANE_IP> # Check for high latency (>50ms) or packet lossBindplane-Agent-Ressourcennutzung prüfen:
top # Look for observiq-otel-collector process # Verify CPU < 80% and memory is availablePassen 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
1fest. - Sie können das Batchintervall auch verkürzen, um die E-Mails häufiger zu senden.
Wenn Ressourcen knapp sind, sollten Sie den Bindplane-Agent-Host skalieren (mehr CPU/Arbeitsspeicher).
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:
Prüfen Sie, ob der Bindplane-Agent ausgeführt wird:
sudo systemctl status observiq-otel-collectorPrüfen Sie, ob der Bindplane-Agent den konfigurierten Port überwacht:
sudo netstat -tuln | grep 514So deaktivieren Sie die Firewall vorübergehend, um einen Test durchzuführen:
# Linux sudo ufw disable # Test connection from Forcepoint # Then re-enable sudo ufw enableBindplane-Agent-Logs während des Tests prüfen:
sudo journalctl -u observiq-otel-collector -f- Sie sollten einen eingehenden Verbindungsversuch sehen.
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