Nous avons conçu un logiciel pour retirer la corvée de la conformité, et nous l’utilisons sur chaque mission, donc nous ne sommes pas contre l’automatisation. Nous sommes contre l’affirmation qui l’accompagne souvent : que l’automatisation rend l’évaluation, ou l’évaluateur, inutile. Voici où elle aide vraiment, et où elle n’aide pas.
Là où elle aide
Produire des traces datées à intervalles réguliers. L’évaluation repose sur la preuve qu’un contrôle a fonctionné pendant toute la période. Un export de configuration pris le premier de chaque mois, par une tâche, avec un horodatage, est une meilleure preuve que le même export pris à la main la semaine précédant l’évaluation. Listes d’accès, règles de pare-feu, état des correctifs, résultats d’analyses, sorties de revue des journaux : tout ce qui peut être exporté à intervalles réguliers devrait l’être.
Remarquer la dérive. Un mécanisme qui compare l’état réel à l’état voulu et prévient quelqu’un quand ils diffèrent est ce que les exigences de détection des changements demandent réellement. Notez la différence avec l’infrastructure-as-code : les modèles définissent l’état voulu, et ne prouvent rien de l’état réel. Une détection de dérive avec une alerte et une trace de revue est une preuve. Les modèles seuls sont une description.
Revoir les journaux à grande échelle. La revue quotidienne des journaux est une exigence que personne ne satisfait à la main sur un grand parc. Une alerte qui produit un ticket, et une trace que le ticket a été traité, est la forme réaliste du contrôle.
Lier les preuves aux exigences. Un export sert quatre exigences. Un système qui conserve le lien, pour que l’élément soit demandé une fois et retrouvé quatre fois, fait gagner plus de temps d’évaluation que n’importe quelle autre chose.
Là où elle n’aide pas
Juger de l’adéquation. Un outil peut vous dire que l’authentification multifacteur est configurée sur le VPN. Il ne peut pas vous dire que l’API d’administration n’a pas ce contrôle et est accessible depuis le réseau bureautique. C’est une question de périmètre et d’architecture, à laquelle répond quelqu’un qui comprend l’environnement.
L’observation. Quatre personnes franchissant un sas à entrée unique avec quatre badges. Un accueil décrit comme tenu en permanence, sans personne. Une documentation de sauvegarde qui décrit une infrastructure reconstruite depuis. Aucun outil ne voit cela. Un évaluateur dans le bâtiment, si.
Lire les documents pour ce qu’ils ne disent pas. L’attestation d’un prestataire qui liste tous les sites sauf le vôtre. Un document de périmètre qui met le coffre de clés hors périmètre. Les lire correctement, c’est le métier.
L’interprétation. Là où le standard laisse de la marge, un outil choisit une lecture et la cache. Un évaluateur montre le raisonnement.
L’affirmation dont il faut se méfier
Certaines plateformes de conformité disent, ou laissent entendre, que leur tableau de bord est l’évaluation. Ce n’est pas le cas. Pour un Report on Compliance, le Council exige un Qualified Security Assessor, et aucun éditeur d’automatisation n’en est un. Pour une auto-évaluation, le questionnaire demande toujours si les contrôles sont en place dans votre environnement, et un tableau de bord au vert pour les systèmes auxquels il est connecté ne dit rien de ceux auxquels il ne l’est pas. L’automatisation est la couche des preuves. Le jugement reste celui d’une personne, et la signature celle d’un QSA.
L’automatisation est la couche des preuves. Le jugement reste celui d’une personne, et la signature celle d’un QSA.
Ce que l’on fait de travers
On automatise la collecte et l’on saute la revue, si bien que les traces s’empilent sans que personne ne les lise, ce qui est en soi un constat. On prend un modèle pour un contrôle. On achète une plateforme et l’on suppose que le périmètre est ce qu’elle surveille.