L’IA invisible dépasse les inventaires réseau des entreprises

KnowBe4 remet sous les projecteurs une vieille hypothèse de sécurité : un inventaire approuvé ne prouve plus que chaque actif en activité est connu. L’article Google News met en lumière les services d’IA, les appareils cachés et d’autres actifs que les registres conventionnels peuvent manquer. Cette combinaison transforme une faiblesse administrative en problème de sécurité actif.

Le conflit essentiel n’oppose pas un fournisseur de sécurité à un autre. Il oppose les registres statiques aux preuves continues. Les bases de données d’approvisionnement décrivent ce qu’une organisation pense posséder, tandis que la télémétrie réseau, des terminaux, des identités et des navigateurs révèle ce que les personnes utilisent réellement.

Cet écart s’est creusé à mesure que les fonctions d’IA se répandent dans les logiciels, les extensions de navigateur, les interfaces de programmation d’applications et les suites de productivité existantes. Un service peut ne jamais être acquis comme produit distinct. Il peut apparaître via une mise à jour, un compte personnel, une clé API ou un appareil appartenant à un employé.

L’argument de KnowBe4 dépasse donc la gestion courante des actifs. Les équipes de sécurité doivent désormais découvrir les comportements logiciels, les mouvements de données, les identités et les services externes, en plus du matériel physique. Elles doivent aussi le faire sans considérer chaque connexion inhabituelle comme malveillante.

L’article Google News révèle une défaillance plus large des inventaires

Le changement central est simple : les inventaires de sécurité doivent décrire l’activité observée, et non seulement la propriété approuvée.

L’article Google News présente le problème à travers trois catégories d’actifs. Les outils d’IA représentent des services externes et des logiciels intégrés. Les appareils cachés représentent du matériel ayant contourné le processus normal d’enrôlement. Les actifs inconnus couvrent tout ce qui reste visible dans la télémétrie tout en étant absent des registres de référence.

Ces catégories se recoupent, mais soulèvent des questions différentes. Un ordinateur portable personnel peut accéder à un service d’IA approuvé via un navigateur non géré. Un ordinateur portable approuvé peut utiliser un modèle non approuvé via une API. Une plateforme de productivité autorisée peut activer une nouvelle fonctionnalité d’IA sans déclencher un événement d’achat distinct.

Un inventaire traditionnel peut enregistrer l’ordinateur portable et la suite de productivité tout en manquant le comportement risqué. Il peut aussi répertorier un fournisseur d’IA sans indiquer quels employés l’utilisent. Aucun de ces registres n’explique quelles données franchissent la frontière.

C’est pourquoi une simple liste d’appareils ne peut pas étayer les décisions de risque modernes. Les équipes de sécurité ont besoin d’une carte relationnelle reliant les utilisateurs, les terminaux, les applications, les identités, les données et les destinations. Chaque observation exige du contexte avant de devenir exploitable.

Le problème dépasse également l’IA générative. Caméras, imprimantes, équipements de laboratoire, contrôles de bâtiments, machines virtuelles, conteneurs et ressources cloud temporaires peuvent tous échapper aux registres manuels. Certains n’ont pas d’agents de gestion standard. D’autres apparaissent brièvement et disparaissent avant le prochain examen planifié.

Le NIST a formalisé ce périmètre élargi dans CSF 2.0. Ses résultats de gestion des actifs couvrent le matériel, les logiciels, les systèmes, les services, les fournisseurs, les données et les flux réseau. Le cadre traite également l’identification comme une gestion continue des risques, et non comme un exercice comptable annuel.

Cette distinction est importante, car inconnu ne signifie pas hostile. Un appareil nouvellement observé peut être un remplacement autorisé en attente de documentation. Un domaine étrange peut appartenir au système de diffusion de contenu d’un fournisseur approuvé. Un point de terminaison lié à l’IA peut prendre en charge une fonctionnalité que les employés n’ont jamais consciemment activée.

La découverte doit donc créer une file d’attente de classification. Elle ne doit pas déclencher automatiquement une sanction ou une isolation. Les équipes ont besoin de suffisamment d’éléments pour déterminer le propriétaire, la finalité, la sensibilité et l’importance métier.

