Cloud Exchange FAQs

What versions are supported in Cloud Exchange?

The following versions of Cloud Exchange are supported:

• CE 4.2.x
• CE 5.0.0
• CE 5.0.1 and above

Can I add a proxy directly from the UI?

Yes, you can. However, after adding the proxy in the UI, you need to run the ./setup script.

Can the plugin version and Cloud Exchange version be reverted to a previous version?

No, Cloud Exchange does not support reverting to a previous version.

What is the OS update procedure and how are updates maintained?

Starting from v5.0.1, Cloud Exchange is built on top of an NS PSIRT-hardened/reviewed Ubuntu OS and therefore does not receive notifications for OS updates. The underlying OS for Cloud Exchange as a VM will be updated to the latest version, hardened, and reviewed by NS PSIRT, with every new release.

What data does Cloud Exchange store on the host machine?

• For Log Shipper: Cloud Exchange does not store any data permanently. It pulls logs from Netskope tenants, transforms them, and then shares them with the SIEM platform. Data is stored temporarily on the machine’s disk only between pulling and sharing.
• For Ticket Orchestrator: Cloud Exchange stores alerts in the database.
• For Threat Exchange: Cloud Exchange stores indicators in the database.
• For User Risk Exchange: Cloud Exchange stores user and host risk scores.
• For Application Risk Exchange: Cloud Exchange stores the application risk score.

What should be installed in the Analytics Token and JWT Token in K8S installation? What is this for?

The JWT Token secures communication between the UI and Core containers, while the Analytics Token is used to exchange analytics results with Netskope. The JWT Token is added during Cloud Exchange configuration, and the Analytics Token is hardcoded into the docker-compose.yml file.

What is AVX, and is it necessary for Cloud Exchange?

AVX stands for Advanced Vector Extensions. Yes, AVX support is required for your machine when deploying Cloud Exchange.

What are the steps for Proxy configuration in Cloud Exchange if it wasn’t configured during installation?

Follow these steps to configure the proxy:

1. Stop the running Cloud Exchange containers.
2. Execute the setup script with the command: sudo python3 ./setup.
3. When prompted during script execution, enter your proxy details (proxy server and port). Complete the rest of the setup as during installation.
4. Validate the proxy in the .env file by running: cat .env.
   • Check the variables CORE_HTTP_PROXY and CORE_HTTPS_PROXY for proxy details.
5. Start the Cloud Exchange container using: sudo ./start.

What is the supported architecture for machines to install Cloud Exchange?

Cloud Exchange v4.0.x and older versions support the x86 architecture. Machines with x86 architecture and AVX support are recommended. Further details and system requirements can be found in the Cloud Exchange System Requirements article.

What are the steps to edit/update proxy details in Cloud Exchange?

You can update proxy details by executing the setup script on the machine where CE is deployed. You can also update proxy details from the Cloud Exchange UI, but make sure to run the setup script afterward to apply the changes on the machine.

What are the steps to regenerate self-signed certificates for Cloud Exchange?

Follow these steps to regenerate self-signed certificates:

1. Go to the ta_cloud_exchange directory (or /opt/cloudexchange/cloudexchange for CE as a VM).
2. Stop Cloud Exchange services: sudo ./stop.
3. Go to the data/ssl_certs directory.
4. Remove the old certificates with: rm -rf cte_cert.crt cte_cert_key.key.
5. Return to the ta_cloud_exchange directory and run the setup script: sudo python3 ./setup.
6. Start Cloud Exchange services: sudo ./start.

Why does Cloud Exchange use user ID 1001?

Cloud Exchange uses user ID 1001 for its internal worker processes to enhance security. This ensures the least privilege, improved resource management, and a more secure containerized environment. This process is automatic, so manual intervention is not required.

What should be done when the REST API v2 token expires, and how can I tell when it is expired?

You will see this warning in Cloud Exchange when the v2 token expires.

Follow these steps to change the expiration and reissue the v2 token:

1. Log in to Netskope Tenant and select Settings.
2. Go to Tools and then REST API v2.
3. Find your v2 token used in Cloud Exchange, click the three dots, and select Change Expiration. Set the expiration as desired.
4. Reissue the token by selecting Reissue from the same menu.
5. Update the new token in Cloud Exchange under Settings > Netskope Tenants.

Does the HA feature work for both VM and non-VM Cloud Exchange deployments?

Yes, High Availability (HA) works with standalone deployments on Linux machines running Ubuntu or RHEL, as well as with Cloud Exchange deployed as a virtual machine.

Is Cloud Exchange High Availability supported with three Cloud Exchange instances running in different data centers, or do they all need to be in the same data center?

Cloud Exchange HA supports instances running across multiple data centers.

Which platforms does Cloud Exchange support for a VM?

VMWare (OVA), Google Cloud Platform (OVA), AWS (AMI), Azure (VHDX)

What is the limitation of OVA?

Users do not get the root access in the OVA. This is the only limitation.

Why is it necessary to eliminate the root for cteadmin user in OVA apart from certain commands that are required for Cloud Exchange operations?

