Guide des solutions d'intégration de CrowdStrike et Netskope

Zero Trust Risk Framework: Building Adaptive Policy with CrowdStrike Context

Un guide d'intégration stratégique et opérationnel pour les architectes de sécurité et les administrateurs de politiques

1. Introduction

Le Zero Trust est une stratégie, pas un interrupteur. Accorder ou refuser l’accès en deux états — autorisé ou bloqué — laisse les équipes de sécurité avec un outil rudimentaire dans un environnement de menaces nuancé. La politique réelle doit correspondre au risque réel : un utilisateur sur un ordinateur portable d’entreprise sain et entièrement corrigé accédant à un outil SaaS standard à 9 h. mérite une expérience différente de celle du même utilisateur sur un périphérique dont le niveau de sécurité est dégradé et qui accède à une charge de travail cloud sensible depuis un emplacement inhabituel.

Le Zero Trust Engine de Netskope est au cœur de la plateforme Netskope One. Il décode et déchiffre chaque transaction en temps réel, évalue en continu plus de 50 variables contextuelles pour établir un profil de risque granulaire, puis applique la politique précise correspondant à ce profil. CrowdStrike enrichit ce profil avec des signaux haute fidélité provenant du terminal, de la couche d'identité et du réseau de renseignements sur les menaces que Netskope ne peut pas voir seul.

Ce document couvre le cadre de risque zero trust et la carte d'intégration complète, y compris les versions de plugin, les portées d'API requises, les prérequis de licence, une comparaison des deux méthodes de partage d'IOC, les références de dépannage, les chemins d'escalade du support, les intégrations en sens inverse qui permettent à une console côté CrowdStrike de déclencher directement une action Netskope (section 4.11), le pipeline d'événements AI SecOps vers Falcon Next-Gen SIEM (section 4.9.3), un modèle SOAR construit sur le terrain utilisant l'API Device Tags (section 4.11.3), et une note sur les listes de marché qui reconditionnent des capacités existantes sous un nom différent (section 4.12).

Intended Audience

Architectes de sécurité, responsables de programmes Zero Trust et administrateurs de politiques élaborant ou affinant un déploiement conjoint Netskope + CrowdStrike. Les guides d'intégration individuels liés tout au long de ce document restent la source faisant autorité pour les étapes de configuration exactes et constituent le premier endroit à consulter lorsqu'un écran de l'interface utilisateur diffère de ce qui est décrit ici. L'interface utilisateur du plugin Netskope Cloud Exchange change entre les versions.

1.1 Glossaire des termes

Des acronymes sont utilisés tout au long de ce document. Les formes complètes sont indiquées lors de la première utilisation dans le corps du texte ; la liste complète est fournie ci-dessous à titre de référence.

Term	Forme complète/Définition
ZTA	Évaluation Zero Trust — score de santé continu des périphériques de CrowdStrike
ZTNA	Accès réseau Zero Trust — accès à distance par application et conscient de l'identité (Netskope Private Access)
UEBA	Analyse du comportement des utilisateurs et des entités (UEBA) — moteur de scoring de risque comportemental de Netskope
CCI	Cloud Confidence Index — évaluation des risques de Netskope pour les applications cloud
DLP (Prévention des pertes de données)	Prévention des pertes de données
IOC	Indicateur de compromission (comme un hachage, un domaine ou une adresse IP malveillant(e))
IOA	Indicateur d'attaque — preuve comportementale d'une technique d'attaque active
IOM	Indicateur de mauvaise configuration — une configuration de ressource cloud qui augmente la surface d'attaque
CVE	Common Vulnerabilities and Exposures — l'identifiant public d'une vulnérabilité logicielle connue
SCIM	System for Cross-domain Identity Management — le protocole utilisé pour synchroniser les utilisateurs/groupes entre les locataires
XDR	Détection et réponse étendues (XDR)
SIEM	Gestion des informations et des événements de sécurité (SIEM)
RTR	Real-Time Response — la fonctionnalité d'accès à distance aux hôtes et de script de CrowdStrike
CE	Cloud Exchange — le courtier d'intégration low-code de Netskope
CRE	Cloud Risk Exchange — le module de risque unifié de Cloud Exchange. Depuis Cloud Exchange v4.1.0+, CRE consolide ce qui était auparavant des sous-modules distincts, User Risk Exchange (URE) et Application Risk Exchange (ARE), en un seul module Risk Exchange qui ingère conjointement les scores de risque des périphériques, des utilisateurs/hôtes, des identités et des applications. Les listes de plugins tiers individuels dans le portail de connaissances Netskope peuvent encore porter un suffixe hérité « (URE) » dans leur nom, mais ils se configurent et s’exécutent tous sous ce module Risk Exchange (CRE) unique de génération actuelle — voir la section 3.2 pour savoir comment ce document les regroupe.
URE	User Risk Exchange — l'ancien nom du sous-module de risque utilisateur/hôte, désormais fusionné dans CRE (voir CRE ci-dessus). Conservé dans ce document uniquement lorsqu'il apparaît dans le nom officiel d'un plugin spécifique.
CSPM	Gestion du niveau de sécurité dans le cloud
NPA	Netskope Private Access
SSE	Security Service Edge
SASE	Secure Access Service Edge
MTTR	Temps moyen de réponse/résolution
RBAC	Contrôle d’accès basé sur les rôles (RBAC)
CASB	Cloud Access Security Broker
SOAR	Orchestration, automatisation et réponse en matière de sécurité
ECS	Elastic Common Schema — la convention de nommage de champ normalisée (event.action, event.severity, etc.) que l'analyseur netskope-sse de CrowdStrike mappe dans les événements Netskope au sein de Falcon Next-Gen SIEM.
HEC	HTTP Event Collector — le type de connecteur Falcon Next-Gen SIEM qui reçoit les événements transmis par webhook via HTTP

2. Cadre de risque Zero Trust de Netskope

2.1 Le Zero Trust Engine

Le Zero Trust Engine est la structure d'évaluation des risques et d'application des politiques en ligne de Netskope. Il fonctionne à ce que Netskope appelle la couche 8, au-dessus de la pile réseau traditionnelle, pour comprendre non seulement qui se connecte et où, mais aussi ce qu'ils font, avec quelles données, dans quelle instance d'application et dans quelles conditions de risque. Chaque transaction est évaluée par rapport à ce contexte complet avant qu'une décision de stratégie ne soit appliquée.

Le moteur applique une confiance adaptative continue. Il ne prend pas une décision d'accès unique lors de l'établissement de la session pour ensuite se retirer. La télémétrie des risques est recueillie en continu et la politique peut changer en cours de session si le profil de risque évolue.

2.2 Cinq dimensions du contexte de risque

La politique Netskope évalue simultanément le risque selon cinq dimensions. Chaque dimension peut être enrichie avec des signaux externes, y compris des signaux provenant de CrowdStrike.

Dimension	Ce que Netskope évalue
Utilisateur	Qui est l'utilisateur ? Quel est leur score de risque comportemental (UEBA — Analyse du comportement des utilisateurs et des entités) ? Sont-ils anormaux par rapport à leur groupe de pairs ? Ont-ils été signalés dans un groupe de risque ?
périphérique	Le périphérique est-il géré ou non géré ? Quelle est sa posture de sécurité : agent installé, système d’exploitation corrigé, disque chiffré, certificats valides ? Une menace a-t-elle été détectée dessus ?
Application	À quelle application l'utilisateur accède-t-il ? Quel est son score de risque CCI (Cloud Confidence Index) ? L'utilisateur accède-t-il à une instance personnelle ou à une instance d'entreprise ? S'agit-il d'une application approuvée ?
Data	Quelle est la sensibilité des données concernées ? Correspond-il à un profil DLP (Prévention des pertes de données) : PII, code source, données financières, contenu réglementé ? Quelle activité est effectuée : affichage, chargement, partage, téléchargement, impression ?
Réseau / Localisation	D'où l'utilisateur se connecte-t-il ? L'adresse IP source ou l'emplacement sont-ils cohérents avec un comportement normal ? La destination est-elle un domaine ou une adresse IP malveillant(e) connu(e) ?

2.3 Actions de politique : un éventail de résultats

Comme le Zero Trust Engine évalue les cinq dimensions ensemble, les résultats des politiques peuvent être bien plus précis qu’une décision binaire d’autorisation ou de blocage. Les résultats suivants sont disponibles et peuvent être combinés ou déclenchés de manière conditionnelle en fonction des seuils de score de risque :

Action	Quand l'utiliser
Allow	Accès complet sans restriction. Réservé aux transactions à faible risque et à haute confiance.
Alerter	L'accès se poursuit ; un événement de sécurité est consigné et peut déclencher une alerte SIEM (Security Information and Event Management).
Coach/Justify	Un avertissement est présenté à l'utilisateur. Ils doivent accuser réception ou justifier l'action avant de continuer. Efficace pour les situations à risque limite sans perturber le workflow.
Restreindre l'activité	Autoriser l'accès à l'application mais bloquer des activités spécifiques au sein de celle-ci. Par exemple : autorisez la consultation et le téléchargement, mais bloquez le chargement, le partage et l'impression.
Accès restreint	Réduisez le périmètre d'accès à mesure que le risque augmente. Un utilisateur avec un score de risque de périphérique modéré pourrait obtenir un accès en lecture seule ; un utilisateur avec un score élevé pourrait ne pas avoir d’accès.
Isolation de navigateur à distance	Lorsque les utilisateurs accèdent à des destinations à haut risque, acheminez la session via un intermédiaire limité, le navigateur distant, afin qu’aucun contenu ne s’exécute localement. Efficace pour les sites non vérifiés ou à risque qui ne doivent pas être totalement bloqués.
Mise en quarantaine	Interceptez un téléchargement de fichier (upload ou download) et acheminez-le vers un emplacement de quarantaine pour examen.
Block	Refuser totalement l'accès. Appliqué lorsque le risque dépasse un seuil défini ou que la destination est connue comme malveillante.
Reclassifier le périphérique	Modifiez le statut géré/non géré du périphérique en temps réel, déclenchant automatiquement un niveau de politique différent.
Déplacer l’utilisateur vers un groupe	Attribuez automatiquement l'utilisateur à un groupe à accès restreint, qui correspond alors à un ensemble de politiques plus restrictif.
Notification utilisateur	Déclenchez une notification à l'utilisateur et à son responsable via ITSM, e-mail ou Slack.

3. Stratégie d'intégration : comment CrowdStrike enrichit la stratégie Netskope

