FAQ sur Cloud Exchange

Q : Qu'est-ce que 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 : Quels sont les principaux modules de Cloud Exchange et quelles données gèrent-ils ?

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

• Log Shipper (CLS): Extrait les journaux (alertes, événements, NSL) de votre locataire Netskope, les transforme et les partage avec votre SIEM ou vos plates-formes de gestion des journaux. Il stocke temporairement les données sur le disque de la machine CE uniquement pendant le processus d'extraction et de partage et ne stocke aucune donnée de manière permanente.
• Threat Exchange (CTE): Facilite le partage bidirectionnel de renseignements sur les menaces (comme les hachages de fichiers, les URL/domaines malveillants, les IP) entre Netskope et d'autres outils de sécurité (comme les plateformes de renseignements sur les menaces, les EDR). Il stocke les indicateurs dans sa base de données.
• Ticket Orchestrator (CTO): Automatise la création et la mise à jour des tickets dans les systèmes ITSM ou de gestion des cas (par exemple, ServiceNow, Jira) sur la base des alertes Netskope. Il stocke les alertes dans sa base de données.
• Risk Exchange (CREv2): Combine les capacités des modules originaux User Risk Exchange et Application Risk Exchange décrits ci-dessous.
• User Risk Exchange (CRE for Users): Partage les scores de risque des utilisateurs et des hôtes (dérivés de Netskope User and Entity Behavior Analytics - UEBA) avec d'autres systèmes pour permettre un contrôle d'accès basé sur le risque et des politiques de sécurité adaptatives. Il stocke ces scores.
• Application Risk Exchange (CRE for Applications): Partage les scores de risque des applications (basés sur le Cloud Confidence Index - CCI de Netskope) avec d'autres plateformes. Il stocke ces scores de risque d'application.

Q : Puis-je revenir à une version antérieure de Cloud Exchange ou de ses plugins ?

A: Non, Cloud Exchange ne prend pas en charge la rétrogradation ou le retour à une version antérieure de la plateforme Cloud Exchange ou des plugins individuels. Netskope vous recommande vivement de sauvegarder votre configuration Cloud Exchange avant d'effectuer toute mise à jour. Si vous devez utiliser une version spécifique plus ancienne, un nouveau déploiement de cette version est généralement nécessaire, suivi d'une restauration de la configuration si elle est disponible et compatible.

Q : Comment les mises à jour du système d'exploitation sont-elles gérées pour Cloud Exchange ?

A: À partir de Cloud Exchange v5.0.1, la plateforme est construite sur un système d'exploitation Ubuntu révisé et renforcé par Netskope PSIRT. En raison de ce durcissement, Cloud Exchange lui-même ne reçoit pas ou ne demande pas de notifications de mise à jour générale du système d'exploitation à partir des référentiels du système d'exploitation sous-jacent. Pour Cloud Exchange déployé en tant que machine virtuelle (VM/OVA), le système d'exploitation sous-jacent est mis à jour avec la dernière version renforcée et révisée à chaque version officielle de New Cloud Exchange . Pour les déploiements conteneurisés sur votre propre hôte, vous êtes responsable de la maintenance et de la sécurisation du système d'exploitation de l'hôte, tandis que Netskope assure la maintenance du système d'exploitation dans les conteneurs Cloud Exchange.

Q : Pourquoi Cloud Exchange utilise-t-il l'ID utilisateur 1001 pour ses processus ?

A: Cloud Exchange utilise un identifiant d'utilisateur non root (tel que 1001) pour ses processus de travail internes, principalement en tant que meilleure pratique de sécurité. Cela garantit le principe du moindre privilège, ce qui signifie que les processus s'exécutent avec les seules autorisations dont ils ont absolument besoin. Cette approche améliore la gestion des ressources dans l'environnement conteneurisé et contribue à un déploiement global plus sûr. Il s'agit d'un processus interne automatique qui ne nécessite pas d'intervention manuelle.

Q : Existe-t-il des limites de débit pour l'extraction ou l'exportation de journaux depuis Netskope via Cloud Exchange ?

A: L'ingestion de journaux à partir du locataire Netskope est soumise aux limites de débit de l'API (4 appels par seconde par point d'extrémité via l'API V2). 

Pour l'exportation de journaux, Cloud Exchange n'impose aucune limite de débit. Il peut transmettre jusqu'à 10 000 alertes, 10 000 événements et 5 Mo de journaux de transactions web par lot, avec des délais de livraison généralement inférieurs à 10 secondes. Cela permet d'assurer une livraison efficace des journaux en temps quasi réel tout en restant dans les limites de l'API de Netskope.

Q : Quelles sont les étapes à suivre pour effectuer des changements au niveau du serveur sur le serveur Cloud Exchange tout en s'assurant que l'intégrité des données est maintenue ?

A: Pour effectuer des modifications au niveau du serveur sur le serveur Cloud Exchange sans perdre de données :

