L’authentification est rompue : voici comment les responsables de la sécurité peuvent y remédier

L’authentification continue de fonctionner là où elle compte le plus : sur les lignes de front réglementées telles que les soins de santé, le gouvernement, l’aérospatiale et les voyages. Le problème central n’est pas le manque d’innovation. Il s’agit plutôt d’un écosystème fragile et fragmenté de cartes, de lecteurs, de middleware et de logiciels qui fonctionnent rarement ensemble sous la pression du monde réel. Même les solutions « sans mot de passe » d’aujourd’hui peuvent être compromises par une mauvaise mise en œuvre, des rétrogradations et des voies de repli que les attaquants sont prompts à exploiter. Cet article examine où ces échecs se produisent, pourquoi ils persistent et propose un modèle pratique permettant aux RSSI de guider leurs organisations et leurs fournisseurs vers une authentification résiliente, résistante au phishing et prête pour le terrain.

Le problème : fragile de par sa conception

L’authentification est censée être le contrôle le plus fiable de votre pile de sécurité. Pourtant, dans de nombreuses entreprises, il s’agit souvent du plus fragile car il comporte trop d’éléments mobiles : types d’identifiants, lecteurs (avec contact, sans contact, double fréquence), protocoles, middleware, plates-formes d’identité et nuances du système d’exploitation des appareils. Toute inadéquation mineure, telle qu’un format d’identifiant inattendu, une bizarrerie de pilote, une nuance de navigateur ou un correctif précipité, peut rapidement transformer une connexion critique en une crise du centre de services. Il ne s’agit pas seulement d’un risque théorique ; c’est une réalité quotidienne pour les équipes opérationnelles qui doivent assurer le bon fonctionnement des unités de soins, des agents de terrain et des opérations en salle.

Aperçus du secteur : où ça casse (et pourquoi c’est important)

• Soins de santé. Les cliniciens ont besoin de rapidité et de tolérance zéro pour les temps d’arrêt. Un grand hôpital a tenté d’associer les informations d’identification HID SEOS avancées, qui utilisent des identifiants aléatoires préservant la confidentialité, avec une plate-forme SSO clinique qui attend des identifiants statiques pour la reconnaissance des utilisateurs. Cette inadéquation architecturale a obligé à choisir entre une confidentialité renforcée et des flux de travail fiables. Le projet est resté bloqué jusqu’à ce que l’équipe revienne à une technologie compatible avec les identifiants statiques. Dans le domaine des soins de santé, même un problème mineur peut rapidement dégénérer en incident de sécurité des patients.
• Gouvernement étatique et local. Les agences ont déployé des informations d’identification FIDO2 unifiées pour couvrir à la fois l’accès aux portes et les connexions aux ordinateurs portables. Cependant, ils ont vite découvert que de nombreux ordinateurs portables robustes n’incluaient pas l’antenne basse fréquence nécessaire à l’accès physique. Les équipes ont soit divisé les informations d’identification, ce qui allait à l’encontre de l’objectif, soit ajouté des lecteurs externes, ce qui a augmenté les coûts et la complexité. Les utilisateurs sur le terrain se sont retrouvés avec plusieurs badges et dongles sur eux, ce qui est à l’opposé de la résilience.
• Aérospatiale et voyages. Les organisations aérospatiales qui ont adopté des écosystèmes de cartes propriétaires, tels que LEGIC, ont été confrontées à des contraintes de licence qui limitaient le nombre de lecteurs qu’elles pouvaient acheter et la rapidité avec laquelle elles pouvaient se développer à l’échelle mondiale. Dans le secteur du voyage, le passage d’une compagnie de croisière aux identifiants sur bracelet a été confronté à des défis liés aux exigences FIPS 201, conçues pour les cartes plutôt que pour les appareils portables. Cela a contraint l’entreprise à adopter des solutions d’ingénierie personnalisées. Dans ces cas-là, l’innovation a progressé plus vite que les normes et les équipes opérationnelles ont dû en gérer les conséquences.

Causes profondes : pourquoi l’écosystème est bloqué