Le titre de KnowBe4 fonctionne parce qu’il condense ces cas en une question inconfortable : les défenseurs peuvent-ils protéger des actifs qu’ils ne peuvent pas nommer ? La réponse dépend moins de l’achat d’un scanner supplémentaire que de la réconciliation de plusieurs visions incomplètes.

Le Shadow AI exerce une pression sur les équipes de sécurité dans les deux sens

Les responsables de la sécurité doivent révéler les usages non autorisés de l’IA sans bloquer un travail utile ni instaurer une surveillance excessive des employés.

Le Shadow AI désigne les services ou fonctionnalités d’IA utilisés en dehors du processus technologique approuvé par une organisation. Le terme couvre davantage que les employés utilisant des chatbots publics. Il inclut aussi les comptes API personnels, les assistants de programmation, les extensions de navigateur, les fonctionnalités intégrées et les modèles exécutés sur du matériel local.

Chaque voie laisse des traces différentes. L’accès via navigateur peut apparaître dans les journaux web ou de noms de domaine. L’activité API peut apparaître dans les registres cloud, de dépôt ou de gestion des secrets. Les modèles locaux peuvent ne générer aucune connexion externe après l’arrivée de leurs fichiers.

Cette fragmentation place les équipes de sécurité entre deux exigences. Les dirigeants veulent un inventaire fiable de l’IA, car des informations confidentielles peuvent entrer dans des systèmes externes. Les employés veulent accéder à des outils qui les aident à rechercher, rédiger, coder, analyser et communiquer.

Un blocage généralisé offre une politique claire, mais une faible visibilité opérationnelle. Les personnes peuvent se tourner vers des appareils personnels, des connexions mobiles ou des services moins connus. L’organisation perd alors la possibilité de voir les usages, d’orienter les comportements ou de proposer une alternative plus sûre.

Un accès sans restriction crée le problème inverse. Les collaborateurs peuvent soumettre des informations clients, des contrats, du code source, des notes de réunion ou une stratégie interne à des services aux règles de conservation peu familières. Même un fournisseur réputé peut être inadapté à une catégorie de données particulière.

Les recommandations de Microsoft sur la découverte des applications d’IA illustrent cette évolution vers des contrôles au niveau des comportements. Elles décrivent une visibilité sur les visites, les téléversements, les contenus collés et d’autres interactions risquées. Il s’agit d’une tâche différente de la vérification de la présence d’une application dans une liste d’approvisionnement.

L’identité ajoute une couche supplémentaire. Un compte d’entreprise et un compte personnel peuvent atteindre le même service via le même point de terminaison. La surveillance au niveau du domaine peut identifier la destination, mais pas le contrat applicable, le paramètre de conservation ou l’autorisation de l’utilisateur.

L’IA intégrée complique davantage la classification. Une application familière peut ajouter des fonctions de synthèse, de transcription, de prédiction ou de génération de contenu au moyen d’une mise à jour ordinaire. Le produit sous-jacent reste approuvé, tandis que son comportement de traitement des données change.

Les équipes de sécurité sont donc poussées à maintenir deux inventaires liés. Le premier couvre les actifs et services techniques. Le second couvre les cas d’usage approuvés, les catégories de données, les identités, les propriétaires et les exigences de contrôle.

Ce second inventaire ne peut pas relever uniquement de la sécurité. Les achats connaissent les contrats. Le service juridique comprend les conditions d’utilisation. Les équipes chargées de la confidentialité évaluent le traitement des données. Les responsables de département savent pourquoi les employés ont besoin d’un outil. Les propriétaires de plateforme comprennent la configuration et la journalisation.

La réponse imposée est autant organisationnelle que technique. La sécurité doit bâtir un processus répétable transformant les découvertes en décisions d’attribution. Sinon, les systèmes de détection produisent des alertes sans créer de gouvernance.

Les employés ont aussi besoin d’un canal de signalement utilisable. Un collaborateur qui découvre une fonctionnalité d’IA utile devrait pouvoir demander un examen sans s’attendre à un refus automatique. Ce processus révèle la demande avant qu’elle ne quitte entièrement les canaux gérés.

La pression persistera parce que l’adoption de l’IA évolue plus vite que les cycles de revue annuels. Un inventaire trimestriel peut encore manquer un service ayant généré des milliers d’interactions internes en quelques jours. La découverte continue doit alimenter un processus d’approbation et de correction plus rapide.

Les preuves continues remplacent la liste statique des actifs

