This page provides the reference for Transaction Events Formats including the new Universal format as well at legacy Format 1 to Format 4.

To learn more: Transaction Events Fields Reference

Transaction Events Universal

After several evolution of Transaction Events Formats with rigid list of fields, we are migrating to a fully customized and ever evolving Format called Transaction Events Universal.

With this transition we are allowing every customer to select the field they are interested in when events are exported.

Transaction Events Universal has been introduced with 197 fields and will be extended over the time. To avoid any production impact when new fields are added, we now require every Transaction Events export to define the list of fields.

Transaction Events Universal transition

Netskope Security Cloud features are migrating to Transaction Events Universal in phases:

SkopeIT: Transaction Events Universal only
Event Streaming Client:
- Most of the tenant are using Transaction Events Universal, only few tenants are using Legacy Format.
- Any new configuration is using TE Universal.
- All TE Universal Fields are supported
Log Streaming Direct to Cloud:
- Most of the tenant are using Transaction Events Universal, only few tenants are using Legacy Format.
- Any new configuration is using TE Universal.
- Note: We are working on extending the allowed field list to include all TE Universal fields.
Advanced Analytics: Migration to Transaction Events Universal in progress.
Splunk TA with PubSubLight (EOL): Legacy Format only
Cloud Exchange with PubSubLight Subscription (EOL): Legacy Format only
Cloud Exchange with Log Streaming Direct to Cloud:
- Most of the tenant are using Transaction Events Universal, only few tenants are using Legacy Format.
- Any new configuration is using TE Universal.
- Note: We are working on extending the allowed field list to include all TE Universal fields.

Transaction Events Universal key improvements

In addition to support future evolutions by adding new fields on demand without any impact, we completed the standardization of the existing data.

Standardized field content:

x-c-authn-user / cs-username no longer include the user IP when user is not authenticated.
User IP is still available in c-ip, x-cs-userip and x-policy-src-ip.
When user is not authenticated x-c-authn-user / cs-username will have the following values:
- Unauthenticated: a configured authentication bypass matched the Client request.
- Pending: this request require authentication and is being redirected to the IDP. This request is not yet authenticated.
- Exception: the POP could not authenticate this request.
All multi values (list) fields have been moved to semicolon ; separator, here is the full list of fields with multiple values:
- x-other-category (previous separator was , ) and x-policy-categories
- x-ssl-policy-categories
- x-cs-app-instance-tag (previous separator was ,) and x-cs-app-instance-tags
- x-cs-app-tags (previous separator was ,)
- x-cs-access-proxy
- x-tp-result
- x-tp-engine
- x-tp-malware-name
- x-tp-severity
- x-c-authz-groups
- x-rs-file-md5
- x-rs-file-sha256
date time fields have been standardized to epoch and YYYY-MM-DD hh:mm:ss
- Request start time (UTC/GMT timezone)
  - x-cs-timestamp: epoch format
  - date: YYYY-MM-DD
  - time: hh:mm:ss
- User local time
  - x-c-timezone: Timezone offset in string (eq +01:00)
  - x-c-local-timestamp: epoch format in local timezone
  - x-c-local-time: YYYY-MM-DD hh:mm:ss format in local timezone
- Remote server certificate start time (UTC/GMT timezone)
  - x-r-cert-start: epoch format
  - x-r-cert-startdate: YYYY-MM-DD hh:mm:ss format (previous format was MMM d HH:mm:ss yyyy z)
- Remote server certificate end time (UTC/GMT timezone)
  - x-r-cert-end: epoch format
  - x-r-cert-enddate: YYYY-MM-DD hh:mm:ss format (previous format was MMM d HH:mm:ss yyyy z)

Removed fields (will always be empty if exported):

x-category-id: Is now always empty, please use x-category to identify category
x-other-category-id: Is now always empty, please use x-policy-categories to identify categories
x-cs-domain-fronted-sni: Is now always empty. This field was designed to provide feedback on Domain Fronting protection (which detects mismatch between the SNI and the hostname received in the HTTP GET) but was not intuitive because customers had to compare with x-cs-sni. Instead, we introduced x-cs-ssl-fronting-error to identify Domain Fronting detection. x-cs-sni is also available to report on received SNI

