Cloud Exchange FAQs

Q: What is Netskope Cloud Exchange?

A: Netskope Cloud Exchange is a powerful platform service that enhances your security posture by enabling automated data exchange between your Netskope Security Cloud platform and your broader security and IT ecosystem. It allows you to share threat intelligence, risk scores, logs, and automate security workflows with third-party SIEMs, SOAR platforms, EDR solutions, ITSM tools, and more.

Q: What are the main modules within Cloud Exchange and what data do they handle?

A: Cloud Exchange includes several modules, each designed for specific data exchange functions:

• Log Shipper (CLS): Pulls logs (alerts, events, NSL) from your Netskope tenant, transforms them, and shares them with your SIEM or log management platforms. It stores data temporarily on the CE machine’s disk only during the pulling and sharing process and does not store any data permanently.
• Threat Exchange (CTE): Facilitates bidirectional sharing of threat intelligence (like file hashes, malicious URLs/domains, IPs) between Netskope and other security tools (like threat intelligence platforms, EDRs). It stores indicators in its database.
• Ticket Orchestrator (CTO): Automates the creation and updating of tickets in ITSM or case management systems (e.g., ServiceNow, Jira) based on Netskope alerts. It stores alerts in its database.
• Risk Exchange (CREv2): Combines the capabilities of the original User Risk Exchange and Application Risk Exchange modules described below.
• User Risk Exchange (CRE for Users): Shares user and host risk scores (derived from Netskope User and Entity Behavior Analytics – UEBA) with other systems to enable risk-based access control and adaptive security policies. It stores these scores.
• Application Risk Exchange (CRE for Applications): Shares application risk scores (based on Netskope Cloud Confidence Index – CCI) with other platforms. It stores these application risk scores.

Q: Can I revert Cloud Exchange or its plugins to a previous version?

A: No, Cloud Exchange does not natively support downgrading or reverting the core Cloud Exchange platform or individual plugins to a previous version. Netskope highly recommends that you back up your Cloud Exchange configuration before performing any upgrades. If you need to run an older specific version, a fresh deployment of that version would typically be required, followed by a configuration restore if available and compatible.

Q: How are Operating System (OS) updates managed for Cloud Exchange?

A: Starting from Cloud Exchange v5.0.1, the platform is built on a Netskope PSIRT-hardened and reviewed Ubuntu OS. Because of this hardening, Cloud Exchange itself does not receive or prompt for general OS update notifications from the underlying OS repositories. For Cloud Exchange deployed as a Virtual Machine (VM/OVA), the underlying OS is updated to the latest hardened and reviewed version with each new official Cloud Exchange release. For containerized deployments on your own host, you are responsible for maintaining and securing the host OS, while Netskope maintains the OS within the Cloud Exchange containers.

Q: Why does Cloud Exchange use user ID 1001 for its processes?

A: Cloud Exchange uses a non-root user ID (such as 1001) for its internal worker processes primarily as a security best practice. This ensures the principle of least privilege, meaning processes run with only the permissions they absolutely need. This approach improves resource management within the containerized environment and contributes to a more secure overall deployment. This is an automatic internal process and does not require manual intervention.

Q: Are there any rate limits for log pulling or export from Netskope via Cloud Exchange?

A: Log ingestion from the Netskope tenant is subject to API rate limits (4 calls per second per endpoint via API V2). 

For log export, Cloud Exchange does not impose any rate limits. It can forward up to 10,000 alerts, 10,000 events and 5MB of web transaction logs per batch, with delivery times usually under 10 seconds. This ensures efficient, near real-time log delivery while staying within Netskope’s API limits.

Q: What steps should be followed to perform server-level changes on the Cloud Exchange server while ensuring data integrity is maintained?

A: To perform server-level changes on the Cloud Exchange server without losing data:

1. Save the environment config (cat .env).
2. Stop Cloud Exchange containers (sudo ./stop).
3. Apply server/system changes (e.g., disk, memory, OS).
4. Re-run setup (sudo ./setup) to apply changes.
5. Restart services (sudo ./start).

This process ensures the environment is preserved and data integrity is maintained.

Q: Do we need to purchase an additional license to use Cloud Exchange features?

A: No separate license is required

Q: Why does the CE web URL display a “Not Secure” warning? Is this related to Cloud Exchange itself?

A: No, this warning is not caused by the Cloud Exchange (CE) application itself. The “Not Secure” message appears in your browser because the SSL/TLS certificate for the CE URL is either self-signed or not trusted by the browser.
This is typically due to how the certificate was generated, installed or distributed and is not managed directly by CE.

To install a valid and trusted SSL/TLS certificate on the server hosting CE. Once configured correctly, the warning will disappear.
We recommend consulting with your internal IT/security team to validate and fix the certificate setup

Q: Does Cloud Exchange support Ubuntu with FIPS?

A: No, Currently Cloud Exchange is not tried and tested for Ubuntu Pro 22.04 with FIPS. So we suggest you disable FIPS before deploying Cloud Exchange

Q: How to enable debug-level logs in Cloud Exchange?

A: To enable debug-level logging in Cloud Exchange, follow these steps:

1. Go to Cloud Exchange > Settings > General > Logs
2. By default, the Log Level is set to Info
3. From the dropdown, select Debug
4. Click Save at the bottom of the page to apply the changes.

Q: We receive this error during a setup script or start script “-bash: ./start: /bin/sh^M: bad interpreter”?

A: This error occurs because of the format of the file. So you have this command to change the file format.
do2unix setup
do2unix start

Q: Why does Cloud Exchange (CE) UI hang or become unresponsive when Microsoft Defender ATP or CrowdStrike agents are installed on RHEL/Ubuntu VMs?

A: When Microsoft Defender ATP and CrowdStrike agents are installed on the same RHEL/Ubuntu virtual machine where Cloud Exchange is deployed, they may consume significant system memory due to continuous scanning and monitoring activities. This can lead to Out Of Memory (OOM) conditions, causing the Cloud Exchange UI to hang and, in some cases, require a system reboot to recover.

