Chaque mission que nous avons menée, PCI ou non, a buté au moins une fois sur la même question. Pas « ce contrôle est-il en place ? » mais « qu’est-ce que ce contrôle est censé couvrir ? ». En voici trois.
Un industriel sans inventaire
Un groupe industriel de plus de vingt usines nous a demandé de piloter son programme de sécurité. La première chose que nous avons demandée : la liste de ce qui était sur le réseau. Il n’y en avait pas. Chaque site appliquait ses correctifs à sa manière, surtout sous Windows, et la preuve que les correctifs étaient appliqués était décrite dans un dossier de direction comme « des données informelles du personnel informatique ».
On ne protège pas ce que l’on ne sait pas compter. La première étape mesurable du programme n’a été ni un pare-feu ni une plateforme de détection. Ce furent neuf cents agents sur seize sites, pour que quelqu’un puisse enfin dire combien il y avait de machines et combien de vulnérabilités sur chacune. La réponse, quelques mois plus tard : environ deux cents par poste de travail en moyenne. Désagréable, mais enfin un chiffre qui pouvait baisser.
Un processeur dont les documents de périmètre se contredisaient
Un processeur de paiement par carte a abordé sa première évaluation 3DS comme une extension de sa conformité PCI DSS. Organisation mûre, système de management de la sécurité conséquent : la partie 3DS devait être une formalité.
Le premier jour, il n’existait aucune définition formelle de l’environnement 3DS. La liste des logiciels critiques n’incluait pas les principales applications 3DS. Deux documents de périmètre se contredisaient sur le système d’exploitation des serveurs cryptographiques : AIX pour l’un, Linux pour l’autre. Le tiers qui exploitait le centre de données avait des responsabilités que personne n’avait écrites.
Rien de tout cela n’était une faiblesse de sécurité en soi. Tout cela a bloqué l’évaluation, parce qu’un évaluateur ne peut pas dire qu’un contrôle est en place pour un environnement que personne n’a défini. Sur les quarante et une exigences encore ouvertes après les journées sur site, la plupart relevaient du périmètre, de la documentation et des responsabilités. La technique, elle, tenait.
Une banque dont le périmètre dépendait d’une seule décision
Une banque en ligne accédait au réseau SWIFT par un bureau de service, pas par sa propre infrastructure. Son évaluation selon le cadre de sécurité client de SWIFT dépendait entièrement d’une décision prise tôt : quel type d’architecture était-elle ? Choisissez le mauvais et vous évaluez les mauvais contrôles.
La bonne réponse était le type sans empreinte locale, ce qui ramenait le périmètre à une seule machine virtuelle d’opérateur, accessible par VPN, et aux personnes qui l’utilisaient. Une fois cela établi, l’évaluation a pris deux jours. Deux des quinze contrôles obligatoires n’étaient pas en place, tous deux sur cette machine : elle pouvait naviguer librement sur Internet, et personne ne relisait ses journaux. Si le type d’architecture avait été choisi à la légère, aucun des deux n’aurait été regardé.
Ce que l’on fait de travers
On commence par les contrôles. Scanners, politiques, authentification multifacteur, journalisation. Les contrôles sont satisfaisants parce qu’on peut les acheter et les montrer. Mais un contrôle appliqué à un environnement non défini ne prouve rien, et un évaluateur le dira.
On suppose que l’inventaire existe parce que quelqu’un doit bien en avoir un. Demandez à le voir. Demandez sa date. Demandez qui en est responsable. D’après notre expérience, la réponse honnête est souvent un tableur tenu par une seule personne, mis à jour pour la dernière fois avant une réorganisation.
On traite le périmètre comme une formalité PCI plutôt que comme un fait d’ingénierie. Le périmètre, c’est la liste de ce qui peut vous faire mal. C’est la même liste, que le lecteur soit un QSA, un opérateur de ransomware ou l’équipe sécurité de votre plus grand client.
Le périmètre, c’est la liste de ce qui peut vous faire mal.