Assurance ou validation

Une entreprise de technologies de la santé a intégré un fournisseur de gestion de données cliniques dont le rapport SOC 2 de type II couvrait les critères de contrôle d'accès, de disponibilité et de confidentialité. L'assurance issue du rapport SOC 2 a été citée dans l'évaluation TPRM comme preuve de l'efficacité des contrôles d'accès du fournisseur. Ce que l'évaluation TPRM n'a pas vérifié, c'est la question précise posée par le CISO de l'entreprise de santé : un utilisateur du système du fournisseur peut-il accéder au dossier de n'importe quel patient, ou les contrôles d'accès sont-ils limités aux patients précis que chaque utilisateur est autorisé à traiter ? Le rapport SOC 2 a confirmé que le programme de contrôle d'accès du fournisseur fonctionnait : les utilisateurs étaient authentifiés, les accès étaient journalisés et des revues des accès étaient menées chaque trimestre. Il n'a pas vérifié si le modèle d'autorisation empêchait un utilisateur authentifié d'accéder aux dossiers d'autres patients. Ce n'était pas un critère du référentiel SOC 2. Lors d'un test d'intrusion commandé par l'entreprise de santé auprès du fournisseur (en exerçant son droit d'audit), le testeur s'est authentifié en tant qu'utilisateur clinique standard et a réussi à accéder aux dossiers de patients extérieurs à sa patientèle autorisée, par une manipulation de paramètres de l'API que le programme de contrôle d'accès du fournisseur n'avait pas traitée. L'assurance SOC 2 était valide. Le contrôle d'autorisation précis que l'entreprise de santé devait faire valider n'avait pas été testé par le rapport SOC 2.

Qu'est-ce réellement que le problème de l'assurance et de la validation ?

L'assurance est la confiance professionnelle, exprimée par un tiers indépendant, 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. L'assurance SOC 2, la certification ISO 27001 et les attestations de conformité PCI-DSS apportent toutes une assurance, c'est-à-dire la confiance que les contrôles du fournisseur satisfont à des critères définis, sur la base des tests de l'auditeur. La validation est la confirmation directe qu'un contrôle précis, dans une configuration précise, prévient un risque précis dans un contexte précis. La différence est celle qui sépare le général du particulier : l'assurance opère au niveau des référentiels et des critères, tandis que la validation opère au niveau des contrôles individuels et des scénarios d'attaque précis.

L'écart de critères est le mécanisme par lequel l'assurance laisse des risques précis non validés. Chaque référentiel d'assurance définit les critères qu'il évalue, c'est-à-dire les exigences de contrôle précises qui doivent être satisfaites pour que l'opinion d'assurance soit émise. Les contrôles et les risques qui ne relèvent pas de ces critères ne sont ni évalués ni couverts par l'assurance. Les Trust Services Criteria du SOC 2 couvrent de larges catégories de gestion des accès, de disponibilité et de confidentialité, mais ne prévoient pas de tester toutes les techniques possibles de contournement des autorisations. Un fournisseur dont le rapport SOC 2 confirme l'efficacité des contrôles d'accès peut avoir un modèle d'autorisation présentant des vulnérabilités précises que les critères SOC 2 n'ont pas été conçus pour détecter.

L'écart lié aux risques propres aux applications en est la manifestation la plus concrète pour la TPRM. Chaque relation avec un client crée des risques précis en fonction des données, des systèmes et des modes d'accès concernés. Le risque précis d'une entreprise de santé, l'accès aux dossiers d'autres patients par manipulation de paramètres d'API, est un risque propre à la relation qu'un référentiel de conformité générique ne traitera pas spécifiquement. Valider les risques propres à une relation exige des tests qui ciblent ces risques précis dans le contexte précis de la relation avec le fournisseur, et non l'assurance d'un référentiel qui définit ses propres critères indépendamment du profil de risque d'un client donné.

• Critères du référentiel d'assurance ne couvrant pas le risque précis du client
• Scénarios d'attaque propres à la relation absents des critères de conformité
• Contournement des autorisations de l'API ne figurant pas parmi les critères SOC 2
• Lacunes de contrôle d'accès propres à l'application non détectées par une assurance générique
• Aucune validation directe des scénarios les plus à risque propres au client

Pourquoi c’est important

La distinction entre assurance et validation est importante pour la TPRM, car les risques précis que créent les relations avec les clients (les données particulières qu'elles exposent, les modes d'accès particuliers qu'elles permettent, les scénarios d'attaque particuliers les plus pertinents) ne relèvent souvent pas des critères des référentiels de conformité qui fournissent les principales preuves d'assurance. L'assurance de conformité confirme le programme de contrôle générique. Le risque propre au client exige une validation spécifique.

La dimension des données réglementées rend ce problème particulièrement aigu. Les types de données réglementées (PHI dans le secteur de la santé, PII au titre du GDPR, données de titulaires de cartes au titre de la norme PCI-DSS, données financières au titre des réglementations financières) créent des exigences précises de contrôle d'accès qui peuvent ne pas être pleinement prises en compte dans les critères du référentiel de conformité général d'un fournisseur. Un fournisseur dont le rapport SOC 2 confirme le fonctionnement des contrôles d'accès n'a peut-être pas été testé spécifiquement sur les exigences d'autorisation applicables au type précis de données réglementées que le client partage.

Là où la plupart des équipes se trompent

L'erreur la plus constante consiste à accepter l'assurance comme validation du risque propre au client. L'assurance répond à la question du référentiel. La validation répond à la question du client. Un même fournisseur peut apporter des réponses différentes à ces deux questions.

• Accepter l'assurance comme validation du risque propre au client
• Critères du référentiel considérés comme une couverture du risque du client
• Aucune validation du risque propre au client pour les scénarios les plus à risque
• Droit d'audit non utilisé pour des tests de validation spécifiques
• Scénarios d'attaque propres à la relation non testés

À quoi ressemblent les bonnes pratiques

Les programmes matures d'assurance et de validation s'appuient sur l'assurance de conformité pour comprendre l'environnement de contrôle général et la complètent par des tests de validation spécifiques pour les scénarios les plus à risque propres au client, au moyen de tests d'intrusion, de tests de sécurité des API et d'exercices ciblés du droit d'audit, afin de valider les contrôles précis qu'exige le profil de risque du client.

• L'assurance comme fondement, la validation comme complément : la conformité apporte une confiance générale, la validation traite les risques précis
• Scénarios de risque propres au client identifiés : quelles attaques précises toucheraient le plus cette relation
• Tests de validation ciblés pour les scénarios précis les plus à risque
• Droit d'audit exercé à des fins de validation, axé sur les questions de risque propres au client
• Constats de validation intégrés au registre des risques parallèlement à l'évaluation fondée sur l'assurance

Outils

Tests de sécurité des applications : Burp Suite, OWASP ZAP, tests de sécurité des API

Les outils de test de sécurité des applications permettent de valider des vulnérabilités précises de contrôle d'accès et d'autorisation que les tests des référentiels de conformité ne traitent pas. Pour les professionnels de la TPRM, commander des tests de sécurité des API ciblés sur les risques précis de contrôle d'accès de la relation avec le fournisseur fournit les preuves de validation que l'assurance SOC 2 ne peut pas fournir.

Tests d'intrusion : exercices ciblés du droit d'audit

Les tests d'intrusion ciblés commandés au titre du droit d'audit et axés sur des scénarios de risque précis définis par le client permettent de valider exactement les risques créés par la relation avec le client. Pour les professionnels de la TPRM, élaborer des scénarios de test propres au client pour les tests d'intrusion menés au titre du droit d'audit permet d'obtenir la validation spécifique que les tests de conformité génériques ne peuvent pas produire.

Enjeux de gouvernance

Le défi de gouvernance posé par la distinction entre assurance et validation est le coût des tests de validation spécifiques. Les tests d'intrusion ciblés et les évaluations de sécurité des applications exigent un investissement important pour chaque relation avec un fournisseur. La réponse de gouvernance consiste à hiérarchiser l'exigence de validation selon le risque : une validation spécifique complète pour les relations les plus à risque, où le risque propre au client a les conséquences les plus graves, et le recours à l'assurance pour les relations moins risquées, où les critères du référentiel constituent une approximation suffisante du risque du client.

• Identifier les deux ou trois scénarios de risque propres au client les plus importants pour chaque relation à haut risque
• Commander des tests de validation ciblés pour ces scénarios précis
• Utiliser le droit d'audit pour la validation, et pas seulement pour l'attestation
• Distinguer ce que le rapport SOC 2 a testé et n'a pas testé pour la relation précise avec le fournisseur
• Documenter l'écart de validation : quels risques précis sont couverts par l'assurance et lesquels nécessitent une validation directe

Si vous êtes une petite équipe

Pour votre fournisseur le plus à risque, notez le scénario d'attaque qui, s'il réussissait chez ce fournisseur, causerait le plus de tort à vos clients : le mode d'accès précis, le type de données précis, le chemin d'exploitation précis. Demandez ensuite si le dernier rapport SOC 2 ou la dernière évaluation ISO 27001 du fournisseur a testé précisément ce scénario. Si la réponse est non ou incertaine, vous avez identifié l'écart de validation. Ce scénario précis définit le périmètre d'un test ciblé, mené au titre du droit d'audit, qui valide ce que l'assurance de conformité ne valide pas.

• Identifier le scénario d'attaque le plus préjudiciable pour chaque relation à haut risque avec un fournisseur
• Vérifier si l'assurance de conformité a testé précisément ce scénario
• Commander des tests de validation ciblés pour les scénarios hautement prioritaires non validés
• Utiliser le droit d'audit pour une validation propre à un scénario

Ce qu’il faut exiger

Demandez directement :

« Nous avons identifié [scénario d'attaque précis, par exemple une manipulation de paramètres de l'API permettant d'accéder aux données d'autres clients] comme le scénario le plus à risque pour notre relation. Votre dernier rapport SOC 2 ou votre dernier test d'intrusion a-t-il testé précisément ce scénario et, si ce n'est pas le cas, donneriez-vous votre consentement à un test ciblé de ce scénario précis au titre de notre clause de droit d'audit ? »

Preuves attendues

• Confirmation du fait que le scénario précis a été testé ou non lors des évaluations existantes
• Consentement à des tests de validation ciblés pour les scénarios non validés
• Résultats des tests antérieurs si le scénario a été évalué
• Preuves de remédiation si le scénario a déjà été identifié comme une lacune

Un fournisseur qui confirme une assurance SOC 2 sur le contrôle d'accès doit être interrogé sur le test précis du scénario d'accès le plus pertinent pour les données du client. L'assurance couvre les critères. La validation couvre le scénario.

Comment le prouver

• Registres d'identification des scénarios de risque propres au client
• Registres des tests de validation ciblés
• Documentation de l'écart de validation
• Registres de l'exercice du droit d'audit à des fins de validation

À retenir

L'assurance répond à la question du référentiel. La validation répond à la question du client. Le rapport SOC 2 a confirmé le fonctionnement des contrôles d'accès : authentification, journalisation, revues. Le test d'intrusion a révélé qu'un utilisateur authentifié pouvait accéder au dossier de n'importe quel patient par manipulation de paramètres de l'API. Les deux constats sont exacts. Le référentiel d'assurance ne posait pas la question du client. Seuls les tests de validation ciblés l'ont posée. Identifiez les scénarios de risque propres au client. Vérifiez si l'assurance existante les a testés. Commandez des tests de validation pour ceux qui ne l'ont pas été. Le référentiel fournit le fondement. Le risque précis du client exige le complément.