Lors d'une évaluation TPRM portant sur un éditeur de logiciels traitant des paiements dans le secteur de la santé, les évaluateurs ont demandé des preuves à l'appui de la réponse au questionnaire confirmant un programme annuel de tests d'intrusion. La réponse du fournisseur avait confirmé : des tests d'intrusion annuels par un cabinet externe, des constats corrigés selon un SLA défini et des résultats examinés par le comité de sécurité. Les demandes de preuves ont révélé une tout autre réalité. Le rapport de test d'intrusion le plus récent datait de quatorze mois, en dehors de la cadence annuelle déclarée. Le document de suivi de la remédiation faisait état de quarante-trois constats ouverts, dont trente et un avaient dépassé l'échéance de leur SLA sans que la remédiation soit achevée. Les procès-verbaux du comité de sécurité montraient que la dernière réunion remontait à six mois, et que les constats du test d'intrusion, inscrits à l'ordre du jour, avaient été reportés à la réunion suivante, qui n'avait pas encore eu lieu. Chaque élément de la réponse au questionnaire était exact en tant que description du programme tel qu'il existait dans les politiques. Aucun ne reflétait l'état opérationnel actuel du programme. Le programme de tests d'intrusion était réel. Sa mise en œuvre au moment de l'évaluation n'était pas conforme aux exigences déclarées du programme.
Qu’est-ce que l’écart entre contrôle et mise en œuvre, réellement ?
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 la procédure) 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 contrôles qui existent au niveau des politiques décrivent la posture de sécurité prévue. Les contrôles mis en œuvre et en fonctionnement décrivent la posture de sécurité réelle. L'écart entre les deux est la différence entre la documentation de conformité et la réalité opérationnelle de la sécurité.
L'existence d'un contrôle est relativement facile à établir et à documenter. Une organisation peut créer en quelques jours une politique de sécurité de l'information, un programme de tests d'intrusion, un processus de gestion des vulnérabilités et une procédure de revue des accès. Ces politiques décrivent fidèlement les contrôles que l'organisation entend appliquer. Savoir si ces contrôles fonctionnent réellement (si les tests d'intrusion sont menés selon le calendrier, si les vulnérabilités sont corrigées dans le respect du SLA, si les revues des accès produisent de véritables décisions) est une autre question, qui exige des preuves opérationnelles plutôt que de la documentation de politiques.
Le problème du questionnaire utilisé comme documentation des politiques est le mécanisme par lequel les écarts entre contrôle et mise en œuvre persistent sans être détectés dans les programmes de TPRM. Les questionnaires qui demandent « disposez-vous d’un programme de tests d’intrusion ? » posent une question sur l’existence d’une politique. La réponse exacte (« oui, nous avons un programme qui exige des tests annuels, une correction selon des SLA et une supervision par un comité ») décrit fidèlement la politique. Elle ne décrit pas l’état de la mise en œuvre. Un programme de TPRM qui accepte les réponses aux questionnaires comme preuves de la mise en œuvre des contrôles a accepté une documentation des politiques comme preuve opérationnelle, et l’écart entre les deux reste invisible pour l’évaluation.
- Existence d'une politique acceptée comme preuve de mise en œuvre : les réponses au questionnaire décrivant la conception du programme sont traitées comme des preuves de son exécution opérationnelle
- Dépassements de SLA invisibles dans le questionnaire : les retards de correction n’apparaissent pas dans les réponses qui confirment l’existence de SLA de correction
- Défaillances de cadence non détectables à partir de la description des politiques : évaluations en retard et revues différées décrites correctement en tant que programmes, mais à tort comme étant à jour
- Gouvernance du comité décrite au présent : la supervision par le comité de sécurité est décrite comme existante même lorsque le comité ne s'est pas réuni récemment
- Demandes de preuves distinguant la politique de la mise en œuvre : l'étape d'audit que la plupart des évaluations par questionnaire omettent
Pourquoi c’est important
Les écarts de mise en œuvre des contrôles sont importants pour la TPRM, car la réduction du risque apportée par un contrôle de sécurité dépend entièrement de l'état opérationnel du contrôle, et non de son état sur le plan des politiques. Un programme de tests d'intrusion qui n'a produit aucun test depuis quatorze mois n'apporte aucune découverte de vulnérabilités au titre de ce programme. Quarante-trois constats ouverts dont les SLA de remédiation sont dépassés représentent des vulnérabilités connues qui existent dans l'environnement du fournisseur et n'ont pas été corrigées. La politique du programme est en place. La réduction du risque attendue du programme est absente.
L'exposition du client aux écarts de mise en œuvre des contrôles est directe : la posture de sécurité réelle du fournisseur est plus faible que ne le laisse penser la posture du programme confirmée par le questionnaire. Une notation des risques TPRM fondée sur des réponses au questionnaire qui confirment l'existence du programme est calibrée sur la posture de sécurité prévue. La posture de sécurité réelle (test d'intrusion en retard, constats non corrigés, comité inactif) est celle qui détermine l'exposition réelle du client au risque. La notation surestime la sécurité du fournisseur.
Là où la plupart des équipes se trompent
La défaillance la plus constante consiste à ne pas demander de preuves permettant de distinguer la politique de la mise en œuvre. La plupart des évaluations TPRM comportent des demandes de preuves, qui invitent les fournisseurs à fournir des pièces justificatives pour certaines réponses au questionnaire. La lacune réside dans ce qui est accepté comme preuve. Un document de politique du programme de tests d'intrusion ou une liste de paramètres de test confirme la conception du programme. Le rapport de test le plus récent et la feuille de calcul de suivi de la remédiation confirment l'état opérationnel. Accepter le premier comme preuve du second, voilà la lacune.
- Accepter la documentation des politiques comme preuve de mise en œuvre
- Demandes de preuves n’incluant pas d’indicateurs opérationnels : respect des SLA, respect des fréquences et ancienneté des constats
- Aucun examen des preuves de l'état de mise en œuvre : seule la documentation des politiques est examinée
- Formulation du questionnaire permettant des réponses exactes au regard des politiques mais inexactes au regard de la mise en œuvre
- Aucun suivi des lacunes dans les preuves : des preuves manquantes ou vagues sont acceptées sans contestation
À quoi ressemblent les bonnes pratiques
Les programmes TPRM matures distinguent les preuves de politique des preuves de mise en œuvre dans la conception de leurs demandes de preuves : ils demandent les éléments qui reflètent l'état opérationnel plutôt que la documentation des politiques, et réclament spécifiquement les indicateurs qui révèlent le respect de la cadence, le respect du SLA et la qualité d'exécution du programme.
- Demandes de preuves précisant les éléments de mise en œuvre : rapport de test le plus récent, ancienneté actuelle des constats, taux de respect du SLA de remédiation
- Vérification de la cadence : dates des exécutions les plus récentes du programme comparées à la cadence déclarée
- Indicateurs de respect du SLA : pourcentage de constats corrigés dans le respect du SLA, plutôt que la confirmation qu'un SLA existe
- Procès-verbaux des instances de gouvernance : confirmation que les comités de supervision se réunissent à la fréquence annoncée
- Suivi de l'ancienneté des constats : les constats ouverts les plus anciens comme indicateur de la qualité de la mise en œuvre
Outils
Plateformes de GRC : ServiceNow GRC, MetricStream, RSA Archer
Les plateformes GRC qui suivent les indicateurs de mise en œuvre des contrôles en parallèle de leur documentation offrent une visibilité sur l'état opérationnel que la documentation des politiques ne peut pas fournir. Pour les professionnels de la TPRM, demander aux fournisseurs s'ils utilisent une plateforme GRC qui suit les indicateurs de mise en œuvre (ancienneté des constats, respect du SLA de remédiation, respect de la cadence d'évaluation) constitue une question précise de surveillance de l'état opérationnel.
Conformité automatisée : Drata, Vanta, Secureframe
Les plateformes de conformité automatisée collectent en continu les preuves de mise en œuvre : elles vérifient que les tests d'intrusion ont été réalisés, suivent le respect du SLA de remédiation des vulnérabilités et alertent lorsque les contrôles cessent d'être efficaces. Pour les professionnels de la TPRM, demander aux fournisseurs s'ils utilisent une surveillance automatisée de la conformité capable de détecter et de signaler les défaillances de mise en œuvre décrites dans le scénario d'ouverture constitue une question précise sur leur capacité de détection.
Enjeux de gouvernance
Le défi de gouvernance posé par les écarts de mise en œuvre des contrôles tient à la conception des demandes de preuves. Demander des preuves est simple. Savoir quelles preuves distinguent la politique de la mise en œuvre, et ne pas accepter la documentation des politiques comme preuve de mise en œuvre, exige de comprendre la différence entre les deux et de concevoir des demandes de preuves qui font ressortir précisément les indicateurs de mise en œuvre.
- Concevoir les demandes de preuves autour des éléments de mise en œuvre : dates, indicateurs et registres opérationnels plutôt que documents de politique
- Demander la dernière exécution de tous les contrôles périodiques : rapport de test le plus récent, résultat de la revue la plus récente
- Demander les données de respect du SLA (pourcentage de conformité), et non la confirmation qu'un SLA existe
- Suivre la fréquence d’exécution du programme : date de la dernière exécution de chaque contrôle périodique
- Contester les preuves vagues : considérer « preuves disponibles sur demande » comme une absence de réponse
Si vous êtes une petite équipe
Pour vos trois relations fournisseurs les plus à risque, faites passer vos demandes de preuves pour trois contrôles courants de la documentation des politiques aux éléments de mise en œuvre. Au lieu de « documentation du programme de tests d'intrusion », demandez « le rapport du test d'intrusion le plus récent et la liste actuelle des constats ouverts avec leur ancienneté ». Au lieu de « politique de gestion des vulnérabilités », demandez « le nombre actuel de vulnérabilités ouvertes par tranche d'ancienneté et le taux de respect du SLA pour le dernier trimestre ». Au lieu de « charte du comité de sécurité », demandez « les procès-verbaux des trois dernières réunions du comité ». Ces trois demandes de preuves repensées révéleront immédiatement si la mise en œuvre des contrôles correspond à leur documentation.
- Demander le rapport de test le plus récent et la liste actuelle des constats ouverts, et non la documentation des politiques
- Demander les indicateurs de respect des SLA, et non la politique de SLA
- Demander les procès-verbaux des réunions, et non la charte du comité
- Suivre la cadence d'exécution de tous les contrôles périodiques
Ce qu’il faut exiger
Demandez directement :
« Pour votre programme de tests d'intrusion, veuillez fournir : la date de votre test d'intrusion externe le plus récent, le nombre de constats issus de ce test, ainsi que le nombre actuel de constats ouverts et l'ancienneté de votre plus ancien constat ouvert. »
« Pour votre programme de gestion des vulnérabilités, veuillez fournir votre taux de respect du SLA de remédiation pour le dernier trimestre, en précisant le pourcentage de vulnérabilités corrigées dans le délai défini par votre SLA. »
Preuves attendues
- Date du test d'intrusion le plus récent et nombre actuel de constats ouverts, avec l'ancienneté du constat le plus ancien
- Taux de respect des SLA de correction : pourcentage de conformité, et non politique de SLA
- Date de la dernière réunion du comité de sécurité
- Répartition par ancienneté des constats : depuis combien de temps les constats ouverts le sont
Il faut demander la date du test le plus récent à un fournisseur dont la réponse au questionnaire confirme un programme annuel de tests d'intrusion. Quatorze mois, c'est en dehors de la cadence annuelle. Le programme est réel. La mise en œuvre n'est pas à jour. Les deux peuvent être évalués. Demandez la date.
Comment le prouver
- Registres de preuves de mise en œuvre pour les principaux contrôles des fournisseurs
- Registres de vérification de la cadence : dates d'exécution les plus récentes
- Demandes de données de respect du SLA et résultats
- Documentation des demandes de preuves repensées
À retenir
Le programme qui existe sur le papier et le programme qui fonctionne en pratique sont deux postures de sécurité différentes. Le questionnaire décrit fidèlement le programme sur le papier. Les preuves révèlent le programme en fonctionnement. Quatorze mois depuis le dernier test d'intrusion, c'est un programme qui n'a pas testé l'environnement depuis quatorze mois. Trente et un constats ayant dépassé leur SLA de remédiation, ce sont trente et une vulnérabilités connues qui n'ont pas été corrigées. Un comité de sécurité qui ne s'est pas réuni depuis six mois est un organe de gouvernance qui n'a pas exercé sa fonction de supervision. Tous ces faits sont compatibles avec une réponse exacte au questionnaire qui confirme l'existence du programme. Le questionnaire décrit la conception. Les preuves décrivent le fonctionnement. Demandez les preuves qui révèlent le fonctionnement.