1. Enregistrer la configuration de l'environnement (cat .env).
2. Arrêter les conteneurs Cloud Exchange (sudo ./stop).
3. Appliquez les modifications apportées au serveur/système (par exemple, disque, mémoire, système d'exploitation).
4. Exécutez à nouveau le programme d'installation (sudo ./setup) pour appliquer les changements.
5. Redémarrer les services (sudo ./start).

Ce processus garantit la préservation de l'environnement et l'intégrité des données.

Q : Devons-nous acheter une licence supplémentaire pour utiliser les fonctionnalités de Cloud Exchange ?

A: Aucune licence distincte n'est requise

Q : Pourquoi l'URL du site CE affiche-t-elle un avertissement "Non sécurisé" ? Est-ce lié à Cloud Exchange lui-même ?

A: Non, cet avertissement n'est pas causé par l'application Cloud Exchange (CE) elle-même. Le message « Non sécurisé » s’affiche dans votre navigateur car le certificat SSL/TLS de l’URL CE est soit self-signed , soit non approuvé par le navigateur.
Cela est généralement dû à la manière dont le certificat a été généré, installé ou distribué, et n'est pas géré directement par CE.

Pour installer un certificat SSL/TLS valide et fiable sur le serveur hébergeant CE. Une fois la configuration correctement effectuée, l'avertissement disparaîtra.
Nous vous recommandons de consulter votre équipe informatique/sécurité interne pour valider et corriger la configuration du certificat.

Q : Cloud Exchange supporte-t-il Ubuntu avec FIPS ?

A: Non, actuellement Cloud Exchange n'est pas testé pour Ubuntu Pro 22.04 avec FIPS. Nous vous suggérons donc de désactiver FIPS avant de déployer Cloud Exchange.

Q : Comment activer les journaux de niveau débogage dans Cloud Exchange ?

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

1. Va à Cloud Exchange > Settings > General > Logs
2. By default, the Log Level is set to Info
3. Dans la liste déroulante, sélectionnez Debug
4. Cliquez sur Save en bas de la page pour appliquer les modifications.

Q : Nous recevons cette erreur lors d'un script d'installation ou de démarrage "-bash : ./start : /bin/sh^M : mauvais interprète" ?

A: Cette erreur est due au format du fichier. Vous disposez donc de cette commande pour modifier le format du fichier.
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: Lorsque Microsoft Defender ATP et les agents CrowdStrike sont installés sur la même machine virtuelle RHEL/Ubuntu où Cloud Exchange est déployé, ils peuvent consommer une quantité importante de mémoire système en raison des activités continues d'analyse et de surveillance. Cela peut conduire à des conditions d'absence de mémoire (OOM), entraînant le blocage de l'interface utilisateur de Cloud Exchange et, dans certains cas, nécessitant un redémarrage du système pour le rétablir.

Pour atténuer ce problème, il est recommandé de mettre sur liste blanche les répertoires utilisés par Docker (généralement /var) et le chemin d'installation de Cloud Exchange sur la VM. Cela permet de réduire les analyses inutiles et d'éviter une consommation excessive de mémoire.

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. Aller à : Settings > Administration > IP Allowlist.
4. Add the identified public IP address under Netskope IP Addresses.
5. Save the configuration changes.
6. Retournez sur Cloud Exchange et réessayez la configuration du jeton API.

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?

R : 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 : Cloud Exchange peut-il fonctionner avec un CPU et une RAM inférieurs aux exigences système documentées si ma charge de travail et mon utilisation actuelle des ressources sont faibles ?

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.

Pour garantir une performance optimale et une stabilité du système, le nombre recommandé de processus de travail doit être d’environ 1.25 times the number of available CPU cores. Cette dimension aide Cloud Exchange à traiter efficacement les charges de travail, à gérer les opérations concurrentes et à maintenir des performances constantes à mesure que le volume de données et l’activité d’intégration augmentent.

Pour ces raisons, Netskope recommande de maintenir les exigences du système documentées même si l’utilisation actuelle des ressources semble faible.

Q : Comment trouver le répertoire d’installation Cloud Exchange ?

R : Si vous souhaitez connaître le répertoire d'installation de Cloud Exchange, utilisez l'une des méthodes suivantes en fonction de votre type de déploiement :

i) Pour un déploiement de Cloud Exchange conteneurisé :

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

ii) Pour un déploiement Cloud Exchange en tant que VM, le répertoire d’installation par défaut est :

/opt/cloudexchange/cloudexchange

Q : Est-ce que Cloud Exchange (CE) v6.1.0 Supporter RHEL 9.7 ?

A: Oui. Les versions minimales de Linux éligibles à Cloud Exchange sont documentées dans les Exigences du système Cloud Exchange. Pour Cloud Exchange v6.1.0, RHEL 9.5 est la version minimale qualifiée. En général, New versions mineures au-delà du minimum qualifié sont censées supporter Cloud Exchange déploiements. Par conséquent, déploiement de Cloud Exchange v6.1.0 sur RHEL 9.7 est pris en charge.

Q: Cloud Exchange prend-il en charge plusieurs configurations de locataires Netskope ?

A: Bien que Cloud Exchange permette techniquement plusieurs configurations de locataires Netskope, cela est fortement déconseillé. Exécuter plusieurs configurations de locataires simultanément peut gravement dégrader les performances et la stabilité du système de Cloud Exchange. Pour une fiabilité optimale, il est fortement recommandé de maintenir une configuration à locataire unique par déploiement.

Q: Où devrais-je ouvrir un dossier de support pour une assistance liée à Cloud Exchange ?

Q: Est-il possible de renouveler le certificat SSL de Cloud Exchange directement depuis l’interface utilisateur Cloud Exchange ?

A: Oui. Le certificat SSL Cloud Exchange peut être renouvelé directement depuis l’interface utilisateur sans avoir besoin d’un accès à la ligne de ligne.

Steps

1. Naviguez dans les paramètres → général.
2. Cliquez sur Renouveler le certificat.
3. Le certificat SSL sera automatiquement renouvelé.

Veuillez noter que Cloud Exchange affichera une notification d’avertissement 30 days before the SSL certificate expires, vous invitant à renouveler le certificat. Il est recommandé de renouveler le certificat pendant cette période afin d’éviter toute interruption de service.

Après avoir cliqué sur Renouveler le certificat, prévoyez 5 à 7 minutes pour que le processus backend se termine. Une fois terminé, ouvrez l’interface utilisateur de Cloud Exchange dans une fenêtre de navigation privée/incognito pour valider que le certificat SSL renouvelé a été appliqué avec succès.