L’approche gagnante combine plusieurs signaux imparfaits, puis mesure les divergences entre eux.

Aucun capteur unique ne peut identifier chaque actif. L’analyse active sonde les systèmes accessibles, mais elle peut perturber des équipements opérationnels sensibles. La surveillance passive observe le trafic en toute sécurité, mais les appareils silencieux peuvent rester invisibles. Les agents de terminaux offrent des détails, mais le matériel non géré n’en dispose pas.

Un programme de découverte fiable traite chaque source comme une preuve partielle. Les registres réseau montrent les connexions. Les systèmes d’identité montrent les comptes et l’authentification. Les plateformes de terminaux montrent les applications installées, les processus, les extensions et les fichiers locaux. Les plans de contrôle cloud montrent les ressources et les relations entre services.

Les bases de données d’approvisionnement et de configuration restent importantes. Elles fournissent le propriétaire, le contrat, le cycle de vie et le contexte métier. Leur faiblesse n’est pas leur inutilité. Leur faiblesse est qu’elles décrivent souvent une intention plutôt qu’un comportement présent.

La première étape pratique consiste à définir les attentes de référence. Les équipes ont besoin de listes d’appareils, services, identités, outils d’IA, catégories de données et chemins réseau approuvés. Ces listes forment une base de référence, mais elles ne doivent jamais devenir l’unique version de la réalité.

La deuxième étape consiste à recueillir les observations en continu. Les enregistrements DHCP et de résolution d’adresses peuvent révéler le matériel connecté. Les journaux de noms de domaine et de proxy peuvent révéler des services externes. Les journaux d’authentification peuvent relier l’activité aux identités. Les données des terminaux peuvent identifier les processus ayant initié le trafic.

Les environnements cloud exigent leurs propres voies de découverte. Les ressources peuvent apparaître par automatisation et disparaître après la fin d’une charge de travail. Les conteneurs, fonctions sans serveur, bases de données gérées et environnements de développement temporaires peuvent ne pas ressembler aux appareils traditionnels.

L’usage de l’IA ajoute des preuves au niveau applicatif. Les équipes peuvent rechercher des catégories de services connues, des extensions de navigateur, des autorisations OAuth, des clés API liées aux modèles et des transferts inhabituels vers des destinations externes. Elles peuvent aussi vérifier quels produits approuvés ont récemment ajouté des fonctions d’IA.

La troisième étape est la réconciliation. Chaque objet observé doit être comparé à un registre attendu. Chaque registre attendu doit disposer de preuves récentes montrant qu’il existe toujours. Les divergences deviennent la file de travail.

Cette file a besoin de catégories claires. Un actif peut être autorisé et documenté, autorisé mais non documenté, non autorisé mais bénin, suspect, ou ne plus être présent. Inconnu doit être une classification temporaire, et non une zone d’attente permanente.

La priorisation doit suivre l’exposition et les conséquences. Une passerelle inconnue exposée à Internet mérite un examen plus rapide qu’un appareil de test isolé. Un service recevant des données réglementées exige davantage d’attention qu’un service traitant du texte marketing public.

Les technologies opérationnelles exigent une prudence supplémentaire. Ces systèmes ont souvent de longs cycles de vie, des protocoles spécialisés et une tolérance limitée à l’analyse active. Les recommandations sur l’inventaire OT publiées par plusieurs agences conseillent de combiner documentation, inspection physique et informations dérivées du réseau.

Ces recommandations identifient également des attributs utiles, notamment le rôle de l’appareil, le nom d’hôte, l’adresse réseau, le fabricant, le modèle, le système d’exploitation, l’emplacement, les protocoles, les ports, les services et les comptes utilisateurs. Ces attributs aident à transformer une adresse observée en décision de risque.

Ce mécanisme change la manière dont le succès doit être mesuré. Un inventaire volumineux n’est pas automatiquement un bon inventaire. Un programme utile mesure la couverture, la fraîcheur, le délai de réconciliation, l’attribution des responsabilités et l’ancienneté des inconnus non résolus.

Il devrait également suivre la fréquence à laquelle des actifs connus deviennent inconnus après des modifications. Cet indicateur met en évidence les défaillances des processus d’intégration, de départ, d’approvisionnement et de configuration. La découverte peut ensuite améliorer les systèmes à l’origine de cet écart.