CrowdStrike contribue à quatre catégories de signaux que le Zero Trust Engine ne peut pas déduire de la seule inspection du trafic inline : santé du périphérique, risque lié à l’identité de l’utilisateur, renseignement sur les menaces et posture de la charge de travail cloud. Chaque catégorie alimente une ou plusieurs des cinq dimensions de risque décrites dans la section 2, permettant des résultats de politique qui nécessiteraient autrement une intervention manuelle.

Les intégrations utilisent deux canaux principaux :

• Netskope Cloud Exchange (CE) : une plateforme d'intégration low-code auto-hébergée qui héberge des plugins pour Risk Exchange (CRE), Threat Exchange, Log Shipper et les workflow ITSM.
• CrowdStrike Falcon Foundry : un framework d'application natif hébergeant l'application Direct to Zero Trust, qui normalise et déduplique les IOC (indicateurs de compromission) avant de les envoyer vers les listes d'URL et de fichiers Netskope.

3.1 Vue d'ensemble de l'architecture

Le diagramme ci-dessous montre comment les deux canaux se situent entre le Zero Trust Engine de Netskope et la plate-forme CrowdStrike Falcon. Cloud Exchange est un broker exploité par le client (une machine virtuelle que le client configure et maintient) ; l'application Direct to Zero Trust de Falcon Foundry est une application native hébergée par CrowdStrike qui ne nécessite aucune infrastructure distincte. Les deux écrivent finalement dans les mêmes surfaces de politique Netskope (listes d’URL, listes de hachage de fichiers, classification du périphérique, groupes d’utilisateurs). Chaque flux bidirectionnel est représenté par une paire de flèches côte à côte, et le flux SOAR/XDR en sens inverse (section 4.11) possède son propre chemin le long du bord droit.

3.2 Carte intégration-résultat

Une note sur la terminologie avant ce tableau : les versions actuelles de Cloud Exchange (v4.1.0 et versions ultérieures) utilisent un module Risk Exchange unique et unifié appelé Cloud Risk Exchange, ou CRE, qui ingère les scores de risque des périphériques, des utilisateurs/hôtes, des identités et des applications dans un moteur de risque unique. Cela a remplacé une architecture antérieure où User Risk Exchange (URE) et Application Risk Exchange (ARE) étaient positionnés comme des modules distincts aux côtés d'un Risk Exchange axé sur les périphériques. Cette ancienne séparation explique pourquoi certaines listes de plugins individuels dans le portail de connaissances Netskope portent encore un suffixe URE hérité dans leur nom de produit. Le nom du plugin n’a pas été modifié, même s’il se configure et s’exécute désormais sous le module Risk Exchange (CRE) unique de génération actuelle.

En pratique, cela signifie que les lignes ci-dessous qui alimentent Risk Exchange ne sont pas des alternatives concurrentes parmi lesquelles vous devez choisir. Il s'agit de plugins complémentaires qui contribuent chacun avec un type de score différent (santé du périphérique, risque hôte/utilisateur, risque d'identité) au même moteur CRE. Un déploiement typique en exécute plusieurs simultanément, combinant les scores dans une seule règle métier. Les regroupements ci-dessous organisent le tableau par type de signal apporté par chaque intégration, plutôt que par le nom du module qu'elle porte. Il est ainsi plus clair de comprendre ce que fait chaque ligne et de savoir que vous ne choisissez pas entre des systèmes distincts.

