Page traduite et vérifiée automatiquement. La version anglaise fait foi. Certaines parties restent en anglais le temps que leur traduction soit vérifiée. Voir en anglais · Signaler une erreur de traduction
Le vocabulaire, en termes simples
Chaque terme indique ce qu'il est et pourquoi un praticien s'y intéresse. La deuxième ligne est la partie qui le rend utilisable. Gratuit à tous les niveaux d'adhésion, parce que le vocabulaire est la première barrière d'entrée dans ce métier et que ce n'est pas ce qu'il faut faire payer.
A B C D E F G H I J K L M N O P Q R S T V W Z
A
- Efficacité de la recertification des accès
-
La certification des accès est le processus périodique qui consiste à examiner les comptes actifs et leurs autorisations et à décider de façon délibérée si chaque compte doit conserver ses accès actuels : confirmer que l'accès est toujours approprié, réduire son périmètre lorsqu'il est devenu disproportionné et révoquer les accès qui ne sont plus nécessaires.
l’efficacité des certifications d’accès est importante en TPRM, car les certifications d’accès sont souvent citées comme un contrôle de gouvernance essentiel pour la gestion des accès des fournisseurs : la preuve que les accès sont régulièrement revus et confirmés comme appropriés.
- Efficacité des certifications d’accès : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments probants à demander plutôt que des assurances : le taux de révocation de la dernière campagne de recertification, et pas seulement le taux d’achèvement ; la confirmation que la plateforme de recertification empêche l’approbation en masse ; la description du suivi de la qualité de la recertification, adéquation du temps d’examen et répartition des décisions.
- Erreurs de configuration des politiques d’accès
-
Les erreurs de configuration des politiques d’accès sont des paramètres de contrôle d’accès qui ne reflètent pas correctement le modèle d’accès voulu pour un système, une ressource ou des données à un moment donné.
les erreurs de configuration des politiques d'accès sont importantes pour la TPRM parce que les fournisseurs qui détiennent des données de clients peuvent avoir des politiques d'accès au stockage, aux bases de données et aux applications qui étaient correctement configurées pour la sensibilité initiale de ces données, mais qui n'ont pas été mises à jour à mesure que les données ont évolué.
- Erreurs de configuration des politiques d'accès : les éléments probants
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : outil de CSPM et résultats de la dernière analyse ; processus reliant la reclassification des données à la revue des politiques ; documentation de la fréquence de revue des politiques d’accès.
- Revues des accès
-
Une revue des accès est une vérification périodique que les personnes ayant accès à un système en ont toujours besoin, effectuée par une personne compétente pour en juger, sur une population dont vous pouvez démontrer l’exhaustivité, avec un suivi des révocations jusqu’à leur achèvement. C’est le contrôle le plus souvent en échec dans les missions d’assurance, et il échoue d’une manière inhabituelle : la revue a lieu et pourtant elle ne passe pas.
tous les référentiels l'exigent, tous les auditeurs l'échantillonnent, et ses quatre modes de défaillance sont constants. La population était l'export d'un seul système et omettait les groupes, les comptes de service et le circuit de support du fournisseur. Le réviseur a approuvé quarante noms de droits qu'il ne pouvait pas lire. Rien n'a été révoqué, ce qui, après plusieurs cycles, signifie que personne ne s'est réellement impliqué. Et les décisions ont été consignées sans que les retraits soient jamais vérifiés.
- Responsabilité
-
L'article 5(2) du GDPR exige que le responsable du traitement soit responsable du respect des principes relatifs à la protection des données et soit en mesure de le démontrer. La responsabilité n'est pas un principe de plus parmi les sept ; c'est l'obligation de prouver les six autres. La documentation, les registres, les analyses et les politiques sont les moyens de construire cette preuve.
c’est pourquoi la documentation est une obligation et non une bonne pratique. Une organisation qui traite des données de manière licite mais ne peut pas démontrer son raisonnement a manqué au principe de responsabilité, même si tous les autres principes ont été respectés. Un bon comportement non documenté est mal apprécié lors d’une enquête, car l’enquêteur ne peut pas le distinguer de la chance.
- Décisions d’adéquation
-
Une décision d'adéquation est une constatation de la Commission européenne selon laquelle un pays tiers assure un niveau de protection des données essentiellement équivalent à celui de l'UE, ce qui permet aux données personnelles d'y être transférées sans autre mécanisme de transfert. Le Royaume-Uni, le Japon, la Suisse, le Canada pour les organisations commerciales et les États-Unis dans le cadre du Data Privacy Framework figurent parmi les pays couverts.
l'adéquation est commode et conditionnelle. Le Safe Harbour a été invalidé en 2015. Le Privacy Shield a été invalidé en 2020. À chaque fois, les transferts fondés sur la décision ont perdu leur mécanisme du jour au lendemain et les organisations se sont empressées de recourir aux clauses contractuelles types. Le Data Privacy Framework a déjà été contesté, et la décision concernant le Royaume-Uni comporte une clause d'extinction qui exige son renouvellement.
- Attaques adverses contre l'IA
-
Les attaques adverses sont importantes pour la TPRM parce que les modèles d'IA que les fournisseurs déploient pour des décisions lourdes de conséquences (authentification de documents, vérification d'identité, détection de la fraude, contrôle qualité) peuvent présenter des vulnérabilités adverses que les indicateurs standard de précision sur les jeux de référence ne révèlent pas.
les attaques adverses sont importantes en TPRM, car les modèles d’IA que les fournisseurs déploient pour des décisions lourdes de conséquences (authentification de documents, vérification d’identité, détection de la fraude, contrôle qualité) peuvent présenter des vulnérabilités adverses que les indicateurs de précision des bancs d’essai habituels ne révèlent pas.
- Attaques adverses contre l’IA : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : types d'attaques testés (boîte blanche, boîte noire, transfert) ; un fournisseur qui confirme une précision de 97% sur les jeux de référence doit être interrogé sur la robustesse face aux attaques adverses. La précision sur les jeux de référence décrit les performances sur des données de test standard. La robustesse face aux attaques adverses décrit les performances sur des entrées spécialement conçues pour exploiter le modèle. Les deux mesurent des performances. Elles ne mesurent pas la même chose.
- Exposition des clés API d'IA
-
L'exposition des clés API d'IA est le risque de sécurité créé lorsque les identifiants qui authentifient l'accès aux API des modèles d'IA (clés émises par les portails développeurs des fournisseurs d'IA, points de terminaison d'inférence et infrastructure de mise à disposition des modèles) sont générés, gérés, stockés et utilisés en dehors du programme de gestion des identifiants établi de l'entreprise.
L’exposition des clés API d’IA compte en matière de TPRM parce que les relations de l’entreprise avec ses fournisseurs d’IA, de plus en plus nombreuses à mesure que l’IA s’intègre dans toutes les fonctions de l’entreprise, génèrent une population croissante d’identifiants qui authentifient l’accès à des capacités d’IA sensibles et peuvent exposer le modèle du fournisseur aux schémas de requêtes et aux données de l’entreprise.
- Exposition des clés API d'IA : les éléments probants
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : inventaire des clés API actives de l'organisation ; périmètre d'autorisations de chaque clé émise ; capacité d'alerte en cas d'utilisation anormale des clés.
- Expansion de la surface d'attaque liée à l'IA
-
L'expansion de la surface d'attaque liée à l'IA est l'augmentation de l'exposition globale des données et de la vulnérabilité des systèmes d'une entreprise qui se produit à mesure que plusieurs fournisseurs et outils d'IA sont adoptés au fil du temps : chacun est évalué individuellement comme un risque acceptable, mais ensemble ils créent une surface de risque supérieure à la somme des évaluations individuelles.
l'expansion de la surface d'attaque liée à l'IA est importante pour la TPRM parce que l'entreprise qui évalue les fournisseurs d'IA isolément peut passer à côté du risque global créé par plusieurs fournisseurs d'IA qui accèdent collectivement à différents éléments du même univers de données.
- Expansion de la surface d'attaque liée à l'IA : les éléments probants
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments probants à demander plutôt que des assurances : la documentation du périmètre d’accès individuel aux données ; la connaissance du contexte d’exposition agrégée ; un fournisseur qui confirme un cadrage approprié des accès aux données doit être interrogé sur sa connaissance de l’exposition agrégée. Le cadrage individuel est approprié pour l’accès individuel. L’exposition agrégée exige la vue d’ensemble que les évaluations individuelles ne produisent pas.
- Biais de l'IA dans les décisions relatives aux risques
-
Les biais de l'IA dans les décisions relatives aux risques sont la distorsion systématique des évaluations des risques générées par l'IA, causée par des biais encodés dans les données d'entraînement, par des choix de conception du modèle ou par des boucles de rétroaction créées lorsque les résultats de l'IA influencent les futures données d'entraînement.
les biais de l'IA dans les décisions relatives aux risques sont importants pour la TPRM parce que la notation des risques fournisseurs par l'IA détermine de plus en plus des décisions importantes concernant les relations fournisseurs : profondeur de la diligence raisonnable, conditions contractuelles, intensité de la surveillance et hiérarchisation des fournisseurs.
- Biais de l’IA dans les décisions de risque : les preuves
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : analyse de l’intensité d’évaluation dans les données d’entraînement ; évaluation de l’impact disparate entre groupes de fournisseurs ; un fournisseur qui affirme l’objectivité de son IA doit être interrogé sur la précision selon les groupes de caractéristiques. L’objectivité confirme la cohérence. La précision selon les groupes confirme que cette cohérence reflète un risque réel plutôt que des habitudes d’évaluation historiques.
- Application de la conformité de l’IA
-
L'application de la conformité de l'IA est la capacité opérationnelle de garantir que les politiques de gouvernance de l'IA (exigences de revue, normes de déploiement, obligations de surveillance) sont réellement appliquées à tous les systèmes d'IA qui relèvent de leur champ, et pas seulement aux systèmes présentés pour revue par les canaux prévus.
l'application de la conformité de l'IA est importante pour la TPRM parce que les fournisseurs qui revendiquent une gouvernance complète de l'IA doivent être évalués sur la couverture de son application (la part de leurs déploiements d'IA réellement examinés dans le cadre de leur processus de gouvernance), et pas seulement sur le processus de gouvernance lui-même.
- Application de la conformité de l'IA : les éléments probants
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments probants à demander plutôt que des assurances : un inventaire de l’IA indiquant les systèmes revus par rapport au total des systèmes découverts ; l’intégration d’une revue IA dans les achats SaaS ; un fournisseur qui confirme l’existence d’un processus de gouvernance de l’IA doit être interrogé sur la couverture de son application. Le processus confirme le mécanisme de gouvernance. Le taux de couverture confirme la part du parc d’IA que le mécanisme atteint réellement.
- Écart entre conformité et sécurité de l'IA
-
L'écart entre conformité et sécurité de l'IA est la distinction entre la conformité d'un système d'IA aux réglementations générales en matière de protection des données et de sécurité (GDPR pour le traitement des données, SOC 2 pour les contrôles de sécurité, ISO 27001 pour la gestion de la sécurité de l'information) et sa conformité aux exigences propres aux systèmes d'IA qui prennent des décisions lourdes de conséquen
l'écart entre conformité et sécurité de l'IA est important pour la TPRM parce que l'entreprise qui déploie le système d'IA d'un fournisseur dans un cas d'usage réglementé hérite des obligations de conformité de ce cas d'usage, que la documentation de conformité du fournisseur couvre ou non ces obligations.
- Écart entre conformité et sécurité de l’IA : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : exemple d'explication individuelle au titre de l'article 22 ; évaluation du haut risque au titre du règlement européen sur l'IA ; un fournisseur qui confirme sa conformité au GDPR doit être invité à fournir l'exemple d'explication au titre de l'article 22. La conformité au GDPR couvre le traitement des données. La conformité à l'article 22 couvre la prise de décision automatisée. Même règlement, obligations différentes.
- Continuité et plan de sortie de l’IA
-
La planification de la continuité et de la sortie en matière d'IA est l'ensemble des pratiques qui permettent à une entreprise d'assurer la continuité de ses activités lorsqu'un modèle d'IA d'un fournisseur est retiré, qu'un fournisseur quitte le marché ou qu'une relation commerciale doit prendre fin, y compris, en particulier, la conservation des données d'entraînement, la documentation de l'étalonnage du modèle et de l'ingé
la planification de la continuité et de la sortie de l’IA est importante en TPRM, car la dépendance opérationnelle envers les modèles d’IA crée un risque de continuité d’activité que la planification de la continuité d’activité habituelle ne traite pas.
- Continuité et plan de sortie de l’IA : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : engagement d'assistance à la transition (données d'entraînement et ingénierie des variables) ; portabilité des données dans un format réutilisable ; un fournisseur qui confirme les bonnes performances de son modèle d'IA doit être interrogé sur le préavis de retrait et l'assistance à la transition. Les performances confirment la valeur de la dépendance. Le préavis de retrait et l'assistance à la transition déterminent le coût de son démantèlement sous la pression du temps.
- Problèmes de traçabilité des données d’IA
-
Le lignage des données d'IA, dans le contexte des opérations de sécurité, décrit le parcours complet que suivent les signaux, alertes et renseignements de sécurité depuis leur génération par les systèmes de détection fondés sur l'IA, à travers les processus de traitement, de priorisation, d'escalade et de réponse qui déterminent comment et quand les humains y donnent suite.
le lignage des données d'IA dans les opérations de sécurité est important pour la TPRM parce que le résultat en matière de sécurité du déploiement de la surveillance de sécurité par l'IA d'un fournisseur dépend du parcours complet de la détection à la réponse, et pas seulement de la capacité de détection de l'IA.
- Problèmes de lignage des données d'IA : les éléments probants
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : délai attendu entre détection et investigation pour les alertes critiques hors heures ouvrées ; temps moyen d’investigation suivi comme indicateur ; processus d’escalade hors heures ouvrées pour les alertes critiques liées à l’IA.
- Risques de conservation des données par l’IA
-
Les risques liés à la conservation des données par l’IA sont les risques de sécurité, de conformité et juridiques découlant de la conservation des données que les utilisateurs saisissent dans les systèmes d’IA, en particulier le risque que des informations sensibles, réglementées ou juridiquement protégées, téléversées dans un assistant d’IA, soumises sous forme de requête à une IA ou traitées par un pipeline d’IA, soient conservées par le fournisseur d’IA ou
les risques de conservation des données par l’IA sont importants en TPRM, car l’adoption informelle et rapide d’outils d’IA en entreprise crée un risque de conservation systématique pour des catégories de données sensibles (MNPI, données personnelles, informations couvertes par le secret professionnel, données de santé réglementées) que des employés téléversent individuellement vers des assistants d’IA sans conscience précise d
- Risques liés à la conservation des données par l’IA : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments probants à demander plutôt que des assurances : la durée de conservation du fournisseur pour le niveau d’offre actuel ; la communication de la durée de conservation du prestataire LLM ; l’engagement DPA à une conservation nulle ou configurable.
- Défis de l'explicabilité de l'IA
-
Les difficultés d’explicabilité de l’IA comptent en matière de TPRM parce que les exigences juridiques et réglementaires relatives à l’explication de l’IA sont nettement plus exigeantes que ce que les outils d’explicabilité actuels fournissent automatiquement.
Les difficultés d’explicabilité de l’IA comptent en matière de TPRM parce que les exigences juridiques et réglementaires relatives à l’explication de l’IA sont nettement plus exigeantes que ce que les outils d’explicabilité actuels fournissent automatiquement.
- Difficultés d’explicabilité de l’IA : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : exemple complet d'explication en langage clair destinée à une personne concernée ; documentation de la légitimité des variables à forte contribution ; évaluation de la conformité aux normes réglementaires en matière d'explication.
- Gouvernance de l’IA
-
La gouvernance de l'IA est l'ensemble des décisions, des responsables et des registres qui déterminent quels systèmes d'IA une organisation utilise, ce que chacun décide et à propos de qui, qui l'a approuvé et quelle supervision existe. Elle se distingue de la sûreté de l'IA, qui concerne le comportement des modèles eux-mêmes, et de la sécurité des modèles, qui concerne les attaques dont ils font l'objet. La gouvernance porte sur l'usage qu'en fait l'organisation.
demandez à une organisation combien de systèmes d'IA elle utilise et la réponse sera fausse d'un ordre de grandeur. Elle compte les deux modèles construits par l'équipe données et oublie la fonctionnalité du fournisseur qui note les tickets de support, l'outil de recrutement qui classe les candidats et l'assistant intégré à un produit dont personne n'a pensé qu'il revenait à adopter l'IA. La gouvernance commence par savoir ce qui est utilisé, et la plupart des programmes commencent ailleurs.
- Cadres de gouvernance de l'IA
-
Les lacunes des cadres de gouvernance de l’IA sont les écarts entre les processus de gouvernance de l’IA documentés et leur mise en œuvre opérationnelle : les réunions de comité qui n’ont pas lieu à la fréquence annoncée, les revues de modèles menées pour le déploiement initial puis omises lors des mises à jour suivantes, et les programmes de surveillance qui sont décri
les lacunes des cadres de gouvernance de l'IA sont importantes pour la TPRM parce que la documentation de gouvernance confirme l'intention du fournisseur.
- Cadres de gouvernance de l’IA : les preuves
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : procès-verbaux des trois dernières réunions du comité d’éthique de l’IA ; registres de revue des modèles pour les mises à jour les plus récentes ; confirmation que la validation des modèles s’applique aux mises à jour.
- Lacunes de gouvernance de l’IA
-
Les lacunes de la gouvernance de l’IA sont les insuffisances du cadre de gouvernance de l’IA d’une organisation (politiques, processus, comités d’examen et cadres de conformité) qui conduisent à déployer ou à maintenir en fonctionnement des systèmes d’IA sans supervision, transparence ou conformité adéquates aux exigences réglementaires applicables.
les lacunes de la gouvernance de l'IA sont importantes pour la TPRM parce que les obligations de conformité réglementaire de l'entreprise s'appliquent aux systèmes d'IA des fournisseurs qui exercent des fonctions réglementées dans les processus de l'entreprise, que ces systèmes aient été achetés ou développés en interne.
- Lacunes de la gouvernance de l'IA : les éléments probants
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : évaluation des risques élevés au titre du règlement européen sur l’IA pour les systèmes concernés ; un fournisseur qui affirme la maturité de sa gouvernance de l’IA doit être interrogé sur son alignement réglementaire actuel. La maturité de la gouvernance décrit le cadre. L’actualité réglementaire indique si le cadre reflète les réglementations actuellement applicables.
- Risque d'hallucination de l'IA dans les décisions
-
Dans le contexte des décisions d’IA lourdes de conséquences, le risque d’hallucination dépasse la confabulation des LLM pour englober la catégorie plus large des décisions d’IA prises avec assurance sur la base de schémas qui ne reflètent pas un raisonnement solide, juridiquement défendable ou éthiquement approprié.
le risque d'hallucination de l'IA dans les décisions est important pour la TPRM parce que l'entreprise qui déploie l'IA d'un fournisseur pour des décisions lourdes de conséquences hérite de la logique de décision du modèle, ainsi que des conséquences juridiques, réglementaires et réputationnelles si cette logique se révèle discriminatoire, arbitraire ou juridiquement indéfendable.
- Risque d'hallucination de l'IA dans les décisions : les éléments probants
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments probants à demander plutôt que des assurances : un fournisseur qui confirme l’explicabilité doit être invité à fournir un exemple d’explication en langage clair et une évaluation de la discrimination par indicateurs indirects. L’explicabilité technique identifie ce que le modèle a utilisé. L’explicabilité utile relie ce qu’il a utilisé aux raisons pour lesquelles il s’agit d’un motif légitime.
- Analyses d'impact de l'IA
-
Une analyse d'impact de l'IA établit, pour un système qui compte, ce qu'il décide et à propos de qui, ce qui pourrait mal tourner pour une personne plutôt que pour l'entreprise, comment il est classé au regard du droit applicable, et quels dispositifs de supervision et de surveillance existeront avant sa mise en service. Elle aboutit à des décisions, pas à un document, et elle est étroitement liée à l'analyse d'impact relative à la protection des données, qu'elle accompagne souvent.
les évaluations se présentent sous deux formes peu utiles. Un questionnaire de sécurité auquel on a ajouté le mot IA, qui interroge sur le chiffrement sans rien dire des personnes à l'encontre desquelles le système décide. Ou un document philosophique sur l'équité qui ne change rien. L'évaluation utile se situe entre les deux et pose les deux questions qui déterminent tout : que décide le système, et à propos de qui ?
- Lacunes de la réponse aux incidents d'IA
-
Les lacunes de réponse aux incidents d’IA sont les insuffisances du programme de réponse aux incidents d’une organisation qui laissent les incidents liés aux décisions des modèles d’IA (décisions d’IA préjudiciables, défaillances de modèles d’IA, manipulation de systèmes d’IA et manquements à la gouvernance de l’IA) sans procédures d’enquête définies, exigences de conservation des preuves, circuits d’escalade ou remédi
les lacunes de réponse aux incidents d’IA sont importantes en TPRM, car les produits d’IA des fournisseurs qui prennent des décisions lourdes de conséquences (crédit, assurance, emploi, soins cliniques) produiront tôt ou tard des décisions contestées, examinées ou portées en justice.
- Lacunes de la réponse aux incidents d'IA : les éléments probants
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : playbook d'incident d'IA ou équivalent ; circuit d'escalade vers une expertise externe en IA ; un fournisseur qui confirme une capacité complète d'IR doit être invité à fournir son playbook d'incident d'IA. L'IR traditionnelle couvre les incidents de cybersécurité. La réponse aux incidents d'IA couvre les incidents liés aux décisions des modèles. Les deux sont nécessaires pour les déploiements d'IA en entreprise.
- Fuite de données d’inférence d’IA
-
La fuite de données d’inférence d’IA est l’exposition des données présentes dans l’environnement d’inférence d’un modèle d’IA (la fenêtre de contexte, l’invite système enrichie par récupération, les sources de données connectées chargées comme contexte et les états de traitement intermédiaires du modèle) à une extraction par des entrées utilisateur, une manipulation des invites ou des techniques par canal auxiliaire
la fuite de données d’inférence d’IA est importante en TPRM, car une configuration sans conservation, bien que nécessaire, ne suffit pas à protéger les données sensibles qui transitent par l’environnement d’inférence de l’IA.
- Fuite de données lors de l'inférence de l'IA : les éléments probants
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : description du contenu de la fenêtre de contexte (ce qui est chargé au début de la session) ; résultats des tests d’injection de prompt en cours de session visant l’extraction du contexte ; résultats des tests de confidentialité de l’invite système.
- Journalisation et traçabilité de l'IA
-
La journalisation et la traçabilité de l’IA consistent à recueillir de manière exhaustive les informations nécessaires pour reconstituer la décision d’un système d’IA à tout moment après qu’elle a été prise, en particulier la version du modèle qui a pris la décision, les données d’entrée présentées au modèle au moment de la décision, les résultats intermédiaires du modèle et la décis
La journalisation et la traçabilité de l'IA sont importantes pour la TPRM parce que les contrôles réglementaires, les litiges et les recours contre des décisions individuelles exigent tous la capacité de reconstituer des décisions précises de l'IA à partir des enregistrements historiques.
- Journalisation et traçabilité de l’IA : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : démonstration de la piste d'audit des décisions historiques ; confirmation de la journalisation des variables d'entrée à un instant donné ; durée de conservation des journaux de décisions.
- Usage abusif de l’IA par les fournisseurs
-
L'usage abusif de l'IA par les fournisseurs recouvre les manières dont les systèmes d'IA déployés par les fournisseurs produisent des résultats préjudiciables, inéquitables ou opérationnellement erronés en raison de biais des données d'entraînement, de choix de conception du modèle et de contextes de déploiement qui conduisent l'IA à désavantager systématiquement certains segments de clientèle.
l’usage abusif de l’IA par les fournisseurs est important en TPRM, car les clients de l’entreprise interagissent avec les systèmes du fournisseur fondés sur l’IA, et les résultats produits par ces systèmes (priorisation du support, classification des services, acheminement des réponses) concernent les clients de l’entreprise, et pas seulement ceux du fournisseur.
- Usage abusif de l’IA par les fournisseurs : les preuves
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : résultats d’audit d’équité par segment de clientèle ; un fournisseur qui affirme de solides performances d’IA doit être invité à fournir des indicateurs par segment. La performance moyenne confirme que le système fonctionne pour la moyenne. Les indicateurs par segment révèlent s’il fonctionne de manière homogène pour tout le monde.
- Scénarios d’usage abusif de l’IA
-
Les scénarios d'usage abusif de l'IA dans le contexte de l'entreprise sont des situations où des outils d'IA approuvés et déployés à des fins métier légitimes sont utilisés, ou agissent eux-mêmes de façon autonome, d'une manière qui crée un risque juridique, éthique ou réputationnel qui n'a pas été évalué lors du processus d'approbation.
les scénarios d'usage abusif de l'IA sont importants pour la TPRM parce que les outils d'IA de fournisseurs approuvés pour des fonctions légitimes peuvent disposer de capacités (collecte autonome de données, prise de décision automatisée, traitement à grande échelle) qui créent des risques juridiques et éthiques invisibles dans l'évaluation de sécurité, laquelle s'est concentrée sur la manière dont l'outil traite les données fournies par les utilisateurs.
- Scénarios d'usage abusif de l'IA : les éléments probants
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : divulgation des capacités de collecte autonome de données ; base juridique au titre du GDPR pour le traitement de données externes ; indications sur les exigences de transparence à l'intention des utilisateurs.
- Risque de la chaîne d'approvisionnement des modèles d'IA
-
Le risque de chaîne d’approvisionnement des modèles d’IA est la catégorie de risques découlant de la provenance, de la composition et de l’intégrité des composants d’un modèle d’IA, en particulier les données d’entraînement, l’architecture du modèle de base, le processus d’affinage et l’infrastructure utilisée pour développer et déployer le modèle.
le risque lié à la chaîne d’approvisionnement des modèles d’IA compte en matière de TPRM parce que les produits d’IA que les fournisseurs intègrent désormais aux flux de travail des entreprises ne sont pas des logiciels traditionnels : ils portent des informations sur les données sur lesquelles ils ont été entraînés, ils peuvent se comporter de manière inattendue lorsque des entrées déclenchent des biais ou des portes dérobées intégrés, et leur profil de risque dépend d’un
- Risque lié à la chaîne d’approvisionnement des modèles d’IA : les preuves
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : confirmation et contrôles de l’exclusion des données d’entraînement ; un fournisseur d’IA qui fournit un rapport SOC 2 doit aussi être invité à fournir la documentation des fiches de modèle, la provenance des données d’entraînement et l’évaluation des attaques par inférence. Le SOC 2 couvre l’enveloppe opérationnelle. La documentation du modèle couvre le risque de chaîne d’approvisionnement qu’elle contient.
- Contrôle des versions des modèles d’IA
-
Le risque lié au contrôle des versions des modèles d’IA englobe les risques de sécurité et opérationnels découlant de la gestion des versions de modèles d’IA en production, en particulier les risques créés lorsque les mises à jour des modèles de fondation, les correctifs de sécurité et les révisions de modèles sont retardés, appliqués de façon incohérente ou non suivis avec la même rigueur que les logiciels tradition
La gestion des versions des modèles d'IA est importante pour la TPRM parce que les produits d'IA que les fournisseurs déploient dans les environnements des entreprises reposent sur des chaînes de dépendances (modèles de fondation, infrastructure de mise à disposition, frameworks de ML) qui exigent des correctifs de sécurité continus.
- Gestion des versions des modèles d'IA : les éléments probants
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments probants à demander plutôt que des assurances : la version du modèle de fondation actuellement déployée par rapport à la dernière disponible ; le niveau de mise à jour des correctifs de sécurité, c’est-à-dire les correctifs en attente et leur classification de sécurité ; le processus de validation accélérée des correctifs de sécurité.
- Risques opérationnels de l'IA
-
Les risques opérationnels de l’IA sont les risques découlant du déploiement de systèmes d’IA dans des contextes opérationnels réels, où les caractéristiques de performance du modèle (précision, modes de défaillance, niveaux de confiance et biais systématiques) interagissent avec les hypothèses des processus métier, les niveaux de supervision humaine et les conséquences en aval d’une manière qui crée des ri
les risques opérationnels de l'IA sont importants pour la TPRM parce que les processus métier qui dépendent des produits d'IA des fournisseurs sont généralement conçus autour d'indicateurs de précision agrégés plutôt qu'autour des schémas d'erreurs systématiques.
- Risques opérationnels de l'IA : les éléments probants
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : rapports de précision segmentés par type ou complexité de dossier ; validation des hypothèses de processus métier au regard des schémas d'erreurs ; couverture par la revue humaine des segments à fort taux d'omission.
- Fuite de données dans les résultats de l'IA
-
La fuite de données dans les résultats de l’IA, dans le contexte des produits d’IA d’entreprise, recouvre deux dimensions de risque distinctes. La première correspond au sens traditionnel de la fuite de données : des données sensibles issues du contexte de l’IA, de son corpus d’entraînement ou de la base de connaissances connectée apparaissent dans des résultats accessibles à des personnes non autorisées.
la fuite de données dans les résultats de l’IA est importante en TPRM, car les produits d’IA que les fournisseurs déploient pour les travailleurs du savoir des entreprises (assistants de recherche, outils de rédaction de documents, outils de communication client, accélérateurs d’analyse) créent un risque systématique de confabulation dans les productions de ces travailleurs.
- Fuite de données dans les résultats de l’IA : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : évaluation du taux de confabulation dans le domaine concerné ; un fournisseur qui confirme la qualité de son assistance à la recherche par l'IA doit être interrogé sur l'évaluation du taux de confabulation et l'attribution des sources. La qualité des résultats confirme que le processus de génération fonctionne. L'évaluation du taux de confabulation confirme à quelle fréquence ce qu'il génère est exact.
- Vulnérabilités des plugins d’IA
-
Les vulnérabilités des plugins d’IA, dans le contexte des outils de sécurité fondés sur l’IA, sont les angles morts structurels et les limites opérationnelles des systèmes de détection fondés sur l’apprentissage automatique : non pas des défaillances dans la mise en œuvre de la technologie, mais des contraintes inhérentes au fonctionnement de l’apprentissage automatique supervisé, qui créent des écarts systématiques entre les taux de détec
les vulnérabilités des plugins de sécurité fondés sur l'IA sont importantes pour la TPRM parce que la surveillance de sécurité fondée sur l'IA est de plus en plus présentée comme la principale couche de détection, en remplacement ou en forte réduction de la revue par des analystes humains.
- Vulnérabilités des plugins d’IA : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : périmètre des techniques couvertes par le jeu de données de test ; confirmation de la couverture des techniques LOTL et de l'évasion adverse ; taux de faux positifs en production dans des entreprises comparables.
- Fiabilité de la notation des risques par l’IA
-
La fiabilité de la notation des risques par l'IA est la mesure dans laquelle un score de risque généré par l'IA prédit avec exactitude le risque qu'il prétend mesurer, ainsi que la disponibilité des métadonnées, des données d'étalonnage et de la quantification de l'incertitude qui permettent aux praticiens du risque d'évaluer si l'on peut se fier au score pour la décision précise qu'il sert à é
la fiabilité de la notation des risques par l’IA compte en matière de TPRM parce que des scores de risque considérés comme fiables alors qu’ils ne sont pas étalonnés, assortis d’un niveau de confiance quantifié ni suivis dans le temps produisent une allocation des ressources systématiquement erronée : trop d’attention portée aux fournisseurs à score élevé qui ne présentent pas réellement de risque élevé, trop peu aux fournisseurs à score faible qui présen
- Fiabilité de la notation des risques d’IA : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : données d'étalonnage par plage de scores ; intervalle de confiance ou quantification de l'incertitude ; évolution historique des scores, sur six mois au minimum.
- Surveillance de la sécurité par l'IA
-
Une surveillance de sécurité de l'IA complète exige non seulement que le programme de surveillance rende compte de ce qu'il détecte, mais aussi qu'il rende compte honnêtement de ce qu'il ne détecte pas, des domaines où sa confiance de détection est plus faible et des activités des analystes humains nécessaires pour compenser les limites de l'IA.
une surveillance complète de la sécurité de l’IA compte en matière de TPRM parce que l’assurance de sécurité qu’apportent les rapports de surveillance dépend de la fidélité avec laquelle ces rapports représentent à la fois les capacités et les limites du programme.
- Surveillance de la sécurité de l’IA : les preuves
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : déclaration des lacunes de couverture dans les rapports de surveillance ; déclaration des variations de confiance par catégorie d’alerte ; un fournisseur qui remet des rapports hebdomadaires de surveillance par l’IA doit être invité à y ajouter une section sur les limites. Les indicateurs de performance décrivent ce qui fonctionne. La déclaration des limites décrit ce que les indicateurs de performance ne montrent pas. Les deux sont nécessaires pour un rapport de surveillance de sécurité honnête.
- Lacunes des tests de sécurité de l’IA
-
Les lacunes des tests de sécurité de l’IA sont les omissions dans le programme de tests de sécurité d’un fournisseur qui laissent le modèle d’IA lui-même, par opposition à l’infrastructure, à l’application et aux contrôles opérationnels qui l’entourent, non testé face aux catégories d’attaques spécifiques auxquelles les systèmes d’IA sont vulnérables.
les lacunes des tests de sécurité de l'IA sont importantes pour la TPRM parce que les preuves d'assurance de sécurité que les fournisseurs présentent pour leurs produits d'IA couvrent souvent de manière exhaustive les dimensions de sécurité traditionnelles tout en laissant les dimensions de sécurité propres à l'IA totalement non évaluées.
- Lacunes des tests de sécurité de l’IA : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : preuves de tests de sécurité propres à l'IA (entrées adverses, injection de prompt) ; résultats des exercices de red team sur l'IA ; un fournisseur qui fournit des preuves SOC 2, de tests d'intrusion et de SDLC doit être invité à fournir des preuves de tests propres à l'IA en tant que catégorie distincte. Les preuves traditionnelles couvrent l'enveloppe. Les tests de l'IA couvrent le modèle. Les deux sont nécessaires.
- Dépendances de la chaîne d'approvisionnement de l'IA
-
Les dépendances de la chaîne d’approvisionnement de l’IA sont les bibliothèques open source, les composants de modèles préentraînés, les utilitaires de traitement des données et les paquets de frameworks ML qui constituent la pile logicielle sur laquelle repose un système d’IA, et par lesquels des attaques de la chaîne d’approvisionnement peuvent compromettre le système d’IA sans s’en prendre au modèle lui-même.
Les dépendances de la chaîne d'approvisionnement de l'IA sont importantes pour la TPRM parce que la sécurité du système d'IA du fournisseur est limitée par la sécurité de chaque composant de sa pile de dépendances, et pas seulement par l'architecture du modèle et le processus d'entraînement.
- Dépendances de la chaîne d'approvisionnement de l'IA : les éléments probants
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : SBOM du pipeline d’IA incluant toutes les dépendances ML ; couverture de l’outil SCA pour toutes les dépendances d’IA ; format de sérialisation des modèles et confirmation d’un chargement sécurisé.
- Lacunes de détection des menaces par l’IA
-
Les lacunes de détection des menaces par l’IA sont les catégories de techniques, les schémas d’attaque et les comportements d’acteurs malveillants qu’une plateforme de surveillance de sécurité fondée sur l’IA ne détecte pas, soit parce que la couverture de détection de ces catégories n’a jamais été configurée, soit parce que les données d’entraînement de l’IA ne comprenaient pas d’exemples représentatifs de ces techniques, soit p
les lacunes de la détection des menaces liées à l’IA comptent en matière de TPRM parce que des tableaux de bord de détection entièrement au vert sont souvent présentés comme la preuve d’une couverture complète, et acceptés comme tels par les équipes TPRM qui examinent la posture de sécurité des fournisseurs.
- Lacunes de détection des menaces par l’IA : les preuves
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : délai entre le renseignement et la configuration pour les avis récents ; cartographie de couverture ATT&CK mise à jour au cours du dernier trimestre ; confirmation de la détection active des techniques précises signalées par l’ISAC.
- Évaluation des fournisseurs d’IA
-
L’évaluation d’un fournisseur dont le produit intègre de l’IA ajoute des questions que la revue de sécurité habituelle ne pose pas. Que décide le système, et à propos de qui. Sur quelles données a-t-il été entraîné, au niveau de description sur lequel le fournisseur acceptera de s’engager. Quelles informations de performance publie-t-il, et pour quelles populations. Quelle supervision le produit permet-il, et à quelle journalisation pouvez-vous accéder. Les réponses que vous ne pouvez pas obtenir sont des constats.
presque toute l'IA arrive intégrée à des produits de fournisseurs, si bien que la plupart des organisations évaluent le modèle de quelqu'un d'autre avec une visibilité limitée. Le questionnaire standard établit si le fournisseur chiffre les données et revoit les accès. Il n'établit pas si le classement de l'outil de recrutement a déjà été mesuré sur des candidats de plus de cinquante ans, et c'est la question que l'autorité de régulation vous posera, à vous et non au fournisseur.
- Risques d’enfermement propriétaire en IA
-
Les risques d’enfermement propriétaire auprès des fournisseurs d’IA apparaissent lorsque la dépendance opérationnelle d’une entreprise envers le modèle d’IA d’un fournisseur donné devient si profonde que les coûts de changement (en temps, en efforts de recalibrage, en refonte des flux de travail et en perturbations opérationnelles) deviennent prohibitifs.
L'enfermement chez les fournisseurs d'IA est important pour la TPRM parce que des dépendances profondes à l'IA créent un risque de concentration qui peut rester invisible jusqu'à ce qu'une perturbation impose une migration.
- Risques d'enfermement chez les fournisseurs d'IA : les éléments probants
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : préavis contractuel de dépréciation des API ; un fournisseur qui affirme de solides performances d’IA doit être interrogé sur son préavis de dépréciation et son aide à la migration. La performance confirme la valeur de la dépendance. L’aide à la migration et le préavis déterminent le coût de son démantèlement.
- Risques de sécurité de la revue de code assistée par l’IA
-
la sécurité de la génération de code par l’IA est importante en TPRM, car l’adoption d’assistants de codage IA dans les processus de développement des fournisseurs introduit peut-être des schémas de vulnérabilités que les outils de sécurité existants ne sont pas configurés de façon optimale pour détecter.
la sécurité de la génération de code par l’IA est importante en TPRM, car l’adoption d’assistants de codage IA dans les processus de développement des fournisseurs introduit peut-être des schémas de vulnérabilités que les outils de sécurité existants ne sont pas configurés de façon optimale pour détecter.
- Risques de sécurité de la revue de code assistée par l'IA : les éléments probants
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : déclaration d’adoption et gouvernance des assistants de codage IA ; évaluation de la couverture SAST pour les motifs générés par l’IA ; suivi de l’évolution du taux de constats depuis l’adoption.
- Risques de l’automatisation par l’IA
-
Les risques de l’automatisation pilotée par l’IA sont les conséquences opérationnelles, juridiques et réputationnelles qui surviennent lorsque des flux de travail d’IA autonomes exécutent des décisions et des actions à grande échelle sans intégration suffisante avec l’ensemble du contexte opérationnel, sans supervision humaine appropriée des cas limites, et sans contraintes limitant l’action autonome à d
les risques de l’automatisation par l’IA comptent en matière de TPRM parce que les fournisseurs qui utilisent l’automatisation par l’IA dans des flux de travail qui touchent l’entreprise (gestion des contrats, communications avec les clients, facturation, reporting de conformité) peuvent produire des erreurs opérationnelles en masse qui affectent les clients, les partenaires et les relations réglementaires de l’entreprise.
- Risques de l’automatisation par l’IA : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : revue préalable à l'exécution pour les communications de masse ; un fournisseur qui confirme les performances de son automatisation par l'IA doit être interrogé sur l'exhaustivité de l'intégration des données et sur la revue préalable à l'exécution. Les indicateurs de performance reflètent ce que l'automatisation fait correctement dans son périmètre. L'exhaustivité de l'intégration et les points de contrôle de revue limitent ce qu'elle fait incorrectement à grande échelle.
- Lassitude face aux alertes dans les écosystèmes
-
La lassitude face aux alertes est la dégradation de la qualité de l'analyse qui résulte de volumes d'alertes élevés dépassant la capacité d'analyse disponible pour chaque alerte.
la fatigue face aux alertes est importante en TPRM, car la qualité du SOC du fournisseur constitue la protection du client contre les menaces visant ses données, et la qualité d’un SOC soumis à un volume élevé d’alertes est nettement inférieure à celle d’un SOC dont le volume d’alertes est maîtrisé.
- Fatigue des alertes dans les écosystèmes : les preuves
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : volume d’alertes par analyste et par poste ; taux de faux positifs par catégorie d’alerte ; déploiement de l’automatisation SOAR et effet sur le volume d’alertes.
- Lacunes de priorisation des alertes
-
Les lacunes de priorisation des alertes sont les décalages entre des niveaux de gravité d’alerte statiques et le contexte de risque dynamique qui rend certaines techniques plus ou moins dangereuses selon le paysage actuel des menaces. Les niveaux de gravité des alertes sont attribués lors de la rédaction des règles, en fonction du profil de risque général de la technique à ce moment-là.
les lacunes de priorisation des alertes sont importantes en TPRM, car la rapidité de réponse du SOC à une alerte donnée dépend de son niveau de gravité, et un niveau de gravité qui ne reflète pas le contexte actuel des menaces produit des vitesses de réponse calibrées pour un paysage de menaces qui n’existe plus.
- Lacunes de priorisation des alertes : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : confirmation du circuit allant du renseignement sur les menaces à la priorisation ; mise à jour récente de la gravité déclenchée par le renseignement sur les menaces ; un fournisseur qui confirme des niveaux de service définis pour les alertes doit être interrogé sur la mise à jour, en fonction du renseignement actuel sur les menaces, des niveaux de gravité qui orientent les alertes vers ces niveaux de service. Les niveaux de service mesurent la conformité. Les niveaux de gravité déterminent si cette conformité est calibrée sur la menace actuelle.
- Tests de biais algorithmiques
-
Les tests de biais mesurent si les résultats d’un système diffèrent entre des groupes de personnes de manière significative, par exemple si les taux d’erreur, les taux d’approbation ou les scores varient en fonction d’une caractéristique protégée ou d’un indicateur indirect de celle-ci. Il n’est pas nécessaire que quiconque ait voulu la différence pour qu’elle existe. Un modèle entraîné sur des décisions historiques apprend les schémas de ces décisions, y compris ceux que personne ne défendrait.
c’est la mesure que la plupart des évaluations prétendent effectuer et que peu réalisent. Les performances mesurées globalement peuvent être excellentes alors que les performances pour un groupe sont médiocres, et les chiffres globaux masquent précisément le constat qu’un régulateur ou un plaignant mettra en avant. Les obligations de l’AI Act européen pour les systèmes à haut risque et la fonction Measure du cadre NIST supposent toutes deux que vous puissiez produire les chiffres par groupe.
- Techniques d’anonymisation
-
Les techniques d'anonymisation comprennent l'agrégation, qui présente des totaux plutôt que des individus ; la généralisation, qui remplace les valeurs précises par des fourchettes ; la suppression, qui retire les valeurs rares ; l'ajout de bruit, qui perturbe les valeurs ; et la confidentialité différentielle, qui borne ce que toute requête peut révéler sur un individu. Chacune réduit le risque de ré-identification de manière différente et avec un coût différent en termes d'utilité.
le critère juridique est de savoir si la ré-identification est raisonnablement probable par quelque moyen que ce soit, y compris par recoupement avec d'autres jeux de données. Un jeu de données qui paraît anonyme isolément peut être ré-identifié en le croisant avec une liste électorale, un profil sur un réseau social ou une violation antérieure. Ce sont les données auxiliaires qui rendent la ré-identification possible, et elles échappent au contrôle du responsable du traitement.
- Faiblesses d’authentification des API
-
L'authentification des API est l'ensemble des mécanismes par lesquels une API vérifie qu'une partie qui émet une requête est bien celle qu'elle prétend être et qu'elle est autorisée à effectuer la requête qu'elle effectue.
L’authentification des API est le contrôle qui établit la frontière de confiance entre votre organisation et la plateforme du fournisseur.
- Faiblesses d’authentification des API : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : documentation de la durée d'expiration des jetons et du processus de rotation (un délai et un processus, pas une déclaration de politique) ; documentation des portées OAuth propres à l'intégration (les portées réelles, pas les portées disponibles) ; confirmation que le périmètre des tests d'intrusion API inclut explicitement l'évaluation du mécanisme d'authentification.
- Détournement des identités API
-
Les identités API sont les identifiants (clés API, secrets clients, jetons OAuth et autres jetons d’authentification lisibles par machine) utilisés par les applications, les intégrations et les processus automatisés pour s’authentifier auprès des interfaces de programmation et des plateformes.
le détournement des identités API est important pour la TPRM parce que les clés API sont le principal mécanisme par lequel les applications des fournisseurs et les partenaires d'intégration accèdent aux plateformes des clients, et la gestion du cycle de vie de ces clés détermine si l'accès qu'elles confèrent reste dans le périmètre prévu ou s'il lui survit et le déborde.
- Détournement des identités API : les éléments probants
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : inventaire des clés API avec les dates de dernière utilisation et les applications associées ; confirmation de l'analyse des dépôts avec les résultats de la dernière analyse ; description de la surveillance de l'utilisation (comment une utilisation inattendue d'une clé est détectée).
- Tests de sécurité des API dans la CI/CD
-
les tests de sécurité des API sont importants pour la TPRM parce que les API que les fournisseurs d'entreprise exposent pour les intégrations (API REST, points de terminaison GraphQL, récepteurs de webhooks) sont des points d'accès aux données et aux fonctionnalités du fournisseur qui exigent des tests de sécurité propres aux API pour être évalués efficacement.
les tests de sécurité des API sont importants pour la TPRM parce que les API que les fournisseurs d'entreprise exposent pour les intégrations (API REST, points de terminaison GraphQL, récepteurs de webhooks) sont des points d'accès aux données et aux fonctionnalités du fournisseur qui exigent des tests de sécurité propres aux API pour être évalués efficacement.
- Tests de sécurité des API dans la CI/CD : les éléments probants
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : outil de test de sécurité propre aux API et couverture ; cas de test BOLA et approche de test multi-utilisateurs ; documentation de la couverture du OWASP API Top 10.
- Exposition de l’IA via les API
-
L'exposition de l'IA fondée sur des API est le risque pour les données et la sécurité créé lorsque le produit d'IA d'un fournisseur utilise une API de LLM tiers, comme GPT-4 d'OpenAI, Claude d'Anthropic, Gemini de Google ou Azure OpenAI, comme moteur d'inférence sous-jacent, ce qui fait transiter les données de l'entreprise soumises au produit du fournisseur chez le fournisseur de LLM tiers, par son infr
l'exposition de l'IA fondée sur des API est importante pour la TPRM parce que l'adoption rapide de produits de fournisseurs reposant sur des LLM a créé une nouvelle catégorie de risque lié aux quatrièmes parties que la plupart des programmes de TPRM n'ont pas traitée de façon systématique.
- Exposition de l’IA via les API : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : divulgation de l'infrastructure LLM sous-jacente, avec le fournisseur et le niveau de service ; couverture par l'DPA du traitement des données par le fournisseur de LLM ; confirmation de l'abonnement de niveau entreprise avec conditions renforcées.
- Journalisation et traçabilité des applications
-
La journalisation applicative dans un contexte de sécurité est la capture systématique des événements pertinents pour la sécurité : ceux qui permettent de détecter des attaques en cours, d'enquêter sur des incidents après coup et de démontrer le respect des obligations en matière de contrôle d'accès et de traitement des données.
la journalisation applicative dans les environnements des fournisseurs est pertinente pour la TPRM pour deux raisons distinctes, souvent confondues, mais dont les implications en matière de gouvernance diffèrent.
- Journalisation et traçabilité des applications : les éléments probants
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : réponse affirmative à la question du scénario à soixante jours, avec confirmation précise de la journalisation des accès aux données et de la capacité d’attribution des identités ; documentation de la politique de conservation des journaux indiquant la durée de conservation et l’exigence sur laquelle elle est calibrée ; confirmation de la journalisation des événements d’accès aux données au niveau applicatif, avec attribution de l’identité de l’utilisateur.
- Sécurité des registres d'artefacts
-
La sécurité des registres d'artefacts est importante pour la TPRM parce que les artefacts logiciels que votre entreprise reçoit de ses fournisseurs sont distribués via des registres dont la posture de sécurité détermine si l'artefact que vous téléchargez est bien celui que le fournisseur a publié.
la sécurité des registres d'artefacts est importante pour la TPRM parce que les artefacts logiciels que votre entreprise reçoit de ses fournisseurs sont distribués via des registres dont la posture de sécurité détermine si l'artefact que vous téléchargez est bien celui que le fournisseur a publié.
- Sécurité des registres d'artefacts : les éléments probants
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : registres des revues d'accès au registre d'artefacts et liste actuelle des comptes ; intégration du cycle de vie des identités pour l'accès au registre ; un fournisseur qui confirme la signature des artefacts doit être interrogé sur l'immuabilité du registre et ses contrôles d'accès. La signature confirme l'artefact au moment de la publication. L'immuabilité garantit que l'artefact téléchargé est bien l'artefact publié. Les contrôles d'accès déterminent qui peut remplacer un artefact modifiable.
- Assurance ou certification
-
Un SOC 2 est une attestation : un cabinet CPA exprime une opinion sur l’assertion de la direction concernant ses contrôles, selon une norme d’attestation. ISO 27001 est une certification : un organisme de certification accrédité certifie qu’un système de management est conforme à une norme publiée, à l’issue d’un audit au regard des exigences de cette norme. Ces termes désignent des mécanismes, des résultats et des autorités de régulation différents.
les acheteurs demandent une certification et reçoivent une attestation, ou l'inverse, et aucune des parties ne s'en aperçoit avant qu'une clause du contrat ne soit mise à l'épreuve. Un SOC 2 ne se renouvelle pas comme un certificat ; un certificat ISO ne contient pas de contrôles testés comme un rapport.
- Assurance ou validation
-
L'assurance est une confiance professionnelle, exprimée par un tiers indépendant, dans le fait qu'un système de contrôles fonctionne conformément à des critères définis, sur la base de preuves recueillies au moyen de méthodes d'évaluation structurées.
la distinction entre assurance et validation est importante en TPRM, car les risques spécifiques créés par les relations clients (les données particulières qu’elles exposent, les modes d’accès particuliers qu’elles permettent, les scénarios d’attaque les plus pertinents) ne relèvent souvent pas des critères des référentiels de conformité qui fournissent l’assu
- Assurance ou validation : les éléments probants
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : confirmation que le scénario précis a été testé ou non lors des évaluations existantes ; consentement à des tests de validation ciblés sur les scénarios non validés ; résultats des tests antérieurs si le scénario a été évalué.
- Temps de présence des attaquants via les fournisseurs
-
Le temps de présence des attaquants via les fournisseurs est important en TPRM, car l’exposition des données du client ne commence pas lorsque l’attaquant pénètre dans l’environnement du client, mais lorsqu’il accède à n’importe quel environnement de la chaîne d’approvisionnement menant aux données du client.
le temps de présence des attaquants via les fournisseurs est important pour la TPRM parce que l'exposition des données du client ne commence pas lorsque l'attaquant pénètre dans l'environnement du client, mais lorsqu'il obtient l'accès à n'importe quel environnement de la chaîne d'approvisionnement menant aux données du client.
- Temps de présence des attaquants via les fournisseurs : les preuves
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : MTTD empirique tiré d’incidents réels ; source de détection, SOC interne ou notification externe ; temps de présence le plus long observé lors des incidents récents.
- Attestation et certification
-
Une certification est délivrée par un organisme externe accrédité au regard d'un schéma défini, comme ISO 27001, à l'issue d'un audit, et elle peut être vérifiée auprès de l'émetteur. Une attestation est une déclaration à votre propre sujet, parfois signée par un dirigeant et parfois accompagnée d'un examen indépendant, comme dans le cas d'un rapport SOC 2, où un auditeur atteste la description de la direction. Les deux mots sont employés indifféremment dans les échanges commerciaux et ont des sens différents en cas de litige.
les acheteurs demandent si vous êtes certifié, et la réponse honnête, pour de nombreux programmes solides, est qu’ils détiennent un rapport d’attestation plutôt qu’un certificat. Les assureurs, les régulateurs et les services achats des grandes entreprises font tous la distinction. Se dire certifié lorsqu’on détient une attestation est une déclaration inexacte, et un acheteur compétent la repère dès le premier appel.
- Qualité des preuves d'audit
-
La qualité des preuves d'audit est la mesure dans laquelle les preuves fournies pour un contrôle de sécurité démontrent réellement ce qu'elles sont censées démontrer : que le contrôle est mis en œuvre, fonctionne efficacement et s'applique à tous les systèmes et utilisateurs pertinents, et pas seulement qu'un paramètre existe dans une configuration capturée à un moment donné.
la qualité des preuves est importante pour la TPRM parce que l'assurance apportée par une évaluation achevée n'est jamais plus solide que les preuves qui l'étayent.
- Qualité des preuves d’audit : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : confirmation de la couverture (tous les rôles confirmés ou capture d'écran de la politique complète) ; confirmation de l'actualité (les preuves reflètent l'état actuel) ; résultats de conformité automatisés de préférence aux captures d'écran manuelles.
- Limites du périmètre d'audit
-
Les limites du périmètre d'audit sont les frontières de ce qu'un audit a examiné et testé et de ce sur quoi il a conclu, et, par voie de conséquence, de ce que l'audit n'a pas examiné, pas testé ou sur quoi il n'a pas tiré de conclusions.
les limites du périmètre d'audit sont importantes pour la TPRM parce que les rapports SOC 2, les certificats ISO 27001 et les autres rapports d'audit de tiers sont les principales preuves de l'efficacité des contrôles dans les évaluations des fournisseurs, et ils comportent tous des limites de périmètre qui conditionnent ce que les conclusions du rapport permettent valablement d'affirmer.
- Limites du périmètre d’audit : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments probants à demander plutôt que des assurances : la déclaration des problèmes connus de qualité des contrôles pendant la période d’audit ; la description des changements importants postérieurs à la période ; la section des exceptions et la réponse de la direction du rapport le plus récent.
- Indépendance de l'auditeur
-
L’auditeur de service doit être indépendant des contrôles qu’il examine. Les normes d’attestation interdisent à l’auditeur de concevoir, de mettre en œuvre ou d’exploiter les contrôles, car un auditeur qui a construit le contrôle ne peut pas se prononcer de façon crédible sur son efficacité. L’indépendance est une condition préalable pour que l’opinion ait une quelconque valeur.
c’est pourquoi votre auditeur ne rédigera pas vos politiques, ne vous dira pas précisément quel contrôle mettre en œuvre et répondra à une question sur la remédiation par une description du critère plutôt que par une solution. Un cabinet qui propose à la fois du conseil en préparation et l’audit doit confier les deux à des équipes distinctes, et beaucoup refusent de faire les deux pour un même client.
- Prise de décision automatisée
-
L'article 22 du GDPR confère aux personnes le droit de ne pas faire l'objet d'une décision fondée exclusivement sur un traitement automatisé, y compris le profilage, produisant des effets juridiques les concernant ou les affectant de manière significative de façon similaire. Lorsque de telles décisions sont autorisées, par contrat, par la loi ou par consentement explicite, la personne a le droit d'obtenir une intervention humaine, d'exprimer son point de vue et de contester la décision.
les décisions de crédit, la présélection des candidats, la tarification des assurances et le blocage des fraudes font de plus en plus intervenir des modèles, et l’intervention humaine est souvent purement nominale. Un examinateur qui approuve tout ce que recommande le modèle, à raison de centaines par jour, n’intervient pas. La décision est, en substance, fondée exclusivement sur un traitement automatisé, quoi qu’en dise le schéma du processus.
B
- Tests des sauvegardes
-
Une sauvegarde est une copie. Une restauration est la preuve que la copie peut redevenir un système opérationnel dans le délai promis. Tester les sauvegardes signifie effectuer la restauration, selon un calendrier, vers une cible définie, vérifier le résultat et consigner ce qui s'est passé. La plupart des organisations effectuent des sauvegardes. Bien moins nombreuses sont celles qui en ont déjà restauré une dans des conditions proches de celles d'une véritable panne.
les sauvegardes sont le contrôle sur lequel tous les référentiels et tous les assureurs posent des questions, et l'assurance que la plupart des organisations offrent est que la tâche de sauvegarde s'est terminée. Une tâche terminée prouve que la copie a été écrite. Elle ne prouve rien quant au fait que la copie soit lisible, complète, à jour ou restaurable dans le délai visé, et les rançongiciels ont fait de la différence entre une sauvegarde et une restauration la différence entre une interruption et une fermeture.
- Contournements de la protection des branches et de la revue de code
-
Les contournements de la protection des branches comptent en matière de TPRM parce qu’ils représentent l’écart entre les contrôles de la chaîne d’approvisionnement logicielle qu’un fournisseur a documentés et ceux qui sont réellement appliqués en pratique.
les contournements de la protection des branches sont importants pour la TPRM parce qu'ils représentent l'écart entre les contrôles de la chaîne d'approvisionnement logicielle qu'un fournisseur a documentés et ceux qui sont réellement appliqués en pratique.
- Protection des branches et contournements de la revue de code : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : configuration de la protection des branches, y compris sa couverture des administrateurs ; liste des accès administrateur aux dépôts et date de la dernière revue ; surveillance des journaux d'audit pour les commits directs sur les branches protégées.
- Difficultés d’attribution des violations
-
L’attribution d’une violation est le processus consistant à déterminer qui a mené une attaque donnée : l’acteur de la menace, sa motivation, son affiliation organisationnelle et ses prochaines actions probables.
les difficultés d’attribution des violations sont importantes en TPRM, car la réponse du client à une violation chez un fournisseur ne doit pas être suspendue dans l’attente d’une attribution définitive issue de l’enquête technico-légale du fournisseur.
- Difficultés d'attribution des violations : les éléments probants
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : faits techniques confirmés, distincts de l'attribution (chronologie des accès, systèmes, types de données) ; tactiques, techniques et procédures observées pendant l'enquête, indépendamment de l'attribution ; évaluation préliminaire du périmètre indépendante de l'attribution.
- Notification des violations
-
Le GDPR impose au responsable du traitement de notifier à l'autorité de contrôle toute violation de données personnelles dans un délai de 72 heures après en avoir pris connaissance, à moins que la violation ne soit pas susceptible d'engendrer un risque pour les personnes. Lorsque le risque est élevé, les personnes concernées doivent également en être informées dans les meilleurs délais. Les sous-traitants doivent notifier leurs responsables du traitement dans les meilleurs délais.
la prise de connaissance intervient plus tôt que la confirmation. Les équipes attendent d’avoir une vision complète avant de notifier et manquent le délai, alors que le règlement autorise explicitement une notification par étapes : une notification initiale avec ce qui est connu, suivie d’informations complémentaires au fil de l’enquête. Le délai de 72 heures concerne le premier contact, et non le rapport final.
- Lacunes des simulations de violation
-
Les lacunes des simulations de violation sont les écarts entre ce que teste un exercice de simulation de violation et ce qu’exige un véritable incident de sécurité, plus précisément l’écart entre une simulation scénarisée et coopérative, où l’équipe IR est informée de chaque étape, et une violation réelle, où la détection est ambiguë, le périmètre incertain, l’attaquant actif et ad
les lacunes des simulations de violation sont importantes pour la TPRM parce que le rapport de simulation qui confirme la capacité d'IR au regard de critères définis peut tester un ensemble de capacités différent de celui qu'exige une violation réelle.
- Lacunes dans la simulation de violations : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments probants à demander plutôt que des assurances : la méthodologie de simulation, scénarisée ou axée d’abord sur la détection ; l’historique des exercices purple team ou en conditions réelles ; le MTTD et le MTTC issus des exercices adverses.
- Lettres de liaison
-
Une lettre de liaison, parfois appelée lettre de couverture de l’écart, couvre la période entre la fin de la période d’observation d’un rapport et la date à laquelle un client le lit. Elle affirme qu’aucun changement important n’est intervenu dans l’environnement de contrôle depuis la fin de la période. Elle est rédigée et signée par la direction du fournisseur.
les rapports sont toujours rétrospectifs. Si la période s’est terminée en septembre et que nous sommes en février, cinq mois ne sont pas couverts, et la lettre de liaison est le moyen habituel de combler cet écart sans attendre le prochain rapport.
- Contrôle d'accès défaillant dans les applications des fournisseurs
-
Le contrôle d'accès défaillant est l'incapacité d'une application à appliquer correctement les règles qui déterminent quels utilisateurs authentifiés peuvent accéder à quelles ressources, effectuer quelles actions et voir quelles données.
un contrôle d’accès défaillant dans l’application d’un fournisseur est particulièrement dangereux du point de vue du risque lié aux tiers, car il peut exposer les données de votre organisation à d’autres clients de la même plateforme, et vous exposer aux données d’autres clients, d’une manière qui engage votre responsabilité réglementaire quelle que soit l’intention.
- Contrôle d’accès défaillant dans les applications des fournisseurs : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments probants à demander plutôt que des assurances : une documentation du périmètre des tests d’intrusion incluant explicitement les tests IDOR et des scénarios d’élévation de privilèges ; la confirmation des tests d’isolation entre locataires pour les applications multilocataires, avec des preuves de la méthodologie ; la confirmation que l’autorisation est appliquée côté serveur, et non par un contrôle d’accès au niveau de la couche UI.
- Validation de l’intégrité de la compilation
-
La validation de l’intégrité des builds est l’ensemble des contrôles qui vérifient la fiabilité du processus de production des artefacts, c’est-à-dire la chaîne de preuves allant du code source revu au binaire déployé, qui démontre que chaque étape de la compilation a été réalisée comme prévu, par des systèmes autorisés, avec les entrées prévues et sans modification non autorisée
l'intégrité de la compilation est le contrôle qui comble l'écart laissé par la signature de code, l'écart entre « l'artefact a été signé avec la clé du fournisseur » et « l'artefact est une représentation fidèle du code source revu ». Pour les praticiens de la TPRM, c'est dans cet écart qu'opèrent les attaques de la chaîne d'approvisionnement les plus lourdes de conséquences.
- Validation de l’intégrité de la compilation : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : attestations de provenance SLSA ou références au journal de transparence pour les versions récentes ; confirmation des fichiers de verrouillage des dépendances, avec la politique de vérification des empreintes ; description de l'isolation de l'environnement de compilation (environnements éphémères ou équivalent).
- Intégrité du pipeline de compilation
-
L'intégrité du pipeline de compilation est importante pour la TPRM parce que l'éditeur de logiciels dont le pipeline est compromis produit des logiciels compromis, quelle que soit la robustesse de ses contrôles de sécurité en production.
l’intégrité du pipeline de build compte en matière de TPRM parce que l’éditeur de logiciels dont le pipeline est compromis produit des logiciels compromis, quelle que soit la robustesse de ses contrôles de sécurité en production.
- Intégrité du pipeline de compilation : les éléments probants
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : inventaire des intégrations tierces CI/CD avec le périmètre de leurs identifiants ; génération et niveau de provenance SLSA ; un fournisseur qui affirme la sécurité de son environnement de production doit être interrogé sur la sécurité de son pipeline de compilation. Les contrôles de l’environnement de production protègent ce qui s’exécute. Les contrôles du pipeline de compilation protègent la manière dont cela a été construit. L’attaque SolarWinds a contourné les premiers en compromettant les seconds.
- Analyse d'impact sur l'activité
-
Une analyse d’impact sur l’activité détermine, pour chaque service ou processus, ce qui se passe au fil du temps s’il est indisponible : quels clients sont touchés, quels revenus s’arrêtent, quelles obligations ne sont pas respectées et à partir de quel moment le préjudice devient inacceptable. Elle produit les objectifs de reprise par service et un classement de ce qu’il faut rétablir en premier lorsque tout tombe en panne en même temps.
des objectifs de reprise copiés d’un modèle ne protègent rien, et des plans de continuité qui traitent chaque service comme également urgent rétablissent le wiki pendant que les paiements sont à l’arrêt. Le BIA est l’étape qui produit les chiffres dont dépend tout le reste de la continuité, et c’est l’étape le plus souvent remplacée par un tableur d’estimations au hasard.
C
- CAIQ
-
Le Consensus Assessments Initiative Questionnaire est l'ensemble de questions standard de la Cloud Security Alliance, mis en correspondance avec sa Cloud Controls Matrix. Il est conçu pour les fournisseurs de services cloud, et beaucoup en publient une version remplie dans un registre public, ce qui signifie qu'une bonne partie de vos fournisseurs cloud y ont déjà répondu avant que vous ne le demandiez.
c'est l'ensemble standard le plus susceptible d'exister déjà chez un fournisseur SaaS ou d'infrastructure, c'est donc la première chose à rechercher avant de rédiger votre propre questionnaire. Il intervient aussi lorsqu'un acheteur vous en demande un : disposer alors d'un CAIQ rempli et à jour sur votre centre de confiance supprime toute une catégorie de demandes.
- Déclarations de périmètre de certification
-
La déclaration de périmètre d'une certification est la phrase figurant sur le certificat, ou dans la description du système du rapport, qui indique ce qui a réellement été examiné : quels produits, quels environnements, quels sites, quelles entités. Tout ce que la certification affirme s'applique dans les limites de cette phrase et à rien d'autre. Un acheteur qui lit les certificats lit la déclaration de périmètre avant le logo.
le rapport SOC 2 Type II sans anomalie d'un fournisseur couvrait sa plateforme principale. L'acheteur utilisait un produit plus récent du même fournisseur, lancé après la période d'observation et non mentionné dans la description du système. Le rapport était exact, sans réserve et sans rapport avec l'achat, et personne ne l'a remarqué parce que la vérification consistait à constater qu'un rapport existait.
- Gestion des changements selon CC8
-
Le critère CC8 exige que les modifications de l'infrastructure, des données, des logiciels et des procédures soient autorisées, conçues, développées, testées, approuvées et mises en œuvre de manière contrôlée. C'est le critère qui demande si les choses arrivent en production de façon délibérée.
le circuit normal des changements est généralement bien maîtrisé, car il est conçu, documenté et utilisé chaque jour. C’est le circuit d’urgence qui cède. Quelque chose est en panne, un correctif est nécessaire immédiatement, l’approbation habituelle est sautée et, une semaine plus tard, personne ne retrouve l’enregistrement. Les auditeurs le savent et échantillonnent délibérément les changements d’urgence.
- Invitation au statut de Charter Practitioner
-
Bonjour,
- Données des enfants
-
Le GDPR fixe à seize ans l'âge à partir duquel un enfant peut consentir aux services de la société de l'information, en permettant aux États membres de l'abaisser jusqu'à treize ans, et la plupart l'ont fixé entre les deux. Le traitement des données d'un enfant fondé sur le consentement en dessous de cet âge exige l'autorisation parentale. Des codes tels que l'Age Appropriate Design Code du Royaume-Uni imposent des obligations de conception aux services susceptibles d'être utilisés par des enfants, quel que soit le public visé.
les services qui ne visent pas les enfants les attirent quand même, et « ce n'est pas notre public » n'est pas une évaluation. Le critère est de savoir si les enfants sont susceptibles d'accéder au service, et une plateforme généraliste sans contrôle de l'âge est susceptible d'être utilisée par des enfants. Les obligations découlent de cette probabilité.
- Revues d'accès et retrait des accès dans la CI/CD
-
les revues d’accès CI/CD sont importantes en TPRM, car les comptes CI/CD orphelins sont des voies d’accès à l’environnement du pipeline qui existent sans justification métier active. Le compte d’un ancien employé est un identifiant qui a pu être compromis par hameçonnage ou vol d’identifiants sans qu’aucun employé actif ne remarque une activité suspecte.
les revues d’accès CI/CD sont importantes en TPRM, car les comptes CI/CD orphelins sont des voies d’accès à l’environnement du pipeline qui existent sans justification métier active.
- Revues d’accès et déprovisionnement CI/CD : les preuves
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : intégration du cycle de vie des identités pour le départ des employés ; processus de déprovisionnement des comptes de service et des comptes fournisseurs ; inventaire des accès CI/CD avec justification et responsable.
- Journalisation d'audit et observabilité de la CI/CD
-
la journalisation d’audit CI/CD est importante en TPRM, car la capacité du fournisseur à enquêter sur une compromission de la chaîne d’approvisionnement ou un incident de sécurité dans son pipeline dépend de la qualité et de la conservation de sa piste d’audit CI/CD.
la journalisation d’audit CI/CD est importante en TPRM, car la capacité du fournisseur à enquêter sur une compromission de la chaîne d’approvisionnement ou un incident de sécurité dans son pipeline dépend de la qualité et de la conservation de sa piste d’audit CI/CD.
- Journalisation d’audit et observabilité CI/CD : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : durée de conservation des journaux d'audit de la CI/CD ; stockage externe immuable des journaux d'audit ; exhaustivité des événements (contexte capturé avec les événements de déploiement).
- Défaillances de gestion des identifiants CI/CD
-
la gestion des identifiants de la CI/CD est importante pour la TPRM parce qu'elle détermine le rayon d'impact maximal d'une compromission du pipeline. Le fournisseur dont le pipeline utilise un seul compte de service doté d'identifiants de déploiement en production s'expose, en cas de compromission de n'importe quel pipeline, à un rayon d'impact correspondant à un accès complet à la production.
la gestion des titres d’authentification CI/CD compte en matière de TPRM parce qu’elle détermine le rayon d’impact maximal d’une compromission du pipeline.
- Défaillances de gestion des identifiants CI/CD : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : confirmation de la mise en œuvre de l'identité de charge de travail ou feuille de route ; limitation des identifiants de production aux seules étapes de déploiement ; audit des comptes de service portant sur le périmètre des identifiants.
- Sécurité des plateformes CI/CD : risques liés à GitHub Actions et à GitLab CI
-
Action communautaire : approuvé en v2.1. Mis à jour en v2.2 : nouvelle fonctionnalité.
la sécurité des plateformes CI/CD est importante pour la TPRM parce que les actions et composants qui s'exécutent dans les pipelines CI/CD des fournisseurs sont du code tiers qui s'exécute avec les identifiants du pipeline : le même modèle de menace que pour les dépendances applicatives, appliqué à l'infrastructure de compilation plutôt qu'à l'application elle-même.
- Sécurité des plateformes CI/CD : risques liés à GitHub Actions et à GitLab CI : les éléments probants
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : mise en œuvre de l'épinglage par SHA dans les fichiers de workflow ; liste des actions approuvées ou restrictions par éditeur ; un fournisseur qui confirme la sécurité de sa CI/CD doit être interrogé sur l'épinglage des actions et la gouvernance de leur approbation. L'épinglage des dépendances applicatives contrôle quel code s'exécute dans l'application. L'épinglage des actions contrôle quel code s'exécute dans le pipeline qui compile l'application.
- Sécurité CI/CD pour les secteurs réglementés
-
La sécurité de la CI/CD dans les secteurs réglementés est importante pour la TPRM parce que les certifications de conformité dans les secteurs réglementés peuvent ne pas refléter la conformité du pipeline CI/CD si leur périmètre n'incluait pas une évaluation rigoureuse des exigences propres à la CI/CD.
la sécurité de la CI/CD dans les secteurs réglementés est importante pour la TPRM parce que les certifications de conformité dans les secteurs réglementés peuvent ne pas refléter la conformité du pipeline CI/CD si leur périmètre n'incluait pas une évaluation rigoureuse des exigences propres à la CI/CD.
- Sécurité de la CI/CD pour les secteurs réglementés : les éléments probants
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : correspondance entre le pipeline CI/CD et les exigences réglementaires ; résultats de l'analyse des écarts et état de la remédiation ; preuves de conformité pour les contrôles propres à la CI/CD.
- Architecture de sécurité réseau dans le cloud
-
L’architecture de sécurité réseau dans le cloud est importante en TPRM, car la migration vers le cloud transfère souvent les charges de travail applicatives vers l’infrastructure cloud sans transférer la discipline de sécurité réseau qui régissait l’environnement sur site.
l'architecture de sécurité réseau dans le cloud est importante pour la TPRM parce que la migration vers le cloud transfère souvent les charges de travail applicatives vers l'infrastructure cloud sans transférer la discipline de sécurité réseau qui régissait l'environnement sur site.
- Architecture de sécurité réseau dans le cloud : les éléments probants
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : résultats de l'audit des groupes de sécurité ouverts à 0.0.0.0/0 ; un fournisseur qui confirme la sécurité de son cloud doit être interrogé sur la configuration de ses groupes de sécurité. Les groupes de sécurité cloud sont le principal contrôle de sécurité réseau dans les environnements cloud. Une règle 0.0.0.0/0 sur les ports d'administration expose les instances à l'ensemble d'Internet, quels que soient les contrôles de sécurité de la couche applicative.
- Sécurité du cloud
-
Dans le contexte du risque lié aux tiers, la sécurité du cloud ne concerne pas d’abord l’infrastructure du fournisseur de cloud : cette partie est largement prise en charge. Le risque réel tient à la manière dont votre organisation a configuré son environnement cloud et aux conditions dans lesquelles les fournisseurs sont autorisés à y opérer.
lorsqu’un fournisseur opère à l’intérieur de votre environnement cloud, le modèle traditionnel du risque lié aux tiers (évaluer les contrôles, recevoir une attestation, classer le rapport) s’effondre presque complètement.
- Sécurité du cloud : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : un ensemble d'autorisations documenté et défendable pour le rôle cloud du fournisseur, et non une capture d'écran d'AdministratorAccess ; la preuve qu'un outil CSPM ou équivalent est appliqué aux environnements qu'il gère ; un processus défini pour informer les clients des modifications de configuration effectuées dans leur environnement.
- Défaillances de l'isolation des charges de travail cloud
-
L’isolation des charges de travail dans le cloud est l’ensemble des mécanismes techniques qui empêchent une charge de travail (une application, un processus, un conteneur, une machine virtuelle) d’accéder à la mémoire, au stockage, au trafic réseau ou au contexte d’exécution d’une autre charge de travail s’exécutant sur la même infrastructure sous-jacente.
l'isolation des charges de travail est la garantie technique sur laquelle reposent les environnements mutualisés des fournisseurs.
- Défaillances de l'isolation des charges de travail cloud : les éléments probants
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : confirmation que les conteneurs privilégiés sont interdits ou strictement contrôlés dans les environnements de production ; un SLA de correction défini pour les vulnérabilités critiques de l’environnement d’exécution des conteneurs, idéalement de 24 à 72 heures pour les CVE critiques ; documentation du périmètre des tests d’intrusion confirmant que des scénarios d’isolation des charges de travail sont inclus.
- La signature de code et ses limites
-
Les limites de la signature de code sont importantes pour la TPRM parce que les entreprises qui exigent la signature de code comme contrôle de sécurité de la chaîne d'approvisionnement peuvent avoir un faux sentiment d'assurance quant à l'authenticité des logiciels signés.
les limites de la signature de code sont importantes pour la TPRM parce que les entreprises qui exigent la signature de code comme contrôle de sécurité de la chaîne d'approvisionnement peuvent avoir un faux sentiment d'assurance quant à l'authenticité des logiciels signés.
- La signature du code et ses limites : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : confirmation de la protection des clés par HSM ou équivalent ; un fournisseur qui confirme la signature de code doit être interrogé sur la protection des clés et la journalisation de transparence. La vérification de la signature confirme que la clé a signé l'artefact. La protection des clés empêche leur compromission. La journalisation de transparence détecte la compromission. Les trois sont nécessaires pour une assurance significative en matière de signature de code.
- Pratiques de signature de code
-
La signature de code est souvent citée dans les évaluations de sécurité des fournisseurs comme preuve de l'intégrité des artefacts et de la sécurité de leur distribution. Pour les praticiens de la TPRM, les attaques contre 3CX et SolarWinds montrent qu'un artefact signé avec la clé légitime d'un fournisseur peut tout de même être malveillant si l'environnement de compilation qui l'a produit a été compromis.
la signature du code est souvent citée dans les évaluations de sécurité des fournisseurs comme preuve de l’intégrité des artefacts et de la sécurité de leur distribution.
- Pratiques de signature du code : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : confirmation du stockage des clés de signature (stockage inviolable fondé sur un HSM ou équivalent) ; contrôles d'accès au pipeline de signature automatisé (clé de signature inaccessible aux développeurs individuels) ; attestations de provenance SLSA ou documentation équivalente de la provenance des compilations.
- Cadres de contrôles communs
-
Un cadre de contrôle commun est un ensemble unique de contrôles décrivant ce que votre organisation fait réellement, avec un identifiant stable pour chacun, mis en correspondance avec chaque référentiel au regard duquel vous êtes évalué. Au lieu d'un ensemble de contrôles SOC 2, d'un ensemble de contrôles ISO et d'un ensemble de contrôles HITRUST tenus par trois équipes, un seul ensemble de trente à quatre-vingts contrôles répond aux trois, et chaque élément de preuve est produit une seule fois.
c'est au deuxième référentiel que le coût du programme double, et il ne le devrait pas. L'essentiel de ce qu'exigent SOC 2, ISO 27001, NIST CSF et HITRUST correspond à la même pratique sous-jacente exprimée différemment : des accès accordés de façon délibérée et revus, des changements approuvés, des incidents traités, des fournisseurs évalués. Les différences portent sur l'accent mis et sur les preuves attendues, pas sur ce que vous faites le lundi matin.
- Contrôles compensatoires
-
Un contrôle compensatoire est une mesure alternative adoptée lorsqu'un contrôle requis ne peut pas être mis en œuvre tel que spécifié, en raison d'une contrainte réelle et documentée. Il doit répondre à l'intention de l'exigence initiale et offrir une rigueur comparable, et le raisonnement doit être consigné sous une forme qu'un évaluateur peut tester. Cela représente plus de travail que la conformité, pas moins.
chaque référentiel comporte des exigences que certaines organisations ne peuvent pas respecter à la lettre. Un système ancien qui ne prend pas en charge l’authentification multifacteur, un fournisseur qui ne peut pas signer une clause particulière, un processus que suppose la formulation d’un régulateur et que votre activité ne comporte pas. Le contrôle compensatoire est la voie légitime pour contourner chacune de ces situations, et c’est aussi la voie la plus souvent détournée pour éviter quelque chose de gênant.
- Contrôles complémentaires dans les contrats
-
Les CUEC décrivent ce qu'un client doit faire pour que les contrôles du fournisseur soient efficaces. De plus en plus, les contrats des fournisseurs renvoient directement aux CUEC, ce qui fait de leur mise en œuvre par le client une obligation contractuelle plutôt qu'une recommandation figurant en annexe.
si une violation remonte à un contrôle que le rapport du fournisseur désignait comme relevant de la responsabilité du client, le fournisseur renverra à cette liste, et au contrat qui l'intègre. La section CUEC est discrètement devenue le document qui détermine qui était en faute.
- Contrôles complémentaires des organisations sous-traitantes
-
Les contrôles complémentaires de l'organisation sous-traitante de services, ou CSOC, sont les contrôles que l'entreprise auditée suppose exécutés par son organisation sous-traitante de services. Sécurité physique du centre de données. Isolation entre locataires au niveau de l'hyperviseur. Élimination sécurisée du matériel. Ils sont énoncés dans le rapport et testés par personne dans ce rapport.
Les CUEC transfèrent la responsabilité vers vous, le client. Les CSOC la transfèrent vers le prestataire situé sous le fournisseur. Ensemble, les deux listes décrivent tout ce que l'opinion du rapport ne couvre pas, et lire les deux est le seul moyen de comprendre sur quoi porte réellement l'opinion.
- Contrôles complémentaires de l'entité utilisatrice (CUEC)
-
Les contrôles d’un fournisseur ne fonctionnent que si vous faites votre part, et les CUEC sont votre part, rédigée par le fournisseur. Ce sont les contrôles que le fournisseur suppose que vous appliquez pour que son environnement soit sécurisé : imposer la MFA aux utilisateurs que vous créez, revoir les accès que vous avez attribués, définir la valeur de conservation, tenir vos propres clés API hors du contrôle de version. Ils figurent dans une section du rapport SOC 2 que la plupart des lecteurs sautent.
un rapport SOC 2 est une preuve qui concerne le fournisseur. La liste des CUEC en est la seule partie qui vous concerne, et l'auditeur n'en a testé aucun élément, parce qu'il a été mandaté par le fournisseur et n'a aucune visibilité sur votre côté. Chaque CUEC est un contrôle dont le fournisseur a décliné la responsabilité, par écrit, et qu'il vous a renvoyé.
- Lacunes de l'automatisation de la conformité
-
Les plateformes d’automatisation de la conformité (Drata, Vanta, Secureframe et outils similaires) automatisent la collecte des preuves de conformité, la surveillance de l’efficacité des contrôles et l’évaluation de la préparation aux certifications de sécurité.
les lacunes de l'automatisation de la conformité sont importantes pour la TPRM parce que la surveillance automatisée de la conformité est de plus en plus citée par les fournisseurs comme preuve de l'efficacité continue des contrôles.
- Lacunes de l’automatisation de la conformité : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments probants à demander plutôt que des assurances : l’inventaire du périmètre d’intégration de la plateforme de conformité ; la confirmation du statut d’intégration des ajouts récents ; la confirmation de l’alignement avec le périmètre de la description de système SOC 2.
- Écart entre conformité et sécurité
-
La conformité est l’état de conformité à un ensemble défini d’exigences (une norme, une réglementation, un référentiel) pour un périmètre défini à un moment donné. La sécurité est la résistance continue aux menaces réelles sur l’ensemble de la surface d’attaque.
la distinction entre conformité et sécurité est importante pour la TPRM parce que les certifications de conformité sont les preuves de tiers les plus couramment utilisées dans les évaluations de sécurité des fournisseurs, et qu'elles présentent systématiquement les limites décrites.
- Écart entre conformité et sécurité : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : inventaire des systèmes adjacents hors périmètre connectés à l'environnement inclus dans le périmètre ; journal des changements postérieurs à l'évaluation avec analyse de leur impact sur la conformité ; identification des lacunes de périmètre et évaluation compensatoire.
- Conformité en tant que code dans la CI/CD
-
La conformité en tant que code est importante en TPRM, car les certifications de conformité ponctuelles (rapports PCI DSS QSA, rapports d’auditeur SOC 2, certifications ISO 27001) décrivent fidèlement l’état de conformité au moment de l’audit, mais ne peuvent pas confirmer l’état de conformité actuel si un temps important s’est écoulé.
la conformité en tant que code est importante pour la TPRM parce que les certifications de conformité à un instant donné (rapports PCI DSS QSA, rapports d'auditeur SOC 2, certifications ISO 27001) décrivent avec exactitude l'état de conformité au moment de l'audit mais ne peuvent pas confirmer l'état de conformité actuel si un temps important s'est écoulé.
- Conformité en tant que code dans la CI/CD : les éléments probants
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : mise en œuvre de la conformité en tant que code et couverture des référentiels ; détection et alerte en cas de dérive de conformité ; un fournisseur qui confirme une certification de conformité doit être interrogé sur la surveillance continue depuis la certification. La certification confirme la conformité au moment de l'audit. La surveillance continue de la conformité confirme que l'état de conformité a été maintenu. Les deux sont nécessaires pour une assurance de conformité à jour.
- Accès conditionnel : l’écart entre politique et application
-
Les lacunes de l'accès conditionnel sont importantes pour la TPRM parce que le contournement par l'authentification héritée sape l'exigence d'MFA, qui est la principale défense contre le vol d'identifiants.
les lacunes de l’accès conditionnel comptent en matière de TPRM parce que le contournement par l’authentification héritée sape l’exigence de MFA, qui constitue la principale défense contre le vol de titres d’authentification.
- Lacunes de l’accès conditionnel
-
L'accès conditionnel est un modèle de politique de sécurité dans lequel les décisions d'accès sont prises sur la base de plusieurs signaux contextuels, et pas uniquement sur la réussite de l'authentification.
les lacunes de l'accès conditionnel sont importantes pour la TPRM parce qu'elles déterminent si les contrôles d'accès qui régissent la manière dont les employés des fournisseurs et leurs propres utilisateurs internes accèdent aux données sensibles tiennent réellement compte des risques ou ne sont conformes qu'en apparence.
- Lacunes de l’accès conditionnel : les preuves
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : documentation des exigences de conformité des appareils (inscription au MDM exigée pour les accès sensibles) ; inventaire des signaux d’accès conditionnel (toutes les conditions évaluées dans les politiques d’accès) ; politique d’accès depuis les appareils personnels, explicitement interdit pour l’accès à la production.
- Consentement
-
Au sens du GDPR, le consentement doit être libre, spécifique, éclairé et univoque, exprimé par un acte positif clair, et aussi simple à retirer qu’à donner. Le responsable du traitement doit être en mesure de démontrer qu’il a été obtenu. Un consentement intégré aux conditions d’utilisation, recueilli au moyen de cases précochées ou imposé comme condition d’un service qui n’en a pas besoin n’est pas valable.
le consentement est la base la plus exigeante, et celle dont les défaillances sont les plus visibles. Une autorité de régulation peut examiner un formulaire d'inscription et voir si la case était précochée. Un consentement unique couvrant plusieurs finalités distinctes ne satisfait pas à l'exigence de spécificité. Un consentement qui ne peut pas être retiré sans appeler une ligne d'assistance ne satisfait pas à l'exigence de retrait.
- Registres de consentement
-
Un responsable du traitement qui se fonde sur le consentement doit être en mesure de démontrer que la personne concernée a donné son consentement. Cela suppose un enregistrement indiquant qui a consenti, quand, à quoi précisément, par quel mécanisme et quelle formulation lui a été présentée à ce moment-là. L’enregistrement doit survivre aux modifications de la formulation, car un consentement obtenu dans une version ne couvre pas les finalités ajoutées dans une version ultérieure.
la formulation change. Les politiques de confidentialité sont révisées, des finalités sont ajoutées, un consentement obtenu en 2021 pour des courriels de prospection sert plus tard de fondement à un profilage qui n’existait pas alors. Un enregistrement qui ne consigne que le fait du consentement ne peut pas montrer ce qu’il couvrait, et une autorité de régulation considérera qu’il ne couvre rien au-delà de ce qui peut être prouvé.
- Chaîne d’approvisionnement des images de conteneurs
-
Le risque lié à la chaîne d'approvisionnement des images de conteneurs est important pour la TPRM parce que les logiciels livrés sous forme de conteneurs incluent toute la pile logicielle du fournisseur, y compris les bibliothèques système et les composants du système d'exploitation, et pas seulement le code applicatif.
le risque lié à la chaîne d'approvisionnement des images de conteneurs est important pour la TPRM parce que les logiciels livrés sous forme de conteneurs incluent toute la pile logicielle du fournisseur, y compris les bibliothèques système et les composants du système d'exploitation, et pas seulement le code applicatif.
- Chaîne d'approvisionnement des images de conteneurs : les éléments probants
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments probants à demander plutôt que des assurances : les résultats d’analyse de toutes les couches des images de conteneurs ; la fréquence et le processus de reconstruction des images de base ; le SBOM du conteneur, y compris les bibliothèques système.
- Sécurité des registres de conteneurs dans la CI/CD
-
La sécurité des registres de conteneurs est importante en TPRM, car les images de conteneurs que les entreprises déploient depuis les registres des fournisseurs constituent le mécanisme de livraison de la chaîne d’approvisionnement logicielle pour les applications conteneurisées.
la sécurité des registres de conteneurs est importante pour la TPRM parce que les images de conteneurs que les entreprises déploient à partir des registres des fournisseurs constituent le mécanisme de livraison de la chaîne d'approvisionnement logicielle pour les applications conteneurisées.
- Sécurité des registres de conteneurs en CI/CD : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments probants à demander plutôt que des assurances : l’authenticité de l’espace de noms du registre, privé ou vérifié ; un fournisseur qui distribue des images de conteneurs doit être interrogé sur la signature des images et la vérification des espaces de noms. La signature des images apporte l’assurance d’authenticité. La vérification des signatures dans le pipeline du client l’impose. Les deux sont nécessaires pour fermer le vecteur du typosquatting et de la compromission de la distribution.
- Sécurité des conteneurs dans la CI/CD
-
La sécurité des conteneurs en CI/CD est importante en TPRM, car les logiciels livrés sous forme de conteneurs incluent l’ensemble de la pile logicielle (image de base, dépendances et application), et la gestion des vulnérabilités doit s’étendre à toutes les couches.
la sécurité des conteneurs en CI/CD est importante en TPRM, car les logiciels livrés sous forme de conteneurs incluent l’ensemble de la pile logicielle (image de base, dépendances et application), et la gestion des vulnérabilités doit s’étendre à toutes les couches.
- Sécurité des conteneurs en CI/CD : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : outil d'analyse des conteneurs et confirmation de la couverture de toutes les couches ; un fournisseur qui confirme l'analyse des conteneurs doit être interrogé sur la couverture des couches. L'analyse de la couche applicative couvre les dépendances ajoutées par le fournisseur. L'analyse de toutes les couches couvre l'environnement d'exécution. Les deux sont nécessaires pour une gestion complète des vulnérabilités des conteneurs.
- La réalité de la conformité continue
-
La conformité continue est une philosophie de conception de programme qui remplace les évaluations de conformité ponctuelles et périodiques par des vérifications automatisées et permanentes qui surveillent l’efficacité des contrôles entre les cycles d’évaluation formels. Le terme « continue » suggère une surveillance constante, un programme qui détecterait immédiatement toute défaillance de contrôle.
la réalité de la conformité continue est importante en TPRM, car l’expression « conformité continue » dans les descriptions de sécurité des fournisseurs donne une impression de surveillance en temps réel que la mise en œuvre opérationnelle ne permet pas toujours.
- Réalité de la conformité continue : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments probants à demander plutôt que des assurances : la fréquence de vérification des contrôles critiques ; la configuration du routage des alertes, file des incidents ou file de conformité ; le délai de réponse cible et réel en cas de défaillance critique de la conformité.
- Lacunes de la surveillance continue
-
La surveillance continue en TPRM est la collecte et l'évaluation permanentes de signaux sur la posture de sécurité des fournisseurs entre les cycles d'évaluation formels, à l'aide de données de notation de sécurité externes, de flux de renseignement sur les menaces, de divulgations publiques de vulnérabilités, de renseignements sur les entreprises et d'une veille des mesures réglementaires, afin de détecter les changements importants du r
les lacunes de la surveillance continue comptent en matière de TPRM parce que les autorités de contrôle des services financiers, de la santé et des infrastructures critiques attendent de plus en plus une surveillance continue dans le cadre des programmes de gestion du risque lié aux tiers, non pas en remplacement des évaluations périodiques, mais en complément permettant de détecter les changements importants entre les évaluations form
- Lacunes de la surveillance continue : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : documentation du processus de notification des changements importants ; politique de notification des changements de dirigeants clés en matière de sécurité ; notification des incidents de sécurité en dessous du seuil contractuel formel.
- Plateformes de surveillance continue
-
Les plateformes d'automatisation de la conformité se connectent à vos systèmes cloud, d'identité, de gestion des tickets et de code, vérifient en continu les configurations au regard des exigences de contrôle et recueillent automatiquement des preuves à mesure que les contrôles s'exécutent. Elles font apparaître les lacunes entre deux audits et suppriment une grande partie du travail manuel de collecte des preuves.
elles réduisent réellement le coût d'un SOC 2, et elles rendent la dérive des contrôles visible en quelques jours plutôt qu'au prochain audit. Pour une petite équipe, elles peuvent faire la différence entre un audit gérable et un audit qui ne l'est pas.
- Surveillance continue ou évaluation ponctuelle
-
La surveillance continue est importante parce que les événements de risque qui justifient le plus une réponse de TPRM (violations chez les fournisseurs, changements d'infrastructure, renouvellement des dirigeants) surviennent généralement entre deux évaluations plutôt qu'au moment commode du cycle de revue annuel.
la surveillance continue est importante parce que les événements de risque qui justifient le plus une réponse TPRM (violations chez les fournisseurs, changements d’infrastructure, renouvellement de la direction) surviennent généralement entre deux évaluations plutôt qu’au moment commode du cycle de revue annuel.
- Surveillance continue ou évaluation ponctuelle : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments probants à demander plutôt que des assurances : une obligation contractuelle d’autodéclaration assortie de déclencheurs précis ; le délai de notification selon les types de changements ; des exemples récents de notification proactive aux clients.
- Surveillance continue des fournisseurs
-
La surveillance continue consiste à déterminer quels événements modifient le risque d’un fournisseur, à surveiller ces événements et à faire en sorte que chacun déclenche une action définie, avec un responsable et un délai. Ce n’est pas un produit. Quatre éléments méritent d’être surveillés : les renseignements sur les violations concernant vos fournisseurs, l’expiration des documents sur lesquels vous vous appuyez, les changements chez le fournisseur, comme de nouveaux sous-traitants ultérieurs ou un nouveau propriétaire, et l’évolution de votre propre utilisation de ces fournisseurs.
les fournisseurs changent, et les changements ne sont pas annuels. Un fournisseur subit une violation en mars, son rapport expire en juin, il ajoute un sous-traitant ultérieur en août et il est racheté en octobre. Rien de tout cela n’apparaît dans une notation enregistrée en janvier, et c’est la notation que le registre affiche. Le quatrième déclencheur, l’extension de votre propre usage, est celui que les programmes manquent le plus souvent, car il se produit de votre côté et rien ne vient l’annoncer.
- Application des exigences contractuelles de sécurité
-
L’application des exigences contractuelles de sécurité est importante parce que la valeur des exigences contractuelles de sécurité en matière de réduction des risques dépend entièrement de leur mise en œuvre effective.
l'application des exigences contractuelles de sécurité est importante parce que la valeur de réduction des risques des exigences contractuelles de sécurité dépend entièrement de leur mise en œuvre effective.
- Application des exigences contractuelles de sécurité : les éléments probants
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : confirmation de conformité exigence par exigence, avec preuves ; preuves techniques pour les exigences de chiffrement et de contrôle d’accès ; documentation du processus de notification des incidents démontrant le respect du délai de 72 heures.
- Contrôles contractuels et contrôles réels
-
Les exigences contractuelles de sécurité définissent la posture de sécurité qu’un fournisseur doit maintenir comme condition de la relation commerciale. Elles établissent des obligations, définissent des normes et ouvrent des recours juridiques si les normes ne sont pas respectées.
la distinction entre contrôles contractuels et contrôles réels est importante pour la TPRM parce que les cadres réglementaires attendent de plus en plus des organisations non seulement qu'elles prévoient des exigences de sécurité dans les contrats fournisseurs, mais aussi qu'elles puissent démontrer que ces exigences sont respectées.
- Contrôles contractuels et contrôles réels : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments probants à demander plutôt que des assurances : des preuves de configuration technique pour les exigences contractuelles spécifiques ; la déclaration des exceptions, c’est-à-dire les écarts connus par rapport aux exigences contractuelles ; l’évaluation des chemins hérités au regard des exigences contractuelles.
- Duplication des contrôles
-
La duplication des contrôles est le maintien de plusieurs instances d'une même fonction de contrôle de sécurité au sein d'une organisation : outils distincts, processus distincts ou programmes distincts remplissant des fonctions de sécurité équivalentes avec un périmètre qui se chevauche ou est identique.
la duplication des contrôles est importante pour la TPRM parce que les fournisseurs qui maintiennent des contrôles en double peuvent afficher une posture de conformité qui semble complète (outils multiples, programmes multiples, défense en profondeur) alors que la couverture réelle est moins complète qu'il n'y paraît et que la charge opérationnelle est nettement plus élevée que celle d'un programme rationalis
- Duplication des contrôles : les preuves
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : registres d’identification et de rationalisation des doublons.
- Malentendus sur l'héritage des contrôles
-
L’héritage de contrôles consiste à s’appuyer sur une certification, un audit ou une évaluation réalisés par un tiers comme preuve que certains contrôles sont en place, plutôt que d’évaluer directement ces contrôles.
les malentendus sur l'héritage des contrôles sont importants pour la TPRM parce qu'ils créent un type particulier de fausse assurance : la confiance qui découle d'une certification authentique et reconnue qui ne couvre pas réellement les actifs pertinents pour le risque du client.
- Malentendus sur l'héritage des contrôles : les éléments probants
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : déclaration de périmètre de la certification ou description du système confirmant la couverture du service concerné ; liste des systèmes explicitement exclus de la description du système SOC 2 ; déclaration d’applicabilité ISO 27001 sur demande.
- Incohérences dans la cartographie des contrôles
-
La mise en correspondance des contrôles consiste à documenter les liens entre les contrôles de sécurité mis en œuvre et les exigences de plusieurs référentiels de conformité, normes réglementaires et exigences des clients.
les incohérences de mise en correspondance des contrôles sont importantes pour la TPRM parce que les documents de correspondance sont souvent fournis comme preuves de conformité dans les évaluations des fournisseurs, pour montrer que les contrôles du fournisseur satisfont aux exigences pertinentes pour le client.
- Incohérences de mise en correspondance des contrôles : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : description du contenu du contrôle traitant précisément le texte de l'exigence ; documentation du programme de formation ou des procédures montrant un contenu propre à l'exigence ; identification des lacunes si l'exigence n'est que partiellement satisfaite.
- Objectif de contrôle et activité de contrôle
-
Un objectif de contrôle est le résultat dont vous avez besoin. Une activité de contrôle est ce que quelqu'un fait réellement pour l'atteindre. « L'accès aux systèmes de production est approprié » est un objectif. « Chaque trimestre, les managers examinent une liste générée par le système des accès de leur équipe à la production et consignent, pour chaque entrée, l'approbation ou le retrait » est une activité. Les auditeurs testent les activités.
les matrices de contrôle énumèrent souvent des objectifs et les appellent des contrôles. Lorsque l'auditeur demande des preuves, il n'y a rien à produire, parce qu'un objectif ne laisse pas de trace. On ne peut qu'en discuter. La mission est au point mort pendant que l'activité est reconstituée a posteriori.
- Responsable du contrôle et responsable des preuves
-
Le responsable du contrôle est la personne qui répond du fonctionnement du contrôle tel qu’il a été conçu. Le responsable des preuves est la personne chargée de produire le document qui prouve qu’il a fonctionné. Ce sont souvent des personnes différentes, et le contrôle peut fonctionner parfaitement sans que la preuve soit jamais recueillie, parce que personne n’était chargé de la recueillir.
les audits échouent au moment du passage de relais entre les deux. Le responsable qui revoit les accès effectue la revue ; l’analyste censé exporter l’enregistrement est en congé ; l’auditeur demande la preuve ; il n’y en a pas. Le contrôle a fonctionné et l’audit consigne une exception.
- Profondeur des tests de contrôle
-
La profondeur des tests de contrôle est la mesure dans laquelle les tests de sécurité éprouvent les contrôles, systèmes et chemins d’attaque les plus pertinents au regard du modèle de menace réel, plutôt que les contrôles, systèmes et chemins d’attaque les plus faciles à tester dans un budget et un calendrier donnés.
la profondeur des tests de contrôle est importante en TPRM, car les rapports de tests d’intrusion figurent parmi les preuves les plus demandées et les plus pondérées dans les évaluations de sécurité des fournisseurs.
- Profondeur des tests de contrôle : les preuves
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : documentation du périmètre du test d’intrusion, incluant les systèmes dans et hors périmètre ; confirmation que les environnements API authentifiés sont dans le périmètre ; description de la méthodologie de test, composantes automatisées et manuelles.
- Test des contrôles et conception des contrôles
-
Un contrôle peut échouer de deux manières distinctes. Une défaillance de conception signifie que le contrôle, même parfaitement exécuté, n'atteindrait pas son objectif : la revue a lieu mais la population examinée est incomplète, ou l'étape d'approbation existe mais intervient après le déploiement. Une défaillance de fonctionnement signifie que le contrôle est bien conçu mais ne s'est pas exécuté comme prévu : la revue a été sautée le deuxième mois, l'approbation a été donnée après coup.
les auditeurs les signalent séparément, et la remédiation est entièrement différente. Une défaillance de conception exige de reconcevoir le contrôle. Une défaillance de fonctionnement exige de corriger les personnes et la fréquence. Traiter l'une comme l'autre gaspille la remédiation : former à nouveau les réviseurs ne corrige pas une population qui omettait les comptes de service, et reconcevoir la revue ne corrige pas un réviseur parti en congé sans remplaçant.
- Écart entre contrôle et mise en œuvre
-
L'écart entre contrôle et mise en œuvre est la différence entre ce qu'un contrôle de sécurité est censé faire, tel que spécifié dans la politique, la documentation du programme et les procédures, et ce qu'il fait réellement en pratique, tel que le reflètent les registres d'exécution, les données sur les constats et les indicateurs opérationnels.
les lacunes de mise en œuvre des contrôles sont importantes en TPRM, car la réduction du risque apportée par un contrôle de sécurité dépend entièrement de son état opérationnel, et non de son état sur le papier.
- Écart entre contrôle et mise en œuvre : les preuves
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : date du dernier test d’intrusion et nombre actuel de constats ouverts, avec l’ancienneté du plus ancien ; taux de respect du SLA de remédiation (pourcentage conforme, et non la politique de SLA) ; date de la dernière réunion du comité de sécurité.
- Défaillances de la réponse coordonnée
-
Les défaillances de la réponse coordonnée sont les ruptures de la réponse conjointe aux incidents qui surviennent lorsque les plans d'IR du fournisseur et du client contiennent des objectifs contradictoires, des procédures incompatibles ou des calendriers incompatibles qui ne peuvent être conciliés sans négociation pendant un incident actif. Chaque plan peut, pris isolément, être excellent dans sa conception comme dans son exécution.
les défaillances de la réponse coordonnée sont importantes pour la TPRM parce que l'issue pour le client d'un incident partagé dépend de la qualité de la réponse coordonnée, et une réponse coordonnée dont les conflits entre plans sont résolus en temps réel pendant un incident actif donne un résultat nettement moins bon qu'une réponse coordonnée dont les conflits ont été identifiés et rés
- Défaillances de la réponse coordonnée : les preuves
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : conflit reconnu avec le SLA de restauration du client ; résolution du conflit négociée à l’avance ; exercice sur table conjoint incluant le scénario de conflit.
- Correspondance COSO
-
Les Trust Services Criteria reposent sur le référentiel Internal Control Integrated Framework du COSO, plus précisément sur ses dix-sept principes, complétés par des critères supplémentaires propres au contexte des services de confiance. Les critères communs CC1 à CC5 correspondent directement aux cinq composantes du COSO : environnement de contrôle, évaluation des risques, activités de contrôle, information et communication, et pilotage.
cela explique la présence de critères relatifs à la supervision par le conseil d’administration, à la structure organisationnelle, à la compétence et à la responsabilité dans ce que la plupart des gens s’attendent à voir comme un rapport de sécurité. Ils proviennent du COSO, et ils sont là parce qu’un environnement de contrôle sans gouvernance pour le soutenir ne tient pas.
- Critères ou contrôles dans les questionnaires
-
Un questionnaire de sécurité porte sur des contrôles précis : chiffrez-vous les données au repos, faites-vous tourner les clés chaque trimestre, revoyez-vous les accès chaque mois ? Un rapport SOC 2 rend compte au regard de critères, avec des contrôles choisis par le fournisseur pour y satisfaire. Les deux concordent rarement point par point, parce que le questionnaire suppose une manière de satisfaire à un critère alors que le fournisseur a pu en choisir une autre.
un fournisseur peut répondre non à une question sur un contrôle précis et satisfaire tout de même au critère sous-jacent par une autre voie. Consigner cela comme une lacune, et pousser le fournisseur à adopter le contrôle que vous préférez, revient à lui demander de modifier quelque chose qui fonctionne déjà.
- Planification de la stratégie de sortie des fournisseurs critiques
-
La planification d’une stratégie de sortie est importante parce que l’incapacité à sortir d’une relation avec un fournisseur critique sans catastrophe opérationnelle est en soi un risque : risque de concentration, risque de rapport de force et risque de résilience opérationnelle, que l’entreprise supporte quelle que soit la posture de sécurité du fournisseur.
la planification d’une stratégie de sortie est importante parce que l’incapacité à sortir d’une relation avec un fournisseur critique sans catastrophe opérationnelle est en soi un risque : risque de concentration, risque de rapport de force et risque de résilience opérationnelle, que l’entreprise supporte quelle que soit la posture de sécurité du fournisseur.
- Planification de la stratégie de sortie des fournisseurs critiques : les éléments probants
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : engagement d’assistance à la transition avec calendrier ; documentation sur la portabilité des données et les formats d’export ; disponibilité de la documentation des API pour l’intégration de sortie.
- Risques liés aux flux de données transfrontaliers
-
Le risque lié aux flux de données transfrontaliers apparaît lorsque des données personnelles circulent entre des juridictions dont les normes de protection des données diffèrent, ce qui crée des obligations de conformité réglementaire qui doivent être remplies pour chaque transfert.
la gouvernance des flux de données transfrontaliers est importante en TPRM, car les obligations réglementaires applicables aux transferts internationaux de données (clauses contractuelles types, règles d’entreprise contraignantes, décisions d’adéquation) relèvent de la responsabilité de l’exportateur de données, et non de l’importateur.
- Risques liés aux flux de données transfrontaliers : les éléments probants
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : carte de l'empreinte géographique du traitement (tous les lieux où les données des clients sont traitées) ; inventaire des mécanismes de transfert (type de mécanisme et version en vigueur pour chaque lieu de transfert) ; confirmation des mécanismes de transfert des sous-traitants ultérieurs (non seulement la liste, mais la couverture par un mécanisme).
- Transferts transfrontaliers
-
Le chapitre V du GDPR restreint le transfert de données personnelles hors de l’Espace économique européen, sauf si un mécanisme de transfert s’applique : une décision d’adéquation, des clauses contractuelles types, des règles d’entreprise contraignantes ou l’une des dérogations limitées. La restriction suit les données partout où elles vont, y compris lors des transferts ultérieurs effectués par le destinataire.
l’accès est un transfert. Un ingénieur du support situé dans un pays tiers qui consulte le dossier d’un client européen a transféré ces données, même si elles n’ont jamais quitté le serveur européen. L’administration à distance, le support en continu selon les fuseaux horaires et le développement délocalisé sont tous des transferts, et cartographier uniquement le lieu de stockage des données passe à côté de la plupart d’entre eux.
- Délais de réponse entre organisations
-
Les problèmes de délais de réponse entre organisations surviennent lorsque des incidents de sécurité touchant plusieurs organisations, notamment des incidents de chaîne d’approvisionnement visant des fournisseurs et leurs clients dans une même campagne, font l’objet d’enquêtes indépendantes par chaque organisation touchée plutôt que d’un partage d’informations coordonné.
les délais de réponse entre organisations comptent en matière de TPRM parce que les incidents de la chaîne d’approvisionnement créent souvent des situations de ciblage commun dans lesquelles une réponse coordonnée permettrait une détection plus rapide et réduirait le temps de présence de l’attaquant pour toutes les parties.
- Délais de réponse entre organisations : les éléments probants
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : processus de notification des clients en cas de ciblage simultané ; mécanisme de partage des IOC (STIX/TAXII, MISP ou accord bilatéral) ; participation à un ISAC du secteur concerné.
- Visibilité multiplateforme
-
Les lacunes de visibilité multiplateforme sont les angles morts de la surveillance de sécurité qui existent aux interfaces entre différentes plateformes technologiques, services gérés et opérateurs tiers, plus précisément les systèmes et environnements où la frontière de responsabilité de surveillance entre deux parties est ambiguë, supposée plutôt que confirmée, ou
la visibilité multiplateforme est importante pour la TPRM parce que les environnements technologiques complexes des fournisseurs, avec de multiples services gérés, des opérateurs tiers et une infrastructure hybride, créent des possibilités de lacunes de surveillance à chaque interface entre les parties.
- Visibilité multiplateforme : les preuves
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : confirmation de la surveillance de sécurité de l’exécution Kubernetes ; périmètre de surveillance de sécurité du service géré inscrit dans le contrat ; un fournisseur qui affirme couvrir les terminaux, le cloud et le réseau doit être interrogé précisément sur la surveillance de sécurité des conteneurs et de Kubernetes. Les catégories confirmées couvrent les composants confirmés. Le cluster Kubernetes qui héberge les données des clients exige sa propre confirmation.
- Propagation des identités entre systèmes
-
La propagation des identités entre systèmes est le processus par lequel les événements du cycle de vie des identités (création d'utilisateurs, changements de rôle et retrait des accès) sont communiqués depuis une source d'identité centrale (généralement un IdP ou une plateforme IGA) à tous les systèmes connectés, afin que l'état des identités soit cohérent dans l'ensemble du parc applicatif.
la propagation des identités entre systèmes est importante en TPRM, car les fournisseurs qui accèdent aux environnements des clients à travers plusieurs systèmes (espaces de travail de projet, outils de collaboration avec les clients, environnements de développement partagés) peuvent présenter des lacunes de déprovisionnement IGA pour les systèmes connexes à l’environnement client déployés spécifiquement pour la mission.
- Propagation des identités entre systèmes : les éléments probants
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : liste des connecteurs IGA avec la date du dernier rapprochement ; capacité ou processus de découverte des applications fantômes ; processus de vérification des accès après départ couvrant les systèmes non IGA.
- Risques d’accès entre locataires
-
Le risque d’accès inter-locataires est la possibilité que les données, la charge de travail ou l’environnement d’un client au sein d’une plateforme cloud mutualisée soient consultés, affectés ou compromis en raison de la présence d’un autre client sur la même plateforme, ou en raison de faiblesses dans les composants partagés de la plateforme qui servent tous les locataires simultané
le risque entre locataires est l'une des dimensions les moins évaluées du risque cloud lié aux tiers, précisément parce qu'il est invisible dans le modèle d'évaluation standard.
- Risques d'accès entre locataires : les éléments probants
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : une description architecturale claire de l’isolation des locataires, non pas un argument commercial mais une explication technique ; la documentation des contrôles d’accès du support, y compris les exigences d’autorisation et la journalisation d’audit ; des rapports de tests d’intrusion ou leurs synthèses confirmant que des scénarios inter-locataires ont été testés.
- Détection des attaques entre locataires
-
La détection des attaques inter-locataires consiste à déterminer si une compromission de sécurité touchant l’environnement d’un client sur une plateforme mutualisée a accédé, ou pourrait accéder, aux environnements d’autres clients par l’intermédiaire de composants d’infrastructure partagés.
la détection des attaques entre locataires est importante pour la TPRM parce que les clients des plateformes mutualisées font face à un risque de violation qui prend naissance dans l'environnement d'un autre client : un risque totalement hors de leur contrôle, qui dépend de la capacité du fournisseur à détecter les accès entre locataires et à informer les clients touchés.
- Détection des attaques inter-locataires : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : liste de contrôle des enquêtes entre locataires (quelles couches sont vérifiées) ; élément déclencheur et délai de la notification des colocataires ; procédure de revue du contrôle d'accès aux bases de données partagées.
- Tables de correspondance
-
Une table de correspondance met en relation les exigences de deux référentiels ou plus, en indiquant quelle exigence de l’un correspond à quelle exigence de l’autre. Les bonnes sont graduées et précisent si une correspondance est totale, partielle ou simplement thématique. Les mauvaises sont des listes de numéros côte à côte, produites une fois par quelqu’un qui a lu les intitulés.
une table de correspondance est la manière dont un programme de contrôle évite de faire trois fois le même travail, et c'est aussi la manière dont il surestime discrètement sa couverture. Une correspondance partielle enregistrée comme complète est le point où un programme commence à dire aux évaluateurs qu'une exigence est satisfaite alors qu'elle ne l'est qu'en grande partie. Les tables de correspondance publiées par les organismes responsables des référentiels et par les fournisseurs vont du rigoureux au décoratif, et le lecteur ne peut généralement pas les distinguer à partir du format.
D
- Interfaces trompeuses en matière de consentement
-
Les interfaces trompeuses sont des conceptions d'interface qui orientent les utilisateurs vers un choix qu'ils n'auraient pas fait autrement : un bouton d'acceptation dans une couleur appuyée à côté d'un lien de refus en gris, un parcours de refus enfoui à trois clics de profondeur, des sollicitations répétées après un refus, des doubles négations déroutantes, ou un mur de cookies qui bloque le contenu jusqu'à ce que le consentement soit donné. Les autorités de régulation nomment désormais des schémas précis dans leurs lignes directrices et leurs mesures répressives.
un consentement obtenu au moyen d'une interface trompeuse n'est pas donné librement, et un consentement qui n'est pas donné librement n'est pas un consentement. Le traitement qui repose sur lui n'a pas de base légale. Les autorités de régulation européennes ont infligé des amendes à des entreprises précisément pour des interfaces de consentement asymétriques, et la conception elle-même constitue désormais une preuve.
- Lacunes de couverture DAST des applications fournisseurs
-
Le DAST est présenté dans la plupart des programmes de sécurité des fournisseurs comme le complément du SAST : là où l’analyse statique détecte les vulnérabilités du code avant le déploiement, les tests dynamiques détectent les vulnérabilités d’exécution dans l’application déployée.
Le DAST est présenté dans la plupart des programmes de sécurité des fournisseurs comme le complément du SAST : là où l’analyse statique détecte les vulnérabilités du code avant le déploiement, les tests dynamiques détectent les vulnérabilités d’exécution dans l’application déployée.
- Lacunes de couverture DAST dans les applications des fournisseurs : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : pourcentage de couverture de la dernière analyse DAST, avec indication explicite de ce qui est exclu du périmètre ; confirmation des tests authentifiés, avec description de la gestion de l'authentification dans l'outil d'analyse ; confirmation de l'environnement (production ou équivalent de production), avec description de toute différence significative par rapport à la production.
- DAST dans le pipeline CI/CD
-
L'efficacité des DAST est importante pour la TPRM parce que les paramètres d'authentification et de configuration avec lesquels les DAST sont exécutés déterminent les vulnérabilités qu'ils peuvent trouver.
L'efficacité des DAST est importante pour la TPRM parce que les paramètres d'authentification et de configuration avec lesquels les DAST sont exécutés déterminent les vulnérabilités qu'ils peuvent trouver.
- DAST dans le pipeline CI/CD : les preuves
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : description de la configuration de l’environnement cible du DAST ; documentation du périmètre du DAST (points de terminaison et flux d’authentification couverts) ; un fournisseur qui affirme réaliser des analyses DAST doit être interrogé sur la configuration de l’environnement testé. Le DAST teste ce qui s’exécute. Si ce qui s’exécute ne correspond pas à la configuration de production, les constats du DAST ne décrivent pas les vulnérabilités de production.
- Lacunes de la journalisation des accès aux données
-
La journalisation des accès aux données est la capture systématique d'enregistrements indiquant quel utilisateur ou processus a accédé à quelles données, quand, depuis quel emplacement, et quelle opération a été effectuée : lecture, écriture, exportation, suppression, requête.
la journalisation des accès aux données est importante pour la TPRM parce que la menace interne, c'est-à-dire un employé du fournisseur qui abuse de son accès légitime aux données des clients, est l'une des catégories de menaces les plus lourdes de conséquences et les moins détectables du paysage du risque lié aux tiers.
- Lacunes de la journalisation des accès aux données : les éléments probants
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : description de la capacité de détection des menaces internes (le contrôle précis qui détecterait une exportation massive) ; confirmation de la journalisation des accès au niveau applicatif avec alerte sur les exportations massives ; durée de conservation des journaux et base de son calibrage.
- Accumulation progressive des privilèges d'accès aux données
-
L'accumulation progressive des privilèges est l'accumulation graduelle de droits d'accès au fil du temps, à mesure que des personnes reçoivent de nouveaux accès à des fins précises sans perdre leurs accès antérieurs lorsque ces fins prennent fin. Chaque attribution individuelle suit le bon processus de provisionnement : demande, approbation, accès.
l'accumulation progressive des privilèges est importante pour la TPRM parce qu'elle crée un risque de menace interne invisible pour les évaluations centrées sur les attributions d'accès individuelles.
- Accumulation progressive des privilèges d'accès aux données : les éléments probants
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : preuves de revue des profils cumulés pour la population à forte ancienneté ; confirmation du déclencheur de retrait des accès lors d'un changement de rôle ; plateforme de gestion du cycle de vie IGA, le cas échéant.
- Accès aux données via les API
-
Les API sont devenues la principale interface par laquelle les données circulent entre les systèmes : le mécanisme par lequel les intégrations de fournisseurs, les applications mobiles, les connexions avec les partenaires et les services internes accèdent aux données que détiennent les bases de données et les systèmes applicatifs.
l’accès aux données par API est important en TPRM, car les interfaces de programmation sont le véritable mécanisme d’accès aux données de pratiquement toutes les intégrations de fournisseurs, et les contrôles de sécurité de la couche API déterminent la protection réelle des données dont bénéficient les intégrations, indépendamment des contrôles au niveau de la base de données que les évaluations de gouvernance examinent habituellement.
- Accès aux données via les API : les éléments probants
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments probants à demander plutôt que des assurances : la confirmation de la capacité de filtrage des champs, périmètre des champs par intégration ou restitution de l’enregistrement complet ; la configuration de la limitation de débit, limites par clé sur les points de terminaison de récupération des données ; la confirmation du périmètre des tests de sécurité API, y compris les tests d’autorisation des champs et d’énumération.
- Idées reçues sur l'anonymisation des données
-
L'anonymisation des données est le processus qui consiste à transformer des données personnelles de manière à empêcher de façon irréversible l'identification des personnes auxquelles elles se rapportent, en supprimant ou en modifiant les informations identifiantes de sorte que la ré-identification ne soit pas raisonnablement possible par des moyens susceptibles d'être à la disposition d'un adversaire potentiel.
l'anonymisation des données est importante pour la TPRM parce qu'elle sert souvent de mécanisme pour alléger les exigences de gouvernance applicables aux données partagées avec les fournisseurs d'analyse, de recherche et d'AI/ML, l'argument étant que les données anonymisées ne sont pas des données personnelles et ne nécessitent donc pas les mêmes contrôles d'accès, les mêmes clauses DPA et les mêmes exigences de sécurité que les données ide
- Idées reçues sur l’anonymisation des données : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : documentation de la technique d'anonymisation (méthode précise appliquée, et pas seulement « identifiants supprimés ») ; évaluation du risque de ré-identification à l'aide d'outils formels et d'hypothèses réalistes sur les données auxiliaires ; confirmation d'une réévaluation périodique pour les données anonymisées il y a plus de 12 mois.
- Difficultés d'auditabilité des données
-
L’auditabilité des données est la capacité à produire sur demande la preuve du respect des obligations en matière de protection des données, non pas au moyen d’un programme de conformité qui génère des preuves lorsqu’un régulateur les demande, mais au moyen d’une infrastructure de preuve permanente qui enregistre en continu les événements de conformité et les conserve dans un format qui permet l’audit et la re
l'auditabilité des données est importante pour la TPRM parce que c'est la capacité qui transforme une pratique de conformité en conformité défendable : la capacité de démontrer à une autorité de régulation, à un client ou à un auditeur que les obligations de protection des données sont respectées, quand elles le sont, et que les preuves de ce respect sont disponibles pour examen.
- Difficultés d'auditabilité des données : les éléments probants
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : résultats des revues d'accès dans un format consultable et prêt pour l'audit ; journal des suppressions indiquant le système, le calendrier et la documentation de confirmation ; journal des DSAR avec l'état de traitement et les preuves des délais.
- Lacunes de la notification des violations de données
-
La gouvernance de la notification des violations de données dans les relations fournisseurs est l'ensemble des mécanismes contractuels et opérationnels qui garantissent qu'un fournisseur communique au client les incidents de sécurité affectant ses données dans un délai qui permet au client de remplir ses propres obligations réglementaires de notification.
les lacunes dans la notification des violations comptent en matière de TPRM parce que les obligations réglementaires du client ne sont pas suspendues pendant que le fournisseur enquête.
- Lacunes de la notification des violations de données : les éléments probants
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : documentation du processus de réponse aux incidents faisant de la notification au client une étape définie et encadrée dans le temps ; précision du délai de notification (nombre maximal d’heures entre la découverte et la notification) ; modèle de notification initiale avec confirmation du contenu minimal.
- Classification des données
-
La classification des données attribue des exigences de traitement aux informations en fonction de leur sensibilité. Un schéma type comporte quatre niveaux : public, interne, confidentiel et restreint, chaque niveau étant assorti de règles de stockage, de transmission, d'accès, de partage et d'élimination. Les données personnelles et les catégories particulières de données sont généralement rattachées aux niveaux les plus élevés.
les contrôles, la conservation et les décisions d'accès renvoient tous à la classification, de sorte qu'un parc sans classification impose une seule politique pour tout, qui est soit trop stricte pour les contenus publics, soit trop souple pour les contenus restreints. La classification est ce qui permet un traitement proportionné.
- Validation de la suppression des données
-
La validation de la suppression des données est le processus qui consiste à confirmer que les données ont été supprimées de façon complète et irréversible de tous les emplacements où elles existaient, et pas seulement à confirmer qu'une action de suppression a été effectuée sur les systèmes compris dans le périmètre de la demande de suppression.
la validation de la suppression des données est importante pour la TPRM parce que le droit à l'effacement prévu par le GDPR et les droits équivalents prévus par le CCPA, la LGPD et d'autres cadres créent des obligations juridiquement contraignantes qui exigent une suppression complète, de tous les systèmes, y compris les sauvegardes et les archives, et pas seulement des systèmes actifs principaux.
- Validation de la suppression des données : les éléments probants
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : confirmation de la couverture des systèmes (liste des systèmes examinés et suppression confirmée dans chacun) ; enregistrements des journaux de suppression lorsqu’ils existent, c’est-à-dire des preuves d’action plutôt que des preuves d’absence ; confirmation explicite de la suppression dans les sauvegardes et archives.
- Lacunes de détection de l'exfiltration de données
-
Les lacunes de la détection de l’exfiltration de données sont les limites de la capacité d’un programme de sécurité à repérer le moment où des données sont transférées hors de l’organisation par un attaquant, lacunes qui découlent du calibrage des seuils, de l’architecture de détection et des techniques d’exfiltration spécifiques que les attaquants utilisent pour contourner la détection configurée.
les lacunes de détection de l'exfiltration de données sont importantes pour la TPRM parce que la DLP constitue la principale preuve, lors des enquêtes consécutives à une violation, permettant d'établir si des données ont réellement été exfiltrées et en quel volume, et un système de DLP qui a évalué douze transferts individuellement sans détecter l'exfiltration au niveau de la session ne fournit aucune preuve d'une violation qu'un enquêteur
- Lacunes de détection de l’exfiltration de données : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : confirmation de la configuration de l'agrégation par session de la DLP ; un fournisseur qui confirme un déploiement de DLP avec des seuils configurés doit être interrogé sur l'inclusion de l'agrégation par session dans la configuration. Les seuils par événement détectent l'exfiltration en un seul événement. L'agrégation par session détecte l'exfiltration fragmentée. Les deux exigent une configuration spécifique. Les deux exigent une confirmation spécifique.
- Voies d’exfiltration de données
-
L'exfiltration de données est le transfert non autorisé de données d'un environnement contrôlé vers un environnement non contrôlé, que ce soit par intention malveillante, par négligence d'un employé ou par des raccourcis de commodité qui contournent les contrôles de sécurité.
la gouvernance des voies d’exfiltration de données est importante en TPRM, car le risque d’exfiltration que présente un fournisseur ne dépend pas de la solidité des contrôles mis en place sur les canaux qu’il a traités, mais de l’exhaustivité des contrôles sur tous les canaux par lesquels les données peuvent transiter.
- Chemins d'exfiltration des données : les éléments probants
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : confirmation de la couverture DLP du transfert vers une messagerie personnelle (contrôle technique ou reconnaissance explicite de la lacune) ; documentation de la politique relative aux appareils et comptes personnels (interdiction explicite et mécanisme d'application) ; historique des incidents d'exfiltration (incidents récents, canal concerné et résultat du contrôle).
- Lacunes des outils de gouvernance des données
-
Les outils de gouvernance des données sont l’infrastructure technique qui rend opérationnelles les politiques de gouvernance : les plateformes, outils et systèmes automatisés qui exécutent la classification, appliquent les règles de conservation, gèrent les revues d’accès, tiennent à jour les inventaires de données et surveillent la conformité en continu plutôt que de dépendre de processus manuels périodiques.
les lacunes des outils de gouvernance des données sont importantes pour la TPRM parce qu'elles déterminent la cohérence et l'ampleur réelles de l'exécution du programme de gouvernance : l'écart entre ce que décrit la politique et ce que les processus manuels peuvent produire.
- Lacunes des outils de gouvernance des données : les éléments probants
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments probants à demander plutôt que des assurances : le nom de l’outil de classification et son pourcentage de couverture ; le nom de la plateforme IGA avec confirmation de la révocation automatique ; l’outil de gestion du cycle de vie avec le journal des suppressions automatisées.
- Gouvernance des données ou application effective
-
La gouvernance des données est le cadre de politiques, de normes et de processus qui définit comment les données doivent être collectées, classifiées, protégées, conservées et éliminées au sein d'une organisation.
la distinction entre gouvernance des données et application effective est importante en TPRM, car la valeur d’assurance de la documentation de gouvernance des données d’un fournisseur dépend entièrement de sa conformité à la réalité opérationnelle.
- Gouvernance des données et application effective : les éléments probants
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : preuves du déploiement des outils de classification (pas la politique, le système déployé) ; configuration de l'automatisation de la conservation (pas le calendrier de la politique, le processus de suppression configuré) ; constats de l'audit interne et état de leur remédiation (preuves des tests de conformité de la gouvernance).
- Exhaustivité de l'inventaire des données
-
Un inventaire des données est un registre documenté de l’ensemble des systèmes, bases de données, emplacements de stockage et flux de données qui contiennent ou traitent des données sensibles dans l’environnement d’une organisation ou d’un fournisseur.
l’exhaustivité de l’inventaire des données est importante en TPRM, car tous les contrôles de gouvernance des données en aval (gestion des accès, chiffrement, politiques de conservation, périmètre de réponse aux incidents) dépendent de l’identification, dans l’inventaire, des systèmes auxquels ces contrôles doivent s’appliquer.
- Exhaustivité de l’inventaire des données : les preuves
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : résultats d’analyses de découverte comparés à l’inventaire documenté, avec documentation des écarts ; documentation du processus de mise à jour de l’inventaire (déclencheurs et fréquence) ; confirmation du périmètre de l’inventaire, incluant toutes les catégories de systèmes pertinentes.
- Mauvaise gestion du cycle de vie des données
-
La gestion du cycle de vie des données est la gouvernance des données depuis leur création ou leur collecte jusqu'à leur utilisation, leur conservation, leur archivage et, à terme, leur suppression ou leur destruction.
la mauvaise gestion du cycle de vie des données est importante en TPRM, car la conservation non autorisée des données, c’est-à-dire leur conservation au-delà de la durée autorisée par la finalité du traitement, crée un risque résiduel pur sans aucune valeur métier correspondante.
- Mauvaise gestion du cycle de vie des données : les preuves
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : documentation du processus de suppression (circuit formel de la demande à l’exécution puis à la vérification) ; responsable désigné du cycle de vie (fonction précise chargée de l’exécution et de la fourniture des preuves) ; preuves de vérification de la suppression lors d’une récente fin de relation client, démontrant que le processus fonctionne.
- Traçabilité des données chez les tiers
-
Le lignage des données est l'enregistrement traçable de l'origine des données, de leurs transformations et de leur parcours : une chaîne de traçabilité qui identifie chaque système, processus et partie ayant touché les données depuis leur création jusqu'à leur état actuel.
la traçabilité des données chez les tiers est importante en TPRM, car les obligations réglementaires applicables aux données des clients (limitations du traitement, restrictions géographiques, exigences d’autorisation des sous-traitants ultérieurs, droits des personnes concernées) s’appliquent aux données quel que soit le nombre d’intermédiaires qui les séparent du client.
- Lignage des données chez les tiers : les éléments probants
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : liste à jour des sous-traitants ultérieurs avec leurs noms, juridictions, données reçues et finalité du traitement ; documentation du processus de notification des changements avec les droits d'opposition des clients ; confirmation de l'interdiction de réutilisation des données (les sous-traitants ultérieurs ont l'interdiction contractuelle d'utiliser les données des clients à des fins non autorisées).
- Cartographie des données
-
La cartographie des données consiste à identifier les données personnelles détenues par une organisation, où elles se trouvent, comment elles circulent entre les systèmes et les parties, qui peut y accéder et ce qu’il en advient tout au long de leur cycle de vie. C’est le fondement empirique du registre des activités de traitement, du calendrier de conservation, du registre des transferts et de chaque demande d’exercice des droits.
toutes les autres obligations en matière de vie privée en dépendent. Une organisation ne peut pas donner suite à une demande d'effacement sans savoir où se trouvent les données. Elle ne peut pas évaluer les transferts sans savoir où vont les données. Elle ne peut pas fixer de durées de conservation sans savoir ce qu'elle détient. Un programme sans cartographie est un programme qui devine.
- Minimisation des données
-
La minimisation des données exige que les données personnelles soient adéquates, pertinentes et limitées à ce qui est nécessaire au regard des finalités pour lesquelles elles sont traitées. Collectez ce que la finalité exige, et rien de plus. Conservez-les uniquement aussi longtemps que la finalité l'exige. C'est l'un des sept principes de l'article 5 du GDPR et l'un des plus difficiles à faire respecter par une équipe produit.
davantage de données semble toujours utile plus tard. Un formulaire qui demande la date de naissance alors que seule la tranche d’âge est nécessaire, un journal qui enregistre le corps complet des requêtes alors que seuls les codes de statut sont requis, un CRM qui stocke chaque champ proposé par l’intégration. Chacun est un manquement à la minimisation, et chacun élargit la surface de chaque violation, de chaque demande d’accès et de chaque obligation de conservation.
- Défaillances de la minimisation des données
-
La minimisation des données est importante en TPRM pour une raison à la fois juridiquement significative et intuitive en pratique : on ne peut pas subir de violation sur des données qu’on ne détient pas. Chaque élément de données transféré à un fournisseur au-delà de ce qui est nécessaire à la finalité déclarée représente une extension inutile de la surface d’exposition aux violations.
la minimisation des données est importante en TPRM pour une raison à la fois juridiquement significative et intuitive en pratique : on ne peut pas subir de violation sur des données qu’on ne détient pas.
- Défaillances de la minimisation des données : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : inventaire précis des champs de données avec la justification de la finalité de chaque champ reçu ; confirmation qu'aucun champ n'est reçu sans finalité opérationnelle active ; évaluation des capacités d'anonymisation ou de pseudonymisation pour les champs dont l'identification n'est pas nécessaire sur le plan opérationnel.
- Ambiguïté de la propriété des données
-
La propriété des données dans les relations fournisseurs recouvre deux catégories distinctes mais souvent confondues. La première est la propriété des données elles-mêmes : les dossiers clients, les journaux de transactions, les données comportementales et les informations opérationnelles que le client communique au fournisseur pour traitement.
l’ambiguïté sur la propriété des données compte en matière de TPRM parce que les conséquences commerciales et concurrentielles des lacunes en matière de propriété peuvent être aussi importantes que les failles de sécurité.
- Ambiguïté de la propriété des données : les éléments probants
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : disposition sur la propriété des actifs dérivés (clauses contractuelles explicites sur la propriété des modèles et des algorithmes) ; confirmation de la restriction d'usage concurrentiel (interdiction de proposer à des concurrents des capacités issues de la collaboration avec le client) ; documentation du traitement des actifs après la résiliation (suppression ou restitution des modèles entraînés à la fin du contrat).
- Portabilité des données
-
Le droit à la portabilité des données permet à une personne de recevoir les données personnelles qu’elle a fournies à un responsable du traitement, dans un format structuré, couramment utilisé et lisible par machine, et de les transmettre à un autre responsable du traitement. Il ne s’applique que lorsque le traitement est fondé sur le consentement ou sur un contrat, et uniquement lorsqu’il est effectué à l’aide de procédés automatisés.
il est souvent invoqué pour des données qu'il ne couvre pas. Les inférences que vous avez tirées, les scores que vous avez calculés et les dossiers que vous avez constitués sur la personne à partir d'autres sources ne sont pas des données qu'elle a fournies et ne sont pas portables. Les données traitées sur la base de l'intérêt légitime ou d'une obligation légale n'entrent pas non plus dans le champ.
- Accords de traitement des données
-
Un accord de traitement des données est le contrat que l'article 28 du GDPR impose entre un responsable du traitement et un sous-traitant. Son contenu obligatoire est énuméré dans l'article : l'objet et la durée, la nature et la finalité, les types de données et les catégories de personnes concernées, ainsi que les obligations des deux parties, notamment ne traiter les données que sur instruction, la confidentialité, la sécurité, les règles relatives aux sous-traitants ultérieurs, l'assistance pour l'exercice des droits et les analyses d'impact, la suppression ou la restitution en fin de contrat, et les droits d'audit.
un DPA auquel manque l'une des clauses obligatoires n'est pas conforme, aussi professionnelle que soit sa rédaction. Le consentement au recours à des sous-traitants ultérieurs et les droits d'audit sont les deux clauses le plus souvent absentes des modèles des fournisseurs, et leur absence n'est généralement pas délibérée. Le modèle a été rédigé dans un autre but et n'a jamais été vérifié au regard de l'article.
- Analyses d'impact relatives à la protection des données
-
Une analyse d'impact relative à la protection des données est un processus documenté visant à identifier et à réduire au minimum les risques d'un projet en matière de protection des données avant son lancement. Elle est obligatoire lorsque le traitement est susceptible d'engendrer un risque élevé pour les personnes, en particulier en cas de nouvelles technologies, de surveillance à grande échelle, d'évaluation systématique ou de profilage, ou de traitement à grande échelle de catégories particulières de données.
l'DPIA est le moment documenté où quelqu'un s'est demandé si ce projet devait être construit de la manière dont il l'est, et ce qui pourrait être fait autrement. C'est aussi ce qu'une autorité de régulation demande en premier après une plainte, et son absence lorsqu'elle était requise constitue en soi un manquement, indépendamment du fait que le traitement se soit révélé préjudiciable ou non.
- Délégués à la protection des données
-
Le GDPR exige un délégué à la protection des données dans trois cas : l'organisation est une autorité publique, ses activités de base consistent en un suivi régulier et systématique à grande échelle des personnes, ou ses activités de base consistent en un traitement à grande échelle de catégories particulières de données ou de données relatives aux condamnations pénales. L'effectif et le chiffre d'affaires ne sont pas le critère.
de nombreuses organisations désignent un DPO volontairement, et ce faisant elles assument l'ensemble des obligations légales qui en découlent : indépendance, ressources suffisantes, rattachement direct au niveau le plus élevé de la direction, protection contre le licenciement pour l'exercice de ses missions et association à toutes les questions de protection des données. Un DPO désigné volontairement n'en est pas une version allégée.
- Risques liés à la réplication des données
-
La réplication des données est la création de copies de données à des fins opérationnelles, de disponibilité et d’analyse : serveurs de secours actifs qui assurent la continuité en cas de défaillance du système principal, copies de sauvegarde qui permettent la reprise après une perte de données, environnements DR qui reproduisent la production pour les tests de basculement, environnements de développement et de test alimentés av
le risque lié à la réplication des données est important en TPRM, car l’évaluation de sécurité du fournisseur couvre généralement le système principal : la base de données que le fournisseur décrit dans sa documentation de sécurité, que couvre son évaluation SOC 2 et que maintient son processus de revue des accès.
- Risques liés à la réplication des données : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : inventaire des réplicas (tous les systèmes contenant des données clients, avec leur propriétaire et l'état du contrôle d'accès) ; confirmation des données des environnements de développement (données synthétiques ou masquées, ou données de production avec des contrôles équivalents) ; confirmation du périmètre d'effacement (tous les réplicas inclus dans les processus d'effacement).
- Résidence et souveraineté des données
-
La résidence des données désigne le lieu où les données sont physiquement stockées. La souveraineté des données désigne les lois qui peuvent imposer l’accès à ces données. Un jeu de données stocké dans une région de Francfort exploitée par une entreprise dont le siège est aux États-Unis réside en Allemagne et est soumis aux procédures judiciaires américaines, car l’opérateur peut y être contraint en vertu du droit américain, quel que soit l’emplacement des serveurs.
les clients posent des questions sur la souveraineté et reçoivent des réponses sur la résidence. Un sélecteur de région dans une console de cloud satisfait à la résidence en un clic et ne dit rien de la souveraineté, car l’exposition juridique de l’opérateur suit l’opérateur, et non le centre de données.
- Résidence des données ou accès aux données
-
La résidence des données est une contrainte portant sur le lieu de stockage physique des données : quel centre de données, quel pays, quelle juridiction. C’est un contrôle significatif dans le contexte des exigences de souveraineté des données, des règles de compétence réglementaire et des restrictions applicables au transfert transfrontalier qui précisent où les données personnelles peuvent être stockées.
les engagements de résidence des données sont de plus en plus utilisés comme mécanisme principal de conformité au GDPR, l’argument étant que les données stockées dans l’UE ne font jamais l’objet d’un transfert international restreint au sens du chapitre V du GDPR.
- Résidence des données ou accès : les preuves
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : carte géographique des accès, indiquant tous les lieux depuis lesquels les données de la région désignée sont consultées, avec le cadre d’autorisation applicable à chacun ; confirmation de la géographie de réplication des sauvegardes, dans la région désignée ou avec des mécanismes de transfert approuvés ; confirmation de la disponibilité des journaux sur la géographie des accès.
- Défaillances de la séparation des données
-
Le cloisonnement des données dans les environnements mutualisés est l’approche architecturale et technique qui garantit que les données d’un client ne peuvent pas être consultées au moyen de la session authentifiée d’un autre client.
les défaillances de cloisonnement des données sont importantes en TPRM, car elles représentent une catégorie de risque propre aux plateformes mutualisées, susceptible d’exposer les données d’un client à d’autres clients sans intervention d’un attaquant, par des bogues, des erreurs de configuration et des défauts de conception inhérents à l’architecture mutualisée.
- Défaillances de la séparation des données : les éléments probants
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : description de l’architecture mutualisée, avec le mécanisme d’isolation précis ; confirmation du périmètre du test d’intrusion inter-locataires, avec le contournement de l’isolation comme objectif explicite ; confirmation de la sécurité au niveau des lignes de la base de données ou d’une autre isolation architecturale.
- Accords de partage de données
-
Lorsque deux responsables du traitement partagent des données personnelles, chacun pour ses propres finalités, la relation est de responsable du traitement à responsable du traitement et nécessite un accord de partage de données plutôt qu’un DPA au titre de l’article 28. L’accord couvre la finalité du partage, la base légale sur laquelle s’appuie chaque partie, les données partagées, les mesures de sécurité, le traitement des demandes d’exercice des droits, ce que chaque partie communique aux personnes concernées et ce qui se passe à la résiliation.
Les DPA prévus à l’article 28 régissent les relations avec les sous-traitants et ne conviennent pas du tout au partage entre responsables du traitement. Un tel contrat impose au sous-traitant de n’agir que sur instruction du responsable du traitement, ce qui n’a aucun sens entre deux responsables du traitement qui déterminent chacun leurs propres finalités. En signer un pour un accord de partage attribue aux deux parties des rôles qu’aucune d’elles n’exerce.
- Application de la souveraineté des données
-
La souveraineté des données est le principe selon lequel les données sont soumises aux lois et réglementations de la juridiction dans laquelle elles sont stockées ou traitées, et selon lequel l’organisation qui contrôle ces données est protégée contre l’accès des gouvernements étrangers, sauf par des mécanismes juridiques définis : traités d’entraide judiciaire, décisions de justice formelles avec appropri
l’application effective de la souveraineté des données est importante en TPRM, car le secteur public, les secteurs réglementés et les organisations soumises à des obligations de traitement de données liées à la sécurité nationale exigent de plus en plus une véritable souveraineté des données, et non une souveraineté fondée sur le lieu de stockage, qui peut être contournée par la structure de l’entreprise et le droit extraterritorial.
- Application effective de la souveraineté des données : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : divulgation de la structure de l'entreprise (société mère ultime et juridiction) ; évaluation de l'exposition aux lois extraterritoriales de la juridiction de la société mère ; confirmation de la séparation des accès opérationnels (accès de la société mère à l'infrastructure).
- Demandes d’accès des personnes concernées
-
Une demande d'accès de la personne concernée est l'exercice par une personne de son droit d'obtenir les données personnelles qu'une organisation détient à son sujet, ainsi que les finalités, les destinataires, la durée de conservation et la source. Le responsable du traitement dispose d'un mois pour répondre, délai qui peut être prolongé de deux mois pour les demandes complexes ou nombreuses, et le délai court à compter de la réception.
les demandes arrivent par n’importe quel canal. Un ticket d’assistance, une réponse à un courriel marketing, un message sur les réseaux sociaux, un commentaire dans une réclamation. Aucun formulaire n’est requis, et le délai court à compter du moment où l’organisation l’a reçue, et non du moment où quelqu’un l’a reconnue comme une DSAR et l’a transmise à la bonne équipe.
- Droits des personnes concernées au-delà de l’accès
-
Au-delà de l’accès et de l’effacement, le GDPR confère aux personnes le droit de rectification des données inexactes, le droit à la limitation du traitement dans certaines circonstances, le droit d’opposition au traitement fondé sur l’intérêt légitime ou à des fins de prospection, ainsi que des droits relatifs à la prise de décision automatisée. Chacun est assorti du même délai de réponse d’un mois et de la même obligation de répondre.
les processus sont conçus pour les demandes d'accès, parce que ce sont les plus courantes, et improvisés pour tout le reste. Une opposition est traitée comme un effacement. Une demande de limitation n'est pas reconnue du tout. Une rectification est appliquée à un système et pas aux autres. Chacun de ces cas constitue un manquement au respect d'un droit, avec les mêmes conséquences que l'absence de réponse à une DSAR.
- Incohérences du marquage des données
-
Le marquage des données est l'application d'étiquettes de classification (niveaux de sensibilité, catégories de données, exigences de traitement) aux éléments de données dans tous les systèmes où ils se trouvent. Un marquage cohérent garantit qu'un élément de données porte la même classification et les contrôles correspondants, quel que soit le système dans lequel il réside.
l’incohérence du marquage des données est importante en TPRM, car elle signifie que les contrôles de protection des données appliqués au système principal ne s’appliquent pas nécessairement aux mêmes données dans les systèmes secondaires, et que ces systèmes secondaires peuvent avoir des populations d’accès nettement plus larges.
- Incohérences dans l’étiquetage des données : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : description du mécanisme de propagation des étiquettes ou reconnaissance de la lacune ; documentation du schéma de classification de référence couvrant tous les systèmes ; preuves de validation de la cohérence de la classification entre systèmes.
- Surveillance de l'utilisation des données
-
La surveillance de l'utilisation des données est la capacité d'observer comment les données sont réellement traitées dans l'environnement d'un fournisseur : quelles requêtes sont exécutées sur elles, quels pipelines les consomment, quels produits y font référence, et si leur utilisation réelle est conforme à l'utilisation prévue au contrat.
la surveillance de l’utilisation des données est importante en TPRM, car c’est le mécanisme qui transforme un DPA d’une déclaration d’usage autorisé en un instrument de gouvernance applicable.
- Surveillance de l'utilisation des données : les éléments probants
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : confirmation de la surveillance de l'utilisation interne (journaux de requêtes et attribution des pipelines) ; description de la surveillance des données d'entraînement de ML ; description de la capacité de détection des dépassements de périmètre.
- Protection contre les attaques DDoS et résilience des fournisseurs
-
la protection contre les attaques DDoS et la résilience sont importantes en TPRM, car la disponibilité de la plateforme du fournisseur est une dépendance directe pour les entreprises clientes dont les activités reposent sur cette plateforme.
la protection contre les attaques DDoS et la résilience sont importantes en TPRM, car la disponibilité de la plateforme du fournisseur est une dépendance directe pour les entreprises clientes dont les activités reposent sur cette plateforme.
- Protection contre les attaques DDoS et résilience des fournisseurs : les preuves
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : prestataire et capacité d’atténuation des attaques DDoS ; procédure et délai de notification des clients ; couverture du SLA pour les interruptions liées aux attaques DDoS.
- Risques liés à l’administration déléguée
-
L'administration déléguée est une fonctionnalité des plateformes cloud qui permet à une organisation (un partenaire ou un fournisseur de services gérés) d'administrer l'environnement cloud d'une autre organisation pour son compte : le personnel du partenaire peut accéder au locataire du client avec des privilèges d'administration au moyen de ses propres identifiants organisationnels, sans avoir été cré
les risques liés à l’administration déléguée sont importants en TPRM, car les relations d’administration déléguée représentent l’un des droits d’accès les plus privilégiés qu’une organisation puisse accorder à un fournisseur : un accès administrateur à l’ensemble d’un locataire cloud, régi par les politiques de sécurité du fournisseur plutôt que par celles du client.
- Risques liés à l’administration déléguée : les preuves
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : justification opérationnelle actuelle de chaque relation d’administration déléguée ; politique de MFA pour le personnel du partenaire lors des sessions d’administration déléguée ; spécification des rôles GDAP en cas de relation de partenariat avec Microsoft.
- Suppression ou destruction
-
La suppression retire les données des systèmes actifs, de sorte qu’elles ne sont plus disponibles en fonctionnement normal. La destruction les rend irrécupérables partout où elles existent, y compris dans les sauvegardes, répliques, instantanés, journaux, exports analytiques et caches. Une demande d’effacement est satisfaite par la première et auditée au regard de la seconde.
les sauvegardes sont l'endroit où l'effacement échoue. Les données supprimées de la base de production persistent dans les sauvegardes nocturnes pendant leur durée de conservation, dans les réplicas jusqu'à leur synchronisation, dans les extractions de l'entrepôt de données jusqu'au prochain chargement complet, et dans les journaux jusqu'à leur rotation. Un responsable du traitement qui a confirmé l'effacement alors que tous ces emplacements contiennent encore les données a fait une déclaration qui n'est pas vraie.
- Angles morts des dépendances (SCA)
-
L’analyse de la composition logicielle consiste à identifier et à évaluer les bibliothèques open source et tierces incluses dans l’arbre de dépendances d’une application, en recensant les composants dont dépend l’application, les vulnérabilités connues de ces composants et les obligations de licence qu’ils créent.
Log4Shell a démontré à grande échelle ce que les praticiens du risque lié aux tiers avaient compris en théorie : la posture de sécurité d'un fournisseur pour les applications qu'il livre est en grande partie déterminée par la posture de sécurité de chaque bibliothèque de son arbre de dépendances, y compris les dépendances qu'il n'a pas choisies et dont il ignore peut-être l'existence.
- Angles morts des dépendances (SCA) : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : confirmation de la couverture des dépendances transitives, avec le nom de l'outil et la description du périmètre d'analyse ; SBOM au format CycloneDX ou SPDX, à jour au cours du dernier cycle de publication ; engagement sur le délai moyen de prise de connaissance des CVE critiques des dépendances (un délai, pas une description de processus).
- Attaques par confusion de dépendances
-
La confusion de dépendances est importante pour la TPRM parce qu'il s'agit d'une attaque de la chaîne d'approvisionnement à laquelle vos fournisseurs peuvent être vulnérables, en particulier les éditeurs de logiciels et les fournisseurs d'outils de développement qui utilisent des registres de paquets internes en plus de dépendances publiques.
la confusion de dépendances est importante pour la TPRM parce qu'il s'agit d'une attaque de la chaîne d'approvisionnement à laquelle vos fournisseurs peuvent être vulnérables, en particulier les éditeurs de logiciels et les fournisseurs d'outils de développement qui utilisent des registres de paquets internes en plus de dépendances publiques.
- Attaques par confusion de dépendances : les éléments probants
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : réservation des noms de paquets internes sur les registres publics ; isolation de l’environnement de compilation vis-à-vis des accès réseau externes ; un fournisseur qui affirme appliquer des pratiques de compilation sécurisées doit être interrogé précisément sur l’atténuation de la confusion de dépendances. La sécurité de l’environnement de compilation inclut la configuration des registres, et pas seulement la revue de code et l’analyse statique.
- Épinglage des dépendances ou versions flottantes
-
L'épinglage des dépendances est important pour la TPRM parce que des spécifications de versions flottantes dans le code d'un fournisseur signifient que le logiciel qu'il a livré hier peut différer de celui qu'il compilera demain, même si aucune ligne du code applicatif n'a changé. Pour la sécurité de la chaîne d'approvisionnement, la reproductibilité de la résolution des dépendances est un contrôle fondamental.
l'épinglage des dépendances est important pour la TPRM parce que des spécifications de versions flottantes dans le code d'un fournisseur signifient que le logiciel qu'il a livré hier peut différer de celui qu'il compilera demain, même si aucune ligne du code applicatif n'a changé.
- Épinglage des dépendances ou versions flottantes : les éléments probants
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : existence de fichiers de verrouillage dans les dépôts de production ; application des fichiers de verrouillage dans le pipeline CI/CD ; outils automatisés de mise à jour des dépendances, Dependabot ou Renovate.
- Automatisation des mises à jour des dépendances
-
La qualité de l'automatisation des mises à jour de dépendances est importante pour la TPRM parce que la présence d'une automatisation est la confirmation facile : vérifier que Dependabot est configuré prend quelques secondes. Savoir si cette automatisation réduit réellement l'exposition aux vulnérabilités des dépendances exige de comprendre les taux de fusion, l'ancienneté des demandes en attente et la priorisation des mises à jour de sécurité.
la qualité de l'automatisation des mises à jour de dépendances est importante pour la TPRM parce que la présence d'une automatisation est la confirmation facile : vérifier que Dependabot est configuré prend quelques secondes.
- Automatisation des mises à jour des dépendances : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : taux de création et de fusion des PR de mises à jour de sécurité ; configuration de la priorisation des mises à jour de sécurité par rapport aux autres mises à jour ; un fournisseur qui confirme utiliser Dependabot ou une automatisation des mises à jour de dépendances doit être interrogé sur le taux de fusion. L'automatisation configurée, c'est l'outil. Le taux de fusion est l'indicateur d'efficacité. 847 demandes de fusion générées et 23 fusionnées, ce n'est pas de la gestion de la sécurité des dépendances.
- Isolation des environnements de déploiement
-
L’isolation des environnements de déploiement est importante en TPRM, car les environnements de préproduction qui traitent des données de production ou partagent des identifiants avec les systèmes de production créent des risques de sécurité qui ne sont pas pris en compte dans les évaluations de sécurité de l’environnement de production.
l’isolation des environnements de déploiement est importante en TPRM, car les environnements de préproduction qui traitent des données de production ou partagent des identifiants avec les systèmes de production créent des risques de sécurité qui ne sont pas pris en compte dans les évaluations de sécurité de l’environnement de production.
- Isolation des environnements de déploiement : les éléments probants
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : confirmation du processus d'assainissement des données et de sa validation ; documentation des identifiants distincts par niveau d'environnement ; un fournisseur qui confirme ses contrôles d'accès aux données de production doit être interrogé sur l'isolation des données et des identifiants des environnements hors production. Les contrôles de production protègent les données de production. L'isolation des environnements détermine si ces données atteignent des environnements où les mêmes contrôles ne s'appliquent pas.
- Capacités de retour arrière et de reprise des déploiements
-
Les capacités de retour arrière sont importantes pour la TPRM parce qu'elles déterminent la rapidité avec laquelle un fournisseur peut se rétablir après un déploiement problématique, y compris un déploiement contenant une vulnérabilité ou une compromission de la chaîne d'approvisionnement.
les capacités de retour arrière sont importantes en TPRM, car elles déterminent la rapidité avec laquelle un fournisseur peut se remettre d’un déploiement problématique, y compris d’un déploiement contenant une vulnérabilité ou une compromission de la chaîne d’approvisionnement.
- Capacités de retour arrière et de reprise des déploiements : les éléments probants
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : exemple récent d’exécution d’un retour arrière avec mesure du temps ; processus d’évaluation de la réversibilité des migrations de base de données ; infrastructure d’indicateurs de fonctionnalité pour les scénarios de retour arrière complexes.
- Critères de description
-
Les critères de description, publiés dans la section 200 de DC, régissent ce que doit contenir une description de système : les services fournis, les principaux engagements de service et exigences du système, les composants du système, les aspects pertinents de l’environnement de contrôle, les incidents survenus pendant la période et les critères utilisés. Toute description SOC 2 suit cette structure.
cela explique pourquoi les descriptions de systèmes de fournisseurs sans lien entre eux se lisent comme si elles avaient été rédigées à partir du même modèle. C'est le cas, dans la mesure où les mêmes critères les ont façonnées. Cela signifie aussi qu'un élément manquant se remarque : une description sans section sur les incidents, ou sans déclaration des engagements de service, a omis quelque chose que les critères exigent.
- Angles morts de détection
-
Les angles morts de détection sont les parties d'un environnement technologique qui ne sont pas couvertes par la configuration actuelle de la surveillance de sécurité : les systèmes, services et environnements qui génèrent des événements pertinents pour la sécurité mais ne sont pas configurés pour transmettre ces événements à la plateforme de surveillance où le SOC peut les détecter et y répondre.
les angles morts de détection sont importants pour la TPRM parce que la couverture de surveillance d'un fournisseur n'est jamais plus exhaustive que son dernier audit de configuration, et dans les environnements en croissance rapide, l'écart entre la configuration et l'environnement réel peut représenter une part importante de la surface d'attaque.
- Angles morts de la détection : les preuves
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : comparaison entre l’inventaire des environnements et la configuration de la surveillance ; pourcentage de couverture de l’environnement actuel ; confirmation du processus de déploiement de la configuration de surveillance.
- Lacunes de l'ingénierie de détection
-
L’ingénierie de la détection est la discipline qui consiste à concevoir, construire, tester et maintenir la logique de détection (règles de corrélation, analyses comportementales et politiques de détection des anomalies) qui permet à un SIEM et à un SOC d’identifier une activité malveillante dans un environnement donné.
les lacunes de l'ingénierie de détection sont importantes pour la TPRM parce que la capacité de détection du SOC ne vaut que par les règles qui ont été élaborées et maintenues.
- Lacunes de l’ingénierie de détection : les preuves
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : ratio entre règles personnalisées et règles par défaut ; nombre de règles propres au secteur et couverture des techniques ; fréquence de test des règles et date du dernier test.
- Équilibre entre détection et prévention
-
Le problème de l'équilibre entre détection et prévention dans l'évaluation de la sécurité des fournisseurs est la difficulté de comprendre si l'absence de violation chez un fournisseur reflète une capacité de prévention efficace ou simplement une faible exposition aux attaques. Les deux produisent le même historique de violations.
l'équilibre entre détection et prévention est important pour la TPRM parce que les cibles de la chaîne d'approvisionnement sont choisies précisément pour leur accès à des données de grande valeur, et les fournisseurs qui détiennent ou traitent des données de grande valeur subiront une pression d'attaque croissante à mesure que la valeur de leurs données sera connue des acteurs malveillants.
- Équilibre entre détection et prévention : les éléments probants
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : historique des quasi-incidents (attaques importantes évitées) ; taux et volume de blocage de la sécurité de la messagerie ; délais de correction des vulnérabilités critiques.
- Écarts de parité entre développement et production
-
La parité entre développement et production est le principe selon lequel les environnements de développement, de préproduction et de production doivent être aussi semblables que possible, afin d’éviter que surviennent en production des problèmes qui n’ont pas été détectés lors des tests.
pour les praticiens en TPRM, la parité entre développement et production est le problème de fiabilité qui sous-tend tous les résultats de tests de sécurité des fournisseurs.
- Problèmes de parité entre développement et production : les éléments probants
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : documentation du périmètre des tests d'intrusion confirmant que l'environnement de production a été testé, ou vérification documentée de la parité entre la préproduction et la production ; divulgation de la configuration propre à la production (tous les paramètres, fonctionnalités ou intégrations de production non couverts par les tests de sécurité) ; documentation du processus de gestion des changements en production, y compris la synchronisation de la revue de sécurité et des tests.
- Confiance dans les appareils pour l’accès des fournisseurs
-
La confiance dans les appareils est la composante de la gouvernance des accès qui évalue la posture de sécurité du terminal à partir duquel l'accès est demandé : elle détermine si l'appareil est géré par l'organisation (ou par une organisation de confiance), s'il satisfait aux exigences de conformité définies, s'il dispose d'une protection des terminaux à jour et s'il est capable de répondre aux org
la confiance dans les appareils est importante pour la TPRM parce que l'accès des fournisseurs aux environnements des clients signifie que les données de session, les fichiers téléchargés et le contenu mis en cache provenant des systèmes des clients résident sur les appareils des ingénieurs du fournisseur, et la sécurité de ces données une fois qu'elles atteignent le terminal du fournisseur dépend entièrement de la posture de sécurité de ses terminaux.
- Confiance dans les appareils pour l’accès des fournisseurs : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : confirmation de l'enrôlement MDM des appareils utilisés pour accéder aux environnements des clients ; documentation de la politique de conformité des appareils (niveau de correctifs, protection des terminaux, chiffrement) ; confirmation de la capacité d'effacement à distance et du délai d'intervention.
- DevSecOps pour les systèmes anciens
-
Le DevSecOps des systèmes anciens est important en TPRM, car les fournisseurs des entreprises maintiennent souvent des systèmes anciens qui continuent de traiter des données métier critiques pendant qu’ils investissent dans la modernisation.
le DevSecOps des systèmes hérités est important pour la TPRM parce que les fournisseurs d'entreprise maintiennent souvent des systèmes hérités qui continuent de traiter des données métier critiques pendant que le fournisseur investit dans la modernisation.
- DevSecOps pour les systèmes hérités : les éléments probants
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : tests de sécurité du processus de livraison historique (analyse des dépendances, SAST) ; volet sécurité dédié à l’existant pendant la migration ; inventaire de la dette de sécurité de l’existant et plan de remédiation.
- Modèle de maturité DevSecOps pour l’évaluation TPRM
-
L'évaluation de la maturité DevSecOps est importante pour la TPRM parce que la qualité du logiciel d'un fournisseur, en particulier la densité de vulnérabilités non détectées dans le code livré, est directement corrélée à l'efficacité de son programme DevSecOps, et pas seulement à la sophistication de sa description.
l’évaluation de la maturité DevSecOps est importante en TPRM, car la qualité des logiciels d’un fournisseur, et plus précisément la densité de vulnérabilités non détectées dans le code livré, est directement corrélée à l’efficacité de son programme DevSecOps, et pas seulement à la sophistication de sa description.
- Modèle de maturité DevSecOps pour l'évaluation en TPRM : les éléments probants
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments probants à demander plutôt que des assurances : le nombre de points de contrôle bloquants par rapport aux points consultatifs ; le stock actuel de constats critiques et élevés ; l’évolution nette de ce stock au dernier trimestre.
- Digital Trust Common Framework DTCF
-
Le cadre de contrôles commun de l’Association : des objectifs normalisés, mis en correspondance avec les référentiels utilisés par les professionnels, publiés gratuitement.
Les correspondances sont qualifiées, et une cellule vide est enregistrée comme une absence délibérée, avec sa justification, plutôt que masquée.
See also: scope, control-owner
- Règles de prospection directe
-
Le marketing direct électronique en Europe est régi par la directive ePrivacy, transposée au niveau national par les PECR au Royaume-Uni et par des textes équivalents ailleurs, parallèlement au GDPR qui ne la remplace pas. ePrivacy fixe des règles pour les courriels, les SMS et les appels non sollicités, en exigeant généralement le consentement préalable des particuliers, avec une exception d'accord implicite pour les clients existants, et en appliquant des règles différentes aux abonnés professionnels.
les équipes satisfont au GDPR en identifiant une base légale et supposent que le marketing est couvert. Ce n'est pas le cas. Le GDPR régit le traitement des données personnelles ; ePrivacy régit l'envoi du message, et les deux doivent être respectés. Une base fondée sur l'intérêt légitime au titre du GDPR ne l'emporte pas sur une exigence de consentement au titre d'ePrivacy.
- Sécurité DNS et risque fournisseur
-
la sécurité DNS est importante en TPRM, car les contrôles au niveau DNS constituent une capacité de prévention et de détection économique qui réduit fortement l’efficacité de l’hameçonnage et des communications C2 des logiciels malveillants, deux des principaux vecteurs d’attaque contre les employés des fournisseurs.
la sécurité DNS est importante en TPRM, car les contrôles au niveau DNS constituent une capacité de prévention et de détection économique qui réduit fortement l’efficacité de l’hameçonnage et des communications C2 des logiciels malveillants, deux des principaux vecteurs d’attaque contre les employés des fournisseurs.
- Sécurité DNS et risque fournisseur : les éléments probants
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : confirmation du filtrage DNS avec renseignement sur les menaces ; un fournisseur qui affirme la sécurité de son réseau doit être interrogé sur la sécurité DNS. Le filtrage DNS bloque l’hameçonnage et la résolution C2 au niveau du réseau. La journalisation DNS offre une visibilité sur les indicateurs de compromission. Ce sont deux contrôles de la couche réseau qui réduisent fortement l’efficacité des attaques pour un faible coût.
- Profondeur de la diligence raisonnable selon le niveau du fournisseur
-
La profondeur de la diligence raisonnable est importante parce que le risque que représente un fournisseur n'est pas réduit par la collecte de preuves confirmant que ses contrôles sont documentés : il l'est par la compréhension de leur mise en œuvre effective.
la profondeur de la diligence raisonnable est importante car le risque que représente un fournisseur n’est pas réduit en collectant des preuves confirmant que ses contrôles sont documentés ; il l’est en comprenant si ces contrôles sont effectivement mis en œuvre.
- Profondeur de la diligence raisonnable selon le niveau du fournisseur : les preuves
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : rapport SOC 2 avec la description des tests réalisés ; clarification des inclusions et exclusions du périmètre ; lettre de liaison pour l’actualité si le rapport date de plus de six mois.
- Questionnaires de diligence raisonnable
-
Un questionnaire de diligence raisonnable est un ensemble de questions adressées à un fournisseur sur ses pratiques de sécurité et de protection de la vie privée. Ses réponses vous indiquent ce que le fournisseur est prêt à s’engager à faire par écrit, ce qui est utile, et les pratiques qu’il dit avoir, ce qui est une affirmation. Il ne vous dit pas si un contrôle fonctionne, car le fournisseur décrit une intention et personne ne l’a testée.
les questionnaires sont l'instrument le plus utilisé et le moins examiné de toute la discipline. Des centaines de questions partent, les réponses reviennent des semaines plus tard, quelqu'un les note, et ensuite personne ne peut dire ce qui a été établi, au-delà du fait que le fournisseur remplit des questionnaires. Pourtant, les acheteurs continuent de les envoyer, parce que c'est la seule chose qui passe à l'échelle.
E
- Surveillance des employés
-
La surveillance au travail, qu'elle porte sur les courriels, l'utilisation du web, la localisation, les frappes au clavier ou la productivité, constitue un traitement de données personnelles et relève pleinement du droit de la protection des données. Le consentement est en général une base non valable pour celle-ci, car le déséquilibre des pouvoirs entre employeur et employé empêche que le consentement soit donné librement. L'intérêt légitime, assorti d'une analyse documentée et d'une réelle transparence, est la voie défendable habituelle, et certaines juridictions ajoutent des exigences propres au droit du travail.
les outils de surveillance sont souvent déployés en vertu d’une clause de consentement figurant dans le contrat de travail, au motif que la signature du contrat valait consentement. Ce n’était pas le cas, et les régulateurs l’ont répété à maintes reprises. Le salarié n’avait pas de choix réel, et un consentement sans choix n’est pas un consentement.
- Chiffrement au repos et en cours d’utilisation
-
La confirmation du chiffrement au repos est l’un des contrôles de sécurité les plus souvent cités dans les réponses des fournisseurs aux questionnaires : il est visible, vérifiable et documenté dans les rapports SOC 2.
la confirmation du chiffrement au repos est l’un des contrôles de sécurité les plus souvent cités dans les réponses des fournisseurs aux questionnaires : il est visible, vérifiable et documenté dans les rapports SOC 2.
- Chiffrement au repos ou en cours d'utilisation : les éléments probants
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : description de l'architecture de gestion des clés (service KMS, séparation entre l'accès aux clés et l'accès aux données) ; description de la protection en cours d'utilisation (contrôles d'accès, chiffrement au niveau des champs ou informatique confidentielle pour les données les plus sensibles) ; confirmation de la couverture TLS des communications entre services internes.
- Niveaux de risque du règlement sur l'IA
-
Le règlement européen sur l’IA classe les systèmes d’IA selon leur usage plutôt que selon leur technique. Les pratiques interdites sont purement et simplement prohibées. Les usages à haut risque, énumérés dans ses annexes et comprenant l’emploi, le crédit, l’éducation, les services essentiels et l’application de la loi, sont soumis à des obligations importantes. Les systèmes soumis à des obligations de transparence, comme ceux qui interagissent avec des personnes ou génèrent du contenu, doivent le signaler. Tout le reste n’est soumis qu’à peu d’obligations au-delà du droit commun.
le niveau de risque décide de tout, et la plupart des organisations évaluent comme si la question n'existait pas. Un modèle qui classe les réapprovisionnements d'entrepôt et un modèle qui classe les candidats à un emploi ont une architecture similaire et des obligations entièrement différentes, parce que le second relève d'un usage à haut risque. Votre rôle compte aussi : les fournisseurs qui mettent un système sur le marché ont davantage d'obligations que les déployeurs qui l'utilisent, même si les déployeurs de systèmes à haut risque ont de réelles obligations, notamment le contrôle humain et la surveillance.
- Calendriers de preuves
-
Un calendrier des preuves indique, pour chaque contrôle, la pièce qui prouve qu'il s'est exécuté, le système dont elle provient, la personne nommément chargée de la produire, la fréquence, la durée de conservation et l'emplacement de stockage. Les preuves destinées à un rapport de Type II ou à une certification doivent couvrir toute la période ; elles sont donc produites chaque mois et chaque trimestre pendant la période d'observation plutôt que rassemblées à la fin, et c'est le calendrier qui permet d'y parvenir.
l'essentiel des difficultés d'audit tient aux preuves. Les contrôles fonctionnent généralement. Ce qui échoue, c'est la capacité à montrer qu'ils ont fonctionné, pour la période, à partir d'une source à laquelle l'auditeur peut se fier, sans trois semaines de recherches dans les systèmes. Une liste de quarante demandes arrive, chacune est transmise à un responsable du contrôle qui exporte quelque chose et fait une capture d'écran d'autre chose, la moitié des pièces ne sont pas datées, et deux ont été produites cette semaine pour un contrôle censé s'exécuter chaque trimestre.
- Caractère suffisant des preuves
-
Des preuves suffisantes montrent ce qui s’est passé, quand, dans quel système, par qui, et couvrent la période testée. Elles sont assez complètes pour que l’auditeur n’ait à croire personne sur parole pour ce qu’elles ne montrent pas.
la plupart des preuves rejetées ne sont pas fausses. Elles sont incomplètes. Une capture d'écran sans horodatage, sans identifiant de système et sans indication de périmètre prouve que quelque chose a existé à un moment inconnu sur un écran inconnu. Elle ne peut être rattachée ni au contrôle, ni à la période, ni à la population, et ne peut donc étayer aucune conclusion.
- Preuve ou attestation
-
L'attestation est une déclaration faite par une personne habilitée affirmant qu'une condition est remplie, généralement sur la base de sa connaissance, de sa conviction ou de sa compréhension des politiques, normes et pratiques de l'organisation.
la distinction entre preuve et attestation est importante pour la TPRM parce que le risque de sécurité créé par une relation fournisseur est déterminé par la configuration réelle des systèmes qui traitent les données des clients, et non par la norme de l'organisation ou par la conviction du CISO quant au respect de cette norme.
- Preuve ou attestation : les éléments probants
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : enregistrements de configuration du chiffrement au niveau des systèmes ou résultats de l’outil de CSPM ; liste de tous les systèmes contenant des données clients, avec leur configuration de chiffrement ; documentation des exceptions, c’est-à-dire de tout système non conforme à la norme déclarée.
- Abus de la gestion des exceptions
-
La gestion des exceptions est le mécanisme de gouvernance qui permet de reconnaître que des circonstances opérationnelles précises créent de réelles contraintes empêchant la mise en œuvre d'une exigence de sécurité de référence, et de gérer formellement ces situations au moyen de contrôles compensatoires, d'une acceptation documentée du risque résiduel et de délais définis soit pour la r
l’abus de la gestion des exceptions est important en TPRM, car les référentiels de sécurité de base des fournisseurs confirmés par questionnaire peuvent s’accompagner de registres d’exceptions étendus qui soustraient systématiquement une part importante de l’environnement aux exigences de base.
- Abus de la gestion des exceptions : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : répartition des exceptions par ancienneté et nombre de récurrences ; taux de conformité de référence pour les exigences critiques ; feuilles de route de mise en œuvre pour les exceptions de report.
- Processus de gestion des exceptions
-
Une exception est la décision qu’un contrôle ou une politique ne s’appliquera pas dans un cas précis pendant une période précise. Elle exige tout ce qu’exige une acceptation, plus un périmètre et une revue avant l’expiration. La dérive typique est l’exception permanente : accordée pour une migration de six mois, jamais réexaminée, toujours en vigueur quatre ans plus tard et dont dépendent désormais des systèmes construits après elle.
un programme de contrôle sans voie d'exception produit deux résultats, tous deux mauvais. Soit les personnes contournent discrètement le contrôle, soit elles s'arrêtent et l'activité est bloquée. Le processus d'exception est ce qui permet au contrôle de tenir pendant que le cas limite réel est traité de manière visible, avec un nom, une raison et une date.
- Remédiation des exceptions et réponse de la direction
-
Lorsqu’un rapport de type II décrit une exception, la direction peut y joindre une réponse : ce qui s’est passé, pourquoi, ce qui a été fait et quand. La réponse est celle de la direction, et non de l’auditeur, et l’auditeur la rapporte sans la tester.
la réponse vous en apprend davantage sur l’organisation que l’exception elle-même. Une remédiation précise et datée, avec un responsable désigné et une modification du contrôle, se lit très différemment d’un paragraphe rassurant, et cette différence est un signal direct de la manière dont l’organisation traite ses propres défaillances.
- Exceptions
-
Une exception est un cas où un contrôle n’a pas fonctionné comme décrit pendant la période d’observation. Une revue trimestrielle des accès effectuée en retard. Un utilisateur sorti dont l’accès lui a survécu une semaine. Un changement déployé sans l’approbation enregistrée. Le rapport décrit l’exception, les tests de l’auditeur et la réponse de la direction.
les exceptions sont normales. Toute organisation qui exploite des contrôles pendant douze mois manquera quelque chose, et un rapport qui décrit ce qui a été manqué et ce qui a été fait à ce sujet remplit exactement sa fonction. Le nombre d’exceptions importe moins que leur nature et la réponse de la direction.
F
- Faux positifs ou risques ignorés
-
La gouvernance des faux positifs dans les programmes de sécurité des fournisseurs concerne directement la TPRM parce qu'elle détermine ce que les outils de sécurité du fournisseur trouvent réellement et traitent, par opposition à ce qu'ils trouvent et écartent.
la gouvernance des faux positifs dans les programmes de sécurité des fournisseurs concerne directement la TPRM parce qu'elle détermine ce que les outils de sécurité du fournisseur trouvent réellement et traitent, par opposition à ce qu'ils trouvent et écartent.
- Faux positifs et risques ignorés : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : données sur le taux de suppression par niveau de gravité (pourcentage des constats de chaque niveau de gravité supprimés plutôt que corrigés) ; documentation du circuit d'approbation des suppressions confirmant l'exigence d'une revue de sécurité pour les constats élevés et critiques ; confirmation de la corrélation entre tests d'intrusion et SAST (si des constats des tests d'intrusion correspondaient à des constats SAST précédemment supprimés).
- Hygiène des règles de pare-feu et réseaux des fournisseurs
-
L'hygiène des règles de pare-feu est importante pour la TPRM parce que l'architecture de sécurité réseau déclarée par un fournisseur n'est exacte que dans la mesure où son ensemble de règles de pare-feu la reflète.
l'hygiène des règles de pare-feu est importante pour la TPRM parce que l'architecture de sécurité réseau déclarée par un fournisseur n'est exacte que dans la mesure où son ensemble de règles de pare-feu la reflète.
- Hygiène des règles de pare-feu et réseaux des fournisseurs : les preuves
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : nombre de règles de pare-feu et date de la dernière revue ; un fournisseur qui affirme la sécurité de son pare-feu doit être interrogé sur l’hygiène de ses règles. La sécurité d’un pare-feu est la combinaison de son architecture et de la qualité des règles qui la mettent en œuvre. 3,847 règles dont la justification est inconnue ne constituent pas un pare-feu qui met fidèlement en œuvre l’architecture de sécurité voulue.
- Difficultés d’accès pour l’investigation numérique
-
Les difficultés d'accès aux éléments forensiques sont les obstacles pratiques, juridiques et contractuels à l'obtention des preuves forensiques (journaux, images forensiques, captures mémoire, enregistrements du trafic réseau) nécessaires pour mener une enquête indépendante sur un incident de sécurité survenu dans l'environnement d'un fournisseur.
les difficultés d'accès aux éléments forensiques sont importantes pour la TPRM parce que les clients qui ne peuvent pas mener d'enquête forensique indépendante sur une violation chez un fournisseur ne peuvent pas déterminer leur propre exposition avec la précision nécessaire aux déclarations réglementaires, aux demandes d'indemnisation auprès des assureurs et aux procédures judiciaires.
- Difficultés d'accès aux éléments forensiques : les éléments probants
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : procédure d'accès forensique en cas de violation ; engagement de préservation des preuves avant la remédiation ; limitation de la conservation pour litige aux fins de l'enquête du client.
- Risque lié aux quatrièmes parties
-
Une quatrième partie est le fournisseur de votre fournisseur : le cloud sur lequel tourne son logiciel, le prestataire de paiement intégré à son outil de facturation, le service de transcription intégré à sa plateforme de support. Vous ne les avez pas choisis, vous n'avez aucun contrat avec eux, et une panne ou une violation chez l'un d'eux vous atteint par l'intermédiaire d'une entreprise dont vous n'avez jamais entendu parler.
deux problèmes se posent ici et ils appellent des réponses différentes. La visibilité, lorsque vous ne pouvez pas dire qui fait partie de la chaîne avant que quelque chose ne casse. Et la concentration, lorsque bon nombre de vos fournisseurs supposément indépendants s'avèrent reposer sur la même poignée de prestataires, de sorte qu'une seule défaillance arrive par plusieurs portes à la fois et que votre diversification n'était qu'un ensemble de logos sur une seule plateforme.
- Angle mort du risque lié aux quatrièmes parties
-
Le risque lié aux quatrièmes parties est important parce que la surface d'attaque de l'entreprise s'étend à travers les chaînes d'approvisionnement de ses fournisseurs, et pas seulement à travers les fournisseurs eux-mêmes.
le risque lié aux quatrièmes parties est important parce que la surface d'attaque de l'entreprise s'étend à travers les chaînes d'approvisionnement de ses fournisseurs, et pas seulement à travers les fournisseurs eux-mêmes.
- Angle mort du risque lié aux quatrièmes parties : les éléments probants
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : liste complète des sous-traitants ultérieurs avec la fonction de chacun ; identification des fournisseurs d'infrastructure et d'authentification ; confirmation du programme de gestion du risque lié aux tiers du fournisseur lui-même.
G
- Risque géopolitique dans le choix des fournisseurs
-
Le risque géopolitique est important parce qu’il crée une catégorie de risque fournisseur que les évaluations techniques de sécurité traditionnelles ne traitent pas : le risque découlant de l’environnement juridique dans lequel s’inscrivent le personnel, la structure juridique et les activités du fournisseur. Les contrôles techniques protègent les données contre l’accès non autorisé des attaquants.
le risque géopolitique est important parce qu'il crée une catégorie de risque fournisseur que les évaluations de sécurité techniques traditionnelles ne traitent pas : le risque découlant de l'environnement juridique dans lequel évoluent le personnel, la structure d'entreprise et les activités du fournisseur.
- Risque géopolitique dans le choix des fournisseurs : les éléments probants
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : déclaration des juridictions dont relève le personnel occupant des fonctions d’accès aux données ; analyse des lois d’accès gouvernemental pour les juridictions déclarées ; cadre juridique de notification des clients en cas d’accès gouvernemental.
- Modèles de sécurité GitOps
-
La sécurité GitOps est importante en TPRM, car les mises en œuvre GitOps qui accordent de larges permissions à l’opérateur créent un chemin direct entre le droit de fusion sur un dépôt Git et le contrôle du cluster de production.
la sécurité GitOps est importante en TPRM, car les mises en œuvre GitOps qui accordent de larges permissions à l’opérateur créent un chemin direct entre le droit de fusion sur un dépôt Git et le contrôle du cluster de production.
- Modèles de sécurité GitOps : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : contrôles d'accès au dépôt GitOps et approbation des fusions ; un fournisseur qui confirme un déploiement GitOps doit être interrogé sur le RBAC de l'opérateur. Les autorisations de l'opérateur GitOps définissent le rayon d'impact de l'accès en fusion au dépôt GitOps. Un opérateur cluster-admin avec un accès en fusion ouvert crée une autorité de déploiement cluster-admin pour toute personne disposant d'un accès en fusion.
- Lacunes de la responsabilité en matière de gouvernance
-
La responsabilité en matière de gouvernance est le sentiment personnel d’obligation et d’appropriation, éprouvé par une personne précise, de veiller à ce qu’une relation fournisseur soit gouvernée efficacement, que les risques soient gérés et que, lorsque les choses tournent mal, des mesures décisives soient prises sans attendre d’autorisation ni d’instruction.
les lacunes en matière de responsabilité de gouvernance sont importantes en TPRM, car une gestion efficace du risque fournisseur, en particulier dans des situations à fort enjeu comme les incidents de sécurité chez un fournisseur, exige des personnes qui répondent personnellement du résultat et agissent avec détermination.
- Lacunes en matière de responsabilité de gouvernance : les preuves
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : personne nommément désignée, responsable de l’ensemble de la relation ; coordonnées directes, dont un numéro de mobile pour la notification des incidents hors heures ouvrées ; confirmation qu’elle connaît les obligations contractuelles de notification.
- Ambiguïté sur la responsabilité de la gouvernance
-
L'ambiguïté de la responsabilité de gouvernance dans les relations fournisseurs est l'absence d'un responsable unique de l'ensemble de la relation fournisseur, c'est-à-dire la personne ou le rôle chargé de veiller à ce que la relation fonctionne comme prévu, à ce que les risques soient gérés dans toutes leurs dimensions, et à ce que l'escalade et la réponse soient coordonnées lorsque des problèmes a
l’ambiguïté sur la responsabilité de la gouvernance est importante en TPRM, car les relations complexes avec les fournisseurs rencontrent inévitablement des situations qui exigent une réponse coordonnée : incidents de sécurité, défaillances de service, demandes des autorités de régulation, litiges contractuels et changements importants chez le fournisseur.
- Ambiguïté sur la responsabilité de la gouvernance : les preuves
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : responsable désigné de la relation client ; processus d’acheminement des notifications d’incident, c’est-à-dire la manière dont les notifications parviennent au responsable désigné ; délai d’escalade entre un incident de sécurité et la notification au client.
- Limites des outils de GRC
-
Les limites des outils de GRC sont les écarts entre ce qu’une plateforme de GRC est techniquement capable de gérer et ce que le programme de gestion des risques lui fait réellement gérer.
les limites des outils GRC sont importantes en TPRM, car la plateforme GRC sert de plus en plus de preuve de la maturité du programme de gestion des risques, lors des contrôles réglementaires, dans les rapports au conseil d’administration et dans la documentation de diligence raisonnable des fournisseurs.
- Limites des outils de GRC : les éléments probants
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : documentation du processus d'alimentation du programme de GRC ; registres de formalisation des canaux informels de remontée des risques ; évaluation de la couverture de la plateforme au regard du paysage des risques.
H
- Identifiants codés en dur dans les applications des fournisseurs
-
Les identifiants codés en dur sont des valeurs d’authentification (noms d’utilisateur, mots de passe, clés API, clés cryptographiques, jetons ou certificats) intégrées directement dans le code source, le binaire compilé, le micrologiciel, le fichier de configuration ou le script de déploiement d’une application, de telle sorte qu’elles ne peuvent pas être modifiées par les mécanismes de configuration normaux.
les identifiants codés en dur dans les applications des fournisseurs représentent une catégorie de risque qui échappe entièrement au contrôle du client et se situe entièrement dans le code du fournisseur, une combinaison qui crée une position de gouvernance particulière et inconfortable.
- Identifiants codés en dur dans les applications des fournisseurs : les éléments probants
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : preuves de configuration SAST confirmant que les règles de détection des identifiants sont actives et appliquées à l'ensemble du code ; documentation des identifiants par défaut (divulgation complète de tous les identifiants par défaut livrés avec l'application et du mécanisme de modification mis à la disposition des clients) ; confirmation que le périmètre des tests d'intrusion inclut explicitement la recherche d'identifiants codés en dur.
- Systèmes d’IA à haut risque
-
Un système d'IA à haut risque, au sens du règlement européen sur l'IA, est un système utilisé dans un contexte que le règlement énumère dans ses annexes : recrutement et gestion des travailleurs, solvabilité, éducation et notation des examens, accès aux services essentiels, application de la loi, migration et administration de la justice, entre autres. La liste porte sur ce que le système décide, et à propos de qui. Un modèle simple dans un usage à haut risque est à haut risque ; un modèle sophistiqué qui résume vos notes de réunion ne l'est pas.
la plupart des organisations sont des déployeurs de systèmes achetés auprès de fournisseurs, et c'est le cas le plus souvent évalué comme si aucune obligation ne s'appliquait. Le déployeur d'un système à haut risque doit assurer un contrôle humain par des personnes compétentes, surveiller le fonctionnement du système, conserver les journaux, l'utiliser conformément aux instructions du fournisseur et informer les personnes concernées. Rien de tout cela n'est un contrôle de sécurité, et rien de tout cela ne figure dans le SOC 2 du fournisseur.
- Supervision humaine
-
La supervision humaine est la conception qui permet à une personne d’intervenir dans les décisions d’un système d’IA, et elle n’est réelle qu’à quatre conditions. L’examinateur voit suffisamment d’éléments pour juger, c’est-à-dire le résultat et les facteurs qui le sous-tendent plutôt qu’un simple score. Il dispose du temps nécessaire, mesuré au regard de l’objectif de traitement réel. Il a la compétence requise pour la décision. Et passer outre est sans risque sur le plan professionnel, c’est-à-dire qu’il n’est pas évalué d’une manière qui le sanctionne.
« un humain examine tous les résultats » est la phrase la plus courante de la documentation de gouvernance de l’IA et l’une des moins informatives. Supprimez l’une des quatre conditions et la supervision se réduit à une signature. La quatrième est celle que les organisations examinent rarement et c’est généralement la contrainte déterminante : un réviseur évalué sur le nombre de dossiers traités par heure ne passera pas deux minutes à contredire un modèle.
I
- Lacunes dans la détection des anomalies d’identité
-
La détection des anomalies d’identité est la capacité à repérer les modes d’accès qui s’écartent du comportement normal établi, en détectant les événements d’authentification, les modes d’accès, les transferts de données et les caractéristiques de session incompatibles avec le comportement de référence d’un utilisateur ou correspondant à des schémas d’attaque connus.
la détection des anomalies d'identité est importante pour la TPRM parce que le personnel des fournisseurs qui accède aux environnements des clients crée un profil de comportement d'identité qui devrait pouvoir être détecté comme anormal lorsqu'il s'écarte de l'activité normale de support ou d'exploitation.
- Lacunes de détection des anomalies d’identité : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : analyse de la détection du scénario d'attaque (quels signaux l'attaque décrite déclencherait) ; déploiement d'une UEBA avec des références comportementales individuelles ; processus d'établissement de la référence des accès des fournisseurs.
- Expansion de la surface d’attaque des identités
-
La surface d’attaque des identités est l’ensemble des points d’authentification, des systèmes d’identité et des magasins d’identifiants qu’exploite une organisation, c’est-à-dire tous les systèmes où un attaquant pourrait tenter de s’authentifier comme un utilisateur légitime et obtenir un accès.
l'expansion de la surface d'attaque des identités est importante pour la TPRM parce que les fournisseurs qui se sont développés par acquisitions, adoption du SaaS et migration vers le cloud peuvent avoir une surface d'attaque des identités nettement plus étendue que ne le laisse penser la description de leur IdP centralisé.
- Expansion de la surface d’attaque des identités : les preuves
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : inventaire complet des systèmes d’identité au-delà de l’IdP de l’entreprise ; comparaison des politiques d’authentification entre tous les systèmes d’identité ; configuration de l’authentification SaaS, IdP de l’entreprise ou annuaire local.
- Rayon d’impact d’une compromission d’identité
-
Le rayon d’impact est l’étendue des systèmes, des données et des capacités qui deviennent accessibles à un attaquant lorsqu’il compromet un titre d’authentification d’identité donné. C’est la réponse à la question : si ce titre d’authentification était volé maintenant, que pourrait en faire un attaquant ?
le rayon d'impact est important pour la TPRM parce que les relations avec des fournisseurs desservant plusieurs clients rendent possibles des attaques de la chaîne d'approvisionnement à identifiant unique, où la compromission d'une seule identité du fournisseur donne un accès simultané aux environnements de plusieurs clients.
- Rayon d'impact d'une compromission d'identité : les éléments probants
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : périmètre maximal d'accès aux environnements des clients par identifiant ; politique de seuil de rayon d'impact, si elle est définie ; accès JIT pour les identifiants à fort rayon d'impact.
- Risques liés à la confiance dans la fédération d'identités
-
La fédération d’identités est une relation de confiance entre fournisseurs d’identité qui permet aux utilisateurs d’une organisation d’accéder aux ressources d’une autre organisation au moyen des identifiants de leur organisation d’origine.
les risques liés à la confiance dans la fédération d'identités sont importants pour la TPRM parce qu'ils constituent l'équivalent, en IAM, de l'attaque de la chaîne d'approvisionnement : l'adversaire qui ne peut pas compromettre directement la cible compromet un partenaire de confiance et utilise la relation de confiance pour obtenir l'accès.
- Risques liés à la confiance dans la fédération d'identités : les éléments probants
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : documentation de la politique MFA de l'IdP du partenaire (niveau d'application et éventuelles exceptions) ; processus de notification d'une compromission de l'IdP du partenaire, avec délais ; gouvernance du cycle de vie des identités (fréquence de revue des comptes et processus de retrait des accès).
- Lacunes de la gouvernance des identités
-
La gouvernance des identités est le programme de politiques, de processus et d’outils qui garantit que les identités numériques (comptes utilisateurs, comptes de service, identifiants API et autres principaux d’accès) sont créées de façon appropriée, maintenues de façon proportionnée et retirées en temps utile tout au long de leur vie opérationnelle.
les lacunes de la gouvernance des identités sont importantes pour la TPRM parce qu'elles révèlent une différence systématique de maturité de gouvernance entre la manière dont un fournisseur gère les identités de ses propres employés et celle dont il gère les identités du personnel qui accède aux environnements des clients.
- Lacunes de la gouvernance des identités : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : documentation du périmètre de couverture de l'IGA (populations d'identités incluses) ; inventaire des comptes fournisseurs avec la date du dernier rapprochement ; données sur le taux de réalisation des revues d'accès par population d'identités.
- Lacunes de journalisation des identités
-
La journalisation des identités est la capture exhaustive de tous les événements liés aux identités dans un environnement : tentatives d'authentification (réussies et échouées), décisions d'autorisation (accès accordés et refusés), événements du cycle de vie des sessions (création, prolongation, expiration et fin de session), enregistrements des actions privilégiées (ce que les utilisateurs privilégiés ont fait pen
les lacunes de journalisation des identités sont importantes en TPRM, car les fournisseurs qui accèdent aux environnements des clients ont besoin d’une journalisation complète des identités pour détecter les attaques contre leurs propres environnements avant qu’elles n’atteignent les données des clients.
- Lacunes de la journalisation des identités : les éléments probants
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : documentation du périmètre des événements des journaux d'identité (types d'événements capturés) ; confirmation de la journalisation des échecs d'authentification avec alertes dans le SIEM ; durée de conservation des journaux calibrée sur les besoins des enquêtes.
- Vérification de l'identité des fournisseurs
-
La vérification d’identité est le processus consistant à vérifier que la personne qui demande un accès, ou pour laquelle un accès est demandé, est bien celle qu’elle prétend être, en établissant un lien fiable entre une identité numérique (un compte et un identifiant) et une personne réelle précise dont l’identité est confirmée.
la vérification de l'identité des fournisseurs est importante pour la TPRM parce que les propriétés de sécurité de l'accès des fournisseurs (moindre privilège, responsabilité individuelle, surveillance comportementale) reposent toutes sur l'hypothèse que l'identité du titulaire du compte est exacte.
- Vérification de l'identité des fournisseurs : les éléments probants
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : confirmation de la vérification de l'emploi du personnel désigné ; documentation du processus de désignation autorisé (qui peut désigner, et à quel niveau) ; politique de divulgation des sous-traitants et gouvernance de leurs accès.
- Hypothèses de confiance en matière d’identité
-
Les hypothèses de confiance en matière d’identité sont les convictions implicites sur la posture de sécurité et la fiabilité des systèmes d’identité et des pratiques d’accès des fournisseurs, qui sous-tendent les droits d’accès, les contrôles d’accès et les configurations de surveillance appliqués aux relations avec les fournisseurs.
les hypothèses de confiance en matière d'identité sont importantes pour la TPRM parce que les contrôles d'accès, les configurations de surveillance et les mesures d'atténuation des risques appliqués aux accès des identités des fournisseurs sont calibrés en fonction du niveau de confiance évalué du fournisseur.
- Hypothèses de confiance en matière d'identité : les éléments probants
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : déclaration des changements organisationnels (acquisitions, changements de direction, migrations d’infrastructure) ; déclaration des incidents de sécurité, y compris ceux sous le seuil de notification ; données de surveillance continue de la posture de sécurité.
- Mouvement latéral fondé sur l'identité
-
Le mouvement latéral fondé sur l'identité est la technique consistant à parcourir un environnement en enchaînant des étapes légitimes d'identité et d'autorisation : utiliser un jeu d'identifiants valides pour en obtenir un autre, utiliser l'accès à une ressource pour découvrir ou atteindre les identifiants d'une autre, et progresser vers une cible de grande valeur par une suite d'i
les mouvements latéraux fondés sur l’identité sont importants en TPRM, car les environnements des fournisseurs ayant accès aux systèmes des clients sont précisément ceux où une compromission d’identifiants pourrait se propager à travers des chaînes de permissions jusqu’aux données ou à l’infrastructure des clients.
- Mouvements latéraux fondés sur l’identité : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : outil d'analyse des chemins d'attaque et date de la dernière analyse ; registres de remédiation des chemins de mouvement latéral ; documentation des restrictions d'accès aux magasins d'identifiants.
- Classification des incidents
-
La classification des incidents est l’échelle de gravité qui détermine, dans les premières minutes, qui est réveillé, à quelle fréquence les points de situation sont diffusés, si le service juridique est mobilisé et si un ingénieur peut mettre un système hors ligne sans demander l’autorisation. Trois ou quatre niveaux, chacun avec des déclencheurs objectifs que la personne qui découvre le problème peut appliquer, et chacun avec une réponse définie.
la première heure d’un incident est consacrée à des questions auxquelles on aurait pu répondre à l’avance, et le débat sur la gravité suffisante pour une escalade est la plus coûteuse d’entre elles. Une échelle sans déclencheurs devient ce débat au pire moment. Une échelle avec déclencheurs le transforme en simple consultation, et la réponse suit automatiquement.
- Défaillances de la communication en cas d’incident
-
Les ruptures de communication sur les incidents dans les relations fournisseurs sont les défaillances dans la transmission d'informations précises et techniquement utiles de l'équipe IR du fournisseur à l'équipe IR du client pendant un incident partagé, ruptures qui compromettent la capacité du client à comprendre sa propre exposition, à remplir ses propres obligations réglementaires et à con
les défaillances de communication en cas d’incident sont importantes en TPRM, car la capacité du client à remplir ses propres obligations réglementaires (évaluation du risque de violation au titre de HIPAA, notification au titre du GDPR, déclaration d’incidents dans les services financiers) dépend de l’obtention d’informations techniques précises auprès du fournisseur dans les délais réglementaires applicables.
- Défaillances de communication en cas d’incident : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : contact IR nommément désigné pour la communication technique pendant les incidents ; engagement à fournir des détails techniques précis dans un délai défini ; processus de communication d'équipe IR à équipe IR contournant les délais de revue juridique.
- Escalade des incidents entre fournisseurs
-
L’escalade des incidents entre fournisseurs consiste à garantir que les incidents de sécurité survenant dans les environnements des fournisseurs et touchant les données des clients sont remontés au client, et aux autorités réglementaires, dans des délais qui permettent au client de respecter ses obligations réglementaires, et pas seulement selon les SLA internes de gestion des incidents du fournisseur.
l’escalade des incidents entre fournisseurs est importante en TPRM, car les obligations réglementaires du client sont déterminées par la loi, et non par la classification des incidents du fournisseur.
- Escalade des incidents entre fournisseurs : les éléments probants
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : critères de classification des incidents pour les systèmes pertinents pour le client ; délai de notification préliminaire à compter de la détection ; confirmation que le SLA de notification est calibré sur l'échéance réglementaire du client.
- Confusion sur la responsabilité des incidents
-
La confusion sur la responsabilité des incidents est l'absence d'une personne ou d'une équipe unique dotée d'une autorité claire, attribuée à l'avance, pour prendre certaines décisions à fort enjeu pendant un incident de sécurité.
la confusion sur la responsabilité des incidents compte en matière de TPRM parce que la notification de violation par le fournisseur déclenche le délai réglementaire du client, et la boucle d’escalade du client est le mécanisme qui détermine quelle part de ce délai est consommée avant qu’une décision de notification ne soit prise.
- Confusion sur la responsabilité des incidents : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : responsable nommément désigné de la décision de notification aux clients ; responsable nommément désigné de la décision de notification aux autorités de régulation ; coordonnées hors heures ouvrées des responsables de ces décisions.
- Lacunes des playbooks d'incident
-
Les lacunes des playbooks d'incident sont les insuffisances des procédures de réponse aux incidents propres à chaque scénario qui empêchent une exécution efficace dans les conditions d'un incident réel : lacunes d'exhaustivité, d'accessibilité, d'exactitude et de précision opérationnelle qui provoquent des retards, des erreurs ou des échecs lorsque les intervenants tentent d'exécuter le playbook pendant un
les lacunes des procédures d’intervention sont importantes en TPRM, car la qualité de la réponse d’un fournisseur à une violation touchant les données des clients dépend de l’efficacité avec laquelle ses procédures s’exécutent dans les conditions réelles d’un incident, qui peut survenir à 2 heures du matin un samedi, avec un analyste d’astreinte sur son appareil personnel, sans accès au wiki de l’équipe réseau
- Lacunes des playbooks d'incident : les éléments probants
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : date et méthode du test d’opérabilité ; lacunes relevées lors du test d’opérabilité ; conception des procédures, autonomes ou renvoyant à des références externes.
- SLA de réponse aux incidents
-
Les niveaux de service de réponse aux incidents prévus dans les contrats fournisseurs définissent les exigences de délai applicables à des actions de réponse précises : délais de notification, engagements de mise à jour sur l'enquête et échéances d'achèvement de la remédiation. Le respect du SLA se mesure au fait que les actions interviennent ou non dans les délais définis.
Les IR SLA comptent en matière de TPRM parce qu’ils constituent le principal mécanisme contractuel de protection du délai de réponse du client, mais des SLA qui protègent le calendrier sans exiger le contenu qui permet la réponse protègent la relation contractuelle sans protéger la capacité réelle du client à répondre.
- Niveaux de service de réponse aux incidents : les éléments probants
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : exigences relatives au contenu de la notification (ce que la notification contiendra) ; SLA de confirmation du périmètre, lorsque la confirmation du périmètre suit la notification préliminaire ; un fournisseur qui affirme un SLA de notification de quarante-huit heures doit être interrogé sur le contenu de la notification à son arrivée. Le délai est une dimension du SLA. Le contenu en est l’autre. Les deux sont nécessaires pour que la notification permette la réponse qu’elle est censée protéger.
- Réponse aux incidents au titre de CC7
-
CC7 porte sur l’exploitation des systèmes : détection et surveillance des anomalies, évaluation des événements, réponse aux incidents et rétablissement. Il couvre également la communication des incidents aux parties concernées. C’est le critère qui demande si vous remarqueriez un dysfonctionnement et ce que vous feriez pour y remédier.
les auditeurs demandent les incidents survenus pendant la période et suivent leur traitement à travers le processus. N’en avoir aucun soulève en soi une question, car une année sans aucun événement de sécurité est plus probablement une année sans détection qu’une année sans attaque. Le plan est testé au regard de ce qui s’est réellement passé.
- Informations produites par l'entité
-
Les informations produites par l’entité (IPE) désignent tout rapport, liste ou extrait que vous générez et remettez à l’auditeur comme preuve. Une liste d’utilisateurs issue du système d’identité. Un journal des changements issu de l’outil de tickets. Un tableur des résultats de revue des accès. Avant de pouvoir s’y fier, l’auditeur doit s’assurer qu’ils sont complets et exacts.
c'est pourquoi l'auditeur demande à voir la requête, les paramètres, la date à laquelle elle a été exécutée et le système dont elle provient, et parfois à assister à sa génération. Une liste arrivée par courriel sans provenance est une affirmation, pas une preuve, et la valider coûte généralement plus cher que ne l'aurait coûté sa production en bonne et due forme.
- Détection de la dérive de l’infrastructure
-
La dérive de l'infrastructure est importante pour la TPRM parce que la posture de sécurité de l'infrastructure de production d'un fournisseur n'est exacte que dans la mesure où la configuration IaC qui la décrit l'est, et la dérive signifie que la posture réelle peut être moins sûre que ne le laisse penser la documentation IaC.
la dérive de l’infrastructure est importante en TPRM, car la posture de sécurité de l’infrastructure de production d’un fournisseur n’est exacte que dans la mesure où la configuration IaC qui la décrit l’est, et la dérive signifie que la posture réelle peut être moins sûre que ne le laisse penser la documentation IaC.
- Détection de la dérive de l'infrastructure : les éléments probants
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : mise en œuvre et surveillance de la détection de dérive ; date et résultats de la dernière évaluation de la dérive ; processus de changement d’urgence assorti d’une obligation de codification IaC.
- Sécurité du provisionnement de l’infrastructure
-
La sécurité du provisionnement de l'infrastructure est importante pour la TPRM parce que les fournisseurs qui provisionnent automatiquement leur infrastructure au moyen de pipelines CI/CD confient à ces pipelines des identifiants de fournisseurs cloud et des capacités de gestion de l'infrastructure.
la sécurité du provisionnement de l’infrastructure est importante en TPRM, car les fournisseurs qui provisionnent automatiquement leur infrastructure au moyen de pipelines CI/CD confient à ces pipelines des identifiants de fournisseur de cloud et des capacités de gestion de l’infrastructure.
- Sécurité du provisionnement de l’infrastructure : les preuves
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : emplacement de stockage de l’état, avec confirmation du versionnage et de la journalisation des accès ; documentation du contrôle d’accès à l’état (qui peut lire et écrire) ; processus de revue des plans pour les changements en production.
- Risque lié à la chaîne d'approvisionnement de l'infrastructure en tant que code
-
le risque de chaîne d’approvisionnement IaC est important en TPRM, car les fournisseurs qui automatisent leur infrastructure, ce qui est de plus en plus la norme dans les environnements cloud natifs, bâtissent leur infrastructure sur des chaînes de dépendances qui incluent des modules de registres publics.
le risque lié à la chaîne d'approvisionnement de l'IaC est important pour la TPRM parce que les fournisseurs qui automatisent leur infrastructure, ce qui devient la norme dans les environnements cloud natifs, bâtissent leur infrastructure sur des chaînes de dépendances qui incluent des modules de registres publics.
- Risque lié à la chaîne d'approvisionnement de l'infrastructure en tant que code : les éléments probants
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : couverture de l'analyse IaC, y compris le contenu des modules ; registre interne de modules validés ou équivalent ; un fournisseur qui confirme ses pratiques de sécurité IaC doit être interrogé sur la couverture de la chaîne d'approvisionnement des modules. L'analyse de sécurité IaC de son propre code confirme l'enveloppe. L'analyse complète du contenu des modules couvre la chaîne d'approvisionnement.
- Risque inhérent et risque résiduel
-
Le risque inhérent est l’exposition avant l’intervention de tout contrôle. Le risque résiduel est ce qui subsiste après les contrôles dont vous disposez réellement, fonctionnant comme ils fonctionnent réellement. L’écart entre les deux représente la valeur de votre programme de contrôle, et confondre les deux produit des rapports soit alarmants sans raison, soit rassurants sans raison.
un conseil d'administration demande dans quelle mesure l'organisation est exposée, et la réponse honnête dépend du chiffre que vous donnez. Un registre des fournisseurs qui consigne le risque inhérent affiche tous les fournisseurs critiques en rouge et n'indique à personne quoi faire. Un registre qui ne consigne que le risque résiduel masque le fait qu'un seul contrôle peu coûteux sépare un score faible d'un score élevé, ce qui est précisément ce qu'un conseil d'administration devrait savoir.
- Hiérarchisation du risque inhérent
-
La hiérarchisation selon le risque inhérent est le processus de classement des relations fournisseurs selon leur risque potentiel pour l’organisation, avant l’évaluation des contrôles, à partir de caractéristiques objectives de la relation : les données auxquelles le fournisseur accède, les services qu’il fournit, les systèmes auxquels il se connecte et la criticité opérationnelle qu’il représente.
la hiérarchisation selon le risque inhérent est importante car, sans elle, l’effort de diligence raisonnable est réparti selon la commodité administrative plutôt que selon le risque.
- Hiérarchisation selon le risque inhérent : les preuves
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : critères de hiérarchisation précis avec seuils ; questionnaire ou périmètre d’évaluation différencié selon le niveau ; un fournisseur qui affirme mener une diligence raisonnable rigoureuse pour tous ses fournisseurs doit être interrogé sur ses critères de hiérarchisation. Évaluer tous les fournisseurs de la même façon relève soit du théâtre de la proportionnalité, soit d’un échec de la proportionnalité, selon que le questionnaire est calibré sur le niveau de risque le plus élevé ou le plus faible.
- Confusion entre risque inhérent et risque résiduel
-
Le cadre distinguant risque inhérent et risque résiduel est important parce que les scores de risque résiduel déterminent l’allocation des ressources : quels fournisseurs font l’objet d’une surveillance intensive et lesquels d’une supervision plus légère.
le cadre risque inhérent et risque résiduel compte parce que les scores de risque résiduel déterminent l’allocation des ressources : quels fournisseurs font l’objet d’une surveillance intensive, lesquels d’une supervision plus légère.
- Confusion entre risque inhérent et risque résiduel : les éléments probants
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : inclusions et exclusions du périmètre d’évaluation ; confirmation que les systèmes d’interaction sont inclus dans le périmètre ; méthodologie de test des contrôles pour les systèmes inclus.
- Vulnérabilités d'injection dans le code des fournisseurs
-
Les vulnérabilités par injection sont une catégorie de faiblesses de sécurité applicative qui apparaît lorsqu’une application intègre des données non fiables, généralement des entrées fournies par l’utilisateur, dans une commande ou une requête d’une manière qui permet d’interpréter ces données comme faisant partie de la commande plutôt que comme des données à traiter par celle-ci.
les vulnérabilités d'injection dans les applications des fournisseurs ont des conséquences particulièrement lourdes du point de vue du risque lié aux tiers, parce que leur impact ne se limite pas aux données du fournisseur : il s'étend à tout ce à quoi l'application peut accéder, ce qui, dans un contexte SaaS mutualisé, inclut souvent les données de tous les clients simultanément.
- Vulnérabilités d'injection dans le code des fournisseurs : les éléments probants
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments probants à demander plutôt que des assurances : une documentation du périmètre des tests d’intrusion incluant explicitement la couverture des injections pour les fonctionnalités récemment ajoutées et les surfaces d’entrée peu évidentes ; l’historique des constats d’injection avec les délais de remédiation et les preuves de vérification, des constats antérieurs corrigés et vérifiés étant plus rassurants que l’absence de tout constat ; la confirmation de la configuration de la détection des injections SAST, avec le périmètre de couverture du code source.
- Demande d'informations, observation, inspection, réexécution
-
Un auditeur dispose de quatre procédures pour tester un contrôle. L’enquête consiste à demander à quelqu’un comment il fonctionne. L’observation consiste à le regarder s’exécuter. L’inspection consiste à examiner les preuves qu’il a produites. La réexécution consiste à le refaire de manière indépendante et à comparer le résultat. Elles sont présentées ici par ordre de force probante.
la demande d'informations seule ne suffit presque jamais pour un rapport de Type II, parce que s'entendre dire qu'un contrôle fonctionne n'est pas la preuve qu'il a fonctionné. C'est pourquoi « nous leur avons expliqué le processus » ne clôt jamais une demande d'audit, et pourquoi l'auditeur continue de réclamer la pièce après la réunion.
- Accès des initiés chez les fournisseurs
-
La menace interne chez les fournisseurs est le risque que des employés de fournisseurs disposant d’un accès légitime aux données des clients en fassent un usage abusif (pour un gain financier, un avantage concurrentiel, un grief personnel ou sous une contrainte extérieure) d’une manière que les contrôles d’accès n’empêchent pas, parce que l’accès est autorisé, et que la sécurité périmétrique ne détecte pas, parc
l'accès des initiés chez les fournisseurs est important pour la TPRM parce que la relation fournisseur crée une catégorie de personnes, les employés du fournisseur, qui disposent d'un accès autorisé aux données des clients mais ne sont pas soumis aux processus RH, à la formation à la sécurité, à la surveillance comportementale ni aux contrôles liés à l'emploi du client.
- Accès des initiés chez les fournisseurs : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : description de la mise en œuvre de l'analyse comportementale (UEBA appliqué à l'accès aux données, références établies, détection des anomalies configurée) ; confirmation de la surveillance des exportations de données (détection des schémas cumulés avec calibrage des seuils) ; historique des incidents liés aux menaces internes (événements de détection, résultats des enquêtes).
- Menaces internes chez les fournisseurs
-
Les menaces internes chez les fournisseurs désignent le risque que des employés, des prestataires ou des utilisateurs de confiance d'un fournisseur, disposant d'un accès légitime à des systèmes contenant des données de clients, fassent un usage abusif de cet accès, intentionnellement, par négligence ou sous la contrainte, d'une manière qui nuit au client.
les menaces internes chez les fournisseurs sont importantes en TPRM, car le client ne peut pas surveiller directement le comportement des employés du fournisseur : il n’a pas accès à l’UEBA qui détecterait le changement dans les requêtes de l’ingénieur de données, aucune visibilité sur la surveillance des destinations d’export qui signalerait le transfert vers Dropbox, et aucun mécanisme direct pour déte
- Menaces internes chez les fournisseurs : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : confirmation du déploiement de l'UEBA pour le personnel ayant accès aux données des clients ; documentation de la limitation des accès au strict nécessaire ; configuration de la DLP pour la détection des exportations par petits lots.
- Exposition à Internet et gestion de la surface d’attaque
-
La gestion de l’exposition à Internet est importante en TPRM, car les surfaces d’attaque externes confirmées par les fournisseurs diffèrent souvent des services réellement accessibles depuis l’extérieur, en raison de l’informatique fantôme, des erreurs de configuration et de la nature dynamique de l’infrastructure cloud.
la gestion de l’exposition à Internet est importante en TPRM, car les surfaces d’attaque externes confirmées par les fournisseurs diffèrent souvent des services réellement accessibles depuis l’extérieur, en raison de l’informatique fantôme, des erreurs de configuration et de la nature dynamique de l’infrastructure cloud.
- Exposition sur Internet et gestion de la surface d'attaque : les éléments probants
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : comparaison entre les résultats d'analyse et l'inventaire documenté.
- Sécurité IPv6 : le protocole que votre équipe de sécurité a peut-être oublié
-
IPv6 activé : par défaut sur tous les terminaux. Surveillance IPv6 : aucune.
la sécurité IPv6 est importante en TPRM, car IPv6 est activé par défaut dans la plupart des environnements modernes, et les attaquants qui le savent peuvent utiliser des chemins de communication IPv6 pour contourner les contrôles de sécurité IPv4.
- ISAE 3402 et équivalents internationaux
-
La norme ISAE 3402 est la norme internationale d'assurance applicable aux rapports sur les contrôles d'une organisation de services, publiée par l'IAASB et non par l'AICPA, et globalement équivalente à un rapport SOC 1. La norme ISAE 3000 est la norme plus large applicable aux missions d'assurance autres que les audits d'informations financières, en vertu de laquelle sont émis, hors des États-Unis, des rapports couvrant les contrôles de sécurité et opérationnels.
les fournisseurs en Europe, au Royaume-Uni, en Australie et ailleurs détiennent souvent ces rapports plutôt qu’un SOC 2, et ils sont légitimes. Un fournisseur britannique disposant d’un rapport ISAE 3000 sur les contrôles de sécurité a été examiné par un professionnel indépendant selon une norme reconnue, et le rejeter parce qu’il ne s’appelle pas SOC 2 est une erreur.
- Déclaration d’applicabilité ISO 27001
-
La déclaration d’applicabilité est le document ISO 27001 qui énumère chaque contrôle de l’annexe A de la norme, indique s’il s’applique à votre organisation, la justification et son état de mise en œuvre. Elle est exigée par la norme, mentionnée sur le certificat, et c’est le premier document qu’ouvre un auditeur de certification, car tout le reste de l’audit en découle.
le certificat vous indique qu’une organisation est certifiée. La déclaration d’applicabilité vous dit ce que cela signifie : quels contrôles sont couverts par l’audit, lesquels ont été exclus et pourquoi, et si les exclusions relèvent de la pertinence ou de la commodité. Un fournisseur incapable de produire sa déclaration d’applicabilité sur demande vous a appris quelque chose sur la manière dont la certification a été obtenue.
- ISO 42001
-
ISO 42001 est la norme de système de management de l’IA, structurée comme ISO 27001 : des articles sur le contexte, le leadership, la planification, le support, le fonctionnement, l’évaluation et l’amélioration, avec une annexe de mesures spécifiques à l’IA. Elle est certifiable, ce qui signifie qu’un organisme accrédité peut réaliser un audit sur cette base et délivrer un certificat assorti d’une déclaration de périmètre.
les acheteurs qui demandent la norme ISO 27001 pour la sécurité commencent à demander la norme ISO 42001 pour l’IA, en particulier lorsqu’un produit prend des décisions concernant des personnes. Elle est aussi évoquée en interne comme le moyen de doter la gouvernance de l’IA des mêmes mécanismes que la gouvernance de la sécurité : un périmètre, une appréciation des risques, une déclaration d’applicabilité, un audit interne et une revue de direction.
J
- Arrivées, mobilités, départs
-
Le processus arrivée, mobilité, départ est le processus par lequel l'accès est accordé lorsqu'une personne arrive, ajusté lorsqu'elle change de rôle et retiré lorsqu'elle part. Les arrivées sont traitées parce que quelqu'un doit travailler. Les départs sont traités, tôt ou tard, parce qu'un audit le vérifie. C'est lors des mobilités que les accès s'accumulent, parce qu'ajouter un accès est une demande que quelqu'un formule, alors que retirer l'ancien accès n'est la tâche de personne.
c'est le contrôle à l'origine de la moitié des constats de tout audit des accès, c'est le mécanisme que la plupart des contrôles complémentaires de l'entité utilisatrice figurant dans les rapports des fournisseurs supposent que vous exploitez, et c'est là que le compte d'un utilisateur parti modifie des coordonnées bancaires dix-huit mois après son départ. Les auditeurs le testent en rapprochant le flux RH des créations et suppressions de comptes, et c'est dans ce rapprochement que les lacunes apparaissent.
- Responsables conjoints du traitement
-
Lorsque deux organisations ou plus déterminent conjointement les finalités et les moyens d'un traitement, elles sont responsables conjoints du traitement. Le GDPR leur impose de définir leurs obligations respectives dans un accord transparent, notamment qui traite les demandes d'exercice des droits des personnes concernées et qui fournit la politique de confidentialité, et de mettre les grandes lignes de cet accord à la disposition des personnes concernées.
la responsabilité conjointe du traitement naît sans que personne ne l’ait voulu. Une campagne co-marquée où les deux parties décident qui cibler. Une plateforme partagée où les deux parties déterminent ce qui est collecté. Un accord de recommandation où les deux utilisent les mêmes données à leurs propres fins. Les juridictions ont retenu la responsabilité conjointe du traitement dans des montages que les parties décrivaient autrement.
- Accès juste-à-temps ou accès permanent
-
L'accès juste-à-temps est un modèle d'accès à privilèges dans lequel des identifiants à privilèges élevés sont attribués au besoin pour une tâche précise et automatiquement révoqués lorsque la tâche est terminée ou qu'une durée définie expire.
l’accès JIT par opposition à l’accès permanent est important en TPRM, car les contrats de support et de services gérés des fournisseurs impliquent souvent un accès à privilèges permanent aux environnements des clients : un accès provisionné pour la disponibilité, qui représente une exposition continue des identifiants pendant toute la durée de la relation avec le fournisseur.
- Accès juste-à-temps ou accès permanent : les preuves
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : confirmation d’un accès JIT ou documentation justifiant les accès permanents ; indicateurs d’utilisation des accès (heures utilisées par rapport aux heures de validité de l’identifiant) ; confirmation de la plateforme PAM pour le provisionnement JIT.
K
- Sécurité de Kubernetes dans la CI/CD
-
La sécurité de la configuration Kubernetes compte en matière de TPRM parce que les erreurs de configuration des clusters Kubernetes constituent souvent le chemin exploitable qui transforme une vulnérabilité de conteneur en compromission du cluster.
la sécurité de la configuration de Kubernetes est importante pour la TPRM parce que les erreurs de configuration des clusters Kubernetes sont souvent le chemin exploitable qui transforme une vulnérabilité de conteneur en compromission du cluster.
- Sécurité de Kubernetes en CI/CD : les preuves
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : analyse des manifestes Kubernetes dans le pipeline CI/CD ; mécanisme d’application du contexte de sécurité des pods ; mise en œuvre des politiques réseau et posture par défaut.
L
- Mouvement latéral et réseaux plats
-
Les mouvements latéraux et les réseaux à plat comptent en matière de TPRM parce que la valeur d’une attaque de la chaîne d’approvisionnement est souvent déterminée non par la prise d’appui initiale, mais par la capacité de mouvement latéral que permet l’architecture du réseau.
les mouvements latéraux et les réseaux plats sont importants en TPRM, car la valeur d’une attaque de la chaîne d’approvisionnement est souvent déterminée non par la prise de pied initiale, mais par la capacité de mouvement latéral que permet l’architecture réseau.
- Mouvement latéral et réseaux plats : les éléments probants
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : description de la segmentation du réseau par fonction métier ; barrières au mouvement latéral entre les zones ; résultats des tests d'intrusion internes portant sur les chemins de mouvement latéral.
- Base légale
-
Le GDPR exige une base légale pour chaque activité de traitement et en prévoit six : le consentement, l'exécution d'un contrat, le respect d'une obligation légale, la sauvegarde des intérêts vitaux, l'exécution d'une mission d'intérêt public et l'intérêt légitime. L'une d'elles doit s'appliquer avant le début du traitement, et elle doit être identifiée et documentée dès le départ.
le consentement est la base vers laquelle on se tourne en premier parce qu'elle semble la plus sûre. C'est la plus exigeante. Il doit être libre, spécifique, éclairé et univoque, aussi facile à retirer qu'à donner, et il crée des obligations qui durent aussi longtemps que le traitement. La plupart des traitements B2B reposent sur l'intérêt légitime ou sur le contrat, et choisir le consentement par défaut revient à bâtir un programme sur le fondement le plus difficile qui soit.
- Moindre privilège dans les accès des fournisseurs
-
Le moindre privilège est le principe selon lequel chaque entité (utilisateur, compte de service, application ou intégration de fournisseur) doit se voir accorder l'accès minimal nécessaire à l'exécution de sa fonction précise, et rien de plus.
le moindre privilège dans l'accès des fournisseurs est important pour la TPRM parce que le rayon d'impact de la compromission d'un identifiant de fournisseur est déterminé non par ce dont le fournisseur avait besoin, mais par ce qui lui a été accordé.
- Moindre privilège dans l’accès des fournisseurs : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : documentation des autorisations des comptes de service (autorisations précises avec justification fonctionnelle) ; historique des revues du périmètre d'accès (proportionnalité examinée, et pas seulement existence confirmée) ; aucun accès de niveau administrateur pour des fonctions non administratives.
- L'intérêt légitime en marketing
-
La possibilité pour une organisation d'envoyer des messages marketing à une personne qui n'a jamais donné son accord dépend du lieu où se trouve le destinataire. Dans une grande partie de l'Europe, les courriels B2B adressés à une adresse professionnelle peuvent reposer sur l'intérêt légitime, sous réserve d'un droit d'opposition. Au Canada, la CASL interprète strictement le consentement implicite, le rattache à une relation existante et lui fixe une date d'expiration. Aux États-Unis, la loi CAN-SPAM autorise l'envoi moyennant une possibilité de désinscription et une adresse postale. Les PECR du Royaume-Uni se situent entre les deux.
une même liste de campagne couvre souvent tous ces régimes, et une règle appliquée uniformément est fausse quelque part. La base juridique défendable pour une adresse professionnelle allemande ne l’est pas pour une adresse canadienne, et les régimes de sanctions diffèrent d’un ordre de grandeur.
- Intérêts légitimes et profilage
-
Le profilage, c'est-à-dire l'évaluation automatisée d'aspects personnels visant à prédire le comportement, les intérêts ou les caractéristiques, peut reposer sur l'intérêt légitime comme base légale. Mais la mise en balance doit tenir compte du caractère intrusif du profil, des attentes raisonnables de la personne et de l'effet du profilage sur elle. Plus le profil a de conséquences, plus l'équilibre est difficile à trouver.
la notation comportementale, les modèles de propension et les prédictions d’engagement sont couramment justifiés par une LIA qui ne prend en compte que le bénéfice pour l’entreprise. Le test de mise en balance demande ce à quoi la personne s’attendrait, si elle s’y opposerait si elle le savait, et ce que le profil change à la manière dont elle est traitée. Un profil qui influe sur les prix, l’éligibilité ou le contenu que voit une personne n’est pas une intrusion mineure.
- Risques d'intégration des LLM
-
Les risques d'intégration des LLM sont les risques pour la sécurité et la vie privée qui découlent de la connexion de grands modèles de langage aux référentiels de données de l'entreprise (bibliothèques de documents, bases de données, messageries et bases de connaissances), ce qui crée un système d'IA capable de récupérer et de traiter des données de l'entreprise en réponse aux requêtes des utilisateurs.
Les risques d’intégration de LLM comptent en matière de TPRM parce que les déploiements de LLM en entreprise connectés à des référentiels de documents sensibles créent une nouvelle catégorie de risque d’accès aux données que les contrôles d’accès traditionnels ne sont pas conçus pour traiter.
- Risques d'intégration des LLM : les éléments probants
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : comparaison entre le périmètre d'autorisations du compte de service et celui des utilisateurs ; surveillance des requêtes pour détecter les schémas d'extraction ; un fournisseur qui confirme la sécurité de son intégration de LLM doit être interrogé sur le périmètre d'autorisations du compte de service et l'exclusion des catégories de documents sensibles. Les contrôles d'accès protègent l'accès direct aux documents. Le périmètre de récupération du compte de service et la surveillance de la fenêtre de contexte protègent la voie indirecte que crée le LLM.
- Ingestion des journaux des fournisseurs
-
L'ingestion des journaux des fournisseurs est la difficulté d'obtenir, de consulter et de conserver les données des journaux de sécurité des environnements des fournisseurs à des fins d'enquête sur les incidents, de preuve de conformité et de détection continue des menaces dans le SIEM du client.
l’ingestion des journaux des fournisseurs est importante en TPRM, car les enquêtes de sécurité exigent de plus en plus des journaux provenant des environnements des fournisseurs, et la disponibilité de ces preuves dépend de politiques de conservation et de modalités d’accès dont la plupart des évaluations de fournisseurs confirment l’existence sans vérifier leur adéquation aux besoins d’enquête.
- Ingestion des journaux des fournisseurs : les preuves
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : durée de conservation par catégorie de journaux ; procédure et délais d’accès aux journaux pour les investigations ; capacité de transfert des journaux pour les systèmes critiques.
- Journalisation et conservation des preuves
-
La journalisation enregistre ce qui s’est passé : qui s’est connecté, ce qui a changé, ce qui a été consulté, ce que le système a fait. La conservation détermine combien de temps cet enregistrement subsiste. Ensemble, elles constituent la preuve de la plupart des autres contrôles, puisqu’une revue d’accès, une approbation de changement ou la chronologie d’un incident ne sont démontrables que si le journal qui les a enregistrées existe encore lorsque quelqu’un le demande.
le constat d’audit est rarement qu’un contrôle n’a pas été exécuté. C’est que personne ne peut prouver qu’il l’a été sur la période, parce que le journal a été écrasé au bout de quatre-vingt-dix jours alors que la période d’audit est de douze mois. Le problème se pose lors des incidents, quand on ne peut pas déterminer depuis quand l’accès existait parce que le journal avait expiré. Et il se pose en matière de vie privée, quand des journaux enregistrant le contenu des requêtes s’avèrent contenir des données personnelles que personne n’avait cartographiées.
- Accès logique au titre de CC6
-
Le critère CC6 couvre l'accès logique et physique : la manière dont l'accès est attribué, authentifié, autorisé, revu et retiré, la manière dont l'accès physique aux locaux est contrôlé, et la manière dont les données sont protégées en transit, au repos et lors de leur élimination. C'est de loin le plus vaste des neuf groupes de critères communs.
CC6 concerne chaque système et chaque arrivée, mobilité et départ. Le volume de preuves est supérieur à celui de tout autre groupe, la population change constamment, et les modes de défaillance sont ceux qui provoquent des violations. Il produit plus d’exceptions que tout autre groupe, et l’auditeur y consacre plus de temps qu’à aucun autre.
M
- Identités machines et identités humaines
-
Les identités machines sont importantes pour la TPRM parce qu'elles sont la principale voie par laquelle les attaques de la chaîne d'approvisionnement se propagent des environnements des fournisseurs vers ceux des clients. L'attaque SolarWinds a compromis les identités machines du pipeline de compilation.
les identités machine comptent en matière de TPRM parce qu’elles constituent la principale voie par laquelle les attaques de la chaîne d’approvisionnement se propagent des environnements des fournisseurs vers ceux des clients.
- Identités machines et identités humaines : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : nombre d'identités machines et capacité d'inventaire ; déploiement d'une plateforme de gestion des secrets pour les identifiants machines ; inclusion de la revue des identités machines dans le cycle de gouvernance.
- Complexité de la TPRM pour les fournisseurs de services gérés
-
la complexité des MSP est importante pour la TPRM parce que les relations avec les MSP comptent parmi les relations fournisseurs les plus risquées de l'entreprise : elles impliquent un large accès aux systèmes, le contrôle opérationnel de fonctions critiques et une exposition profonde des données.
la complexité des MSP est importante pour la TPRM parce que les relations avec les MSP comptent parmi les relations fournisseurs les plus risquées de l'entreprise : elles impliquent un large accès aux systèmes, le contrôle opérationnel de fonctions critiques et une exposition profonde des données.
- Complexité de la TPRM des fournisseurs de services gérés : les éléments probants
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : liste complète des outils du MSP avec la caractérisation de leurs accès ; certifications de sécurité des outils à accès direct ; exigences de sécurité appliquées à leurs propres fournisseurs d'outils.
- Seuil de signification dans une attestation
-
Le seuil de signification est le seuil à partir duquel un écart est suffisamment important pour influer sur l'opinion de l'auditeur ou pour être signalé comme une exception. C'est un jugement que porte l'auditeur, éclairé par le critère concerné, la nature de l'écart et son effet probable sur les décisions d'un lecteur.
cela explique pourquoi un contrôle ayant échoué une fois sur un échantillon de vingt-cinq peut ne pas apparaître comme une exception, et pourquoi une seule défaillance d’un contrôle critique peut y figurer. Cela explique aussi pourquoi le rapport n’est pas un journal complet de tout ce qui a été imparfait au cours de l’année. C’est une opinion, façonnée par un jugement sur ce qui compte.
- Mesurer le ROI d’un programme DevSecOps
-
la mesure du ROI du DevSecOps est importante en TPRM, car les fournisseurs incapables de démontrer les résultats de sécurité de leur investissement DevSecOps investissent peut-être dans un théâtre de la sécurité plutôt que dans l’amélioration de la sécurité.
la mesure du ROI du DevSecOps est importante en TPRM, car les fournisseurs incapables de démontrer les résultats de sécurité de leur investissement DevSecOps investissent peut-être dans un théâtre de la sécurité plutôt que dans l’amélioration de la sécurité.
- Mesurer le ROI d'un programme DevSecOps : les éléments probants
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : registres de suivi du MTTR et tendance ; taux de découverte des vulnérabilités avant et après la mise en production ; modèle des coûts évités pour le programme de sécurité.
- Risques d’exposition des métadonnées
-
Les métadonnées sont des données sur les données : les informations contextuelles, structurelles et techniques qui décrivent, situent et soutiennent les données principales sans être elles-mêmes les données principales.
l’exposition des métadonnées compte en matière de TPRM parce qu’elle représente une catégorie de divulgation d’informations largement invisible pour les évaluations axées sur la protection des données principales.
- Risques d'exposition des métadonnées : les éléments probants
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : revue de la configuration des en-têtes HTTP (suppression des en-têtes identifiant le serveur) ; configuration de la gestion des erreurs (messages d’erreur génériques sans détails sur le système) ; processus de gestion des métadonnées des documents, avec nettoyage avant toute diffusion externe.
- Des indicateurs qui résistent à un conseil d’administration
-
Un conseil d'administration est responsable de la supervision, pas des contrôles : savoir si l'organisation comprend son exposition, si le programme dispose de ressources suffisantes et si la direction dit la vérité. Les indicateurs destinés à un conseil doivent servir ces trois questions. Les menaces bloquées, le taux de réalisation des formations et une carte de chaleur qui n'a pas bougé depuis trois trimestres n'en servent aucune, et un conseil qui acquiesce et passe à autre chose réagit de façon juste à un rapport qui ne demande rien.
le rapport qui aboutit à une décision est celui qui montre une évolution dans une direction qui compte et qui se termine par une demande. Le délai de remédiation des constats critiques, passé de neuf à vingt-six jours, a déclenché une discussion sur les ressources. Le nombre d'engagements de sécurité envers les clients sans aucune preuve à l'appui a conduit directement au financement d'une ressource dédiée à la conformité, ce qu'une année de cartes de chaleur n'avait pas obtenu.
- Lacunes dans l’application de la MFA
-
Les lacunes d’application de la MFA sont les chemins d’authentification d’un environnement où le second facteur n’est pas exigé, c’est-à-dire les chemins par lesquels des identités peuvent s’authentifier avec un seul facteur (généralement un mot de passe, une clé API ou un certificat) sans la vérification supplémentaire qu’apporte la MFA.
les lacunes dans l'application de la MFA sont importantes pour la TPRM parce que les fournisseurs qui traitent des données clients sont des cibles attrayantes, précisément parce que leurs systèmes détiennent simultanément des données de plusieurs clients.
- Lacunes d’application de la MFA : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : inventaire des chemins d'authentification (tous les chemins, avec leur statut MFA) ; documentation des méthodes d'authentification des comptes de service ; inventaire des points de terminaison hérités avec un plan de migration ou de contrôle compensatoire.
- Microsegmentation dans les environnements des fournisseurs
-
La microsegmentation est importante en TPRM, car une confirmation de segmentation du réseau sans évaluation de la qualité des règles peut décrire une séparation topologique assortie d’une connectivité fonctionnelle : une segmentation qui existe sur le schéma du réseau mais qui peut être franchie au moyen de règles larges au niveau des zones.
la microsegmentation est importante pour la TPRM parce qu'une confirmation de la segmentation réseau sans évaluation de la qualité des règles peut décrire une séparation topologique assortie d'une connectivité fonctionnelle : une segmentation qui existe dans le schéma du réseau mais qui peut être traversée grâce à des règles larges au niveau des zones.
- Microsegmentation dans les environnements des fournisseurs : les éléments probants
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : description des règles aux frontières de segmentation (précision des sources, destinations et ports) ; politique de refus par défaut aux frontières des zones ; processus de revue des règles et date de la dernière revue.
- Exposition de stockage cloud mal configuré via les fournisseurs
-
Le stockage d’objets dans le cloud (AWS S3, Azure Blob Storage, Google Cloud Storage) est l’un des services les plus utilisés et les plus souvent mal configurés dans les environnements cloud des entreprises. Il est bon marché, évolutif et conçu pour rendre les données rapidement accessibles.
les erreurs de configuration du stockage cloud se situent à l'intersection de deux catégories de risques que les programmes de TPRM traitent souvent séparément : le traitement des données par les fournisseurs et la sécurité du cloud.
- Exposition de stockage cloud mal configuré via les fournisseurs : les preuves
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : captures d’écran ou exports de configuration confirmant que les blocages d’accès public sont activés, et non une case cochée dans un questionnaire ; documentation de la configuration du chiffrement précisant la norme de chiffrement et l’approche de gestion des clés ; confirmation de la journalisation des accès, avec la durée de conservation précisée.
- Sécurité des applications mobiles CI/CD
-
La sécurité de la CI/CD mobile est importante pour la TPRM parce que les applications mobiles distribuées par les magasins d'applications arrivent sur les appareils des utilisateurs avec la configuration de sécurité, quelle qu'elle soit, produite par le pipeline de compilation.
la sécurité de la CI/CD mobile est importante pour la TPRM parce que les applications mobiles distribuées par les magasins d'applications arrivent sur les appareils des utilisateurs avec la configuration de sécurité, quelle qu'elle soit, produite par le pipeline de compilation.
- Sécurité de la CI/CD des applications mobiles : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : validation de la configuration des binaires dans le pipeline CI/CD ; vérification de la journalisation de débogage pour les versions de production ; outils de test de sécurité propres aux applications mobiles utilisés.
- Contrôle d’accès aux modèles
-
Le contrôle d'accès aux modèles, dans le contexte de la sécurité de l'IA, répond à un problème qui n'existe pas dans la sécurité logicielle traditionnelle : un modèle peut être volé par l'intermédiaire de son API sans aucune violation des contrôles d'accès de l'API. Les contrôles d'accès traditionnels empêchent l'accès non autorisé à une ressource.
le contrôle d’accès aux modèles est important en TPRM, car les fournisseurs qui exposent des interfaces de programmation de modèles d’IA à des entreprises clientes, et à travers elles potentiellement aux propres clients et partenaires de ces entreprises, créent une surface d’attaque par extraction de modèle que la sécurité API traditionnelle ne traite pas.
- Contrôle d'accès aux modèles : les éléments probants
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : surveillance du volume de requêtes par clé API ; résultats de l’évaluation des attaques par extraction de modèle ; un fournisseur qui affirme disposer d’une authentification API et d’une limitation de débit doit être interrogé sur la détection de l’extraction. L’authentification confirme un accès autorisé. La détection de l’extraction détermine si cet accès autorisé sert à reconstruire le modèle.
- Fiches de modèle
-
Une fiche de modèle est un document structuré décrivant un modèle d’IA : ce pour quoi il a été entraîné, sur quel type de données, comment ses performances ont été évaluées et pour quelles populations, ses limites connues, et les usages auxquels il est destiné ou non. Les fournisseurs les publient pour les modèles qu’ils fournissent ; les organisations les rédigent pour les modèles qu’elles construisent.
c’est le document qui répond aux questions qu’une analyse d’impact de l’IA doit poser, et son absence constitue en soi un constat. Lorsqu’un fournisseur ne peut pas dire sur quelles populations la performance de son modèle a été mesurée, vous apprenez qu’elle l’a été sur une seule, ce qui est généralement le cas qui comptait : un outil de tri du support testé en anglais alors qu’un tiers de vos clients écrivent en espagnol.
- Risques de dérive des modèles
-
La dérive d'un modèle est la dégradation de l'alignement entre le comportement en production d'un modèle d'apprentissage automatique et son comportement prévu, un désalignement qui se développe au fil du temps à mesure que la distribution des données réelles rencontrées par le modèle en production s'écarte de la distribution des données d'entraînement à partir desquelles il a été construit.
la dérive des modèles est importante en TPRM, car les modèles d’IA que les fournisseurs déploient pour des décisions lourdes de conséquences (détection de la fraude, notation de crédit, classification de sécurité, évaluation du risque client) dériveront avec le temps d’une manière qui n’apparaît pas toujours dans les indicateurs de performance habituels.
- Risques de dérive des modèles : les éléments probants
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : surveillance propre à la dérive, au-delà des indicateurs de performance ; suivi de la stabilité de l'importance des variables pour les modèles à apprentissage en ligne ; évaluation de la dérive conceptuelle et fréquence de réentraînement.
- Risques de vol de modèles
-
Le risque de vol de modèle est le risque que la logique de décision et les capacités d’un modèle d’IA propriétaire puissent être reconstituées par un attaquant au moyen d’interrogations systématiques de l’API du modèle, directement ou par l’intermédiaire d’un tiers disposant d’un accès API légitime, sans que l’attaquant n’accède jamais aux poids, à l’architecture ou aux données d’entraînement du modèle.
le vol de modèles compte en matière de TPRM sous deux angles.
- Risques de vol de modèles : les éléments probants
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : exigences de sécurité API des entreprises clientes ; confirmation de la surveillance du volume de requêtes par clé ; un fournisseur qui affirme la sécurité de son API doit être interrogé sur la sécurité des intégrations de ses entreprises clientes. L’API du fournisseur contrôle l’accès direct. Les intégrations des clients constituent la surface étendue par laquelle le modèle peut être consulté indirectement.
- Considérations de sécurité CI/CD multicloud
-
La sécurité CI/CD multicloud est importante en TPRM, car les incohérences d’architecture de sécurité entre les clouds créent un maillon faible unique : le cloud dont la gestion des identifiants ou la configuration de sécurité est la plus faible constitue le point de plus grande vulnérabilité d’un pipeline qui s’étend sur les deux.
la sécurité CI/CD multicloud est importante pour la TPRM parce que les incohérences d'architecture de sécurité entre les clouds créent un maillon faible unique : le cloud dont la gestion des identifiants ou la configuration de sécurité est la plus faible constitue le point de vulnérabilité maximale d'un pipeline qui s'étend sur les deux.
- Considérations de sécurité CI/CD multicloud : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : documentation des mécanismes d'authentification par cloud ; état de la mise en œuvre de l'identité de charge de travail par cloud ; dates de rotation des identifiants des comptes de service.
- Risque fournisseur multicloud
-
Le risque fournisseur multicloud est la lacune de gouvernance qui apparaît lorsque l’infrastructure d’un fournisseur s’étend sur plusieurs fournisseurs de cloud, alors que la diligence raisonnable, les contrôles contractuels et la surveillance continue du client ne portent que sur un seul, généralement celui dont le client a connaissance ou celui que le fournisseur a présenté lors de l’intégration.
l'architecture multicloud des fournisseurs remet directement en cause l'une des hypothèses fondamentales du modèle d'évaluation TPRM standard : que le fournisseur constitue un environnement de sécurité unique et cohérent qui peut être évalué au moyen d'un questionnaire et d'une certification de conformité.
- Risque fournisseur multicloud : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : une liste complète des fournisseurs cloud et des régions utilisés pour le traitement des données des clients, et pas seulement la plateforme principale ; une documentation du périmètre SOC 2 confirmant la couverture de tous les environnements pertinents, ou une reconnaissance explicite de ce qui est hors périmètre et pourquoi ; un schéma des flux de données montrant comment les données des clients circulent dans l'architecture multicloud du fournisseur.
N
- Sécurité NAT et risques liés à la traduction d'adresses réseau
-
les idées reçues sur la sécurité du NAT sont importantes en TPRM, car les fournisseurs qui décrivent leurs systèmes internes comme « protégés par le NAT » décrivent peut-être exactement l’absence de routage IP direct, tout en maintenant des règles de redirection de ports qui rendent ces mêmes systèmes accessibles depuis Internet par des chemins configurés délibérément ou oubliés.
les idées reçues sur la sécurité du NAT sont importantes en TPRM, car les fournisseurs qui décrivent leurs systèmes internes comme « protégés par le NAT » décrivent peut-être exactement l’absence de routage IP direct, tout en maintenant des règles de redirection de ports qui rendent ces mêmes systèmes accessibles depuis Internet par des chemins configurés délibérément ou oubliés.
- Sécurité NAT et risques liés à la traduction d'adresses réseau : les éléments probants
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : inventaire et revue des règles de redirection de ports.
- Nature, calendrier et étendue
-
La nature correspond au type de test que l’auditeur réalise. Le calendrier correspond au moment de la période. L’étendue correspond à la quantité, c’est-à-dire la taille de l’échantillon et la profondeur. Ensemble, ces éléments décrivent la quantité de travail que l’auditeur effectuera sur chaque contrôle, et tous trois dépendent du niveau de risque perçu par l’auditeur.
comprendre ces trois éléments explique pourquoi une demande paraît anodine et une autre excessive. Un contrôle avec de bons antécédents, des preuves solides et un faible risque fait l’objet de tests légers. Un contrôle situé dans un domaine marqué par des exceptions antérieures, une documentation faible ou une forte exposition voit les trois curseurs poussés vers le haut.
- Contrôle d'accès au réseau dans les environnements d'entreprise
-
Le NAC est important en TPRM, car les réseaux des fournisseurs qui permettent à des appareils non gérés de se connecter au réseau de l’entreprise présentent une surface d’accès réseau non maîtrisée : tout lieu physique doté d’une prise réseau ou d’un signal sans fil devient un point d’entrée potentiel pour n’importe quel appareil.
Le NAC est important en TPRM, car les réseaux des fournisseurs qui permettent à des appareils non gérés de se connecter au réseau de l’entreprise présentent une surface d’accès réseau non maîtrisée : tout lieu physique doté d’une prise réseau ou d’un signal sans fil devient un point d’entrée potentiel pour n’importe quel appareil.
- Contrôle d'accès au réseau dans les environnements d'entreprise : les éléments probants
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : confirmation du déploiement du NAC pour le filaire et le sans-fil ; accès différencié pour les appareils gérés et non gérés ; un fournisseur qui affirme la sécurité de son réseau doit être interrogé sur le NAC. La sécurité des terminaux sur les appareils gérés protège les appareils gérés. Le NAC contrôle ce à quoi les appareils non gérés peuvent accéder lorsqu’ils se connectent au réseau. Les deux sont nécessaires pour maîtriser la surface d’accès au réseau.
- Gestion des accès réseau pour les sous-traitants et les tiers
-
La gestion de l'accès réseau des prestataires est importante pour la TPRM parce que les prestataires disposant d'un accès au réseau de l'entreprise dont la mission est terminée représentent le même risque d'accès orphelin que les employés partis, mais par une lacune de gestion du cycle de vie que les systèmes d'identité intégrés aux RH ne traitent pas automatiquement.
la gestion de l'accès réseau des prestataires est importante pour la TPRM parce que les prestataires disposant d'un accès au réseau de l'entreprise dont la mission est terminée représentent le même risque d'accès orphelin que les employés partis, mais par une lacune de gestion du cycle de vie que les systèmes d'identité intégrés aux RH ne traitent pas automatiquement.
- Gestion de l'accès réseau des prestataires et des tiers : les éléments probants
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : processus de départ des prestataires et registres de SLA ; vérification de l’intégration des dates de fin de contrat ; registres d’audit mensuel des accès des prestataires.
- Revue et recertification des accès réseau
-
La qualité des revues d’accès réseau est importante en TPRM, car une confirmation de revue d’accès sans évaluation de la méthode peut décrire une activité de conformité plutôt qu’un contrôle de sécurité efficace.
la qualité des revues d'accès au réseau est importante pour la TPRM parce qu'une confirmation de revue des accès sans évaluation de la méthodologie peut décrire une activité de conformité plutôt qu'un contrôle de sécurité efficace.
- Revue et certification des accès réseau : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : suivi des comptes supprimés à chaque revue.
- Détection des anomalies réseau et écarts par rapport à la référence
-
La détection des anomalies réseau est importante en TPRM, car le vol d’identifiants suivi d’une utilisation abusive lente et prudente de ces identifiants est précisément le schéma d’attaque qu’emploient les acteurs spécialisés dans les identifiants pour échapper à la détection par signatures.
la détection des anomalies réseau est importante pour la TPRM parce que le vol d'identifiants suivi d'une utilisation abusive, prudente et lente, de ces identifiants est le schéma d'attaque que les acteurs malveillants axés sur les identifiants utilisent précisément pour échapper à la détection par signatures.
- Détection des anomalies réseau et des écarts par rapport à la référence : les éléments probants
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments probants à demander plutôt que des assurances : la couverture de la détection des anomalies en complément des signatures.
- Chiffrement réseau : ce qui est chiffré et ce qui ne l'est pas
-
Le chiffrement du réseau interne est important en TPRM, car il détermine ce qu’un attaquant ayant pris pied dans le réseau interne peut observer.
le chiffrement du réseau interne est important pour la TPRM parce qu'il détermine ce qu'un attaquant qui a pris pied en interne peut observer.
- Tests d'intrusion réseau dans le contexte de la TPRM
-
Le périmètre des tests d'intrusion réseau est important pour la TPRM parce que les constats d'un rapport de test d'intrusion décrivent ce qui a été testé, pas ce qui existe. Un test d'intrusion externe d'une application sans anomalie confirme que l'application externe testée est raisonnablement sécurisée.
le périmètre des tests d’intrusion réseau est important en TPRM, car les constats d’un rapport de test d’intrusion décrivent ce qui a été testé, et non ce qui existe.
- Tests d'intrusion réseau dans le contexte de la TPRM : les éléments probants
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : exigence d’inclure le réseau interne dans le périmètre pour les fournisseurs critiques ; exigences de périmètre dans les contrats des fournisseurs critiques.
- Périmètre réseau et périmètre d’identité
-
La distinction entre périmètre réseau et périmètre d'identité est importante pour la TPRM parce que les réponses des fournisseurs aux questionnaires de sécurité réseau qui confirment des contrôles robustes de pare-feu et de périmètre décrivent un modèle de sécurité qui ne traite pas le principal vecteur d'attaque, fondé sur les identifiants.
la distinction entre périmètre réseau et périmètre d'identité est importante pour la TPRM parce que les réponses des fournisseurs aux questionnaires de sécurité réseau qui confirment des contrôles robustes de pare-feu et de périmètre décrivent un modèle de sécurité qui ne traite pas le principal vecteur d'attaque, fondé sur les identifiants.
- Périmètre réseau et périmètre d’identité : les preuves
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : confirmation de l’application de la MFA sans possibilité de contournement ; gestion des appareils pour le contrôle d’accès ; détection d’anomalies en cas de compromission d’identifiants.
- Résilience du réseau et points de défaillance uniques
-
La résilience du réseau compte en matière de TPRM parce que la disponibilité de la plateforme d’un fournisseur constitue une dépendance opérationnelle directe pour les entreprises clientes.
la résilience du réseau compte en matière de TPRM parce que la disponibilité de la plateforme d’un fournisseur constitue une dépendance opérationnelle directe pour les entreprises clientes.
- Résilience du réseau et points de défaillance uniques : les éléments probants
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : évaluation de la redondance des ISP et des circuits.
- Architecture de sécurité réseau pour les environnements centrés sur le SaaS
-
L’architecture de sécurité réseau centrée sur le SaaS est importante en TPRM, car l’application de référentiels traditionnels d’évaluation de la sécurité réseau à des environnements centrés sur le SaaS produit des résultats qui décrivent des inadéquations d’architecture plutôt que des lacunes de sécurité.
l'architecture de sécurité réseau orientée SaaS est importante pour la TPRM parce que l'application des cadres traditionnels d'évaluation de la sécurité réseau aux environnements orientés SaaS produit des résultats d'évaluation qui décrivent des inadéquations d'architecture plutôt que des lacunes de sécurité.
- Architecture de sécurité réseau pour les environnements orientés SaaS : les éléments probants
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : revue de la gestion de la posture de sécurité SaaS.
- Sécurité réseau à la frontière OT/IT
-
la sécurité de la frontière OT/IT est importante en TPRM, car les fournisseurs qui fabriquent du matériel, exploitent des sites de production ou gèrent des systèmes logistiques disposent de réseaux OT dont la posture de sécurité influe directement sur l’intégrité et la disponibilité de leurs processus opérationnels.
la sécurité de la frontière OT/IT est importante en TPRM, car les fournisseurs qui fabriquent du matériel, exploitent des sites de production ou gèrent des systèmes logistiques disposent de réseaux OT dont la posture de sécurité influe directement sur l’intégrité et la disponibilité de leurs processus opérationnels.
- Sécurité réseau des fournisseurs en forte croissance : l'écart d'échelle
-
La sécurité face à l'écart d'échelle est importante pour la TPRM parce que les fournisseurs en croissance rapide peuvent décrire des contrôles de sécurité à leur niveau de qualité actuel alors que ces contrôles fonctionnent en réalité en dessous du niveau de qualité requis pour leur taille actuelle.
la sécurité face à l'écart d'échelle est importante pour la TPRM parce que les fournisseurs en croissance rapide peuvent décrire des contrôles de sécurité à leur niveau de qualité actuel alors que ces contrôles fonctionnent en réalité en dessous du niveau de qualité requis pour leur taille actuelle.
- Sécurité réseau des fournisseurs en forte croissance, l'écart d'échelle : les éléments probants
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : revue de la trajectoire de croissance et des investissements de sécurité.
- Sécurité réseau dans les évaluations de tiers
-
L’écart entre questionnaire et évaluation technique compte en matière de TPRM parce qu’il détermine la valeur d’assurance réelle de l’évaluation de la sécurité réseau. Pour les fournisseurs critiques, une évaluation de la sécurité réseau fondée uniquement sur un questionnaire peut confirmer l’existence des contrôles tout en passant à côté des problèmes de qualité de mise en œuvre qui créent le risque de sécurité réel.
l'écart entre questionnaire et évaluation technique est important pour la TPRM parce qu'il détermine la valeur d'assurance réelle de l'évaluation de la sécurité réseau.
- Sécurité réseau dans les évaluations de tiers : les éléments probants
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : échantillon de règles du pare-feu externe à examiner ; résultats récents d’analyses de vulnérabilités externes ; confirmation d’une surface d’attaque externe sans exposition sur Shodan.
- Réponse aux incidents de sécurité réseau : les 60 premières minutes
-
La rapidité de réponse aux incidents de sécurité réseau est importante en TPRM, car le temps de présence pendant un incident actif, c’est-à-dire la période entre la détection et le confinement, est le moment où l’attaquant atteint ses objectifs. Un fournisseur dont le délai entre délibération et isolement est de deux heures offre aux attaquants deux heures d’accès actif après la détection.
la rapidité de réponse aux incidents de sécurité réseau est importante pour la TPRM parce que le temps de présence pendant un incident actif, c'est-à-dire la période entre la détection et le confinement, est le moment où l'attaquant atteint ses objectifs.
- Les indicateurs de sécurité réseau qui comptent vraiment
-
La qualité des indicateurs de sécurité réseau est importante pour la TPRM parce que des indicateurs qui décrivent l'activité sans décrire le risque ne peuvent pas étayer des décisions d'évaluation fondées sur les risques.
la qualité des indicateurs de sécurité réseau compte en matière de TPRM parce que des indicateurs qui décrivent l’activité sans décrire le risque ne peuvent pas étayer des décisions d’évaluation fondées sur les risques.
- Les indicateurs de sécurité réseau qui comptent vraiment : les éléments probants
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : définition et suivi d’indicateurs fondés sur le risque ; mesure du délai de détection des menaces réseau.
- Surveillance de la sécurité réseau et intégration au SIEM
-
la couverture des journaux du SIEM compte en matière de TPRM parce que la présence d’un SIEM confirme que la plateforme de surveillance existe, tandis que la couverture des journaux détermine ce que cette plateforme peut réellement détecter.
la couverture des journaux du SIEM compte en matière de TPRM parce que la présence d’un SIEM confirme que la plateforme de surveillance existe, tandis que la couverture des journaux détermine ce que cette plateforme peut réellement détecter.
- Surveillance de la sécurité réseau et intégration au SIEM : les preuves
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : identification des sources de journaux critiques absentes ; un fournisseur qui affirme disposer d’un SIEM doit être invité à fournir la liste des sources de journaux. La présence d’un SIEM correspond à la plateforme. L’étendue des sources de journaux correspond à la couverture de détection. Le rapport entre sources connectées et sources potentielles révèle ce que le SIEM peut et ne peut pas détecter.
- Exigences de sécurité réseau dans les contrats fournisseurs
-
Les exigences contractuelles de sécurité réseau sont importantes pour la TPRM parce qu'elles déterminent si la posture de sécurité confirmée lors de l'évaluation est opposable, c'est-à-dire si l'entreprise dispose d'un recours contractuel lorsque le fournisseur ne maintient pas les contrôles de sécurité que l'évaluation a confirmés.
les exigences contractuelles de sécurité réseau sont importantes en TPRM, car elles déterminent si la posture de sécurité confirmée lors de l’évaluation est opposable, c’est-à-dire si l’entreprise dispose d’un recours contractuel lorsque le fournisseur ne maintient pas les contrôles de sécurité confirmés par l’évaluation.
- Exigences de sécurité réseau dans les contrats fournisseurs : les éléments probants
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : revue de la précision des clauses de sécurité des contrats ; obligations de sécurité précises dans les contrats critiques.
- Évaluation de la segmentation réseau en TPRM
-
L’évaluation de la segmentation réseau est importante en TPRM, car la valeur de sécurité de la segmentation réseau d’un fournisseur est déterminée par sa règle de frontière la plus permissive, et non par la plus restrictive.
l'évaluation de la segmentation réseau est importante pour la TPRM parce que la valeur de sécurité de la segmentation réseau d'un fournisseur est déterminée par sa règle de frontière la plus permissive, et non par la plus restrictive.
- Évaluation de la segmentation réseau en TPRM : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : architecture des serveurs de rebond pour l'accès à la production ; règle de frontière interne la plus permissive ; tests d'efficacité de la segmentation depuis des positions internes.
- Sécurité du protocole de synchronisation horaire et intégrité des journaux
-
La sécurité NTP et l'exactitude de l'horodatage des journaux sont importantes pour la TPRM parce qu'elles déterminent la fiabilité forensique des journaux de sécurité d'un fournisseur lors d'une enquête sur un incident.
La sécurité NTP et l'exactitude de l'horodatage des journaux sont importantes pour la TPRM parce qu'elles déterminent la fiabilité forensique des journaux de sécurité d'un fournisseur lors d'une enquête sur un incident.
- Documentation de la topologie réseau et gouvernance de la sécurité
-
L'actualité de la documentation de la topologie réseau est importante pour la TPRM parce que les évaluations de la sécurité réseau menées à partir de schémas obsolètes évaluent une architecture qui n'existe pas.
l'actualité de la documentation de la topologie réseau est importante pour la TPRM parce que les évaluations de la sécurité réseau menées à partir de schémas obsolètes évaluent une architecture qui n'existe pas.
- Visibilité du réseau et analyse du trafic
-
La visibilité du trafic est-ouest est importante en TPRM, car elle détermine la rapidité avec laquelle une compromission de la chaîne d’approvisionnement ou une violation interne est détectée. Un attaquant qui a compromis un système quelconque du réseau d’un fournisseur procédera à des mouvements latéraux pour atteindre des cibles de plus grande valeur : dépôts de code source, infrastructure de compilation, bases de données de production.
la visibilité du trafic est-ouest est importante en TPRM, car elle détermine la rapidité avec laquelle une compromission de la chaîne d’approvisionnement ou une violation interne est détectée.
- Visibilité du réseau et analyse du trafic : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : NDR ou analyse équivalente du trafic interne ; segments réseau couverts par la surveillance ; un fournisseur qui confirme une surveillance du réseau doit être interrogé sur l'inclusion du trafic est-ouest dans cette surveillance. La surveillance du périmètre détecte ce qui entre et ce qui sort. La surveillance est-ouest détecte ce qui se déplace à l'intérieur. Les attaques actuelles exigent les deux.
- NIST SP 800-161 pour les praticiens
-
NIST 800-161 compte en matière de TPRM parce qu’il fournit un cadre spécifique, approuvé par les pouvoirs publics, pour évaluer la sécurité de la chaîne d’approvisionnement logicielle, qui donne aux professionnels un vocabulaire structuré pour poser des questions allant au-delà de simples déclarations binaires de conformité.
NIST 800-161 compte en matière de TPRM parce qu’il fournit un cadre spécifique, approuvé par les pouvoirs publics, pour évaluer la sécurité de la chaîne d’approvisionnement logicielle, qui donne aux professionnels un vocabulaire structuré pour poser des questions allant au-delà de simples déclarations binaires de conformité.
- NIST SP 800-161 pour les praticiens : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : auto-évaluation du niveau de mise en œuvre NIST 800-161 ; documentation du contrôle de la chaîne d'approvisionnement SR-3 ; preuves de la mise en œuvre du suivi de provenance SR-4.
O
- Portées OAuth excessives
-
OAuth est un cadre d’autorisation qui permet à des applications d’obtenir un accès limité à des comptes utilisateurs sur des services tiers, en permettant à un utilisateur d’autoriser une application à agir en son nom à des fins précises sans lui communiquer ses identifiants.
l’excès de portée OAuth compte en matière de TPRM parce que les autorisations OAuth accordées aux applications des fournisseurs persistent, souvent pendant des années, et la portée qu’elles confèrent reste accessible à l’application du fournisseur, que les fonctionnalités susceptibles d’utiliser cette portée soient un jour développées ou utilisées ou non.
- Portées OAuth excessives : les éléments probants
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : justification par autorisation (chaque portée rattachée à une fonctionnalité précise) ; option de portée minimale nécessaire (existence ou non de configurations à portée réduite) ; identification des autorisations inutilisées (autorisations actuellement non exercées par des fonctionnalités actives).
- Registre des obligations
-
La liste des obligations légales, réglementaires et contractuelles applicables, chacune exprimée simplement, avec un responsable, les preuves et l’échéance.
C’est le premier document de tout programme, car le périmètre, les contrôles et la conservation dépendent tous de la connaissance de ce qui s’applique.
Taught in DTF-120 · See also: scope, evidence
- L'open source comme risque lié aux tiers
-
L’open source en tant que risque lié aux tiers compte parce que les attaques de la chaîne d’approvisionnement les plus importantes de la dernière décennie ont visé des composants open source : Log4Shell, la porte dérobée de XZ Utils, event-stream et d’autres attaques similaires ont toutes exploité la confiance que les logiciels construits sur des composants open source accordent à ces composants.
l'open source en tant que risque lié aux tiers est important parce que les attaques de la chaîne d'approvisionnement les plus marquantes de la dernière décennie ont ciblé des composants open source : Log4Shell, la porte dérobée de XZ Utils, event-stream et d'autres attaques similaires ont toutes exploité la confiance que les logiciels construits sur des composants open source accordent à ces composants.
- L’open source en tant que risque tiers : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : nomenclature logicielle du produit ; confirmation des outils d'SCA et de la surveillance des vulnérabilités ; SLA de remédiation des vulnérabilités open source.
- Risque lié aux licences open source
-
Le risque lié aux licences open source est important pour la TPRM parce que les logiciels que votre entreprise déploie peuvent imposer des obligations juridiques que l'entreprise ou le fournisseur n'a pas identifiées, obligations qui peuvent apparaître après le déploiement, lorsque les implications juridiques d'une combinaison de licences sont évaluées.
le risque lié aux licences open source est important pour la TPRM parce que les logiciels que votre entreprise déploie peuvent imposer des obligations juridiques que l'entreprise ou le fournisseur n'a pas identifiées, obligations qui peuvent apparaître après le déploiement, lorsque les implications juridiques d'une combinaison de licences sont évaluées.
- Risque lié aux licences open source : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : SBOM avec les informations de licence de tous les composants ; résultats de l'analyse des licences identifiant les composants copyleft ; évaluation de la conformité juridique pour les composants AGPL et à copyleft fort.
- Risque de chaîne d’approvisionnement open source
-
Le risque lié à la chaîne d'approvisionnement open source est la catégorie de risque de sécurité qui découle de la dépendance d'une application à des composants logiciels développés, maintenus et distribués hors du contrôle de l'organisation, généralement par des communautés de bénévoles, des développeurs individuels ou des fondations, sous licences open source.
le risque de chaîne d’approvisionnement open source est le point où le cadre du risque lié aux tiers rencontre celui de la sécurité de la chaîne d’approvisionnement, à leur intersection la plus fondamentale.
- Risque lié à la chaîne d'approvisionnement open source : les éléments probants
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : documentation du processus d'évaluation préalable à l'adoption (critères, approbations, outils utilisés) ; confirmation de la capacité de détection des paquets malveillants (nom de l'outil et capacité d'analyse comportementale au-delà des bases de données CVE) ; confirmation de l'épinglage des dépendances et des fichiers de verrouillage, avec preuves dans le contrôle de version.
- Comptes de fournisseurs orphelins
-
Les comptes de fournisseurs orphelins sont des comptes utilisateurs et des comptes de service actifs dans les systèmes d’une organisation, qui appartiennent à des employés de fournisseurs, à des prestataires ou à des principaux de service dont la relation opérationnelle avec l’organisation a pris fin.
les comptes de fournisseurs orphelins sont importants en TPRM, car ils représentent une surface d’attaque qui persiste après la disparition de la justification de risque qui la fondait.
- Comptes de fournisseurs orphelins : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : inventaire des comptes du fournisseur dans tous les systèmes ; documentation du processus de départ couvrant tous les types de comptes ; un fournisseur qui confirme ses procédures de départ doit être invité à fournir un inventaire à jour de tous les comptes qu'il détient dans l'environnement du client, non seulement l'accès principal attribué, mais aussi les comptes de service et les comptes propres aux applications dans tous les systèmes. Cet inventaire devient le périmètre du départ. Sans lui, le périmètre du départ se limite à ce qui figure sur la liste de contrôle.
- Externaliser le risque ou externaliser la responsabilité
-
La responsabilité en matière d’externalisation est importante parce qu’elle définit le risque résiduel de l’entreprise en cas de défaillance d’un fournisseur.
la responsabilité en matière d’externalisation compte parce qu’elle définit le risque résiduel de l’entreprise en cas de défaillance d’un fournisseur.
- Externaliser le risque ou externaliser la responsabilité : les éléments probants
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : détails des assurances responsabilité civile professionnelle et cyberrisques ; montants de couverture et exclusions pertinents pour la responsabilité réglementaire ; programme de conformité réglementaire pour les activités externalisées.
- Comptes de service surprivilégiés
-
Les comptes de service sont des identités non humaines : des comptes créés pour des applications, des tâches d’automatisation, des processus planifiés, des outils de surveillance et des pipelines d’intégration plutôt que pour des utilisateurs humains. Ils s’authentifient auprès des systèmes et reçoivent des autorisations pour exécuter les fonctions qu’ils sont censés prendre en charge.
les comptes de service dotés de privilèges excessifs sont importants en TPRM, car ils représentent la catégorie d’identités la plus couramment exploitée dans les attaques de la chaîne d’approvisionnement.
- Comptes de service surprivilégiés : les éléments probants
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : inventaire des comptes de service (nombre, registre et documentation des propriétaires) ; confirmation de la revue des accès des comptes de service (inclusion dans le cycle de revue formel, avec la date de la dernière revue) ; approche de gestion des identifiants (plateforme de gestion des secrets ou politique relative aux identifiants statiques).
P
- Modèle de confiance des registres de paquets
-
Le modèle de confiance des registres de paquets est important pour la TPRM parce que les produits logiciels de vos fournisseurs reposent sur des paquets dont la fiabilité ne dépend pas de leur légitimité passée, mais de la sécurité actuelle des comptes de leurs mainteneurs.
le modèle de confiance des registres de paquets est important en TPRM, car les produits logiciels de vos fournisseurs reposent sur des paquets dont la fiabilité dépend non pas de leur légitimité passée, mais de la sécurité actuelle des comptes de leurs mainteneurs.
- Modèle de confiance des registres de paquets : les éléments probants
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : MFA pour les comptes de publication de paquets ; épinglage des dépendances et application des fichiers de verrouillage ; processus de revue des mises à jour de versions mineures.
- Intégration des tests d’intrusion dans la CI/CD
-
L'intégration des tests d'intrusion est importante pour la TPRM parce que des tests d'intrusion annuels, pour des fournisseurs dont le rythme de publication est soutenu, fournissent une référence de sécurité à un instant donné qui peut ne pas représenter la posture de sécurité actuelle.
l'intégration des tests d'intrusion est importante pour la TPRM parce que des tests d'intrusion annuels, pour des fournisseurs dont le rythme de publication est soutenu, fournissent une référence de sécurité à un instant donné qui peut ne pas représenter la posture de sécurité actuelle.
- Intégration des tests d'intrusion dans la CI/CD : les éléments probants
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : date du test d’intrusion et nombre de versions publiées depuis ; programme de tests déclenchés par les mises en production ou tests continus ; documentation du périmètre du test d’intrusion annuel, incluant le pipeline et l’infrastructure.
- Périmètre des tests d'intrusion
-
Un rapport de test d’intrusion décrit ce qui a été testé, comment, ce qui a été trouvé et ce qui a été recommandé. La section sur le périmètre est celle qui détermine le sens du reste. Un rapport sans constat sur un périmètre étroit indique que le testeur n’a rien trouvé là où il était autorisé à regarder, et c’est des endroits où il ne l’était pas que viendra le prochain incident.
les acheteurs demandent le rapport, les assureurs demandent si des tests ont lieu, et le rapport est lu pour son nombre de constats plutôt que pour son périmètre. Un rapport comportant deux constats de faible gravité portant sur le site marketing est présenté comme une preuve concernant le produit. Du côté du destinataire, le rapport sans anomalie d'un fournisseur est accepté sans vérifier si l'API avec laquelle vous vous intégrez réellement faisait partie du périmètre.
- Contrôles de fin de période et contrôles sur toute la période
-
Les contrôles diffèrent par leur fréquence. Certains fonctionnent en continu, comme l'authentification. D'autres fonctionnent périodiquement, comme les revues d'accès trimestrielles. D'autres encore fonctionnent une fois par an, comme l'évaluation annuelle des risques ou le test de reprise après sinistre. L'auditeur teste chacun selon sa fréquence, et les preuves attendues diffèrent complètement de l'un à l'autre.
un contrôle annuel n’a qu’une seule occasion d’être exécuté et documenté au cours de la période. S’il est manqué, aucune remédiation n’est possible dans cette période, et le rapport consignera une exception qu’aucun rattrapage ne pourra effacer.
- Données personnelles et PII
-
Les PII, ou informations personnellement identifiables, sont une notion américaine plus étroite qui désigne les données identifiant une personne précise : un nom, un numéro de sécurité sociale, un numéro de compte. Les données personnelles au sens du GDPR sont une notion plus large. Elles couvrent tout ce qui se rapporte à une personne identifiable, que l'identification soit directe ou indirecte, ce qui inclut les adresses IP, les identifiants d'appareils, les identifiants de cookies, les traces de localisation et les enregistrements pseudonymisés.
les équipes délimitent un programme de protection de la vie privée selon la définition étroite, concluent que leurs journaux et données analytiques ne contiennent pas de PII, puis découvrent plus tard que, selon la définition plus large, la moitié de leur télémétrie était depuis le début constituée de données personnelles. Le terme choisi au départ détermine ce que couvre le programme.
- Risques de sécurité du pipeline en tant que code
-
La sécurité du pipeline en tant que code est importante pour la TPRM parce que le pipeline CI/CD est le pont de confiance entre le code source et le logiciel de production.
la sécurité des pipelines en tant que code compte en matière de TPRM parce que le pipeline CI/CD est le pont de confiance entre le code source et le logiciel en production.
- Risques de sécurité du pipeline en tant que code : les éléments probants
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : configuration CODEOWNERS pour les fichiers de configuration du pipeline ; processus de revue des modifications de la configuration du pipeline ; limitation de l'accès aux identifiants pour les tâches du pipeline.
- Points d’attention
-
Sous chaque critère figure une liste de points d'attention. Ils se lisent comme des exigences. Ils n'en sont pas. Ce sont des indications illustratives de l'AICPA qui décrivent ce à quoi pourrait ressembler en pratique le respect du critère, et une organisation peut satisfaire à un critère sans traiter chaque point d'attention, ou en traitant certains d'une manière que la liste ne mentionne jamais.
les équipes lisent les points d’attention comme une liste de contrôle obligatoire, créent un contrôle pour chacun d’eux, puis maintiennent ces contrôles pendant des années en produisant des preuves que personne n’a demandées. Les auditeurs ne testent pas les points d’attention. Ils vérifient si le critère est satisfait.
- Politique et application
-
L’écart entre politique et application est la différence entre les exigences de sécurité documentées (normes, procédures et lignes directrices qui définissent le fonctionnement attendu des contrôles de sécurité) et les mécanismes techniques et opérationnels qui mettent réellement en œuvre ces exigences dans les systèmes en exploitation.
la distinction entre politique et application est importante en TPRM, car les évaluations de sécurité des fournisseurs qui confirment l’existence de politiques confirment la norme que le fournisseur a documentée, et non celle que ses systèmes appliquent.
- Politique et application effective : les éléments probants
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments probants à demander plutôt que des assurances : la configuration de la plateforme d’identité montrant les exigences de mot de passe réellement appliquées ; la configuration des mots de passe des comptes de service, documentée séparément ; l’inventaire de la configuration des mots de passe des systèmes hérités.
- Politique, norme, procédure
-
Une politique énonce ce qui doit être fait et pourquoi, à un niveau qui change rarement et qui est approuvé par la haute direction. Une norme énonce les exigences précises qui mettent en œuvre la politique : l'algorithme de chiffrement, la fréquence des revues, la longueur des mots de passe. Une procédure décrit comment une personne nommément désignée exécute une tâche, étape par étape. Trois documents, trois publics, trois rythmes de changement.
les organisations rédigent vingt politiques à partir d'un modèle, chacune mélangeant les trois, puis ne peuvent plus modifier une fréquence de revue sans un cycle d'approbation au niveau du conseil d'administration, si bien que la fréquence reste erronée. Les auditeurs confrontent les politiques à la pratique, et une politique contenant une exigence précise que l'organisation ne respecte pas est un constat que vous avez rédigé vous-même. Le personnel à qui l'on demande ce qu'une politique exige de lui ne sait pas répondre, parce qu'il s'agit de douze pages d'intentions.
- Considérations relatives à l’auditeur précédent
-
Lorsqu'une organisation change d'auditeur de services, le nouveau cabinet examine le rapport et l'opinion de la période précédente pour planifier sa mission. Il peut demander l'accès à la documentation de son prédécesseur, et il lira avec une attention particulière les exceptions du rapport précédent et les réponses de la direction.
changer de cabinet est normal et souvent judicieux, pour des raisons de coût, de compétences ou de relation. La transition se passe mieux lorsque l'organisation peut montrer que les exceptions antérieures ont été corrigées et que les raisons du changement sont ordinaires. Elle se passe moins bien lorsqu'elle ressemble à une fuite.
- Protection des données dès la conception et par défaut
-
La protection des données dès la conception signifie que la protection des données est prise en compte tout au long du développement d'un produit ou d'un processus, intégrée à l'architecture plutôt qu'ajoutée après coup. La protection des données par défaut signifie qu'avant toute modification par l'utilisateur, les paramètres les plus protecteurs s'appliquent : collecte minimale de données, conservation la plus courte, partage le plus restreint. Les deux sont des obligations au titre de l'article 25 du GDPR.
par défaut est la plus vérifiable des deux, et la plus facile à ne pas respecter. Un produit peut être conçu avec soin et être tout de même livré avec le partage activé, une conservation illimitée et un paramètre de confidentialité désactivé. Les paramètres par défaut sont ce que vivent la plupart des utilisateurs, parce que la plupart des utilisateurs ne les modifient jamais.
- Protection de la vie privée dans la phase de découverte produit
-
Associer la protection de la vie privée à la phase de découverte d'un produit signifie poser les questions relatives aux données lorsque le produit n'est encore qu'une esquisse : ce qui sera collecté, pourquoi, auprès de qui, pour combien de temps, et si le même résultat pourrait être obtenu avec moins. À ce stade, une modification est une conversation. Au lancement, la même modification représente une version, une migration et un retard.
une revue de la protection de la vie privée placée à la fin du processus ne peut qu'approuver ou bloquer. Bloquer un produit fini coûte si cher politiquement que cela arrive rarement, si bien que la revue tardive approuve sous des conditions qui ne sont jamais remplies. La fonction devient une chambre d'enregistrement parce qu'elle a été placée là où elle ne pouvait être rien d'autre.
- Indicateurs de confidentialité
-
Des indicateurs utiles en matière de vie privée mesurent si le programme fonctionne plutôt que son niveau d'activité. Le délai de réponse aux demandes d'exercice des droits par rapport au délai légal. La proportion d'activités de traitement dotées d'une base légale documentée. La date de la dernière mise à jour du registre des activités de traitement. Le nombre de conceptions modifiées lors de la revue de protection de la vie privée. La proportion de fournisseurs disposant d'un DPA conforme. Chacun répond à une question sur l'efficacité.
les conseils d'administration demandent si le programme fonctionne, et la réponse proposée est généralement un décompte : demandes reçues, évaluations réalisées, sessions de formation dispensées. Le volume augmente avec la sensibilisation et avec la taille de l'entreprise, ce qui fait passer une bonne année pour une mauvaise et n'apprend rien au conseil sur le risque.
- Politiques de confidentialité
-
Les articles 13 et 14 du GDPR prescrivent les informations à fournir aux personnes concernées lors de la collecte de leurs données : l'identité du responsable du traitement, les finalités et la base légale, les destinataires, les éventuels transferts, la durée de conservation, leurs droits et, si les données n'ont pas été collectées auprès d'elles, leur source. Les informations doivent être fournies d'une façon concise, transparente, compréhensible et aisément accessible, en des termes clairs et simples.
les politiques de confidentialité sont souvent complètes et illisibles. Chaque élément requis est présent, noyé dans quatre mille mots de rédaction juridique qu'aucune personne concernée ne lira. Cela ne satisfait pas à l'exigence de transparence, même si cela satisfait à celle d'exhaustivité, parce qu'une information qui ne peut pas être comprise n'a pas été fournie.
- Outils des opérations de protection de la vie privée
-
Les outils d'exploitation de la protection de la vie privée prennent en charge le travail récurrent d'un programme : réception et suivi des demandes d'exercice des droits avec leurs délais, tenue du registre des activités de traitement, enregistrement des consentements et gestion des préférences, flux de travail DPIA, évaluations des fournisseurs, et preuves de tout cela. C'est ce qui transforme un ensemble d'obligations en un ensemble de routines.
le travail sur la vie privée est répétitif, soumis à des délais et lourd en preuves, ce qui est exactement le type de travail qui échoue lorsqu'il repose sur la mémoire et le courriel. Une demande d'exercice des droits suivie dans une boîte de réception partagée manque son échéance. Un registre des activités de traitement tenu dans un tableur dérive. Un enregistrement du consentement dans une colonne booléenne ne prouve rien.
- Gestion des accès à privilèges
-
L'accès à privilèges est la capacité de modifier des systèmes, des données ou les accès d'autres personnes : rôles d'administrateur, accès en écriture aux bases de données, droits de déploiement, comptes d'urgence. Le gérer signifie savoir qui le détient, l'accorder pour un objectif et une durée plutôt que de façon permanente, le séparer des comptes que les personnes utilisent au quotidien, et consigner ce qui en a été fait.
l’accès à privilèges permanent est le constat qui apparaît dans presque toutes les premières évaluations, c’est la première chose que recherche un auditeur SOX sur les systèmes qui produisent les chiffres, et c’est la raison pour laquelle les identifiants d’un ingénieur victime d’hameçonnage deviennent une violation plutôt qu’un simple incident. C’est aussi le constat le plus long à corriger, car le supprimer change la façon dont les gens travaillent.
- Lacunes de la gestion des accès à privilèges (PAM)
-
La gestion des accès à privilèges est un ensemble d'outils et de processus conçus pour contrôler, surveiller et auditer l'utilisation des identifiants à privilèges, c'est-à-dire des comptes disposant d'accès élevés aux systèmes, aux données et à l'infrastructure.
les lacunes de PAM sont importantes en TPRM, car les prestataires de services gérés et les fournisseurs d’infrastructure qui détiennent des accès à privilèges aux environnements des clients représentent certains des points de risque les plus lourds de conséquences dans la chaîne d’approvisionnement de l’entreprise.
- Lacunes de la gestion des accès à privilèges (PAM) : les éléments probants
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : confirmation du stockage des identifiants des environnements clients dans un coffre PAM d’entreprise ; confirmation de l’enregistrement des sessions d’accès client, avec durée de conservation ; documentation du périmètre de couverture PAM, accès internes et externes.
- Gestion des accès à privilèges (PAM) dans le contexte des fournisseurs
-
La gestion des accès à privilèges (PAM) ne se limite pas à sécuriser les identifiants d’administration ; elle consiste à maîtriser les conditions dans lesquelles des actions à fort impact peuvent se produire dans un environnement. Fondamentalement, la PAM régit l’accès aux systèmes, aux données et aux capacités susceptibles de modifier de manière significative l’état de l’entreprise.
dans les environnements de tiers, les accès à privilèges sont rarement délimités aussi strictement qu’ils devraient l’être.
- Gestion des accès réseau à privilèges
-
La gestion des accès réseau à privilèges compte en matière de TPRM parce que les administrateurs réseau disposent des accès nécessaires pour modifier les contrôles de sécurité qui protègent tous les autres systèmes.
la gestion des accès réseau à privilèges est importante pour la TPRM parce que les administrateurs réseau disposent des accès nécessaires pour modifier les contrôles de sécurité qui protègent tous les autres systèmes.
- Gestion des accès réseau à privilèges : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : mise en œuvre de l'enregistrement des sessions sur l'infrastructure d'accès à privilèges ; un fournisseur qui confirme une architecture d'hôtes bastions pour l'accès à privilèges doit être interrogé sur l'enregistrement des sessions et le transfert SSH. Le bastion constitue le point de passage obligé. L'enregistrement des sessions et la prévention du contournement de la journalisation sont les contrôles d'observabilité qui rendent ce point de passage utile sur le plan de la sécurité.
- Sécurité des environnements d’exécution des langages de programmation
-
La sécurité de l'environnement d'exécution est importante pour la TPRM parce qu'un fournisseur qui livre un code applicatif bien corrigé exécuté sur un environnement d'exécution en fin de vie (EOL) livre un logiciel dont l'environnement d'exécution fondamental comporte des vulnérabilités non corrigées de façon permanente.
la sécurité de l'environnement d'exécution est importante pour la TPRM parce qu'un fournisseur qui livre un code applicatif bien corrigé exécuté sur un environnement d'exécution en fin de vie (EOL) livre un logiciel dont l'environnement d'exécution fondamental comporte des vulnérabilités non corrigées de façon permanente.
- Sécurité des environnements d'exécution des langages de programmation : les éléments probants
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : calendrier de migration des environnements d'exécution en fin de vie (EOL) ou proches de la fin de vie (EOL) ; un fournisseur qui confirme que ses dépendances applicatives sont à jour doit être interrogé sur l'actualité de ses environnements d'exécution. L'SCA applicative couvre les dépendances. L'évaluation de l'environnement d'exécution couvre la couche sur laquelle s'exécutent les dépendances. Les deux sont nécessaires pour une évaluation complète de la santé de la chaîne d'approvisionnement.
- Injection de prompt
-
L’injection de prompt est une attaque visant un système fondé sur un modèle de langage, dans laquelle un contenu lu par le modèle, comme un document, une page web, un e-mail ou le message d’un utilisateur, contient un texte que le modèle traite comme des instructions plutôt que comme des données. Le modèle fait alors ce que dit le texte de l’attaquant : il exfiltre des informations qui lui ont été fournies, ignore ses règles ou effectue une action au moyen d’un outil auquel il a accès.
c’est la vulnérabilité propre à cette catégorie de systèmes, et il n’existe pas de correctif. Un modèle ne peut pas distinguer de manière fiable les instructions des données dans un même canal : tout système qui laisse un modèle lire un contenu non fiable puis agir en conséquence porte donc cette exposition par conception. Le risque croît avec ce que le modèle peut faire : un modèle qui ne peut que répondre est embarrassant en cas d’injection ; un modèle qui peut envoyer des courriels ou modifier des enregistrements est dangereux.
- Injection de prompt via les fournisseurs
-
L'injection de prompt est une technique d'attaque qui exploite l'incapacité des grands modèles de langage à distinguer de manière fiable les instructions légitimes de l'opérateur, généralement transmises par une invite système, des instructions contrôlées par l'attaquant intégrées aux saisies des utilisateurs ou aux données que le LLM traite. Le LLM est conçu pour suivre des instructions.
l’injection de prompts via les fournisseurs compte en matière de TPRM parce que chaque produit d’IA déployé par un fournisseur qui a accès aux données de l’entreprise constitue une surface d’attaque potentielle par injection de prompts.
- Injection de prompt via les fournisseurs : les éléments probants
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : méthodologie et résultats des tests d'injection de prompt ; documentation du périmètre d'accès aux outils des agents ; contrôles architecturaux (passerelle LLM, garde-fous).
- Pseudonymisation et anonymisation
-
La pseudonymisation remplace les champs identifiants par un jeton ou une clé, de sorte que les données ne peuvent plus être attribuées à une personne sans informations supplémentaires conservées séparément. Les données restent des données personnelles au sens du GDPR, car la ré-identification est possible. L'anonymisation rend les données telles qu'une personne ne peut être identifiée par aucun moyen raisonnablement susceptible d'être utilisé, et les données anonymes sortent entièrement du champ du GDPR.
presque rien de ce qui est présenté comme anonymisé ne satisfait réellement au critère. Supprimer les noms en laissant les dates de naissance, les codes postaux et les intitulés de poste produit des données qui peuvent être ré-identifiées avec un effort modeste. La norme consiste à savoir si la ré-identification est raisonnablement probable, compte tenu du coût, du temps, de la technologie et des autres données disponibles.
- Limitation des finalités
-
La limitation des finalités exige que les données personnelles soient collectées pour des finalités déterminées, explicites et légitimes, et ne soient pas traitées ultérieurement d'une manière incompatible avec ces finalités. Des données collectées pour fournir un service ne peuvent pas glisser vers une autre finalité sans une analyse de compatibilité ou une nouvelle base légale pour ce nouvel usage.
l’exemple type est celui des données de support qui deviennent des données d’entraînement. Des conversations avec les clients, collectées pour résoudre des problèmes, servent plus tard à entraîner un modèle, à améliorer un produit ou à créer un signal commercial. Personne n’a décidé de réaffecter les données ; elles étaient simplement là et utiles. La limitation des finalités est le principe selon lequel l’utilité n’est pas un fondement.
Q
- Opinions avec réserve
-
L'opinion de l'auditeur prend quatre formes. Une opinion sans réserve signifie que les contrôles étaient conçus de manière appropriée et ont fonctionné efficacement. Une opinion avec réserve signifie qu'ils l'étaient, à l'exception d'un point précis que l'auditeur décrit. Une opinion défavorable signifie qu'ils ne l'étaient pas. Une impossibilité d'exprimer une opinion signifie que l'auditeur n'a pu se forger aucune opinion. L'opinion figure en première page, dans des termes conçus pour ne pas attirer l'attention.
l’opinion est la phrase la plus importante du rapport, et elle est régulièrement négligée au profit des tableaux de tests. Une opinion avec réserve n’est pas un audit échoué, mais c’est l’auditeur qui vous dit que quelque chose d’important n’a pas tenu, et le paragraphe qui l’explique mérite d’être lu avant tout le reste.
- Lassitude face aux questionnaires et risque réel
-
La lassitude face aux questionnaires est importante en TPRM, car elle représente l’approche dominante de l’évaluation du risque lié aux tiers et qu’elle donne systématiquement de mauvais résultats sur la question à laquelle la gestion des risques a le plus besoin de répondre : quels sont les risques spécifiques créés par cette relation fournisseur précise, et ces risques sont-ils correctement maîtrisés ?
la lassitude face aux questionnaires est importante pour la TPRM parce qu'elle représente l'approche dominante de l'évaluation du risque lié aux tiers et qu'elle donne systématiquement de mauvais résultats sur la question à laquelle la gestion des risques a le plus besoin de répondre : quels sont les risques précis créés par cette relation fournisseur précise, et ces risques sont-ils maîtrisés de manière adéquate ?
- Lassitude face aux questionnaires et risque réel : les preuves
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : réponses aux questions propres à la relation, avec preuves à l’appui ; reconnaissance du profil de risque spécifique créé par la relation ; preuves de contrôles traitant les risques spécifiques identifiés.
R
- Évaluations de préparation
-
Une évaluation de préparation est un examen du périmètre, des contrôles et des preuves envisagés avant le début de la période d’observation, généralement réalisé par l’auditeur ou un consultant. Elle permet d’identifier les écarts tant qu’ils sont encore peu coûteux à corriger et avant qu’ils ne deviennent des exceptions dans un rapport que vos clients liront.
une exception relevée pendant la phase de préparation est une tâche. La même lacune relevée pendant l'audit est un constat, consigné de façon permanente dans un document que tous les prospects liront pendant l'année suivante. Sur le plan économique, il n'y a pas de comparaison.
- Registres des activités de traitement
-
Le registre des activités de traitement, exigé par l’article 30 du GDPR, est un inventaire de chaque activité de traitement menée par un responsable du traitement ou un sous-traitant : les finalités, les catégories de données et de personnes concernées, les destinataires, les éventuels transferts internationaux, les durées de conservation et une description des mesures de sécurité. C’est la carte de ce que l’organisation fait des données personnelles.
c’est la première chose que demande une autorité de contrôle, car il révèle en un seul document si un programme existe. Personne ne tient un registre des activités de traitement par hasard. Son existence, son exhaustivité et sa mise à jour en disent plus sur la gouvernance des données de l’organisation que n’importe quelle politique.
- Objectifs de reprise
-
L’objectif de délai de reprise est la durée pendant laquelle un service peut être indisponible avant que la perte ne devienne inacceptable. L’objectif de point de reprise est la quantité de données, mesurée en temps, que vous pouvez vous permettre de perdre : l’écart entre la dernière copie saine et la panne. Ce sont deux engagements distincts. Un RTO de quatre heures avec un RPO de vingt-quatre heures signifie que vous serez rétabli avant midi après avoir perdu la journée d’hier.
les clients les exigent tous deux dans les annexes de sécurité, les assureurs les demandent dans les formulaires de souscription, et les référentiels de continuité les exigent par service. Ils ressurgissent aussi le jour où une restauration est nécessaire, lorsque l’organisation découvre que le RPO inscrit dans la politique supposait des sauvegardes quotidiennes, passées à un rythme hebdomadaire lors d’une revue des coûts.
- Angles morts réglementaires
-
Les angles morts réglementaires sont les cadres réglementaires applicables à une relation fournisseur, déterminés par la localisation des données, la résidence des personnes concernées, le secteur d'activité ou la zone géographique des opérations, qui ne sont pas évalués parce que le programme d'évaluation a été conçu pour un autre contexte réglementaire.
les angles morts réglementaires sont importants pour la TPRM parce que les cadres réglementaires non évalués créent une exposition non maîtrisée en matière de conformité.
- Angles morts réglementaires : les éléments probants
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : géographie de l'infrastructure (régions cloud précises où les données sont stockées) ; confirmation de la résidence des personnes concernées (résidents de quelles juridictions sont concernés) ; confirmation de la signature d'un DPA pour les relations soumises au GDPR.
- Écarts d'interprétation réglementaire
-
Les écarts d'interprétation réglementaire sont les divergences entre la manière dont différentes parties (autorités de régulation, organisations, fournisseurs et conseillers juridiques) interprètent les exigences précises des réglementations applicables.
les écarts d'interprétation réglementaire sont importants pour la TPRM parce que l'obligation réglementaire du client est satisfaite lorsque le fournisseur met en œuvre l'exigence selon l'interprétation qu'appliquera l'autorité de régulation, et non selon l'interprétation que le fournisseur juge la plus commode sur le plan opérationnel ou la plus défendable sur le plan juridique.
- Écarts d'interprétation réglementaire : les éléments probants
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : calcul précis de la durée de conservation (événement de départ, événement de fin, exceptions) ; confirmation que le calcul correspond à l'interprétation du client ; fondement réglementaire de l'interprétation du fournisseur.
- Cartographie réglementaire dans la TPRM
-
La cartographie réglementaire est importante parce que les lacunes de conformité découvertes lors d'un contrôle réglementaire coûtent nettement plus cher que celles identifiées et corrigées grâce à une gestion proactive du programme. Une lacune dans l'évaluation du risque de concentration ICT au titre de DORA, identifiée lors d'une analyse des écarts en 2023, peut être corrigée avant la date d'application de 2025.
la cartographie réglementaire est importante parce que les lacunes de conformité découvertes lors d'un contrôle réglementaire coûtent nettement plus cher que celles identifiées et corrigées grâce à une gestion proactive du programme.
- Cartographie réglementaire dans la TPRM : les éléments probants
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : liste des cadres réglementaires applicables à la TPRM ; analyse des écarts DORA (le cas échéant) ; un fournisseur qui confirme un programme de TPRM mature doit être interrogé sur les réglementations qu'il est conçu pour satisfaire et sur leur actualité. La maturité du programme au regard des exigences de 2020 n'est pas la maturité du programme au regard de celles de 2024.
- Confusion due aux chevauchements réglementaires
-
Un chevauchement réglementaire se produit lorsque plusieurs cadres réglementaires s'appliquent à la même organisation, aux mêmes données ou aux mêmes systèmes, chacun imposant des exigences qui peuvent être complémentaires, équivalentes ou contradictoires. HIPAA et PCI-DSS constituent le chevauchement le plus fréquent en matière de traitement des données de santé.
la confusion liée au chevauchement réglementaire est importante en TPRM, car les fournisseurs opérant dans des contextes réglementaires qui se chevauchent peuvent présenter des lacunes de conformité à l’intersection : des domaines où leur programme HIPAA ne satisfait pas aux exigences PCI-DSS et où leur programme PCI-DSS ne traite pas les spécificités HIPAA, laissant le chevauchement sans réponse.
- Confusion due aux chevauchements réglementaires : les éléments probants
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments probants à demander plutôt que des assurances : la cartographie des systèmes soumis à des chevauchements réglementaires, c’est-à-dire l’identification des systèmes soumis à plusieurs cadres ; l’analyse des exigences les plus strictes pour les principaux domaines de chevauchement ; une évaluation unifiée de la conformité pour les systèmes concernés par ces chevauchements.
- Circuits d’approbation des mises en production
-
Les circuits d'approbation des mises en production sont importants pour la TPRM parce que des déploiements automatiques en production sans point de contrôle d'approbation humaine signifient que les constats de sécurité qui ne sont pas configurés comme bloquants seront déployés en production à chaque fusion.
les circuits d’approbation des mises en production sont importants en TPRM, car des déploiements automatiques en production sans point de contrôle d’approbation humaine signifient que les constats de sécurité qui ne sont pas configurés comme bloquants seront déployés en production à chaque fusion.
- Circuits d’approbation des mises en production : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : configuration de la protection de l'environnement de production avec des réviseurs obligatoires ; processus d'acceptation des constats consultatifs pour le déploiement en production ; exigence relative au statut des constats de sécurité dans la revue des versions.
- Sécurité de l'accès à distance pour les effectifs hybrides
-
La sécurité des terminaux d’accès à distance est importante en TPRM, car le personnel en BYOD crée une situation dans laquelle l’accès au réseau de l’entreprise se fait depuis des appareils sans niveau de sécurité de base exigé.
la sécurité des terminaux d’accès à distance est importante en TPRM, car le personnel en BYOD crée une situation dans laquelle l’accès au réseau de l’entreprise se fait depuis des appareils sans niveau de sécurité de base exigé.
- Sécurité de l’accès à distance pour les équipes hybrides : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : mise en œuvre de la vérification de la posture des appareils pour l'accès VPN ; exigences relatives aux appareils gérés pour les systèmes sensibles ; exigences relatives au MDM et aux agents de sécurité des terminaux.
- Diffusion du rapport et NDA
-
Un rapport SOC 2 de type II est un document à usage restreint, destiné à l’entreprise auditée, à ses clients et à leurs auditeurs, ainsi qu’aux personnes ayant une compréhension suffisante du système pour l’interpréter. Il n’est pas destiné à une publication générale. Le SOC 3 existe à cette fin.
le rapport contient des détails sur vos contrôles, votre système et les exceptions relevées, soit exactement ce qu’un attaquant aimerait lire. Il porte également le nom et l’opinion de l’auditeur, qui ne souhaite pas qu’ils soient interprétés par des personnes ne disposant pas du contexte nécessaire.
- Rendre compte ou éclairer
-
Le reporting est la communication des indicateurs et des activités du programme : décomptes, moyennes, taux d’achèvement et points d’avancement qui décrivent ce que le programme a fait.
la distinction entre reporting et analyse compte en matière de TPRM parce que la valeur de gouvernance du programme dépend de la qualité des décisions qu’il permet, et non du volume de ses productions.
- Rendre compte ou éclairer : les éléments probants
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : évaluation honnête de l’évolution du profil de risque du fournisseur au cours des douze derniers mois ; risques ouverts importants dans le programme de sécurité du fournisseur ; améliorations apportées au cours des douze derniers mois.
- Compilations reproductibles en pratique
-
Les builds reproductibles comptent en matière de TPRM parce qu’ils constituent la condition technique préalable à la vérification indépendante de la provenance des logiciels au niveau binaire.
les compilations reproductibles sont importantes pour la TPRM parce qu'elles sont la condition technique préalable à la vérification indépendante de la provenance des logiciels au niveau binaire.
- Les compilations reproductibles en pratique : les éléments probants
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : référence du commit de code source pour les artefacts distribués ; participation au projet Reproducible Builds ou équivalent ; un fournisseur qui confirme la sécurité de sa chaîne d'approvisionnement doit être interrogé sur la reproductibilité. La reproductibilité est le fondement technique de la vérification indépendante. Sans elle, la provenance des binaires doit être acceptée sur la seule base de la confiance dans l'infrastructure de distribution.
- Calendriers de conservation
-
Un calendrier de conservation fixe la durée de conservation de chaque catégorie de données personnelles, et sa justification. Chaque durée est liée à un motif juridique, réglementaire, contractuel ou opérationnel précis. Lorsque le motif disparaît, la conservation prend fin et les données sont supprimées ou anonymisées. Le calendrier est l’expression opérationnelle du principe de limitation de la conservation.
sept ans sont appliqués à tout parce que cela semble défendable. C'est défendable pour les documents financiers dans de nombreuses juridictions, et pour presque rien d'autre. Les données marketing, les tickets de support, les journaux applicatifs et les dossiers de candidats ont chacun leur propre durée justifiée, généralement bien plus courte.
- Recherche et fuite de données
-
Les systèmes à génération augmentée par la recherche répondent aux questions en interrogeant un index de documents et en transmettant les documents pertinents à un modèle. Le modèle peut donc faire ressortir tout ce que contient l’index, et l’index contient souvent des contenus que la personne qui pose la question n’a jamais été autorisée à voir. Le modèle n’en sait rien ; on lui a donné le document et demandé de le résumer.
c’est la manière la plus courante dont un assistant interne devient une violation de données. Un index pratique construit sur un lecteur partagé, un système de tickets et un wiki inclut le dossier RH que quelqu’un a partagé trop largement, le tableur des salaires, l’export de dossiers clients qu’un ingénieur du support a réalisé il y a deux ans. L’assistant répond poliment et avec exactitude à une question sur l’un d’eux, posée par quelqu’un qui n’aurait pas dû la poser.
- Droit d’audit
-
Une clause de droit d'audit vous donne la possibilité contractuelle d'examiner les contrôles d'un fournisseur, soit directement, soit par l'intermédiaire d'un tiers, soit en recevant ses rapports d'assurance indépendants. La plupart des organisations n'exercent jamais la version sur site. Ce qu'elles utilisent, chaque année, c'est la clause qui prévoit que le fournisseur remettra son rapport d'assurance sur demande.
c'est l'une des six clauses contractuelles qui portent le risque lié aux tiers, et c'est celle que l'on négocie le plus âprement tout en prévoyant de ne jamais l'utiliser. Sa valeur réelle est double : elle vous permet d'obtenir le rapport d'assurance sans discussion, et elle modifie le comportement du fournisseur par sa seule existence. Les clients réglementés en ont aussi besoin pour leurs autorités de surveillance, ce qui la rend non négociable dans ces contrats.
- Ensembles de contrôles bien dimensionnés
-
Un ensemble de contrôles doit couvrir les critères avec le plus petit nombre de contrôles que l'organisation peut réellement exploiter et étayer par des preuves à chaque période. Chaque contrôle de l'ensemble est une obligation récurrente : il doit s'exécuter, selon le calendrier prévu, et laisser une trace, tant qu'il fait partie de l'ensemble.
les grands ensembles de contrôles paraissent rigoureux et échouent en pratique. Un ensemble de deux cents contrôles, repris tel quel d'un référentiel, en contient des dizaines que personne n'exploite réellement, et chacun d'eux devient une exception dès le premier audit qui l'échantillonne. L'organisation a créé ses propres constats.
- Les clauses de droit d'audit en pratique
-
Le droit d’audit est important parce que c’est le mécanisme par lequel l’entreprise peut obtenir une vérification directe et indépendante des contrôles de sécurité du fournisseur, impossible à obtenir au moyen de questionnaires et d’examens documentaires. La réponse d’un fournisseur à un questionnaire décrit ce que le fournisseur dit de ses contrôles.
le droit d’audit est important parce que c’est le mécanisme par lequel l’entreprise peut obtenir une vérification directe et indépendante des contrôles de sécurité du fournisseur, impossible à obtenir au moyen de questionnaires et d’examens documentaires.
- Les clauses de droit d'audit en pratique : les éléments probants
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les pièces à demander plutôt que des assurances : confirmation du périmètre et des limites de la clause d'audit ; précisions sur la clause de substitution (ce qui peut être substitué et dans quel but) ; délai de préavis et processus logistique.
- Gouvernance de l’acceptation des risques
-
La gouvernance de l'acceptation des risques est importante parce que les risques acceptés sont des risques que l'organisation a choisi en connaissance de cause d'assumer. Si ce choix est fait sans contrôles compensatoires, surveillance ou limites dans le temps adéquats, l'organisation ne fait que différer la matérialisation du risque au lieu de le gérer.
la gouvernance de l'acceptation des risques est importante parce que les risques acceptés sont des risques que l'organisation a choisi en connaissance de cause d'assumer.
- Gouvernance de l'acceptation des risques : les éléments probants
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : politique d’acceptation des risques avec limites de durée et niveaux d’autorisation ; registre actif des risques acceptés avec dates de revue ; contrôles compensatoires pour les risques acceptés significatifs.
- Usage abusif de l'acceptation des risques
-
L’acceptation du risque est un mécanisme de gouvernance permettant de reconnaître formellement qu’un risque ou une lacune de contrôle précis ne sera pas corrigé dans le délai de remédiation standard, et de documenter la justification métier de cette décision, le niveau de risque résiduel, le responsable métier qui en assume la responsabilité et les conditions dans lesquelles l’acc
Le mauvais usage de l’acceptation des risques est important pour la TPRM parce qu’il produit des registres des risques qui semblent exhaustifs (tous les risques identifiés sont documentés et gérés) tout en contenant en pratique une population croissante d’acceptations anciennes qui représentent de véritables risques non atténués, assumés sans supervision active.
- Mauvais usage de l’acceptation des risques : les preuves
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : registre des risques filtré sur les acceptations anciennes, avec dates et historique des revues ; suivi des engagements de remédiation pour les acceptations assorties d’une remédiation prévue ; configuration de l’expiration des acceptations dans la plateforme GRC.
- Désalignement de l’appétence au risque
-
Le désalignement de l’appétence au risque dans la gestion des fournisseurs est l’écart entre la tolérance formellement définie de l’organisation à l’égard des risques liés aux fournisseurs (exprimée en limites de concentration, exigences minimales de sécurité, seuils de volume de données et critères de profondeur d’intégration) et le profil de risque réel du portefeuille de fournisseurs existant.
le désalignement de l’appétence au risque est important en TPRM, car les cadres d’appétence au risque sont des engagements de gouvernance : le conseil d’administration a défini le niveau de concentration des fournisseurs et de risque de sécurité qu’il est prêt à accepter.
- Désalignement de l’appétence au risque : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : répartition des composants de traitement des données (ce qui est traité et où) ; évaluation de la faisabilité technique d’une réduction du périmètre de traitement ; calendrier de transition et estimations des coûts pour réduire la concentration.
- L’évaluation des risques selon CC3
-
CC3 exige de l’organisation qu’elle précise ses objectifs, identifie les risques pesant sur leur réalisation, analyse ces risques, y compris le risque de fraude, et les réévalue en cas de changement important. En pratique, cela exige une évaluation des risques documentée et réellement tenue à jour plutôt que produite une seule fois pour l’audit.
CC3 est le critère qui relie tout le reste. Les contrôles existent parce que des risques ont été identifiés et, sans trace de ce raisonnement, l’ensemble des contrôles paraît arbitraire. C’est aussi là que les auditeurs cherchent la preuve que l’organisation réfléchit à sa propre exposition plutôt que de se contenter d’appliquer une liste de vérification.
- Lacunes dans la communication des risques
-
La communication des risques est le processus qui garantit que les risques identifiés parviennent aux personnes qui ont l’autorité, les ressources ou la responsabilité opérationnelle nécessaires pour agir, et pas seulement aux personnes qui ont la responsabilité technique de les suivre.
Les lacunes dans la communication des risques sont importantes pour la TPRM parce que la valeur du programme pour l’organisation est déterminée par la qualité des décisions qu’il permet, et que les décisions exigent une communication qui atteint les décideurs sous des formes propices à une action éclairée.
- Lacunes dans la communication des risques : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : matrice des publics pour la communication des risques ; traces de notification des responsables métier pour les constats hautement prioritaires ; documentation des formats de communication selon les publics.
- Défaillances de la hiérarchisation des risques
-
La hiérarchisation des risques est le processus consistant à ordonner les risques selon l’urgence et l’intensité de la réponse de gestion, en fonction de leurs conséquences réelles, c’est-à-dire la combinaison de probabilité et d’impact qui détermine quels risques, s’ils n’étaient pas atténués, causeraient le plus de dommages.
les défaillances de priorisation des risques sont importantes en TPRM, car elles déterminent où se concentrent les ressources de remédiation et l’attention de la direction, et par conséquent où la réduction des risques se produit réellement.
- Défaillances de la hiérarchisation des risques : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : méthodologie ou critères de classement des risques au sein d’un même niveau ; délais de remédiation différenciés selon les conséquences ; constats ouverts les plus lourds de conséquences et état de leur remédiation.
- Difficultés de quantification des risques
-
La quantification des risques consiste à exprimer le risque en termes de probabilité et d’ampleur : la probabilité qu’un événement défavorable précis se produise et son impact financier ou opérationnel s’il se produit.
Les difficultés de quantification des risques sont importantes pour la TPRM parce que les décisions de gouvernance et les décisions métier qui reposent sur les évaluations des risques fournisseurs (allocation budgétaire, assurance, transfert des risques, rapports au conseil d’administration et hiérarchisation de la remédiation) exigent de plus en plus une expression financière des risques plutôt que des classements ordinaux.
- Difficultés de quantification des risques : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : volume et classification des données clients traitées ; estimations des coûts de notification et de réponse aux violations ; plafonds de garantie de la cyberassurance et exclusions pertinentes.
- Exactitude du registre des risques
-
Un registre des risques est l’inventaire de référence des risques identifiés en cours de gestion, c’est-à-dire le paysage des risques actifs que les processus de gouvernance utilisent pour hiérarchiser la remédiation, allouer les ressources et rendre compte à la direction.
L’exactitude du registre des risques est importante pour la TPRM parce que le registre est le principal outil de prise de décision en matière de gouvernance : hiérarchiser les ressources de remédiation, surveiller les éléments à haut risque et rendre compte du risque actuel à la direction.
- Exactitude du registre des risques : les preuves
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : preuves des étapes de remédiation achevées pour les constats de longue durée ; étapes de remédiation restantes avec dates d’achèvement visées ; cause du retard si la remédiation est en retard sur le calendrier.
- Subjectivité de la notation des risques
-
La subjectivité de la notation des risques est la variation des résultats d’évaluation qui découle des différences d’interprétation des évaluateurs quant aux preuves, aux contrôles compensatoires et aux critères de notation, au sein d’une méthode d’évaluation des risques définie. Ce n’est pas un défaut de la structure de la méthode : la structure peut être parfaitement cohérente et bien définie.
La subjectivité de la notation des risques est importante pour la TPRM parce que les notes de risque orientent des décisions lourdes de conséquences : approbation ou rejet du fournisseur, mesures d’atténuation des risques exigées, intensité de la surveillance et exigences contractuelles.
- Subjectivité de la notation des risques : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : preuve technique de la mise en œuvre du contrôle compensatoire ; explication précise de la manière dont le contrôle compensatoire réduit le risque lié au contrôle manquant ; toute validation indépendante de l’efficacité du contrôle compensatoire.
- Accès fondé sur les rôles face à l’utilisation réelle
-
L’écart entre l’accès fondé sur les rôles et l’utilisation réelle est important pour la TPRM parce que les fournisseurs qui utilisent le RBAC pour gérer les accès de leurs employés peuvent compter une population d’utilisateurs disposant d’accès nettement plus étendus que ne l’exige leur travail réel, et cet excès d’accès représente, en cas de compromission d’identifiants, un rayon d’impact supérieur au besoin fonctionnel.
L’écart entre l’accès fondé sur les rôles et l’utilisation réelle est important pour la TPRM parce que les fournisseurs qui utilisent le RBAC pour gérer les accès de leurs employés peuvent compter une population d’utilisateurs disposant d’accès nettement plus étendus que ne l’exige leur travail réel, et cet excès d’accès représente, en cas de compromission d’identifiants, un rayon d’impact supérieur au besoin fonctionnel.
- Accès fondé sur les rôles face à l’utilisation réelle : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : données d’utilisation des autorisations (autorisations utilisées et inutilisées pour les rôles concernés) ; intégration de l’analyse d’utilisation dans le processus de revue des accès ; historique de recalibrage des rôles (date de la dernière mise à jour des rôles en fonction des schémas d’utilisation).
- Autoprotection des applications à l’exécution dans un contexte CI/CD
-
La RASP est importante pour la TPRM parce qu’elle représente la couche de sécurité située entre les contrôles du périmètre réseau qu’un fournisseur a confirmés et le comportement réel de l’application à l’exécution.
La RASP est importante pour la TPRM parce qu’elle représente la couche de sécurité située entre les contrôles du périmètre réseau qu’un fournisseur a confirmés et le comportement réel de l’application à l’exécution.
- Autoprotection des applications à l’exécution dans un contexte CI/CD : les preuves
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : confirmation du déploiement d’une solution RASP ou d’une protection à l’exécution ; couverture et capacité de détection de la protection à l’exécution ; intégration CI/CD pour le déploiement de la protection à l’exécution.
S
- Posture de sécurité SaaS face à l’évaluation traditionnelle des fournisseurs
-
La posture de sécurité SaaS est importante parce que le vecteur d’attaque le plus courant contre les plateformes SaaS n’est pas une compromission au niveau de la plateforme : c’est un accès fondé sur des identifiants via des comptes utilisateurs compromis, des comptes de service dotés de privilèges excessifs et des jetons API persistants.
La posture de sécurité SaaS est importante parce que le vecteur d’attaque le plus courant contre les plateformes SaaS n’est pas une compromission au niveau de la plateforme : c’est un accès fondé sur des identifiants via des comptes utilisateurs compromis, des comptes de service dotés de privilèges excessifs et des jetons API persistants.
- Posture de sécurité SaaS et évaluation traditionnelle des fournisseurs : les preuves
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : confirmation de l’accès API pour l’intégration SSPM ; capacités de reporting sur les utilisateurs et les permissions ; prise en charge de la rotation des identifiants API.
- Vente et partage au titre de la CPRA
-
La CPRA californienne définit la vente comme la communication d’informations personnelles à un tiers en échange d’une contrepartie monétaire ou d’une autre contrepartie de valeur, et le partage comme leur communication à un tiers à des fins de publicité comportementale inter-contextes, que quelque chose de valeur soit échangé ou non. Les deux déclenchent le droit du consommateur de s’y opposer et l’obligation de respecter ce choix.
Les pixels publicitaires ont pris la plupart des entreprises au dépourvu. Un pixel de suivi qui envoie des données de navigation à une plateforme publicitaire en échange de mesures d’audience ou de constitution d’audiences constitue une vente ou un partage au sens de cette définition, même en l’absence de toute facture. La contrepartie est le service reçu, et l’obligation de permettre l’opposition s’applique.
- Échantillonnage et populations
-
Les auditeurs ne testent pas chaque occurrence d’un contrôle. Ils procèdent par échantillonnage, et la taille de l’échantillon dépend de la fréquence du contrôle et de la taille de la population. Un contrôle quotidien peut être échantillonné à 25 occurrences sur l’année ; un contrôle trimestriel à deux ; un contrôle exécuté une seule fois à une. L’approche est standard et les tailles sont conventionnelles.
La population vient en premier, et la produire relève généralement de votre responsabilité. L’auditeur a besoin d’une liste complète et exacte de chaque exécution du contrôle, de chaque changement, de chaque nouvel arrivant, de chaque revue des accès, avant d’y prélever un échantillon. Une population générée à partir d’un rapport filtré, ou d’un système qui ne capture pas chaque occurrence, donne à l’auditeur un échantillon d’un sous-ensemble, et la conclusion qui en est tirée n’est pas étayée.
- SAST, ce qu’il détecte et ce qu’il ne détecte pas
-
Les lacunes en matière de SAST sont importantes pour la TPRM parce qu’une confirmation de SAST sans évaluation de la couverture et de la remédiation donne l’assurance de la présence de l’outil plutôt que de son efficacité.
Les lacunes en matière de SAST sont importantes pour la TPRM parce qu’une confirmation de SAST sans évaluation de la couverture et de la remédiation donne l’assurance de la présence de l’outil plutôt que de son efficacité.
- SAST, ce qu’il détecte et ce qu’il ne détecte pas : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : cartographie de la couverture SAST avec les modules exclus et leur justification ; SLA de remédiation SAST par niveau de gravité ; il convient de demander à un fournisseur qui confirme utiliser le SAST sa couverture et son arriéré de remédiation. La présence du SAST est l’outil. La couverture et la vitesse de remédiation sont les indicateurs d’efficacité.
- SAST face à la réduction réelle des risques
-
Le SAST est l’une des pratiques de sécurité applicative les plus souvent citées dans les réponses des fournisseurs aux questionnaires, et l’une des plus souvent présentées de façon trompeuse, non par tromperie délibérée, mais parce que la question « utilisez-vous le SAST ? » peut recevoir une réponse exacte de tout fournisseur dont la chaîne d’outils de développement comprend un scanner, que celui-ci
Le SAST est l’une des pratiques de sécurité applicative les plus souvent citées dans les réponses des fournisseurs aux questionnaires, et l’une des plus souvent présentées de façon trompeuse, non par tromperie délibérée, mais parce que la question « utilisez-vous le SAST ? » peut recevoir une réponse exacte de tout fournisseur dont la chaîne d’outils de développement comprend un scanner, que celui-ci
- SAST face à la réduction réelle des risques : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : nombre de constats critiques et élevés ouverts pour l’application concernée, avec des données de tendance montrant le sens de l’évolution ; délai moyen de remédiation des constats critiques, sous forme de chiffre et non de déclaration de principe ; confirmation de la politique de blocage avec documentation du processus d’exception.
- Périmètre et frontière du système
-
La frontière du système définit quels systèmes, personnes, processus et données sont inclus dans l’audit et lesquels ne le sont pas. Tout ce qui est à l’intérieur est décrit et testé. Tout ce qui est à l’extérieur n’est pas testé, et le rapport n’en dit rien. C’est l’entreprise auditée qui trace la frontière.
Un périmètre étroit produit un audit moins coûteux et plus rapide, et un rapport qui couvre moins que ce que suppose le lecteur. Un périmètre large produit l’inverse. Aucun des deux n’est erroné, mais le choix doit être fait délibérément, et le périmètre doit correspondre à ce que les clients achètent réellement.
- Extension du périmètre entre deux cycles d’audit
-
Les produits évoluent plus vite que le périmètre d’audit. Entre un rapport et le suivant, un fournisseur peut lancer de nouveaux services, ouvrir de nouvelles régions, acquérir une entreprise ou migrer son infrastructure. Le rapport dont vous disposez décrit le système tel qu’il était pendant une période qui s’est terminée il y a un certain temps.
Le rapport est exact et, en même temps, ne couvre pas ce que vous achetez aujourd’hui. Un client qui a adopté une nouvelle fonctionnalité il y a six mois peut s’appuyer sur un rapport dont la description du système est antérieure à l’existence de cette fonctionnalité.
- Gestion des secrets & des clés
-
La gestion des secrets est la discipline qui consiste à contrôler la manière dont les identifiants sensibles (clés API, mots de passe, certificats, clés de chiffrement, jetons et chaînes de connexion) sont créés, stockés, distribués, utilisés et retirés. Cela ressemble à un simple problème d’hygiène informatique, et c’est précisément pour cette raison que le sujet est si systématiquement sous-estimé.
Les intégrations des fournisseurs reposent presque entièrement sur des secrets.
- Gestion des secrets & des clés : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : plateforme de gestion des secrets nommée, avec contrôles d’accès documentés et journalisation d’audit ; politique de rotation fixant une durée de vie maximale des identifiants, idéalement 90 jours ou moins ; processus de révocation immédiate lors du départ de personnes disposant d’accès.
- Secrets dans le code source
-
Les secrets dans le code source sont importants en TPRM, car les dépôts de développement de vos fournisseurs peuvent contenir des identifiants donnant accès à des systèmes qui traitent vos données : identifiants de bases de données de production, clés de fournisseurs de cloud, jetons API de services qui traitent vos données.
Les secrets présents dans le code source sont importants pour la TPRM parce que les dépôts de développement de vos fournisseurs peuvent contenir des identifiants donnant accès à des systèmes qui traitent vos données : identifiants de bases de données de production, clés de fournisseurs cloud, jetons API de services qui manipulent vos données.
- Secrets dans le code source : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : mise en œuvre d’un crochet de pré-commit pour la détection des secrets ; confirmation de la rotation des identifiants pour toute exposition passée ; politique de gestion des secrets et son application.
- Gestion des secrets en CI/CD
-
L’hygiène de gestion des secrets est importante pour la TPRM parce que les identifiants des pipelines CI/CD (clés d’accès aux fournisseurs cloud, jetons de registre d’artefacts, identifiants de déploiement en production) comptent parmi les identifiants les plus précieux de l’environnement d’une entreprise.
L’hygiène de gestion des secrets est importante pour la TPRM parce que les identifiants des pipelines CI/CD (clés d’accès aux fournisseurs cloud, jetons de registre d’artefacts, identifiants de déploiement en production) comptent parmi les identifiants les plus précieux de l’environnement d’une entreprise.
- Gestion des secrets en CI/CD : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : calendrier de rotation des secrets et dates des dernières rotations ; documentation de la portée des secrets (quelles étapes accèdent à quels secrets) ; il convient d’interroger un fournisseur qui confirme gérer ses secrets sur la rotation, le masquage et l’hygiène de l’historique git. La gestion des secrets est le mécanisme de stockage. La rotation, le masquage et l’hygiène de l’historique déterminent si les secrets stockés restent secrets.
- Application des normes de codage sécurisé
-
Une norme de codage sécurisé est un ensemble défini de règles, de lignes directrices et d’exigences qui précisent comment les développeurs doivent écrire le code pour éviter d’introduire des vulnérabilités de sécurité.
Les normes de codage sécurisé sont le contrôle en amont qui détermine la qualité de sécurité du code avant que les outils d’analyse automatisée n’aient l’occasion de détecter ce que ces normes étaient censées prévenir.
- Application des normes de codage sécurisé : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : documentation de la correspondance des règles SAST indiquant quelles exigences de la norme sont appliquées automatiquement par l’outillage ; confirmation de la plateforme de formation avec description d’un contenu propre à chaque langage et pertinent au regard de la norme ; indicateurs de conformité (pourcentage du code respectant les exigences de la norme, mesuré par un outillage).
- SDLC sécurisé dans les environnements des fournisseurs
-
La sécurité applicative des fournisseurs est la catégorie de risque la plus directement liée à ce que vit réellement votre organisation lorsque le logiciel d’un fournisseur est piraté, exploité ou s’avère contenir des vulnérabilités. Toutes les autres dimensions de la sécurité des fournisseurs (configuration du cloud, gestion des accès, chiffrement) opèrent au niveau de l’infrastructure.
la sécurité applicative des fournisseurs est la catégorie de risque la plus directement liée à ce que vit réellement votre organisation lorsque le logiciel d’un fournisseur est piraté, exploité ou s’avère contenir des vulnérabilités.
- SDLC sécurisé dans les environnements des fournisseurs : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : synthèse de test d’intrusion limitée à l’application concernée, datant de moins de 12 mois, avec le nombre de constats ouverts par niveau de gravité ; confirmation de l’outil SAST avec fréquence d’analyse, couverture du code et documentation des SLA de remédiation ; documentation du processus de divulgation des vulnérabilités avec un délai de notification engagé et des SLA de remédiation par niveau de gravité.
- Programme de champions de la sécurité en DevSecOps
-
Les programmes de champions de la sécurité sont importants pour la TPRM parce qu’ils constituent le mécanisme organisationnel qui diffuse la sécurité dans le flux de développement, là où elle peut le plus efficacement prévenir les vulnérabilités avant qu’elles ne soient intégrées au code.
Les programmes de champions de la sécurité sont importants pour la TPRM parce qu’ils constituent le mécanisme organisationnel qui diffuse la sécurité dans le flux de développement, là où elle peut le plus efficacement prévenir les vulnérabilités avant qu’elles ne soient intégrées au code.
- Programme de champions de la sécurité en DevSecOps : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : nombre de champions actifs par équipe de développement ; date de la dernière formation ou réunion des champions ; constats de sécurité attribués aux champions au cours du dernier trimestre.
- Suivi de la dette de sécurité et vitesse de remédiation
-
Le suivi de la dette de sécurité est important en TPRM, car le rapport entre constats générés et constats corrigés est l’indicateur disponible le plus fiable pour savoir si un programme DevSecOps améliore réellement la posture de sécurité.
Le suivi de la dette de sécurité est important pour la TPRM parce que le rapport entre constats générés et constats corrigés est l’indicateur disponible le plus précis pour savoir si un programme DevSecOps améliore réellement la posture de sécurité.
- Suivi de la dette de sécurité et vitesse de remédiation : les preuves
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : arriéré actuel de constats par niveau de gravité ; évolution nette de l’arriéré au dernier trimestre (hausse ou baisse) ; répartition par ancienneté des constats critiques et élevés.
- Contournement des contrôles de sécurité en CI/CD
-
Les contournements des points de contrôle de sécurité sont importants en TPRM, car ils marquent la différence entre des points de contrôle de sécurité qui sont des contrôles et des points de contrôle qui ne sont que de la surveillance. Un point de contrôle que les administrateurs peuvent contourner unilatéralement à la demande est un outil de surveillance qui génère des alertes quand l’alerte dérange.
Les contournements des points de contrôle de sécurité sont importants pour la TPRM parce qu’ils marquent la différence entre des points de contrôle de sécurité servant de contrôles et des points de contrôle de sécurité servant à la surveillance.
- Contournements des points de contrôle de sécurité en CI/CD : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : politique de gouvernance des contournements (qui peut contourner et avec quelle approbation) ; disponibilité d’un journal d’audit des événements de contournement ; processus et fréquence de revue du journal des contournements.
- Cloisonnement des opérations de sécurité
-
Le cloisonnement des opérations de sécurité désigne les séparations organisationnelles et techniques entre les équipes de sécurité spécialisées (sécurité applicative, sécurité du cloud, sécurité des terminaux, SOC, sécurité réseau) qui empêchent la visibilité transversale, la corrélation des constats entre domaines et l’identification des chaînes d’attaque entre domaines.
Le cloisonnement des opérations de sécurité est important pour la TPRM parce que les chaînes d’attaque qu’utilisent les attaquants sophistiqués de la chaîne d’approvisionnement pour atteindre les données des clients s’étendent généralement sur plusieurs domaines de sécurité : exploitation de vulnérabilités applicatives pour obtenir un accès initial, de mauvaises configurations des terminaux pour élever les privilèges et de mauvaises configurations du cloud pour atteindre des
- Cloisonnement des opérations de sécurité : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : mécanisme de corrélation entre domaines (outil ou processus) ; périmètre des exercices red team (chaînes entre domaines testées) ; capacité d’évaluation des chemins d’attaque multidomaines.
- Les questionnaires de sécurité à grande échelle
-
Répondre aux questionnaires de sécurité des acheteurs est un coût récurrent de la vente aux organisations réglementées, et la façon habituelle de les traiter est mauvaise d’une manière bien précise : chacun est rempli de mémoire par la personne qui a rempli le précédent, un peu différemment chaque fois, et personne ne consigne ce qui a été dit. Six mois plus tard, un questionnaire similaire arrive et le travail repart de zéro.
trois questionnaires reçus en un trimestre au sujet du chiffrement au repos obtiennent trois réponses différentes, aucune fausse, chacune mettant l’accent sur un point différent. Un quatrième, rempli dans l’urgence, engage l’entreprise sur un contrôle qu’elle n’applique pas, et cette réponse est désormais une déclaration contractuelle dont personne à l’ingénierie ne sait qu’elle a été faite.
- Tests de sécurité des indicateurs de fonctionnalité
-
La sécurité des indicateurs de fonctionnalité est importante pour la TPRM parce que les indicateurs de fonctionnalité constituent un mécanisme de déploiement qui contourne les contrôles du pipeline CI/CD si le processus d’activation des indicateurs n’est pas soumis à une gouvernance de sécurité équivalente.
la sécurité des indicateurs de fonctionnalité est importante en TPRM, car les indicateurs de fonctionnalité constituent un mécanisme de déploiement qui contourne les contrôles du pipeline CI/CD si le processus d’activation de l’indicateur ne fait pas l’objet d’une gouvernance de sécurité équivalente.
- Tests de sécurité des indicateurs de fonctionnalité : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : documentation du contrôle d’accès aux indicateurs de fonctionnalité (qui peut les activer en production) ; circuit d’approbation pour toute nouvelle activation d’indicateur de fonctionnalité ; lien entre la revue de sécurité et l’état des indicateurs de fonctionnalité.
- Séparation des tâches
-
La séparation des tâches est le principe selon lequel aucune personne ne peut mener seule une action sensible de bout en bout : celui qui demande n’approuve pas, celui qui développe ne déploie pas en production, celui qui accorde un accès ne le révise pas, celui qui modifie un bénéficiaire ne libère pas le paiement. C’est un contrôle contre l’erreur comme contre la fraude, et c’est le contrôle que les petites organisations ont le plus de mal à appliquer.
Les auditeurs la testent directement, les contrôles financiers en dépendent, et son absence est ce qui fait d’une seule personne compromise ou négligente un événement significatif. Elle intervient aussi dans les revues des accès, où le réviseur qui approuve son propre accès a appris quelque chose à l’auditeur, et dans la gestion des changements, où un développeur qui peut fusionner et déployer seul a retiré la revue du processus.
- Choisir la bonne méthodologie d’évaluation de la sécurité réseau
-
Le choix de la méthode d’évaluation est important pour l’efficacité du programme de TPRM, car une méthode inadaptée (une évaluation peu approfondie pour des fournisseurs très critiques) crée un faux sentiment d’assurance : le fournisseur a été évalué, l’évaluation n’a relevé aucun problème, mais la méthode d’évaluation était insuffisante pour trouver les problèmes qui existent.
Le choix de la méthodologie d’évaluation est important pour l’efficacité du programme de TPRM parce qu’une méthodologie inadaptée (une évaluation peu approfondie pour des fournisseurs très critiques) crée un faux sentiment d’assurance : le fournisseur a été évalué, l’évaluation n’a relevé aucun problème, mais la méthodologie d’évaluation était insuffisante pour détecter les problèmes existants.
- Choisir la bonne méthode d’évaluation de la sécurité réseau : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : exigences de preuves techniques pour les fournisseurs critiques ; intégration d’analyses externes pour les fournisseurs critiques ; revue de la méthodologie dans le cadre de la gouvernance de la TPRM.
- Lacunes de la découverte des données sensibles
-
La découverte des données sensibles est le processus systématique d’analyse de l’environnement de données d’une organisation visant à identifier où se trouvent les données sensibles (informations personnelles, données financières, informations de santé, identifiants et autres catégories de données réglementées ou à forte valeur) dans les systèmes de stockage, les documents, les plateformes collaboratives et les i
Les lacunes de la découverte des données sensibles sont importantes pour la TPRM parce qu’elles représentent la catégorie d’exposition des données qui est invisible pour les évaluations standard de la sécurité des fournisseurs.
- Lacunes de la découverte des données sensibles : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : documentation du périmètre du programme de découverte (tous les systèmes inclus, avec confirmation précise de la couverture des plateformes de support et de collaboration) ; synthèse des résultats de la dernière analyse de découverte pour les systèmes de support ; documentation du processus de remédiation pour les données sensibles découvertes hors périmètre.
- Sécurité du serverless en CI/CD
-
La sécurité du serverless est importante en TPRM, car des rôles d’exécution Lambda trop permissifs sont un constat fréquent dans les environnements serverless qui n’ont pas appliqué le principe du moindre privilège à la configuration IAM des fonctions.
la sécurité du serverless est importante en TPRM, car des rôles d’exécution Lambda trop permissifs sont un constat fréquent dans les environnements serverless qui n’ont pas appliqué le principe du moindre privilège à la configuration IAM des fonctions.
- Sécurité du serverless en CI/CD : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : comptes rendus de revue du moindre privilège des rôles d’exécution ; utilisation de IAM Access Analyzer ou d’un outil équivalent ; analyse de l’IaC pour la sécurité des rôles d’exécution.
- Auditeur de services et organisation de services
-
L’organisation de services est l’entreprise auditée. L’auditeur de services est le cabinet CPA qui réalise la mission. L’entité utilisatrice est le client qui s’appuie sur le rapport, et l’auditeur utilisateur est l’auditeur propre de ce client, qui peut à son tour s’appuyer sur le rapport. Le rapport est rédigé pour ces deux derniers.
Savoir quel rôle vous occupez change la manière dont vous lisez le document. Les CUEC sont rédigés pour l’entité utilisatrice et son auditeur, c’est pourquoi ils se lisent comme des instructions. La description du système est rédigée par l’organisation de services à son propre sujet. L’opinion est celle de l’auditeur de services, adressée à la direction de l’organisation de services.
- Risques de détournement de session
-
Le détournement de session est la technique d’attaque consistant à voler l’élément d’identification de session obtenu après authentification (généralement un cookie de session, un jeton d’accès ou un jeton d’actualisation) et à l’utiliser pour accéder aux systèmes en tant qu’utilisateur authentifié sans repasser par le processus d’authentification.
Le risque de détournement de session est important pour la TPRM parce que les fournisseurs qui détiennent des jetons de session valides pour accéder aux environnements clients offrent un vecteur d’attaque supplémentaire au-delà du vol d’identifiants.
- Risques de détournement de session : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : documentation de la durée de vie des jetons d’accès et d’actualisation ; confirmation de la mise en œuvre de l’évaluation continue des accès ; capacité de révocation des sessions et délai de réponse.
- IA fantôme
-
L’IA fantôme désigne l’utilisation d’outils et de fonctionnalités d’IA que personne n’a approuvés ni recensés : assistants grand public utilisés sur des comptes personnels, modèles appelés depuis le code de production sans revue, et assistants activés dans des produits que l’organisation achète déjà. Cette dernière catégorie est la plus importante et la moins visible, car la nouvelle fonctionnalité d’un fournisseur ne donne pas l’impression d’adopter l’IA.
L’interdiction ne fonctionne pas. Bannir une catégorie sans proposer d’alternative approuvée déplace l’activité vers des comptes personnels où vous ne voyez rien. Et une enquête ne la détecte pas non plus, car les gens décrivent les outils qu’ils ont choisis délibérément, et non la fonctionnalité apparue dans la plateforme de support le trimestre dernier, qui résume désormais chaque ticket.
- Cloud fantôme utilisé par les fournisseurs
-
L’utilisation d’un cloud fantôme par les fournisseurs désigne la création, la modification ou l’exploitation de ressources cloud dans l’environnement d’un client, ou à l’aide de l’identité cloud et de la facturation du client, sans que le client ait explicitement connaissance de ces activités précises ni ne les ait approuvées.
L’utilisation d’un cloud fantôme par les fournisseurs est l’un des exemples les plus clairs de la manière dont le risque lié aux tiers dans les environnements cloud ne peut être évalué au seul niveau de l’organisation du fournisseur.
- Cloud fantôme utilisé par les fournisseurs : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : une description claire des types de ressources que le fournisseur doit pouvoir créer, avec leur justification opérationnelle ; la preuve de contrôles internes empêchant les ingénieurs du fournisseur de provisionner des ressources non autorisées dans les environnements clients ; un processus défini de mise hors service des ressources créées par le fournisseur à la fin de la mission.
- Limites de couverture du SIEM
-
Les limites de couverture du SIEM sont les écarts entre les systèmes et environnements qu’une plateforme SIEM surveille et l’ensemble du parc technologique qui génère des événements pertinents pour la sécurité. Une plateforme SIEM surveille ce dont elle reçoit la télémétrie : les systèmes, services et environnements configurés pour transmettre des journaux et des événements au SIEM.
les limites de couverture du SIEM sont importantes en TPRM, car les attaquants de la chaîne d’approvisionnement ciblent précisément les voies d’entrée les moins surveillées dans les environnements des fournisseurs : les services gérés, les systèmes d’accès des prestataires et les pipelines de développement, plus susceptibles de présenter des lacunes de couverture de surveillance.
- Limites de couverture du SIEM : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : confirmation de la couverture des services gérés ou divulgation des lacunes ; il convient de demander à un fournisseur disposant d’un SIEM mature l’inventaire des intégrations. Le déploiement du SIEM décrit la capacité. L’inventaire décrit ce que couvre cette capacité.
- SIG et SIG Lite
-
Le questionnaire Standardized Information Gathering est un vaste ensemble structuré de questions tenu à jour par le programme Shared Assessments, qui couvre la sécurité, la protection de la vie privée, la résilience et les domaines connexes. SIG Lite en est la version de base, plus courte. Leur intérêt est qu’un fournisseur en a peut-être déjà rempli un, ce qui transforme votre évaluation en un examen de réponses existantes plutôt qu’en un nouvel interrogatoire.
Lorsque votre programme détermine quel instrument utiliser pour chaque niveau, les jeux standard sont les candidats évidents pour le niveau supérieur, et les fournisseurs qui vendent à des acheteurs réglementés tiennent souvent à jour un SIG rempli précisément pour cette raison. En accepter un fait gagner des semaines aux deux parties, à condition de le lire plutôt que de le classer.
- Sigstore et la révolution des journaux de transparence
-
Sigstore est important pour la TPRM parce qu’il fournit une norme gratuite et accessible de signature et de transparence pour la chaîne d’approvisionnement logicielle, qui lève l’obstacle technique à l’adoption pour les petits fournisseurs.
Sigstore est important pour la TPRM parce qu’il fournit une norme gratuite et accessible de signature et de transparence pour la chaîne d’approvisionnement logicielle, qui lève l’obstacle technique à l’adoption pour les petits fournisseurs.
- Sigstore et la révolution des journaux de transparence : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : confirmation de l’adoption de Sigstore Cosign ou feuille de route ; vérification des entrées du journal Rekor pour les versions récentes ; approche actuelle de signature et de gestion des clés si Sigstore n’est pas utilisé.
- SLA face à l’application effective
-
Les accords de niveau de service définissent les normes de performance qu’un fournisseur doit respecter : pourcentages de disponibilité, délais de réponse, fenêtres de traitement et délais de résolution.
la distinction entre SLA et application effective est importante en TPRM, car les SLA sont un outil contractuel essentiel de gestion des risques : ils fixent des normes de performance censées garantir que les fournisseurs livrent des services fiables et de grande qualité.
- SLA face à l’application effective : les preuves
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : analyse des causes profondes de chaque manquement au SLA ; mesures de remédiation précises avec calendrier ; investissements d’infrastructure ou changements opérationnels prévus.
- SOC 1, SOC 2 et SOC 3
-
Un SOC 1 porte sur les contrôles pertinents pour l’information financière d’un client ; c’est ce que l’auditeur financier d’un client attend d’un prestataire de paie ou de facturation. Un SOC 2 porte sur les Trust Services Criteria, pour les clients soucieux de sécurité et d’exploitation. Un SOC 3 est une synthèse publique, à usage général, d’un SOC 2, sans le détail des tests.
Un même fournisseur peut détenir deux de ces rapports pour des raisons différentes, et recevoir le mauvais fait perdre un cycle de revue. Le rapport SOC 1 d’un prestataire de paie ne dit rien de sa posture de sécurité, et son rapport SOC 2 ne dit rien de l’exactitude de ses traitements financiers.
- SOC 2 plus
-
Un SOC 2 plus, parfois écrit SOC 2+, est une mission SOC 2 étendue pour rendre compte de critères supplémentaires en plus des critères des services de confiance, généralement ISO 27001, HIPAA, la Cloud Controls Matrix de la CSA ou le NIST CSF. L’auditeur associe les contrôles de l’organisation à chaque référentiel et rend compte de l’ensemble dans un seul document.
Pour un fournisseur dont les clients demandent des référentiels différents, c’est réellement efficace. Un seul cycle de collecte des preuves, un seul audit, plusieurs livrables d’assurance. Pour un client, cela signifie que le rapport SOC 2 qu’il reçoit peut déjà répondre à ses questions ISO ou HIPAA sans exercice distinct.
- SOC 2 Type I et Type II
-
Un rapport de type I examine si les contrôles étaient conçus de manière appropriée et en place à une date donnée. Un type II examine si ces contrôles ont effectivement fonctionné, comme décrit, sur une période, généralement de trois à douze mois. Les deux sont émis selon la même norme et se ressemblent en couverture, et c’est là que commence la confusion.
Un Type I prouve qu’un contrôle existait un jour donné. Un Type II prouve qu’il a continué de fonctionner pendant des mois, malgré les changements de personnel, les mises en production et la pression ordinaire pour sauter une étape. Les équipes achats ont appris à demander le second parce que le premier ne dit presque rien sur la constance du comportement d’un fournisseur.
- Limites de l’automatisation du SOC
-
Les limites de l’automatisation du SOC sont les modes de défaillance, les lacunes de couverture et les vulnérabilités liées à la dérive qui empêchent les outils automatisés d’opérations de sécurité (plateformes SOAR, systèmes de tri automatisé et flux d’orchestration) de remplir de manière fiable les fonctions pour lesquelles ils ont été déployés.
les limites de l’automatisation du SOC sont importantes en TPRM, car le déploiement d’un SOAR donne l’apparence d’une meilleure couverture de détection et d’une plus grande capacité des analystes sans garantir que l’automatisation remplit correctement les fonctions qu’elle a remplacées.
- Limites de l’automatisation du SOC : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : date de la dernière revue d’alignement sur l’environnement ; procédure d’intégration de la gestion des changements au SOAR ; il convient d’interroger un fournisseur qui confirme le déploiement d’un SOAR sur la surveillance de l’état de ses playbooks. Le déploiement décrit ce qui a été installé. La surveillance de l’état indique si ce qui a été installé fonctionne toujours correctement. La dérive de l’environnement rend cette distinction essentielle.
- Exception « soft opt-in »
-
L’exception « soft opt-in » est une dérogation prévue par les règles ePrivacy qui permet la prospection par courriel ou par SMS sans consentement préalable, lorsque les coordonnées du destinataire ont été obtenues à l’occasion d’une vente ou de la négociation d’une vente, que la prospection porte sur des produits ou services similaires et qu’une possibilité de s’y opposer a été offerte lors de la collecte et dans chaque message ultérieur.
C’est la base la plus couramment invoquée pour la prospection auprès des clients existants, et elle est fréquemment étendue au-delà de ses conditions. L’exception exige une vente ou la négociation d’une vente. Elle exige des produits similaires. Elle exige que la possibilité de s’opposer ait été offerte au moment de la collecte des coordonnées, et non ajoutée ultérieurement.
- Nomenclature logicielle : au-delà de l’obligation
-
la qualité de la SBOM est importante en TPRM, car une SBOM obsolète, incomplète ou dépourvue d’informations sur l’état des vulnérabilités donne l’apparence de la transparence de la chaîne d’approvisionnement sans en avoir la substance.
la qualité de la SBOM est importante en TPRM, car une SBOM obsolète, incomplète ou dépourvue d’informations sur l’état des vulnérabilités donne l’apparence de la transparence de la chaîne d’approvisionnement sans en avoir la substance.
- Nomenclature logicielle, au-delà de l’obligation : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : SBOM propre à chaque version dans un format standard (CycloneDX ou SPDX) ; documentation VEX pour les composants présentant des vulnérabilités critiques connues ; processus de génération du SBOM et cadence de mise à jour.
- Automatisation de la nomenclature logicielle
-
L’automatisation des SBOM est importante pour la TPRM parce que la valeur de renseignement d’un programme SBOM est proportionnelle à la rapidité avec laquelle les nouvelles CVE présentes dans l’inventaire déclenchent la prise de conscience et l’action de l’entreprise. Un programme qui examine les SBOM une fois par an lors de la réévaluation offre une connaissance des CVE avec douze mois de retard.
l’automatisation de la SBOM est importante en TPRM, car la valeur de renseignement d’un programme de SBOM est proportionnelle à la rapidité avec laquelle de nouvelles CVE touchant l’inventaire déclenchent la prise de conscience et l’action de l’entreprise.
- Automatisation de la nomenclature logicielle : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : SBOM au format CycloneDX JSON pour la version actuellement déployée ; processus de notification des CVE pour les vulnérabilités des composants ; cadence de mise à jour du SBOM (fréquence des mises à jour).
- Lacunes de l’analyse de la composition logicielle
-
les lacunes de l’SCA sont importantes en TPRM, car le rapport « zéro vulnérabilité critique » d’un outil SCA ne couvre que ce que l’outil a été configuré pour analyser.
les lacunes de l’SCA sont importantes en TPRM, car le rapport « zéro vulnérabilité critique » d’un outil SCA ne couvre que ce que l’outil a été configuré pour analyser.
- Lacunes de l’analyse de la composition logicielle : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : documentation du périmètre de l’SCA (dépôts et écosystèmes couverts) ; fréquence des analyses et intégration au flux de développement ; il convient de demander à un fournisseur qui confirme la mise en œuvre d’un outil d’SCA la documentation de son périmètre. L’existence de l’outil confirme la capacité. La documentation du périmètre révèle ce que couvre cette capacité et ce qu’elle manque.
- Analyse de la composition logicielle en CI/CD
-
la couverture SCA dans la CI/CD est importante en TPRM, car l’exposition aux vulnérabilités logicielles est déterminée par le composant le moins bien couvert, et non par le mieux couvert.
la couverture SCA dans la CI/CD est importante en TPRM, car l’exposition aux vulnérabilités logicielles est déterminée par le composant le moins bien couvert, et non par le mieux couvert.
- Analyse de la composition logicielle en CI/CD : les preuves
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : cartographie de couverture SCA incluant tous les dépôts de production ; taux de fusion des PR du robot de mise à jour des dépendances pour les constats critiques ; configuration de l’application CI/CD pour l’SCA.
- Vérification de la provenance des logiciels
-
La vérification de la provenance des logiciels est importante en TPRM, car la compromission des infrastructures de distribution est un vecteur d’attaque documenté : c’est le mécanisme utilisé lors de l’attaque NotPetya (via l’infrastructure de mise à jour de M.E.Doc), de l’attaque ASUS Live Update et d’incidents similaires de la chaîne d’approvisionnement.
La vérification de la provenance des logiciels est importante pour la TPRM parce que les compromissions de l’infrastructure de distribution sont un vecteur d’attaque documenté : c’est le mécanisme utilisé dans l’attaque NotPetya (via l’infrastructure de mise à jour de M.E.Doc), dans l’attaque ASUS Live Update et dans d’autres incidents similaires de la chaîne d’approvisionnement.
- Vérification de la provenance des logiciels : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : attestation de provenance SLSA pour des versions précises ; processus de vérification des entrées du journal de transparence ; il convient d’interroger un fournisseur qui confirme la signature de ses versions sur la vérification des attestations de provenance. La signature confirme que la clé a signé l’artefact. L’attestation de provenance confirme que le système de compilation a produit ce que la clé a signé. La compromission de l’infrastructure de distribution contourne la signature si l’attaquant disposait aussi d’un accès de signature. Une attestation de provenance consignée dans un journal de transparence immuable avant la compromission est la preuve que la compromission ne peut pas effacer.
- Chaîne d’approvisionnement logicielle des produits SaaS
-
La sécurité de la chaîne d’approvisionnement SaaS est importante pour la TPRM parce que les entreprises qui ont le plus investi dans les contrôles de la chaîne d’approvisionnement des logiciels installés (SBOM, SCA, provenance) dépendent simultanément de services SaaS dont la sécurité de la chaîne d’approvisionnement est entièrement gérée par le fournisseur.
La sécurité de la chaîne d’approvisionnement SaaS est importante pour la TPRM parce que les entreprises qui ont le plus investi dans les contrôles de la chaîne d’approvisionnement des logiciels installés (SBOM, SCA, provenance) dépendent simultanément de services SaaS dont la sécurité de la chaîne d’approvisionnement est entièrement gérée par le fournisseur.
- Chaîne d’approvisionnement logicielle des produits SaaS : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : SBOM de la plateforme SaaS ou inventaire équivalent des dépendances ; programme de surveillance des vulnérabilités des dépendances open source ; processus de détection et de notification des compromissions du pipeline de compilation.
- Sécurité de la chaîne d’approvisionnement logicielle
-
La sécurité de la chaîne d’approvisionnement logicielle tient en une question fondamentale : pouvez-vous faire confiance non seulement au logiciel que livre un fournisseur, mais aussi à l’ensemble du processus qui l’a produit ? La plupart des contrôles de sécurité portent sur ce que fait le logiciel une fois en cours d’exécution : recherche de vulnérabilités, surveillance des anomalies, contrôle des accès.
les évaluations traditionnelles des tiers traitent le fournisseur comme l’unité de risque : ses contrôles, ses certifications, ses politiques.
- Sécurité de la chaîne d’approvisionnement logicielle : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : un SBOM lisible par machine au format CycloneDX ou SPDX, à jour à la dernière version publiée ; documentation des pratiques de signature des artefacts et de gestion des clés ; preuve que les identifiants du pipeline sont de courte durée et à portée limitée, et non statiques et étendus.
- Sécurité des mécanismes de mise à jour logicielle
-
La sécurité des mécanismes de mise à jour est importante pour la TPRM parce que les éditeurs de logiciels qui livrent des produits dotés de mécanismes de mise à jour automatique ouvrent un canal persistant de déploiement de code dans l’environnement de l’entreprise.
la sécurité des mécanismes de mise à jour est importante en TPRM, car les éditeurs de logiciels qui livrent des produits dotés de mécanismes de mise à jour automatique ouvrent un canal permanent de déploiement de code dans l’environnement de l’entreprise.
- Sécurité des mécanismes de mise à jour logicielle : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : description de l’architecture de sécurité du mécanisme de mise à jour ; politique de gestion et de rotation des certificats et des clés ; processus de notification des compromissions de l’infrastructure de mise à jour.
- Périmètre défini par logiciel pour l’accès des fournisseurs
-
Le SDP pour l’accès des fournisseurs est important pour la TPRM parce que la confiance établie au niveau du réseau pour un fournisseur ne se restreint pas automatiquement lorsque la propriété, la posture de sécurité ou le personnel de ce fournisseur changent.
Le SDP pour l’accès des fournisseurs est important pour la TPRM parce que la confiance établie au niveau du réseau pour un fournisseur ne se restreint pas automatiquement lorsque la propriété, la posture de sécurité ou le personnel de ce fournisseur changent.
- Périmètre défini par logiciel pour l’accès des fournisseurs : les preuves
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : historique des changements de propriétaire depuis l’ouverture de l’accès ; clause contractuelle de notification des changements de propriétaire ; réévaluation de l’accès lors de tout changement de propriétaire.
- SSAE 18 et AT-C 205
-
La norme SSAE 18 est la norme d’attestation publiée par l’AICPA selon laquelle les missions SOC sont réalisées aux États-Unis. La section AT-C 205 de cette norme couvre les missions d’examen, ce qu’est un SOC 2. La norme régit la manière dont la mission est planifiée, réalisée et rapportée, ainsi que les personnes habilitées à la réaliser.
cela explique pourquoi un SOC 2 ne peut être émis que par un cabinet CPA agréé, aussi compétent que soit un cabinet de conseil en sécurité, et pourquoi le rapport porte le nom du cabinet, son agrément et ses obligations d’indépendance. Cela explique aussi pourquoi l’auditeur ne peut pas corriger ce qu’il trouve, car la norme exige son indépendance vis-à-vis des contrôles examinés.
- Clauses contractuelles types
-
Les clauses contractuelles types sont les clauses contractuelles approuvées par la Commission européenne pour le transfert de données personnelles vers un pays tiers. La version de 2021 est modulaire : le module un couvre les transferts de responsable du traitement à responsable du traitement, le module deux de responsable du traitement à sous-traitant, le module trois de sous-traitant à sous-traitant et le module quatre de sous-traitant à responsable du traitement. Les parties choisissent le module correspondant à leur relation réelle.
Le module doit correspondre à la manière dont les données circulent réellement. Un responsable du traitement qui exporte vers un sous-traitant et signe le module un dispose d’un contrat qui ne décrit pas le transfert, et le transfert ne repose sur aucun mécanisme valable. Les fournisseurs proposent fréquemment leur module par défaut sans tenir compte du rôle du client.
- Risque lié aux données structurées et non structurées
-
La dimension de risque liée aux données non structurées est importante pour la TPRM parce que les évaluations des fournisseurs centrées sur la sécurité des données structurées (chiffrement des bases de données, contrôles d’accès, journalisation d’audit) passent systématiquement à côté de la majeure partie de la surface de données, là où les informations sensibles des clients sont le plus susceptibles de se trouver et le moins susceptibles d’être gouvernées.
la dimension du risque lié aux données non structurées est importante en TPRM, car les évaluations de fournisseurs centrées sur la sécurité des données structurées (chiffrement des bases de données, contrôles d’accès, journalisation d’audit) passent systématiquement à côté de la majeure partie de la surface de données, là où les informations sensibles des clients ont le plus de chances de se trouver et le moins de chances d’être encadrées.
- Risque lié aux données structurées et non structurées : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : inventaire complet des données incluant les référentiels non structurés en plus des bases de données principales ; confirmation de la couverture de l’outil de découverte des données (référentiels non structurés inclus dans le périmètre de découverte et de classification) ; preuves de la gouvernance des plateformes collaboratives (contrôles d’accès, politiques de DLP et journalisation d’audit activée).
- Sous-traitants ultérieurs
-
Un sous-traitant ultérieur est un tiers engagé par un sous-traitant pour effectuer un traitement pour le compte du responsable du traitement. L’article 28 impose au sous-traitant d’obtenir l’autorisation préalable du responsable du traitement, soit spécifique à chaque sous-traitant ultérieur, soit générale avec information sur les changements et possibilité de s’y opposer, et de répercuter les mêmes obligations par contrat.
La liste des sous-traitants ultérieurs d’un fournisseur est l’endroit où votre empreinte de données réelle devient visible, et elle est généralement plus longue que prévu. Un produit SaaS peut faire intervenir un hébergeur, un outil de support, un service de messagerie, une plateforme d’analyse, un prestataire de paiement et un service de surveillance, chacun traitant une partie de vos données.
- Visibilité sur les sous-traitants ultérieurs
-
La visibilité sur les sous-traitants ultérieurs est importante parce que les obligations de l’entreprise en matière de protection des données, ainsi que son exposition aux risques de la chaîne d’approvisionnement, s’étendent à tous les sous-traitants ultérieurs du fournisseur, qu’ils soient déclarés ou non.
la visibilité sur les sous-traitants ultérieurs est importante parce que les obligations de l’entreprise en matière de protection des données, ainsi que son exposition au risque de la chaîne d’approvisionnement, s’étendent à tous les sous-traitants ultérieurs du fournisseur, qu’ils soient déclarés ou non.
- Visibilité sur les sous-traitants ultérieurs : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : engagement de notification préalable pour les nouveaux sous-traitants ultérieurs ; preuve de l’application d’un test fonctionnel aux sous-traitants ultérieurs ; il convient de demander à un fournisseur qui fournit une liste de sous-traitants ultérieurs dans son DPA de fournir également sa pile technologique de production. La liste du DPA correspond aux sous-traitants ultérieurs déclarés. La pile de production révèle l’environnement de traitement réel. L’écart entre les deux constitue le risque de visibilité sur les sous-traitants ultérieurs.
- Événements postérieurs
-
Les événements survenant après la fin de la période d’observation mais avant l’émission du rapport peuvent devoir être mentionnés dans le rapport s’ils affectent la présentation fidèle de la description du système ou la compréhension des contrôles par le lecteur. Une violation, une panne majeure, un changement de propriétaire ou une défaillance significative d’un contrôle durant cette période en sont les exemples habituels.
La période délimite les tests, pas l’obligation de divulgation. Une violation survenue dans les semaines séparant la fin de la période et l’émission du rapport correspond précisément à cette situation, et un rapport qui n’en dit rien n’est pas neutre. La direction est tenue d’en informer l’auditeur, et l’auditeur est tenu d’en tenir compte.
- Organisations de sous-services
-
Une organisation de sous-services est un fournisseur dont les contrôles conditionnent la capacité de votre propre service à satisfaire un critère. Votre hébergeur cloud. Votre prestataire de paiement. Le prestataire de détection gérée qui surveille vos journaux. Le critère est la dépendance, pas la dépense : un fournisseur entre dans cette catégorie si un critère ne peut être satisfait sans que ses contrôles fonctionnent.
Vous ne pouvez pas tester les contrôles d’une autre entreprise, et votre auditeur non plus : le rapport doit donc en dire quelque chose, et la manière dont il le fait façonne l’ensemble du document. Les organisations de sous-services nommées dans un rapport indiquent au lecteur où s’arrête l’assurance de l’entreprise auditée et où commence celle de quelqu’un d’autre.
- Concentration des fournisseurs de sous-services dans les rapports
-
Le rapport SOC 2 de votre fournisseur exclut son hébergeur. Le rapport de l’hébergeur exclut un centre de colocation. Le rapport du centre fait référence à un fournisseur d’électricité et de connectivité. La chaîne se poursuit au-delà du point où quiconque lit habituellement, et l’assurance s’amenuise à chaque niveau.
Le risque de concentration se situe au bas de la pile. Vingt de vos fournisseurs peuvent chacun exclure le même grand fournisseur cloud, dans la même région, et chaque rapport semble satisfaisant pris isolément. La dépendance n’apparaît que lorsque la chaîne est retracée et que les rapports sont lus ensemble.
- Frontières de confiance de l’IA dans la chaîne d’approvisionnement
-
Les frontières de confiance de l’IA définissent le périmètre de ce qu’un système d’IA doit et ne doit pas faire, révéler ou permettre, selon la personne qui le sollicite et le contexte.
Les frontières de confiance de l’IA sont importantes pour la TPRM parce que les produits d’IA des fournisseurs qui agrègent des informations opérationnelles sensibles dans des bases de connaissances interrogeables créent des capacités de reconnaissance accessibles à tout utilisateur capable de s’authentifier, y compris des utilisateurs aux identifiants compromis, des attaques d’ingénierie sociale et des menaces internes disposant d’identifiants exce
- Frontières de confiance de l’IA dans la chaîne d’approvisionnement : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : évaluation du contenu sensible de la base de connaissances ; contrôles d’accès contextuels au-delà de l’authentification ; il convient d’interroger un fournisseur qui confirme des contrôles d’authentification pour l’IA sur le périmètre de ses frontières de confiance. L’authentification confirme l’identité. Le périmètre de la frontière de confiance détermine si la demande de l’identité authentifiée relève du périmètre d’accès approprié aux informations sensibles.
- Détection des attaques de la chaîne d’approvisionnement
-
La détection des attaques de la chaîne d’approvisionnement est importante pour la TPRM parce que le fournisseur dont la surveillance de la sécurité en production est excellente mais dont le pipeline de compilation ne génère aucun signal pour le SOC présente une lacune de détection précisément pour le vecteur qu’utilisent les attaques de la chaîne d’approvisionnement.
la détection des attaques de la chaîne d’approvisionnement est importante en TPRM, car le fournisseur dont la surveillance de sécurité en production est excellente mais dont le pipeline de compilation ne génère aucun signal pour le SOC présente une lacune de détection précisément sur le vecteur qu’utilisent les attaques de la chaîne d’approvisionnement.
- Détection des attaques de la chaîne d’approvisionnement : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : périmètre de surveillance du pipeline de compilation et ingestion des journaux ; règles de détection propres à la chaîne d’approvisionnement dans le SIEM ; délai de détection attendu pour une compromission du pipeline de compilation.
- Attaques de la chaîne d’approvisionnement
-
Une attaque de la chaîne d’approvisionnement compromet un fournisseur de confiance, un composant logiciel ou un mécanisme de mise à jour afin d’atteindre en une seule fois tous les clients de ce fournisseur. Plutôt que d’attaquer mille organisations, l’attaquant compromet la seule chose que ces mille organisations ont en commun : un pipeline de compilation, une bibliothèque largement utilisée, l’outil d’accès à distance d’un prestataire de services gérés ou la clé de signature d’un fournisseur.
C’est la raison pour laquelle le risque lié aux tiers a cessé d’être une formalité d’achat. Les attaques qui ont touché le plus grand nombre d’organisations ces dernières années sont arrivées par des mises à jour logicielles de confiance et par des prestataires disposant d’un accès légitime, et non par le périmètre des victimes elles-mêmes. Vos contrôles fonctionnaient. La confiance que vous aviez accordée à un fournisseur était la vulnérabilité.
- Réponse aux incidents de la chaîne d’approvisionnement
-
La réponse aux incidents de la chaîne d’approvisionnement est importante pour la TPRM parce que le fournisseur dont le programme d’IR est mature pour les incidents de production mais qui ne dispose d’aucun guide de réponse pour la chaîne d’approvisionnement sera nettement moins efficace pour répondre à une compromission de la chaîne d’approvisionnement, et l’entreprise dont le fournisseur a été compromis recevra une notification plus tardive, des inf
La réponse aux incidents de la chaîne d’approvisionnement est importante pour la TPRM parce que le fournisseur dont le programme d’IR est mature pour les incidents de production mais qui ne dispose d’aucun guide de réponse pour la chaîne d’approvisionnement sera nettement moins efficace pour répondre à une compromission de la chaîne d’approvisionnement, et l’entreprise dont le fournisseur a été compromis recevra une notification plus tardive, des inf
- Réponse aux incidents de la chaîne d’approvisionnement : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : existence d’un guide de réponse aux incidents de la chaîne d’approvisionnement ; inventaire des déploiements clients et processus de notification ; comptes rendus d’exercices sur table consacrés à la chaîne d’approvisionnement.
- Risque lié à la chaîne d’approvisionnement dans les fusions et acquisitions
-
Le risque lié à la chaîne d’approvisionnement dans les opérations M&A est important parce que la dette technique liée aux dépendances logicielles, accumulée pendant des années de priorité donnée à la vitesse de développement des fonctionnalités plutôt qu’à la sécurité, n’est pas visible dans une vérification préalable technologique standard mais est directement héritée par l’entreprise acquéreuse.
le risque de chaîne d’approvisionnement dans les opérations de M&A est important parce que la dette technique liée aux dépendances logicielles, accumulée pendant des années à privilégier la vitesse de livraison des fonctionnalités au détriment de la sécurité, n’apparaît pas dans la diligence raisonnable technologique habituelle, mais est directement héritée par l’entreprise acquéreuse.
- Risque de la chaîne d’approvisionnement dans les fusions et acquisitions : les preuves
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : SBOM actuelle issue du code de production ; identification des dépendances en EOL avec évaluation de la remédiation ; inventaire des vulnérabilités critiques avec état de correction.
- Quantification des risques de la chaîne d’approvisionnement
-
La quantification des risques de la chaîne d’approvisionnement est importante parce qu’elle transforme la documentation des risques en gestion des risques. Le CISO et le conseil d’administration ont besoin d’estimations de l’exposition financière pour prendre des décisions d’investissement, hiérarchiser des initiatives de sécurité concurrentes et communiquer la posture de risque aux parties prenantes qui décident de l’allocation des ressources.
La quantification des risques de la chaîne d’approvisionnement est importante parce qu’elle transforme la documentation des risques en gestion des risques.
- Quantification des risques de la chaîne d’approvisionnement : les preuves
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : méthode de quantification des risques de la chaîne d’approvisionnement ; estimations de l’exposition financière pour les scénarios critiques de la chaîne d’approvisionnement ; priorisation des investissements fondée sur les risques quantifiés.
- La sécurité de la chaîne d’approvisionnement dans les pipelines CI/CD
-
La sécurité de la chaîne d’approvisionnement des pipelines CI/CD est importante pour la TPRM parce qu’un fournisseur qui confirme analyser les dépendances de ses applications sans confirmer la sécurité des composants de son pipeline a traité une surface d’attaque de la chaîne d’approvisionnement tout en en laissant une autre sans réponse.
La sécurité de la chaîne d’approvisionnement des pipelines CI/CD est importante pour la TPRM parce qu’un fournisseur qui confirme analyser les dépendances de ses applications sans confirmer la sécurité des composants de son pipeline a traité une surface d’attaque de la chaîne d’approvisionnement tout en en laissant une autre sans réponse.
- La sécurité de la chaîne d’approvisionnement dans les pipelines CI/CD : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : inventaire des composants du pipeline avec leur statut d’épinglage SHA ; mise en œuvre de la surveillance des mainteneurs des actions du pipeline ; processus de vérification de l’installation des outils de compilation.
- Sécurité de la chaîne d’approvisionnement dans les secteurs réglementés
-
La sécurité de la chaîne d’approvisionnement dans les secteurs réglementés est importante pour la TPRM parce que les entreprises des secteurs réglementés sont soumises à des exigences réglementaires précises et documentées que leurs fournisseurs doivent également respecter, et que les évaluations générales de la sécurité de la chaîne d’approvisionnement peuvent ne pas traiter sous la forme requise.
La sécurité de la chaîne d’approvisionnement dans les secteurs réglementés est importante pour la TPRM parce que les entreprises des secteurs réglementés sont soumises à des exigences réglementaires précises et documentées que leurs fournisseurs doivent également respecter, et que les évaluations générales de la sécurité de la chaîne d’approvisionnement peuvent ne pas traiter sous la forme requise.
- La sécurité de la chaîne d’approvisionnement dans les secteurs réglementés : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : SBOM et VEX au format réglementaire pour les fournisseurs de dispositifs médicaux ; conformité aux dispositions DORA sur la chaîne d’approvisionnement ICT pour les services financiers ; exemples de dossiers réglementaires comprenant la documentation de la chaîne d’approvisionnement.
- Évaluation de la maturité de la sécurité de la chaîne d’approvisionnement
-
L’évaluation de la maturité de la sécurité de la chaîne d’approvisionnement est importante pour la TPRM parce qu’elle fournit une vision par domaine des investissements réalisés en sécurité de la chaîne d’approvisionnement et des lacunes existantes, ce qui oriente directement à la fois la hiérarchisation des améliorations du programme interne et les questions que les équipes de TPRM doivent poser aux fournisseurs sur les dom
L’évaluation de la maturité de la sécurité de la chaîne d’approvisionnement est importante pour la TPRM parce qu’elle fournit une vision par domaine des investissements réalisés en sécurité de la chaîne d’approvisionnement et des lacunes existantes, ce qui oriente directement à la fois la hiérarchisation des améliorations du programme interne et les questions que les équipes de TPRM doivent poser aux fournisseurs sur les dom
- Évaluation de la maturité de la sécurité de la chaîne d’approvisionnement : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : niveaux de maturité pour six domaines de sécurité de la chaîne d’approvisionnement ; reconnaissance d’un niveau 0 pour les domaines absents plutôt qu’une mention « sans objet » ; feuille de route d’investissement pour les domaines les moins matures.
T
- Exercices sur table
-
Un exercice sur table fait parcourir aux personnes qui répondraient à un incident un scénario réaliste, en salle, sans toucher à aucun système, afin de découvrir où le plan échoue. Quatre-vingt-dix minutes, les véritables intervenants, aucune préparation, et un journal des décisions tenu tout au long. Le résultat n’est pas une note : ce sont les modifications du runbook que l’exercice a mises en évidence.
les plans d’incident sont rédigés par des personnes qui imaginent un incident, et ils se comportent différemment sous la pression d’un incident réel. L’exercice sur table est le seul moyen de découvrir cet écart avant qu’il ne coûte quelque chose. La question se pose aussi parce que les référentiels et les assureurs demandent si le plan est testé, et un plan testé une seule fois, il y a vingt mois, avant l’arrivée du responsable actuel, n’est testé en aucun sens qui compte.
- Périodes de test et écarts entre les rapports
-
Un rapport de type II couvre une période définie. Le rapport suivant couvre la période suivante. Mais les rapports sont publiés des semaines ou des mois après la fin de leur période, et les périodes ne se suivent pas toujours. Un fournisseur doté d’un rapport annuel peut laisser un client chaque année avec plusieurs mois qu’aucun rapport ne couvre.
Un client qui enregistre la date du rapport plutôt que la période couverte ne sait pas quand son assurance a expiré. Les lettres de transition existent précisément pour remédier à cela, et c’est en connaissant l’écart que vous savez quand en demander une.
- La méthode d’exclusion
-
Selon la méthode d’exclusion, les contrôles d’une organisation de sous-services sont exclus de l’audit. Le rapport décrit ce que l’entreprise auditée attend de ce prestataire, indique que ces contrôles n’ont pas été testés et les énumère comme contrôles complémentaires de l’organisation de sous-services. C’est la méthode qu’utilisent presque tous les rapports SOC 2, car l’alternative exige la participation du prestataire.
c’est pourquoi le SOC 2 d’un fournisseur peut contenir des contrôles attribués à AWS ou à Azure que personne n’a testés au cours de la mission. L’entreprise auditée s’appuie sur eux, déclare s’y appuyer, et l’opinion de l’auditeur ne couvre que ce que l’entreprise exploite elle-même.
- Les critères communs, de CC1 à CC9
-
La catégorie Sécurité est organisée en neuf groupes appelés critères communs. CC1 couvre l’environnement de contrôle, CC2 la communication, CC3 l’évaluation des risques, CC4 le suivi, CC5 les activités de contrôle, CC6 l’accès logique et physique, CC7 l’exploitation des systèmes et la réponse aux incidents, CC8 la gestion des changements et CC9 l’atténuation des risques, y compris la gestion des fournisseurs. Chaque rapport SOC 2 traite des neuf.
Les groupes ne sont pas équivalents en effort ni en risque. CC6 couvre à lui seul l’attribution des accès, l’authentification, l’autorisation, le retrait des accès, l’accès physique et l’élimination des données, touche tous les systèmes et produit plus d’exceptions que tout autre groupe. CC1 et CC2 relèvent essentiellement de la gouvernance et de la documentation. Savoir lequel est lequel change la manière dont vous lisez un rapport et dont vous planifiez un audit.
- Le responsable du traitement
-
Le responsable du traitement est celui qui détermine les finalités et les moyens du traitement des données personnelles : pourquoi elles sont traitées et, dans les grandes lignes, comment. La qualité découle de la décision, et non du contrat. Une entreprise qui décide quelles données collecter et ce qu’elle en fait est responsable de ce traitement, quelle que soit la qualification retenue dans un accord.
Le responsable du traitement assume les obligations principales : base légale, transparence, droits des personnes concernées, notification des violations, responsabilité. Un fournisseur qui commence à utiliser les données de vos clients pour améliorer ses propres produits a pris une décision sur la finalité et est devenu responsable du traitement pour cet usage, quoi que dise le DPA sur sa qualité de sous-traitant.
- Les cinq catégories des services de confiance
-
Sécurité, Disponibilité, Intégrité du traitement, Confidentialité et Vie privée sont les cinq catégories qu’un rapport SOC 2 peut couvrir. Seule la catégorie Sécurité est obligatoire. Les quatre autres sont facultatives, choisies par l’entreprise auditée, et la plupart des rapports n’incluent que la Sécurité, ou la Sécurité et la Disponibilité.
Lorsque quelqu’un dit avoir un SOC 2, il s’agit presque toujours de la catégorie Sécurité. Si vous avez besoin d’une assurance sur la disponibilité, le traitement des données ou les informations personnelles, il se peut que le rapport n’en traite pas du tout, et la page de garde l’indique en une seule ligne que la plupart des lecteurs ne vérifient pas.
- L’avenir du DevSecOps
-
L’avenir du DevSecOps est important pour la TPRM parce que les fournisseurs des logiciels dont les entreprises dépendront dans cinq ans construisent ces logiciels dès aujourd’hui, avec les programmes DevSecOps actuels, auxquels s’ajoutent les investissements d’avenir qu’ils consacrent aux cinq trajectoires ci-dessus.
L’avenir du DevSecOps est important pour la TPRM parce que les fournisseurs des logiciels dont les entreprises dépendront dans cinq ans construisent ces logiciels dès aujourd’hui, avec les programmes DevSecOps actuels, auxquels s’ajoutent les investissements d’avenir qu’ils consacrent aux cinq trajectoires ci-dessus.
- L’avenir du DevSecOps : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : feuille de route du programme DevSecOps à trois ans ; approche et calendrier pour la sécurité du code généré par l’IA ; objectif et calendrier d’adoption de SLSA.
- L’avenir de la sécurité réseau : cinq tendances qui redessinent le périmètre
-
Périmètre traditionnel : en voie de disparition. Identité : le nouveau périmètre.
L’avenir de la sécurité réseau est important pour la TPRM parce que les fournisseurs qui se préparent au futur paysage de la sécurité réseau (en adoptant le SASE, en développant une détection fondée sur l’IA, en planifiant la transition post-quantique) sont des fournisseurs dont la posture de sécurité sera mieux adaptée au paysage des menaces de 2028 que celle des fournisseurs qui maintiennent l’ar
- L’avenir de la sécurité de la chaîne d’approvisionnement logicielle
-
L’avenir de la sécurité de la chaîne d’approvisionnement est important pour la TPRM parce que les investissements réalisés aujourd’hui dans le programme doivent tenir compte des capacités qui seront requises dans trois à cinq ans, et pas seulement de la situation actuelle.
L’avenir de la sécurité de la chaîne d’approvisionnement est important pour la TPRM parce que les investissements réalisés aujourd’hui dans le programme doivent tenir compte des capacités qui seront requises dans trois à cinq ans, et pas seulement de la situation actuelle.
- L’avenir de la sécurité de la chaîne d’approvisionnement logicielle : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : politique de gouvernance de la génération de code par l’IA ; exigences de profondeur de revue pour le code généré par l’IA ; connaissance et planification de la transition vers la cryptographie post-quantique.
- L’avenir de la TPRM : de l’assurance au renseignement
-
Le passage de l’assurance au renseignement est important parce qu’il répond à la limite fondamentale de l’évaluation ponctuelle : son incapacité à prédire ce qui va se passer ensuite.
Le passage de l’assurance au renseignement est important parce qu’il répond à la limite fondamentale de l’évaluation ponctuelle : son incapacité à prédire ce qui va se passer ensuite.
- L’avenir de la TPRM : de l’assurance au renseignement : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : capacité ou feuille de route de notation prédictive des risques ; analyse des tendances historiques à partir des données du programme ; intégration de signaux externes pour la prévision des tendances.
- La méthode inclusive
-
La méthode inclusive est l’alternative à la méthode d’exclusion. Les contrôles pertinents de l’organisation de sous-services sont décrits et testés dans le rapport de l’entreprise auditée elle-même, de sorte que le lecteur n’a rien à présumer de la couche sous-jacente. L’opinion couvre réellement l’ensemble de la pile.
Elle offre une assurance plus solide que la méthode d’exclusion, et les acheteurs demandent parfois pourquoi un fournisseur ne l’a pas utilisée. La réponse est pratique. L’organisation de sous-services doit accepter d’être incluse, d’être décrite dans la description du système et de signer sa propre assertion de la direction pour la mission.
- L’évaluation des intérêts légitimes
-
Une analyse de l’intérêt légitime (LIA) est le raisonnement documenté qui justifie de se fonder sur l’intérêt légitime comme base légale. Elle comporte trois volets. Le test de finalité : quel est l’intérêt, et est-il légitime. Le test de nécessité : le traitement est-il nécessaire à cet intérêt, ou pourrait-il être atteint autrement. Le test de mise en balance : l’intérêt l’emporte-t-il sur les droits et les attentes raisonnables de la personne.
la plupart des traitements B2B, l’essentiel de la prévention de la fraude, l’essentiel de la surveillance de sécurité et une grande partie des analyses reposent sur l’intérêt légitime. Les autorités de régulation demandent à voir l’analyse, et non l’affirmation. Un responsable du traitement qui invoque l’intérêt légitime mais ne peut pas présenter son raisonnement n’a pas, aux yeux de l’autorité, réalisé l’analyse.
- L’assertion de la direction
-
Avant l’opinion de l’auditeur figure l’assertion de la direction : une déclaration signée par l’entreprise auditée attestant que la description du système est exacte et que les contrôles ont été conçus de manière appropriée et, pour un Type II, ont fonctionné efficacement. L’opinion de l’auditeur porte sur cette assertion.
Tout le rapport repose sur le fait que la direction a décrit son système avec sincérité. Si la description minimise le périmètre, omet un composant ou présente une frontière de manière inexacte, chaque résultat de test sans anomalie porte sur un objet plus restreint que ce que le lecteur supposait, et l’opinion de l’auditeur, bien qu’exacte, porte sur cet objet plus restreint.
- Le cadre de gestion des risques liés à l’IA du NIST
-
Le cadre de gestion des risques liés à l’IA du NIST est une structure volontaire de gestion des risques des systèmes d’IA articulée autour de quatre fonctions. Gouverner établit la responsabilité et la culture. Cartographier identifie le contexte, les personnes touchées et les risques. Mesurer évalue ces risques, y compris les performances pour les différents groupes touchés par le système. Gérer agit sur ce qui a été mesuré, par la supervision et le suivi. Il vous indique comment travailler, là où une réglementation vous dit ce que vous devez faire.
C’est la référence dont s’inspirent la plupart des processus d’évaluation, qu’ils la citent ou non, et c’est le cadre qu’un acheteur ou un régulateur reconnaîtra lorsque vous décrirez la manière dont vous évaluez les risques liés à l’IA. Il s’associe naturellement au règlement européen sur l’IA : le règlement classe et impose des obligations, le RMF vous donne la méthode pour les respecter.
- La période d’observation
-
La période d’observation est l’intervalle sur lequel un audit de type II a testé le fonctionnement des contrôles. Elle est indiquée dans l’opinion et couvre généralement trois, six ou douze mois. Une période de trois mois comme une période de douze mois produisent un rapport valable.
Une période de trois mois couvre au plus une revue trimestrielle des accès, voire aucune. Une période de douze mois en couvre quatre, plus une clôture d’exercice, une période de fêtes, au moins une réorganisation et plusieurs mises en production. La période la plus longue constitue une affirmation bien plus forte sur la tenue des contrôles sous une pression normale.
- Le sous-traitant
-
Un sous-traitant traite des données personnelles pour le compte d’un responsable du traitement, en agissant uniquement sur instruction documentée de celui-ci. Il ne décide pas des finalités du traitement. Ses obligations sont plus restreintes que celles d’un responsable du traitement, mais bien réelles : sécurité, confidentialité, gestion des sous-traitants ultérieurs, aide au traitement des demandes d’exercice des droits, et suppression ou restitution des données à la fin.
Dès qu’un sous-traitant décide d’une finalité qui lui est propre, il cesse d’être sous-traitant pour cette activité et assume directement les obligations d’un responsable du traitement. L’exemple le plus courant est l’analytique : un fournisseur SaaS qui fait passer les données de ses clients dans ses propres modèles pour améliorer son produit a pris une décision sur la finalité que le client n’a pas ordonnée.
- Le droit à l’effacement
-
Le droit à l’effacement, souvent appelé droit à l’oubli, permet à une personne d’exiger la suppression de ses données personnelles dans des cas précis : les données ne sont plus nécessaires, le consentement est retiré, la personne s’oppose au traitement et il n’existe pas de motif impérieux prévalant, le traitement était illicite, ou une obligation légale impose la suppression. C’est l’un des droits les plus demandés et l’un des moins correctement appliqués.
Il n’est pas absolu. Il ne s’applique pas lorsque le traitement est nécessaire au respect d’une obligation légale, à la constatation ou à la défense de droits en justice, à la liberté d’expression, à la santé publique ou à l’archivage dans l’intérêt public. Un responsable du traitement qui supprime tout sur demande peut avoir détruit des documents que la loi l’obligeait à conserver.
- Les leçons de SolarWinds toujours pas retenues
-
Les leçons non retenues de SolarWinds sont importantes en TPRM, car elles représentent un écart systématique entre les capacités actuelles des attaques de la chaîne d’approvisionnement et les questions d’évaluation que posent la plupart des programmes de TPRM.
Les leçons non retenues de SolarWinds sont importantes pour la TPRM parce qu’elles représentent un écart systématique entre les capacités actuelles des attaques de la chaîne d’approvisionnement et les questions d’évaluation que posent la plupart des programmes de TPRM.
- Les leçons de SolarWinds toujours pas retenues : les preuves
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : contrôles d’isolation et de surveillance du pipeline de compilation ; protection des clés de signature (HSM ou équivalent) ; sécurité du mécanisme de mise à jour et gouvernance par l’entreprise.
- La description du système
-
La description du système est la présentation, par l’entreprise auditée elle-même, du système inclus dans le périmètre : ce que fait le service, l’infrastructure et les logiciels concernés, les personnes et les processus, les données traitées et la frontière qui entoure l’ensemble. L’auditeur examine si elle est présentée fidèlement. C’est l’entreprise qui la rédige.
la description détermine ce qui a été audité. Une description qui trace une frontière étroite, autour d’un noyau bien maîtrisé et à l’écart des services plus récents et moins ordonnés, produit un audit plus facile et un rapport qui couvre moins qu’un lecteur ne le suppose. Rien de tout cela n’est irrégulier, mais un lecteur qui ne compare pas la description au service qu’il utilise réellement n’a aucune idée de ce que couvre l’opinion.
- Actions tierces et flux de travail réutilisables
-
La sécurité des flux de travail partagés et des actions réutilisables est importante pour la TPRM parce qu’un seul flux de travail partagé compromis peut constituer le point d’entrée dans la chaîne d’approvisionnement de tous les services du portefeuille d’un fournisseur.
La sécurité des flux de travail partagés et des actions réutilisables est importante pour la TPRM parce qu’un seul flux de travail partagé compromis peut constituer le point d’entrée dans la chaîne d’approvisionnement de tous les services du portefeuille d’un fournisseur.
- Actions tierces et flux de travail réutilisables : les preuves
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : contrôles d’accès au dépôt des flux de travail partagés ; exigences de revue pour les modifications des flux de travail partagés ; épinglage par SHA dans les flux de travail partagés.
- Intégrations d’IA de tiers
-
Les risques liés aux intégrations d’IA tierces sont les risques de sécurité, de conformité, de gouvernance et opérationnels créés lorsque des plateformes SaaS d’entreprise intègrent des capacités d’IA (fonctionnalités reposant sur des modèles d’apprentissage automatique, de grands modèles de langage ou une automatisation pilotée par l’IA) dans leurs produits.
Les intégrations d’IA tierces sont importantes pour la TPRM parce que l’IA la plus lourde de conséquences dans la pile technologique d’une entreprise est souvent intégrée à des plateformes SaaS standard plutôt que déployée sous forme de produits d’IA autonomes.
- Intégrations d’IA tierces : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : inventaire des fonctionnalités d’IA avec l’étendue de leur accès aux données ; documentation des données d’entraînement pour les fonctionnalités d’IA lourdes de conséquences ; évaluation de l’équité des fonctionnalités d’IA ayant une incidence sur des personnes.
- Recours aux rapports d’audit de tiers
-
Les rapports d’audit de tiers (SOC 2, ISO 27001, attestations PCI-DSS, rapports de tests d’intrusion de cabinets réputés) fournissent des preuves d’assurance précieuses. Ils représentent le jugement professionnel de spécialistes indépendants qui ont examiné les contrôles du fournisseur au regard de critères définis.
Le recours aux audits tiers est important pour la TPRM parce que les rapports d’audit sont les éléments de preuve les plus couramment acceptés et les plus fortement pondérés dans les évaluations des fournisseurs, et que leur valeur dépend de facteurs propres à chaque rapport et à chaque relation client, et non de la réputation du cabinet ou de l’opinion sans réserve du rapport.
- Recours aux audits tiers : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : confirmation du périmètre pour les systèmes concernant le client ; description de la méthodologie pour les catégories de contrôles concernant le client ; évaluation complémentaire pour toute exclusion du périmètre touchant les données du client.
- Notification des incidents par les tiers
-
Lorsqu’un fournisseur subit une violation, vos propres obligations de notification envers les régulateurs et les clients peuvent courir à partir du moment où vous en avez connaissance, ce qui peut être le moment où vous lisez la nouvelle plutôt que celui où le fournisseur confirme quoi que ce soit. Le délai contractuel du fournisseur pour vous informer et votre délai réglementaire pour informer les autres sont des délais différents, et le second n’attend pas le premier.
une entreprise apprend la compromission d’un fournisseur par une page web, passe un week-end à déterminer s’il s’agit d’une violation et si son délai a commencé à courir, et manque d’un jour une échéance contractuelle envers un client. Ces trois questions avaient des réponses établies qui auraient pu être rédigées des mois plus tôt, et le week-end a été consacré au droit au lieu de l’investigation technique.
- Gestion des risques liés aux tiers
-
La gestion des risques liés aux tiers est la discipline qui consiste à savoir quelles organisations externes touchent à vos données, à vos systèmes ou à vos clients, à les évaluer en proportion de cette exposition, à contractualiser ce qui compte, à surveiller les événements qui modifient leur risque et à récupérer vos données à la fin de la relation. Cinq étapes. La plupart des programmes sont construits autour de la deuxième et négligent les quatre autres.
Chaque référentiel au regard duquel vous êtes évalué pose la question, chaque acheteur grand compte la pose, et un nombre croissant de régulateurs demandent à voir le registre. Le sujet revient aussi parce que la violation qui vous atteint le plus souvent n’est pas la vôtre. C’est celle d’un fournisseur, et le questionnaire qu’il a rempli lors de son intégration ne disait rien du sous-traitant ultérieur qui a réellement été compromis.
- Risque lié aux SDK tiers
-
le risque lié aux SDK est important en TPRM, car les SDK intégrés aux applications mobiles et web des entreprises créent des risques de collecte et de transmission de données dont l’entreprise n’a pas forcément pleinement conscience, et qui évoluent au fil du temps à mesure que les fournisseurs de SDK mettent à jour leurs produits.
le risque lié aux SDK est important en TPRM, car les SDK intégrés aux applications mobiles et web des entreprises créent des risques de collecte et de transmission de données dont l’entreprise n’a pas forcément pleinement conscience, et qui évoluent au fil du temps à mesure que les fournisseurs de SDK mettent à jour leurs produits.
- Risque lié aux SDK tiers : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : inventaire des SDK avec documentation de leur comportement en matière de collecte de données ; processus d’examen des mises à jour des SDK pour les changements ayant une incidence sur la vie privée ; résultats d’analyse du trafic réseau pour les SDK à haut risque.
- Risque lié aux tiers et risque lié aux quatrièmes parties
-
Le risque lié aux quatrièmes parties est le risque de sécurité créé par les fournisseurs de vos fournisseurs : les sous-traitants ultérieurs, les fournisseurs de sous-services et les acteurs de la chaîne d’approvisionnement auxquels vos tiers font appel pour vous fournir leurs services.
Le risque lié aux quatrièmes parties est important parce que les violations de données ne respectent pas les frontières organisationnelles de la chaîne de dépendances.
- Risque lié aux tiers et risque lié aux quatrièmes parties : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : inventaire complet des sous-traitants ultérieurs avec leurs fonctions et les catégories de données concernées ; certifications de sécurité des sous-traitants ultérieurs (SOC 2 ou équivalent) ; documentation des délais de la chaîne de notification des violations.
- Angles morts de la détection des menaces
-
Les angles morts de la détection des menaces sont les lacunes dans la capacité d’un programme de surveillance de la sécurité à détecter une activité d’attaque : les techniques d’attaque, les comportements des attaquants et les schémas d’activité malveillante que la logique de détection actuelle du programme de surveillance ne repère pas comme anormaux ou malveillants.
les angles morts de la détection des menaces sont importants en TPRM, car l’évaluation des capacités de détection d’un fournisseur confirme généralement l’existence et la configuration du programme de détection plutôt que de tester son efficacité face à des techniques d’attaque actuelles et réalistes.
- Angles morts de la détection des menaces : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : méthodologie des exercices red team ou purple team, y compris si des techniques LotL ont été incluses ; taux de détection des techniques LotL lors du dernier exercice ; cartographie ou pourcentage de couverture ATT&CK.
- Chasse aux menaces chez les fournisseurs
-
La chasse aux menaces est la recherche proactive, fondée sur des hypothèses, d’activités d’attaquants dans un environnement : il s’agit de rechercher des indicateurs de compromission que la détection automatisée n’a pas signalés, à partir de renseignements sur les menaces concernant des techniques d’attaque précises, des comportements connus d’attaquants ou des schémas d’anomalies compatibles avec une activité malveillante.
La chasse aux menaces dans les environnements des fournisseurs est importante pour la TPRM parce que les attaquants sophistiqués de la chaîne d’approvisionnement ciblent précisément les environnements les plus susceptibles d’être hors du périmètre des chasses aux menaces standard : le pipeline CI/CD, l’environnement de développement, le système d’accès des prestataires et les services gérés.
- Chasse aux menaces chez les fournisseurs : les preuves
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : documentation du périmètre de la dernière chasse aux menaces ; confirmation de l’inclusion de la CI/CD ou justification de son exclusion ; un fournisseur qui affirme pratiquer une chasse proactive aux menaces doit être interrogé sur la question de savoir si le périmètre de la chasse couvrait les environnements précis que le renseignement déclencheur avait identifiés comme à haut risque. L’activité de chasse prouve que le programme fonctionne. L’alignement du périmètre prouve qu’il est efficace.
- Lacunes d’intégration du renseignement sur les menaces
-
Les lacunes d’intégration du renseignement sur les menaces sont les retards, les limites de couverture et les défaillances de processus qui empêchent le renseignement sur les menaces d’être rendu opérationnel sous forme de détection active dans les délais qu’exige le paysage des menaces.
Les lacunes d’intégration du renseignement sur les menaces sont importantes pour la TPRM parce que l’abonnement d’un fournisseur à un service de renseignement sur les menaces et ses investissements dans une plateforme ne se traduisent par une meilleure détection que si le renseignement parvient au SIEM à temps pour détecter la menace qu’il décrit.
- Lacunes d’intégration du renseignement sur les menaces : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : cadence d’intégration par catégorie d’IOC ; indicateur de latence d’intégration (délai entre la publication et l’activation de la détection) ; il convient de poser à un fournisseur qui confirme l’intégration TI-SIEM la question du scénario de 11 h. L’existence de l’intégration décrit la connexion. La réponse à la question du scénario décrit quand la connexion apporte de la valeur.
- Renseignement sur les menaces pour les attaques de la chaîne d’approvisionnement
-
L’opérationnalisation du renseignement sur les menaces est importante en TPRM, car le renseignement sur les menaces visant la chaîne d’approvisionnement fournit le signal de risque prospectif que les évaluations historiques ne peuvent pas fournir : il décrit ce que font les attaquants aujourd’hui, quels secteurs ils ciblent et quels vecteurs d’attaque ils utilisent.
L’opérationnalisation du renseignement sur les menaces est importante pour la TPRM parce que le renseignement sur les menaces visant la chaîne d’approvisionnement fournit le signal de risque prospectif que les évaluations historiques ne peuvent pas fournir : il décrit ce que font les attaquants aujourd’hui, quels secteurs ils ciblent et quels vecteurs d’attaque ils utilisent.
- Renseignement sur les menaces pour les attaques de la chaîne d’approvisionnement : les preuves
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : connaissance par le fournisseur de l’avis de menace décrit ; évaluation de son exposition aux vecteurs d’attaque décrits ; mesures de remédiation ou d’atténuation prises en réponse.
- La modélisation des menaces dans le SDLC
-
La modélisation des menaces est importante pour la TPRM parce que c’est la seule activité de sécurité capable de détecter de manière fiable les vulnérabilités de conception avant la mise en œuvre.
La modélisation des menaces est importante pour la TPRM parce que c’est la seule activité de sécurité capable de détecter de manière fiable les vulnérabilités de conception avant la mise en œuvre.
- La modélisation des menaces dans le SDLC : les preuves
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : exemple récent de modélisation des menaces avec la fonctionnalité qui l’a déclenchée ; suivi des mesures d’atténuation de la modélisation des menaces jusqu’à leur mise en œuvre ; méthode et outils de modélisation des menaces utilisés.
- Fréquence de réévaluation par niveau
-
La fréquence de réévaluation par niveau est importante parce que la capacité de la TPRM est limitée. Chaque cycle d’évaluation consacré à un fournisseur à faible risque qui n’a pas changé de manière significative est un cycle qui n’est pas disponible pour un fournisseur à haut risque dont le profil de risque a évolué depuis sa dernière évaluation.
La fréquence de réévaluation par niveau est importante parce que la capacité de la TPRM est limitée.
- Fréquence de réévaluation par niveau : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : déclaration des changements significatifs depuis la dernière évaluation ; engagement de notification proactive des changements entre deux évaluations ; rapport de confiance ou journal des modifications de sécurité pour la période.
- Inspection TLS et trafic chiffré
-
La sécurité de l’inspection TLS est importante pour la TPRM parce que les fournisseurs qui déploient l’inspection TLS sans protection adéquate des clés privées ni application des correctifs sur les équipements ont créé un risque cryptographique qui inverse la finalité de sécurité de l’inspection TLS.
La sécurité de l’inspection TLS est importante pour la TPRM parce que les fournisseurs qui déploient l’inspection TLS sans protection adéquate des clés privées ni application des correctifs sur les équipements ont créé un risque cryptographique qui inverse la finalité de sécurité de l’inspection TLS.
- Inspection TLS et trafic chiffré : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : mise en œuvre d’un HSM pour la clé privée de l’CA ; calendrier d’application des correctifs des équipements d’inspection et date du dernier correctif ; limitation du périmètre de confiance de l’inspection TLS.
- Risques liés à la persistance des jetons
-
Le risque de persistance des jetons est l’exposition de sécurité créée par les jetons d’accès OAuth, les jetons API et les autres identifiants au porteur qui restent valides au-delà de la durée de vie opérationnelle de l’application, de l’intégration ou du cas d’usage qui les a demandés.
le risque de persistance des jetons est important en TPRM, car les plateformes qui conservent des jetons OAuth pour les intégrations de fournisseurs accumulent des identifiants qui survivent aux intégrations qu’ils servent.
- Risques liés à la persistance des jetons : les preuves
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : inventaire des jetons OAuth avec dates de dernière utilisation et applications associées ; documentation du processus de révocation des jetons, y compris le déclenchement lors du retrait d’une application ; politique d’expiration des jetons (durées de validité maximales des jetons émis).
- Confusion entre tokenisation et masquage
-
La tokenisation et le masquage des données sont deux techniques qui remplacent des valeurs de données sensibles par des substituts non sensibles dans les systèmes où la valeur d’origine n’est pas nécessaire à la fonction principale.
La confirmation de la tokenisation et du masquage est fréquemment citée comme preuve de la protection des données sensibles dans les évaluations des fournisseurs des secteurs du paiement, de la santé et des services financiers.
- Confusion entre tokenisation et masquage : les preuves
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : liste des accès à la détokenisation avec historique des revues (qui y a accès, date de la dernière revue, justification documentée) ; confirmation du journal d’audit de la détokenisation (journalisation en place, processus de revue défini) ; politique de cohérence du masquage (contextes recevant des valeurs masquées ou non masquées documentés).
- La TPRM comme levier pour l’activité
-
Présenter la gestion comme un levier pour l’activité est important parce que cela détermine la pérennité du programme de TPRM. Les programmes qui créent des frictions pour l’activité sans valeur correspondante subissent une pression croissante pour être contournés, privés de ressources ou remplacés par des solutions de conformité moins contraignantes.
le positionnement comme levier pour l’activité est important parce qu’il détermine la pérennité du programme de TPRM.
- La TPRM comme levier pour l’activité : les preuves
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : rapport SOC 2 et certifications pertinentes prêts à être fournis ; contact sécurité désigné pour faciliter l’évaluation ; un fournisseur qui souhaite être intégré rapidement doit être invité à présenter son dossier de préqualification. Les fournisseurs qui ont investi pour être faciles à évaluer aident l’entreprise à mener un processus de TPRM plus rapide et de meilleure qualité. Cet investissement est en soi un signal positif.
- Reporting TPRM au conseil d’administration et à la direction
-
Le reporting au conseil d’administration est important parce que c’est le mécanisme par lequel s’exerce la gouvernance des risques des relations avec les tiers au niveau du conseil. Un conseil qui ne reçoit pas les informations nécessaires pour poser des questions éclairées sur le risque lié aux tiers est un conseil qui ne peut pas assurer une supervision efficace des risques.
Le reporting au conseil d’administration est important parce que c’est le mécanisme par lequel s’exerce la gouvernance des risques des relations avec les tiers au niveau du conseil d’administration.
- Rapports de TPRM au conseil d’administration et à la direction : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : rapports au comité des risques du conseil d’administration sur la TPRM ; identification des risques significatifs au niveau du conseil d’administration ; il convient de demander à un fournisseur qui confirme une gouvernance de la TPRM mature si cette gouvernance remonte jusqu’au conseil d’administration. La maturité opérationnelle du programme n’équivaut pas à une supervision des risques par le conseil d’administration.
- TPRM dans les fusions et acquisitions
-
La TPRM dans les opérations M&A est importante parce que le risque d’hériter de relations fournisseurs non divulguées, d’incidents de sécurité en cours et de contrats fournisseurs restrictifs est réel, quantifiable et évitable grâce à une vérification préalable avant la clôture.
La TPRM dans les opérations M&A est importante parce que le risque d’hériter de relations fournisseurs non divulguées, d’incidents de sécurité en cours et de contrats fournisseurs restrictifs est réel, quantifiable et évitable grâce à une vérification préalable avant la clôture.
- La TPRM dans les fusions et acquisitions : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : liste complète des fournisseurs avec caractérisation de leur accès aux données ; constats de TPRM ouverts, quelle que soit leur gravité ; il convient de demander à une cible d’acquisition son portefeuille de fournisseurs, ses constats ouverts et son historique d’incidents dans le cadre de la vérification préalable de l’opération M&A. Ces informations déterminent le risque lié aux tiers que l’entreprise acquiert, qui doit être évalué financièrement et géré, et non découvert dix-huit mois après la clôture.
- Lacunes en matière de propriété et de responsabilité dans la TPRM
-
Les lacunes en matière de propriété et de responsabilité sont importantes parce que les risques identifiés qui restent non gérés ne sont pas moins dangereux que les risques non identifiés : ils le sont davantage, car l’organisation a une connaissance documentée du risque et ne peut invoquer l’ignorance lors d’une analyse post-incident ou d’un contrôle réglementaire.
Les lacunes en matière de propriété et de responsabilité sont importantes parce que les risques identifiés qui restent non gérés ne sont pas moins dangereux que les risques non identifiés : ils le sont davantage, car l’organisation a une connaissance documentée du risque et ne peut invoquer l’ignorance lors d’une analyse post-incident ou d’un contrôle réglementaire.
- Lacunes de responsabilité et d’appropriation en TPRM : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : processus formel de réponse à la remédiation des constats ; contact d’escalade pour les constats critiques non résolus ; engagement de délai de remédiation pour les constats critiques.
- Automatisation du programme de TPRM et ses limites
-
Les limites de l’automatisation sont importantes parce que les gains d’efficacité de l’automatisation de la TPRM sont réels et précieux, mais qu’ils doivent être obtenus sans compromettre la qualité analytique qui rend utile le renseignement sur les risques du programme.
Les limites de l’automatisation sont importantes parce que les gains d’efficacité de l’automatisation de la TPRM sont réels et précieux, mais qu’ils doivent être obtenus sans compromettre la qualité analytique qui rend utile le renseignement sur les risques du programme.
- Automatisation du programme de TPRM et ses limites : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : étape de revue humaine dans le processus d’évaluation automatisé ; processus de recoupement des preuves en complément de la notation des questionnaires ; indicateurs de qualité en complément des indicateurs d’efficacité.
- Modèles de maturité des programmes de TPRM
-
L’évaluation de la maturité de la TPRM est importante parce qu’elle fournit l’analyse structurée nécessaire pour hiérarchiser les investissements du programme.
L’évaluation de la maturité de la TPRM est importante parce qu’elle fournit l’analyse structurée nécessaire pour hiérarchiser les investissements du programme.
- Modèles de maturité des programmes de TPRM : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : alignement sur les cadres réglementaires pour chaque domaine ; feuille de route d’amélioration du programme guidée par les écarts de maturité ; validation indépendante de l’évaluation de maturité.
- Métriques & KPI du programme TPRM
-
Les indicateurs du programme sont importants parce qu’ils déterminent si l’investissement dans la TPRM est justifié et où il doit être orienté. Un programme mesuré uniquement à l’aide d’indicateurs d’achèvement des processus ne peut ni démontrer sa valeur à la direction ni identifier les domaines où des améliorations du programme auraient le plus fort impact en matière de réduction des risques.
les indicateurs du programme sont importants parce qu’ils déterminent si l’investissement en TPRM est justifié et vers quoi il doit être orienté.
- Indicateurs & KPI du programme de TPRM : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : taux de constats par niveau de fournisseur ; taux de remédiation et délai moyen ; il convient de demander à un fournisseur qui confirme disposer d’un programme de TPRM mature ses indicateurs de résultats en matière de risque. L’achèvement des processus vous indique qu’il fait fonctionner le programme. Les indicateurs de résultats vous indiquent ce que le programme a accompli.
- Défaillances de conception des questionnaires de TPRM
-
La conception des questionnaires est importante parce que la qualité du renseignement sur les risques qui oriente les décisions de TPRM est limitée par la qualité des informations produites par le questionnaire. Un questionnaire bien conçu qui pose les quarante bonnes questions produit un meilleur renseignement sur les risques, en moins de temps, qu’un questionnaire mal conçu de 187 questions.
La conception des questionnaires est importante parce que la qualité du renseignement sur les risques qui oriente les décisions de TPRM est limitée par la qualité des informations que génère le questionnaire.
- Défaillances de conception des questionnaires de TPRM : les preuves
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : configurations techniques précises plutôt que des attestations de politique génériques ; documents probants pour les mises en œuvre de contrôles déclarées ; documentation d’architecture pour les domaines de sécurité critiques.
- Empoisonnement des données d’entraînement
-
L’empoisonnement des données d’entraînement est la contamination du jeu de données d’entraînement d’un modèle d’apprentissage automatique de façon à lui faire apprendre des schémas erronés, biaisés ou délibérément manipulés, ce qui produit un modèle qui se comporte de manière incorrecte et prévisible, au profit d’un attaquant ou en reflétant les erreurs structurelles du corpus d’entraînement.
L’empoisonnement des données d’entraînement est important pour la TPRM parce que des produits d’IA qui obtiennent de bons résultats sur les métriques de test fournies par le fournisseur peuvent néanmoins présenter des angles morts systématiques causés par des données d’entraînement contaminées.
- Empoisonnement des données d’entraînement : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : documentation de la composition temporelle du corpus d’entraînement ; méthodologie et résultats d’évaluation de la qualité des étiquettes ; résultats des tests sur les angles morts face aux attaques adverses.
- Analyses d’impact des transferts
-
Une analyse d’impact des transferts évalue si la législation et les pratiques du pays de destination, notamment en matière d’accès des autorités publiques aux données, compromettent les protections que les clauses contractuelles types sont censées offrir. Si c’est le cas, des mesures supplémentaires doivent être adoptées, ou le transfert ne doit pas avoir lieu. Cette exigence découle de l’arrêt Schrems II de 2020.
c’est l’étape la plus souvent omise, car elle exige de se forger un avis sur le régime de surveillance d’un autre pays, ce qui semble relever d’un juriste plutôt que d’une équipe de protection de la vie privée. Mais les clauses l’exigent, les autorités de régulation la demandent, et un transfert vers les États-Unis fondé sur des clauses contractuelles types sans TIA au dossier est un transfert dont une autorité de régulation peut écarter le mécanisme.
- Risque lié aux dépendances transitives
-
Le risque lié aux dépendances transitives est important pour la TPRM parce que les éditeurs des logiciels que vous déployez ont des arbres de dépendances transitives qui peuvent contenir des composants vulnérables qu’ils ne surveillent pas activement.
Le risque lié aux dépendances transitives est important pour la TPRM parce que les éditeurs des logiciels que vous déployez ont des arbres de dépendances transitives qui peuvent contenir des composants vulnérables qu’ils ne surveillent pas activement.
- Risque lié aux dépendances transitives : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : confirmation d’une analyse SCA transitive complète ; délais de réponse à Log4Shell comme cas d’étude de vulnérabilité transitive ; il convient d’interroger un fournisseur qui confirme gérer les vulnérabilités par SCA sur la couverture en profondeur des dépendances transitives. L’SCA des dépendances directes est un point de départ. L’analyse transitive complète donne le tableau complet. Log4Shell est le cas de test de référence pour savoir si la distinction a été rendue opérationnelle.
- Centres de confiance
-
Un centre de confiance est une page publique présentant la posture de sécurité et de protection de la vie privée d’une organisation : certifications détenues, rapports disponibles sous NDA, liste des sous-traitants ultérieurs, politiques et réponses aux questions les plus fréquentes des acheteurs. Certains réservent des documents sur demande ; d’autres les publient librement.
Il transforme un travail répétitif de questionnaires au cas par cas en libre-service, et il témoigne de la maturité auprès d’un acheteur avant même le début de toute conversation. Un prospect qui peut constater que le rapport SOC 2 existe, que les sous-traitants ultérieurs sont répertoriés et que les questions ont reçu une réponse arrive à la revue de sécurité déjà rassuré.
- Critères des services de confiance
-
Les Trust Services Criteria ne sont pas une liste de contrôles. Ce sont des critères, des énoncés de ce qui doit être vrai, et chaque organisation conçoit ses propres contrôles pour y satisfaire. L’AICPA énonce le résultat requis ; l’entreprise auditée décide de ce qu’elle fait pour l’atteindre ; l’auditeur teste ce que l’entreprise a décidé.
C’est pourquoi deux entreprises d’un même marché peuvent détenir des rapports SOC 2 qui se lisent de façon totalement différente, avec un nombre de contrôles, une formulation et des preuves différents, et être tous deux valables. C’est aussi pourquoi un questionnaire construit sur les contrôles d’une entreprise ne peut pas être rempli à partir du rapport d’une autre entreprise.
- Typosquattage dans les registres de paquets
-
Le typosquatting est important pour la TPRM parce que les produits logiciels de vos fournisseurs reposent sur des arbres de dépendances qui peuvent inclure des paquets typosquattés à l’insu du fournisseur, parce que le paquet typosquatté était une dépendance transitive, parce qu’il n’avait pas de CVE et parce que leurs analyses SCA, par définition, ne détectent pas les paquets malveillants.
Le typosquatting est important pour la TPRM parce que les produits logiciels de vos fournisseurs reposent sur des arbres de dépendances qui peuvent inclure des paquets typosquattés à l’insu du fournisseur, parce que le paquet typosquatté était une dépendance transitive, parce qu’il n’avait pas de CVE et parce que leurs analyses SCA, par définition, ne détectent pas les paquets malveillants.
- Typosquattage dans les registres de paquets : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : détection des paquets malveillants au-delà de l’analyse des CVE ; épinglage des dépendances et application des fichiers de verrouillage ; il convient d’interroger un fournisseur qui confirme une analyse des vulnérabilités par SCA sur la détection des paquets malveillants. La SCA analyse les vulnérabilités connues. Les paquets typosquattés ne sont pas des vulnérabilités connues : il s’agit de code malveillant sans CVE. Outils différents, modèle de menace différent.
V
- Dérive des accès des fournisseurs au fil du temps
-
La dérive des accès des fournisseurs est importante parce qu’elle crée un écart systématique entre le profil de risque évalué par le programme de TPRM et le profil de risque que présente réellement la relation avec le fournisseur.
La dérive des accès des fournisseurs est importante parce qu’elle crée un écart systématique entre le profil de risque évalué par le programme de TPRM et le profil de risque que présente réellement la relation avec le fournisseur.
- Dérive des accès des fournisseurs au fil du temps : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : inventaire actuel de l’étendue des accès aux données ; modifications des accès depuis la dernière évaluation ; confirmation de l’absence de tout accès aux données non divulgué.
- Accès des fournisseurs via des principaux de service
-
Un principal de service est une identité non humaine créée dans une plateforme d’identité cloud (le plus souvent Azure Active Directory, mais le concept existe chez tous les grands fournisseurs cloud sous des noms différents) qui représente une application, un service ou un processus automatisé plutôt qu’une personne.
Les principaux de service constituent l’ossature opérationnelle des intégrations des fournisseurs dans les environnements Azure et Microsoft 365, et de plus en plus dans AWS et GCP également, sous des formes équivalentes comme les rôles IAM pour les applications et les comptes de service GCP.
- Accès des fournisseurs via des principaux de service : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : une liste précise des principaux de service utilisés dans votre environnement, avec la description de leurs périmètres d’autorisation ; une politique de rotation des identifiants fixant une durée de validité maximale, idéalement 90 jours ou moins pour les secrets clients ; la preuve d’un stockage sécurisé des identifiants côté fournisseur, dans un coffre-fort de secrets et non dans un fichier de configuration ou une variable d’environnement.
- Prolifération des comptes d’admin des fournisseurs
-
La prolifération des comptes administrateurs est l’accumulation, au fil du temps, de comptes d’administration à privilèges résultant d’une combinaison de décisions légitimes d’attribution et d’une gestion insuffisante de leur cycle de vie.
la prolifération des comptes administrateurs sur les plateformes des fournisseurs est importante en TPRM, car chaque compte administrateur superflu est un identifiant à hauts privilèges qu’un acteur malveillant pourrait utiliser pour prendre le contrôle total de la plateforme.
- Prolifération des comptes administrateurs des fournisseurs : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : nombre de comptes administrateurs et leur composition (salariés actuels, prestataires, parties externes) ; historique de la revue des justifications (date du dernier examen du besoin actif) ; confirmation d’un accès administrateur JIT ou documentation de la gouvernance des comptes permanents.
- Transparence des fournisseurs sur leur usage de l’IA
-
La transparence sur l’utilisation de l’IA par les fournisseurs est le cadre de divulgation et de responsabilité couvrant toutes les manières dont un fournisseur utilise l’IA d’une façon qui touche l’entreprise cliente, y compris les fonctionnalités de produit reposant sur l’IA commercialisées auprès du client et les systèmes d’IA internes qui utilisent les données du client à des fins opérationnelles propres au fournisseur, comme la notation des clients,
La transparence sur l’utilisation de l’IA par les fournisseurs est importante pour la TPRM parce que les données de l’entreprise (ses modes d’utilisation, son historique de support et son comportement opérationnel) peuvent être utilisées par les systèmes d’IA du fournisseur d’une manière qui influe sur le service que reçoit l’entreprise, sur les prix qui lui sont proposés et sur les décisions stratégiques que prend le fournisseur concernant la relation.
- Transparence des fournisseurs sur leur usage de l’IA : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : divulgation des systèmes d’IA internes utilisant les données de l’entreprise ; couverture des usages internes de l’IA dans l’accord de traitement des données ; divulgation de la classification et de l’orientation des clients.
- Lacunes de visibilité sur les alertes des fournisseurs
-
Les lacunes de visibilité sur les alertes des fournisseurs désignent l’absence d’accès du client aux données de surveillance, aux alertes et aux événements de détection générés par l’infrastructure d’opérations de sécurité d’un fournisseur pour les systèmes et les données concernés par la relation client.
Les lacunes de visibilité sur les alertes des fournisseurs sont importantes pour la TPRM parce que l’évaluation des capacités du SOC d’un fournisseur vous indique ce que le fournisseur peut détecter.
- Lacunes de visibilité sur les alertes des fournisseurs : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : procédure d’escalade des alertes pour les systèmes concernant le client ; disposition à transmettre certaines catégories d’alertes au SOC du client ; processus permettant au client de fournir un contexte de détection au SOC du fournisseur.
- Risques liés aux accès des fournisseurs à des fins d’analyse
-
Le risque lié aux accès analytiques survient lorsque les accès aux données accordés aux équipes d’analyse (les personnes chargées de créer des tableaux de bord, des rapports et des modèles analytiques) sont nettement plus étendus que ce qu’exige une tâche analytique précise, et sont maintenus sans les contrôles d’accès, la journalisation et la cadence de revue appliqués aux autres formes d’
le risque lié aux accès analytiques est important en TPRM, car le scénario de menace interne le plus susceptible de provoquer une violation de données clients importante chez un fournisseur SaaS mutualisé n’est pas une attaque externe sophistiquée : c’est un utilisateur analytique autorisé, disposant d’un accès en lecture illimité à l’ensemble des données clients, qui choisit d’utiliser cet accès en dehors
- Risques liés aux accès des fournisseurs à des fins d’analyse : les preuves
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : documentation du périmètre des accès analytiques (nombre d’analystes, étendue des accès, restriction du périmètre client) ; confirmation de la journalisation au niveau des requêtes pour les sessions analytiques ; historique des revues des accès analytiques, inclus dans les revues périodiques, avec la date de la dernière revue.
- Application des droits d’audit des fournisseurs
-
Les droits d’audit des fournisseurs sont des dispositions contractuelles qui permettent au client de réaliser, ou de faire réaliser, des évaluations de sécurité de l’environnement, des contrôles et des pratiques du fournisseur.
L’application des droits d’audit des fournisseurs est importante pour la TPRM parce que la vérification indépendante est le mécanisme de gouvernance qui distingue la gestion des risques de la documentation des risques.
- Application des droits d’audit des fournisseurs : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : preuves techniques pour les contrôles spécifiés plutôt que des réponses à un questionnaire ; coopération conforme à la clause de droit d’audit ; protection de la confidentialité des constats telle que convenue.
- Risque des sauvegardes des fournisseurs
-
Les données de sauvegarde contiennent les mêmes informations que les données de production au moment où la sauvegarde a été réalisée. Elles présentent la même sensibilité, la même classification réglementaire et les mêmes implications en matière de notification des violations en cas d’exposition.
le risque lié aux données de sauvegarde des fournisseurs est important en TPRM, car les systèmes de sauvegarde constituent le plus grand point d’accumulation de données historiques dans l’environnement d’un fournisseur : ils détiennent des copies de données clients remontant à plusieurs années, avec une gouvernance qui reflète l’état de l’organisation au moment de la création de chaque sauvegarde plutôt que les normes de sécurité actuelles.
- Risque lié aux données de sauvegarde des fournisseurs : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : historique des revues d’accès aux sauvegardes (date de la dernière revue et population actuelle disposant d’un accès) ; cycle de vie des clés de chiffrement des sauvegardes (calendrier de rotation et politique de rechiffrement des sauvegardes historiques) ; historique des analyses de sécurité du stockage des sauvegardes (analyse la plus récente et constats éventuels).
- Exposition du stockage des sauvegardes des fournisseurs
-
L’exposition du stockage des sauvegardes des fournisseurs est le risque qui survient lorsqu’un fournisseur conserve des copies de sauvegarde des données clients sous des contrôles de sécurité plus faibles, moins surveillés et gouvernés avec moins de rigueur que l’environnement de production principal évalué lors de la vérification préalable du fournisseur.
Le stockage des sauvegardes est l’endroit où les données vont pour être oubliées, non pas intentionnellement, mais comme conséquence structurelle de la manière dont les systèmes de sauvegarde sont conçus et hiérarchisés.
- Exposition du stockage des sauvegardes des fournisseurs : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : documentation de l’emplacement de stockage des sauvegardes, de la norme de chiffrement et des contrôles d’accès, équivalents ou supérieurs aux normes de production ; confirmation du périmètre SOC 2 couvrant explicitement l’infrastructure de sauvegarde, ou autre mécanisme d’assurance pour les environnements de sauvegarde ; processus défini de purge des sauvegardes déclenché par la résiliation du contrat, avec un délai engagé et une norme de preuve.
- Retards de détection des violations chez les fournisseurs
-
Les retards de détection des violations chez les fournisseurs sont l’écart entre le début d’un incident de sécurité dans l’environnement d’un fournisseur, sa détection par le fournisseur et la notification des clients du fournisseur. Ce sont trois événements distincts de la chronologie, chacun créant une catégorie différente de risque pour le client.
Les retards de détection des violations chez les fournisseurs sont importants pour la TPRM parce que les obligations réglementaires du client, le calendrier de sa réponse aux incidents et ses options d’atténuation des risques dépendent tous directement de la rapidité avec laquelle le fournisseur l’informe après la détection d’une violation.
- Retards de détection des violations chez les fournisseurs : les preuves
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : délai entre détection et notification lors d’incidents passés ; procédure de notification distinguant notification préliminaire et notification confirmée ; engagement de notification préliminaire dans un nombre d’heures défini après la détection.
- Comptes d’urgence des fournisseurs
-
Les comptes d’urgence sont des identifiants d’urgence à hauts privilèges, conçus pour les situations où les voies d’accès normales sont indisponibles et où des systèmes critiques exigent une intervention immédiate : verrouillages catastrophiques, incidents actifs nécessitant un accès administrateur plus rapide que ne le permettent les circuits normaux, et scénarios de reprise après sinistre où les
Les comptes bris de glace sont importants pour la TPRM parce que les fournisseurs qui gèrent des environnements clients disposent de mécanismes d’accès d’urgence à ces environnements, et ces mécanismes peuvent être sujets au même problème de dérive vers les paramètres par défaut.
- Comptes bris de glace des fournisseurs : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : journal d’utilisation des comptes bris de glace indiquant pour chaque utilisation le statut de déclaration d’urgence ; confirmation de l’application technique d’une double autorisation ; politique de sanctions en cas d’utilisation non autorisée d’un compte bris de glace.
- Continuité d’activité & résilience des fournisseurs
-
La continuité d’activité et la résilience des fournisseurs sont importantes parce que les perturbations opérationnelles chez les fournisseurs critiques affectent directement les opérations de l’entreprise, et que la capacité de l’entreprise à assurer la continuité de service pour ses propres clients lors de perturbations chez ses fournisseurs dépend de la disponibilité d’informations exactes sur les capa
La continuité d’activité et la résilience des fournisseurs sont importantes parce que les perturbations opérationnelles chez les fournisseurs critiques affectent directement les opérations de l’entreprise, et que la capacité de l’entreprise à assurer la continuité de service pour ses propres clients lors de perturbations chez ses fournisseurs dépend de la disponibilité d’informations exactes sur les capa
- Continuité d’activité & résilience des fournisseurs : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : résultats les plus récents des tests de BCP avec le RTO effectivement atteint ; documentation de l’architecture géographique de l’infrastructure principale et de secours ; confirmation de l’indépendance de l’infrastructure (alimentation électrique et réseau).
- Pratiques de revue de code des fournisseurs
-
La revue de code consiste à faire examiner une modification de code par un ou plusieurs développeurs avant sa fusion dans la base de code principale, afin de vérifier qu’elle est correcte, lisible, maintenable et conforme aux normes du projet.
La revue de code constitue le dernier point de contrôle humain avant la livraison du code, le moment du processus de développement où un réviseur sensibilisé à la sécurité peut détecter les vulnérabilités qui ont échappé aux outils automatisés, les failles de logique métier que les scanners ne peuvent pas détecter et les décisions de conception dont les implications en matière de sécurité ne sont visibles que pour quelqu’un qui comprend à la fois l
- Pratiques de revue de code des fournisseurs : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : documentation de la liste de contrôle de revue de sécurité couvrant l’authentification, l’autorisation, le traitement des entrées et les données sensibles pour les types de changements concernés ; description du programme de champions de la sécurité (sélection, formation et maintien des réviseurs) ; confirmation de la formation des développeurs à la sécurité avec le nom de la plateforme, la description de la couverture et la fréquence de diffusion.
- Indicateurs de compromission des fournisseurs
-
Les indicateurs de compromission des fournisseurs sont les preuves techniques (événements d’authentification, connexions réseau, modifications du système de fichiers, modifications du registre et exécutions de processus) qui démontrent la présence d’un attaquant dans l’environnement d’un fournisseur. Les indicateurs de compromission confirment que l’accès a eu lieu.
Les indicateurs de compromission des fournisseurs sont importants pour la TPRM parce que l’évaluation du risque de violation par le client, et sa décision de notification réglementaire, supposent de comprendre non seulement qu’un fournisseur a été compromis, mais aussi ce que la compromission a permis d’obtenir sur les données que le client partage avec ce fournisseur.
- Indicateurs de compromission des fournisseurs : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : confirmation de la journalisation API au niveau des données et des requêtes ; capacité d’investigation permettant de confirmer les conséquences des accès aux données ; il convient de demander à un fournisseur qui confirme sa capacité de détection des compromissions si sa journalisation permet de confirmer les conséquences, et pas seulement de détecter des indicateurs. L’indicateur apprend aux enquêteurs que l’accès a eu lieu. Le journal des conséquences leur apprend à quoi l’accès a servi.
- Risque de concentration des fournisseurs
-
Le risque de concentration des fournisseurs est important parce qu’il s’agit d’une propriété du portefeuille que les évaluations individuelles des fournisseurs sont structurellement incapables d’identifier : sa mesure exige d’agréger des données à l’échelle du portefeuille de fournisseurs.
Le risque de concentration des fournisseurs est important parce qu’il s’agit d’une propriété du portefeuille que les évaluations individuelles des fournisseurs sont structurellement incapables d’identifier : sa mesure exige d’agréger des données à l’échelle du portefeuille de fournisseurs.
- Risque de concentration des fournisseurs : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : évaluation par le fournisseur de son propre risque de concentration ; plan de continuité d’activité en cas de défaillance de son principal prestataire ; état de préparation de prestataires alternatifs pour les fonctions critiques.
- Coordination du confinement avec les fournisseurs
-
La coordination du confinement avec les fournisseurs consiste à concilier les décisions de confinement prises par l’équipe IR d’un fournisseur, qui doit peser l’impact opérationnel des mesures de confinement sur l’ensemble de ses clients, avec l’urgence de confinement d’un client précis dont les données sont activement menacées.
la coordination du confinement avec les fournisseurs est importante en TPRM, car la perte de données du client pendant une violation active chez un fournisseur dépend directement de la durée pendant laquelle l’attaquant conserve son accès, et cette durée dépend en partie de la rapidité avec laquelle le fournisseur exécute le confinement.
- Coordination du confinement avec les fournisseurs : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : autorité et processus de décision en matière de confinement ; délai maximal de confinement à compter de la demande du client ; déclencheurs de confinement préapprouvés, le cas échéant.
- Dérive des contrôles des fournisseurs
-
La dérive des contrôles est la dégradation progressive du programme de sécurité d’un fournisseur entre deux évaluations formelles : l’érosion progressive de la posture de sécurité due au renouvellement du personnel, à la réduction des budgets, à l’affaiblissement de la gouvernance et au retrait d’outils, qui pris isolément n’atteignent pas forcément le seuil d’un « changement important du programme », mais qui collectivement repr
la dérive des contrôles est importante en TPRM, car la qualité du programme de sécurité qui justifiait la notation de risque d’un fournisseur peut ne plus décrire fidèlement sa posture actuelle deux ans après le début de la relation.
- Dérive des contrôles des fournisseurs : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : effectifs de l’équipe de sécurité comparés à la dernière évaluation ; fréquence des réunions de gouvernance au cours des six derniers mois ; il convient de poser à un fournisseur qui confirme l’absence de changement significatif de son programme les quatre questions propres à la dérive. Chaque réponse prise isolément peut être inférieure au seuil de changement significatif. Le tableau d’ensemble peut décrire une dérive importante.
- Revues des accès des fournisseurs aux données
-
Les revues des accès, c’est-à-dire le processus périodique consistant à vérifier que tous les comptes ayant accès à des systèmes et données sensibles doivent toujours en disposer, sont un contrôle fondamental de la gouvernance des identités, exigé par PCI-DSS, SOC 2, ISO 27001 et la plupart des cadres réglementaires qui traitent de la sécurité de l’information.
la qualité des revues des accès est importante en TPRM, car c’est le contrôle qui détermine si l’accès accordé aux employés d’un fournisseur reste proportionné à leurs fonctions actuelles au fil du temps.
- Revues des accès des fournisseurs aux données : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : taux de révocation lors du cycle de revue des accès le plus récent ; format des données de revue des accès montrant le contexte des comptes fourni aux réviseurs ; confirmation du retrait automatisé des accès et description de l’intégration avec les RH.
- Risques liés à l’agrégation des données par les fournisseurs
-
Le risque d’agrégation des données est le risque qui naît de la combinaison de jeux de données individuellement anodins mais collectivement sensibles.
Le risque d’agrégation des données est important pour la TPRM parce qu’il représente une catégorie de risque invisible au niveau de l’évaluation de chaque client et visible uniquement au niveau du portefeuille de clients du fournisseur.
- Risques liés à l’agrégation des données par les fournisseurs : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : divulgation de la concentration sectorielle de la clientèle (combien de concurrents du secteur partagent des données équivalentes) ; confirmation dans le DPA de la restriction de l’utilisation des données entre clients ; description de l’architecture technique d’isolation des données.
- Risques liés à l’enrichissement des données par les fournisseurs
-
L’enrichissement des données est la pratique consistant à compléter un jeu de données de base avec des attributs supplémentaires provenant de fournisseurs externes, en ajoutant aux fiches clients des données démographiques, comportementales, firmographiques et psychographiques afin de créer des profils plus riches.
L’enrichissement des données par les fournisseurs est important pour la TPRM parce qu’il représente une catégorie de traitement de données qui a lieu dans le système du fournisseur sans décision explicite du client de collecter ou de traiter les données enrichies.
- Risques liés à l’enrichissement des données par les fournisseurs : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : déclaration des fonctionnalités d’enrichissement (ce qui est ajouté, à partir de quelles sources et dans quelles catégories) ; inventaire des données relevant du droit d’accès, y compris les catégories enrichies ; dispositions du DPA relatives à l’enrichissement (base légale, conservation et obligations de suppression pour les données enrichies).
- Lacunes des accords de traitement des données des fournisseurs
-
Les lacunes des accords de traitement des données sont importantes parce qu’elles déterminent si les obligations de l’entreprise en tant que responsable du traitement au titre du GDPR, à savoir garantir que les sous-traitants ne traitent les données personnelles que sur instruction documentée et pour des finalités déterminées, sont respectées.
les lacunes des accords de traitement des données sont importantes parce qu’elles déterminent si les obligations de l’entreprise en tant que responsable du traitement au titre du GDPR, en particulier veiller à ce que les sous-traitants ne traitent les données personnelles que sur instruction documentée et pour des finalités déterminées, sont respectées.
- Lacunes des accords de traitement des données des fournisseurs : les preuves
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : confirmation claire que l’utilisation pour l’entraînement de l’IA est interdite ou n’est pas pratiquée ; engagement de notification préalable des changements de politique ; confirmation d’un usage restreint, uniquement aux fins du service contractuel.
- Exposition des lacs de données des fournisseurs
-
Un lac de données est un référentiel centralisé conçu pour stocker de grands volumes de données brutes et non traitées provenant de sources multiples (bases de données applicatives, flux d’événements, journaux API, flux externes) dans leur format natif, ce qui permet des requêtes analytiques souples sans les contraintes de schéma d’une base de données relationnelle traditionnelle.
l’exposition des lacs de données des fournisseurs est importante en TPRM, car elle représente une concentration de données sensibles en un point de l’architecture du fournisseur expressément conçu pour être largement accessible.
- Exposition des lacs de données des fournisseurs : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : confirmation de l’existence d’un lac de données avec description du contrôle d’accès ; preuve de revue des accès (date de la dernière revue des accès au lac de données et population actuelle disposant d’un accès) ; confirmation de l’utilisation des données pour l’entraînement ML et processus d’autorisation.
- Pratiques de conservation des données des fournisseurs
-
La conservation des données par les fournisseurs est importante pour la TPRM parce que les données détenues par un fournisseur au-delà de la période où elles sont nécessaires représentent un risque résiduel pur, c’est-à-dire un risque sans aucun avantage opérationnel correspondant. Les données dont le fournisseur n’a plus besoin pour aucune finalité de traitement n’apportent aucune valeur.
La conservation des données par les fournisseurs est importante pour la TPRM parce que les données détenues par un fournisseur au-delà de la période où elles sont nécessaires représentent un risque résiduel pur, c’est-à-dire un risque sans aucun avantage opérationnel correspondant.
- Pratiques de conservation des données des fournisseurs : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : documentation du périmètre de suppression (tous les systèmes inclus dans le processus de suppression, avec confirmation explicite que les sauvegardes, les environnements de développement et les sous-traitants ultérieurs sont couverts) ; politique de conservation des sauvegardes (durées maximales de conservation et déclenchement ou non de la purge des sauvegardes par les demandes de suppression) ; preuve technique de la suppression (au-delà de la confirmation du chargé de compte, un enregistrement techniquement vérifiable du périmètre de suppression).
- Risques liés à la transformation des données par les fournisseurs
-
La transformation des données est le processus par lequel des données d’entrée sont modifiées, enrichies, dérivées ou calculées pour produire des données de sortie aux caractéristiques différentes : normalisation qui uniformise les formats, dérivation qui calcule de nouveaux attributs à partir d’attributs existants, enrichissement qui associe des données externes aux enregistrements d’entrée, et agrégation qui produit
La transformation des données par les fournisseurs est importante pour la TPRM parce que la transformation crée de nouvelles données, qui n’existaient pas avant que le fournisseur ne traite les données d’entrée, et dont les caractéristiques peuvent différer sensiblement de celles des données d’entrée en matière de statut réglementaire, de sensibilité et d’obligations liées aux droits.
- Risques liés à la transformation des données par les fournisseurs : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : inventaire des attributs dérivés (ce qui est créé à partir des données fournies par le client) ; dispositions du DPA relatives à la dérivation (base légale et conservation des attributs dérivés) ; confirmation du périmètre des DSAR incluant les attributs dérivés.
- Sécurité des environnements de développement des fournisseurs
-
La sécurité des environnements de développement est importante pour la TPRM parce que la chaîne d’approvisionnement logicielle commence sur les postes de travail des développeurs.
La sécurité des environnements de développement est importante pour la TPRM parce que la chaîne d’approvisionnement logicielle commence sur les postes de travail des développeurs.
- Sécurité des environnements de développement des fournisseurs : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : confirmation du MDM et de la sécurité des terminaux pour les postes de travail des développeurs ; gestion centralisée des identifiants de développement ; politique et surveillance des extensions d’IDE.
- Risques liés à l’intégration des annuaires des fournisseurs
-
L’intégration d’annuaires relie deux systèmes d’identité par une relation de synchronisation : les objets, attributs et événements de cycle de vie d’un annuaire se propagent à l’autre et, dans les intégrations bidirectionnelles, les modifications circulent dans les deux sens.
l’intégration d’annuaires est importante en TPRM, car c’est l’une des relations d’identité les plus fondées sur la confiance qu’une organisation puisse établir avec un fournisseur : les modifications de l’annuaire du partenaire se propagent directement dans l’infrastructure d’identité du client.
- Risques liés à l’intégration des annuaires des fournisseurs : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : documentation du périmètre de synchronisation de l’annuaire (types d’objets et attributs inclus) ; confirmation de la surveillance de la synchronisation entrante avec alertes en cas d’anomalie ; posture de sécurité des comptes administrateurs partenaires disposant d’un accès à la synchronisation de l’annuaire.
- Circuits d’escalade des fournisseurs
-
Les circuits d’escalade des fournisseurs sont les procédures documentées et les moyens de contact que les clients utilisent pour joindre la direction de la sécurité et de la réponse aux incidents du fournisseur lors d’un incident de sécurité.
Les circuits d’escalade des fournisseurs sont importants pour la TPRM parce que la capacité du client à obtenir des informations techniques, à coordonner les actions de réponse et à influer sur les décisions de confinement lors d’une violation chez un fournisseur dépend entièrement de l’efficacité du circuit d’escalade vers la direction de la sécurité du fournisseur.
- Circuits d’escalade des fournisseurs : les preuves
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : contact direct de l’équipe de sécurité, personne nommément désignée avec un mobile joignable hors heures ouvrées ; délai de réponse attendu pour une escalade urgente ; protocole d’incident actif pour l’escalade par le client.
- La santé financière des fournisseurs comme signal de TPRM
-
La surveillance de la santé financière est importante parce qu’elle comble l’écart entre l’exactitude d’une évaluation ponctuelle et la réalité actuelle du risque fournisseur.
La surveillance de la santé financière est importante parce qu’elle comble l’écart entre l’exactitude d’une évaluation ponctuelle et la réalité actuelle du risque fournisseur.
- La santé financière des fournisseurs comme signal de TPRM : les preuves
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : confirmation de la stabilité des effectifs de l’équipe de sécurité ; actualité du calendrier des évaluations et certifications ; absence d’investissements de sécurité significatifs reportés.
- Rôles IAM des fournisseurs dans votre cloud
-
Un rôle IAM dans un environnement cloud est un ensemble nommé d’autorisations qui définit quelles actions peuvent être effectuées sur quelles ressources et, point essentiel, il peut être endossé par des entités qui ne sont pas des utilisateurs humains.
les rôles IAM des fournisseurs sont l’une des manifestations les plus concrètes et les plus directes du risque lié aux tiers dans un environnement cloud.
- Rôles IAM des fournisseurs dans votre cloud : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : une liste des rôles IAM ou des principaux de service précis que le fournisseur utilise dans votre environnement, avec la description des autorisations ; la preuve de la gouvernance des identifiants côté fournisseur (comment les identifiants du personnel du fournisseur sont gérés et révoqués) ; un processus défini de mise hors service comprenant des étapes explicites de restitution ou de confirmation de la révocation des accès cloud.
- Preuves d’audit des identités des fournisseurs
-
Les preuves d’audit relatives à la gouvernance des identités sont la documentation qui démontre, à un examinateur externe, que les contrôles de gouvernance des identités ont fonctionné comme décrit : non pas des attestations de leur existence, mais des enregistrements de leur fonctionnement.
Les preuves d’audit des identités des fournisseurs sont importantes pour la TPRM parce que les clients qui s’appuient sur les attestations des fournisseurs concernant la gouvernance des identités pour leur propre conformité réglementaire peuvent découvrir que ces attestations sont indéfendables lorsque le régulateur demande les preuves sous-jacentes.
- Preuves d’audit des identités des fournisseurs : les preuves
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : registre des décisions de revue des accès (décisions individuelles avec examinateur et horodatage) ; document de définition des rôles (périmètre des permissions de chaque rôle) ; configuration de la MFA avec documentation des exceptions.
- Scénarios de compromission d’identité des fournisseurs
-
La compromission d’identité des fournisseurs est la catégorie d’attaque dans laquelle un acteur malveillant prend le contrôle des identifiants d’un employé du fournisseur, ou compromet l’infrastructure de gestion des identités du fournisseur, et utilise ces identifiants pour accéder aux environnements des clients par les voies d’accès légitimes du fournisseur.
La compromission d’identité des fournisseurs est importante pour la TPRM parce qu’elle représente la menace d’accès que les contrôles de sécurité côté client sont le moins à même de détecter.
- Scénarios de compromission d’identité des fournisseurs : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : description de l’analyse comportementale pour les accès du personnel de support aux environnements clients ; confirmation du déploiement d’une MFA résistante à l’hameçonnage pour le personnel ayant accès aux environnements clients ; confirmation de l’enregistrement des sessions pour les accès aux environnements clients.
- Gestion du cycle de vie des identités des fournisseurs
-
La gestion du cycle de vie des identités est l’ensemble des processus qui régissent la création, la maintenance et la désactivation des comptes utilisateurs tout au long de leur vie opérationnelle, afin que les comptes soient créés lorsque l’accès est nécessaire, maintenus de manière proportionnée à mesure que les besoins évoluent et désactivés lorsque l’accès n’est plus nécessaire.
le cycle de vie des identités des fournisseurs est important en TPRM, car les comptes de plateforme appartenant à d’anciens employés de fournisseurs représentent un risque de compromission d’identifiants précis et bien documenté.
- Gestion du cycle de vie des identités des fournisseurs : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : documentation du processus de notification des départs (retrait des accès à la plateforme inclus dans la liste de contrôle de départ des employés) ; vérification de l’emploi actuel pour tous les comptes actifs de la plateforme ; date et résultats du dernier rapprochement des effectifs.
- Surveillance des identités des fournisseurs
-
La surveillance des identités à la frontière avec les fournisseurs englobe deux domaines de surveillance distincts mais complémentaires. La surveillance côté client capture ce que font les identités des fournisseurs dans l’environnement du client : événements d’accès, requêtes de données, modifications de configuration, durée des sessions et schémas d’accès qui s’écartent de la référence.
La surveillance des identités des fournisseurs est importante pour la TPRM parce que la capacité de détection d’une compromission d’identité d’un fournisseur doit couvrir la frontière entre fournisseur et client : la surveillance du client ne peut à elle seule détecter la chaîne d’attaque antérieure à la session, et la surveillance du fournisseur peut à elle seule ne pas réagir aux signaux avant que les environnements des clients ne soient atteints.
- Surveillance des identités des fournisseurs : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : capacité de surveillance des identités côté fournisseur (alertes sur les échecs d’authentification et seuils de priorité) ; obligation et délai de notification en matière de sécurité des identités ; un fournisseur dont la surveillance détecte soixante-trois tentatives d’authentification échouées visant un membre du personnel, mais qui ne génère pas d’alerte prioritaire et n’informe pas le client, dispose d’une surveillance qui capte le signal sans y donner suite. Les deux moitiés comptent : le signal et la réponse. Interrogez-le sur les deux.
- Notation du risque d’identité des fournisseurs
-
La notation des risques liés aux identités est la pratique consistant à calculer un niveau de risque composite pour chaque principal d’identité (comptes utilisateurs, comptes de service et identifiants API) à partir de multiples signaux qui influent sur la probabilité et l’impact de sa compromission.
La notation des risques liés aux identités des fournisseurs est importante pour la TPRM parce que le personnel des fournisseurs qui accède aux environnements clients représente une surface de risque concentrée, où la compromission d’une seule personne peut avoir un impact sur plusieurs clients.
- Notation des risques liés aux identités des fournisseurs : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : description de la notation des risques liés aux identités, signaux utilisés et méthodologie de notation ; contrôles renforcés pour les personnes dépassant les seuils de risque ; un fournisseur qui répond « tout le personnel suit notre programme de sécurité standard » a décrit une gouvernance au niveau du programme. Demandez précisément si une personne de son équipe a été identifiée comme présentant un risque élevé en raison de la combinaison de l’étendue de ses accès et de ses signaux individuels de posture de sécurité. Le programme standard fixe le plancher. La notation des risques identifie qui se situe au-dessus.
- Défaillances de notification des incidents par les fournisseurs
-
La notification des incidents est importante parce que la capacité de l’entreprise à réagir à une violation chez un fournisseur dépend directement du moment où elle en est informée et de l’exhaustivité de cette information. Une notification tardive ou incomplète entraîne une réponse tardive, une mise en conformité réglementaire tardive, une notification tardive des personnes et une exposition prolongée aux conséquences de la violation.
La notification des incidents est importante parce que la capacité de l’entreprise à réagir à une violation chez un fournisseur dépend directement du moment où elle en est informée et de l’exhaustivité de cette information.
- Défaillances de notification des incidents par les fournisseurs : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : confirmation écrite de l’interprétation du déclencheur et du délai de notification ; contact direct avec l’équipe de sécurité pour la notification des violations ; modèle de contenu de notification ou engagement sur un contenu minimal.
- Exhaustivité de l’inventaire des fournisseurs
-
L’exhaustivité de l’inventaire des fournisseurs est la mesure dans laquelle le programme de TPRM d’une organisation a identifié et pris en compte toutes les relations actives avec des tiers : non seulement les fournisseurs ajoutés délibérément au programme de gestion des risques, mais l’ensemble des fournisseurs qui ont accès aux données, aux systèmes ou aux opéra
L’exhaustivité de l’inventaire des fournisseurs est l’exigence fondamentale de la TPRM : un programme qui ne sait pas ce qu’il ignore ne peut pas gérer le risque qu’il n’a pas identifié.
- Exhaustivité de l’inventaire des fournisseurs : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : mise en œuvre de déclencheurs d’enregistrement sur l’ensemble des circuits d’achat ; taux d’exhaustivité de l’inventaire communiqué à la direction ; il convient de demander à un fournisseur qui confirme disposer d’un programme de TPRM mature comment il sait que son inventaire est complet. La maturité des processus concerne les fournisseurs que le programme connaît. L’exhaustivité de l’inventaire indique si le programme connaît tous les fournisseurs qu’il devrait connaître.
- Maturité des plans d’IR des fournisseurs
-
La maturité du plan IR est la mesure dans laquelle un plan de réponse aux incidents reflète une capacité opérationnelle réelle et testée, et pas seulement l’existence d’une documentation décrivant les procédures prévues.
La maturité des plans d’IR des fournisseurs est importante pour la TPRM parce que l’issue pour le client en cas de violation chez un fournisseur dépend de la qualité d’exécution de l’IR par le fournisseur, et que cette qualité d’exécution dépend d’une maturité que la documentation seule ne peut démontrer.
- Maturité des plans d’IR des fournisseurs : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : date et scénario de l’exercice le plus récent ; disponibilité de guides de réponse par scénario (rançongiciel, exfiltration de données) ; indicateurs de performance d’IR issus des exercices (MTTD, MTTC).
- Fréquence des tests d’IR des fournisseurs
-
La fréquence des tests d’IR des fournisseurs ne se limite pas à la fréquence des exercices : elle englobe aussi l’étendue de leur couverture des scénarios d’attaque, des environnements technologiques et des participants de l’organisation qu’impliquerait un incident réel. La fréquence des tests est un indicateur nécessaire mais insuffisant de l’efficacité d’un programme d’IR.
La fréquence des tests d’IR des fournisseurs est importante pour la TPRM parce que la capacité d’IR qui compte le plus, à savoir une réponse coordonnée associant les fonctions juridique, communication, opérations et sécurité sous la pression d’un incident, ne se construit qu’au moyen d’exercices qui entraînent précisément cette coordination.
- Fréquence des tests d’IR des fournisseurs : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : journal des exercices (dates, scénarios, participants) ; il convient de demander à un fournisseur qui confirme tester régulièrement sa réponse aux incidents (IR) le journal des exercices. Le journal révèle ce que la confirmation ne dit pas : la fréquence précise, la diversité des scénarios, la couverture des participants et le périmètre des exercices red team. Le journal des exercices est la preuve. La confirmation est la description.
- Gestion des fournisseurs au titre de CC9
-
CC9 exige de l’organisation qu’elle identifie et atténue les risques liés aux perturbations de l’activité ainsi qu’aux fournisseurs et partenaires commerciaux. En pratique, le volet fournisseurs exige que vous sachiez qui sont vos fournisseurs, que vous évaluiez le risque qu’ils représentent, que vous les surveilliez tout au long de la relation et que vous gériez la fin de la relation.
C’est le critère qui rend auditable votre propre programme de gestion des risques liés aux tiers. C’est aussi pourquoi un fournisseur qui vous demande un rapport SOC 2 vous demandera, dans la même conversation, comment vous évaluez vos fournisseurs. Les deux questions sont le même critère vu de chaque côté.
- Couverture de la surveillance des fournisseurs
-
La couverture de la surveillance des fournisseurs, du point de vue du client, est la mesure dans laquelle le client a une visibilité sur les événements de sécurité de l’environnement du fournisseur qui concernent son propre risque, plus précisément les événements susceptibles d’indiquer une attaque de la chaîne d’approvisionnement en cours ou de laisser présager des menaces qui apparaîtront dans l’
La couverture de la surveillance des fournisseurs est importante pour la TPRM parce qu’elle détermine à quel stade du cycle de vie d’une attaque de la chaîne d’approvisionnement le client peut détecter une attaque provenant de l’environnement du fournisseur.
- Couverture de la surveillance des fournisseurs : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : procédure d’alerte en cas de compromission d’identifiants de développeurs ; engagement de transmission des événements touchant la chaîne d’approvisionnement ; il convient de demander à un éditeur de logiciels dont le produit est déployé dans l’environnement du client si son pipeline de compilation est surveillé et si les compromissions d’identifiants dans cet environnement seraient transmises au client. La surveillance du fournisseur couvre le fournisseur. L’accord de transmission couvre le client.
- Sortie de relation avec les fournisseurs
-
La sortie de relation est ce qui se passe lorsqu’une relation avec un fournisseur prend fin : les accès sont révoqués, les données sont restituées ou détruites avec preuve à l’appui, les intégrations et les clés API sont désactivées, le contrat est clôturé et l’entrée du registre est datée. C’est l’étape du cycle de vie qui est le plus systématiquement omise, car les relations prennent généralement fin sans bruit et personne n’est responsable de ce moment.
La fin d’une relation est le moment où des données sont laissées derrière soi. Un ancien fournisseur détient encore une copie, dispose encore d’un compte de service dans votre annuaire, a encore un webhook pointant vers vos systèmes, et personne ne s’en aperçoit jusqu’à ce qu’un audit échantillonne les fournisseurs sortis ou qu’une violation chez ce fournisseur expose des données que vous pensiez détruites deux ans plus tôt.
- Risque lié à la sortie des fournisseurs
-
Le risque lié à la fin de relation avec un fournisseur est important parce que les accès orphelins et les données conservées représentent une exposition continue qui ne génère aucune valeur métier. La clé API qui a subsisté après la clôture du contrat est un identifiant utilisable par un attaquant qui l’obtient, que ce soit par les systèmes de l’ancien fournisseur ou par les appareils de l’ancien employé.
Le risque lié à la sortie de relation avec les fournisseurs est important parce que les accès orphelins et les données conservées représentent une exposition continue qui ne génère aucune valeur métier.
- Risque lié à la sortie de relation avec les fournisseurs : les preuves
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : processus et délai de restitution et de suppression des données ; capacité de suppression certifiée avec preuves d’audit ; inventaire des données en fin de mission.
- Points de contrôle de sécurité à l’intégration des fournisseurs
-
Les points de contrôle de sécurité à l’intégration des fournisseurs sont importants parce que le risque que représente un fournisseur n’attend pas la fin de l’évaluation : il est présent dès l’attribution des accès. Un fournisseur non évalué disposant d’un accès aux données de production représente le même risque qu’un fournisseur évalué présentant des faiblesses de contrôle identifiées.
Les points de contrôle de sécurité à l’intégration des fournisseurs sont importants parce que le risque que représente un fournisseur n’attend pas la fin de l’évaluation : il est présent dès l’attribution des accès.
- Points de contrôle de sécurité à l’intégration des fournisseurs : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : processus d’entrée en relation avec un point de validation TPRM ; taux de conformité aux points de contrôle comme indicateur du programme ; il convient de demander à un fournisseur qui confirme la maturité de son programme de TPRM si ses propres évaluations de fournisseurs sont réalisées avant l’attribution des accès. La valeur du point de contrôle tient entièrement à son moment. Une évaluation postérieure à l’accès n’est pas un point de contrôle : c’est un examen rétrospectif.
- Retards d’intégration et de sortie des fournisseurs
-
Les retards d’attribution et de retrait des accès des fournisseurs sont les décalages entre le moment où un accès devrait être créé ou supprimé et celui où il l’est réellement.
Les risques liés aux délais d’intégration et de sortie sont importants pour la TPRM parce qu’ils représentent les modes de défaillance concrets de processus de gouvernance des accès bien conçus mais mal calibrés dans leur exécution.
- Retards d’intégration et de sortie des fournisseurs : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : SLA de notification des départs (délai maximal entre le départ et la notification au client) ; confirmation du moment du retrait des accès (retrait déclenché par l’événement ou planifié) ; données sur le délai de finalisation de l’intégration (délai moyen et maximal entre la désignation et l’accès).
- Risque lié aux contributions open source des fournisseurs
-
Le risque lié aux contributions open source est important pour la TPRM parce que les bibliothèques open source sur lesquelles reposent les logiciels des fournisseurs sont maintenues par des contributeurs humains dont les motivations peuvent changer, et parce que le modèle de confiance qui rend le développement open source efficace est aussi celui que ciblent précisément les attaquants de la chaîne d’approvisionnement.
Le risque lié aux contributions open source est important pour la TPRM parce que les bibliothèques open source sur lesquelles reposent les logiciels des fournisseurs sont maintenues par des contributeurs humains dont les motivations peuvent changer, et parce que le modèle de confiance qui rend le développement open source efficace est aussi celui que ciblent précisément les attaquants de la chaîne d’approvisionnement.
- Risque lié aux contributions open source des fournisseurs : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : prise en compte des attaques de type XZ Utils dans le modèle de sécurité de la chaîne d’approvisionnement ; il convient d’interroger un fournisseur qui confirme gérer ses dépendances open source sur la surveillance du risque lié aux contributeurs. La gestion des versions des dépendances porte sur le paquet utilisé. La surveillance des contributeurs porte sur les personnes autorisées à modifier ce paquet.
- Risques de l’adoption du sans mot de passe par les fournisseurs
-
L’authentification sans mot de passe remplace le secret partagé (mot de passe) par un identifiant cryptographique (clé d’accès, clé de sécurité matérielle ou certificat) qui prouve l’identité au moyen d’une clé privée qui ne quitte jamais l’appareil d’authentification.
Les risques liés à l’adoption du sans mot de passe sont importants pour la TPRM parce que les annonces de passage au sans mot de passe sont de plus en plus utilisées comme preuve d’une sécurité d’authentification avancée dans les évaluations des fournisseurs, et que l’écart entre l’annonce du déploiement et la migration complète est rarement divulgué.
- Risques de l’adoption du sans mot de passe par les fournisseurs : les preuves
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : pourcentage de couverture sans mot de passe (total des événements d’authentification par rapport aux événements migrés) ; état de migration des voies d’accès à l’infrastructure (VPN, SSH, bases de données) ; feuille de route de migration des voies restantes, avec calendrier.
- Rythme réel de correction des fournisseurs
-
La réalité de la cadence des correctifs est importante parce que les logiciels que déploie votre entreprise continuent d’accumuler des risques de vulnérabilité entre votre évaluation initiale et la prochaine revue prévue du fournisseur. Un fournisseur qui applique les correctifs lentement ou de manière incomplète est un fournisseur dont les logiciels deviennent progressivement plus vulnérables au fil du temps.
La réalité de la cadence des correctifs est importante parce que les logiciels que déploie votre entreprise continuent d’accumuler des risques de vulnérabilité entre votre évaluation initiale et la prochaine revue prévue du fournisseur.
- Réalité de la cadence des correctifs des fournisseurs : les preuves
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : données historiques sur les délais de correction (publication de la CVE par rapport à la sortie du correctif) ; liste des CVE critiques non corrigées avec calendrier de remédiation ; rythme moyen de correction par niveau de gravité.
- SLA de correction des fournisseurs et réalité
-
La vitesse d’application des correctifs est l’indicateur opérationnel qui détermine pendant combien de temps les données de votre organisation sont exposées à des vulnérabilités connues des applications des fournisseurs. Ce n’est pas un indicateur de risque théorique : c’est un calcul de calendrier.
la vitesse de correction est l’indicateur opérationnel qui détermine pendant combien de temps les données de votre organisation sont exposées par des vulnérabilités connues dans les applications des fournisseurs.
- SLA de correctifs des fournisseurs face à la réalité : les preuves
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : données réelles de délai de correction pour les quatre à six dernières CVE critiques touchant l’application du fournisseur, avec des chiffres précis et non des déclarations de politique ; documentation du processus de notification des clients pour les CVE critiques (délai, canal et engagement sur des recommandations provisoires) ; documentation du processus d’exception avec des données de fréquence, indiquant à quelle fréquence des exceptions au SLA sont accordées et la transparence offerte aux clients dans ce cas.
- Évaluations de la confidentialité des fournisseurs
-
Une évaluation de la confidentialité d’un fournisseur demande quelles données personnelles le fournisseur traitera, dans quel but, sur quelle base légale, où elles iront, combien de temps elles seront conservées, qui d’autre y aura accès et ce qu’il en adviendra à la fin de la relation. C’est un ensemble de questions différent de celui d’une évaluation de sécurité, et un fournisseur peut réussir pleinement l’une tout en échouant à l’autre.
les questionnaires de sécurité couvrent les contrôles et ignorent totalement la finalité. Un fournisseur parfaitement sécurisé qui utiliserait les données de ses clients pour entraîner ses propres modèles, les conserverait indéfiniment et les transférerait vers trois pays sans mécanisme de transfert passerait une revue de sécurité sans un seul constat.
- Fréquence de réévaluation des fournisseurs
-
La fréquence de réévaluation des fournisseurs est la cadence à laquelle une relation avec un fournisseur fait l’objet d’une évaluation de sécurité formelle, c’est-à-dire l’examen approfondi périodique qui confirme la posture de sécurité du fournisseur, identifie les changements de contrôles et met à jour la notation des risques de la relation.
La fréquence de réévaluation des fournisseurs est importante pour la TPRM parce que la fréquence de l’évaluation formelle doit refléter le profil de risque actuel de la relation, qui change à mesure que le fournisseur et la relation évoluent.
- Fréquence de réévaluation des fournisseurs : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : volume actuel de données traitées par rapport à la date de la dernière évaluation ; incidents de sécurité ayant touché d’autres clients depuis la dernière évaluation ; changements significatifs d’infrastructure (nouvelles régions cloud, nouvelles intégrations de systèmes).
- Fuites de données dans le reporting des fournisseurs
-
Le reporting des fournisseurs, c’est-à-dire la remise de rapports analytiques, de tableaux de bord, d’exports de données et de synthèses décisionnelles à des clients ou à des parties prenantes internes, est une activité de transfert de données qui n’est souvent pas encadrée avec la même rigueur que les autres formes d’accès aux données. Les rapports contiennent des données.
Les fuites de données liées aux rapports des fournisseurs sont importantes pour la TPRM parce que le reporting est l’un des flux de données continus les plus volumineux dans la plupart des relations avec les fournisseurs (transferts hebdomadaires ou mensuels de données clients vers des destinataires externes), et il n’est presque jamais évalué avec la rigueur appliquée aux autres transferts de données de volume et de sensibilité équivalents.
- Fuites de données liées aux rapports des fournisseurs : les preuves
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : confirmation du contenu des rapports (données agrégées uniquement ou enregistrements sous-jacents accessibles) ; historique des revues des listes de diffusion, avec confirmation de l’autorisation des destinataires actuels ; description du mode de remise, chiffré ou en clair.
- Tests de résilience des fournisseurs et exercices sur table
-
Les tests de résilience des fournisseurs sont importants parce que la résilience réelle de l’entreprise face aux perturbations chez ses fournisseurs dépend de la possibilité d’exécuter ses plans de continuité, et non de leur existence. Un BCP bien documenté qui ne peut pas être exécuté dans le scénario de perturbation qu’il décrit donne une fausse assurance.
Les tests de résilience des fournisseurs sont importants parce que la résilience réelle de l’entreprise face aux perturbations chez ses fournisseurs dépend de la possibilité d’exécuter ses plans de continuité, et non de leur existence.
- Tests de résilience et exercices sur table des fournisseurs : les preuves
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : comptes rendus des derniers exercices sur table portant sur des scénarios de perturbation chez un fournisseur ; délai de reprise testé par rapport au RTO prévu ; mises à jour du BCP découlant des constats des exercices.
- Validation des réponses des fournisseurs
-
La validation de la réponse des fournisseurs est le processus par lequel le client vérifie de manière indépendante que la réponse à incident d’un fournisseur a abouti à une remédiation complète et durable : non seulement l’éradication des menaces identifiées, mais aussi l’assurance qu’aucune présence résiduelle d’attaquant ne subsiste dans l’environnement du fournisseur.
la validation des réponses des fournisseurs est importante en TPRM, car la reprise du partage de données par le client avec un fournisseur après un rapport de remédiation réexpose ses données à toute présence résiduelle de l’attaquant que la remédiation n’a pas éradiquée.
- Validation de la réponse des fournisseurs : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : engagement de partage des IOC (indicateurs de compromission de l’enquête fournis au client) ; indicateurs de surveillance renforcée pendant la période de surveillance ; disposition à faire réaliser une validation indépendante en cas de violation importante.
- Agrégation des risques fournisseurs
-
L’agrégation des risques fournisseurs est l’analyse des expositions au risque à l’échelle du portefeuille qui résultent de la combinaison de relations fournisseurs évaluées individuellement, plus précisément des risques corrélés créés par des dépendances d’infrastructure partagées, des accès aux données partagés et des voies opérationnelles partagées, qui font que plusieurs fournisseurs individuellement peu risqués devi
L’agrégation des risques fournisseurs est importante pour la TPRM parce que les conseils d’administration et les régulateurs attendent de plus en plus des organisations qu’elles comprennent leur exposition globale aux risques issus des relations avec les fournisseurs : non seulement la répartition des notes de risque individuelles, mais aussi les risques de concentration créés par les dépendances partagées.
- Agrégation des risques fournisseurs : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : identité du principal fournisseur d’infrastructure cloud ; plan de continuité d’activité en cas d’événements affectant la disponibilité du fournisseur d’infrastructure ; infrastructure alternative ou capacité de basculement.
- Alignement sur l’appétence au risque fournisseur
-
L’alignement sur l’appétence au risque est important parce que les acceptations de risque qui enfreignent l’appétence au risque déclarée de l’entreprise créent un écart entre la posture de risque que le conseil d’administration et la direction croient avoir acceptée et celle que les décisions opérationnelles ont réellement créée.
l’alignement sur l’appétence au risque est important parce que les acceptations de risque qui enfreignent l’appétence au risque déclarée de l’entreprise créent un écart entre la posture de risque que le conseil d’administration et la direction croient avoir acceptée et celle que les décisions opérationnelles ont réellement créée.
- Alignement sur l’appétence au risque fournisseur : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : confirmation de la mise en œuvre des contrôles minimaux ; calendrier pour tout contrôle minimal non mis en œuvre ; acceptation des exigences de sécurité de base sans obstacle financier.
- Exactitude du registre des risques fournisseurs
-
L’exactitude du registre des risques est importante parce que les décisions de la direction en matière de risques (où affecter les ressources de remédiation, quels fournisseurs signaler au conseil d’administration, quelles relations réexaminer) sont prises à partir des données du registre. Un registre inexact produit une hiérarchisation des risques inexacte.
l’exactitude du registre des risques est importante parce que les décisions de la direction en matière de risques (où affecter les ressources de remédiation, quels fournisseurs signaler au conseil d’administration, quelles relations réexaminer) sont prises à partir des données du registre.
- Exactitude du registre des risques fournisseurs : les preuves
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : documentation du processus de mise à jour du registre et de ses déclencheurs ; un fournisseur qui affirme disposer d’un registre des risques complet doit être interrogé sur la manière dont il est tenu à jour. La valeur du registre tient à son exactitude. Le processus de mise à jour est le mécanisme qui maintient cette exactitude entre les revues formelles.
- Programmes de divulgation de sécurité des fournisseurs
-
Les programmes de divulgation de sécurité des fournisseurs sont importants pour la TPRM parce qu’ils déterminent la rapidité avec laquelle les vulnérabilités des logiciels des fournisseurs sont découvertes, corrigées et communiquées aux clients.
Les programmes de divulgation de sécurité des fournisseurs sont importants pour la TPRM parce qu’ils déterminent la rapidité avec laquelle les vulnérabilités des logiciels des fournisseurs sont découvertes, corrigées et communiquées aux clients.
- Programmes de divulgation de sécurité des fournisseurs : les preuves
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : données sur le respect des délais de correction pour les divulgations critiques ; processus et délai de notification préalable des clients ; périmètre du programme de divulgation et coordonnées de contact.
- Lassitude face aux questionnaires de sécurité des fournisseurs
-
La lassitude face aux questionnaires est importante parce qu’elle compromet la qualité du renseignement que les questionnaires sont censés produire. Les fournisseurs qui remplissent de grands volumes de questionnaires clients y répondent de manière à réduire le temps passé plutôt qu’à apporter un véritable éclairage sur leur sécurité.
La lassitude face aux questionnaires est importante parce qu’elle compromet la qualité du renseignement que les questionnaires sont censés produire.
- Lassitude des fournisseurs face aux questionnaires de sécurité : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : questionnaire standardisé rempli (SIG, CAIQ), le cas échéant ; rapport SOC 2 pour les domaines de contrôle concernés ; profil de sécurité du fournisseur sur une plateforme standardisée, s’il en tient un à jour.
- Lacunes du périmètre des tests de sécurité des fournisseurs
-
Les lacunes du périmètre des tests de sécurité sont les parties de la surface d’attaque d’une application qui sont exclues des tests de sécurité, que ce soit par des décisions délibérées de limitation du périmètre, par l’absence de mise à jour du périmètre à mesure que l’application évolue ou par l’exclusion implicite de composants dont l’inclusion n’a jamais été envisagée.
les lacunes de périmètre des tests de sécurité sont le problème de validité le plus fondamental de l’évaluation de la sécurité applicative des fournisseurs, plus fondamental que la méthode de test, la compétence du testeur ou la remédiation des constats.
- Lacunes du périmètre des tests de sécurité des fournisseurs : les preuves
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : documentation du périmètre du test d’intrusion, c’est-à-dire la définition réelle du périmètre et non la synthèse ; confirmation explicite que les composants d’intégration client sont inclus dans le périmètre testé ; inventaire complet de la surface API, avec la cartographie de la couverture indiquant quelles interfaces sont testées et lesquelles ne le sont pas.
- Intégration SOC des fournisseurs
-
L’intégration SOC des fournisseurs est la coordination opérationnelle entre les équipes d’opérations de sécurité d’un fournisseur et celles d’un client, plus précisément les mécanismes de communication en temps réel lors d’incidents partagés, d’escalade des détections concernant l’environnement de l’autre partie et de corrélation des événements entre les deux environnements afin d’identifier des attaques
L’intégration SOC des fournisseurs est importante pour la TPRM parce que les attaquants sophistiqués de la chaîne d’approvisionnement comprennent et exploitent les lacunes d’investigation entre des équipes d’opérations de sécurité indépendantes.
- Intégration SOC des fournisseurs : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : il convient de demander à un fournisseur disposant d’un SOC mature ce qui déclenche un appel direct au SOC du client plutôt que la conduite préalable d’une enquête interne. La maturité du SOC est la capacité. Le déclencheur d’escalade et le contact direct constituent l’intégration.
- Risques liés à l’intégration SSO des fournisseurs
-
L’authentification unique est un mécanisme de fédération d’authentification : elle permet aux utilisateurs de s’authentifier auprès de plusieurs systèmes à l’aide d’un seul jeu d’identifiants géré par un fournisseur d’identité central.
Les risques liés à l’intégration SSO des fournisseurs sont importants pour la TPRM parce que le SSO est de plus en plus présenté comme un contrôle de sécurité dans les évaluations des fournisseurs, la confirmation de l’intégration SSO servant de preuve que l’accès est gouverné de manière centralisée.
- Risques liés à l’intégration SSO des fournisseurs : les preuves
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : documentation du périmètre d’authentification (groupes ou critères qui restreignent l’authentification) ; correspondance des attributs SAML pour la détermination des rôles (attributs utilisés et logique d’attribution des rôles) ; niveau d’accès par défaut des utilisateurs authentifiés sans attribut de rôle, qui confirme le comportement de repli.
- Limites de la télémétrie des fournisseurs
-
Les limites de la télémétrie sont les lacunes dans le volume, le détail et la couverture des données pertinentes pour la sécurité auxquelles l’infrastructure de surveillance d’un fournisseur a accès, lacunes qui restreignent ce que le SIEM peut détecter, quel que soit le degré de maturité des règles de détection et des opérations du SOC.
Les limites de la télémétrie des fournisseurs sont importantes pour la TPRM parce qu’elles créent sur les chemins d’attaque des lacunes de visibilité qui sont invisibles pour le SOC du fournisseur et pour l’évaluation de TPRM du client.
- Limites de la télémétrie des fournisseurs : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : niveau de journalisation par système source pour les systèmes situés sur un chemin d’attaque ; état d’intégration au SIEM de chaque source ; il convient de demander à un fournisseur qui confirme une couverture SIEM complète l’inventaire de télémétrie des systèmes précis situés sur le chemin d’attaque vers les données des clients. La couverture du SIEM décrit ce qui est connecté. La qualité de la télémétrie décrit ce que cette connexion apporte.
- Visibilité sur les menaces chez les fournisseurs
-
La visibilité sur les menaces chez les fournisseurs est la capacité du client à voir l’activité pertinente pour la sécurité dans l’environnement du fournisseur qui concerne directement la sécurité des données et de l’intégration du client, plus précisément l’activité qui, combinée aux propres données de surveillance du client, révélerait une attaque transfrontière que la surveil
la visibilité des menaces chez les fournisseurs est importante en TPRM, car les attaques de la chaîne d’approvisionnement les plus sophistiquées ciblent délibérément les jointures entre les environnements de surveillance, en utilisant l’intégration entre le fournisseur et le client à la fois comme voie d’attaque et comme technique d’évasion de la détection.
- Visibilité des menaces chez les fournisseurs : les preuves
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : disposition à partager les données de surveillance des intégrations ; indicateurs d’activité des API pouvant être partagés ; protocole de partage des alertes d’anomalies d’intégration.
- Classement des fournisseurs
-
La hiérarchisation classe les fournisseurs selon le préjudice qu’ils pourraient causer, afin que l’effort d’évaluation suive l’exposition au lieu d’être réparti uniformément sur une liste dont la plupart des entrées ne pourraient pas vous nuire. Deux ou trois niveaux, définis par des critères objectifs : le fournisseur détient-il des données personnelles ou confidentielles, dispose-t-il d’un accès à votre environnement, et se trouve-t-il sur le chemin critique d’un service dont dépendent les clients.
Un programme qui évalue quatre cents fournisseurs avec la même profondeur n’en évalue bien aucun. Le classement par niveau est le mécanisme qui vous permet de consacrer quatre heures à l’outil de support qui contient des pièces jointes de tickets remplies de données personnelles et dix minutes au fournisseur de plantes, sans que personne ait à en débattre à chaque fois.
- Inexactitudes du classement des fournisseurs par niveau
-
Le classement des fournisseurs par niveau est le processus consistant à catégoriser les relations avec les fournisseurs selon leur niveau de risque afin d’appliquer une profondeur d’évaluation, une intensité de surveillance et des exigences de gouvernance proportionnées.
Les inexactitudes du classement des fournisseurs par niveau sont importantes pour la TPRM parce que toute la structure de gestion des risques du programme dépend de l’exactitude des niveaux.
- Inexactitudes du classement des fournisseurs par niveau : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : description complète de tous les services et intégrations fournis par l’entité du fournisseur et ses filiales ; déclaration de toute acquisition ayant eu une incidence sur la relation ; confirmation du recoupement avec l’inventaire des intégrations informatiques.
- Clés de chiffrement gérées par le fournisseur
-
La gestion des clés de chiffrement est la discipline qui consiste à contrôler qui peut générer, consulter, utiliser, renouveler et révoquer les clés cryptographiques qui protègent les données. Chiffrer sans gérer les clés revient à verrouiller un coffre-fort en laissant la combinaison écrite dessus : le mécanisme est solide, mais le contrôle est absent.
dans le contexte du risque lié aux tiers, la gouvernance des clés de chiffrement détermine si le chiffrement est un contrôle réel ou une simple case cochée pour la conformité.
- Clés de chiffrement gérées par le fournisseur : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : une description claire du modèle de gestion des clés, non pas « nous utilisons le chiffrement », mais le modèle précis et qui contrôle les clés ; un processus défini de révocation des clés lié à la résiliation du contrat, avec un délai précis ; la disponibilité des journaux d’audit d’utilisation des clés, preuve que les opérations de déchiffrement sont journalisées et vérifiables.
- VEX, Vulnerability Exploitability eXchange
-
Le VEX est important pour la TPRM parce que, sans lui, les entreprises trient manuellement de longues listes de vulnérabilités, processus coûteux et lent, ou appliquent une acceptation globale des risques à des vulnérabilités non signalées qui peuvent être exploitables ou non.
Le VEX est important pour la TPRM parce que, sans lui, les entreprises trient manuellement de longues listes de vulnérabilités, processus coûteux et lent, ou appliquent une acceptation globale des risques à des vulnérabilités non signalées qui peuvent être exploitables ou non.
- VEX, Vulnerability Exploitability eXchange : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : document VEX au format OpenVEX ou CycloneDX VEX ; justifications des statuts « non affecté » ; liste des statuts « affecté » avec calendrier de remédiation.
- VPN face à l’accès réseau Zero Trust
-
la distinction entre VPN et ZTNA est importante en TPRM, car la confirmation d’un accès VPN apporte une assurance sur le chiffrement du transport et l’authentification sans traiter l’étendue de l’accès réseau que fournit le VPN.
la distinction entre VPN et ZTNA est importante en TPRM, car la confirmation d’un accès VPN apporte une assurance sur le chiffrement du transport et l’authentification sans traiter l’étendue de l’accès réseau que fournit le VPN.
- VPN face à l’accès réseau Zero Trust : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : périmètre d’accès VPN (plages réseau par rapport aux besoins réels) ; nombre d’utilisateurs dans les groupes VPN par rapport aux besoins d’accès légitimes ; adoption ou feuille de route ZTNA pour l’accès des fournisseurs.
- SLA de gestion des vulnérabilités
-
Un SLA de remédiation associe un délai à chaque niveau de priorité : exposé à Internet avec exploitation connue, sept jours ; tout le reste pour lequel un correctif existe, trente jours ; les systèmes en attente de démantèlement sont suivis séparément avec une date. Les niveaux sont définis par l’exposition, l’exploitabilité et la valeur de l’actif, le score de gravité du scanner étant une donnée d’entrée et non la réponse.
Un SLA manqué chaque mois apprend à tout le monde à ignorer les SLA. Une entreprise dont le scanner produisait quatre-vingt-dix vulnérabilités critiques par mois face à un délai de sept jours le manquait systématiquement, ce qui vidait l’indicateur de son sens. Une nouvelle hiérarchisation selon l’exposition à Internet et l’exploitation connue a laissé environ une douzaine d’éléments par mois dans la tranche des sept jours, ce qui était réalisable, et le SLA est devenu réel.
W
- Les idées reçues sur le pare-feu applicatif web
-
La présence d’un WAF est l’un des contrôles de sécurité applicative les plus souvent cités dans les réponses des fournisseurs aux questionnaires : il est visible, il est mesurable (blocages par jour, attaques atténuées) et il fournit des indicateurs impressionnants qui suggèrent un engagement actif en matière de sécurité.
La présence d’un WAF est l’un des contrôles de sécurité applicative les plus souvent cités dans les réponses des fournisseurs aux questionnaires : il est visible, il est mesurable (blocages par jour, attaques atténuées) et il fournit des indicateurs impressionnants qui suggèrent un engagement actif en matière de sécurité.
- Les idées reçues sur le pare-feu applicatif web : les preuves
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : confirmation du suivi des contrôles compensatoires (vulnérabilités couvertes par le WAF suivies séparément des vulnérabilités corrigées, avec des délais de revue définis) ; confirmation du mode blocage du WAF, avec le périmètre de couverture de la surface applicative ; processus de gestion des faux positifs confirmant que les règles n’ont pas été systématiquement désactivées pour réduire les frictions opérationnelles.
- Ce que DevSecOps signifie réellement et ce que les fournisseurs prétendent qu’il signifie
-
DevSecOps : confirmé. Analyses de sécurité : en cours.
L’écart DevSecOps est important pour la TPRM parce que confirmer qu’un fournisseur utilise des outils DevSecOps sans évaluer si ces outils imposent quoi que ce soit donne une assurance de sécurité sur du théâtre sécuritaire plutôt que sur une pratique de sécurité.
- Ce que signifie réellement le DevSecOps et ce que les fournisseurs disent qu’il signifie : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : politique d’application en cas d’échec des analyses de sécurité (ce qui bloque le déploiement) ; cartographie de la couverture des analyses de sécurité (frameworks, écosystèmes, couches d’image) ; processus de remédiation des constats avec responsables désignés et SLA.
- Qu’est-ce que SLSA et pourquoi vos fournisseurs devraient s’en soucier
-
Conformité SLSA : confirmée. Niveau SLSA : 1.
SLSA est important pour la TPRM parce que les attaques de la chaîne d’approvisionnement logicielle, en particulier la compromission des pipelines de compilation et de la distribution des artefacts, comptent parmi les vecteurs d’attaque actuellement exploités qui ont le plus d’impact et qui sont les plus difficiles à détecter.
- Qu’est-ce que SLSA et pourquoi vos fournisseurs devraient s’en soucier : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : niveau SLSA précis, et non une conformité binaire ; attestation de provenance pour une version récente ; méthode de vérification de l’attestation.
- Sécurité des réseaux sans fil et risque fournisseur
-
La sécurité des réseaux sans fil est importante pour la TPRM parce qu’elle détermine le périmètre physique du réseau, c’est-à-dire la distance à laquelle un attaquant doit se trouver pour accéder à une partie quelconque du réseau.
La sécurité des réseaux sans fil est importante pour la TPRM parce qu’elle détermine le périmètre physique du réseau, c’est-à-dire la distance à laquelle un attaquant doit se trouver pour accéder à une partie quelconque du réseau.
- Sécurité des réseaux sans fil et risque fournisseur : les preuves
-
Lorsque vous interrogez un fournisseur sur ce point, voici les pièces à demander plutôt que de simples assurances : méthode d’authentification du réseau sans fil de l’entreprise, 802.1X ou clé partagée ; calendrier de renouvellement des identifiants invités et date du dernier renouvellement ; mise en œuvre d’un portail invité le cas échéant.
Z
- Architecture Zero Trust, ce qu’elle signifie vraiment
-
L’architecture Zero Trust est importante pour la TPRM parce que les fournisseurs qui déclarent appliquer le Zero Trust sans sa dimension de segmentation réseau disposent d’un réseau plat qui maximise le potentiel de déplacement latéral pour tout attaquant qui compromet un utilisateur ou un système interne.
L’architecture Zero Trust est importante pour la TPRM parce que les fournisseurs qui déclarent appliquer le Zero Trust sans sa dimension de segmentation réseau disposent d’un réseau plat qui maximise le potentiel de déplacement latéral pour tout attaquant qui compromet un utilisateur ou un système interne.
- Architecture Zero Trust, ce qu’elle signifie vraiment : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : description de la segmentation du réseau (quelles zones sont isolées de quelles autres) ; mise en œuvre du ZTNA ou d’un contrôle d’accès réseau équivalent ; vérification de la posture de l’appareil au moment de l’accès.
- Zero Trust pour les chaînes d’approvisionnement logicielles
-
Le Zero Trust appliqué aux chaînes d’approvisionnement logicielles est important pour la TPRM parce que les améliorations de sécurité qu’apporte le Zero Trust dans le contexte des réseaux s’appliquent tout autant à la chaîne d’approvisionnement logicielle, et les entreprises qui ont investi dans une architecture réseau Zero Trust tout en laissant leurs chaînes d’approvisionnement logicielles reposer sur une confiance implicite ont créé une asymétrie o
le Zero Trust appliqué aux chaînes d’approvisionnement logicielles est important en TPRM, car les améliorations de sécurité qu’apporte le Zero Trust dans le contexte des réseaux s’appliquent tout autant à la chaîne d’approvisionnement logicielle, et les entreprises qui ont investi dans une architecture réseau Zero Trust tout en laissant leurs chaînes d’approvisionnement logicielles fondées sur une confiance implicite ont créé une asymétrie o
- Zero Trust pour les chaînes d’approvisionnement logicielles : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : vérification de l’identité de l’éditeur au-delà de sa présence dans le registre ; minimisation des identifiants à chaque étape des agents de compilation ; description de l’architecture Zero Trust de la chaîne d’approvisionnement.
- Modèle de maturité Zero Trust pour l’évaluation en TPRM
-
L’évaluation de la maturité Zero Trust est importante pour la TPRM parce que la valeur de sécurité du programme Zero Trust d’un fournisseur est déterminée par la profondeur réelle de sa mise en œuvre dans les cinq dimensions, et non par l’étiquette qu’il lui applique.
L’évaluation de la maturité Zero Trust est importante pour la TPRM parce que la valeur de sécurité du programme Zero Trust d’un fournisseur est déterminée par la profondeur réelle de sa mise en œuvre dans les cinq dimensions, et non par l’étiquette qu’il lui applique.
- Modèle de maturité Zero Trust pour l’évaluation TPRM : les preuves
-
Lorsque vous interrogez un fournisseur à ce sujet, voici les éléments à demander plutôt que des assurances : preuves pour chaque stade de maturité revendiqué ; stade actuel et stade cible par pilier ; il convient de demander à un fournisseur qui confirme appliquer le Zero Trust ses niveaux de maturité par pilier. La confirmation du Zero Trust décrit l’étiquette. La maturité par pilier, preuves à l’appui, décrit la profondeur de mise en œuvre. Les deux sont nécessaires pour comparer les programmes Zero Trust des fournisseurs.
Tenu à jour par l’Association. Chaque terme est un résumé ; le cours indiqué à côté est celui où la pratique est enseignée.