Q : Pourquoi voyons-nous l’erreur « Impossible d’établir un lien avec https://reporting.netskope.tech... » sur la console ?

R : L'URL https://reporting.netskope.tech était précédemment utilisée pour partager des données analytiques vers le serveur d'analyse Netskope. Cette URL est utilisée dans les anciennes versions de Cloud Exchange et a depuis été obsolète. Vous pouvez ignorer cette erreur en toute sécurité. Cela ne causera aucun problème fonctionnel dans Cloud Exchange.

Q : Quelles sont les principales exigences en matière d'architecture et de fonctionnalités du processeur pour l'installation de Cloud Exchange ?

A: Cloud Exchange est conçu et testé exclusivement pour l’architecture x86_64. Une fonctionnalité essentielle requise pour le processeur est la prise en charge des extensions vectorielles avancées (AVX). Les machines doivent disposer à la fois d’une architecture x86_64 et d’un support AVX pour un fonctionnement fiable.

ARM64 Processors are Not Supported: Cloud Exchange ne prend PAS en charge les processeurs basés sur ARM64. En effet, les processeurs ARM64 ne prennent généralement pas en charge AVX, qui est une exigence fondamentale pour Cloud Exchange. L'exécution de Cloud Exchange sur des systèmes ARM64 peut entraîner des défaillances de composants critiques ou des performances peu fiables.

Pour les exigences détaillées du système (cœurs de CPU, RAM, espace disque basé sur des profils tels que Petit, Moyen, Grand), reportez-vous à Exigences du système de Cloud Exchange.

Q : Comment puis-je configurer ou mettre à jour les paramètres de proxy pour Cloud Exchange après l'installation initiale ?

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

1. Arrêtez les conteneurs Cloud Exchange en cours d'exécution : sudo ./stop
2. Accédez à votre répertoire d'installation Cloud Exchange (par exemple, cd /opt/cloudexchange/cloudexchange ou cd ta_cloud_exchange).
3. Exécutez le script d'installation :sudo python3 ./setup
4. Lorsque vous y êtes invité lors de l'exécution du script, entrez les détails de votre proxy (comme http://proxyserver.example.com:port).
5. Répondez au reste des questions d'installation.
6. Une fois le script terminé, vous pouvez valider les paramètres du proxy dans le fichier .env qui se trouve dans votre répertoire d'installation :cat .env. Recherchez les variables CORE_HTTP_PROXY et CORE_HTTPS_PROXY.
7. Démarrez les conteneurs Cloud Exchange : sudo ./start

Cloud Exchange UI Option: Vous pouvez également ajouter/modifier les détails du proxy directement depuis l’interface Cloud Exchange en allant dans Paramètres > Proxy > Général. Toutefois, pour que ces paramètres soient pleinement appliqués au niveau du système pour toutes les communications de conteneur, en particulier si Cloud Exchange lui-même doit utiliser le proxy pour les connexions sortantes de l'hôte, il est souvent nécessaire de réexécuter le script ./setup pour s'assurer que les variables d'environnement sont correctement renseignées dans le fichier .env utilisé par l'environnement d'exécution du conteneur.

Q : Comment puis-je déployer une version conteneurisée antérieure (n-1) spécifique de Cloud Exchange en utilisant 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. Accédez à votre répertoire Git Cloud Exchange (par exemple, ta_cloud_exchange):cd <your_ce_directory>.
2. Assurez-vous que votre dépôt local est à jour avec les balises/branches distantes : sudo git fetch --all --tags
3. Vérifiez l'étiquette de version spécifique que vous souhaitez déployer. Les balises de version sont généralement au format vX.Y.Z: sudo git checkout tags/<version-number>. (Exemple : sudo git checkout tags/v5.1.0)
4. Exécutez le script d'installation pour configurer cette version : sudo ./setup
5. Démarrez le Cloud Exchange : sudo ./start

Q : Comment mettre à jour mon Cloud Exchange conteneurisé d'une ancienne version à la dernière en utilisant Git ?

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

1. Accédez à votre répertoire Git Cloud Exchange : cd <your_ce_directory>.
2. Passez à la branche principale (ou à la branche désignée pour les dernières versions stables, souvent "main" ou "master") : sudo git switch main
3. Tirez les dernières mises à jour du référentiel : sudo git pull
4. Exécutez le script d'installation pour appliquer toutes les modifications de configuration de la version New: sudo ./setup
5. Démarrez le Cloud Exchange : sudo ./start

Consultez toujours les dernières notes de mise à jour de la version New pour connaître les instructions spécifiques de mise à niveau ou les considérations importantes à prendre en compte avant de procéder à une mise à niveau.

Q : Comment régénérer des certificats SSL auto-signés pour l'interface web de Cloud Exchange ?

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. Allez dans votre répertoire principal d’installation Cloud Exchange : (comme /opt/cloudexchange/cloudexchange ou ta_cloud_exchange).
2. Arrêtez les services Cloud Exchange : sudo ./stop
3. Allez dans le répertoire où les certificats SSL sont stockés, en général : cd data/ssl_certs
4. Supprimez ou sauvegardez les anciens fichiers de certificat et de clé (comme cte_cert.crt, cte_cert_key.key) :
   sudo rm -f cte_cert.crt cte_cert_key.key
5. Retournez dans le répertoire principal d'installation de Cloud Exchange: cd ../.. (si vous étiez dans données/ssl_certs)
6. Exécutez le script d'installation. Le script devrait détecter les certificats manquants et vous guider pour générer des certificats New ou les générer automatiquement : sudo python3 ./setup
7. Démarrez les services Cloud Exchange : sudo ./start

Après la régénération, votre navigateur affichera un avertissement concernant le certificat auto-signé New, que vous devrez accepter pour accéder à l'interface utilisateur.