Field name standardized (all fields are available to allow seamless transition to recommended field names):

c-ip, x-cs-userip and x-policy-src-ip have the same value, recommended field is x-policy-src-ip
s-ip and x-policy-dst-ip have the same value, recommended field is x-policy-dst-ip
cs-username and x-c-authn-user have the same value, recommended field is x-c-authn-user
cs-dns and cs-host have the same value, recommended field is cs-host
cs-uri is the concatenation of x-cs-uri-path and cs-uri-query, we recommend to export x-cs-uri-path and cs-uri-query in separate fields or use x-cs-url for the full URL.
x-s-country and x-r-country have the same value, recommended field is x-r-country
x-s-latitude and x-r-latitude have the same value, recommended field is x-r-latitude
x-s-longitude and x-r-longitude have the same value, recommended field is x-r-longitude
x-s-location and x-r-location have the same value, recommended field is x-r-location
x-s-region and x-r-region have the same value, recommended field is x-r-region
x-s-zipcode and x-r-zipcode have the same value, recommended field is x-r-zipcode
x-other-category and x-policy-categories have the same value, recommended field is x-policy-categories
x-cs-app-instance-tag and x-cs-app-instance-tags have the same value, recommended field is x-cs-app-instance-tags

Additional notes:

Warning: sc-bytes no longer includes Remote Server traffic. This data has moved to rs-bytes. Customers relying on sc-bytes for total bandwidth calculations must update their logic or they will see a drop in reported data. sc-bytes now includes POP to Client bytes, as defined by W3C ELFF standard.

Change of behavior per Format

This section provides the exact behavior change for each Legacy Format version.

Please note only the content of the fields have a change, all field names are unchanged and are all available. When migrating to TE Universal with the same list of fields, the following changes will apply. Please review based on your current exported format.

Format 1 to Universal

x-other-category: separator changed from , to ;
cs-username: IP is not used anymore when use in not authenticated, new values Unauthenticated, Pending and Exception
x-category-id: removed, will always be empty, please use x-category instead
x-other-category-id: removed, will always be empty, please use x-other-category instead
x-cs-domain-fronted-sni: removed, will always be empty, please consider adding x-cs-ssl-fronting-error instead
sc-bytes no longer includes Remote Server traffic. This data has moved to rs-bytes. Customers relying on sc-bytes for total bandwidth calculations must update their logic or they will see a drop in reported data.

Format 2 to Universal

x-other-category: separator changed from , to ;
cs-username: IP is not used anymore when use in not authenticated, new values Unauthenticated, Pending and Exception
x-category-id: removed, will always be empty, please use x-category instead
x-other-category-id: removed, will always be empty, please use x-other-category instead
x-cs-domain-fronted-sni: removed, will always be empty, please user x-cs-ssl-fronting-error instead
x-r-cert-startdate: YYYY-MM-DD hh:mm:ss format
x-r-cert-enddate: YYYY-MM-DD hh:mm:ss format
sc-bytes no longer includes Remote Server traffic. This data has moved to rs-bytes. Customers relying on sc-bytes for total bandwidth calculations must update their logic or they will see a drop in reported data.

Format 3 to Universal

x-other-category: separator changed from , to ;
cs-username: IP is not used anymore when use in not authenticated, new values Unauthenticated, Pending and Exception
x-category-id: removed, will always be empty, please use x-category instead
x-other-category-id: removed, will always be empty, please use x-other-category instead
x-cs-domain-fronted-sni: removed, will always be empty, please user x-cs-ssl-fronting-error instead
x-r-cert-startdate: YYYY-MM-DD hh:mm:ss format (previous format was MMM d HH:mm:ss yyyy z)
x-r-cert-enddate: YYYY-MM-DD hh:mm:ss format (previous format was MMM d HH:mm:ss yyyy z)
x-cs-app-instance-tag: separator changed from , to ;
x-cs-app-tags: separator changed from , to ;
sc-bytes no longer includes Remote Server traffic. This data has moved to rs-bytes. Customers relying on sc-bytes for total bandwidth calculations must update their logic or they will see a drop in reported data.

Format 4 to Universal