Le résultat n’est pas une visibilité parfaite. Il s’agit d’un processus défendable qui détecte les changements, consigne les incertitudes et attribue les responsabilités. C’est plus précieux qu’une feuille de calcul soignée dont personne ne peut démontrer l’exactitude.

Les outils d’IA et les appareils cachés laissent des indices différents

Les actifs inconnus deviennent gérables lorsque les équipes examinent leurs signaux en fonction de leur type.

Un appareil physique caché laisse généralement des traces au niveau du réseau. Il demande une adresse, résout des noms, annonce des services, communique avec des pairs ou contacte une destination externe. Son fabricant peut parfois être déduit de son adresse matérielle, bien que cet indice ne soit pas concluant.

L’équipe peut alors poser des questions concrètes. Quel segment réseau l’a observé ? Quand est-il apparu pour la première fois ? Revient-il selon un calendrier ? Quels protocoles utilise-t-il ? Son trafic ressemble-t-il à celui d’une imprimante, d’une caméra, d’un téléphone, d’un serveur ou d’un contrôleur ?

Les contrôles d’accès réseau peuvent exiger une authentification ou placer les appareils inconnus dans des segments restreints. Toutefois, l’isolation doit tenir compte de l’impact opérationnel. Un appareil médical, industriel ou de contrôle des bâtiments inconnu peut assurer des fonctions essentielles malgré une documentation insuffisante.

Un actif cloud inconnu présente un autre schéma. Il peut disposer d’un compte, d’une étiquette de propriétaire, d’un modèle de déploiement ou d’une identité de service. Les enquêteurs devraient relier son événement de création à un utilisateur, un pipeline d’automatisation, un ticket, un dépôt ou un projet.

Un service d’IA caché peut être plus difficile à classer, car la destination peut être visible tandis que le cas d’usage reste obscur. Voir le domaine d’un fournisseur de modèles ne permet pas de savoir si un utilisateur a soumis du texte public ou du code source confidentiel.

Le contexte du navigateur et du terminal aide à combler cet écart. Un navigateur géré peut distinguer les visites, les téléversements, le contenu collé, les téléchargements et les types de comptes. Les contrôles sur les terminaux peuvent identifier l’application d’origine et appliquer des règles selon la sensibilité des informations.

L’utilisation via API exige des preuves différentes. Les équipes de sécurité devraient examiner les magasins de secrets, les dépôts de code source, les systèmes d’intégration continue, les passerelles cloud, les relevés de dépenses et les appels de services sortants. Les clés personnelles peuvent contourner les comptes gérés de manière centralisée et les limites d’utilisation.

Les autorisations OAuth méritent également une attention particulière. OAuth permet à un service d’accéder à un autre au nom d’un utilisateur. Un assistant d’IA ayant accès à une boîte mail, un calendrier, un drive ou un dépôt peut devenir une relation d’actif importante, même sans nouvel appareil.

Les modèles locaux inversent le problème de visibilité. Leur activité d’inférence peut rester sur un terminal, tandis que les téléchargements de modèles et les outils de support créent des événements observables. L’augmentation du stockage, l’installation de paquets, l’exécution de processus et l’utilisation du processeur graphique peuvent fournir un contexte utile.

Les fonctionnalités intégrées exigent un examen des fournisseurs. Les équipes devraient surveiller les notes de version, les paramètres administratifs, les sous-traitants et les modifications contractuelles pour les applications approuvées. Un fournisseur connu peut introduire un nouveau chemin de données sans modifier le nom familier de son produit.

Les travailleurs du savoir créent également un défi de documentation. Ils peuvent combiner plusieurs outils au cours d’une même tâche, en déplaçant du contenu entre un enregistreur de réunions, un chatbot, un éditeur de documents et une plateforme de projet. Chaque outil peut être approuvé alors que le flux combiné enfreint la politique.

Maintenir une base de connaissances sur l’IA claire peut aider les équipes à documenter les flux de travail approuvés, les responsables, les preuves et les limites de données. La documentation devrait soutenir l’enquête plutôt que remplacer l’observation technique.

Le processus de classification devrait se conclure par une action. Les actifs approuvés intègrent des inventaires gérés. Les services inutiles perdent leur accès. Les outils mal configurés reçoivent des paramètres plus sûrs. Les systèmes suspects passent en réponse à incident. Les cas non résolus conservent un accès restreint jusqu’à ce qu’un responsable soit identifié.