Q : Que dois-je faire si le jeton Netskope REST API v2 utilisé par Cloud Exchange expire ?

A: Si le jeton API expire, Cloud Exchange perdra sa capacité à communiquer avec votre locataire Netskope pour extraire des données ou partager des renseignements. Vous verrez généralement une bannière d’avertissement dans l’interface Cloud Exchange indiquant quelque chose comme : « Le jeton API locataire Netskope a expiré pour [Nom du locataire]. Générez le jeton New ou réémettez le jeton et mettez à jour la configuration du locataire pour reprendre la communication entre Netskope locataire et Cloud Exchange.» 

Pour résoudre ce problème :

1. Dans votre Netskope Tenant, allez dans Settings > Tools > REST API v2.
2. Localisez le jeton API v2 spécifique que votre instance Cloud Exchange est configurée pour utiliser.
3. Cliquez sur les trois points (icône d'ellipse) à côté du jeton et sélectionnez **Modifier l'expiration**. Fixez une date d'expiration future New, appropriée.
4. Il est également conseillé de réémettre le jeton à partir du même menu. Cela génère une valeur de jeton New. Copiez la valeur du jeton New.
5. Dans l'interface utilisateur de Cloud Exchange, allez dans Paramètres > Netskope Tenants.
6. Modifiez la configuration de votre locataire et collez la nouvelle valeur du jeton dans le champ Jeton API.
7. Enregistrez la configuration du locataire mise à jour dans Cloud Exchange.

Q : Quelles plates-formes de virtualisation sont prises en charge pour le déploiement d'une VM Cloud Exchange ?

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

• VMware vSphere : en utilisant le format OVA ou Hyper-V - Open Virtualization Appliance. Vous trouverez ci-dessous le Installation Guide pour cette méthode.
• Google Cloud Platform (GCP) : souvent déployable à l'aide d'une OVA. Vous trouverez ci-dessous le Installation Guide pour cette méthode.
• Amazon Web Services (AWS) : utilisation du format AMI - Amazon Machine Image. Vous trouverez ci-dessous le Installation Guide pour cette méthode.
• Microsoft Azure : utilisation du format VHDX - Virtual Hard Disk. Vous trouverez ci-dessous le Installation Guide pour cette méthode.

Consultez toujours la dernière documentation de Netskope Cloud Exchange pour connaître les versions de plate-forme et les formats d'image pris en charge pour la version de Cloud Exchange que vous avez l'intention de déployer.

Q : Lors de l'installation de Cloud Exchange en tant que VM à l'aide du fichier OVA, j'ai vu un tas d'avertissements indiquant que "Votre noyau ne supporte pas les capacités de limite de swap ou que le cgroup n'est pas monté". Il a semblé s'installer correctement, mais je voulais savoir s'il fallait s'en inquiéter.

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 : Que faire lorsqu'un plugin n'est pas trouvé ?

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

1. Va sur Cloud Exchange > Settings > Plugin Repository.
2. Click Check for Updates (first option).
3. Click Update Plugin (third option).
4. Les plugins nouvellement ajoutés ou mis à jour seront désormais visibles. Select le plugin requis et cliquez sur Save.

Pour des informations plus détaillées, veuillez vous référer à la documentation : Dépôt de plugins

Q : Comment vérifier l'état de santé de Cloud Exchange ?

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

• From Login Page of Cloud Exchange UI: Vous pouvez consulter l'info-bulle dans le coin droit et confirmer l'état actuel des composants de Cloud Exchange (Core, UI, MongoDB, RabbitMQ).
• From Cloud Exchange CLI in the machine: Vous devez vous rendre sur le chemin où vous avez installé Cloud Exchange et vous pouvez exécuter la commande suivante pour connaître l'état des conteneurs associés à chaque composant de Cloud Exchange (Core, UI, MongoDB, RabbitMQ) :

• sudo docker ps (pour une machine Ubuntu)
• sudo podman ps (pour une machine RHEL)

Q : Comment créer un jeton V2 pour Cloud Exchange avec RBAC V3 activé dans le locataire Netskope ?

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.

Veuillez donc consulter le guide de documentation suivant, ainsi que les articles de ses sous-sections qui décrivent les étapes à suivre pour créer un jeton v2 à l'aide de RBAC V3 : /fr/managing-administrators-for-rbac-v3

Q : Le Cloud Exchange Log Shipper peut-il extraire des logs du Netskope Cloud Proxy par le biais de notre proxy sur site ?

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 : Pourquoi me demande-t-on des identifiants Git lors d’opérations git pull ou git clone ?

Si Git demande des identifiants lors d’une opération git pull ou git clone , il peut utiliser des informations d’authentification mises en cache ou obsolètes stockées par le gestionnaire de crédenceaux Git.

Pour effacer les identifiants mis en cache, exécutez la commande suivante :

git credential reject

Après avoir supprimé les identifiants mis en cache, réessayez l’opération Git. Git demandera à nouveau l’authentification et vous permettra de saisir les bonnes identifiantes.

Si le problème persiste, vérifiez que l’URL du dépôt, la méthode d’authentification et les autorisations d’accès sont correctement configurées.

Q : Dois-je effectuer une sauvegarde CE avant une mise à niveau ? Une sauvegarde peut-elle être effectuée via l'interface utilisateur CE ?

A: Oui, c’est recommended to take a backup avant de procéder à une mise à niveau. Cette sauvegarde aidera à restaurer l’environnement en cas de problème pendant ou après la mise à niveau.

Cependant, notez que la sauvegarde de Cloud Exchange cannot être effectuée via l'interface utilisateur de CE. Reportez-vous à la documentation contenant les étapes de sauvegarde : /en/backup-cloud-exchange.

Q : Cloud Exchange High Availability (HA) est-il pris en charge pour les déploiements de machines virtuelles et de conteneurs ?

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 : Un cluster Cloud Exchange HA peut-il fonctionner avec des nœuds situés dans des centres de données différents (Multi-DC) ?

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

Q : Quelle est l'approche recommandée pour déployer un cluster HA dans plusieurs centres de données (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 : Des problèmes de performance sont-ils à prévoir si les nœuds Cloud Exchange HA sont déployés dans différents centres de données (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.

Les performances peuvent être affectées par :

• Latence du réseau entre les centres de données.
• Perte de paquets sur les liaisons entre le centre de données.
• Limitations de la bande passante entre les sites.

Une conception soignée du réseau, une planification de la capacité des liens inter-DC, des stratégies appropriées d'équilibrage de la charge en amont du cluster Cloud Exchange et des tests rigoureux de basculement sont essentiels pour identifier et atténuer les impacts potentiels sur les performances dans le cadre d'un déploiement HA multi-DC.

Q : Comment fonctionne le basculement et la gestion du trafic dans une configuration Multi-DC HA pour Cloud Exchange ?

A: Cloud Exchange HA est conçu pour le basculement automatique. Si un nœud actif du cluster devient non réactif ou échoue, le mécanisme HA détecte la défaillance et coordonne la promotion d’un nœud de veille en bonne santé (qui peut résider dans un autre centre de données) pour prendre en charge les opérations actives. La redirection du trafic vers le nœud actif New dépend de votre architecture de déploiement, telle qu’un équilibreur de charge externe, les mises à jour DNS ou les mécanismes de réessai côté client utilisés par les applications intégrées.

Les tests complets pour un déploiement Multi-DC HA incluent généralement les scénarios suivants :

• Simuler des défaillances de nœuds (par exemple, éteindre une VM, arrêter les services Cloud Exchange ou redémarrer des conteneurs sur un nœud).
• Valider la cohérence et l’intégrité des données à travers tous les nœuds et le stockage distribué GlusterFS après un basculement.
• Tester les opérations de lecture/écriture sur le volume GlusterFS depuis tous les nœuds actifs et de secours.
• Vérification de l’état du cluster GlusterFS, y compris l’état du volume et la réplication/synchronisation.
• Confirmation du statut de synchronisation HA et garantie d’une communication saine entre tous les nœuds du cluster.

Q : Quels modules de Cloud Exchange (CLS, CTE, CTO, CRE) sont généralement vérifiés lors des tests Multi-DC HA ?

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): Vérification du partage, de la synchronisation et de l'application sans faille des renseignements sur les menaces dans l'ensemble du cluster et avec les outils de sécurité intégrés.
• CTO (Cloud Ticket Orchestrator): Tester que la création automatisée de tickets, les mises à jour et la synchronisation avec les systèmes ITSM continuent à fonctionner correctement et sans créer de doublons erronés.
• CRE (Cloud Risk Exchange): Veiller à ce que les scores de risque des utilisateurs, des hôtes et des applications continuent d'être évalués, partagés et mis à la disposition des systèmes intégrés.

