Des capacités de sécurité des données accrues signifient-elles une surcharge logicielle ? Repenser l’étendue de la plateforme

Plus n'est pas forcément mieux.

Plus de fonctionnalités peuvent signifier plus d'écrans, plus de paramètres, plus d'administration, plus de formation et plus de technologie que ce dont une équipe a réellement besoin.

Donc, quand un plateforme de sécurité des données couvre la découverte, la classification, DSPM, En matière d'identité et d'accès, de remédiation, de confidentialité, de gouvernance, de cycle de vie et de sécurité de l'IA, les acheteurs devraient se poser une question pertinente :

Avons-nous besoin de tout cela pour résoudre le problème qui se pose à nous ?

Parfois, la réponse est non.

Une équipe chargée de détecter les données sensibles exposées ne devrait pas avoir à lancer une transformation à l'échelle de l'entreprise avant de pouvoir réduire cette exposition. Une entreprise axée sur accès excessif Il ne devrait pas être nécessaire de rendre opérationnel chaque flux de travail relatif à la confidentialité, à la gouvernance ou à l'IA au préalable.
Mais il y a une autre question qui mérite d'être posée :

Si ces problèmes finissent par se croiser, combien de fois l'organisation devra-t-elle redécouvrir et réinterpréter les mêmes données ?

C'est là que réside la différence entre étendue de la plateforme et gonflement des produits Cela commence à avoir de l'importance.

L'expansion des fonctionnalités accroît les capacités sans réduire le travail utile. Une approche globale et pertinente permet aux organisations de résoudre un problème précis aujourd'hui tout en réutilisant les mêmes données lorsque le problème suivant se présente.

Qu’est-ce que le gonflement des plateformes de sécurité des données ?

Le phénomène de « gonflement » d'une plateforme de sécurité des données se produit lorsque des fonctionnalités supplémentaires augmentent les coûts, l'administration, la configuration, la formation, les efforts de mise en œuvre ou la charge cognitive sans apporter une valeur ajoutée suffisante aux résultats dont une organisation a besoin.

Cette définition est importante car l'étendue en soi n'est pas synonyme de gonflement.

Une plateforme peut offrir de nombreuses fonctionnalités tout en permettant à une équipe d'utiliser uniquement celles qui sont pertinentes pour résoudre son problème actuel. À l'inverse, un produit aux fonctionnalités limitées peut engendrer des coûts opérationnels importants si les organisations doivent le connecter à plusieurs autres technologies pour mener à bien une investigation ou une procédure de résolution.

La question utile n'est donc pas :

Combien de fonctionnalités possède cette plateforme ?

C'est:

Dans quelle mesure la plateforme crée-t-elle ou élimine-t-elle du travail supplémentaire lorsque les exigences évoluent ?

Pourquoi l'étendue d'une plateforme peut ressembler à un gonflement

L'objection est intuitivement logique.

Un acheteur commence par un problème précis : trouver des données sensibles, comprendre l’exposition aux risques, identifier les accès excessifs, protéger les données utilisées par l’IA ou remédier à un risque particulier.

L'acheteur découvre alors une plateforme capable de résoudre de nombreux problèmes connexes.

Cela peut susciter des inquiétudes légitimes :

• La mise en œuvre prendra-t-elle plus de temps ?
• Aurons-nous besoin de plus d'administrateurs ?
• Quel niveau de configuration devrons-nous maintenir ?
• Des capacités accrues nécessitent-elles davantage d'acteurs ?
• Les utilisateurs devront-ils apprendre des processus dont ils n'ont pas besoin ?
• Les procédures d'approvisionnement deviendront-elles plus difficiles à expliquer en interne ?
• Payons-nous pour des fonctionnalités que nous n'utiliserons pas ?
• Sommes-nous en train de résoudre le problème hypothétique de demain au lieu du problème réel d'aujourd'hui ?

Ces questions méritent des réponses.

L'erreur consiste à supposer que les réponses se déduisent simplement du nombre de capacités disponibles.

