Trois phrases, issues de trois missions, qui semblaient chacune raisonnable au moment où elle a été prononcée.
« L’informatique dit que c’est corrigé. » Le dossier de direction d’un groupe industriel, décrivant la preuve que vingt usines appliquaient leurs mises à jour de sécurité.
Une capture d’écran de la page de garde d’un document, envoyée par un processeur de paiement par carte comme preuve qu’une revue avait lieu chaque trimestre.
« Nous pouvons considérer qu’aucune donnée n’a été affectée. » La première lettre d’un industriel à ses clients, deux jours après le début d’un incident de ransomware, avant toute analyse.
Aucune n’était un mensonge. Toutes trois étaient des affirmations, et toutes trois ont cédé dès que quelqu’un ayant une raison de vérifier a demandé la preuve.
Qui demande, et quoi
Un QSA demande des preuves parce que le standard fait de l’évaluateur celui qui voit le contrôle fonctionner, pas celui qui s’entend dire qu’il fonctionne. La règle que nous avons écrite dans les notes de post-évaluation d’un processeur, et que nous assumons : si nous n’avons pas pu examiner la preuve, l’exigence n’est pas en place. Pas « probablement en place », pas « en place sous réserve de documentation ». Pas en place.
Un client demande des preuves parce que votre incident est devenu son risque. Après l’attaque, les plus grands clients du groupe ont envoyé des variantes des mêmes cinq questions. Nos données sur vos systèmes ont-elles été touchées ? Par où l’intrusion est-elle entrée, et quels contrôles ont échoué ? Qui était le patient zéro ? Quel logiciel malveillant, et envoyez-nous les indicateurs. Et donnez-nous l’attestation d’un tiers que votre environnement est sain. Aucune de ces questions n’admet une réponse rassurante. Chacune exige une date, une empreinte de fichier, un schéma ou une signature.
Un régulateur demande des preuves parce qu’il doit défendre sa propre décision de vous laisser opérer. Une société de paiement qui se prépare à l’examen de son régulateur bancaire n’a pas besoin de quarante politiques. Elle a besoin des politiques qu’elle peut prouver suivre, et d’une trace de chacune suivie.
Ce que l’on fait de travers
On confond existence et fonctionnement. Une politique de correctifs existe. Une procédure de revue existe. La question est de savoir si elle a tourné le trimestre dernier, qui l’a fait tourner et ce qui en est sorti. Un seul compte rendu de revue est un échantillon de un. La récurrence se montre par plusieurs traces datées, idéalement avec quelque chose de différent dans chacune, parce qu’un compte rendu identique chaque trimestre est une preuve d’un autre genre.
On confond confiance et faits. La première lettre aux clients avait été écrite pour rassurer. Elle a fait l’inverse, parce que lorsque le rapport d’analyse est arrivé quelques semaines plus tard, il contredisait la lettre, et le client tenait désormais deux documents de la même société qui ne disaient pas la même chose. Le silence, ou « nous ne savons pas encore et voici quand nous saurons », aurait coûté moins cher.
On envoie la preuve de la mauvaise chose. Une page de garde prouve qu’un document existe. Une capture de tableau de bord prouve qu’un outil était ouvert. Ni l’une ni l’autre ne prouve que le contrôle a fait ce que l’exigence dit, sur les systèmes du périmètre, pendant la période évaluée.
Une page de garde prouve qu’un document existe. Une capture de tableau de bord prouve qu’un outil était ouvert.