To enhance security and prevent accidental alterations, starting from version 5.0.1, we have adopted a more restrictive approach. The cteadmin user now has limited privileges tailored specifically for managing Cloud Exchange. These privileges are designed to ensure a smooth operation while minimizing the risk of inadvertent modifications.

The sudo privileges are now restricted to essential commands required for Cloud Exchange management within the VM (OVA):

• Assigning IP Addresses:

If the DHCP server is disabled, the following commands are permitted:

• sudo systemctl restart systemd-networkd
• sudo netplan apply
• Setup, Start, Stop, and Diagnose CE:

  For setting up Cloud Exchange, as well as starting, stopping, and diagnosing Cloud Exchange containers or collecting logs, the following commands are allowed:

  • sudo ./setup
  • sudo ./start
  • sudo ./stop
  • sudo ./diagnose

By limiting privileges to these specific commands, we ensure that cteadmin users can perform necessary tasks related to Cloud Exchange management without risking unintended changes that could disrupt operations. This focused approach enhances security and stability within the Cloud Exchange environment.

How can I reboot or shut down Cloud Exchange as a VM (OVA)?

In order to reboot or shutdown the Cloud Exchange (OVA) machine, you can utilize the Actions provided in the VMware vSphere Client.

How do I upgrade to the next latest version of Cloud Exchange in Cloud Exchange as a VM Deployment?

In order to upgrade to the latest version of Cloud Exchange, you would have to set up a new Cloud Exchange instance (OVA VM) using the latest OVA file, mentioned in the documentation here.

• After a new Cloud Exchange instance is created, you can migrate your configured Cloud Exchange data from your current Cloud Exchange instance to the new Cloud Exchange instance, following Migration Procedure in the documentation here.
• Note that the upgrade of Cloud Exchange version in the same machine for Cloud Exchange as a VM deployment is not possible. Use the steps for the Migration Procedure.

How many older logs can I retrieve using Log Shipper?

Netskope tenants only store the three months of alerts in the database.

How can I retrieve the older logs using the Log Shipper module?

You can use historical pulling to retrieve the old logs from the Netskope tenant.

Go to Log Shipper > SIEM Mappings.

How can I stop the historical pulling?

You just need to restart Cloud Exchange to stop the historical pulling.

Is historical pulling of WebTx logs possible?

No, the historical pulling of WebTx logs is not possible. Note that Web Transaction events are stored in Google PubSubLite by Netskope ingestion services, and Google PubSub retains the data of the last 7 days (1 week) only. Here is some documentation with the details: https://docs.netskope.com/en/netskope-transaction-events/#query-transaction-events-metrics.

You then receive this data at your preferred destination using a subscriber such as Cloud Exchange. Therefore, no, the historical pulling of WebTx logs for a specified time range is not possible.

What are the types of Alerts and Events that can be fetched using Log Shipper?

Here is the list of Alerts and Events that could be fetched from the Netskope tenant using Cloud Exchange:

1. Alerts: Compromised Credential, Policy, Malsite, Malware, DLP, Security Assessment, Quarantine, Remediation, UBA, Watchlist, CTEP.
2. Events: Page, Application, Audit, Infrastructure, Network, Incident.

Where can I see the received indicators in the Threat Exchange module?

 You can find the indicators on the Threat IoCs page.

How can I find the received IoC’s source?

You can use the below query to find the source.

[sources.source Like "plugin name"]

How can I create tags from Cloud Exchange?

 You can create tags on the Manage Tags page.

Which Netskope API token is required for the Threat Exchange module?

 Both, the REST API V1 and REST API V2 are required for the Threat Exchange module.

How to create a deduplication rule in Threat Exchange?

In Threat Exchange, go to Business Rules, expand the Business Rule, and click the + icon.

Does Cloud Exchange fetch IoCs from Netskope > Incident > Malware.

No, Cloud Exchange only fetches IoCs from the Netskope tenant from Skope IT Malware and Malsite Alerts. On the Alerts page, click Add Filter, and for Alert Type, select Malsite and Malware, and then click Apply.

What is Aging Criteria for in Threat Exchange plugin configuration.

Aging Criteria showcases the time range of how long Cloud Exchange keep any indicator as active after it was deleted from the source platform. Default is 90 days.

Can I fetch Events and create tickets using the Ticket Orchestrator Module?

No, the Ticket Orchestrator module fetches only alerts from Netskope tenants, and then creates a ticket accordingly for them per the configuration.

How do I avoid duplicate tickets for the same alerts?

You can create a deduplication rule to avoid duplicate tickets. For details go here.

What is the retention period of alerts stored in Cloud Exchange?

The default retention period is 7 days, but you can modify it at Settings > Ticket Orchestrator.

Where does Cloud Exchange pull the user and host score from Netskope?

Cloud Exchange pulls the user and host score from Skope IT UBA Alerts. On the Alerts page, click Add Filter, and for Alert Type, select UBA, and then click Apply.

Is there any requirement for a license for fetching user scores from Netskope tenants?

Yes, an Advanced UEBA license is required for fetching user scores for Risk Exchange.