Integration	Type de score contribué	Principaux résultats des politiques	Version du plugin/de l'application	Module
Device Risk — Endpoint Health
Score ZTA CrowdStrike	Santé du périphérique	Reclassement Managé → Non managé ; réduction ou blocage de l'accès en fonction du seuil de score	CRE v1.1.0+	Bourse des risques (CRE)
User and Host Risk
Risque d'hôte CrowdStrike (User Risk Exchange)	Risque utilisateur + périphérique	Déplacer l'utilisateur vers un groupe restreint ; restreindre les téléchargements ; réduire la portée de la session ZTNA (Zero Trust Network Access)	Historiquement étiqueté URE v1.2.0 ; s'exécute sous CRE dans Cloud Exchange actuel	Bourse des risques (CRE)
Falcon Identity Protection	Risque lié à l’identité	Bloquez ou restreignez l'accès pour les utilisateurs dont les identifiants sont compromis ou présentant un comportement d'identité anormal	Historiquement étiqueté URE v1.0.0 (netskope-ce-4.1.0-ure-crowdstrike_identity_protect) ; s'exécute sous CRE dans Cloud Exchange actuel	Bourse des risques (CRE)
Cloud Workload and Vulnerability Risk
Falcon Cloud Security	Risque de charge de travail Cloud (IOA/IOM)	Intégrez les IOA (indicateurs d'attaque) et les IOM (indicateurs de mauvaise configuration) des charges de travail cloud dans la posture de risque de Netskope pour une stratégie compatible CSPM	CRE (GA actuelle — à vérifier dans le Plugin Store)	Bourse des risques (CRE)
Falcon Spotlight	Vulnérabilité du périphérique (CVE)	Le score de vulnérabilité alimente le risque lié au périphérique ; les périphériques avec un CVE élevé bénéficient d'un accès plus restrictif	CRE v1.0.0	Bourse des risques (CRE)
Threat Intelligence (IOC Sharing)
Threat Exchange (partage d'IOC)	N/A — Données d’IOC, pas un score de risque	Bloquez l'accès aux domaines/adresses IP/URL malveillants connus ; mettez en quarantaine ou bloquez les transferts de fichiers malveillants	CTE v2.3.0	Échange de menaces
Application Direct to Zero Trust (Falcon Foundry)	N/A — Données d’IOC, pas un score de risque	Ingestion automatisée des IOC à partir des détections CrowdStrike dans les listes d'URL et de fichiers Netskope	Application native Falcon Foundry (versioning géré par CrowdStrike)	Falcon Foundry (natif)
Incident Response and Visibility
Intégration XDR (SCIM + partage d'alertes)	S/O — synchronisation d’identité + corrélation d’alertes	Réaffectation automatique de groupe lors de la détection ; enrichissement bidirectionnel des incidents	S/O (jeton natif SCIM 2.0 + API REST v2/RBAC v3)	XDR natif + SCIM
LogScale/NG-SIEM (Log Shipper)	S/O — données de journal, pas un score de risque	Centralisez les journaux de transactions web Netskope dans CrowdStrike pour une investigation SOC unifiée	Plugin Log Shipper / streaming S3 natif	Cloud Exchange ou natif
Actions SOAR de Netskope (Falcon Fusion SOAR)	S.O. — déclencheur d’action, direction inverse	Déclenchez des actions Netskope — par ex., ajouter/supprimer un utilisateur d'un groupe restreint, appliquer un paramètre de gouvernance cloud — directement depuis un playbook Falcon Fusion SOAR	Référencement sur la Marketplace CrowdStrike (connecteur développé par CrowdStrike)	Falcon Fusion SOAR (natif)
Actions de réponse Netskope pour Falcon Insight XDR	S.O. — déclencheur d’action, direction inverse	Déclenchez une action de réponse Netskope SSE directement depuis la console Falcon Insight XDR lors d'une détection, sans créer de workflow Fusion complet	Référencement sur la Marketplace CrowdStrike (connecteur développé par CrowdStrike)	Falcon Insight XDR (natif)
Événements Netskope AI SecOps vers Falcon Next-Gen SIEM (webhooks sortants)	S/O — Données d'événement Cases, User Risk et AI Risk, et non un score de risque	Livraison en temps quasi réel des cas AI SecOps, des risques utilisateur et des événements de risque liés à l’IA dans Falcon Next-Gen SIEM (LogScale), pré-analysés vers les champs ECS pour la corrélation et la recherche SOC	Webhook sortant natif Netskope + connecteur d'événements Falcon HEC/HTTP ; package d'analyseur netskope-sse	Natif (webhook) + Falcon Next-Gen SIEM

Les numéros de version des plugins changent fréquemment. Netskope fournit des mises à jour incrémentielles pour chaque plugin Cloud Exchange de manière indépendante. Vérifiez toujours Settings > Plugin Store dans votre propre locataire Cloud Exchange pour connaître la version actuelle avant le déploiement.

Les deux lignes Falcon Fusion SOAR / Insight XDR du dernier groupe circulent dans la direction opposée à toutes les autres lignes de ce tableau : au lieu qu'un signal CrowdStrike alimente la politique Netskope, un analyste ou un workflow automatisé côté CrowdStrike invoque directement une action Netskope. Voir la section 4.11 pour le traitement détaillé.

4. Analyses approfondies de l'intégration

Chaque section ci-dessous explique quel signal l'intégration fournit, comment il entre dans le moteur de politique Netskope, ce qu'il coûte à mettre en place (licences et prérequis) et quels résultats il permet. Chaque section se termine par les exigences de portée API, une référence rapide de dépannage et un pointeur vers le guide d'implémentation complet.

Comme indiqué dans la section 3.2, les sections 4.1 à 4.3 ci-dessous ne constituent pas trois systèmes distincts parmi lesquels choisir. Il s'agit de trois plugins qui alimentent tous le module unique Risk Exchange (CRE) de génération actuelle avec différents types de scores. Un déploiement en production typique exécute les trois simultanément et combine leurs scores dans les règles métier ; les sections sont conservées séparément ici uniquement parce que chacune possède des prérequis, des portées d'API et un comportement de conversion de score distincts qu'il convient de comprendre individuellement.

4.1 Risque lié au périphérique : score ZTA de CrowdStrike via Risk Exchange (CRE)

Le score ZTA (Zero Trust Assessment) de CrowdStrike est une évaluation continue de la santé du périphérique, dérivée des capteurs. Il évalue le niveau de correctif du système d'exploitation, la santé de l'agent de sécurité, l'état du chiffrement du disque, le statut du pare-feu et la présence de menaces actives. Le score natif de CrowdStrike va de 0 à 100 (100 = état le plus sain).

Score scale. Read this before configuring 4.1 and 4.2 together.

La section 4.1 (santé du périphérique) et la section 4.2 (risque hôte/utilisateur) alimentent le même module Risk Exchange (CRE) mais utilisent une logique de conversion différente, bien que toutes deux proviennent des données hôte de CrowdStrike, et cette différence est importante.

• Score de périphérique ZTA (4.1) : score normalisé Netskope Cloud Risk Exchange = score global d'évaluation d'hôte CrowdStrike × 10. Un ZTA CrowdStrike de 76 devient un score Netskope de 760. Les deux échelles fonctionnent dans la même direction : plus le score est élevé, plus l'état est sain/le risque est faible dans les deux systèmes.
• Score de risque hôte/utilisateur, Falcon Identity Protection (4.2 / 4.3) : le score de risque d'Identity Protection de CrowdStrike va de 0 à 1, où 1 représente le risque minimal et 0 le risque maximal sur certaines surfaces CrowdStrike. Toutefois, la documentation de Netskope Cloud Exchange définit l'échelle CrowdStrike entrante comme 0 = risque minimal et 1 = risque maximal pour ce plugin spécifique, ce qui correspond à la convention inverse du score ZTA. La formule de conversion utilisée dans Risk Exchange est :

Score Netskope Cloud Risk Exchange = |(1 − score de risque CrowdStrike Identity Protection)| × 1 000.

• Effet net : ne supposez pas que les scores bruts côté CrowdStrike des deux plugins évoluent dans la même direction simplement parce qu'ils aboutissent dans le même module CRE. Vérifiez toujours la note de conversion propre à chaque plugin dans Cloud Exchange > Plugin Activity avant de définir un seuil de règle métier, et validez avec un hôte de test connu avant d'activer la reclassification automatique en production.

What this adds to Netskope policy

Sans le score ZTA, Netskope peut évaluer le statut de gestion du périphérique (managé vs non managé) et vérifier la présence du certificat Netskope Client. Avec le score ZTA, Netskope obtient une mesure numérique continue de l'état de santé du périphérique qui peut être directement mappée aux niveaux de politique.

• CRE peut appliquer une balise de périphérique dans Netskope sur la base d’une logique booléenne et du score ZTA, qui peut être utilisée dans les correspondances de classification des périphériques au sein d’une politique en ligne pour une approche nuancée du risque lié aux périphériques. Cela permet d’utiliser plusieurs facteurs, dont le score ZTA, pour définir une correspondance.
• Alternativement, un périphérique dont le score ZTA tombe en dessous d'un seuil défini peut être automatiquement reclassé de Managé à Non managé dans Netskope, le faisant passer à un niveau de politique plus restrictif. Lorsque le score se rétablit, le périphérique peut être automatiquement reclassé en tant que Managé, rétablissant ainsi l'accès sans intervention manuelle.
• Les seuils de score correspondent à des niveaux de politique distincts : accès complet au-dessus de 800, lecture seule entre 500 et 800, blocage en dessous de 500, configurables par organisation.

Prerequisites and licensing

• Un locataire Netskope Cloud Exchange avec le plugin Tenant et le plugin Risk Exchange (CRE) déjà configurés.
• Politique de classification des périphériques Netskope configurée pour utiliser une ou plusieurs étiquettes de périphérique créées et appliquées par CRE.
• Un jeton Netskope RBAC v3 (ou SCIM) si la règle métier associée doit également réécrire vers une règle de classification des périphériques Netskope via le plugin Netskope CRE.
• Identifiants d'instance CrowdStrike (Client ID, Client Secret) générés à partir d'un API Client.
• Si vous utilisez le script Put RTR, le rôle d'administrateur CrowdStrike Real-Time Response (RTR) est requis. Chaque plateforme ciblée (Windows, Mac) nécessite une politique de réponse avec Real-Time Response (commandes à haut risque) activée. Cependant, nous recommandons la méthode de marquage de périphérique plutôt que le script RTR.

API scopes/setup path

• CrowdStrike : Support and Resources > API Clients and Keys > Create API Client, avec au minimum les portées Zero Trust Assessment (lecture) et Hosts (lecture) ; ajoutez Real Time Response (lecture/écriture) si vous utilisez des actions RTR.
• Cloud Exchange : Paramètres > Magasin de plugins > CrowdStrike v1.1.0 (CRE) ou version ultérieure > saisissez l'ID/le secret du client et l'URL de base.
• Compte de service Netskope : Paramètres > Gérer > Classification du périphérique > New règle de classification du périphérique, mise en correspondance avec le fichier/l'étiquette écrit(e) par le plugin. New Roles > Client NS > Périphériques, Classification du périphérique

Troubleshooting quick reference

• Erreur 403 lors de la configuration du plugin : vérifiez que le Client ID/Secret est correct et dispose des portées ci-dessus ; confirmez que l’adresse IP publique de Cloud Exchange figure sur la page de gestion de la liste d’autorisation IP de CrowdStrike, si une telle liste est configurée.
• Aucun hôte récupéré : confirmez que les hôtes existent réellement sous Host Setup and Management du côté de CrowdStrike, et que le champ Host ID est mappé dans la configuration d'entité du plugin.
• Scores manquants pour certains hôtes : vérifiez le paramètre de configuration Score maximum du plugin — le plugin n'extrait que les hôtes dont le score est ≤ à cette valeur — et confirmez que overallAssessmentScore est mappé.
• Erreur 500 : problème transitoire de l'API CrowdStrike ; réessayez après une courte attente.

→ Implementation guide (Risk Exchange plugin, v1.1.0): Plugin CrowdStrike pour Risk Exchange

→ Implementation guide (v1.0.0, superseded): Plugin CrowdStrike pour User Risk Exchange

→ Community walkthrough: Netskope Cloud Risk Exchange et CrowdStrike ZTA

Une alternative « faites-le vous-même » qui mérite d'être connue : le plugin Risk Exchange (CRE) ci-dessus n'est pas le seul moyen de transformer un score ZTA en une action de politique Netskope. La section 4.11.3 documente un modèle personnalisé qui ignore complètement Cloud Exchange et produit le même résultat, la hiérarchisation des risques des périphériques, via un workflow Falcon Fusion SOAR créé manuellement qui appelle directement l'API REST Device Tags de Netskope.

4.2 Risque utilisateur et hôte : Risque hôte CrowdStrike via Risk Exchange (CRE)

Ce plugin collecte les scores de risque au niveau de l'hôte depuis la plate-forme CrowdStrike et les mappe aux scores de risque utilisateur de Netskope sous le même module Risk Exchange (CRE) que la section 4.1 (voir la note sur l'échelle de score à cet endroit avant de configurer ce plugin avec le plugin ZTA). Dans le portail de connaissances Netskope, la liste des produits de ce plugin porte toujours l’ancien nom « User Risk Exchange (URE) » — un vestige de dénomination datant d’avant que Cloud Exchange ne consolide User Risk Exchange et Application Risk Exchange dans le module unique CRE. Il ne s’agit pas d’un système distinct de la version 4.1 ; c’est un plugin différent qui alimente le même moteur de risque avec un type de score différent (risque hôte/utilisateur plutôt que santé du périphérique).

What this adds to Netskope policy

• Les utilisateurs ayant des scores de risque hôte élevés sont automatiquement déplacés vers un groupe à accès restreint dans Netskope.
• Les politiques s'appliquant à ce groupe peuvent restreindre les téléchargements, bloquer l'accès aux applications sensibles ou réduire la portée de la session ZTNA.
• À mesure que le score de risque de l'hôte diminue, l'utilisateur peut être automatiquement replacé dans le groupe standard.

Prerequisites and licensing

• Locataire Netskope Cloud Exchange avec le plugin Tenant et le plugin Risk Exchange (CRE) déjà configurés.
• Une licence Advanced UEBA (User and Entity Behavior Analytics) est généralement requise sur le locataire Netskope pour générer les scores de risque des utilisateurs que Risk Exchange récupère et partage. Confirmez la portée actuelle de la licence avec votre équipe de compte Netskope, car les offres changent avec le temps.
• Identifiants du client API CrowdStrike (ID client/Secret).

API scopes/setup path

• CrowdStrike : client API avec les portées Hosts (lecture) et Zero Trust Assessment (lecture) (ce plugin réutilise le même point de terminaison d'évaluation d'hôte que le plugin ZTA dans la version 4.1, converti différemment comme indiqué à cet endroit).
• Cloud Exchange : Settings > Plugins > recherchez le plugin de risque d'hôte CrowdStrike (listé comme v1.2.0, historiquement étiqueté « (URE) ») > saisissez les identifiants > configurez les règles métier (Business Rules) mappant les plages de scores aux groupes d'utilisateurs Netskope.

Troubleshooting quick reference

• Le score semble inversé par rapport aux attentes : il s’agit presque toujours du cas 4.1 contre 4.2 problème de direction de mise à l’échelle. Vérifiez à nouveau la formule de conversion documentée du plugin plutôt que de supposer une parité avec le plugin ZTA.
• Utilisateurs ne changeant pas de groupe : confirmez que le jeton SCIM (System for Cross-domain Identity Management) ou REST API v2 utilisé par le plugin Netskope CRE dispose d'un accès en écriture aux groupes Netskope, et que la condition de correspondance de la règle métier est évaluée par rapport au champ de score mappé.

→ Implementation guide: Plugin CrowdStrike pour User Risk Exchange

4.3 Risque lié à l'identité : Falcon Identity Protection via Risk Exchange (CRE)

CrowdStrike Falcon Identity Protection détecte les attaques basées sur les identifiants : pulvérisation de mots de passe (password spray), abus de ticket golden, mouvement latéral et modèles d'authentification anormaux. Il attribue à chaque utilisateur un score de risque d'identité basé sur ces données de détection, distinct du score basé sur l'hôte mentionné en 4.2, un troisième type de score complémentaire alimentant le même module Risk Exchange (CRE) décrit en 4.1 et 4.2.

What this adds to Netskope policy

• Un utilisateur ayant un score de risque d'identité élevé mais un périphérique sain peut être soumis à une authentification renforcée avant d'accéder à des applications sensibles.
• Un utilisateur présentant à la fois un risque d’identité élevé et un risque d’hôte élevé peut être totalement bloqué de l’accès aux données sensibles.
• Le risque lié à l'identité peut être utilisé pour appliquer des politiques d'accès juste-à-temps pour les charges de travail cloud privilégiées.

Prerequisites and licensing

• Licence du module CrowdStrike Falcon Identity Protection (distincte de la licence de base des terminaux Falcon).
• Locataire Netskope Cloud Exchange avec le plugin Tenant et le plugin Risk Exchange (CRE) déjà configurés.
• Identifiants de l’instance CrowdStrike : URI de base, ID client, Secret client. L'URI de base correcte dépend de votre région cloud CrowdStrike : commercial (api.crowdstrike.com), US-2 (api.us-2.crowdstrike.com), UE (api.eu-1.crowdstrike.com), ou GovCloud (api.laggar.gcw.crowdstrike.com).

API scopes/setup path

• CrowdStrike : Support and Resources > API Clients and Keys > Add New API Client, avec les champs d'application Identity Protection requis par le plugin (confirmez les noms exacts des champs d'application dans le guide lié, car CrowdStrike a renommé les champs d'application d'identité au fil des versions).
• Cloud Exchange : recherchez le plugin CrowdStrike Falcon Identity Protection dans le Plugin Store (historiquement packagé sous le nom netskope-ce-4.1.0-ure-crowdstrike_identity_protect-v1.0.0 ; s'exécute sous le module CRE actuel quel que soit le nom du package).

Score conversion (see also 4.1)

Échelle de score de risque Netskope : 0–1000, où 0 = risque maximal et 1000 = risque minimal. Échelle de score de risque CrowdStrike Identity Protection : 0–1, où 0 = risque minimal et 1 = risque maximal pour la convention de ce plugin. Formule : score Netskope = |(1 − score CrowdStrike)| × 1000. Le score normalisé que vous voyez dans Netskope Cloud Risk Exchange ne correspondra pas numériquement à ce qui est affiché dans la console CrowdStrike Identity Protection. Ceci est attendu.

Troubleshooting quick reference

• Aucun score utilisateur récupéré : confirmez que les utilisateurs existent et sont désarchivés dans CrowdStrike Identity Protection > Utilisateurs ; seuls les utilisateurs non archivés sont récupérés.
• Utilisateurs ignorés silencieusement : vérifiez si le champ emailAddresses de la réponse de l’API est vide ou contient plusieurs adresses. Ces deux cas sont actuellement ignorés par le plugin plutôt que mappés.
• Autorisations insuffisantes : vérifiez à nouveau que les portées (scopes) de l'API Client correspondent exactement à la section Permissions documentée du plugin.

→ Implementation guide: Plugin CrowdStrike Falcon Identity Protection pour User Risk Exchange 

4.4 Renseignements sur les menaces : Plugin CrowdStrike pour Threat Exchange

Le plugin CrowdStrike Threat Exchange permet un partage bidirectionnel des IOC entre les deux plateformes. CrowdStrike partage des indicateurs de domaine, IPv4, MD5 et SHA-256 avec Netskope ; Netskope renvoie des données d’alerte sur les sites malveillants et les malwares à CrowdStrike. Contrairement aux sections 4.1 à 4.3, ce plugin n’alimente pas du tout Risk Exchange (CRE) ; il appartient à un module Cloud Exchange distinct, Threat Exchange, qui partage des données d’indicateurs plutôt que des scores de risque.

What this adds to Netskope policy

• Les IOC de domaine et IPv4 de CrowdStrike alimentent les listes d'URL de Netskope, sur lesquelles les politiques de protection en temps réel agissent immédiatement.
• Les hachages de fichiers MD5 et SHA-256 de CrowdStrike alimentent les listes de hachages de fichiers Netskope, permettant le blocage ou la mise en quarantaine des transferts de fichiers malveillants connus.
• Les alertes de Netskope concernant les sites malveillants et les malwares sont renvoyées à CrowdStrike, fournissant au SOC (Security Operations Center) un contexte de menace au niveau du cloud, parallèlement à la télémétrie des terminaux.

Prerequisites and licensing

• Locataire Netskope Cloud Exchange avec le plugin Tenant et le plugin Risk Exchange (CRE) déjà configurés.
• Pour une fonctionnalité bidirectionnelle complète (récupération des IOC générés par Netskope et renvoi des IOC externes pour application), des jetons API pour les API REST Netskope v1 et v2 sont généralement requis. Confirmez les exigences actuelles par rapport au guide lié, car Netskope migre progressivement ses surfaces d'API vers v2/RBAC v3.
• Une licence Netskope Advanced Threat Protection ainsi que la fonctionnalité Retrohunt API Query activée par l'équipe de la plateforme Netskope, si vous utilisez la correspondance rétroactive basée sur Retrohunt.

API scopes/setup path

• CrowdStrike : Support et ressources > Client API et clés > Créer un client API. À partir du plugin v2.3.0, CrowdStrike passe de l’API Detect à l’API Alerts. Appliquez la portée Detections (read) avant la mise à niveau, puis supprimez-la une fois la mise à niveau vers la v2.3.0 terminée, conformément à l’avis de dépréciation de CrowdStrike.
• Si une liste d'autorisation IP CrowdStrike est configurée, ajoutez l'adresse IP publique de Cloud Exchange sous Host Setup and Management > Falcon Users > IP Allowlist Management.

Version and scale notes

• Version actuelle du plugin documentée : CTE v2.3.0.
• CrowdStrike ne prend en charge le partage que jusqu'à 1 000 000 d'IOC vers la page de gestion des IoC ; une fois ce plafond atteint, aucun autre IOC n'est partagé tant que les IOC existants ne sont pas effacés.
• Seuls les IOC de hachage de fichier déclenchent activement la prévention dans CrowdStrike ; les IOC de domaine, IPv4 et IPv6 sont stockés pour le contexte de détection/investigation, mais ne bloquent pas eux-mêmes le trafic côté CrowdStrike.

Troubleshooting quick reference

• Erreur 403 : confirmez la validité de l'ID/Secret client, confirmez les portées requises et confirmez l'entrée de la liste d'autorisation IP ci-dessus.
• Erreur lors de la mise à niveau depuis une ancienne version du plugin : mettez à jour les autorisations de l'ID/Secret du client avant la mise à niveau (voir la note sur l'API Detect-to-Alerts ci-dessus), puis supprimez la portée Detections désormais inutile.
• Erreur 401 lors de l'activation de Retrohunt : il s'agit généralement d'un prérequis manquant au niveau du tenant, et non d'une portée API incorrecte. Confirmez que la fonctionnalité Retrohunt API Query est activée par Netskope, confirmez qu'une licence Advanced Threat Protection est active et confirmez que le jeton utilisé est RBAC v3 avec les autorisations Malware sous la portée Threat Protection.
• Les IoC dont les champs de type/valeur sont manquants du côté de CrowdStrike sont ignorés silencieusement lors de l'extraction. Il s'agit d'un comportement attendu du plugin, et non d'un état d'erreur.

→ Implementation guide: Plugin CrowdStrike pour Threat Exchange

→ Cloud Exchange FAQs (Detect→Alerts API transition, Retrohunt, file hash 8MB limit): FAQ sur Cloud Exchange

4.5 Threat Intelligence : Application Netskope Direct to Zero Trust (Falcon Foundry)

L’application Direct to Zero Trust est une application native CrowdStrike Falcon Foundry qui offre une alternative plus automatisée et évolutive au plugin Threat Exchange de Cloud Exchange pour la gestion des IOC. Il extrait les IOC des détections CrowdStrike, les normalise et les déduplique, puis les envoie directement aux listes d’URL et de fichiers Netskope via l’API Netskope.

What this adds to Netskope policy

• Les IOC de domaine et IPv4 issus des détections Falcon sont extraits et envoyés automatiquement vers la liste d'URL Netskope.
• Les hachages MD5 et SHA-256 issus des détections de malwares Falcon mettent à jour la liste des hachages de fichiers Netskope en temps quasi réel.
• Les alertes de sites malveillants et de malwares de Netskope sont réintégrées dans Falcon Foundry, complétant ainsi la boucle de Threat Intelligence.

Prerequisites and licensing

• Droit CrowdStrike Falcon Foundry (une capacité distincte de la licence standard Falcon endpoint). Confirmez avec votre équipe de compte CrowdStrike).
• Identifiants d'API Netskope avec autorisation d'écriture dans les listes d'URL et les listes de hachage de fichiers.
• Aucun serveur Cloud Exchange n’est requis pour ce chemin, car Falcon Foundry héberge l’automatisation de manière native.