• Fragmentation à travers les couches. Des cartes comme SEOS, LEGIC, DESFire et FIDO2, mélangées à des lecteurs avec, sans contact et double fréquence et à des piles d’identité comme Imprivata, Windows Hello, Okta et Ping, interagissent rarement de manière propre. Un changement dans n’importe quelle couche peut déclencher des pannes inattendues dans l’ensemble du système.
• Déclassements et faiblesses de repli. L’authentification reste aussi forte que son chemin de sauvegarde le plus faible. Les attaques d’adversaires du milieu et de rétrogradation contournent régulièrement les flux résistants au phishing, comme le montrent les rapports du CSO sur les exploits de déclassement de clé d’accès FIDO et les attaques de fatigue MFA en cours. Ces lacunes réintroduisent discrètement des risques malgré les progrès modernes en matière d’authentification.
• Fragilité des patchs. Les mises à jour de la plateforme interrompent souvent les flux d’authentification, le CSO documentant les cas où les mises à jour Windows ont perturbé les connexions par carte à puce et Windows Hello for Business. Ces incidents, y compris ceux couverts par les mises à jour Microsoft, mettent hors d’état de fonctionner des fonctions clés de l’entreprise. Et les problèmes d’authentification de Windows Hello Entreprise montrent à quel point les piles d’authentification sont sensibles à la dérive de version.
• Enfermement vis-à-vis des fournisseurs et écarts en matière de normes. Les licences propriétaires et les SDK inégaux limitent la flexibilité et ralentissent les mises à niveau. Des progrès vers des profils d’interopérabilité apparaissent, mais uniquement lorsque les clients l’exigent. La norme IPSIE d’Okta en est un exemple, même si son adoption à grande échelle dépend toujours de la pression des acheteurs.

La voie à suivre : 3 changements architecturaux qui peuvent aider

Trois changements architecturaux peuvent améliorer considérablement la fiabilité et réduire les pannes inattendues. Ces approches ne s’excluent pas mutuellement et peuvent être combinées pour une efficacité maximale sur une seule plateforme.

1) Éléments sécurisés (SE) modulaires embarqués ou sous forme SIM

La cryptographie liée aux appareils, la résistance aux altérations, les états à très faible consommation et le contrôle OEM plus strict sur le micrologiciel et le BIOS améliorent tous la base de sécurité et de fiabilité. Ceci est particulièrement utile dans les environnements difficiles ou cliniques, où l’identité des appareils et la résilience hors ligne sont importantes. Les éléments sécurisés intégrés aident ici en supprimant la dépendance à l’égard de lecteurs externes et de pilotes instables, bien qu’ils introduisent leurs propres compromis tels que le verrouillage du fournisseur, la complexité accrue de la carte et du micrologiciel et le recours à des pièces spécialisées qui peuvent créer un autre défi d’intégration s’il n’existe aucun profil commun. Le moyen le plus efficace de les adopter est de commencer avec une flotte restreinte et de grande valeur, comme des chariots d’urgence, des superviseurs de terrain ou des tablettes de ligne de vol, en associant l’élément sécurisé à une image renforcée et signée et à une posture d’authentification prête à l’emploi hors ligne afin qu’il puisse servir de racine de confiance pour la connexion et les données au repos.

2) Standardisation du middleware (rendre la couche lecteur/identifiant enfichable)

Le middleware devient le pont universel qui atténue les bizarreries des cartes et des lecteurs, vous offrant un moyen stable d’intégrer des plateformes d’identité comme Entra, Okta, Ping ou Imprivata tout en normalisant les identifiants, en appliquant une logique anti-downgrade et en capturant chaque cas étrange pour une réponse rapide aux incidents. Il comporte ses propres obstacles, notamment une propriété floue, un travail d’intégration initial et des SDK concurrents. Pourtant, une fois en place, vous séparez le comportement d’authentification des particularités des appareils et des échanges de fournisseurs, ce qui constitue un gain majeur pour les opérations. La voie la plus propre consiste à mettre en place une couche d’abstraction des informations d’identification avec des politiques claires qui bloquent les solutions de repli héritées sur les applications à haut risque, appliquent des flux résistants au phishing et enregistrent toute décision de rétrogradation en tant qu’événements de sécurité envoyés au SOC, tout en appliquant également des contrôles de protection de session qui atténuent les attaques de l’adversaire au milieu.

3) Écosystème d’identification unifié (le « moment USB‑C » pour l’authentification)

Le comportement standard des lecteurs, des middlewares et des fournisseurs d’identité crée un environnement périphérique plus calme, réduisant ainsi les pannes surprises et les incendies de week-end qui suivent les cycles de correctifs. Le modèle n’est pas gratuit (il nécessite une coordination industrielle, des ponts existants et une gestion constante des changements), mais la direction est déjà tracée vers l’abstraction des informations d’identification avec une prise en charge multiprotocole et des intégrations de référence que les fournisseurs certifient ensemble. Le moyen le plus propre d’y parvenir consiste à passer par des exigences RFP qui exigent une gestion des informations d’identification multiprotocoles, une compatibilité vérifiée du lecteur et de l’IdP, un comportement anti-downgrade documenté et des runbooks clairs pour la gestion de la régression après les mises à jour du système d’exploitation ou de l’IdP, avec des paiements et des renouvellements directement liés au respect de ces normes.