To mitigate this issue, it is recommended to whitelist the directories used by Docker (typically /var) and the Cloud Exchange installation path on the VM. This helps reduce unnecessary scanning and prevents excessive memory consumption.

Q: Cloud Exchange Unable to Communicate with Netskope Tenant Due to Public IP Restriction

A: To resolve this issue, ensure that the public IP address of the Cloud Exchange server is added to the Netskope tenant allowlist.

Steps:

1. Identify the public IP address of the Cloud Exchange server. If unknown, you can run the following command via SSH:

   curl -s https://checkip.amazonaws.com

2. Log in to the Netskope tenant.
3. Go to: Settings > Administration > IP Allowlist.
4. Add the identified public IP address under Netskope IP Addresses.
5. Save the configuration changes.
6. Return to Cloud Exchange and retry the API token configuration.

After the public IP is allowlisted, communication between Cloud Exchange and the Netskope tenant should be restored, and the API token should be saved successfully without errors.

Q: Can the On-Premises Streaming Client replace Cloud Exchange, and can it be deployed on the same VM as Cloud Exchange?

A: The On-Premises Streaming Client and Cloud Exchange (CE) serve different purposes and are not interchangeable.

The On-Premises Streaming Client is designed specifically for log forwarding from Netskope to external systems such as a SIEM. It can function as a standalone solution for log ingestion and forwarding, meaning Cloud Exchange is not required if your only use case is log streaming.

However, Cloud Exchange (CE) provides additional capabilities, such as data enrichment, API-based integrations, and advanced workflows, which are not handled by the Streaming Client.

Regarding deployment:

• Co-location is supported. The On-Premises Streaming Client can not be installed on the same Virtual Machine as Cloud Exchange.
• There are inherent conflicts between the two components.

Q: Does the Cloud Exchange platform support multiple active instances of the same plugin type pointing to a single source?

A: Yes, multiple instances for the same plugin are supported in Cloud Exchange. Based on the API rate limiting on the source, you might hit the API limits earlier for multiple instances compared to a single instance.

Q: Can Cloud Exchange run with lower CPU and RAM than the documented system requirements if my current workload and resource utilization are low?

A: The published Cloud Exchange sizing guidelines represent the recommended and supported configuration to ensure stable operation during normal workloads, peak loads, upgrades, synchronization activities, and background processing tasks.

Although current CPU and memory utilization may appear low, Cloud Exchange has been tested and validated against the documented minimum system requirements. Running below the recommended specifications may lead to performance degradation or unexpected behavior, particularly during upgrades, synchronization operations, increased log volume, or other resource-intensive activities.

Cloud Exchange uses a worker-based processing architecture to handle data ingestion, synchronization, and sharing activities across various integrations and services. The configured worker processes determine how many tasks can be executed concurrently.

To ensure optimal performance and system stability, the recommended number of worker processes should be approximately 1.25 times the number of available CPU cores. This sizing helps Cloud Exchange efficiently process workloads, manage concurrent operations, and maintain consistent performance as data volume and integration activity increase.

For these reasons, Netskope recommends maintaining the documented system requirements even if current resource utilization appears low.

Q: How to find out the Cloud Exchange installation directory?

A: If you want to find out about your Cloud Exchange installation directory, use one of the following methods based on your deployment type:

i) For a Containerized Cloud Exchange deployment:

find / -name "ta_cloud_exchange" 2>/dev/null

ii) For a Cloud Exchange as VM deployment, the default installation directory is:

/opt/cloudexchange/cloudexchange

Q: Does Cloud Exchange (CE) v6.1.0 support RHEL 9.7?

A: Yes. The minimum Linux versions qualified for Cloud Exchange are documented in the Cloud Exchange System Requirements. For Cloud Exchange v6.1.0, RHEL 9.5 is the minimum qualified version. In general, newer minor releases above the minimum qualified version are expected to support Cloud Exchange deployments. Therefore, deploying Cloud Exchange v6.1.0 on RHEL 9.7 is supported.

Q: Does Cloud Exchange support multiple Netskope tenant configurations?

A: While Cloud Exchange technically allows for multiple Netskope tenant configurations, doing so is highly discouraged. Running multiple tenant configurations simultaneously can severely degrade Cloud Exchange’s performance and system stability. For optimal reliability, it is strongly recommended to maintain a single tenant configuration per deployment.

Q: Where should I open a support case for Cloud Exchange-related assistance?

Q: Is it possible to renew the Cloud Exchange SSL certificate directly from the Cloud Exchange UI?

A: Yes. The Cloud Exchange SSL certificate can be renewed directly from the UI without requiring CLI access.

Steps

1. Navigate to Settings → General.
2. Click Renew Certificate.
3. The SSL certificate will be renewed automatically.

Note: Cloud Exchange will display a warning notification 30 days before the SSL certificate expires, prompting you to renew the certificate. It is recommended to renew the certificate during this period to avoid any service interruption.

After clicking Renew Certificate, allow 5–7 minutes for the backend process to complete. Once finished, open the Cloud Exchange UI in a private/incognito browser window to validate that the renewed SSL certificate has been applied successfully.

Q: What are the key processor architecture and feature requirements for installing Cloud Exchange?

A: Cloud Exchange is designed and tested exclusively for the x86_64 architecture. A critical processor feature required is Advanced Vector Extensions (AVX) support. Machines must have both x86_64 architecture and AVX support for reliable operation.

ARM64 Processors are Not Supported: Cloud Exchange does NOT support ARM64-based processors. This is because ARM64 processors do not typically support AVX, which is a fundamental requirement for Cloud Exchange. Running Cloud Exchange on ARM64 systems can lead to critical component failures or unreliable performance.