→ Implementation guide (Community): Netskope Direct to Zero Trust App

4.5.1 Choisir entre les deux méthodes de partage d'IOC

Consideration	Plugin Threat Exchange (4,4, Cloud Exchange)	Application Direct to Zero Trust (4.5, Falcon Foundry)
Infrastructure	Nécessite un serveur Cloud Exchange auto-hébergé (VM) que le client exploite et corrige	Application native hébergée par CrowdStrike ; aucune infrastructure séparée nécessaire pour l'exécution
Directionality	Bidirectionnel réel : extrait les IOC CrowdStrike vers Netskope et renvoie les alertes de sites malveillants/malwares détectés par Netskope vers CrowdStrike	Automatisation principalement unidirectionnelle : extrait les IOC CrowdStrike et les transmet à Netskope ; les alertes Netskope sont réintégrées dans Foundry, mais avec moins de flexibilité de workflow qu'une règle métier Cloud Exchange
Actions sur les hôtes	Prend en charge les actions hôte d'isolation/remédiation et la rétraction d'IOC (pull et push) en tant que fonctionnalités de plugin de premier ordre	Axé sur la normalisation/déduplication des IOC et l'automatisation de l'envoi de listes ; il ne s'agit pas d'un framework général d'action sur les hôtes
Latency	Régie par l'intervalle de synchronisation configuré du plugin (interrogation planifiée)	Conçu pour envoyer un IOC nouvellement détecté à Netskope quelques minutes après sa détection — une latence réduite par conception
Customization	Élevé — Les règles de gestion de Cloud Exchange permettent un filtrage, un étiquetage et une corrélation multi-plugin arbitraires avant qu'un IOC ne soit partagé	Inférieur — la logique réside dans l'application Foundry ; moins exposé pour le filtrage personnalisé
Solution idéale	Organisations exploitant déjà Cloud Exchange pour d'autres plugins (Risk Exchange, Log Shipper), ou ayant besoin d'actions de rétractation/isolement-remédiation et d'un contrôle granulaire des règles de gestion	Organisations souhaitant le flux d'IOC automatisé le plus rapide et le plus simple sans avoir à mettre en place ou à maintenir une infrastructure Cloud Exchange

L'exécution des deux sur les mêmes listes d'URL/fichiers Netskope est prise en charge, mais doit être testée pour la gestion des entrées en double avant le déploiement en production.

4.6 Extended Detection and Response : Intégration CrowdStrike XDR

L'intégration CrowdStrike XDR connecte le SSE (Security Service Edge) de Netskope à la plateforme Falcon XDR pour offrir une vue unique des menaces se déplaçant à travers les périphériques, les réseaux et le cloud. Il combine deux mécanismes : la synchronisation des utilisateurs et des groupes basée sur SCIM, et le partage bidirectionnel des alertes de menace.

SCIM-based user and group management