Cette approche évite de traiter tous les inconnus de la même manière. Elle reconnaît également que la découverte des actifs n’est pas terminée lorsqu’un scanner produit un nom. L’organisation doit comprendre la finalité, le contrôle et l’exposition des données.

Une visibilité accrue peut créer ses propres risques de sécurité et de confidentialité

La découverte continue devient contre-productive lorsque la collecte dépasse un objectif de sécurité défini.

La principale objection à une surveillance étendue concerne la confidentialité. Les données issues des navigateurs, des terminaux, des identités et des réseaux peuvent révéler en détail le comportement des employés. La combinaison de ces données accroît la valeur des enquêtes, mais aussi le risque d’abus.

Les organisations devraient définir ce qu’elles collectent, pourquoi elles le collectent, qui peut y accéder et combien de temps elles le conservent. Un programme de shadow AI devrait se concentrer sur les événements pertinents pour la sécurité. Il ne devrait pas devenir un système général de classement de l’activité des employés.

Les appareils personnels créent une limite particulièrement difficile. Une entreprise peut contrôler l’accès aux données d’entreprise sans prétendre avoir une visibilité sur l’ensemble de l’appareil d’un employé. Les applications gérées, les espaces de travail protégés et l’accès conditionnel peuvent préserver cette séparation.

Les faux positifs créent un autre risque. Les infrastructures partagées, les réseaux de diffusion de contenu, les intégrations fournisseurs et les services d’arrière-plan peuvent faire paraître un trafic ordinaire inhabituel. Le blocage automatique sur la base d’un domaine ou d’une étiquette peut interrompre un travail légitime.

Les bases de données de classification vieillissent aussi rapidement. De nouveaux services d’IA apparaissent, les fournisseurs renommant leurs produits, et les plateformes existantes ajoutent des fonctionnalités reposant sur des modèles. Les règles de détection qui dépendent de listes statiques de fournisseurs manqueront de nouveaux services et classeront mal les anciens.

Le chiffrement limite l’inspection réseau. Une passerelle peut souvent voir la destination et les métadonnées de connexion, mais elle ne peut pas toujours déterminer ce qu’un utilisateur a soumis. Le déchiffrement du trafic améliore la visibilité tout en créant des préoccupations en matière de confidentialité, de certificats, de performances et d’exploitation.

La surveillance des terminaux comble certaines lacunes, mais elle introduit des problèmes de couverture. Les sous-traitants, les systèmes non gérés, les appareils mobiles et les équipements spécialisés peuvent ne pas disposer d’agents. Les équipes de sécurité devraient signaler ces angles morts plutôt que de présenter une couverture partielle comme une certitude.

Il existe également un risque de gouvernance à assimiler la découverte au contrôle. Identifier un service d’IA n’explique pas si son utilisation était nécessaire, approuvée de manière informelle ou couverte par un accord existant. Les preuves techniques nécessitent un responsable métier comptable de la décision.

Le cadrage de KnowBe4 devrait donc être considéré comme un avertissement sur la visibilité, et non comme la preuve que chaque actif non identifié est dangereux. La source fournie n’établit ni une violation mesurée, ni un taux de détection universel, ni un produit unique qui résout le problème.

Le cadre de NIST apporte une retenue importante. Il demande aux organisations de prioriser les actifs selon leur classification, leur criticité, leurs ressources et leur impact sur la mission. Cela dissuade les équipes de consacrer le même effort à chaque anomalie.

Un programme mature mesure aussi les limites des capteurs. Chaque rapport devrait indiquer quels réseaux, terminaux, identités, comptes cloud et utilisateurs distants étaient couverts. Il devrait distinguer l’absence observée de l’absence réelle.

Les équipes de sécurité peuvent tester leurs propres affirmations par des exercices contrôlés. Elles peuvent introduire des appareils de test autorisés, des ressources cloud temporaires, des extensions de navigateur et des appels d’API d’IA. L’objectif est de mesurer quels signaux détectent chaque cas et à quelle vitesse les analystes le classent.

Ces tests devraient inclure des conditions d’échec. Que se passe-t-il lorsqu’un appareil reste silencieux ? Le trafic API personnel peut-il contourner une passerelle gérée ? Une fonctionnalité d’IA intégrée apparaît-elle comme un service distinct ? L’équipe peut-elle identifier le propriétaire de ses données ?

