Un fournisseur de technologies financières disposait d’une politique de mots de passe complète, approuvée par le conseil d’administration, revue régulièrement et alignée sur les recommandations de la NIST SP 800-63B. La politique prévoyait une longueur minimale de douze caractères, des exigences de complexité, l’interdiction des mots de passe courants et une durée de validité maximale de quatre-vingt-dix jours pour les comptes à privilèges. Lors d’une évaluation technique de la sécurité, les évaluateurs ont confronté la configuration réelle de la plateforme d’identité à la politique. Voici ce qu’ils ont constaté : l’Azure AD de l’entreprise était configuré avec un minimum de huit caractères, la configuration n’ayant pas été mise à jour lors de la révision de la politique deux ans plus tôt. La complexité était appliquée dans Azure AD, mais pas dans les trois systèmes d’authentification d’applications héritées qui conservaient leurs propres annuaires d’utilisateurs. La rotation à quatre-vingt-dix jours s’appliquait aux comptes humains dans Azure AD, mais aucune exigence de rotation n’était configurée pour les comptes de service du même locataire. Les comptes de service des applications héritées utilisaient des mots de passe consignés dans un document d’identifiants partagé qui n’avait pas été mis à jour depuis quatorze mois. Chacun de ces écarts avait une cause commune : la politique avait été mise à jour pour refléter les bonnes pratiques de sécurité, mais les configurations techniques qui l’appliquaient n’avaient pas été mises à jour en conséquence. La politique décrivait ce qui devait être appliqué. Les configurations décrivaient ce qui était appliqué. Elles divergeaient sur chaque point mesuré.
L’écart entre politique et application, de quoi s’agit-il vraiment ?
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 comment les contrôles de sécurité doivent fonctionner) et les mécanismes techniques et opérationnels qui mettent réellement en œuvre ces exigences dans les systèmes en production. Les politiques sont des documents normatifs : elles précisent ce qui devrait être vrai. Les configurations, paramètres système et procédures opérationnelles sont des mécanismes de mise en œuvre : ils déterminent ce qui est vrai. Lorsque des politiques sont mises à jour sans mise à jour correspondante des mécanismes de mise en œuvre, la politique décrit une norme de sécurité renforcée que l’environnement n’applique pas.
Le retard de mise à jour par rapport aux politiques est la source la plus courante d’écarts entre politique et application. Les politiques sont mises à jour par des processus de gouvernance : cycles de revue, mises à jour des cadres, évolutions des recommandations réglementaires ou maturation du programme de sécurité. Ces processus produisent des documents de politique mis à jour qui reflètent fidèlement des exigences de sécurité renforcées. Les configurations techniques qui mettent en œuvre ces exigences (paramètres de mots de passe de la plateforme d’identité, jeux de règles de pare-feu, configurations de chiffrement, matrices de contrôle d’accès) sont mises à jour par des processus de gestion des changements qui exigent un effort d’ingénierie, des tests et un déploiement. Le processus de gouvernance qui produit les documents de politique mis à jour est généralement plus rapide et moins gourmand en ressources que le processus d’ingénierie qui met à jour les configurations techniques. La politique passe à la nouvelle norme. La configuration reste en retard.
Le problème des lacunes de couverture aggrave le retard de mise à jour. Même les politiques appliquées de façon cohérente dans les systèmes principaux présentent souvent des lacunes de couverture dans les systèmes secondaires : applications héritées dotées de leur propre authentification, systèmes acquis pas encore intégrés à la norme de l’entreprise, environnements de développement configurés différemment de la production, et comptes de service régis par d’autres processus que les comptes humains. Une politique de mots de passe qui s’applique au fournisseur d’identité de l’entreprise s’applique aux comptes gérés par ce fournisseur. Elle ne s’applique pas aux comptes des systèmes situés hors de son périmètre, sauf si ces systèmes sont explicitement régis par des configurations correspondantes.
- Politique mise à jour sans mise à jour de la configuration : la norme révisée de la politique n’est pas reflétée dans les configurations des systèmes
- Lacunes de configuration des systèmes hérités : la politique s’applique aux systèmes principaux, les applications héritées conservent des configurations distinctes
- Divergence de politique pour les comptes de service : la politique des comptes humains n’est pas appliquée aux comptes de service
- Aucune correspondance entre politiques et configurations : les politiques ne sont pas explicitement reliées aux configurations qui les mettent en œuvre
- Audit des configurations non réalisé : les configurations réelles des systèmes ne sont pas comparées aux exigences des politiques
Pourquoi c’est important
L’écart entre politique et application est un enjeu pour le TPRM parce que 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. Un fournisseur doté d’une politique de mots de passe rigoureuse et de configurations de mots de passe faibles présente une posture de sécurité différente de celle que suggère la confirmation de la politique. La sécurité réelle dépend de ce que la configuration applique, et non de ce que la politique exige.
La dimension réglementaire est explicite et de plus en plus contrôlée. Les régulateurs qui examinent des fournisseurs opérant dans des secteurs réglementés confronteront la configuration à la politique, en demandant non seulement « qu’exige votre politique », mais « qu’applique réellement votre système, et pouvez-vous démontrer que la configuration correspond à l’exigence de la politique ». Un écart entre les deux (douze caractères dans la politique, huit dans la configuration) constitue un constat que la rigueur de la politique n’atténue pas. Le contrôle, c’est la configuration, pas le document.
Là où la plupart des équipes se trompent
La défaillance la plus fréquente consiste à accepter la documentation des politiques comme preuve de la norme de sécurité en vigueur. Les politiques décrivent des exigences. Les configurations mettent en œuvre ces exigences. Ce sont des éléments différents, qui appellent des demandes de preuves différentes. Un document de politique de mots de passe confirme ce qui devrait être appliqué. Un export de configuration ou un rapport de conformité confirme ce qui est appliqué.
- Accepter la documentation des politiques comme preuve de mise en œuvre
- Audit des configurations non inclus dans l’évaluation
- Couverture des systèmes hérités non évaluée : configuration du système principal confirmée, systèmes hérités non examinés
- Configurations des comptes de service non évaluées séparément
- Correspondance entre politiques et configurations non examinée : aucune vérification que les politiques renvoient à des configurations précises qui les mettent en œuvre
À quoi ressemblent les bonnes pratiques
Les programmes matures de gouvernance des politiques tiennent à jour une correspondance explicite entre les exigences des politiques et les configurations qui les mettent en œuvre, réalisent des audits réguliers des configurations pour vérifier leur alignement, et disposent de processus de gestion des changements qui relient les mises à jour des politiques à celles des configurations.
- Correspondance entre politiques et configurations : documentation explicite des configurations qui mettent en œuvre chaque exigence de politique
- Fréquence des audits de configuration : comparaison régulière des configurations réelles aux exigences des politiques
- La mise à jour d’une politique déclenche une revue de configuration : les changements de politique génèrent des tâches de revue et de mise à jour des configurations
- Inventaire des configurations des systèmes hérités : configurations de tous les systèmes soumis à la politique documentées et auditées périodiquement
- Évaluation de la configuration des comptes de service : configurations des mots de passe et des identifiants des comptes de service évaluées séparément de celles des comptes humains
Outils
Conformité des configurations : AWS Config, Azure Policy, scanners de référentiels CIS
Les outils de conformité des configurations comparent en continu les configurations des systèmes déployés aux exigences définies par les politiques, et signalent celles qui ne respectent pas les normes. Les scanners de référentiels CIS évaluent les configurations des systèmes au regard des normes de durcissement du Center for Internet Security. Pour les praticiens du TPRM, demander si le fournisseur utilise des outils de conformité des configurations pour vérifier en continu que celles-ci correspondent aux exigences des politiques constitue une question précise sur l’alignement entre politique et application.
Conformité automatisée : Drata, Vanta
Les plateformes de conformité automatisées collectent des preuves de configuration en plus de la documentation des politiques, et associent ainsi exigences des politiques et vérification des configurations, ce qu’une évaluation manuelle ne peut assurer en continu. Pour les praticiens du TPRM, demander aux fournisseurs de fournir, en plus de la documentation des politiques, les résultats de leur plateforme de conformité confirmant la conformité des configurations permet d’obtenir à la fois la norme de la politique et la preuve de sa mise en œuvre.
Enjeux de gouvernance
La difficulté de gouvernance de l’écart entre politique et application tient à la discipline de gestion des changements nécessaire pour maintenir l’alignement des configurations sur les politiques à mesure que les unes et les autres évoluent. Les révisions de politique sont engagées par des processus de gouvernance. Les changements de configuration exigent un effort d’ingénierie. Les deux processus suivent des calendriers différents avec des responsables différents et, sans lien explicite entre eux, la politique progresse tandis que les configurations prennent du retard.
- Demander des preuves de configuration en plus de la documentation des politiques : les paramètres réels des systèmes, pas le document d’exigences
- Interroger sur la couverture des systèmes hérités : quels systèmes relèvent de la politique et lesquels ont des configurations indépendantes
- Poser une question distincte sur la configuration des comptes de service : les configurations des comptes humains et des comptes machine peuvent différer
- Demander quand la politique a été mise à jour pour la dernière fois et quand les configurations ont été auditées pour la dernière fois : l’écart entre les deux indique leur degré d’obsolescence
- Demander les résultats des outils de conformité plutôt que des documents de politique pour les contrôles techniques
Si vous êtes une petite équipe
Pour votre fournisseur le plus à risque, demandez la configuration réelle des mots de passe de sa principale plateforme d’identité : non pas le document de politique, mais l’export de configuration ou la capture d’écran montrant la longueur minimale, les exigences de complexité et les paramètres de rotation actuellement appliqués. Posez ensuite la même question sur la configuration de ses comptes de service. Comparez les deux à son document de politique. Les écarts entre eux sont les lacunes d’application que l’évaluation de la politique n’a pas révélées.
- Demander la configuration réelle des mots de passe : longueur minimale, complexité, rotation telles qu’appliquées
- Interroger séparément sur les configurations des mots de passe et des identifiants des comptes de service
- Comparer les configurations aux exigences des politiques
- Interroger sur les configurations de mots de passe des systèmes hérités
Ce qu’il faut exiger
Demandez directement :
« Pouvez-vous fournir la configuration des mots de passe actuellement appliquée sur votre principale plateforme d’identité, à savoir la longueur minimale, les exigences de complexité et les paramètres de rotation tels que configurés dans le système, et non tels que spécifiés dans votre politique ? »
« Votre politique de mots de passe s’applique-t-elle aux comptes de service de la même manière qu’aux comptes humains, et quelle est la configuration actuelle des mots de passe des comptes de service, y compris la fréquence de rotation ? »
Preuves attendues
- Configuration de la plateforme d’identité montrant les exigences de mots de passe réellement appliquées
- Configuration des mots de passe des comptes de service documentée séparément
- Inventaire des configurations de mots de passe des systèmes hérités
- Documentation de la correspondance entre politiques et configurations
Il convient de demander à un fournisseur qui présente une politique de mots de passe rigoureuse la configuration qui l’applique. La politique est l’exigence. La configuration est la réalité. L’écart entre une politique à douze caractères et une configuration à huit caractères n’est pas comblé par la rigueur de la politique.
Comment le prouver
- Registres des preuves de configuration des principaux contrôles techniques
- Registres d’évaluation des écarts entre politiques et configurations
- Registres d’audit des configurations
- Évaluation de la configuration des comptes de service
À retenir
La politique régit la norme. La configuration régit le comportement. Elles peuvent diverger, et c’est souvent le cas lorsque les processus de gouvernance mettent à jour les politiques plus vite que les processus d’ingénierie ne mettent à jour les configurations. Une politique à douze caractères avec une configuration à huit caractères n’est pas un échec de la politique : la politique est correcte. C’est un retard de configuration pour lequel le processus de politique n’a prévu aucun mécanisme de rattrapage. La preuve d’une politique rigoureuse est la preuve d’une exigence rigoureuse. La preuve de la configuration qui la met en œuvre est la preuve de la norme réellement appliquée. Demandez les deux. Acceptez la documentation de la politique comme spécification. Demandez les preuves de configuration comme mise en œuvre.