• Ajoutez un utilisateur à un groupe « restreint » dans CrowdStrike → les politiques Netskope pour ce groupe s’appliquent immédiatement.
• Supprimez un utilisateur du groupe lorsque l'incident est résolu → l'accès complet est automatiquement rétabli.
• Les New utilisateurs ajoutés à CrowdStrike sont automatiquement provisionnés dans Netskope avec l'appartenance au groupe correcte.

Bidirectional alert sharing

CrowdStrike XDR ingère les données de transaction web et d'alerte de Netskope, en les combinant avec la télémétrie des terminaux pour faire ressortir les menaces qui couvrent les deux couches. Un utilisateur exfiltrant des données via une application cloud sur un terminal que CrowdStrike considère comme déjà compromis constitue un incident très différent de chaque signal pris isolément.

Prerequisites and licensing

• Intégration SCIM (System for Cross-domain Identity Management) de Netskope configurée et accessible. Veuillez noter que l’ancienne méthode Directory Tool + jeton OAuth pour Netskope SCIM a été obsolète. La recommandation actuelle est d’utiliser un jeton RBAC v3 de Netskope généré via un compte de service (Paramètres > Outils > API REST v3), ou un jeton d’API REST v2, selon le flux requis par le guide d’intégration spécifique.
• Licence du module CrowdStrike Falcon XDR.
• Accès administratif aux deux locataires pour configurer la relation de confiance initiale.

Setup path (high level)

• Configuration de l'authentification : générez le jeton Netskope (RBAC v3 via un compte de service, ou API REST v2 conformément aux instructions actuelles du guide lié).
• Configuration de l'annuaire/SCIM : configurez le mappage des canaux des attributs utilisateur et groupe entre CrowdStrike et Netskope.
• Configuration du partage d'alertes : connectez Falcon XDR aux sources de journaux/alertes Netskope SSE conformément au guide d'intégration tiers.

Troubleshooting quick reference