L'étendue des fonctionnalités, l'étendue de la plateforme et la portée de l'implémentation sont différentes.

Ces concepts sont souvent amalgamés en une seule idée.

Ils ne devraient pas.

Vous ne devriez pas avoir à déployer tous vos moyens pour résoudre un seul problème.

Voici le test le plus simple pour savoir si l'ampleur est devenue excessive.

Supposons que l'objectif immédiat soit d'identifier les données sensibles faisant l'objet d'un accès excessif.

L'organisation a besoin des capacités nécessaires pour découvrir les données pertinentes, les classer, comprendre les accès, identifier les expositions significatives, hiérarchiser le problème et prendre les mesures appropriées.

Il ne devrait pas être nécessaire de rendre opérationnel chaque flux de travail relatif à la confidentialité, processus de gouvernance, politique de conservation des données ou contrôle de l'IA avant de pouvoir résoudre ce problème de sécurité.

La mise en œuvre initiale devrait suivre le résultat initial.

Commencez par le problème. Élargissez-le lorsqu'un autre problème justifie un élargissement.

Cette distinction permet à une entreprise de choisir une plateforme évolutive sans transformer le premier projet en une transformation pluriannuelle.

La question plus pertinente : qu’est-ce qui est réutilisé ?

L'étendue de la plateforme devient plus intéressante lorsque plusieurs fonctionnalités reposent sur la même intelligence sous-jacente.

Considérez le travail nécessaire pour comprendre une donnée d'entreprise :

Où est-il?

Qu'est-ce que c'est?

Est-ce sensible ?

À qui appartient-il ?

Qui ou quoi peut y accéder ?

Comment est-il utilisé ?

Quelles politiques s'appliquent ?

L'organisation devrait-elle encore le conserver ?

Un système d'IA peut-il le récupérer ?

Que doit-il se passer lorsque l'organisation identifie un risque ?

Si chaque nouveau projet de sécurité, de confidentialité, de gouvernance, d'identité, de cycle de vie ou d'IA doit répondre à ces questions indépendamment, l'organisation paie sans cesse pour la même compréhension.

Cela crée un autre type de gonflement.

La question architecturale essentielle n'est pas de savoir combien de modules existent, mais combien de fois l'organisation doit redécouvrir la même vérité.

L'intelligence des données partagées change la valeur de l'étendue.

Une plateforme de base efficace permet à différents flux de travail d'exploiter un contexte partagé plutôt que de le reconstruire.

La découverte permet d'identifier où se trouvent les données. Classification Ces données permettent de déterminer ce qu'elles représentent. L'identité et le contexte d'accès indiquent qui peut y accéder. L'activité apporte des informations sur leur utilisation. La propriété et la traçabilité fournissent un contexte métier et de gouvernance. Les politiques et le cycle de vie influencent les actions à entreprendre.

Ces renseignements peuvent ensuite étayer différentes décisions.

Une équipe de sécurité peut l'utiliser pour prioriser les vulnérabilités. L'équipe chargée de la protection des données peut s'en servir pour comprendre les données personnelles. L'équipe de gouvernance peut l'utiliser pour définir la propriété et les politiques. Les équipes d'identité peuvent l'utiliser pour comprendre les accès effectifs. Les équipes d'IA peuvent l'utiliser pour déterminer quels modèles, copilotes, systèmes RAG ou agents peuvent atteindre.

Les flux de travail restent différents.

Il n'est pas nécessaire de recommencer à zéro à chaque fois pour comprendre les données sous-jacentes.

Pour une analyse plus approfondie de cette architecture, voir Que devrait réellement signifier la sécurité, la confidentialité et la gouvernance unifiées des données ?.

Il existe aussi un phénomène appelé gonflement des outils.

L'ajout excessif de fonctionnalités attire l'attention car il est visible à l'intérieur d'un produit.

La prolifération des outils peut être plus difficile à repérer car les organisations la répartissent dans toute leur pile technologique.

Un produit à la portée ciblée peut résoudre un problème de manière élégante. C'est parfois exactement ce dont une organisation a besoin.