x-other-category: separator changed from , to ;
cs-username: IP is not used anymore when use in not authenticated, new values Unauthenticated, Pending and Exception
x-category-id: removed, will always be empty, please use x-category instead
x-other-category-id: removed, will always be empty, please use x-other-category instead
x-cs-domain-fronted-sni: removed, will always be empty, please user x-cs-ssl-fronting-error instead
x-r-cert-startdate: YYYY-MM-DD hh:mm:ss format (previous format was MMM d HH:mm:ss yyyy z)
x-r-cert-enddate: YYYY-MM-DD hh:mm:ss format (previous format was MMM d HH:mm:ss yyyy z)
x-cs-app-instance-tag: separator changed from , to ;
x-cs-app-tags: separator changed from , to ;

Transaction Events legacy Format 1 to Format 4

This section provide the reference for the fields available in each Format.

Format 1

Format 2

Format 2 is the same as Format 1 with the addition of the italicized fields below.

Format 3

Format 3 is the same as Format 2 with the addition of the italicized fields below.

#Fields: date time time-taken cs-bytes sc-bytes bytes c-ip s-ip cs-username cs-method cs-uri-scheme cs-uri-query cs-user-agent cs-content-type sc-status sc-content-type cs-dns cs-host cs-uri cs-uri-port cs-referer x-cs-session-id x-cs-access-method x-cs-app x-s-country x-s-latitude x-s-longitude x-s-location x-s-region x-s-zipcode x-c-country x-c-latitude x-c-longitude x-c-location x-c-region x-c-zipcode x-c-os x-c-browser x-c-browser-version x-c-device x-cs-site x-cs-timestamp x-cs-page-id x-cs-userip x-cs-traffic-type x-cs-tunnel-id x-category x-other-category x-type x-server-ssl-err x-client-ssl-err x-transaction-id x-request-id x-cs-sni x-cs-domain-fronted-sni x-category-id x-other-category-id x-sr-headers-name x-sr-headers-value x-cs-ssl-ja3 x-sr-ssl-ja3s x-ssl-bypass x-ssl-bypass-reason x-r-cert-subject-cn x-r-cert-issuer-cn x-r-cert-startdate x-r-cert-enddate x-r-cert-valid x-r-cert-expired x-r-cert-untrusted-root x-r-cert-incomplete-chain x-r-cert-self-signed x-r-cert-revoked x-r-cert-revocation-check x-r-cert-mismatch x-cs-ssl-fronting-error x-cs-ssl-handshake-error x-sr-ssl-handshake-error x-sr-ssl-client-certificate-error x-sr-ssl-malformed-ssl x-s-custom-signing-ca-error x-cs-ssl-engine-action x-cs-ssl-engine-action-reason x-sr-ssl-engine-action x-sr-ssl-engine-action-reason x-ssl-policy-src-ip x-ssl-policy-dst-ip x-ssl-policy-dst-host x-ssl-policy-dst-host-source x-ssl-policy-categories x-ssl-policy-action x-ssl-policy-name x-cs-ssl-version x-cs-ssl-cipher x-sr-ssl-version x-sr-ssl-cipher x-cs-src-ip-egress x-s-dp-name x-cs-src-ip x-cs-src-port x-cs-dst-ip x-cs-dst-port x-sr-src-ip x-sr-src-port x-sr-dst-ip x-sr-dst-port x-cs-ip-connect-xff x-cs-ip-xff x-cs-connect-host x-cs-connect-port x-cs-connect-user-agent x-cs-url x-cs-uri-path x-cs-http-version rs-status x-cs-app-category x-cs-app-cci x-cs-app-ccl x-cs-app-tags x-cs-app-suite x-cs-app-instance-id x-cs-app-instance-name x-cs-app-instance-tag x-cs-app-activity x-cs-app-from-user x-cs-app-to-user x-cs-app-object-type x-cs-app-object-name x-cs-app-object-id x-rs-file-type x-rs-file-category x-rs-file-language x-rs-file-size x-rs-file-md5 x-rs-file-sha256 x-error x-c-local-time x-policy-action x-policy-name x-policy-src-ip x-policy-dst-ip x-policy-dst-host x-policy-dst-host-source x-policy-justification-type x-policy-justification-reason x-sc-notification-name

Format 4

Format 4 is the same as Format 3 with the addition of the italicized fields below.