What log format is Expected by the forcepoint_webprotect key?

[harv-qq]

Ours isnt being recognised using the out of the box send it to splunk by the Forcepoint Content Gateways (configured via the FSM)

<159>%<:%b %d %H:%M:%S> %<-sourceServer> vendor=Forcepoint product=Security product_version=%<productVersion> action=%<dispositionString> severity=% category=%<categoryNumber> user=%<=loginID> loginID=%<=loginID> src_host=% src_port=%<clientSourcePort> dst_host=%<urlHost> dst_ip=% dst_port=% bytes_out=%<bytesSent> bytes_in=%<bytesReceived> http_response=%<serverStatusCode> http_method=% http_content_type=%<_contentType> http_user_agent=%<_userAgent> http_proxy_status_code=%<proxyStatusCode> reason=%<scanReasonString> disposition=%<dispositionNumber> policy=%<_policyNames> role=%<roleId> duration=%<scanDuration> url=% logRecordSource=%<logRecordSource>

what is SC4S expecting?

[rjha-splunk]

Can we have a real sample ( anonymised) ?

[harv-qq]

Forcepoints default profile is:

<159>%<:%b %d %H:%M:%S> %<-sourceServer> vendor=Forcepoint product=Security product_version=%<productVersion> action=%<dispositionString> severity=% category=%<categoryNumber> user=%<=loginID> loginID=%<=loginID> src_host=% src_port=%<clientSourcePort> dst_host=%<urlHost> dst_ip=% dst_port=% bytes_out=%<bytesSent> bytes_in=%<bytesReceived> http_response=%<serverStatusCode> http_method=% http_content_type=%<_contentType> http_user_agent=%<_userAgent> http_proxy_status_code=%<proxyStatusCode> reason=%<scanReasonString> disposition=%<dispositionNumber> policy=%<_policyNames> role=%<roleId> duration=%<scanDuration> url=% logRecordSource=%<logRecordSource>

[harv-qq]

if we change the profile to <159>%<:%Y-%m-%dT%H:%M:%S.%3N%:z> %<-sourceServer> vendor=Forcepoint product=Security product_version=% action=% severity=% category=% user=%<=loginID> loginID=%<=loginID> src_host=% src_port=% dst_host=% dst_ip=% dst_port=% bytes_out=% bytes_in=% http_response=% http_method=% http_content_type=%<_contentType> http_user_agent=%<_userAgent> http_proxy_status_code=% reason=% disposition=% policy=%<_policyNames> role=% duration=% url=% logRecordSource=%

Will that still work correctly?

[harv-qq]

or %Y-%m-%dT%H:%M:%S.%f%z

[harv-qq]

example current format, that currently isnt picked up by the forcepoint_webprotect key: LOCAL3.DEBUG: Oct 03 14:37:55 10...* vendor=Forcepoint product=Security product_version=..* action=permitted severity=1 category=2 user=* loginID=* src_host=10...* src_port=14430 dst_host=* dst_ip=... dst_port=443 bytes_out=8340 bytes_in=975 http_response=200 http_method=POST http_content_type=- http_user_agent=Mozilla/5.0_(Windows_NT_10.0;_Win64;_x64)AppleWebKit/537.36(KHTML,_like_Gecko)_Chrome/104.0.5112.81_Safari/537.36_Edg/104.0.1293.47 http_proxy_status_code=200 reason=- disposition=1026 policy=blahblah role=8 duration=86 url=https://blah.com logRecordSource=OnPrem\n

[harv-qq]

is there an update on this? What is the expected logging format that should be matched? We are running 2.30, i can see there is a possible fix for our issue in a later version 2.31.3 but will still like to know the expected log to match the forcepoint key

[rjha-splunk]

@harv-qq Apologies for missing it out, if the message is RFC5424 or RFC3164 there will no problem in assigning the right sourcetype and other default metadata, i just tested the same in version 2.37.0 ( latest) with above message formatted in RFC5424 i.e. '<5>1 2022-10-10T22:53:03Z redactedhostname vendor=Forcepoint product=Security product_version=..* action=permitted severity=1 category=2 user=* loginID=* src_host=10...* src_port=14430 dst_host=* dst_ip=... dst_port=443 bytes_out=8340 bytes_in=975 http_response=200 http_method=POST http_content_type=- http_user_agent=Mozilla/5.0_(Windows_NT_10.0;_Win64;_x64)AppleWebKit/537.36(KHTML,_like_Gecko)_Chrome/104.0.5112.81_Safari/537.36_Edg/104.0.1293.47 http_proxy_status_code=200 reason=- disposition=1026 policy=blahblah role=8 duration=86 url=https://blah.com logRecordSource=OnPrem' Please note the format is <pri><d> %Y-%m-%dT%H:%M:%S.%3N%:z <hostname> <earliermessage>