Mais à mesure que les exigences augmentent, l'organisation peut ajouter un autre outil pour l'accès, un autre pour la confidentialité, un autre pour l'IA, un autre pour le cycle de vie, un autre pour l'activité et un autre pour la remédiation.

Prise isolément, chaque technologie peut paraître simple.

L'architecture, peut-être pas.

L'utilisation accrue d'outils peut engendrer des intégrations, des inventaires distincts, des classifications différentes, des politiques incohérentes, des relations supplémentaires avec les fournisseurs, une administration séparée, un stockage dupliqué et davantage de transferts entre les équipes.

Cela ne signifie pas pour autant que la consolidation soit toujours la bonne solution.

Cela signifie que les acheteurs doivent évaluer les deux formes de ballonnement.

Des capacités accrues impliquent-elles une mise en œuvre plus longue ?

Pas nécessairement, mais les acheteurs devraient le tester.

La portée de la mise en œuvre dépend de ce que l'organisation entend opérationnaliser, des systèmes impliqués, de l'architecture de déploiement, des intégrations requises, de la couverture des données, de la configuration, des processus existants et du résultat recherché.

Une plateforme étendue peut devenir encombrante si l'activation d'une fonctionnalité crée des dépendances envers plusieurs autres.

Cela mérite d'être testé directement.

Vérifiez si le cas d'utilisation initial peut fonctionner de manière autonome. Identifiez les dépendances obligatoires. Déterminez les intégrations réellement nécessaires au premier résultat. Distinguez les fonctionnalités optionnelles des prérequis.

L'indicateur pertinent n'est pas la capacité totale de la plateforme, mais le travail nécessaire pour rendre opérationnelle la capacité dont vous avez besoin.

Les questions relatives à la rapidité de déploiement et au délai de rentabilisation méritent une évaluation distincte. Notre guide sur Délai de mise en valeur du DSPM examine plus en détail la couverture, le contexte, la priorisation, la remédiation et la rapidité de la décision.

Une plateforme large nécessite-t-elle davantage de parties prenantes ?

Une plateforme peut prendre en charge plusieurs fonctions organisationnelles sans exiger que toutes les personnes concernées participent à chaque projet.

Le modèle des parties prenantes devrait découler de la décision.

Si la sécurité doit limiter l'accès excessif aux données sensibles, les acteurs de la sécurité et de l'identité peuvent jouer un rôle central. La protection de la vie privée peut devenir pertinente lorsque les données soulèvent des questions réglementaires ou de finalité. La gouvernance peut s'avérer importante lorsque la propriété des données est incertaine. Les équipes chargées du cycle de vie des données peuvent intervenir lorsque la suppression constitue la solution appropriée.

Ces dépendances découlent du problème lui-même, et non simplement de la plateforme.

En réalité, une base de données commune peut réduire certaines frictions interfonctionnelles lorsque les parties prenantes doivent collaborer, car elles peuvent travailler à partir du même contexte de données.

Une plateforme doit mettre en relation les parties prenantes lorsque le problème nécessite une collaboration, et non pas exiger une collaboration simplement parce que la plateforme prend en charge plusieurs équipes.

Qu'en est-il du coût ?

L'étendue d'une plateforme ne la rend pas automatiquement économiquement efficace.

Les acheteurs doivent évaluer leurs besoins, l'utilisation qu'ils en feront, le fonctionnement de l'emballage, les exigences de mise en œuvre et les coûts administratifs récurrents.

Mais comparer les coûts uniquement au niveau du produit peut occulter des coûts situés ailleurs dans l'architecture.

Une évaluation plus complète peut inclure :

• coûts des logiciels et des abonnements
• services de mise en œuvre et services professionnels
• infrastructure
• administration
• développement et maintenance de l'intégration
• entraînement
• découverte ou classification des doublons
• transferts opérationnels
• effort d'enquête
• effort de remédiation
• outils futurs nécessaires pour les cas d'utilisation connexes

L'objectif n'est pas de justifier une plateforme plus importante.

