Voici une habitude que nous observons davantage dans les bonnes équipes d’ingénierie que dans les mauvaises. Elles achètent ou construisent une technologie capable, puis décrivent la technologie comme si elle était le résultat. Trois exemples, chacun chez un client techniquement solide.
Un jeton signé n’est pas une possession
Une banque en ligne a lancé une API pour les entreprises : données de compte, virements, webhooks. Chaque requête portait un jeton signé avec la clé privée du client, liée à un certificat que l’autorité de la banque avait émis à l’enrôlement, plus un secret partagé et une empreinte de la requête. L’enrôlement lui-même exigeait la double authentification de l’application mobile. De la bonne cryptographie, faite avec soin.
La question de la banque, par écrit : est-ce une authentification forte du client au sens de la DSP2 ? La réponse a pris trois versions et une lecture serrée des normes techniques de réglementation, et c’était non. La connaissance était satisfaite, par le secret d’enrôlement. L’indépendance des facteurs était satisfaite. La possession ne l’était pas. Un fichier de clé privée se copie librement, et une liste d’adresses IP autorisées ne le lie pas à une personne. La réglementation met le devoir d’empêcher la copie à la charge de la banque, pas du client. Il n’y avait pas non plus de lien dynamique avec le montant et le bénéficiaire.
La conception était comparable aux protocoles dédiés aux entreprises que le régulateur accepte au titre de l’exemption pour les utilisateurs professionnels, et c’est là qu’elle a atterri. Mais « comparable à un protocole exempté » est une phrase très différente d’« authentification forte du client », et il aurait coûté moins cher de savoir laquelle on construisait avant le lancement.
Un scanner n’est pas une gestion des vulnérabilités
Un groupe industriel de vingt usines a acheté un scanner de vulnérabilités après une année d’intrusions. La preuve de concept a déployé neuf cents agents sur seize sites et produit, pour la première fois, un décompte. Plusieurs des politiques de référence que nous avons examinées pour des sociétés de paiement font la même distinction, et c’est la bonne : l’analyse est un outil, la gestion des vulnérabilités est un processus avec des responsables, une analyse de risque et des échéances.
Le scanner a dit au groupe qu’il avait environ deux cents vulnérabilités par poste de travail. Il n’a dit à personne qui était responsable de faire baisser ce chiffre, pour quand, ni ce qui se passait quand un site manquait l’échéance. Tout cela a été écrit ensuite : une politique de groupe, des délais par criticité, un processus d’exception avec des contrôles compensatoires. Le tableau de bord du scanner avait le même aspect avant et après. Le contrôle n’a existé qu’après.
Le tableau de bord du scanner avait le même aspect avant et après. Le contrôle n’a existé qu’après.
Un pare-feu applicatif n’est pas un site corrigé
Le site institutionnel du même groupe, sur un système de gestion de contenu en retard de plusieurs versions, avait été discrètement transformé en relais de retransmissions sportives piratées. Une recherche sur le nom de la société affichait « ce site est peut-être piraté » à côté du résultat. L’agence web a proposé dix jours de travail sans engagement de résultat. Une seconde agence a constaté que la mise à niveau casserait le site.
Un pare-feu applicatif a donc été placé devant. Il a arrêté l’abus. C’était aussi, et tout le monde le savait, une façon de ne pas corriger le site. Un pare-feu devant un logiciel non corrigé est un contrôle contre les attaques qu’il connaît, tant que quelqu’un l’entretient. La vulnérabilité est toujours là, et la leçon aussi : le site marketing n’avait aucun responsable côté sécurité, et le DNS était chez un troisième prestataire qui mettait des jours à faire une modification.
Ce que l’on fait de travers
On laisse l’outil nommer le contrôle. « Nous avons la MFA » signifie qu’un produit est installé, pas que chaque chemin vers l’environnement passe par lui. « Nous avons un SIEM » signifie que les journaux sont collectés, pas que quelqu’un les lit. Le processeur que nous avons évalué pour 3DS avait une politique de sécurité de contenu sur ses pages. Elle autorisait les scripts en ligne, ce qui retire l’essentiel de son intérêt.
On évalue la technologie au lieu de l’affirmation. La cryptographie de la banque était saine. La question n’a jamais été « est-ce sécurisé ? » mais « cela répond-il à une définition réglementaire précise ? », et on n’y répond pas de la même façon.