Les réponses varieront selon les environnements. Cette variation explique précisément pourquoi les organisations devraient résister aux affirmations de visibilité complète. L’objectif défendable est une couverture mesurable, des angles morts connus et des périodes d’incertitude constamment plus courtes.

Trois signaux montreront si la découverte réseau rattrape son retard

Le prochain test consiste à déterminer si les organisations peuvent transformer davantage de télémétrie en décisions plus rapides et plus sûres.

Le premier signal est la vitesse de rapprochement. Les équipes devraient mesurer l’intervalle entre la première observation et la classification. Un intervalle plus court indique que les processus de découverte, d’attribution des responsabilités et de réponse fonctionnent ensemble.

Cet indicateur devrait être séparé par catégorie d’actifs. Un appareil physique, une ressource cloud, une application SaaS et une intégration d’API d’IA nécessitent des preuves différentes. Les combiner dans une seule moyenne peut masquer des retards importants.

Si les délais de rapprochement diminuent tandis que les faux positifs restent maîtrisés, le modèle de preuves continues gagne en crédibilité. Si les files d’attente croissent plus vite que les analystes ne peuvent les traiter, les capteurs supplémentaires produisent du bruit plutôt qu’une visibilité utile.

Le deuxième signal est la couverture de l’IA intégrée et basée sur API. De nombreux contrôles commencent par des catégories de sites web parce que le trafic des navigateurs est plus facile à identifier. Cela laisse de côté les clés personnelles, les flux de travail des développeurs, les modèles locaux et les fonctionnalités d’IA intégrées aux plateformes approuvées.

Les organisations devraient comparer les découvertes issues des journaux réseau aux résultats provenant des terminaux, des autorisations d’identité, des systèmes cloud, des dépôts et des examens fournisseurs. De fortes divergences révèlent les domaines où l’architecture de surveillance reste incomplète.

Une couverture plus large renforcerait l’avertissement sous-jacent de KnowBe4 et la réponse proposée ici. Une dépendance persistante aux listes de domaines web affaiblirait les affirmations selon lesquelles les entreprises comprennent leur exposition à l’IA.

Le troisième signal est de savoir si la gouvernance devient plus rapide sans se rabattre par défaut sur un blocage universel. Les équipes de sécurité ont besoin de preuves que des services utiles peuvent passer d’inconnus à examinés puis approuvés. Elles ont également besoin de démontrer que les usages risqués peuvent être limités selon l’identité, la catégorie de données ou la fonctionnalité.

Un processus d’approbation sain devrait comporter des responsables nommés, des exigences de preuve définies et des délais de décision clairs. Il devrait proposer des alternatives plus sûres lorsqu’un service demandé ne peut pas respecter la politique. Le silence ou l’examen indéfini encourage les employés à contourner les contrôles.

Observez la manière dont les fournisseurs exposent les paramètres administratifs, les événements d’audit, les destinations des modèles et les choix de conservation des données. Une meilleure télémétrie produit facilitera la gouvernance de l’IA intégrée. Des journaux limités laisseront les clients dépendants d’indices réseau indirects.

La leçon plus large de cette actualité Google News n’est pas que chaque actif invisible est malveillant. C’est que chaque actif non résolu représente une question sans réponse sur la propriété, l’accès, les données et la responsabilité.

Les responsables de la sécurité devraient se poser une question pratique ce trimestre : combien de temps un appareil ou un service d’IA non enregistré peut-il fonctionner avant que quelqu’un lui attribue un responsable ? Ils devraient ensuite tester la réponse à l’aide d’exemples contrôlés.

Si le résultat se mesure en semaines, l’organisation a encore un problème d’inventaire statique. S’il se mesure en heures, avec des preuves documentées et des contrôles proportionnés, la découverte devient une capacité opérationnelle de sécurité.

La prochaine étape est claire. Sélectionnez un segment réseau, un environnement cloud et un flux de travail très utilisé par les employés. Rapprochez les enregistrements attendus de l’activité observée, classez chaque divergence et consignez les angles morts. Cet exercice révélera davantage qu’une nouvelle feuille de calcul d’inventaire et montrera si l’organisation peut réellement démasquer ce que ses contrôles existants ne parviennent pas à voir.