Face à un zero-day, la posture habituelle consiste à raccourcir le délai de correction. C'est nécessaire, mais cela laisse entière la fenêtre où la faille est connue de l'attaquant et de personne d'autre. Une autre voie existe, complémentaire : agir non pas sur l'existence de la faille, mais sur la fiabilité de son exploitation. Un exploit qui ne fonctionne qu'une fois sur un grand nombre de tentatives cesse d'être une arme industrialisable.
Un zero-day utile est un exploit fiable
Une vulnérabilité n'est pas une attaque. Entre les deux, il faut une chaîne d'exploitation qui suppose de la prédictibilité : connaître la disposition mémoire, l'ordre des opérations, les versions déployées, le comportement attendu du système à chaque étape.
C'est pourquoi les protections système efficaces des vingt dernières années — randomisation des adresses, protections d'exécution, cloisonnement — n'éliminent aucune vulnérabilité. Elles rendent l'exploitation incertaine, ce qui suffit à faire chuter la valeur d'un exploit.
Le polymorphisme fonctionnel applique la même philosophie à la chaîne d'authentification : si l'exécution n'est pas identique d'une fois à l'autre, l'attaquant ne peut pas s'appuyer sur une observation antérieure pour construire une exploitation reproductible.
La fenêtre d'exposition, mesurée honnêtement
| Phase | Ce qui se passe | Ce qui protège |
|---|---|---|
| Avant divulgation | seul l'attaquant connaît la faille | rien de spécifique ; seule la difficulté d'exploitation compte |
| Divulgation | l'éditeur publie un correctif | rapidité de détection et de communication |
| Correction | déploiement dans le parc | maturité du processus de mise à jour |
| Après correction | exploitation des systèmes non corrigés | inventaire réel, y compris systèmes oubliés |
La première ligne est celle qui compte pour ce sujet, et c'est la seule où le processus de mise à jour ne peut rien. La question devient : que reste-t-il quand aucun correctif n'existe ?
La réponse tient en deux mots : défense en profondeur et incertitude. Un attaquant disposant d'une faille sur un composant doit encore franchir ce qui vient après. Si ce qui vient après est une validation reposant sur une méthode de résolution qui n'existe nulle part dans le système compromis, l'exploitation technique ne suffit pas à exécuter l'opération visée.
Trois lignes de défense qui ne dépendent pas du correctif
- L'incertitude d'exécution. Le Moving Target Defense et le polymorphisme fonctionnel visent à rendre le comportement non reproductible d'une exécution à l'autre. Un exploit calibré sur une observation devient peu fiable.
- L'absence de butin centralisé. Une architecture décentralisée, sans donnée identifiante détenue par l'éditeur et avec une biométrie traitée localement, limite ce qu'une compromission d'un composant central permettrait d'obtenir. On réduit l'impact, pas la probabilité.
- La preuve d'intention au moment de l'action. Compromettre un système peut ouvrir une session ; cela ne fournit pas la capacité de résoudre un challenge cognitif. Les opérations à fort impact restent conditionnées à un acte humain conscient.
Ces trois lignes ne remplacent pas la gestion des vulnérabilités. Elles déterminent ce qu'il advient quand celle-ci arrive en retard — ce qui, par définition, est le cas pour un zero-day.
Le cadre réglementaire pousse dans le même sens
Le Cyber Resilience Act (règlement UE 2024/2847), en vigueur depuis fin 2024 avec des obligations principales à horizon fin 2027, formalise deux exigences directement liées : la sécurité dès la conception sur l'ensemble du cycle de vie, et l'interdiction des mots de passe par défaut. La logique sous-jacente est celle de la résilience : on ne demande pas l'absence de vulnérabilité, on demande une conception qui limite ce qu'une vulnérabilité permet.
NIS2 (directive UE 2022/2555) et DORA (règlement UE 2022/2554, applicable depuis janvier 2025) raisonnent de même : la gestion des incidents et la continuité y occupent autant de place que la prévention.
Ce que cela ne dispense pas de faire
Il serait malhonnête de présenter une exécution mouvante comme une alternative à l'hygiène de base.
- Maintenir un inventaire réel. Les compromissions durables reposent le plus souvent sur des systèmes oubliés, pas sur des zero-day.
- Corriger vite. La très grande majorité des exploitations observées visent des vulnérabilités connues et corrigées depuis longtemps.
- Cloisonner. Le facteur cognitif protège une décision ; il ne remplace pas une segmentation réseau ni une gestion des droits.
- Savoir révoquer. Sessions, jetons, clés d'interface : la capacité de coupure conditionne la réponse à incident.
FAQ
Le polymorphisme empêche-t-il l'exploitation d'une faille ?
Non, et le prétendre serait faux. Il vise à réduire la fiabilité et la reproductibilité d'une exploitation, ce qui rend l'industrialisation plus difficile et laisse davantage de chances aux autres lignes de défense.
Pourquoi parler de zero-day dans un contexte d'authentification ?
Parce que la chaîne d'authentification est un composant logiciel comme un autre, et parce qu'elle constitue une cible de choix : la compromettre donne accès à tout ce qu'elle protège.
Comment évaluer ce point chez un fournisseur ?
En posant deux questions concrètes : que permet la compromission d'un de vos composants centraux ? Et quelles opérations restent impossibles à exécuter sans intervention humaine consciente ?
Une solution hébergée en France change-t-elle quelque chose ?
Sur la fenêtre d'exposition, non. Sur la gouvernance de l'incident — délais de notification, accès aux journaux, absence d'exposition à des injonctions extraterritoriales — oui. Ce sont deux sujets distincts qu'il vaut mieux ne pas confondre.
Aller plus loin : le principe du 4ᵉ facteur · le polymorphisme face au brute force · le Cyber Resilience Act et l'authentification · l'architecture décentralisée face au phishing