Les clients sont parfois surpris que nous n’utilisions presque jamais de fiche formelle de contrôle compensatoire. La paperasse est lourde et les équipes occupées n’aiment pas cela, mais ce n’est pas la raison. La raison est que l’essentiel de ce qu’on nous propose comme contrôle compensatoire n’en est pas un. C’est un autre contrôle, pour une autre exigence, présenté à la place de celui qui était demandé. Nous préférons qu’un client corrige le contrôle, ou l’enregistre comme non en place avec un plan, plutôt que de construire une fiche autour d’un substitut.
Refusé : « on le bloque au pare-feu »
Un service qui n’aurait pas dû tourner écoutait sur toutes les interfaces d’un nœud de conteneurs. Le propre inventaire des services approuvés du client le listait comme non approuvé et indiquait qu’il devait être désactivé. L’exception ouverte à son sujet a été close comme « remplacée par des règles réseau de refus ».
Bloquer le trafic ne désactive pas le service. L’exigence porte sur les services qui tournent sur le système. Une autre exigence couvre le réseau. Pour clore le constat : le service désactivé dans l’image du nœud, démontré sur un nœud en fonctionnement.
Refusé : « notre infrastructure-as-code est notre détection des changements »
Pour l’exigence qui demande un mécanisme de détection des changements qui alerte des personnes, le client a pointé les modèles qui définissent sa plateforme de conteneurs. Les modèles définissent l’état souhaité. L’exigence demande quelque chose qui remarque quand l’état réel s’en écarte, et qui prévient quelqu’un. Une détection de dérive pourrait être acceptable, avec la preuve qu’elle tourne : ce qu’elle couvre, à quelle fréquence elle compare, comment un changement hors processus déclenche une alerte, et qui la revoit. Elle doit aussi voir les changements à l’exécution que les modèles ne verront jamais. Montrer que le code correspond au déploiement aujourd’hui prouve aujourd’hui.
Refusé : « on l’écrira à la main le jour même »
Un fournisseur d’infrastructure de paiement, sous le standard de sécurité des PIN, proposait de garder ses procédures de cérémonie des clés génériques et de compléter les détails à la main au début de chaque cérémonie. Cela semble raisonnable, et c’est ce qui le rend dangereux. Cela mélange deux choses. Les données d’instance, les noms, les numéros de série des cartes, les valeurs de contrôle, les numéros de scellés, peuvent s’écrire à la main. Les paramètres de conception, non : le quorum, le nombre de cartes, l’exportabilité des clés, les commandes autorisées. Choisis dans la salle, sous pression, par la seule personne qui comprend le sujet, ils ne reçoivent ni approbation ni revue. Le quorum à lui seul fixe le seuil de collusion de tout le système. Il va dans une annexe approuvée avant la cérémonie.
Sur un point voisin, le fournisseur décrivait un contrôle optionnel qui était une vraie bonne pratique. Notre réponse : ce que vous décrivez est un bon contrôle, il n’est pas dans la procédure, et c’est la procédure que nous examinons. Un contrôle optionnel n’est pas un contrôle.
Recadré : l’autorisation qui ne pouvait pas être temporaire
Le même fournisseur a rejeté notre recommandation de rendre temporaire l’autorisation des commandes hôte d’un module de sécurité matériel, parce que son système de gestion des terminaux doit générer et exporter des clés à la demande. Il avait raison sur cette contrainte, et nous l’avons dit. Mais une autorisation permanente combinée à des clés marquées exportables est exactement la combinaison qui pose problème. L’issue n’était ni d’insister ni d’abandonner : borner et surveiller. Une liste de commandes minimale, des attributs de clés verrouillés, chaque commande d’export journalisée et revue. Un contrôle que l’on ne peut pas retirer peut encore être resserré.
Un contrôle que l’on ne peut pas retirer peut encore être resserré.
Accepté : pas d’agent sur un système d’exploitation immuable
Une plateforme de paiement faisait tourner ses nœuds de conteneurs sur un système d’exploitation immuable, en lecture seule, sans gestionnaire de paquets et sans moyen d’installer un agent. Les analyses de vulnérabilités internes authentifiées, telles que l’exigence les décrit, étaient techniquement impossibles. Le client a proposé un substitut en couches : des images immuables signées, reconstruites plutôt que corrigées, une analyse des images avant déploiement, une détection des menaces à l’exécution par le fournisseur cloud, des analyses au niveau réseau, et de l’infrastructure-as-code avec des contrôleurs d’admission pour que rien de non déclaré n’atteigne le cluster. Le tout rédigé dans une fiche formelle.
Nous l’avons accepté. La contrainte était réelle et technique, pas une préférence. Chaque élément du substitut était prouvé en fonctionnement, pas décrit. Et ensemble, ils répondaient à l’intention de l’exigence, qui est de savoir ce qui est vulnérable à l’intérieur, pas de lancer un type d’analyse en particulier. C’est la différence avec le cas du pare-feu ci-dessus : un substitut qui répond au but, avec des preuves, pour une contrainte que le client n’a pas choisie.
Accepté, avec une faiblesse résiduelle : le gardien à la porte
Un centre de données hébergeant un serveur de contrôle d’accès 3DS n’avait pas de sas à entrée individuelle, que le standard 3DS exige pour empêcher les entrées à la suite. Le client a proposé un gardien à la porte comme contrôle compensatoire.
Nous avons demandé qu’il soit documenté sur la fiche. Le mois suivant, nous avons proposé de le valider par une vérification inopinée de la présence du gardien, à toute heure. Un an plus tard, dans les notes du cycle suivant, nous demandions encore : comment le gardien vérifie-t-il les visiteurs par rapport à une liste d’accès à jour ? Que consigne-t-il ? Existe-t-il une procédure écrite, et une formation ? Y a-t-il des contrôles inopinés de sa prestation ?
Le contrôle a été accepté. Le gardien vérifiait les visiteurs par rapport à une liste à jour, le personnel devait être préautorisé, chaque visiteur était planifié à l’avance, et une procédure imprimée se trouvait au poste du gardien. Les contrôles inopinés formels du gardien n’ont jamais été mis en place. C’est la faiblesse résiduelle honnête, et elle est au dossier. Une personne est un contrôle plus faible qu’une porte, sauf si son travail laisse des traces, et un contrôle compensatoire doit être reprouvé chaque année. Il est accepté pour un cycle, pas pour toujours.
Ce que l’on fait de travers
On propose un contrôle pour une autre exigence et on l’appelle compensatoire. Le test est simple : le substitut répond-il au but de l’exigence qu’il remplace, ou à un but voisin ?
On rédige la fiche au lieu de corriger le contrôle. La plupart des constats coûtent moins cher à corriger qu’à compenser, et une fiche est revue chaque année tant qu’elle existe.
On prend l’acceptation pour définitive. Un contrôle compensatoire est accepté sur les preuves d’un cycle. L’année suivante, on le redemande.