Il s'agit de comprendre le modèle opérationnel total nécessaire pour produire le résultat.

Plus de fonctionnalités peuvent rendre une plateforme plus difficile à expliquer en interne.

Cette inquiétude est réelle.

Un acheteur cherchant à résoudre un problème de sécurité spécifique peut avoir du mal à obtenir un soutien interne si la technologie proposée est décrite comme une transformation majeure de la plateforme.

La solution n'est pas de déployer toutes ses capacités en premier.

Commencez par exposer le problème.

Au lieu de:

“ Nous avons besoin d’une plateforme pour la gestion des données et des protocoles (DSPM), la confidentialité, la gouvernance, l’identité, le cycle de vie, la sécurité de l’IA et la remédiation. ”

Commencez par :

“ Nous devons identifier les données sensibles faisant l’objet d’un accès excessif et réduire cette exposition. ”

Expliquez ensuite les capacités nécessaires pour atteindre ce résultat.

La valeur ajoutée d'une plateforme plus large peut avoir une incidence sur l'architecture, l'approvisionnement ou la planification future sans pour autant devenir la raison pour laquelle chaque partie prenante doit approuver le premier cas d'utilisation.

Achetez la plateforme adaptée au problème que vous devez résoudre. Évaluez l'architecture en fonction des problèmes que vous pourriez avoir à résoudre ultérieurement.

L'IA rend la réutilisation des plateformes plus importante

L'IA introduit de nouveaux systèmes et flux de travail, mais une grande partie du contexte d'entreprise sous-jacent existe déjà.

Les applications et agents d'IA interagissent toujours avec des données. Ils dépendent toujours des identités et des autorisations. Ils fonctionnent toujours selon des politiques de sécurité. Ils peuvent toujours exposer des informations sensibles. Les organisations ont toujours besoin de connaître la propriété, la provenance, l'activité et les mesures correctives des données.

Le problème de l'IA ne part donc pas de zéro.

Une organisation qui maîtrise déjà les données sensibles, l'identité, l'accès, la traçabilité, la propriété et les politiques peut réutiliser ces informations lors de l'évaluation. Sécurité des données de l'IA.

C’est l’une des raisons pour lesquelles l’architecture de la plateforme est importante au-delà du cas d’utilisation initial.

Le prochain problème de sécurité ne devrait pas obliger l'organisation à oublier tout ce qu'elle a appris en résolvant le précédent.

Comment les acheteurs doivent-ils évaluer l'étendue de la plateforme ?

Ne comptez pas les modules.

Choisissez un cas d'utilisation représentatif et analysez les exigences architecturales pour le résoudre.

La meilleure stratégie de plateforme commence par une approche ciblée, sans se focaliser uniquement sur les détails.

Il n'y a aucun mérite à acheter une fonctionnalité simplement parce qu'elle existe.

Il n'y a pas non plus d'intérêt à imposer systématiquement à chaque nouveau problème de données un nouvel inventaire, un nouvel exercice de classification, une nouvelle couche d'intégration et une nouvelle interprétation des données d'entreprise.

Une meilleure architecture favorise à la fois la concentration et la réutilisation.

Commencez par le résultat qui compte maintenant.

Déployez les moyens nécessaires pour atteindre ce résultat.

Vérifiez si cela fonctionne.

Puis, réutilisez cette base lorsqu'un autre besoin légitime se présente.

C'est très différent d'un déploiement global en une seule fois.

C’est également très différent de concevoir chaque achat comme si le problème d’aujourd’hui resterait isolé pour toujours.

L'élargissement des possibilités devrait réduire le travail répétitif, et non l'augmenter.

Une plateforme aussi large mérite d'être examinée de près.

Les acheteurs doivent vérifier si cela ajoute des dépendances, une configuration, une administration, des coûts, des parties prenantes ou des fonctionnalités inutiles au projet initial. Si tel est le cas, ces préoccupations sont légitimes.

Mais le nombre de fonctionnalités à lui seul ne peut pas répondre à cette question.