Plan d’action RSSI : 5 mesures qui changent les résultats ce trimestre

1. Supprimez le maillon le plus faible : supprimez les solutions de secours silencieuses. Identifiez les endroits où les flux sans mot de passe reviennent toujours à des invites héritées telles que les SMS, la voix, l’OTP ou de simples demandes d’approbation. Sur les systèmes gérant de l’argent, des PHI ou des accès privilégiés, désactivez ou contrôlez étroitement ces chemins. Si une solution de repli est inévitable, exigez une vérification d’identité et alertez le SOC pour examen. Les chemins de rétrogradation et les attaques de fatigue MFA réussissent souvent parce que des sauvegardes faibles sont laissées en place, comme détaillé ici.
2. Exigez la transparence de la rétrogradation de vos outils. Exigez de votre IdP ou middleware qu’il consigne chaque événement de rétrogradation et bloque l’usurpation d’identité de navigateur ou d’agent par script qui conduit les utilisateurs vers de faux flux de « navigateur non pris en charge ». Les contournements de rétrogradation dans les flux de clé d’accès et FIDO ont été démontrés dans la nature, votre pile doit donc rendre ces tentatives faciles à détecter et simples à arrêter. Un exemple clair est présenté ici.
3. Renforcez-vous pour les turbulences des patchs (supposons des régressions d’authentification). Créez un gant d’intégration de pré-production qui teste les cartes à puce, les clés d’accès, la confiance des clés Windows Hello et vos flux SSO cliniques ou sur le terrain. Maintenez un déploiement à grande échelle jusqu’à ce que le défi soit passé et conservez une restauration en un clic et un script de communication prêt à envoyer. Les mises à jour récentes de Windows ont montré à quelle vitesse l’authentification peut être interrompue à grande échelle, alors créez des playbooks de mémoire musculaire avant le Patch Tuesday. Les exemples incluent
4. Écrivez l’interopérabilité dans les contrats. Les appels d’offres doivent faire état de l’abstraction des informations d’identification multiprotocoles, des paires de lecteurs certifiés et d’IdP, de la prise en charge de FIDO2 et des clés d’accès sans replis non sécurisés et de l’alignement avec les profils d’interopérabilité émergents. Les fournisseurs s’orientent déjà dans cette direction et la norme IPSIE d’Okta est un exemple qui mérite d’être cité.
5. Choisissez le bon pilote : contraint, de grande valeur et visible. Commencez là où les temps d’arrêt sont coûteux et où les utilisateurs sont déjà formés, comme dans les stations de soins intensifs, les opérations côté piste ou les bureaux des recettes. Associez des appareils à éléments sécurisés intégrés à un middleware indépendant du lecteur et à des politiques anti-downgrade strictes. Suivez le MTTR pour les incidents d’authentification, la fréquence des rétrogradations et le volume du service d’assistance, puis publiez les résultats pour justifier un déploiement plus large.

La vision à long terme : la résilience face à la mode

Les clés d’accès et FIDO2 font avancer l’authentification dans la bonne direction lorsqu’ils sont déployés sans solutions de repli poreuses et avec des intégrations qui se comportent de manière cohérente sous pression. Leurs avantages en matière de sécurité et de convivialité sont clairs, mais leur utilisation dans le monde réel a également montré à quel point les techniques d’adversaire du milieu et les chemins de sauvegarde faibles peuvent compromettre ces gains. Ces problèmes ne sont pas des raisons de ralentir l’adoption mais des rappels pour aborder la mise en œuvre avec discipline.

Pour créer une authentification qui reste stable même à mesure que les systèmes évoluent, nous avons besoin d’interopérabilité, d’un comportement anti-downgrade par défaut et de modes de défaillance progressifs. Cela signifie utiliser du matériel modulaire là où il convient, s’appuyer sur un middleware indépendant du lecteur avec une politique applicable et promouvoir une expérience d’identification unifiée que les fournisseurs certifient et sur laquelle les clients insistent. Les composants existent aujourd’hui ; ce qui manque, c’est la détermination de les relier ensemble.

N’investissez pas dans une autre solution ponctuelle tant que vos contrats, runbooks et pilotes ne reflètent pas ces principes. L’authentification doit être la partie la plus calme et la plus prévisible de votre pile, et non la source de votre prochain incident. Les éléments constitutifs d’une authentification résiliente et interopérable existent déjà. Ce qui manque, c’est la détermination. Il est désormais temps pour les responsables de la sécurité d’établir la norme et d’exiger mieux. Faites en sorte que l’authentification fonctionne pour vous, pas contre vous.

Cet article est publié dans le cadre du Foundry Expert Contributor Network.
Voulez-vous nous rejoindre ?