Q : Quelle est la procédure d'arrêt et de redémarrage des nœuds Cloud Exchange en HA ?

A: Follow the shutdown and startup sequence outlined below:

Stopping Cloud Exchange:

1. Arrêtez chaque nœud secondaire un par un.
2. Arrêtez le nœud primaire.

Starting Cloud Exchange:

1. Démarrez d'abord le nœud principal.
2. Démarrez chaque nœud secondaire un par un.

Q : Un serveur NFS sera-t-il toujours nécessaire pour la haute disponibilité (HA) après la mise à jour vers Cloud Exchange 6.x ?

A: À partir de Cloud Exchange 6.x, l’architecture de haute disponibilité (HA) ne nécessite plus de serveur NFS. Clients qui passent à Cloud Exchange 6.1.0 ou plus tard, ils peuvent retirer le serveur NFS de leur déploiement HA, car le stockage partagé n’est plus une dépendance pour HA.

Q : Comment mettre hors service le nœud principal en HA et le rajouter au cluster HA ?

A: Suivez ces étapes pour arrêter en toute sécurité le nœud principal et le rejoindre au cluster HA :

1. Le nœud rejoindra le cluster sans erreur. L’un des nœuds secondaires assumera automatiquement le rôle principal pendant les temps d’arrêt.
2. Arrêtez le nœud principal en vous connectant à l’une des interfaces secondaires de CE (CE).
3. Effectuez les actions que vous devez effectuer sur le nœud principal.
4. Avant de démarrer CE sur l’ancien nœud principal, assurez-vous que le service serveur de gestion fonctionne en exécutant : sudo systemctl status cloud-exchange
5. Démarrez le nœud principal depuis l’interface CE de l’un des nœuds secondaires actifs en utilisant l’option Redémarrer dans Configurations de nœuds dans les Paramètres généraux.

Q : Jusqu'à quand Log Shipper peut-il récupérer l'historique des alertes du locataire Netskope ?

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 : Comment puis-je effectuer une extraction historique des anciens journaux à l'aide du module Log Shipper ?

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

1. Dans l'interface utilisateur de Cloud Exchange, accédez au module Log Shipper à partir du menu principal.
2. Dans Log Shipper, accédez à la section SIEM Mappings (ou à une section portant un nom similaire et chargée de configurer les destinations des données).
3. Sur la page Mappages SIEM, recherchez l'option Extraire les données historiques, où vous pouvez sélectionner une plage de dates pour extraire les données historiques. Ouvrez la boîte de dialogue en cliquant sur l'icône de la page Mappages SIEM (près de la liste des mappages ou des règles existants).
4. Dans la boîte de dialogue Extraire les données historiques, sélectionnez la plage de dates de début et de fin pour laquelle vous souhaitez extraire les journaux, puis lancez le processus d'extraction.