For detailed system requirements (CPU cores, RAM, Disk space based on profiles like Small, Medium, Large), refer to Cloud Exchange System Requirements.

Q: How do I configure or update proxy settings for Cloud Exchange after initial setup?

A: For containerized deployments, you can configure or update proxy settings by re-running the setup script:

1. Stop the running Cloud Exchange containers: sudo ./stop
2. Go to your Cloud Exchange installation directory (e.g., cd /opt/cloudexchange/cloudexchange or cd ta_cloud_exchange).
3. Execute the setup script:sudo python3 ./setup
4. When prompted during the script execution, enter your proxy details (like http://proxyserver.example.com:port).
5. Complete the rest of the setup questions.
6. After the script completes, you can validate the proxy settings in the .env file within your installation directory:cat .env. Look for the CORE_HTTP_PROXY and CORE_HTTPS_PROXY variables.
7. Start the Cloud Exchange containers: sudo ./start

Cloud Exchange UI Option: You can also add/edit proxy details directly from the Cloud Exchange UI by going to Settings > General > Proxy. However, for these settings to be fully applied at the system level for all container communications, especially if Cloud Exchange itself needs to use the proxy for outbound connections from the host, re-running the ./setup script is often necessary to ensure the environment variables are correctly populated in the .env file used by the container runtime.

Q: How can I deploy a specific previous (n-1) containerized version of Cloud Exchange using Git?

A: To deploy a version prior to the latest (n-1 version), if you are managing your Cloud Exchange deployment via a Git repository:

1. Go to your Cloud Exchange Git directory (e.g., ta_cloud_exchange):cd <your_ce_directory>.
2. Ensure your local repository is up-to-date with remote tags/branches: sudo git fetch --all --tags
3. Check out the specific version tag you want to deploy. Version tags are typically in the format vX.Y.Z: sudo git checkout tags/<version-number>. (Example: sudo git checkout tags/v5.1.0)
4. Run the setup script to configure this version: sudo ./setup
5. Start Cloud Exchange: sudo ./start

Q: How do I upgrade my containerized Cloud Exchange from an older version to the latest using Git?

A: To upgrade to the latest containerized version from an older one, if managing Cloud Exchange via Git:

1. Go to your Cloud Exchange Git directory: cd <your_ce_directory>.
2. Switch to the main branch (or the branch designated for latest stable releases, often ‘main’ or ‘master’): sudo git switch main
3. Pull the latest updates from the repository: sudo git pull
4. Run the setup script to apply any configuration changes for the new version: sudo ./setup
5. Start Cloud Exchange: sudo ./start

Always review the latest release notes for the new version for any specific upgrade instructions or important considerations before upgrading.

Q: How do I regenerate self-signed SSL certificates for the Cloud Exchange web interface?

A: If you need to regenerate the self-signed SSL certificates used by the Cloud Exchange web server (like if they expire, you want to change common name details, or for security reasons), follow these steps for a typical containerized deployment:

1. Go to your main Cloud Exchange installation directory: (like /opt/cloudexchange/cloudexchange or ta_cloud_exchange).
2. Stop the Cloud Exchange services: sudo ./stop
3. Go to the directory where SSL certificates are stored, usually: cd data/ssl_certs
4. Remove or backup the old certificate and key files (like cte_cert.crt, cte_cert_key.key):
   sudo rm -f cte_cert.crt cte_cert_key.key
5. Return to the main Cloud Exchange installation directory: cd ../.. (if you were in data/ssl_certs)
6. Run the setup script. The script should detect the missing certificates and guide you through generating new ones or generate them automatically: sudo python3 ./setup
7. Start Cloud Exchange services: sudo ./start

After regeneration, your browser will show a warning for the new self-signed certificate, which you’ll need to accept to access the UI.

Q: What should I do if the Netskope REST API v2 token used by Cloud Exchange expires?

A: If the API token expires, Cloud Exchange will lose its ability to communicate with your Netskope tenant for pulling data or sharing intelligence. You will typically see a warning banner in the Cloud Exchange UI stating something like: “The Netskope tenant API token has expired for [Tenant Name]. Generate the new token or re-issue the token and update the tenant configuration to resume communication between Netskope Tenant and Cloud Exchange.” 

To resolve this:

1. In to your Netskope Tenant, go to Settings > Tools > REST API v2.
2. Locate the specific API v2 token that your Cloud Exchange instance is configured to use.
3. Click the three dots (ellipsis icon) next to the token and select **Change Expiration**. Set a new, appropriate future expiration date.
4. It’s also a good practice to reissue the token from the same menu. This generates a new token value. Copy this new token value.
5. In Cloud Exchange UI, go to Settings > Netskope Tenants.
6. Edit the configuration for your tenant and paste the newly reissued token value into the API Token field.
7. Save the updated tenant configuration in Cloud Exchange.

Q: Which virtualization platforms are supported for a Cloud Exchange VM deployment?

A: Netskope provides Cloud Exchange VM images for several widely used virtualization platforms. Common supported formats and platforms include:

• VMware vSphere: using OVA or Hyper-V – Open Virtualization Appliance format. Following is the Installation Guide for this method.
• Google Cloud Platform (GCP): often deployable using an OVA. Following is the Installation Guide for this method.
• Amazon Web Services (AWS): using AMI – Amazon Machine Image format. Following is the Installation Guide for this method.
• Microsoft Azure: using VHDX – Virtual Hard Disk format. Following is the Installation Guide for this method.

Always consult the latest Netskope Cloud Exchange documentation for the specific supported platform versions and image formats for the Cloud Exchange version you intend to deploy.

Q: While installing Cloud Exchange as VM using the OVA File and saw a bunch of warnings stating “Your kernel does not support swap limit capabilities or the cgroup is not mounted”. It seemed to install properly but wanted to know if this is something to be concerned about?

A: No, this should not be something to be concerned about. In order to set maximum limits on memory, one needs to enable swap or cgroup limit capabilities in the kernel. Hence, the docker checks for this in the machine and in the Ubuntu machine, this is not enabled, by default. Therefore, docker shows it as a warning. However, it should not ideally affect the Cloud Exchange deployment or workflow

Q: What to do When a Plugin Is Not Found

A: The plugin repository may be outdated, which can prevent the latest plugins from appearing..
Solution:

1. Go to Cloud Exchange > Settings > Plugin Repository.
2. Click Check for Updates (first option).
3. Click Update Plugin (third option).
4. The newly added or updated plugins will now be visible. Select the required plugin and click Save.

For more detailed information, please refer to the documentation: Plugin Repository

Q: How to check the health status of Cloud Exchange?

A: You can check the health status in the following ways:

• From Login Page of Cloud Exchange UI: You can check the info tooltip at the right-side corner and confirm the current status of Cloud Exchange’s components (Core, UI, MongoDB, RabbitMQ).
• From Cloud Exchange CLI in the machine: You need to go to the path wherein you have installed Cloud Exchange and you can execute the following command to status of containers associated with each Cloud Exchange’s components (Core, UI, MongoDB, RabbitMQ):

• sudo docker ps (for Ubuntu machine)
• sudo podman ps (for RHEL machine)

Q: How to create V2 token for Cloud Exchange with RBAC V3 enabled in the Netskope Tenant?

A: The workflow for Rest API V2 token provisioning is being deprecated. Future token provisioning must be performed using the new service account creation and management process, which is integrated with RBAC V3.

Hence, kindly review the following documentation guide, along with their sub-section articles which highlights the steps for you to create v2 token using RBAC V3: /en/managing-administrators-for-rbac-v3

Q: Can the Cloud Exchange Log Shipper pull logs from the Netskope Cloud Proxy through our on-premises proxy?

A: Yes. When proxy settings are properly configured in Cloud Exchange, all connections from the Log Shipper to the Netskope tenant are routed through the on-premises proxy, allowing logs to be pulled successfully.

Q: Why am I being prompted for Git credentials during git pull or git clone operations?

If Git prompts for credentials during a git pull or git clone operation, it may be using cached or outdated authentication information stored by the Git credential manager.

To clear the cached credentials, run the following command:

git credential reject

After removing the cached credentials, retry the Git operation. Git will prompt for authentication again and allow you to enter the correct credentials.

If the issue persists, verify that the repository URL, authentication method, and access permissions are configured correctly.

Q: Is Cloud Exchange High Availability (HA) supported for both VM and containerized deployments?

A: Yes, the High Availability feature in Cloud Exchange is designed to work with standalone (containerized) deployments on Linux machines (such as Ubuntu or RHEL), as well as with Cloud Exchange deployed as a Virtual Machine (VM/OVA).

Q: Can a Cloud Exchange HA cluster operate with nodes in different data centers (Multi-DC)?

A: Yes, Cloud Exchange HA supports configurations where its instances (nodes) are running across multiple physical data centers or availability zones.

Q: What is the recommended approach for deploying an HA cluster across multiple data centers (Multi-DC)?

A: For a robust Multi-DC HA setup, consider the following:

• Deploy Cloud Exchange nodes across the different data centers while ensuring stable, reliable, and low-latency network connectivity between all participating nodes.
• Cloud Exchange HA utilizes GlusterFS as the shared storage layer. The GlusterFS installation and configuration are managed through the Cloud Exchange and management server, providing both shared storage and high availability capabilities for the cluster.
• Ensure that all virtual machines participating in the HA cluster have connectivity to the required GlusterFS repositories during the HA configuration process.
• Verify that each Cloud Exchange node can communicate reliably with the other cluster nodes to support data synchronization, cluster health monitoring, and failover operations.
• Thoroughly validate network path redundancy, GlusterFS availability, and overall network performance, particularly latency and bandwidth, to ensure optimal HA cluster stability.

Q: What are the key network requirements for a Cloud Exchange node in a secondary site  participating in a Multi-DC HA deployment using GlusterFS?

A: The critical network requirements include:

• Reliability & Stability:The network connectivity between all Cloud Exchange HA nodes and the GlusterFS cluster must be stable and reliable. Network interruptions can impact data synchronization, cluster health, and HA operations.
• Low Latency: Network latency between Cloud Exchange nodes across data centers should be kept as low as possible. High latency may affect GlusterFS synchronization, shared storage access, application performance, and failover operations.
• Sufficient Bandwidth: Adequate network bandwidth must be available to support Cloud Exchange data synchronization, shared storage operations, log processing, and HA-related activities. Bandwidth requirements should be evaluated based on the expected workload and data volume.
• GlusterFS Connectivity: All Cloud Exchange HA nodes must maintain consistent connectivity to the GlusterFS cluster and the required GlusterFS communication ports. This ensures proper access to shared storage and successful synchronization across the HA environment.
• Inter-Site Connectivity Validation: Before deploying a Multi-DC HA configuration, validate network connectivity, latency, packet loss, routing stability, and GlusterFS accessibility between all Cloud Exchange nodes to ensure reliable HA functionality and failover readiness.

Q: Are performance issues expected if Cloud Exchange HA nodes are deployed in different data centers (Multi-DC)?

A: It’s possible. Compared to an HA setup where all nodes are within the same data center (and thus very low latency), a Multi-DC HA setup might experience slightly increased operational delays (like a few seconds for certain operations or failover, due to the inherent network latency between geographically separated data centers.

Performance can be affected by:

• Inter-data center network latency.
• Packet loss on the links between data centers.
• Bandwidth limitations between the sites.

Careful network design, capacity planning for inter-DC links, appropriate load balancing strategies in front of the Cloud Exchange cluster, and rigorous failover testing are crucial to identify and mitigate potential performance impacts in a Multi-DC HA deployment.

Q: How does failover and traffic handling typically work in a Multi-DC HA setup for Cloud Exchange?

A: Cloud Exchange HA is designed for automatic failover. If an active node in the cluster becomes unresponsive or fails, the HA mechanism detects the failure and coordinates the promotion of a healthy standby node (which may reside in another data center) to take over active operations. Traffic redirection to the new active node depends on your deployment architecture, such as an external load balancer, DNS updates, or client-side retry mechanisms used by the integrated applications.

Comprehensive testing for a Multi-DC HA deployment typically includes the following scenarios:

• Simulating node failures (for example, powering off a VM, stopping Cloud Exchange services, or restarting containers on one node).
• Validating data consistency and integrity across all nodes and the GlusterFS distributed storage after a failover.
• Testing read/write operations to the GlusterFS volume from all active and standby nodes.
• Verifying the health of the GlusterFS cluster, including volume status and replication/synchronization.
• Confirming the HA synchronization status and ensuring healthy communication between all cluster nodes.

Q: Which Cloud Exchange modules (CLS, CTE, CTO, CRE) are typically verified during Multi-DC HA testing?

A: Validation is generally performed to ensure uninterrupted or quickly restored workflow for all key Cloud Exchange modules during and after failover events in a Multi-DC HA setup. This includes:

• CLS (Cloud Log Shipper): Ensures continuous data ingestion from Netskope and forwarding to third-party SIEMs without significant data loss or excessive duplication.
• CTE (Cloud Threat Exchange): Verifying seamless sharing, synchronization, and application of threat intelligence across the cluster and with integrated security tools.
• CTO (Cloud Ticket Orchestrator): Testing that automated ticket creation, updates, and synchronization with ITSM systems continue to function correctly and without creating erroneous duplicates.
• CRE (Cloud Risk Exchange): Ensuring that user, host, and application risk scores continue to be assessed, shared, and available for consumption by integrated systems.

Q: What is the procedure of stopping and restarting Cloud Exchange Nodes in HA?

A: Follow the shutdown and startup sequence outlined below:

Stopping Cloud Exchange:

1. Stop each secondary node one by one.
2. Stop the primary node.

Starting Cloud Exchange:

1. Start the primary node first.
2. Start each secondary node one by one.

Q: Will an NFS server still be required for High Availability (HA) after upgrading to Cloud Exchange 6.x?

A: Starting with Cloud Exchange 6.x, the High Availability (HA) architecture no longer requires an NFS server. Customers who upgrade to Cloud Exchange 6.1.0 or later can remove the NFS server from their HA deployment, as shared storage is no longer a dependency for HA.

Q: How far back can Log Shipper retrieve historical alerts from the Netskope tenant?

A: The Netskope platform typically stores detailed alerts in its active database for a period of around three months. Log Shipper’s historical pulling feature can retrieve alerts from within this available retention window in the Netskope tenant.

Q: How can I perform a historical pull of older logs using the Log Shipper module?

A: Log Shipper includes a feature to pull historical alert and event data. To use this:

1. In the Cloud Exchange UI, go to the Log Shipper module from the main menu.
2. Within Log Shipper, go to the SIEM Mappings section (or a similarly named section responsible for configuring data destinations).
3. On the SIEM Mappings page, look for Pull Historical Data, where you can select a Date Range to pull historical data. Open the dialog by clicking the icon on the SIEM Mappings page (near the list of existing mappings or rules).
4. In the Pull Historical Data dialog, select the desired start and end date range for which you want to retrieve logs, and then initiate the pull process.

Important Considerations:

• Pulling a large volume of historical data can be time-consuming and may place a load on both the Netskope tenant and your Cloud Exchange instance. Plan accordingly.
• Depending on your SIEM’s ingestion settings and how it handles timestamps, pulling historical data might lead to log duplication if those logs were already partially ingested, or if the time ranges overlap with ongoing streaming.

Q: How can I stop an ongoing historical log pull in Log Shipper if needed?

A: Yes. If you need to stop an active historical pulling process in Log Shipper, the general method is to restart the Cloud Exchange services. This can be done via the Command Line Interface (CLI) on the Cloud Exchange host by going to the Cloud Exchange installation directory and running sudo ./stop followed by sudo ./start.

Q: What are the types of Alerts and Events that Log Shipper can typically fetch from the Netskope tenant?

A: Log Shipper is capable of fetching a comprehensive range of alerts and events generated by the Netskope Security Cloud Platform. Common examples include:

• Alerts: Compromised Credential alerts, Policy violation alerts (for various policies like web access, cloud app usage, etc.), Malsite access alerts, Malware detection alerts, Data Loss Prevention (DLP) incidents, Security Assessment findings (misconfigurations), Quarantine actions, Remediation events, User and Entity Behavior Analytics (UBA) anomalies and alerts, Watchlist alerts, CTEP , Device and content.
• Events: Detailed Page access events, Application usage events, Audit logs (tracking administrative actions within the Netskope platform), Infrastructure-related events, Network events (if applicable to your Netskope services), and overarching Security Incidents that group related alerts/events, Endpoint and Client Status Logs.

Q: What indicators in Cloud Exchange can help verify the timeliness of logs being pulled from Netskope and sent to external log servers?

A: You can verify whether the logs are current by reviewing the Cloud Exchange logging section.

• Logs labeled as historical indicate that older data is being ingested, typically during initial sync or relative delay or backlog processing.
• Logs labeled as real-time confirm that the system is processing and forwarding the most recent data to the destination log servers.

Q: What is the Streaming Client Docker? How does it differ from CLS?

A: The Streaming Client Docker is a lightweight, containerized solution designed to receive Web TX logs only, outputting them in SYSLOG format for integration with SYSLOG-compatible SIEMs.

Key differences:

Q: If we already have a SIEM capable of receiving TX logs, do we still need to purchase additional public cloud storage?

A: Yes, public cloud storage (e.g., S3, GCS, or Azure Blob) is still required to host the streamed Web TX logs, even if the logs are ingested directly by your SIEM.

Q: How does Cloud Exchange handle unsent logs if an outward CLS plugin (e.g., Syslog plugin) fails to forward logs due to a network issue (e.g., firewall restrictions, etc.)?

A: When Cloud Exchange encounters a network issue while forwarding logs, it will attempt to resend them up to 3 times. If delivery still fails, the logs are discarded.

However, you can enable the “Retry Till Successful Delivery” option to ensure logs are continuously retried until delivery is successful.

Additionally, historical events can be retrieved. If Cloud Exchange is unable to ingest logs during a specific time window due to an issue, you can still pull those logs later as long as they remain available in your Netskope tenant (since Cloud Exchange fetches logs directly from the tenant)

Q: Can BWAN logs be sent to Chronicle using the Cloud Exchange plugin?

A: No,The current CLS Chronicle v2.2.0 plugin mapping does not support ingestion of BWAN events. Chronicle relies on UDM mapping. As a workaround, you can use the Syslog plugin to forward BWAN logs to a Syslog server.

Q: What are the validations of log ingestion delay in Cloud Exchange?

A: Ideally, you should not be receiving delay logs at your SIEM using Cloud Exchange, however; if you are, then to validate the same from Cloud Exchange, confirm if the delay in log ingestion is due to pulling of logs from past time.

1. For instance, please see the below log messages referring to pulling of Malware alerts from Netskope tenant:

"message":"TENANT Netskope Tenant (Required) [Netskope Tenant Demo]: Pulled 0 Malware alert(s) for tenant Netskope Tenant Demo in JSON format using Netskope Tenant Demo_Malware index, pulled data till 2025-07-21 18:59:58.","type":"info","createdAt":{"$date":"2025-09-06T06:38:45.726Z"}

Here, you can see that the pulling of malware alerts is happening from the past time. This is the reason you received a log event of several days old recently. This kind of pulling could have been initiated manually through historical pulling, or keeping a large amount of time as the Initial Range in Netskope Log Shipper plugin. Alternatively, due to connectivity issue in pulling the logs from Netskope tenants, please confirm this from the Logging Section and check for any intermittent/recurring errors in pulling the logs.

2. Please confirm if the delay in log ingestion is due to the errors occurred while ingesting the logs at your SIEM:

For instance, please see the below log messages referring to ingestion of alerts/events to your preferred destination and it takes more than 10 seconds: 

• "message":"Ingested 10000 [events][network] log(s) into configuration <Your-Destination-Configuration> successfully. Time taken: 129 seconds.","type":"info","createdAt":{"$date":"2025-07-25T14:55:19.546Z"}
• "message":"Ingested 8248 [alerts][policy] log(s) into configuration <Your-Destination-Configuration> successfully. Time taken: 114 seconds.","type":"info","createdAt":{"$date":"2025-07-25T14:55:20.622Z"}

I would like to note that we have estimated ingestion time from CE to destinations such as Syslog, Qradar, and Azure for one batch of alerts, events, and web transaction logs should be less than 10 seconds. One batch is approximately 10,000 alerts, 10,000 events, or 5MB of Web transaction logs.

For your reference, we have highlighted the above information in the following documentation: /en/cloud-exchange-system-requirements

Hence, based on these observations, we sincerely request you to check regarding the delay issue in receiving logs from your SIEM’s end.

Q: Is there a workaround/alternative to assigning the AWS S3 Bucket permission to the IAM user for the Cloud Log Shipper AWS S3 Alerts Events plugin? 

A: No, the AWS S3 Alerts Events plugin does not support environments where S3 buckets are provisioned externally and managed separately from the plugin runtime.

Examples include:

• Terraform-managed infrastructure
• CloudFormation-managed infrastructure
• Kubernetes + IaC-based deployments
• Centralized platform engineering or shared infrastructure models

In such environments, buckets are typically pre-created by the infrastructure teams, and the runtime IAM role is intentionally restricted from performing account-level discovery or infrastructure creation operations.

This is why the existing plugin will be unable to locate the provided bucket in the current AWS account. The implementation relies on list_buckets(), which requires the s3:ListAllMyBuckets permission. Since this permission is not present in the configured IAM policy, the bucket lookup would either fail or will not return the required bucket.

As part of the original logic, when the bucket cannot be located, the plugin attempts to create the bucket automatically. However, if the runtime role also does not have the s3:CreateBucket permission, it will result in failure in the configuration of the plugin.

Q: Why am I seeing a “token expiration or Event Streaming is disabled” banner in the Cloud Exchange console GUI?

A: This error occurs if you are using the older WebTx plugin configured with Google Pub/Sub, which has reached End-of-Life (EOL). To resolve this, you need to migrate to the new Netskope Log Streaming plugin for your WebTx use case, which requires generating a new token.

A: As per official guidance from Google SecOps, the Service Account and corresponding credentials required for Chronicle (Ingestion API) integration should not be generated independently by the customer. Instead, these credentials are provided directly by the Google SecOps support team or representative.

Q: How should the Service Account Key be generated for the Google Chronicle Plugin integration in Netskope Cloud Exchange?

A: Customers are advised to contact their Google SecOps team to obtain the correct Service Account Key, as this ensures proper configuration and avoids authentication or ingestion errors. Netskope does not recommend generating or documenting custom steps for key creation, as the process may vary based on the customer’s Google environment and setup.

For more details, please refer to the official Google documentation.

Q: Can the Ticket Orchestrator module use Netskope Events (in addition to Alerts) to create tickets in an ITSM system?

A: No, the primary design of the Ticket Orchestrator module is to process Alerts generated by your Netskope tenant. Based on these alerts and the business rules you configure in Cloud Exchange, it then creates or updates corresponding tickets in your integrated ITSM system (like ServiceNow, Jira, etc.). It does not typically use raw Netskope Events (which are more granular activity logs) for direct ticket creation.

Q: How can I prevent Ticket Orchestrator from creating duplicate tickets for the same recurring Netskope alert?

A: Ticket Orchestrator includes mechanisms for alert deduplication to avoid creating multiple ITSM tickets for the same underlying security issue or alert. You can configure these deduplication settings within the Business Rules or global settings for the Ticket Orchestrator module. This involves defining criteria based on specific alert fields (like alert name, affected user/resource, and threat name) and a time window. If a new alert matches an existing one based on your criteria, Ticket Orchestrator can update an existing ticket instead of creating a new one.

Q: What is the default retention period for alerts stored locally by Cloud Exchange for the Ticket Orchestrator module, and can this be changed?

A: For the purpose of ticket tracking and deduplication, the Ticket Orchestrator module stores alert information locally within Cloud Exchange. The default retention period for these stored alerts is typically 7 days. And yes, this retention period can be modified in the Cloud Exchange UI by going to Settings > Ticket Orchestrator (or a similar path for module-specific settings) and adjusting the value for alert retention to suit your operational needs.

Q: Why is the Jira Status field not being updated according to the plugin field mappings?

A: This is a known limitation of Jira. The Status field is a system-managed field and cannot be directly modified through the standard Jira REST APIs. Status changes in Jira can only occur through defined workflow transitions rather than direct field updates.

As a result, any Status mappings configured in the plugin will not be applied when creating or updating Jira issues.

In addition to the Status field, certain other Jira system-managed fields may also be restricted from direct updates through the API, depending on the Jira deployment type and workflow configuration.

For fields that require workflow-based updates, Jira workflow transitions should be used instead of field mappings.

Q: Where in the Cloud Exchange UI can I view the threat indicators (IoCs) received by the Threat Exchange module?

A: You can view the threat indicators that Threat Exchange has processed and stored by going to Threat Exchange (in the left-side panel) and then selecting Threat IoCs. This page displays a sortable and filterable table listing the IoCs, including their value, type (like URL, MD5, SHA256, IP), Netskope Hits, and hits from other sources.

Q: How can I identify the original source of a specific Threat IoC listed in Cloud Exchange?

A: On the Threat Exchange > Threat IoCs page, the UI provides filtering capabilities. To find IoCs from a particular source (like a specific plugin, such as Proofpoint or CrowdStrike), you can use the filter builder. The underlying query language format might be something like [sources.source Like "plugin_identifier"] or similar, which you can often construct using the UI’s filter interface by selecting the source field and specifying the plugin name or identifier.

Q: How can I create and manage tags for IoCs within the Threat Exchange module?

A: Tags help categorize and manage IoCs. You can create and manage these tags by going to Threat Exchange (in the left-side panel) and then selecting Manage Tags. You can enter a tag name (like High_Confidence_Malware_URL) and add it. Existing tags are also listed on this page with options to edit or delete them.

Q: Which versions of Netskope API tokens are required for the Threat Exchange module to operate correctly?

A: For full functionality, including both pulling threat intelligence from Netskope (like policy violations that generate IoCs) and pushing external threat intelligence into Netskope (for policy enforcement), the Threat Exchange module generally requires API tokens for both Netskope REST API v1 and REST API v2. Ensure both are correctly configured in Cloud Exchange under Settings > Netskope Tenants with the necessary permissions.

Q: How do I create a deduplication or exception rule in Threat Exchange to prevent processing redundant IoCs?

A: To create rules that prevent redundant processing of IoCs (like excluding certain IoCs, or IoCs from specific sources from being shared further), you can configure this in a Business Rule in the Threat Exchange module:

1. In the Cloud Exchange UI, go to Threat Exchange > Business Rules.
2. Either create a new Business Rule, or edit an existing one.
3. In the Business Rule configuration, after defining your main criteria for IoC selection, look for the option to add Exception Rules or similar conditional logic. Expand a primary rule (like URL Only), and then clicking the + icon next to Exception Rules.
4. In the exception rule, you can define the criteria for IoCs that should be excluded from the actions of that Business Rule.

Q: Does Threat Exchange fetch IoCs directly from the Netskope tenant UI under Incident > Malware?

A: No. The Threat Exchange module primarily sources IoCs from Netskope based on specific Alerts generated by the platform, particularly Skope IT Malware Alerts and Malsite Alerts. It doesn’t typically pull IoCs directly from a generalized Incident > Malware overview page if that page represents a different data aggregation or view within the Netskope tenant UI. To see the types of alerts that Cloud Exchange would process for IoC generation, go to your Netskope tenant’s main Alerts page, then use the filter options to select the Alert Type as Malsite and Malware, and then click Apply.

Q: What is the purpose of the Aging Criteria setting in a Threat Exchange plugin configuration?

A: The Aging Criteria (sometimes referred to as Time To Live or TTL for indicators) in Threat Exchange determines how long Cloud Exchange will continue to consider an indicator as active after the original source platform (the third-party tool integrated via that plugin) stops reporting it or deletes it. Instead of immediately removing the IoC from its own database and from Netskope policies, Cloud Exchange will age it out based on this configured duration period (the default is often 90 days). This prevents IoCs from going in and out of policies if a source temporarily stops sending it, or if there’s a desire to keep it active for a period for historical context or extended protection, even if the original source no longer sees it as an active threat.

Q: Why Does the Trend Micro Vision One Plugin Convert Full URLs to Domains?

A: This behavior is by design and aligned with the requirements of the Trend Micro Vision One platform. The plugin processes indicators of compromise (IOCs) from Netskope and checks whether the input includes a protocol (such as http:// or https://):

• If a URL includes a protocol, it is forwarded to Trend Micro Vision One as a URL-type object.
• If a URL does not include a protocol, the plugin extracts the root domain and forwards it as a Domain-type object.

This implementation is consistent with how Trend Micro Vision One handles threat objects:

• Domain fields accept only root domains (e.g., example.com)
• URL fields require a protocol and a full URL structure (e.g., https://example.com/path)

So when a Netskope IOC is missing a protocol, the plugin assumes it is a domain entry and formats it accordingly for compatibility with the Vision One platform

Q: What are the configurational steps for configuring CTE Abnormal plugin in Cloud Exchange?

A: The following README file contains the plugin configuration guide details. It highlights the steps for Cloud Exchange configuration of CTE Abnormal Security v1.0.0 plugin. Please review and accordingly, configure the plugin to achieve your use case:abnormal_security/docs/README.md

Q: You have received notification of the planned decommission of Detect APIs from Crowdstrike. Are any changes required for Cloud Exchange (CTE), and what is the impact of this change?

A: The notification from Crowdstrike announces the deprecation (end-of-life) of Legacy Detect APIs from Crowdstrike by 30th September 2025. Since Cloud Exchange previously used these APIs for CTE integration, it will be impacted.

Hence, we want to inform you that the necessary changes to utilize the Alerts API are already included in the latest version of the CTE Crowdstrike plugin (v2.3.0). From Cloud Exchange’s perspective, you only need to update the CTE Crowdstrike plugin version.
Note: Before updating the plugin version, please make sure that “Detections (read)” scope is applied to the Client ID/Secret at Crowdstrike’s end which are being used in the CTE Crowdstrike plugin. This is necessary as CTE is transitioning from Detect APIs to Alerts API. After updating the plugin version to v2.3.0, you need to remove the “Detections” scope from the Client ID/Secret.
Please refer to the following document for instructions on updating the plugin version in Cloud Exchange: /en/update-cloud-exchange-plugins

Q: Why do I get a 401 Client Error when enabling Retrohunt in Cloud Exchange Threat Exchange?

A: 401 Client Error while enabling Retrohunt in the Threat Exchange module is typically not caused by incorrect API permissions, but by missing tenant-level prerequisites.

To successfully use the Retrohunt API, ensure the following requirements are met:

• Your tenant must be licensed for Advanced Threat Protection.
• The Retrohunt API Query feature must be enabled on your tenant by the Netskope Platform team.
• You must use an RBAC v3 token with the predefined Netskope Cloud Exchange role.
• The assigned role should have Malware permissions enabled under the Threat Protection scope.

Resolution Steps:

1. Verify that your organization has an active Advanced Threat Protection license.
2. Contact your Customer Success Manager (CSM) or Technical Account Manager (TAM) to enable the Retrohunt API Query feature if it is not already active.
3. Ensure you are using an RBAC v3 token with the correct role and permissions. 

Q: How should file profiles be managed when approaching the 8MB File Hash List limit?

A: The 8MB limit is an API payload restriction for File Hash Lists. When this limit is reached, only up to 8MB of data is processed, and any additional IoCs are skipped. This can lead to missed indicators if not handled proactively.

To avoid ingestion gaps and manual intervention, the recommended strategy is to distribute and segment file hash lists rather than relying on a single list.

Best Practices

• Use multiple file hash lists
  Distribute IoCs across separate lists based on criteria such as:
  • Severity (High / Medium / Low)
  • Source (e.g., different feeds or tools)
  • IoC type or category (if applicable).
• Align configurations accordingly
  Create separate sharing configurations and business rules, each mapped to its own dedicated file hash list. This ensures better control and avoids hitting the payload limit on a single list.

Q: Why am I unable to configure multiple Destination Profiles or encounter validation errors while using Destination Profiles in Cloud Exchange?

A: This is a known limitation in the current Cloud Exchange functionality. While configuring a single Destination Profile works as expected, attempting to configure multiple Destination Profiles may result in validation errors during setup.

As a temporary workaround, you can configure one action using a Destination Profile and another using a URL List. It is recommended to use different business rules for the Destination Profile action and the URL List action as this approach has been validated to work effectively for similar use cases.

We have confirmed that the issue has been identified, and a fix is currently in progress. This fix is planned to be included in an upcoming release of the Cloud Exchange version. Please note that URL Lists are expected to be deprecated in the future; however, the timeline is more than 6 months before end-of-life (EOL), making this a viable interim solution.

Q: Why are HTTP/HTTPS URLs not synchronizing to the Destination Profile when using Exact Match?

A: This behavior is expected. Destination Profiles do not support HTTP/HTTPS URLs when the Match Type is configured as Exact Match.

To synchronize HTTP/HTTPS URLs successfully, the Match Type must be configured as RegEx on both Cloud Exchange and the Netskope Destination Profile.

Resolution: Configure the Match Type as RegEx on both sides. In Cloud Exchange, go to Threat Exchange > Sharing, edit the relevant sharing configuration, and set Match Type to RegEx. Similarly, in the Netskope tenant, go to Destination Profiles, edit the corresponding profile, and change the Match Type to RegEx.

When configured on both sides, HTTP/HTTPS URLs will synchronize successfully.

Q: From which part of the Netskope platform does Cloud Exchange’s Risk Exchange module pull user and host risk scores?

A: The Risk Exchange module in Cloud Exchange primarily pulls user and host risk scores that are generated by Netskope’s User and Entity Behavior Analytics (UEBA) capabilities. Specifically, it often sources this information from Skope IT UBA Alerts within your Netskope tenant. To view these types of alerts directly in your Netskope tenant, go to the main Alerts page, and then use the filter options to select Alert Type as UBA, and then click Apply.

Q: Is a specific Netskope license required to fetch user risk scores using the Risk Exchange module?

A: Yes. To enable the generation of user risk scores within the Netskope platform, and make them available for Cloud Exchange’s Risk Exchange module to retrieve and share, an Advanced UEBA (User and Entity Behavior Analytics) license is generally required for your Netskope tenant.