Skip to main content
Connect a Zscaler Internet Access (ZIA) Cloud Nanolog Streaming Service (NSS) feed to send web logs to Living Security. This is a push integration. It is separate from the pull-based Zscaler Client Connector integration.

What this integration contributes

The web-log feed can identify the user and device involved in web activity and can contribute normalized activity such as blocked requests, malicious destinations, data-transfer blocks, and generative-AI use. The result depends on the fields and filters configured in Zscaler.

Before you begin

You need:
  • a ZIA Cloud NSS subscription and permission to manage Cloud NSS feeds
  • permission to manage integrations and access keys in Living Security
  • the region for the target Living Security organization
  • a secure place to store the generated access key
Zscaler requires a publicly trusted TLS certificate for an HTTPS Cloud NSS destination. The Living Security regional endpoints satisfy that requirement.

1. Prepare Living Security

1

Create the source and stream

Go to Settings → Integrations → Catalog, add Custom Push Source, and use these exact routing keys:The underscore in web_logs is required. A different pair can accept data but will not use the maintained Zscaler NSS interpreter.
2

Create an access key

Go to Settings → Access Keys, create an access key with Push Ingest scope, and copy its value immediately.
3

Build the destination URL

Use the URL for the Living Security region:
  • United States: https://api.us-east-1.livingsecurity.ai/api/v1/push-ingest/zscaler-nss-feed/web_logs
  • European Union: https://api.eu-west-1.livingsecurity.ai/api/v1/push-ingest/zscaler-nss-feed/web_logs

2. Create the Cloud NSS feed

In the current ZIA Admin Portal, go to Logs → Log Streaming → Internet Log Streaming — Nanolog Streaming Service, open Cloud NSS Feeds, and select Add Cloud NSS Feed. Menu labels can differ in older ZIA portal versions; Zscaler’s Cloud NSS web-log instructions are authoritative for the portal navigation. Configure the feed:
Do not use x-api-key and do not combine an old API key and secret with a period. Current Living Security push ingest accepts the scoped access key only in the Authorization: Bearer … header.
Use this exact, flat Feed Output Format on one line:
Keep every field at the top level. The retired Unify guide wrapped these fields inside an event object and added sourcetype. That envelope can be accepted as JSON but does not match the current interpreter, so it produces no people or activity.
Choose the timezone that your operations team expects when reviewing Zscaler events. Living Security parses the datetime value supplied by the feed.

3. Filter and enable the feed

Use Zscaler’s Policy Action and Policy Reason filters to send the web activity needed by your human-risk program. Avoid a low events-per-second setting that could discard logs during a traffic spike. If your organization must cap the feed, monitor both Zscaler delivery and Living Security Push History while tuning it. Save the feed, run Zscaler’s connectivity test, and then set Status to Enabled.

4. Verify delivery and interpretation

  1. In Living Security, open Settings → Integrations → Connected → zscaler-nss-feed.
  2. In Push History, confirm a recent web_logs run shows the expected record count.
  3. Confirm that recent Zscaler users or device IPs appear against the expected people and that web activity is available downstream.
  4. If the run is accepted but no activity appears, re-check the exact source, stream, and flat output format.

Troubleshooting

The API accepts at most 10,000 records and 10 MB per request, with 600 requests per 60 seconds per organization. See Custom Push Source API for the full response and retry contract.

Custom Push Source API

Review authentication, payload limits, responses, retries, and run verification.

Zscaler Client Connector

Connect the separate Client Connector API for device and posture data.