L'évaluation la plus utile examine ce que la plateforme requiert pour le problème à résoudre, le travail qu'elle élimine, les informations qu'elle réutilise et si les fonctionnalités supplémentaires restent optionnelles jusqu'à ce qu'elles deviennent pertinentes.

Cela permet de définir plus clairement la notion d'étendue utile :

L'étendue utile de la plateforme permet à une organisation de partir d'un résultat, de réutiliser ce qu'elle en apprend et de se développer sans avoir à reconstruire sans cesse sa base de données.

L'objectif n'est pas d'ajouter des fonctionnalités.

Cela représente moins de travail répétitif.

FAQ sur l'étendue de la plateforme de sécurité des données

Qu’est-ce que le gonflement des plateformes de sécurité des données ?

Le gonflement d'une plateforme de sécurité des données se produit lorsque des fonctionnalités supplémentaires augmentent les coûts, la configuration, l'administration, la formation, les efforts de mise en œuvre ou la charge cognitive sans apporter une valeur ajoutée suffisante aux résultats dont une organisation a besoin.

Une plateforme de sécurité des données étendue nécessite-t-elle une mise en œuvre étendue ?

Non. Le périmètre de la plateforme et le périmètre de la mise en œuvre sont différents. Les organisations peuvent commencer par définir un objectif de sécurité précis et mettre en œuvre uniquement les fonctionnalités et les intégrations nécessaires pour l'atteindre.

Quelle est la différence entre l'étendue de la plateforme et la prolifération des fonctionnalités ?

L'étendue de la plateforme décrit l'éventail des résultats connexes qu'une infrastructure commune peut prendre en charge. On parle de « surcharge de fonctionnalités » lorsque des fonctionnalités supplémentaires engendrent une charge opérationnelle sans valeur ajoutée suffisante. L'étendue est utile lorsque les équipes peuvent réutiliser des informations partagées sans activer ni administrer des fonctionnalités inutiles.

Un outil de sécurité spécialisé peut-il engendrer de la complexité ?

Oui. Un outil à portée limitée peut rester simple en interne tout en nécessitant des produits, des intégrations, des inventaires, des transferts manuels ou une réconciliation supplémentaires pour couvrir un flux de travail de sécurité plus large. Les organisations doivent évaluer la complexité à l'échelle de l'ensemble du modèle opérationnel plutôt que sur une seule interface.

L'étendue de la plateforme ralentit-elle la mise en œuvre ?

Pas automatiquement. La mise en œuvre dépend du cas d'utilisation, des intégrations requises, de l'architecture de déploiement, de la configuration, de la couverture des données et des dépendances. Les acheteurs doivent déterminer si les fonctionnalités non liées à la plateforme restent optionnelles lors de la mise en œuvre initiale.

Une plateforme de sécurité des données plus large nécessite-t-elle davantage d'acteurs ?

Pas nécessairement. L'implication des parties prenantes doit intervenir après la résolution du problème. Les équipes supplémentaires deviennent pertinentes lorsque la décision requiert leur expertise, leur appropriation, leur politique ou leur approbation, et non simplement parce que la plateforme prend en charge leurs cas d'utilisation.

Comment les organisations doivent-elles comparer le coût des plateformes de sécurité des données générales et spécifiques ?

Les organisations doivent évaluer le modèle opérationnel global, y compris les logiciels, la mise en œuvre, l'infrastructure, l'administration, les intégrations, la formation, les investigations, la correction, la détection ou la classification des doublons, ainsi que les outils supplémentaires nécessaires à l'atteinte des objectifs actuels et futurs.

Comment les acheteurs doivent-ils évaluer l'étendue d'une plateforme de sécurité des données ?

Commencez par un cas d'utilisation représentatif. Identifiez les fonctionnalités, les intégrations, la configuration, les parties prenantes et les tâches opérationnelles nécessaires à sa résolution. Déterminez ensuite si les cas d'utilisation futurs peuvent réutiliser les données recueillies sans contraindre le projet initial à adopter des fonctionnalités non pertinentes.