Important Considerations:

• L'extraction d'un grand volume de données historiques peut prendre du temps et solliciter à la fois le locataire Netskope et votre instance Cloud Exchange. Planifiez en conséquence.
• En fonction des paramètres d'ingestion de votre SIEM et de la manière dont il gère les horodatages, l'extraction de données historiques peut entraîner une duplication des journaux si ceux-ci ont déjà été partiellement ingérés ou si les plages de temps se chevauchent avec des flux en cours.

Q : Comment puis-je interrompre une extraction d'historique en cours dans Log Shipper si nécessaire ?

A: Oui. Si vous devez interrompre un processus d'extraction historique actif dans Log Shipper, la méthode générale consiste à redémarrer les services Cloud Exchange. Cela peut être fait via l'interface de ligne de commande (CLI) sur l'hôte Cloud Exchange en allant dans le répertoire d'installation de Cloud Exchange et en exécutant sudo ./stop suivi de sudo ./start.

Q : Quels sont les types d'alertes et d'événements que Log Shipper peut typiquement récupérer du locataire Netskope ?

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: Alertes de compromission d'informations d'identification, alertes de violation de politique (pour diverses politiques telles que l'accès au web, l'utilisation d'applications en nuage, etc.), alertes d'accès à des sites malveillants, alertes de détection de logiciels malveillants, incidents DLP (Prévention des pertes de données), résultats d'évaluation de la sécurité (mauvaises configurations), actions de mise en quarantaine, événements de remédiation, anomalies et alertes UBA (User and Entity Behavior Analytics), alertes de liste de surveillance, CTEP , périphérique et contenu.
• Events: Événements détaillés d'accès aux pages, événements d'utilisation des applications, journaux d'audit (suivi des actions administratives au sein de la plateforme Netskope), événements liés à l'infrastructure, événements réseau (si applicable à vos services Netskope), et incidents de sécurité globaux qui regroupent les alertes/événements connexes, journaux d'état des points d'extrémité et des clients.

Q : Quels indicateurs dans Cloud Exchange peuvent aider à vérifier l'actualité des journaux extraits de Netskope et envoyés à des serveurs de journaux externes ?

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 : Qu'est-ce que le client de streaming Docker ? Quelle est la différence avec le 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.

Principales différences :

Q : Si nous disposons déjà d'un SIEM capable de recevoir les journaux TX, devons-nous encore acheter un espace de stockage supplémentaire dans le cloud public ?

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 : Comment Cloud Exchange gère-t-il les journaux non envoyés si un plugin CLS sortant (par exemple, le plugin Syslog) ne parvient pas à transmettre les journaux en raison d'un problème de réseau (par exemple, des restrictions de pare-feu, etc.) ?

A: Lorsque Cloud Exchange rencontre un problème réseau lors du transfert des journaux, il tentera de les renvoyer up to 3 times. Si la livraison échoue toujours, les journaux sont jetés.

Cependant, vous pouvez activer l'option “Retry Till Successful Delivery” pour vous assurer que les journaux sont continuellement réessayés jusqu'à ce que la livraison soit réussie.

En outre, il est possible de retrouver des événements historiques. Si Cloud Exchange n'est pas en mesure d'ingérer les logs pendant une fenêtre de temps spécifique en raison d'un problème, vous pouvez toujours extraire ces logs plus tard tant qu'ils restent disponibles dans votre locataire Netskope (puisque Cloud Exchange récupère les logs directement à partir du locataire).

Q: Les journaux BWAN peuvent-ils être envoyés à Chronicle à l'aide du plugin Cloud Exchange ?

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 : Quelles sont les validations du délai d'ingestion des logs dans 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. Par exemple, veuillez consulter les messages ci-dessous concernant l'extraction d'alertes de logiciels malveillants à partir du locataire Netskope :

"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. Veuillez confirmer si le retard dans l'ingestion des logs est dû aux erreurs survenues lors de l'ingestion des logs dans votre SIEM :

Par exemple, veuillez consulter les messages de journal ci-dessous concernant l'ingestion d'alertes/événements vers votre destination préférée et cela prend plus de 10 secondes : 

• "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.

Pour votre référence, nous avons mis en évidence les informations ci-dessus dans la documentation suivante : /fr/Cloud Exchange-system-requirements

Par conséquent, sur la base de ces observations, nous vous demandons sincèrement de vérifier le problème de retard dans la réception des journaux du côté de votre SIEM.

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: Cette erreur se produit si vous utilisez l'ancienne version WebTx plugin configurée avec Google Pub/Sub, qui a atteint sa fin de vie (EOL). Pour résoudre ce problème, vous devez migrer vers la New Netskope Log Streaming plugin pour votre cas d'utilisation WebTx, ce qui nécessite la génération d'un New jeton.

A: Selon les directives officielles de Google SecOps, le compte de service et les identifiants correspondants nécessaires à l’intégration de Chronicle (API d’ingestion) ne doivent pas être générés indépendamment par le client. Au lieu de cela, ces identifiants sont fournis directement par l’équipe de support ou le représentant de Google SecOps.

Q : Comment la clé de compte de service devrait-elle être générée pour l’intégration du plugin Google Chronicle dans Netskope Cloud Exchange ?

A: Il est conseillé aux clients de contacter leur équipe Google SecOps pour obtenir la bonne clé de compte de service, car cela garantit une configuration adéquate et évite les erreurs d’authentification ou d’ingestion. Netskope ne recommande pas de générer ou de documenter des étapes personnalisées pour la création de clés, car le processus peut varier selon l’environnement Google et la configuration du client.

Pour plus de détails, veuillez consulter la documentation officielle de Google.

Q : Le module Ticket Orchestrator peut-il utiliser les événements Netskope (en plus des alertes) pour créer des tickets dans un système ITSM ?

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 : Comment puis-je empêcher Ticket Orchestrator de créer des tickets en double pour la même alerte Netskope récurrente ?

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 : Quelle est la durée de conservation par défaut des alertes stockées localement par Cloud Exchange pour le module Ticket Orchestrator, et peut-elle être modifiée ?

A: À des fins de suivi et de déduplication des tickets, le module Ticket Orchestrator stocke les informations d'alerte localement dans Cloud Exchange. La durée de conservation par défaut de ces alertes stockées est généralement de 7 jours. Et oui, cette période de conservation peut être modifiée dans l'interface utilisateur de Cloud Exchange en accédant à Paramètres > Ticket Orchestrator (ou un chemin similaire pour les paramètres spécifiques au module) et en ajustant la valeur de conservation des alertes en fonction de vos besoins opérationnels.

Q : Pourquoi le champ Jira Status n’est-il pas mis à jour selon les mappages du champ du plugin ?

R : C’est une limitation connue de Jira. Le champ Statut est un champ géré par le système et ne peut pas être modifié directement via les API REST standard de Jira. Les changements de statut dans Jira ne peuvent se produire que par des transitions de workflow définies plutôt que par des mises à jour directes du champ.

En conséquence, toute correspondance de statut configurée dans le plugin ne sera pas appliquée lors de la création ou de la mise à jour des problèmes Jira.

En plus du champ Status, certains autres champs gérés par le système Jira peuvent également être restreints pour les mises à jour directes via l’API, selon le type de déploiement Jira et la configuration du workflow.

Pour les champs nécessitant des mises à jour basées sur workflow, Jira workflow transitions devraient être utilisées à la place des mappages de champs.

Q : Où, dans l'interface utilisateur de Cloud Exchange, puis-je afficher les indicateurs de menace (IoC) reçus par le module Threat Exchange ?

AVous pouvez consulter les indicateurs de menace que Threat Exchange a traités et stockés en allant dans Threat Exchange (dans le panneau latéral gauche) puis en sélectionnant Threat IoCs. Cette page affiche un tableau triable et filtrable répertoriant les IoC, y compris leur valeur, leur type (comme URL, MD5, SHA256, IP), les résultats Netskope et les résultats provenant d'autres sources.

Q : Comment puis-je identifier la source originale d'une menace IoC spécifique répertoriée dans Cloud Exchange ?

A: Sur la page Threat Exchange > Threat IoCs , l’interface utilisateur offre des capacités de filtrage. Pour trouver des IoC provenant d’une source particulière (comme un plugin spécifique, comme Proofpoint ou CrowdStrike), vous pouvez utiliser le constructeur de filtres. Le format de langage de requête sous-jacent peut être quelque chose comme [sources.source Like "plugin_identifier"] ou similaire, que vous pouvez souvent construire en utilisant l’interface de filtre de l’interface utilisateur en sélectionnant le champ source et en spécifiant le nom ou l’identifiant du plugin.

Q : Comment puis-je créer et gérer des balises pour les objets de confiance dans le module Threat Exchange ?

ALes balises permettent de catégoriser et de gérer les indicateurs de compromission (IoC). Vous pouvez créer et gérer ces balises en allant dans Threat Exchange (dans le panneau latéral gauche) puis en sélectionnant Gérer les balises. Vous pouvez saisir un nom de balise (comme High_Confidence_Malware_URL) et l'ajouter. Les étiquettes existantes sont également listées sur cette page, avec des options pour les modifier ou les supprimer.

Q : Quelles sont les versions des jetons API de Netskope nécessaires au bon fonctionnement du module Threat Exchange ?

APour une fonctionnalité complète, incluant à la fois l'extraction de renseignements sur les menaces de Netskope (comme les violations de politique qui génèrent des IoC) et l'envoi de renseignements sur les menaces externes vers Netskope (pour l'application des politiques), le module Threat Exchange nécessite généralement des jetons d'API pour les API REST v1 et v2 de Netskope. Assurez-vous que les deux sont correctement configurés dans Cloud Exchange sous Paramètres > Locataires Netskope avec les autorisations nécessaires.

Q : Comment créer une règle de déduplication ou d'exception dans Threat Exchange pour empêcher le traitement d'IoC redondants ?

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. Dans l'interface utilisateur de Cloud Exchange, allez à Threat Exchange > Business Rules.
2. Créez une règle de gestion New ou modifiez une règle existante.
3. Dans la configuration des règles de gestion, après avoir défini vos principaux critères de sélection des interfaces de communication, recherchez l'option permettant d'ajouter des règles d'exception ou une logique conditionnelle similaire. Développez une règle primaire (comme URL Only), puis cliquez sur l'icône + à côté de Exception Rules.
4. Dans la règle d'exception, vous pouvez définir les critères pour les objets de confiance qui doivent être exclus des actions de cette règle de gestion.

Q : Threat Exchange récupère-t-il les IoC directement à partir de l'interface utilisateur du locataire Netskope sous Incident > Malware ?

A:Non. Le module Threat Exchange s’approvisionne principalement en IoC de Netskope en se basant sur des alertes spécifiques générées par la plateforme, en particulier les alertes malware IT de Skope et les alertes malsite. Il ne retire généralement pas les IoC directement d’une page générale d’aperçu des incidents > des logiciels malveillants si cette page représente une agrégation de données ou une vue différente dans l’interface utilisateur du locataire Netskope. Pour voir les types d’alertes que Cloud Exchange traiterait pour la génération d’IoC, rendez-vous sur la page principale des Alertes de votre locataire Netskope, puis utilisez les options de filtre pour sélectionner le type d’alerte comme Malsite et Malware, puis cliquez sur Appliquer.

Q : À quoi sert le paramètre Critères de vieillissement dans la configuration d'un plugin Threat Exchange ?

A: Les critères de vieillissement (parfois appelés durée de vie ou TTL pour les indicateurs) dans Threat Exchange déterminent combien de temps Cloud Exchange continuera à considérer un indicateur comme actif après que la plateforme source d'origine (l'outil tiers intégré via ce plugin) cesse de le signaler ou le supprime. Au lieu de supprimer immédiatement l'IoC de sa propre base de données et des politiques Netskope, Cloud Exchange le supprimera en fonction de cette période de durée configurée (la valeur par défaut est souvent de 90 jours). Cela empêche les indicateurs de compromission (IoC) d'être activés et désactivés par les politiques si une source cesse temporairement de les envoyer, ou s'il est souhaité de les maintenir actifs pendant un certain temps à des fins de contexte historique ou de protection étendue, même si la source d'origine ne les considère plus comme une menace active.

Q : Pourquoi le plugin Trend Micro Vision One convertit-il les URL complets en domaines ?

ACe comportement est intentionnel et conforme aux exigences de la plateforme Trend Micro Vision One. Le plugin traite les indicateurs de compromission (IOC) de Netskope et vérifie si l'entrée inclut un protocole (tel que http:// ou 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.

Cette mise en œuvre est cohérente avec la manière dont Trend Micro Vision One gère les objets de menace :

• Les champs de domaine n'acceptent que les domaines racines (par exemple, example.com).
• Les champs URL nécessitent un protocole et une structure URL complète (par exemple, https://example.com/path)

Ainsi, lorsqu'il manque un protocole dans un IOC Netskope, le plugin suppose qu'il s'agit d'une entrée de domaine et la formate en conséquence pour qu'elle soit compatible avec la plateforme Vision One.

Q : Quelles sont les étapes de configuration du plugin CTE Abnormal dans Cloud Exchange ?

ALe fichier README suivant contient les détails du guide de configuration du plugin. Il décrit les étapes de configuration du plugin CTE Abnormal Security v1.0.0 pour Cloud Exchange. Veuillez consulter et configurer le plugin en conséquence pour répondre à vos besoins :abnormal_security/docs/README.md

Q : Vous avez été informé de la mise hors service prévue des API Detect sur le site CrowdStrike. Des changements sont-ils nécessaires pour Cloud Exchange (CTE), et quel est l'impact de ces changements ?

A: La notification de CrowdStrike annonce la dépréciation (fin de vie) de Legacy Detect APIs from Crowdstrike d’ici le 30 septembre 2025. Puisque Cloud Exchange utilisait auparavant ces API pour l’intégration CTE, cela sera impacté.

Par conséquent, nous souhaitons vous informer que les changements nécessaires pour utiliser le site Alerts API sont déjà inclus dans la dernière version du site CTE Crowdstrike plugin (v2.3.0). Du point de vue de Cloud Exchange, il suffit de mettre à jour la version du plugin CTE CrowdStrike.
Note: Avant de mettre à jour la version du plugin, veuillez vous assurer que la portée de “Detections (read)” est appliquée à l'ID du client/au secret du côté de CrowdStrikequi sont utilisés dans le plugin CTE CrowdStrike. Cela est nécessaire car la CTE passe des API de détection à l'API d'alerte. Après avoir mis à jour la version du plugin à v2.3.0, vous devez supprimer le champ d'application "Détections" de l'ID/Secret du client.
Veuillez consulter le document suivant pour obtenir des instructions sur la mise à jour de la version du plugin dans Cloud Exchange: /fr/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 : Pourquoi les URL HTTP/HTTPS ne se synchronisent-elles pas avec le profil de destination lors de l’utilisation de la correspondance exacte ?

A: Ce comportement est attendu. Les profils de destination ne prennent pas en charge les URL HTTP/HTTPS lorsque le type de correspondance est configuré comme correspondance exacte.

Pour synchroniser correctement les URL HTTP/HTTPS, le Type de Correspondance doit être configuré en RegEx à la fois sur Cloud Exchange et sur le profil de destination Netskope.

Resolution: Configurez le Match Type comme RegEx des deux côtés. Dans Cloud Exchange, allez dans Threat Exchange > Sharing, modifiez la configuration de partage pertinente, et définissez le Type de correspondance à RegEx. De même, dans le locataire Netskope, allez dans Destination Profiles, modifiez le profil correspondant, et changez le Type de Correspondance en RegEx.

Lorsqu’ils sont configurés des deux côtés, les URL HTTP/HTTPS se synchronisent avec succès.

Q : De quelle partie de la plateforme Netskope le module Risk Exchange de Cloud Exchange tire-t-il les scores de risque de l'utilisateur et de l'hôte ?

ALe module Risk Exchange de Cloud Exchange récupère principalement les scores de risque des utilisateurs et des hôtes générés par les fonctionnalités d'analyse comportementale des utilisateurs et des entités (UEBA) de Netskope. Plus précisément, ces informations proviennent souvent des alertes Skope IT UBA au sein de votre locataire Netskope. Pour consulter ces types d'alertes directement dans votre locataire Netskope, accédez à la page principale Alertes , puis utilisez les options de filtre pour sélectionner UBA comme type d'alerte, puis cliquez sur Appliquer.

Q : Une licence Netskope spécifique est-elle nécessaire pour récupérer les scores de risque des utilisateurs à l'aide du module Risk Exchange ?

A: Oui. Pour permettre la génération de scores de risque utilisateur au sein de la plateforme Netskope, et les rendre disponibles pour que le module Risk Exchange de Cloud Exchange puisse les récupérer et les partager, une licence UEBA avancée (analyse du comportement des utilisateurs et des entités) est généralement requise pour votre locataire Netskope.