• La synchronisation SCIM ne reflète pas les changements de groupe : confirmez que le jeton utilisé n’a pas expiré et possède toujours les portées accordées lors de la configuration — les jetons RBAC v3 et les anciens jetons OAuth ne sont pas interchangeables, et les mélanger est une source courante d’échecs de synchronisation silencieux après une migration.
• Erreurs de provisionnement à grande échelle (création en masse d'utilisateurs/groupes) : l'API SCIM de Netskope utilise la pagination ; lors de la création de scripts pour des opérations en masse, parcourez les pages à l'aide des paramètres startIndex et count plutôt que de supposer qu'un seul appel renvoie l'ensemble complet.

→ Implementation guide — XDR integration: Intégration CrowdStrike XDR

→ Third-party integration guide — Netskope SSE: Intégration tierce CrowdStrike XDR : Netskope SSE

→ Netskope SCIM / RBAC v3 provisioning guide: Approvisionnement et authentification des utilisateurs

4.7 Risque de charge de travail cloud : plugin Falcon Cloud Security pour Risk Exchange (CRE)

Le plugin Falcon Cloud Security récupère deux catégories de données cloud CrowdStrike et les intègre à la posture de risque de Netskope via le même module Risk Exchange (CRE) utilisé dans les sections 4.1 à 4.3 : IOA (indicateurs d'attaque) cloud, preuves de techniques d'attaquants actives sur les charges de travail cloud, et IOM (indicateurs de mauvaise configuration) qui signalent les erreurs de configuration des ressources cloud augmentant la surface d'attaque.

What this adds to Netskope policy

• Les IOA provenant de charges de travail activement compromises peuvent déclencher une inspection accrue ou bloquer le trafic Netskope vers ces charges de travail.
• Les données IOM alimentent un signal de risque capable de restreindre l’accès aux ressources cloud mal configurées jusqu’à ce que la configuration soit corrigée.
• L'automatisation des politiques NPA (Netskope Private Access) peut déplacer automatiquement la définition d'application d'une charge de travail à risque vers un objet à accès restreint.

Prerequisites and licensing

• Licence du module CrowdStrike Falcon Cloud Security (CSPM — Cloud Security Posture Management).
• Locataire Netskope Cloud Exchange avec le plugin Tenant et le plugin Risk Exchange (CRE) déjà configurés.
• Identifiants du client API CrowdStrike limités aux données de sécurité cloud (confirmez les noms exacts des portées dans le guide actuel du plugin, car la dénomination des portées de Falcon Cloud Security a changé au fil des versions de la plateforme CrowdStrike).

Troubleshooting quick reference

• Suivez le même modèle de liste d'autorisation 403/IP documenté pour les autres plugins Risk Exchange dans la section 4.1 : vérifiez d'abord les étendues (scopes) de l'ID client/secret, puis vérifiez la gestion de la liste d'autorisation IP si elle est configurée.

→ Implementation guide: Plugin CrowdStrike Cloud Security pour Risk Exchange

4.8 Contexte de vulnérabilité : Plugin Falcon Spotlight pour Risk Exchange (CRE)

Falcon Spotlight fournit une gestion continue des vulnérabilités au niveau de la couche terminal. Le plugin Spotlight transmet les scores de vulnérabilité des hôtes gérés dans le contexte de risque des périphériques de Netskope via Risk Exchange (CRE), enrichissant la dimension périphérique du Zero Trust Engine avec des données d'exposition réelles aux CVE (Common Vulnerabilities and Exposures).

What this adds to Netskope policy

Les périphériques présentant des CVE critiques non corrigées peuvent être automatiquement rétrogradés, ce qui restreint l'accès aux données sensibles jusqu'à ce que la vulnérabilité soit corrigée.

Prerequisites and licensing

• Licence du module CrowdStrike Falcon Spotlight.
• Locataire Netskope Cloud Exchange avec le plugin Tenant et le plugin Risk Exchange (CRE) déjà configurés.
• Client API CrowdStrike avec portée Vulnerabilities (read). Il s'agit de l'autorisation spécifique nécessaire pour extraire les enregistrements des utilisateurs et des applications pour ce plugin.

API scopes/setup path

• CrowdStrike : Support et ressources > Clients et clés API > Ajouter un New client API avec la portée Vulnerabilities (read).
• Cloud Exchange : plugin CrowdStrike Falcon Spotlight v1.0.0 (CRE) ; l'URL de base est l'hôte API CrowdStrike spécifique à la région (comme https://api.crowdstrike.com) ; La plage initiale (en jours) contrôle la quantité de données historiques extraites lors de la première synchronisation et doit être comprise entre 0 et 200 jours.

Troubleshooting quick reference

• Aucune vulnérabilité récupérée : confirmez que les vulnérabilités existent réellement du côté de Falcon Spotlight pour le tenant, et confirmez que le mappage entité-source a été effectué lors de la configuration du plugin.
• Erreur 403 : vérifiez la validité de l’ID/Secret client et spécifiquement la portée Vulnerabilities (read), puis vérifiez la gestion de la liste d’autorisation IP si elle est configurée du côté de CrowdStrike.
• Erreur 500 : problème transitoire côté serveur ; patientez et réessayez.

→ Implementation guide: CrowdStrike Falcon Spotlight Plugin pour Risk Exchange

4.9 Visibilité centralisée : LogScale et NG-SIEM

Il existe deux voies d'intégration pour envoyer les données Netskope vers la couche SIEM de CrowdStrike : le plugin CrowdStrike LogScale pour le module Log Shipper de Netskope Cloud Exchange, et l'intégration tierce CrowdStrike NG-SIEM (SIEM de nouvelle génération) utilisant le streaming de journaux natif de Netskope vers un bucket AWS S3 que Falcon ingère.

Ce que cela ajoute

Ces intégrations ne pilotent pas directement les décisions de politique en ligne de Netskope. Leur valeur réside dans la vitesse d’enquête et la précision de détection. Lorsqu'un analyste CrowdStrike enquête sur un incident de point de terminaison, il peut visualiser l'activité complète de l'utilisateur sur les applications cloud au sein de la même console Falcon, ce qui peut faire apparaître des indicateurs antérieurs permettant d'affiner les politiques futures.

Prerequisites

• Pour LogScale via Cloud Exchange : plugins Tenant et Log Shipper configurés, ainsi que les identifiants d'ingestion CrowdStrike LogScale.
• Pour le streaming NG-SIEM natif basé sur S3 : un compartiment AWS S3 accessible à la fois à la configuration de streaming de logs de Netskope et à l'ingestion NG-SIEM de CrowdStrike, avec les autorisations IAM appropriées des deux côtés.

→ LogScale plugin guide: CrowdStrike LogScale Plugin pour Log Shipper

→ NG-SIEM third-party integration guide: CrowdStrike Next-Gen SIEM Intégration de tiers 

→ Log streaming setup: Flux de logs vers CrowdStrike

Événements Netskope AI SecOps vers Falcon Next-Gen SIEM (webhooks sortants)

Un chemin distinct et plus récent que celui des intégrations d'envoi de journaux ci-dessus. Plutôt que de diffuser des journaux de transactions web généraux, cette intégration transmet les événements Netskope AI SecOps Cases, User Risk et AI Risk directement dans Falcon Next-Gen SIEM (LogScale) en temps quasi réel, en utilisant un webhook sortant Netskope d'un côté, et un Falcon HEC (HTTP Event Collector) / connecteur d'événements HTTP de l'autre. Les événements arrivent déjà analysés. Le package d'analyse netskope-sse (le même package qui normalise les autres flux d'alertes et d'événements SSE de Netskope) reconnaît la forme de l'enveloppe AI SecOps et promeut automatiquement les champs vers ECS (Elastic Common Schema) lors de l'ingestion, il n'y a donc aucun analyseur de temps de requête distinct à créer.

Prerequisites

• Un locataire Netskope avec AI SecOps activé et un accès administrateur pour configurer les webhooks sortants (AI SecOps > Configuration > Integrations).
• Un tenant CrowdStrike Falcon Next-Gen SIEM avec l'autorisation de créer des connecteurs de données.
• Le package d'analyseur netskope-sse disponible dans le référentiel Falcon NG-SIEM, installé à partir du registre de packages CrowdStrike-Partners.

Setup path (high level)

• Dans Falcon Next-Gen SIEM, créez un HEC/HTTP Event Connector (fournisseur : Generic) **New**, sélectionnez l'analyseur netskope-sse et activez éventuellement l'enrichissement hôte/utilisateur par rapport aux données d'actifs et d'identité propres à Falcon.
• Générez la clé API du connecteur et copiez son URL API. Ils deviennent le jeton d’authentification (bearer token) et l’URL de destination du webhook (avec /raw ajouté, comme …/services/collector/raw) du côté de Netskope.
• Dans Netskope AI SecOps, créez un New webhook sortant : définissez l'URL de destination et le jeton porteur (bearer token) de l'étape précédente, sélectionnez les types d'événements à transmettre (Cases, User Risk et AI Risk peuvent tous partager un seul webhook — 16 types d'événements sont normalisés vers un ensemble de champs ECS cohérent), et choisissez Envelope (enveloppe signée) comme mode d'encapsulation.
• Envoyez un événement de test réel (comme case.created) et confirmez qu'il arrive dans le référentiel Falcon avec les champs analysés — event.action, event.category[0], event.severity, organization.id, rule.id, url., user.name — parallèlement à la charge utile brute complète conservée sous Vendor.data.

Data structure notes

• La sévérité mappe les niveaux critique/élevé/moyen/faible/informationnel aux scores numériques 90/70/50/30/10 dans event.severity.
• event.kind, event.category, et event.type varient selon le type d'événement. Les champs non présents sur un type d'événement donné sont simplement absents.
• L'onglet Payload contrôle quels groupes de champs optionnels (métadonnées de cas, enquête, entités, lignée de fichiers, détails de risque) sont inclus au-delà de Core. Certains comportent des marqueurs d'IIP, activez donc les groupes conformément à votre politique de traitement des données.

Troubleshooting quick reference

• Erreur 401 ou 403 lors de l'ingestion : régénérez la clé API sur le connecteur Falcon et mettez à jour le champ Jeton (Token) du webhook.
• Les événements arrivent non analysés (uniquement @rawstring) : confirmez que le champ Parsers du connecteur est défini sur netskope-sse.
• @rawstring est vide : l'URL de destination manque de son suffixe /raw.

→ Implementation guide (Community): Envoi des événements Netskope AI SecOps vers CrowdStrike Falcon Next-Gen SIEM

4.10 Coexistence des points de terminaison : interopérabilité au niveau du client

Il ne s'agit pas d'une intégration de partage de données, mais d'une intégration opérationnelle : les deux agents s'exécutent sur le même périphérique, et chacun peut interférer avec l'autre s'il n'est pas configuré correctement.

• CrowdStrike injecte des DLL dans le processus Netskope Client pour surveiller l'activité au niveau de l'API, ce qui peut occasionnellement provoquer une instabilité.
• Atténuation recommandée : ajoutez des exclusions de processus Netskope Client du côté de CrowdStrike, et ajoutez une exception d'application à certificat épinglé dans la configuration de pilotage de Netskope (Paramètres > Plateforme de sécurité cloud > Configuration de pilotage > Configuration par défaut du tenant > Exception > New Exception > Applications à certificat épinglé) afin que le trafic CrowdStrike contourne l'inspection Netskope.

Troubleshooting/validation

Pour valider le fonctionnement du capteur CrowdStrike Falcon après l'application d'exceptions, exécutez un test de détection bénin (choice /M crowdstrike_sample_detection depuis une invite de commande Windows) et confirmez que la détection apparaît dans la console Falcon sous Activity > Detections.

→ Coexistence best-practices guide: CrowdStrike

4.11 Automatisation en sens inverse : déclenchement d’actions Netskope depuis CrowdStrike

Chaque intégration des sections 4.1 à 4.9 circule dans une seule direction : un signal dérivé de CrowdStrike (santé du périphérique, risque d’identité, IOC, score de vulnérabilité, journal) alimente le Netskope Zero Trust Engine, qui décide ensuite du résultat de la politique. Deux listes du CrowdStrike Marketplace fonctionnent dans l’autre sens ; elles permettent à une console ou à un playbook côté CrowdStrike d’invoquer directement une action Netskope. Cela boucle la boucle pour les équipes SOC qui effectuent le triage dans Falcon et souhaitent agir dans Netskope sans changer de console.

4.11.1 Actions Netskope SOAR (Falcon Fusion SOAR)

Un connecteur conçu par CrowdStrike pour Falcon Fusion, le générateur de workflow SOAR (Security Orchestration, Automation, and Response) sans code de CrowdStrike. Il expose les actions Netskope — telles que l’ajout ou la suppression d’un utilisateur d’un groupe restreint, ou l’application d’un paramètre de gouvernance cloud — en tant qu’étapes dans un playbook Fusion, afin qu’un workflow de réponse entièrement automatisé puisse couvrir les deux plateformes sans intervention humaine sur la console Netskope.

• Gestion automatisée des accès utilisateur : contrôlez l'accès au cloud en gérant automatiquement les rôles et les groupes d'utilisateurs au sein d'un workflow Fusion.
• Gouvernance Cloud simplifiée : appliquez les politiques de conformité et les paramètres de sécurité Cloud en tant qu'étape de workflow, et non comme une tâche manuelle.
• Réponse aux incidents accélérée : un workflow Fusion peut surveiller les signaux d'activité cloud et déclencher immédiatement une action de remédiation Netskope, de bout en bout, au sein de CrowdStrike.

Prerequisites and licensing

• CrowdStrike Falcon Next-Gen SIEM (Falcon Fusion SOAR est fourni dans le cadre de ce module).
• Identifiants API côté Netskope avec autorisation de modifier l'appartenance aux utilisateurs/groupes et les paramètres de gouvernance pertinents que le workflow affectera.

Setup path

• Depuis la console CrowdStrike Falcon, accédez à la liste du Marketplace CrowdStrike pour les actions Netskope SOAR et sélectionnez Get Started/Contact Partner pour commencer la configuration du connecteur, puis créez ou étendez un workflow Falcon Fusion en utilisant les actions Netskope exposées comme étapes de workflow.

How this differs from Section 4.6’s SCIM Sync

La section 4.6 maintient l'appartenance au groupe Netskope continuellement synchronisée avec CrowdStrike via SCIM (System for Cross-domain Identity Management), une relation permanente et toujours active. Cette intégration est pilotée par des playbooks et conditionnelle : elle n'agit que lorsqu'un workflow Fusion l'appelle explicitement, et elle peut effectuer une gamme plus large d'actions ponctuelles au-delà de l'appartenance au groupe, au prix de devoir faire concevoir les conditions de déclenchement par un auteur de workflow plutôt que de s'appuyer sur une synchronisation continue.

→ Marketplace listing: Actions SOAR de Netskope

→ Solution guide (shared with other Netskope/CrowdStrike listings): Ce guide de solution

4.11.2 Actions de réponse Netskope pour Falcon Insight XDR

Un équivalent plus restreint, spécifique à l'XDR, du connecteur SOAR Actions ci-dessus. Plutôt que de devoir créer un workflow Fusion, les clients de Falcon Insight XDR peuvent déclencher une action de réponse Netskope SSE (Security Service Edge) directement depuis la console Insight XDR. Par exemple : en réponse à une détection spécifique ou à une alerte d'activité suspecte, avec moins de frais de configuration que la création d'un workflow complet.

• Automatisez la réponse et simplifiez les opérations : actions automatisées cohérentes et reproductibles (comme l'ajout/la suppression d'un utilisateur d'un groupe restreint) déclenchées par les détections XDR.
• Réponse inter-domaine plus rapide : les analystes Falcon Insight XDR peuvent invoquer une action Netskope instantanément, depuis la même console où ils trient déjà la détection, sans avoir à changer de contexte vers Netskope ou à créer un workflow Fusion au préalable.

Prerequisites and licensing

• Modules CrowdStrike Falcon Insight XDR et Falcon Prevent.
• Identifiants API côté Netskope limités aux actions de réponse spécifiques activées (généralement les changements d’appartenance à un groupe ou à un rôle).

Setup path

Configurez directement depuis l'entrée du CrowdStrike Falcon Store pour cette liste (accessible depuis la console Falcon), ce qui relie les deux plates-formes sans déploiement séparé de Cloud Exchange.

Choosing between 4.11.1 and 4.11.2

Si votre SOC crée déjà des playbooks Fusion SOAR et souhaite utiliser les actions Netskope comme une étape parmi d’autres dans une chaîne de réponse automatisée plus large, utilisez les actions SOAR (4.11.1). Si votre priorité est une méthode rapide et facile à configurer permettant aux analystes XDR de déclencher une action Netskope directement à partir d'une détection lors du triage, utilisez Response Actions pour Falcon Insight XDR (4.11.2). Les deux ne sont pas mutuellement exclusifs. Certaines organisations exposent les mêmes actions Netskope sous-jacentes via les deux surfaces pour différentes personnes (ingénieurs SOC qui créent des automatisations vs analystes qui effectuent le triage sur le moment).

→ Marketplace listing: Actions de réponse Netskope pour Falcon Insight XDR 

4.11.3 Modèle Field-Built : Fusion SOAR + API Netskope Device Tags (aucun connecteur Marketplace requis)

Une alternative au connecteur de la marketplace Netskope SOAR Actions dans la section 4.11.1 : plutôt que d'installer un connecteur packagé, ce modèle construit l'intégration directement en utilisant deux primitives natives — l'action Cloud HTTP Request intégrée de Falcon Fusion SOAR et l'API REST Device Tags de Netskope — avec toute la logique de déclenchement vers la politique visible dans un seul workflow visuel, sans déploiement d'application Foundry ou de Cloud Exchange requis.

How it works

• Le workflow se déclenche sur l'événement Zero Trust Assessment > Host assessment change > Overall assessment de CrowdStrike, activé chaque fois que le score ZTA global d'un hôte change.
• Trois conditions enchaînées acheminent le périphérique vers l'un des trois niveaux (Fusion SOAR ne disposant pas de branchement multidirectionnel natif, il s'agit de deux conditions binaires imbriquées) : 0–49 → crowdstrike-zta-high-risk, 50–75 → crowdstrike-zta-med-risk, 76–100 → crowdstrike-zta-low-risk. Chaque balise correspond à sa propre règle de classification des périphériques Netskope et à sa propre politique de protection en temps réel.
• Comme CrowdStrike et Netskope ne partagent pas d'identifiant de périphérique, une requête HTTP Cloud interroge le point de terminaison de recherche de statut client de Netskope (GET /api/v2/events/datasearch/clientstatus) filtré côté serveur par nom d'hôte, trié par orderbys=timestamp desc — le tri est important car un seul nom d'hôte peut avoir plusieurs enregistrements historiques de statut client, et sans tri explicite, l'API ne garantit pas de renvoyer le plus récent en premier.
• Une petite action de script Python extrait le premier élément du tableau (nsdeviceuid et userkey) car la syntaxe de référence de données de Fusion SOAR ne peut pas effectuer d'indexation de tableau directement.
• L'action finale envoie une requête POST au point de terminaison de remplacement en masse des balises de Netskope (/api/v2/devices/device/tags/bulkreplace) avec l'identité du périphérique résolue et la balise cible de la branche. Comme ce point de terminaison remplace la liste complète des balises au lieu de l'ajouter, le déplacement d'un périphérique entre les niveaux supprime automatiquement la balise de l'ancien niveau. Aucune logique de nettoyage distincte n'est nécessaire.

Gotchas worth knowing before you build this yourself

• Un en-tête saisi manuellement nommé « Content-Type: » (avec un signe deux-points à la fin) a provoqué une erreur cryptique 400 « execution failed host ». Le signe deux-points est illégal dans un nom d'en-tête HTTP ; le client HTTP de la plateforme a donc échoué avant que la requête n'atteigne Netskope. Si une requête HTTP Cloud échoue sans détail utile, vérifiez la requête entièrement résolue de l’enregistrement d’exécution, en-têtes inclus.
• userkey n'est pas identique à l'UID du périphérique. Un exemple couramment cité les définit comme égaux, mais c'est incorrect. userkey est un identifiant opaque distinct par inscription, et le fait d'y transmettre un UID de périphérique crée silencieusement une association de balise fantôme alors que l'API renvoie toujours un succès, ce qui rend l'erreur facile à ignorer.
• Le test d'une action unique en isolation attend la prochaine occurrence réelle de ce déclencheur à l'échelle du tenant. Il ne cible pas un périphérique spécifique et semble indiscernable d'une exécution fictive délibérée dans l'interface utilisateur. Testez plutôt le workflow complet avec une charge utile fictive explicite, exécutée en direct de bout en bout.

Verification approach

Faites passer un périphérique de test à travers les trois bandes de score et confirmez que sa balise, et uniquement sa balise, change à chaque fois, en vérifiant l'état réel du périphérique dans Netskope plutôt que de vous fier à une coche verte dans le canevas de workflow.

Generalizes beyond ZTA scores

Le même modèle resolve-identity → apply-tag → let-Device-Classification-decide fonctionne pour tout système capable d'appeler un webhook sortant ou de déclencher un trigger SOAR natif, et pas seulement pour CrowdStrike.

→ Implementation guide (Community): Transformer les scores Zero Trust de CrowdStrike en réponse automatique aux politiques Netskope

4.12 Listes de marché associées (même capacité, offre différente)

Deux autres entrées du CrowdStrike Marketplace font apparaître des fonctionnalités déjà couvertes ailleurs dans ce document sous des noms différents ; elles sont listées ici pour que cette référence soit complète, sans dupliquer les détails techniques :

• Netskope CASB (Cloud Access Security Broker) pour Falcon LogScale : le packaging sur le CrowdStrike Marketplace du chemin d'expédition des journaux LogScale de la section 4.9, fourni avec des tableaux de bord Falcon LogScale prédéfinis pour l'activité, les alertes et les détections CASB. Aucune intégration technique distincte au-delà de ce qui est décrit au point 4.9. Les tableaux de bord constituent la valeur ajoutée.
• Netskope Data Connector (ingestion de données pour Falcon Insight XDR) : le packaging sur la marketplace CrowdStrike de la même ingestion de journaux/alertes Netskope SSE-vers-XDR décrite dans le partage d'alertes bidirectionnel de la section 4.6, à nouveau regroupé avec des tableaux de bord prédéfinis pour un triage unifié au sein de la console Falcon.

Si vous comptez les listes distinctes du CrowdStrike Marketplace liées à Netskope à des fins d'approvisionnement, notez que ces deux éléments sont des vitrines alternatives pour des fonctionnalités déjà couvertes aux sections 4.6 et 4.9, et non des mécanismes d'intégration supplémentaires.

5. Exemples de scénarios de stratégie

Les scénarios suivants illustrent comment plusieurs signaux CrowdStrike se combinent dans la politique Netskope pour produire des résultats qui seraient impossibles avec un seul signal ou avec une logique binaire d'autorisation/blocage seule.

Scénario 1 : périphérique sous attaque active — restreindre l'accès aux données cloud

CrowdStrike détecte des logiciels malveillants sur un ordinateur portable managé. Le score ZTA chute à 200. Le plugin de risque hôte (section 4.2) met à jour la classification du périphérique dans Netskope, passant de « managé » à « non managé » en quelques minutes. La session de l’utilisateur correspond immédiatement à une politique qui autorise un accès en lecture seule aux applications SaaS standard, mais bloque le chargement, le téléchargement et l’accès à toute application marquée comme sensible. L’utilisateur reçoit un message de coaching expliquant que son périphérique a été signalé et l’orientant vers le support informatique. Aucun analyste SOC n’a besoin d’intervenir sur une politique Netskope.

Scénario 2 : Informations d'identification compromises — authentification renforcée avant l'accès au cloud

Falcon Identity Protection détecte les activités de credential stuffing ciblant un compte utilisateur. Le score de risque d'identité dépasse un seuil défini. Risk Exchange (CRE) de Netskope reçoit le score mis à jour via le plugin Falcon Identity Protection et déplace l'utilisateur dans un groupe « risque d'identité élevé ». La politique de ce groupe exige une réauthentification via MFA avant tout accès à une application cloud notée CCI < 70 ou marquée comme service de partage de fichiers. Les outils de productivité habituels de l'utilisateur restent accessibles sans aucune friction.

Scénario 3 : New IOC détecté sur le parc de terminaux — blocage d’URL déployé sur l’ensemble de la base d’utilisateurs

CrowdStrike détecte un nouveau domaine de commande et de contrôle dans une détection Falcon. L'application Direct to Zero Trust extrait le domaine en tant qu'IOC et le transmet à la liste d'URL Netskope en quelques minutes. La politique de protection en temps réel de Netskope bloque immédiatement l'accès à ce domaine pour tous les utilisateurs sur l'ensemble du parc — navigateurs web, applications cloud et périphériques gérés — avant que le domaine n'apparaisse dans un flux de menaces public.

Scénario 4 : Exposition à une vulnérabilité élevée — accès aux données sensibles limité

Falcon Spotlight identifie un périphérique exécutant une application avec une CVE critique non corrigée. Le plugin Spotlight transmet le score de vulnérabilité au contexte de risque du périphérique de Netskope via Risk Exchange (CRE). La politique Netskope empêche le périphérique d'accéder aux données marquées avec un profil DLP PII ou financier et présente un message de coaching invitant l'utilisateur à corriger l'application. Lorsque le correctif est appliqué et que Spotlight signale la CVE comme résolue, l'accès normal est automatiquement rétabli.

Scénario 5 : Risque combiné périphérique + identité — blocage complet avec alerte SOC

Le score ZTA d’un périphérique chute à 150 (malware actif) tandis que Falcon Identity Protection signale simultanément le même utilisateur pour une utilisation anormale des informations d’identification. Les deux signaux alimentent le même module Risk Exchange (CRE) via leurs plugins respectifs. Une règle métier dans Cloud Exchange évalue les deux scores et détermine si le risque combiné dépasse le seuil de terminaison complète de la session. Netskope bloque entièrement la session, déplace l’utilisateur vers un groupe de quarantaine via SCIM et envoie une alerte de haute priorité au SIEM. Le SOC ouvre un incident Falcon XDR unique qui fait apparaître à la fois la détection sur le point final et les données de session Netskope.

Scénario 6 : charge de travail cloud à risque — réduire l'accès aux enquêteurs sur les incidents

Falcon Cloud Security détecte qu'une charge de travail cloud précédemment conforme a accumulé une dérive de configuration critique : des règles de groupe de sécurité ouvertes, des politiques IAM trop permissives et une journalisation désactivée apparaissent sous forme d'IOM. Le plugin Falcon Cloud Security transmet le signal de risque élevé à Netskope via Risk Exchange (CRE). Netskope met à jour la définition de l'application NPA, déplaçant la charge de travail hors du groupe d'applications privées standard vers un objet dédié « En cours d'investigation ». La politique pour cet objet autorise l'accès uniquement aux ingénieurs de sécurité et au personnel des opérations cloud désignés ; tous les autres utilisateurs reçoivent un blocage avec un message contextuel. Lorsque Falcon Cloud Security confirme que les erreurs de configuration sont résolues, la charge de travail revient automatiquement dans le groupe d'applications standard. Aucune modification manuelle des politiques n'est requise.

Scénario 7 : Confinement déclenché par un analyste à partir d’une détection Falcon Insight XDR

Une détection Insight XDR signale le terminal d'un utilisateur pour un comportement suspect de mouvement latéral, corrélant une alerte de capteur Falcon avec des tentatives d'authentification anormales. Plutôt que de basculer vers la console Netskope, l'analyste déclenche l'action de réponse Netskope pour Falcon Insight XDR (section 4.11.2) directement depuis la fiche de détection, déplaçant l'utilisateur vers un groupe Netskope restreint en un seul clic. La politique Netskope pour ce groupe réduit immédiatement la portée de la session ZTNA de l'utilisateur et bloque l'activité de téléchargement/partage, tandis que l'analyste poursuit l'investigation du terminal dans Falcon sans perdre de vue l'incident.

Scénario 8 : Confinement inter-plateforme entièrement automatisé via Falcon Fusion SOAR

Un playbook Falcon Fusion SOAR est configuré pour surveiller une combinaison spécifique de détections : une détection de logiciel malveillant de gravité critique associée à une connexion depuis une New zone géographique non reconnue au cours de la même heure. Lorsque les deux conditions sont remplies pour le même utilisateur, le playbook appelle automatiquement le connecteur Netskope SOAR Actions (section 4.11.1) pour ajouter l'utilisateur à un groupe de quarantaine, et ouvre en parallèle un ticket dans le système ITSM du SOC. Aucun analyste n'intervient pour l'étape de confinement initiale. Le SOC examine le ticket ainsi que les preuves Falcon et Netskope associées, et rétablit manuellement l'accès une fois que l'enquête a disculpé l'utilisateur. Ce scénario illustre la différence avec le scénario 7 ; ici, le déclencheur et l'action sont tous deux entièrement automatisés, l'analyste n'intervenant qu'une fois le confinement effectué.

Scénario 9 : Combinaison d'actions en sens inverse avec des scores de risque transmis

Le score ZTA CrowdStrike d'un utilisateur (section 4.1) chute dans le niveau en lecture seule (500–800) après la détection d'un problème de santé modéré du périphérique, qui n'est pas assez grave pour bloquer totalement l'accès par lui-même. Peu après, un analyste SOC examinant une télémétrie Falcon sans rapport déclenche manuellement l'action de réponse Netskope pour Falcon Insight XDR (section 4.11.2) sur la base d'une évaluation du profil de risque global de l'utilisateur, le déplaçant dans un groupe plus restrictif que celui qu'aurait appliqué le niveau automatique basé sur le ZTA. Étant donné que l'attribution manuelle de groupe et la classification automatique basée sur le périphérique peuvent être actives simultanément, les administrateurs de politiques doivent concevoir des règles métier et une priorité de groupe de sorte que la plus restrictive des deux prévale toujours, et documenter quel mécanisme — score de risque automatique ou action manuelle de l'analyste — fait autorité en cas de désaccord, avant d'activer les deux en production.

Scénario 10 : Le tableau de bord unifié LogScale accélère une enquête existante

Un analyste CrowdStrike enquête sur une détection de point de terminaison et ouvre le tableau de bord Netskope CASB préconfiguré dans Falcon LogScale (section 4.12) pour vérifier l'activité récente de l'utilisateur sur les applications cloud sans quitter la console Falcon. Le tableau de bord indique que l'utilisateur a chargé un volume important de fichiers vers une application de stockage cloud personnelle non autorisée dans l'heure précédant le déclenchement de la détection sur le point de terminaison. Ce contexte, visible en quelques minutes sans nécessiter de connexion Netskope distincte ni de recherche manuelle dans les journaux, conduit l'analyste à faire passer l'incident d'un simple nettoyage de malware à un cas suspect d'exfiltration de données, et à demander que le score de risque hôte de la section 4.2 soit vérifié immédiatement plutôt que d'attendre la prochaine synchronisation planifiée.

6. Pour commencer

Toutes les intégrations n'ont pas besoin d'être déployées en même temps. La séquence recommandée renforce progressivement les capacités, en commençant par les signaux à plus forte valeur ajoutée et la complexité d'implémentation la plus faible.

Étape 1 — Streaming de journaux (visibilité immédiate)

Déployez le plugin LogScale ou configurez le streaming de journaux S3 pour alimenter CrowdStrike NG-SIEM avec les journaux de transactions web de Netskope. Cela apporte une valeur d'investigation immédiate sans nécessiter de modification de stratégie. Référence : Section 4.9.

Étape 2 — Renseignements sur les menaces (impact élevé, faible friction)

Déployez le plugin Threat Exchange ou l'application Direct to Zero Trust pour commencer le partage bidirectionnel d'IOC. Consultez la section 4.5.1 pour choisir ce qui convient à votre environnement. Ceci enrichit immédiatement les politiques d'URL et de hachage de fichiers de Netskope. Référence : sections 4.4 et 4.5.

Étape 3 — Posture du périphérique via le score ZTA

Déployez le plugin Risk Exchange (CRE) avec l'intégration du score ZTA de CrowdStrike. Définissez les seuils de score et la logique de reclassement des périphériques. Commencez par le mode alerte uniquement pour calibrer les seuils avant d'activer le reclassement automatique. Référence : Section 4.1.

Étape 4 — Risque lié à l’utilisateur et à l’identité

Ajoutez le plugin de risque hôte (4.2) et Falcon Identity Protection (4.3) aux côtés du plugin ZTA déjà déployé à l'étape 3. Tous trois alimentent le même module Risk Exchange (CRE) ; cette étape est donc additive et non un déploiement distinct. Définissez des règles métier qui mappent les plages de scores de risque aux groupes d'utilisateurs Netskope et aux politiques qui s'appliquent à chaque groupe. Vérifiez la note sur la direction du score dans la section 4.1 avant de définir les seuils.

Étape 5 — XDR et SCIM

Connectez CrowdStrike XDR à Netskope SSE et configurez la synchronisation de groupe SCIM, en utilisant la méthode actuelle de jeton RBAC v3 plutôt que le flux obsolète OAuth Directory Tool. Cela permet des workflow de réponse aux incidents automatisés sur les deux plateformes. Référence : Section 4.6.

Étape 6 — Contexte de charge de travail Cloud et de vulnérabilité

Ajoutez les plugins Falcon Cloud Security et Falcon Spotlight — deux contributeurs supplémentaires au même module Risk Exchange (CRE) — pour activer un contexte de pilier de risque supplémentaire pour le risque lié aux périphériques et l'accès aux charges de travail. L'un ou l'autre, ou les deux, peuvent être déployés à ce stade. Référence : sections 4.7 et 4.8.

7. Support, escalade et maintenance continue

Cette section fournit des conseils d'escalade généraux documentés par les fournisseurs ; elle ne mentionne intentionnellement pas d'heures de SLA ou d'engagements de temps de réponse spécifiques, car ceux-ci varient selon le niveau de support Netskope et CrowdStrike de chaque organisation et doivent être confirmés directement auprès de l'équipe de compte de chaque fournisseur.

7.1 Où obtenir de l'aide

• Portail de connaissances Netskope : la source faisant autorité et mise à jour en continu pour chaque guide d'implémentation lié dans la section 4 ; consultez-le en priorité lorsqu'une étape de l'interface utilisateur dans ce document ne correspond pas à ce que vous voyez, car Netskope met à jour les interfaces des plugins entre les versions.
• Forum de la communauté Netskope Cloud Exchange : les fils de discussion actifs de la communauté (cités tout au long de la section 4) couvrent souvent des cas limites qui ne figurent pas encore dans la documentation officielle, y compris des procédures testées sur le terrain par d'autres clients communs.
• Portail de support Netskope et votre Customer Success Manager (CSM) / Technical Account Manager (TAM) Netskope : le chemin d'escalade approprié pour les questions de licence (comme confirmer si Advanced UEBA ou Advanced Threat Protection est inclus dans votre contrat actuel) et pour les problèmes que la documentation et la communauté ne résolvent pas.
• Contactez le support CrowdStrike et votre équipe de compte CrowdStrike pour toute question concernant la portée de l'API Client, les droits d'accès à Falcon Foundry/Direct to Zero Trust App, et les codes d'erreur côté CrowdStrike.

7.2 Cadence de maintenance

• Les plugins Cloud Exchange se mettent à jour indépendamment et assez fréquemment ; vérifiez Settings > Plugin Store > Check for Updates à une fréquence régulière (par exemple mensuelle) plutôt que de supposer que les versions de ce document restent à jour.
• Les champs d'application (scopes) de l'API CrowdStrike ont été renommés et répartis entre les versions (voir la transition de l'API Detect→Alerts notée en 4.4) ; revalidez les champs d'application du client API chaque fois qu'une mise à niveau du plugin est prévue avant de l'appliquer.
• Retestez les seuils de score (section 4.1) après toute mise à jour de plugin affectant le module Risk Exchange (CRE). Des changements d'échelle ou de nom de champ ont modifié le comportement de notation lors des versions précédentes.

8. Index de référence de l'intégration

Tous les guides de mise en œuvre de l'intégration sont conservés dans le portail de connaissances de Netskope. Les liens de la communauté sont gérés par la communauté d'utilisateurs de Netskope et sont utiles pour obtenir des détails testés sur le terrain, mais ne constituent pas une documentation officielle.

→ ZTA Score — Risk Exchange Plugin (v1.1.0): Plugin CrowdStrike pour Risk Exchange

→ ZTA Score — Risk Exchange Plugin (v1.0.0, superseded): Plugin CrowdStrike pour User Risk Exchange

→ Host Risk Plugin (v1.2.0, listed as User Risk Exchange): Plugin CrowdStrike pour User Risk Exchange

→ Falcon Identity Protection Plugin (listed as User Risk Exchange): Plugin CrowdStrike Falcon Identity Protection pour User Risk Exchange

→ Threat Exchange Plugin (v2.3.0): Plugin CrowdStrike pour Threat Exchange

→ Direct to Zero Trust App (Falcon Foundry): Netskope Direct to Zero Trust App

→ XDR Integration — native guide: Intégration CrowdStrike XDR

→ XDR Integration — Netskope SSE third-party guide: Intégration tierce CrowdStrike XDR : Netskope SSE

→ Falcon Cloud Security — Risk Exchange Plugin: Plugin CrowdStrike Cloud Security pour Risk Exchange

→ Falcon Spotlight — Risk Exchange Plugin: CrowdStrike Falcon Spotlight Plugin pour Risk Exchange

→ LogScale — Log Shipper Plugin: CrowdStrike LogScale Plugin pour Log Shipper

→ NG-SIEM Third-Party Integration: CrowdStrike Next-Gen SIEM Intégration de tiers

→ Log streaming setup: Flux de logs vers CrowdStrike

→ AI SecOps events to Falcon Next-Gen SIEM (Outbound Webhooks): Envoi des événements Netskope AI SecOps vers CrowdStrike Falcon Next-Gen SIEM

→ Endpoint coexistence best practices: CrowdStrike

→ Netskope SOAR Actions (Falcon Fusion SOAR) — Marketplace listing: Actions SOAR de Netskope

→ Netskope Response Actions for Falcon Insight XDR — Marketplace listing: Actions de réponse Netskope pour Falcon Insight XDR

→ Netskope CASB for Falcon LogScale — Marketplace listing: Cloud Access Security Broker (CASB) de Netskope pour Falcon LogScale 

→ Netskope Data Connector (Data Ingestion for Falcon Insight XDR) — Marketplace listing: Ingestion de données Netskope pour Falcon Insight XDR 

→ Netskope Transaction Logs Data Connector — Marketplace listing: Connecteur de données des journaux de transaction Netskope 

→ EDR remediation integration (in-tenant, retiring Dec 1, 2025 — migrate to Threat Exchange): Intégration de CrowdStrike pour la gestion des incidents (EDR)

→ Field-built Fusion SOAR + Device Tags API pattern: Transformer les scores Zero Trust de CrowdStrike en réponse automatique aux politiques Netskope

→ Netskope SCIM / RBAC v3 user provisioning guide: Approvisionnement et authentification des utilisateurs

→ Cloud Exchange FAQs (licensing, Retrohunt, API transitions, troubleshooting, CRE consolidation): FAQ sur Cloud Exchange

→ Netskope Zero Trust Engine: Zero Trust Engine

→ Netskope + CrowdStrike Solution Brief: Netskope et CrowdStrike

Les URL et les numéros de version reflètent la documentation disponible publiquement à la date de cette révision (juillet 2026) ; vérifiez auprès du portail de connaissances de Netskope et de votre équipe de compte CrowdStrike les dernières versions, les périmètres et les conditions de licence avant le déploiement.