Zscaler ZIA
This article discusses Vectra's support of Zscaler Internet Access (ZIA) and provides details for use with both PCAP ingestion and on-prem capture.
Special Note Regarding Zscaler/Vectra SASE Press Release
If you found this article as a result of the recent Vectra AI June 2025 press release above, please note that the new functionality with Zscaler SASE solutions is currently in Public Preview at Vectra (Early Access at Zscaler) and is planned to become Generally Available (GA) soon. The new PCAP ingestion functionality ingests ZIA traffic captured by Zscaler in their cloud through a Vectra vSensor deployed specifically for this remote user traffic that isn't present on the corporate network where other Vectra Sensors already capture traffic. ZIA is already supported when used inside corporate networks where Vectra Sensors are capturing the traffic. ZPA traffic is also already supported though a different integration.
For more details on SASE/SSE support in general please see SASE/SSE Deployment Guide Links.
Applicability
For customers wishing to secure ZIA traffic, Vectra has two options. They are on-prem capture which is an older method that has been supported for several years and the new PCAP ingestion method that is currently in public preview for Vectra (Early Access for Zscaler). If your ZIA deployment is using ZIA Z-Tunnel 1.0 on your premises (no remote users, and no other sources, or GRE/IPSEc), then the on-prem capture option meets the use case. This option is easier to deploy and has less cost. If your ZIA deployment is using Z-Tunnel 2.0 or includes remote users then the new PCAP ingestion option is required.
If the use case is securing ZPA traffic, please see details for Vectra's ZPA integration here: Zscaler Private Access (ZPA) Log Ingestion Configuration. For more details on SASE/SSE support in general please see SASE/SSE Deployment Guide Links. That article provides high level guidance for integration with supported SASE/SSE vendors and links to the specific guides for each vendor and integration.
ZIA use and how it works with Vectra generally falls into two categories:
Remote - Devices running ZIA are being used off the corporate network.
On-Prem - Devices running ZIA are being used inside the corporate network.
Vectra deployments can have visibility of ZIA traffic in two different ways:
On-Prem Capture - Vectra sensors capturing traffic inside the corporate network.
PCAP Ingestion - A Vectra sensor deployed in AWS that retrieves and ingests PCAPNG traffic from an S3 bucket that Zscaler is writing PCAPs of ZIA traffic into using the Zscaler Administration > Resources > Traffic Capture functionality.
For most situations, it is recommended to use PCAP ingestion for the following reasons:
Both remote and on-prem ZIA traffic can be captured and analyzed by Vectra.
Z-Tunnel 2.0 is fully supported.
Traffic is encrypted in transit to and from Zscaler and Vectra receives a copy of the traffic that goes to and from the internet through Zscaler.
All Vectra AI detection models can fire
When capturing on-prem, ZIA IPs are classified as proxy IPs and some detection models cannot fire and spurious detections can be created.
It is possible to capture ZIA traffic both on-prem and via PCAP ingestion. It should be noted that you will see two different host objects created in Vectra for these ZIA devices and detections will be created and tied to both host objects.
ZIA-device_id - These hosts will show as result of PCAP ingestion and are named by the ZIA device ID.
On-prem capture host name - Host names will vary based on observed host naming artifacts and do not follow any specific format other than the standard your organization uses for host naming.
For more details on how Vectra names hosts, please see Understanding Vectra Detect Host Naming
Details for PCAP Ingestion
Expand/Collapse for Details
Architecture and Requirements
The diagram above shows high level details for the PCAP ingestion option for ZIA integration. Please expand/collapse for additional details below:
Requirements
A supported AWS region is chosen by the customer for the S3 bucket required to store the Zscaler PCAPs.
A Vectra AWS vSensor (click for deployment guide) is deployed in the same region that the bucket will be deployed to.
The vSensor must be able to reach the following AWS services in the same region as the S3 bucket:
Amazon S3 (to download PCAPs).
Amazon SQS (to poll for new file notifications).
You do not need to allow direct access to Amazon SNS – SNS is used internally (S3 → SNS → SQS).
Any controls you have in place must allow the vSensor to use HTTPS (TCP 443) to the internet or to region-specific VPC endpoints.
For region-specific endpoints and full details:
Your ZIA deployment must be licensed for the full packet capture feature that provides PCAP files for Vectra to analyze.
There will be some cost from Zscaler associated with this feature.
Your Vectra deployment must be licensed for the IPs that will be analyzed.
Adding remote user traffic via PCAP ingestion will increase the number of IPs seen in your Vectra deployment.
Please coordinate with your Vectra account team for licensing questions.
The AWS costs will be incurred in the AWS account used for your deployment.
This will primarily be costs for the S3 bucket and egress costs for the metadata transferred to your Vectra Brain for analysis (typically ~0.5% of original traffic).
These costs are expected to be very small and less than the licensing cost for the Zscaler packet capture feature.
PCAPs age out after 1 day and are not retained in the S3 bucket long term.
An AWS IAM user and access token that can be used by Zscaler to access and write to the S3 bucket
After running Vectra's CloudFormation template, the S3 bucket policy will need to be modified so that Zscaler can access it and write to it from the hub IP ranges used by your Zscaler deployment
To do the configuration in Vectra, the user must have a role that contains the ability to edit the "Remote Users" permission. Default role permissions are as follows:
Role
View Remote Users
Edit Remote Users
Admin
Yes
Yes
Auditor
Yes
No
Read-Only
Yes
No
Restricted Admin
Yes
Yes
Security Analyst
Yes
Yes
Setting Admin
Yes
Yes
Super Admin
Yes
Yes
AWS Resource Creation
Vectra provides a CloudFormation (CFN) template to create the AWS resources required to support the Zscaler PCAP ingestion configuration. Please see the attachment titled "Vectra_ZIA_AWS_PCAP_Setup.yaml" to this article for the template.
The CFN template creates the following resources:
S3 Bucket - To temporarily hold the PCAPNG files created by Zscaler so that Vectra can then retrieve and ingest them from its vSensor dedicated for this purpose.
A lifecycle rule is also created that expires objects after 1 day.
SNS Topic and Policy - Simple Notification Service topic to receive S3 event notifications when Zscaler publishes PCAP files to the bucket. The policy grants S3 permissions to publish messages to the topic.
SNS Subscription - Connects the SNS topic to the SQS queue.
**SQS Queue and Policy **- Simple Queue Service to receive SNS notifications for Vectra to process. The policy grants SNS permission to send messages to the SQS queue.
SQS Dead Letter Queue (DLQ) - Holds SQS messages that cannot be processed after 2 attempts. This is used to help with the retry logic and for support troubleshooting.
IAM Instance Role and Profile - IAM role that the vSensor will assume to be able to poll SQS for new messages and read from the S3 bucket. The instance profile is associated with the instance role.
For the Zscaler setup, some manual steps will need to be taken in AWS after the Vectra CFN template deployment is completed:
A "vectra" folder will need to be created in the S3 bucket.
An IAM user with programmatic access using an Access Key ID and Secret Access Key will need to be created for Zscaler to use when writing PCAPs to the bucket.
Integration Flow
Zscaler uploads a PCAP file to the S3 bucket.
The S3 bucket sends a notification to the SNS topic.
The SNS topic forwards the notification to the SQS queue.
Vectra retrieves the message from the SQS queue and downloads the files from the S3 bucket and then ingests the PCAP.
Deploying the Integration
Overview of steps:
Deploy a dedicated Vectra vSensor in the AWS region you intend to use for the Zscaler PCAP ingestion.
Run the Vectra CloudFormation template to create the S3 bucket, SNS topic/policy/subscription, SQS queue/policy/DLQ, and IAM instance role and profile.
Create a folder called "vectra" in the S3 bucket that will be used to store the PCAPs and save the URL for later configuration in Zscaler.
Modify the IAM role for Vectra vSensor in AWS by selecting the EC2InstanceRole that was created by Vectra's CloudFormation template in the last step.
Create IAM user, setup and retrieve the AWS Access Key ID and Secret Access Key for Zscaler configuration, and edit the bucket policy.
Reserve SASE IP range(s) for use by the Zscaler integration in the Vectra Brain.
Configure Zscaler as a SASE integration in the Vectra Brain.
Configure Zscaler Traffic Capture in your Zscaler console.
Please expand or collapse each section below for instructions for each part of the overall deployment process.
1. Deploying the Dedicated Vectra vSensor
Please Expand/Collapse for Details
You must choose an AWS region for the Zscaler PCAP ingestion integration. This region will be used for both the Vectra vSensor deployment that will be dedicated for this ingestion method and for the S3 bucket that will temporarily house the PCAPs created by Zscaler before the Vectra vSensor can ingest them. If you do not have an AWS account, you must create one for this integration. There are no other supported cloud providers that can be used for the integration.
Vectra AWS vSensor Details:
Please see the above guide for details on how to deploy the AWS vSensor. Deploying the vSensor in the chosen region and pairing it to your Vectra Brain will follow the same process that is used for any vSensor.
Any vSensor you use for Zscaler PCAP ingestion must be dedicated to that purpose. Once the feature is enabled, the vSensor will no longer listen for traffic on any of its capture interfaces. It is ok to use an existing vSensor but you must understand that it will no longer be able to process the traffic it processed before the feature was enabled. For most customer situations, Vectra strongly recommends that you deploy a new vSensor that is dedicated to Zscaler PCAP ingestion.
Supported vSensor Instance Type
r5n.4xlarge - This vSensor supports approximately 1Gbps Sensor/Match throughput when used with Zscaler PCAP ingestion.
It is recommended that you configure Zscaler to only create PCAPs of traffic that are necessary to analyze from a security perspective. This will help with scalability of traffic analysis for larger ZIA implementations.
For details on which traffic types that can be filtered, please see Vectra Platform Network Traffic Recommendations or the Vectra NDR (Detect) and Network Identity Architecture Overview.
In general, it is normally safe to filter out the following:
Video Streaming or Multicast
Multiprotocol Label Switching (MPLS)
Core routing protocols
Session Initiation Protocol (SIP)
High-performance computing (HPC) workloads high in bandwidth
HPC workloads that are well isolated
Storage array network file systems (SMB OK)
High-bandwidth backup data
Additional guidance will be given in Step 8 where configuring traffic capture functionality in Zscaler will be covered.
At this time, the r5n.4xlarge is the only vSensor instance type that has been validated by Vectra engineering. Additional vSensors may be supported in the future. Please contact your Vectra account team if you would prefer a different vSensor instance to be qualified.
Once you have successfully deployed and paired your AWS vSensor with your Vectra Brain, you can move on to the next step.
2. Running the Vectra CloudFormation Template
Please Expand/Collapse for Details
As per the architecture overview above running the Vectra supplied CFN template will create an S3 bucket, SNS topic, policy, and subscription, SQS queue, policy, and DLQ, and an instance role and profile.
If you have permissions issues running the template, please work with your AWS admin and expand the below for the specific permissions required by the user who will run the CFN template:
Please Expand/Collapse for Details
To get started, download the CFN template "Vectra_ZIA_AWS_PCAP_Setup.yaml" from the attachment list at the right side of this article and then follow these steps:
In your AWS console, navigate to "CloudFormation", click "Create Stack", and then click "With new resources (standard)" in the dropdown.
In the "Create stack" flow, pick "Choose an existing template" and "Upload a template file" and then upload the "Vectra_ZIA_AWS_PCAP_Setup.yaml" file you downloaded earlier and click "Next"
Next you will need to enter a stack name and a resource prefix that defaults to "vectra". Feel free to use any allowed stack name and edit the resource prefix if desired. The resource prefix will be used in naming of the created resources. For example, if your resource prefix is "vectra" then the S3 bucket would be named "vectrabucket", the SNS topic would be name "vectratopic", etc.
Please note that the generated names must be unique or the stack creation will fail and you will need to start the stack creation process over again.
On the "Configure stack options" step, most options are not required but feel free to enter any tags you desire for example
It is recommended to choose the "Delete all newly created resources" option under the "Stack Failure Options" section.
In the "Capabilities" section, you must click the checkbox to acknowledge that AWS CloudFormation might create IAM resources with custom names.
Click "Next" when you are ready to move on to deploying the stack.
On the "Review and create" step, review your selections, and when ready, click "Submit" in the bottom right hand corner.
While the stack creation process progresses, you can click the refresh button to see updates.
Once you see the "CREATE_COMPLETE" message in the stacks list on the left, this step is completed and you can move on to the next step.
You should keep this tab in your browser open for easy access to the resources created for later steps.
The "Resources" tab of your stack will show the resources that were created and the "Physical ID" column provides names and links to the resources.
You will need to keep track of the following:
The "Bucket Identifier String" from the "Physical ID" column. This will need to be provided in the Vectra UI later.
In this example the bucket identifier string is "vectraziabucket"
The bucket link can be used in the next step to navigate to the bucket so that you can create the required "vectra" folder in the bucket.
The "SQS Queue URL" from the "Physical ID" column. This will need to be provide in the Vectra UI later.
In this example the SQS queue url is "https://sqs.us-west-2.amazonaws.com/257321424819/vectraziaqueue".
As long as you remember the "ResourcePrefix" used when creating the stack, you can always find these items again later.
3. Creating S3 Bucket Folder and Retrieving the URL
Please Expand/Collapse for Details
The Zscaler integration with Vectra requires a folder called "vectra" to exist in the S3 bucket and for the URL for that folder to be input in the Zscaler console during setup.
Navigate to the S3 bucket created in Step 2.
You can simply click the bucket name in the resources tab of the stack you just created, or just navigate to S3 and find the bucket by the ResourcePrefix you used.
Create a folder in the root of your bucket called "vectra" and do NOT specify any encryption key.
To copy the URL, select your "vectra" folder and then click the "Copy URL" button.
Save this for later use.
In our example, the "S3 Folder URL" that will later be entered in your Zscaler console during setup is: https://vectraziabucket.s3.us-west-2.amazonaws.com/vectra/
Please move on to the next step.
4. Modify vSensor IAM Role
Please Expand/Collapse for Details
The IAM role that was created by the CFN template needs to be assigned to the vSensor EC2 instance that you deployed earlier so that it can read messages from the SQS queue and read the PCAP files from the S3 bucket.
Navigate to EC2 in your AWS console, click on "Instances", and select the Vectra vSensor that you created earlier (either by clicking its instance ID or ticking the check box on the left hand side).
Select "Actions" in the upper right hand corner, and from the dropdown, select "Security", then "Modify IAM role".
From the "IAM Role" dropdown, select the IAM role with the ResourcePrefix that matches the one specified when creating the deployment.
Next click "Update IAM role".
This should apply instantly, and the vSensor should now be able to access the resources we deployed earlier. However, the sensor doesn't yet have an understanding of where it should be looking to pull down PCAP files. This will be configured in Step 7.
5. Create IAM User, Retrieve Access Key ID / Secret Access Key, and Update Bucket Policy
Please Expand/Collapse for Details
On the Zscaler side of the integration, access to the S3 folder needs to be authenticated by AWS Access Key ID and Secret Access Key that is tied to an IAM user. Vectra's CFN template only configures the required resources for the Vectra side of the integration. The IAM user and programmatic access key details need to be created manually. Additionally, an S3 bucket policy will need to be edited to allow the Zscaler IAM user to be able to write the PCAP files to the S3 bucket folder. Further, the policy should be configured to only allow writing to the bucket from the ZIA hub IPs used for your ZIA deployment.
Creating a Dedicated IAM User for Zscaler
Navigate to the IAM section of the AWS Console.
Click "Users" and then "Add user".
Name the user as desired (e.g. s3-zscaler).
Click 'Next' to assign permissions.
Attach a Policy to the IAM User
Attach the following policy. Replace "vectraziabucket" with your actual bucket name if different.
Save the Access Key ID and Secret Access Key
After the user is created, save the Access Key ID and Secret Access Key for later configuration in the Zscaler console.
Add an IP-Restricted Bucket Policy for the IAM User
A bucket policy will need to be added for the Zscaler IAM user to be able to write to the bucket. The access to the bucket for this user will also be restricted to the hub IPs used for your ZIA deployment.
To retrieve the list of hub IPs for your Zscaler deployment, see: https://config.zscaler.com/zscaler.net/hubs
Choose your ZIA cloud at the top and then use the IPs from the recommended column to modify the example policy below with the IP ranges your wish to restrict access to.
Copy the below example policy and modify the following:
<your-account-id> - replace with your AWS account ID
s3-zscaler - replace with your IAM user created for Zscaler
vectraziabuket - replace with your bucket identifier
aws:SourceIp - replace with the hub IP ranges recommended for your ZIA cloud from the URL above
After completing the modifications, navigate to S3 > vectraziabucket > Permissions > Bucket Policy and "Edit" the policy, adding your modified policy. When done, click "Save" to save your policy.
6. Reserve SASE IP Range(s)
Please Expand/Collapse for Details
ZIA users are often remote in their location and not on the corporate/campus network. They can have any IP address that might belong to a home network, coffee shop, library, airport lounge, etc. Vectra requires that the IP ranges used in the system do not overlap. This means that IP ranges used on the corporate/campus/data center networks must be unique. When ZIA users traffic is stored in a PCAP and then ingested into Vectra, the real IPs used by the hosts using ZIA need to be remapped into IP ranges that won't overlap with the rest of the IP space used for your deployment. Vectra does this automatically based on IP ranges that you reserve in the Vectra system for this purpose.
Please see the following facts and requirements about this functionality:
IP Address Classification
Your system classifies IP address ranges based on settings in the "IP Address Classification" area.
This is located in your Vectra UI at Configuration > Data Sources > Network > Brain Setup > IP Address Classification.
QUX deployments still have it at Data Sources > Network > Brain Setup > IP Address Classification until they receive updated configuration navigation (scheduled for v9.8).
Please see the Vectra Respond UX Deployment Guide or the Vectra Quadrant UX Deployment Guide for more details on IP Address Classification.
These IP Address Classification settings are important when considering the IP address pool that is reserved for remapping SASE client IP addresses.
Hosts associated with reserved SASE IP ranges MUST be considered as "Internal" in the Vectra system.
By default, Vectra considers RFC-1918 space as "Internal".
Occasionally, customers may want to treat internal space as external.
For example, lab IP space used to simulate attacker infrastructure should be considered as "External" for detection models to function properly in a test of C2 running from an internal host to what would otherwise be internal lab IP space.
"Excluded Subnet of Internal IP Addresses (CIDR)" would normally be configured for this use case in IP Address Classification settings.
SASE integration only processes traffic directed to the internet, not directed to internal network space, therefore such exclusions in IP Address Classification settings cannot be applied to reserved subnets used for SASE IP address remapping .
If your deployment uses non RFC-1918 space for remapping of SASE IPs, it MUST always be considered as "Internal" in your IP Address Classification settings.
Vectra recommends that you use RFC-1918 space that is otherwise unused in your network for SASE IP remapping.
Host association to reserved SASE IP ranges is dynamic and will change over time.
This means that as host sessions expire, any IP address assigned to a ZIA device may change the next time the same device connects.
Tracking of hosts for detections and metadata should use the host named by ZIA-ZIADeviceID instead of the IP whenever possible.
The method of assignment is proprietary and not controllable by the customer.
The range(s) used can be chosen by the customer but not the assignments themselves.
PLEASE NOTE:
Care MUST be taken by administrators to ensure that any IP range used for SASE IP ranges in Vectra does not overlap with IP ranges used by the customer in their environment.
Additionally, there should be NO overlap with any Exclude, Drop, Internal VPN, or Static address ranges configured in the IP Address Classification Settings in your Vectra deployment.
If other Vectra Sensors capture traffic that overlaps with ranges reserved for SASE IP address remapping, the non-SASE metadata would be dropped by the Vectra Brain and not analyzed.
At this point in time, there is no automated check done when the SASE IP ranges are configured to see if they overlap with ranges configured in the IP Address Classification settings.
The default ranges used for Internal IP space in IP Address Classification include RFC-1918 space. It is not necessary to break these larger ranges into smaller ones that carve out the SASE IP range(s) you have chosen. It is ok to leave these as large blocks.
What matters is that the IP address range(s) you use for SASE IP address remapping, do NOT overlap with IP ranges that you are actually using in your environment and are monitored by other Vectra network sensors.
To configure SASE IP remapping ranges:
Navigate in your Vectra UI to Configuration > Data Sources > Network > Remote Users.
QUX deployments still have it at Data Sources > Network > Remote Users until they receive updated configuration navigation (scheduled for v9.8).
Click the "Edit" link or pencil icon to edit the setting.
Enter any ranges you wish to use in standard CIDR format as in this example below and then click the "Save" button.
After saving, this area will track the usage of the subnet pool.
Warning and critical badges will show in this area when ranges are running out of space:
Additionally, a system alert will fire that will cause an email notification to be sent that will contain data such as the below when the IP address pool is 70% utilized:
So please ensure you have reserved enough subnets to cover the expected number of ZIA devices that will be observed through PCAP ingestion, that those subnet ranges will not overlap with traffic seen by other Sensors, and that the ranges don't overlap with any non internal IP ranges in the IP Address Classification settings.
Once you have completed the configuration of these ranges, you can move on to the next step.
The subnets you configure should contain at least 1024 IP addresses in total.
7. Configure Zscaler SASE Integration in the Vectra UI
Please Expand/Collapse for Details
Adding the details to configure what we've created so far into the Vectra UI is easy.
Navigate in your Vectra UI to Configuration > Data Sources > Network > Remote Users.
QUX deployments still have it at Data Sources > Network > Remote Users until they receive updated configuration navigation (scheduled for v9.8).
Click "+ Add SASE Coverage" to add your ZIA PCAP ingestion configuration details.
Choose the AWS Bucket Region you used for AWS vSensor deployment and where you ran the CFN template earlier to create the S3 bucket and associated resources.
Choose the AWS vSensor that you dedicated for this integration.
Input the Bucket Identifier String for the bucket that was created earlier.
The name will be the ResourcePrefix you entered during CFN template deployment followed by "bucket".
This was on the "Resources" tab of stack output after running the CFN template.
Input the SQS Queue URL for the SQS Queue that was created earlier.
The name contain the ResourcePrefix followed by "queue".
This was on the "Resources" tab of the stack output after running the CFN template.
Click "Save Configuration".
When completed, your should see the completed configuration and can move on to the next step.
8. Configure Zscaler Traffic Capture in your Zscaler console
Please Expand/Collapse for Details
At this point in the overall deployment process, your Vectra configuration is done. Now the Zscaler side of the configuration must be completed to begin PCAP generation and storage in the S3 bucket. When the vSensor retrieves a SQS message saying there is new PCAP data to ingest, it will download the PCAP and ingest it.
Zscaler configuration is accomplished in the following two places in your Zscaler console:
Administration > Resources > Traffic Capture Settings
This where the configuration details are input including the authentication details and S3 bucket folder URL you retrieved earlier.
Policy > Web > Capture Control > Traffic Capture
This is where you configure packet capture rules to filter out traffic that is not required for analysis by Vectra and to forward all other traffic to Vectra.
If these options are not available in your Zscaler console, please contact your Zscaler account team.
1. Configure the Traffic Capture Settings:
Navigate in your Zscaler console to Administration > Resources > Traffic Capture Settings.
Enable Traffic Capture
This toggle can be used to turn the overall feature on or off.
AWS S3 Settings
Input the Access Key ID and Secret Key you retrieved in Step 5 earlier.
Input the S3 folder URL from Step 3 earlier.
HTTP Headers
The vast majority of customers will not need this. It is used to further authenticate data being pushed into S3 by custom headers that pass secrets to AWS.
If this type of setup is required, please work with your Zscaler account team for details and guidance.
Per Occurrence Limits
This does not apply to the Full PCAP feature from Zscaler.
This applies only to Event Based capture from Zscaler.
Event Based Capture is a different offering from Zscaler and is not in scope for this article. Reach out to your Zscaler team for details on using Event Based Capture.
Obfuscate User Names or Devices
Some customers may be under requirements to not use personally identifiable details in their integration. If this is a requirement, the Vectra integration will still work, but detections will be logged to a ZIA-uuid that cannot be mapped to a ZIA device/user.
For details on how the UUID mapping would work, contact your Zscaler account team. For example, at this time, Vectra does not know if the UUID would be consistently mapped for each device or user so that detections would represent a unique ZIA device/user and be tracked consistently over time, or if the obfuscation would map the same device/user to different UUIDs over time.
User Names
Vectra plans to work on linking ZIA usernames to device IDs in the future to make analyst investigation easier.
For example, LSS logs are already used by Vectra's ZPA integration to automatically name hosts by ZPA username.
Devices
The current Vectra integration names hosts by ZIA device ID. It is strongly recommended to NOT obfuscate this unless it is a strict privacy requirement. Analysts will have a much harder time tracking down users and devices when hosts are prioritized by Vectra if the Device is obfuscated in the PCAPs created by Zscaler.
Once you have completed configuration in this page and saved it, you can move on to configuring the filtering policies desired.
Please note that you must use the "Test Connection" button to test the connection to the S3 bucket before the "Save" button will be enabled.
2. Configure Traffic Capture Filtering Policies
Navigate in your Zscaler console to Policy > Web > Capture Control > Traffic Capture.
Traffic Capture rules are evaluated in the order specified.
When editing rules, you can change the rule order number to reorder rules.
Rule evaluation stops at the first match.
Vectra recommends that you configure your first rule to have an "Action" of Skip to filter out traffic that isn't necessary to analyze from a security perspective so that it will not be included in PCAPs and the vSensor dedicated to the PCAP ingestion will have more headroom available for security pertinent traffic.
For details on which traffic types that can be filtered, please see Vectra Platform Network Traffic Recommendations or the Vectra NDR (Detect) and Network Identity Architecture Overview.
In general, it is normally safe to filter out the following:
Video Streaming or Multicast
Multiprotocol Label Switching (MPLS)
Core routing protocols
Session Initiation Protocol (SIP)
High-performance computing (HPC) workloads high in bandwidth
HPC workloads that are well isolated
Storage array network file systems (SMB OK)
High-bandwidth backup data
Traffic can be filtered by Network Service/Groups, Network Applications/Groups, source/destination IPs/groups and countries.
Vectra recommends filtering the following:
High bandwidth, low security risk, sanctioned applications such as:
Teams
Zoom
Webex
Google Meeting
Multimedia streaming sites with low security risk
Youtube
Netflix
Pandora
Spotify
There should be a balance though because Vectra does NOT want to recommend filtering out BOX, OneDrive, or other services that might be use by an attacker.
Care should be taken to avoid blind spots while still being mindful of scalability for PCAP ingestion.
Use as many filter rules as necessary to filter out (Skip) what you don't need to analyze and then create one rule to capture all other traffic.
Adding a traffic capture rule:
The above is the capture rule configured in Vectra's test Zscaler tenant.
In the Capture Policy area, you can change the rule order, name, enablement status, and label.
The various criteria in the middle control what is captured.
The "Capture" checkbox in the "Action" area should be as shown above when you want to capture what matches the criteria in the middle section.
When you are configuring a filter rule to "Skip" capture it will be Red:
SPECIAL NOTE FOR SAMPLING AND CAPTURE LIMIT:
These will default to a Sampling rate of 5% and a Capture Limit of 64MB when creating a new rule.
Sampling - This controls the percentage of sessions that are captured and PCAPs are created for.
This should always be set to 100% for your main capture rule because you want Vectra to analyze all the network traffic possible after filtering out unnecessary traffic.
If you want to reduce the amount of traffic processed by PCAP ingestion, you can filter hosts, protocols, applications, etc by following the advice above.
Capture Limit - Zscaler provides several default options here from 32KB to 64MB.
This is the limit at which Zscaler will stop producing a PCAP for a individual connection session and truncate the PCAP.
"Unlimited" will not show as an option unless Zscaler specifically turns on this option for your account.
To request this, reach out to Zscaler and create a support ticket requesting the unlimited setting be made available for your account.
Approval is not a given, and is based on several factors that Zscaler can analyze.
It is recommended by Vectra to set this to unlimited for production use because the efficacy of detection models will be impacted when the entirety of a session is not captured and subsequently analyzed by Vectra.
Some models will still function, but exfil models, for example, will have incomplete data and will definitely be impacted.
Once you have saved your policies, you have completed the setup and can move on.
Post Deployment
This section provides guidance for:
Finding the username (Device Owner) from the ZIA-device_id in your Zscaler console
How to see traffic statistics once the integration is configured and working
Details for system alerts that may be sent.
Please Expand/Collapse for Details
Finding ZIA Username in Zscaler Console
When looking at a host in your Vectra UI such as in the screenshot below:
ZIA hosts are named by Zscaler Device ID in this format: ZIA-device_id
You can copy the device ID portion of the username or copy the Device ID artifact in the details pane for your host.
Navigate in your Zscaler console to Administration > Resources > Access Control > Device Management as seen in the screenshot below:
On the "Device Management" screen, you can use the search box to find the matching device.
The "Device Owner" column will show the ZIA user. Names have been blurred in the screenshot example below:
Traffic Statistics
After you have completed deployment, your vSensor dedicate for PCAP ingestion will now have a "sase0" interface that will show in your UI and CLI.
Once PCAPs begin to be ingested, it can take a few min for traffic graphs in your UI to begin to populate. In this test environment, there was no traffic at the time of the screenshot.
Look under Network Stats > Ingested Traffic > Your vSensor.
The "eth0" will likely be removed in a future update because it on longer functions when the vSensor is in SASE mode.
"show traffic stats" can be used at the CLI of your vSensor to see current stats on packets being observed by the sase0 interface
Alerts
The following system alerts will be created relating to SASE integration, please contact Vectra support for assistance if required:
sase_ingestor_health_check - Various conditions. Text of system email alert below:
sase_address_space_exhaustion - Sent above 70% pool exhaustion. Text of system email alert below:
sase_files_not_flowing_check - Indicates either files not being put into S3 bucket by Zscaler, or Vectra is unable to pull the files down. Text of email system alert below:
sase_ingestor_auth_check - Typically indicates error in AWS side configuration. Maybe the IAM role was not attached to the vSensor or the settings in the UI don't match what was created in AWS. Text of email system alert below:
CLI Configuration Option for Step 7
The configuration of the SASE integration in the Vectra UI can also be done via CLI commands if desired.
Please Expand/Collapse for Details
To configure the integration using the CLI of your Vectra Brain, first login as the "vectra" user to your Brain CLI. If you are unfamiliar with how to do this, please see Console access on Vectra appliances.
The first step in CLI configuration is to add one or more subnets that will be reserved for IP address remapping of ZIA devices. The details are the same as in Step 7 above and should be read there before continuing with CLI configuration. Once in the CLI, run the following command:
The command supports providing a comma-separated list of IP ranges such as:
If there is a need to remove ranges at any time, or view ranges that currently are configured, two other commands are available:
After the IP ranges have been configured, use the "configure" command to point the Vectra vSensor at the AWS resources deployed by the CFN template in Step 2.
After configuring, it's time to enable. Simply use the following command:
Note the presence of the "is_enabled" field in the return. There are some other commands available for convenience. If there is a need to disable or view the current configuration, that available via CLI comand as well. If the configuration needs to be changed after a sensor has already been enabled, the "configure" command above can be used with no further modification. The syntax for the other commands is as follows:
Details for On-Prem Capture
Expand/Collapse for Details
Overview
Vectra natively supports customers who utilize Zscaler Internet Access (ZIA). Vectra is proxy aware and treats all traffic to ZIA as in to out.
Vectra detection algorithms are aware of network traffic direction and because of this, it is important that proxy IPs associated with ZIA are recognized as proxies in Vectra. If the IPs that you use as proxies in ZIA are not designated as "internal" in your Vectra configuration this can cause spurious detections or cause some algorithms to not fire detections when this would have been desired. The reason for this is that while Vectra is very reliable at determining when it is deployed south of a proxy, at this time the proxy IPs must be "internal" within your Vectra configuration to be eligible for automated recognition.
Setting Zscaler ZIA Proxy IPs to "Internal"
To prevent these issues, the set of public IP addresses that Zscaler uses for their proxies should be added to the list of public IP addresses listed as internal to the customer's network in the Vectra UI. The addresses for all the proxies can be found at https://ips.zscaler.net/cenr. Additional information on Zscaler cloud architecture can be found at https://help.zscaler.com/zia/about-zscaler-cloud-architecture. You only need to add the IPs or ranges that you are using for your ZIA implementation, not all ZIA IPs. Please consult with your Zscaler support team if you are unsure of which IPs or ranges to mark as internal.
To set ZIA IPs or ranges as internal:
Navigate in your Vectra UI to Configuration > Data Sources > Network > Brain Setup > IP Address Classification.
Click the "Edit" button or pencil icon.
Add your ZIA proxy IP addresses or ranges to the top box.
Save your setting change at the bottom of the dialog.
Spurious Detections
Customers using Zscaler cloud enforcement may experience spurious detections associated with the Zscaler cloud proxies when the ZIA proxies are not recognized as such in your Vectra deployment. The options for deploying Zscaler are described at https://support.zscaler.com/hc/en-us/articles/205118615-Choosing-Traffic-Forwarding-Methods. If Zscaler is deployed in a mode where traffic is forwarded from the customer's network to Zscaler via a GRE or VPN tunnel from a DMZ firewall, no spurious detections will occur as Zscaler is effectively a transparent proxy.
If Zscaler is used as a proxy by loading PAC files into individual hosts, the spurious detections can appear. In this configuration, Vectra detects the Zscaler proxies as public (external) IP addresses and treats the traffic as external traffic headed to the proxy rather than as external traffic which will be forwarded by the proxy to its ultimate destination. This misunderstanding of the final destination of the traffic causes several algorithms to trigger spurious detections, including External Remote Access, Pulling Instructions, and Data Smuggler.
Please contact Vectra Support if you have a high volume of spurious detections and would like help identifying and triaging them to remove them before they naturally become inactive and eventually age out of the system entirely.
Algorithms Not Firing As Desired
A misunderstanding of the final destination of the traffic as described in the Spurious Detections section above can also cause some some detection algorithms to not fire detections when that is the desired behavior in your environment. As an example, detection of tunnels used for command and control could be impacted.
Attachments
Last updated
Was this helpful?