> ## Documentation Index
> Fetch the complete documentation index at: https://docs.livingsecurity.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Zscaler ZIA Cloud NSS setup

> Send Zscaler Internet Access web logs to Living Security through a Cloud NSS feed.

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](/integrations/catalog/zscaler-client-connector-custom) 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

<Steps>
  <Step title="Create the source and stream">
    Go to **Settings → Integrations → Catalog**, add **Custom Push Source**, and use these exact routing keys:

    | Field | Value |
    | - | - |
    | Data Source Name | `zscaler-nss-feed` |
    | Stream Name | `web_logs` |

    The underscore in `web_logs` is required. A different pair can accept data but will not use the maintained Zscaler NSS interpreter.
  </Step>

  <Step title="Create an access key">
    Go to **Settings → Access Keys**, create an access key with **Push Ingest** scope, and copy its value immediately.
  </Step>

  <Step title="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`
  </Step>
</Steps>

## 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](https://help.zscaler.com/zia/adding-cloud-nss-feeds-web-logs) are authoritative for the portal navigation.

Configure the feed:

| Zscaler field | Value |
| - | - |
| Feed Name | A recognizable name, such as `Living Security web logs` |
| NSS Type | **NSS for Web** |
| Status | **Disabled** while configuring; enable after verification |
| SIEM Rate | **Unlimited** unless your own policy requires a lower rate |
| SIEM Type | **Other** |
| OAuth 2.0 Authentication | **Disabled** |
| Max Batch Size | **512 KB** |
| API URL | The regional Living Security URL from step 1 |
| HTTP Header 1 | `Authorization` = `Bearer <access-key>` |
| HTTP Header 2 | `Content-Type` = `application/json` |
| Log Type | **Web Log** |
| Feed Output Type | **JSON** |
| JSON Array Notation | **Enabled** |
| Feed Escape Character | `,\"` |

<Warning>
  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.
</Warning>

Use this exact, flat **Feed Output Format** on one line:

```text theme={null}
{"datetime":"%d{yy}-%02d{mth}-%02d{dd} %02d{hh}:%02d{mm}:%02d{ss}","reason":"%s{reason}","event_id":"%d{recordid}","protocol":"%s{proto}","action":"%s{action}","transactionsize":"%d{totalsize}","responsesize":"%d{respsize}","requestsize":"%d{reqsize}","urlcategory":"%s{urlcat}","serverip":"%s{sip}","requestmethod":"%s{reqmethod}","refererURL":"%s{ereferer}","useragent":"%s{eua}","product":"NSS","location":"%s{elocation}","ClientIP":"%s{cip}","status":"%s{respcode}","user":"%s{elogin}","url":"%s{eurl}","vendor":"Zscaler","hostname":"%s{ehost}","clientpublicIP":"%s{cintip}","threatcategory":"%s{malwarecat}","threatname":"%s{threatname}","filetype":"%s{filetype}","appname":"%s{appname}","riskscore":"%d{riskscore}","department":"%s{edepartment}","urlsupercategory":"%s{urlsupercat}","appclass":"%s{appclass}","dlpengine":"%s{dlpeng}","urlclass":"%s{urlclass}","threatclass":"%s{malwareclass}","dlpdictionaries":"%s{dlpdict}","fileclass":"%s{fileclass}","bwthrottle":"%s{bwthrottle}","contenttype":"%s{contenttype}","unscannabletype":"%s{unscannabletype}","deviceowner":"%s{deviceowner}","devicehostname":"%s{devicehostname}","keyprotectiontype":"%s{keyprotectiontype}"}
```

<Warning>
  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.
</Warning>

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

| Symptom | Check |
| - | - |
| `401 Unauthorized` | Use `Authorization` with value `Bearer <access-key>`; rotate an expired or revoked key |
| `403 Forbidden` | Create the key with **Push Ingest** scope |
| `404 Not Found` | Register `zscaler-nss-feed` and `web_logs`, then use that exact URL |
| `400 Bad Request` | Enable JSON Array Notation and confirm the output is a top-level array of flat objects |
| `202` but no people or activity | Remove the legacy `sourcetype` / `event` wrapper and verify the exact routing keys |
| `429` | Back off temporary IP-level throttling and honor `Retry-After` when present |
| `503` | Keep the batch for retry, wait for `Retry-After`, and resend it unchanged |
| Connectivity test fails | Check the regional hostname, Bearer header, key status, and public TLS inspection policy |

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](/integrations/custom-push-source) for the full response and retry contract.

## Related

<CardGroup cols={2}>
  <Card title="Custom Push Source API" icon="arrow-up-from-bracket" href="/integrations/custom-push-source">
    Review authentication, payload limits, responses, retries, and run verification.
  </Card>

  <Card title="Zscaler Client Connector" icon="laptop" href="/integrations/catalog/zscaler-client-connector-custom">
    Connect the separate Client Connector API for device and posture data.
  </Card>
</CardGroup>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.