Afin d’accompagner cette évolution, l’Union européenne avait instauré la Directive sur les Services de Paiement. Dans sa deuxième version (DSP2), publiée en 2015, cette directive a voulu la création et la régulation du secteur de l’Open Banking. L’objectif était de permettre aux utilisateurs de laisser un accès à leurs données bancaires à de nouveaux acteurs innovants tels que les initiateurs de paiement et les agrégateurs, tout en favorisant la sécurité et la compétition au sein de l’écosystème des services de paiement.

Malheureusement, la DSP2 présente des limites dont :

• Un problème d’harmonisation des législations conduisant au « forum shopping » qui consiste, pour les fournisseurs de services de paiement, à choisir leur pays d’installation en fonction de la législation locale la plus arrangeante à leur égard.
• Un écart qui n’a pas été suffisamment comblé entre les banques, qui sont en position privilégiée pour fournir des services aux consommateurs, et les prestataires de services de paiement qui en dépendent.
• La fraude, pour laquelle les méthodes employées évoluent rapidement, et pour laquelle les provisions de DSP2 sont maintenant insuffisantes.

C’est pour cela que l’Union Européenne a publié un projet de DSP3 le 28 juin 2023, et une version finale est attendue pour fin 2024 ou début 2025. Le texte sera alors applicable 18 mois après la publication, soit aux alentours du troisième trimestre 2026.

Comment uniformiser l’existant de la DSP2 ?

A la lecture de cette ébauche, il est clair que là où la DSP2 a instauré des concepts structurants et complètement nouveaux comme l’Open Banking ou l’Authentification Forte du Client, la DSP3 cherche à apporter une mise à niveau sur des concepts existants. Comme indiqué sur le site de la commission européenne, il s’agit d’

« une évolution, pas une révolution ».

La forme évolue : la DSP3 s’accompagne d’un règlement, le RSP (Règlement sur les Services de Paiement). Dans son contenu, elle reprend beaucoup d’éléments présents dans la DSP2, ou ses RTS (pour Regulatory Technical Standards ou Normes Techniques de Règlementation). La nouveauté vient du format : il s’agit d’un règlement, qui est donc directement applicable dans les états membres, au contraire des directives qui ont besoin d’être traduites en droit local. Il s’agit d’une des solutions que l’UE considère pour aborder le problème d’harmonisation mentionné précédemment.

Le cadre réglementaire des monnaies électroniques se retrouve aussi simplifié. Les difficultés pratiques liées à la différenciation existante entre les paiements en ligne, réglementés par DSP2, et l’utilisation de monnaies électroniques, réglementée par la Directive sur les Monnaies Electroniques de 2009 (DME) disparaissent puisque DSP3 couvre maintenant ces deux types de services.

En outre, bien qu’il ne s’agisse pas de nouveautés à proprement parler, DSP3 apporte un lot de clarifications dans ses définitions :

• Les comptes de dépôt, tels que les livrets, sont explicitement exclus de la définition de comptes de paiements.
• Les agrégateurs sont définis par leur capacité à collecter et consolider de l’information sur les comptes de paiement, et ce même si l’utilisateur détenteur des comptes n’est pas le destinataire de l’information agrégée.
• Les authentifications multi-facteurs reposent sur deux facteurs dans les catégories classiquement définies (ce que je sais, ce que je suis, ce que je possède), mais il n’est pas nécessaire que les deux facteurs soient de catégories différentes, seulement qu’ils soient indépendants (défini comme : la compromission de l’un n’affecte pas le niveau de sécurité de l’autre).

Que devront faire les différents fournisseurs de services de paiement pour se conformer à la DSP3 ?

Les évolutions phares de la DSP3 portent sur des changements techniques visant protéger le consommateur contre la fraude.

Ainsi, les prestataires de services de paiement vont devoir proposer de nouveaux services. Un premier exemple consiste à fournir à l’utilisateur un tableau de bord de permissions permettant de vérifier à tout moment qui est autorisé à accéder aux données des comptes de paiement. Un autre exemple est le service de vérification du nom du détenteur du compte bénéficiaire d’un paiement, visant à informer l’utilisateur d’une éventuelle usurpation d’identité.

De même, la DSP3 s’intéresse à l’accessibilité pour tous de l’authentification forte. Toutes les banques devront avoir la capacité de fournir un moyen d’authentification adapté à tous leurs utilisateurs, y compris les personnes en situation d’handicap, les personnes âgées, les personnes ayant des faibles compétences numériques ou sans smartphone etc…

L’ajout d’un nouvel acteur en particulier va changer la répartition des responsabilités de conformité : il s’agit des prestataires de services techniques. Ces derniers hériteront d’une partie de la charge de mise en conformité et d’audit, en particulier pour ce qui touche à l’authentification forte du client, lorsque celle-ci est gérée par une solution tierce.

Quels seront les impacts de ces changements ?

Les banques et autres prestataires de paiement sont incités par les changements de la DSP3 à s’échanger des informations pour lutter contre la fraude : des dispositions sont d’ailleurs prévues pour pouvoir le faire dans le respect de la RGPD.

En particulier pour la vérification du nom du détenteur du compte bénéficiaire, cela signifie que les APIs d’Open Banking devront être mises à jour pour pouvoir permettre cette vérification par la banque du payeur. A cause de la complexité de cette opération, à plus forte raison pour les paiements instantanés, l’article associé entrera en vigueur 2 ans après le reste (donc pas avant le troisième trimestre 2028).

Les utilisateurs vont aussi voir apparaitre de nouvelles fonctionnalités, et un temps d’adaptation sera nécessaire pour qu’ils se familiarisent avec ces nouveautés. Un accompagnement devra être mis en place afin de faciliter la compréhension et favoriser l’adoption de ces nouvelles fonctionnalités.

Si le texte final est publié début 2025, les entreprises du secteur des paiements auront jusqu’au troisième trimestre 2026 pour se mettre en conformité.

Il est essentiel de prendre en compte ces changements dès aujourd’hui et d’assurer une veille réglementaire pour se tenir informé des différents textes (RTS, guidelines) qui seront publiés à la fois par la commission européenne et l’Autorité Bancaire Européenne.

[1] Rapport annuel de l’Observatoire de la sécurité des moyens de paiement 2023

Cet article Transition vers la 3e Directive sur les Services de Paiements : quels impacts ? est apparu en premier sur RiskInsight.

Cette tendance s’explique par une volonté de digitalisation des usines et de développement de l’industrie connectée, qui ne s’est que rarement accompagnée d’une modernisation des systèmes industriels associés : les attaques sont rendues plus simples, leurs conséquences plus fortes. Et dans le cas des ransomwares, un défaut d’authentification est souvent le point de départ de la kill-chain : trop faible ou reposant sur des facteurs d’authentification partagés entre opérateurs, les comptes en deviennent sensibles aux attaques par phishing.

Ce constat peut d’ailleurs être retrouvé en analysant les « Fiches incidents Cyber SI industriel »^[2]  partagées par le Clusif. On retrouve parmi elles la prise de contrôle du système de production d’une aciérie allemande, qui aurait pu être évitée si un second facteur d’authentification avait été requis lors de l’exécution d’actions critiques sur le site industriel.

Dès lors, le besoin de sécurisation et de modernisation des méthodes d’authentification des populations dites cols bleus apparait comme crucial, afin de limiter les risques de vols de ces comptes souvent mal protégés sans impacter négativement la productivité globale des opérateurs sur site.

Cet article vise donc, après être revenu plus en détail sur le contexte actuel et sur les contraintes liées à ces populations, à comparer les différentes solutions disponibles aujourd’hui pour ces usages, à analyser les freins à la démocratisation des méthodes jugées les plus prometteuses, et à partager notre vision et recommandations pour rattraper au mieux le retard observé.

Qu’est-ce que l’authentification ?

S’authentifier consiste à certifier son identité auprès d’un système informatique avant de pouvoir accéder à des ressources sécurisées. Tout au long de cet article, nous parlerons d’authentification multifacteur lorsqu’au moins deux facteurs d’authentification parmi les quatre ci-dessous sont combinés :

• Ce que je sais (mot de passe, code PIN, schéma, …)
• Ce que je possède (appareil personnel, clé USB, carte à puce, badge, …)
• Ce que je suis (reconnaissance faciale, empreinte digitale, réseau veineux, …)
• Ce que je fais (mouvement des yeux, signature, dynamique de frappe, …)

Note : le niveau de sécurité dépend de la robustesse des facteurs et de leur indépendance en cas de combinaison^[3] 

Les cols bleus : des cas d’usages diversifiés…

Quand on parle de population col bleu, on entend tous les travailleurs manuels, ne disposant pas de leur propre poste de travail professionnel (e.g. métiers de la mécanique, de l’industrie, de l’aide à la personne). Ces populations rencontrent des cas d’usages d’authentification différentes des populations dites cols blancs, car utilisant la majorité du temps un SI bureautique avec des appareils multiples et partagés entre différents collaborateurs :

• Postes mobiles et tablettes (accès aux logiciels de pilotage de production (MES), …)
• Postes fixe de contrôle (pilotage des machines-outils, gestion, …)
• Postes bureautiques partagés (pointage, formation, …)

Les opérateurs doivent donc pouvoir s’authentifier sur des postes de pilotage, par exemple directement reliés aux machines-outils à l’aide d’une carte réseau, mais aussi indépendamment de leur situation au sein du site sur des postes mobiles.

… Avec des contraintes multiples

Dans le but d’évaluer au mieux les différentes solutions d’authentification envisageables pour les cols bleus, il est important d’avoir à l’esprit les contraintes professionnelles qui leur sont propres.

Ces dernières se déclinent en trois volets principaux :

• Contraintes de rythme:  travailler sous cadence automatique et respecter des normes de production empêche l’utilisation de processus longs ou intempestifs
• Contraintes liées au port d’EPI (équipement de protection individuelle) tels que des gants ou un masque : ils peuvent empêcher l’utilisation de certains facteurs biométriques (reconnaissance faciale, empreinte digitale, …) ou rendre l’usage de mot de passe peu ergonomique (utilisation de gants sur écran tactile ou clavier)
• Contraintes liées à la régularité des changements de poste: changer régulièrement de poste implique de devoir s’authentifier quotidiennement plusieurs fois sur différents postes. De plus, si cette authentification est locale, l’enrôlement préalable devra être fait pour chacun d’entre eux

Au-delà des contraintes cols bleus, des éléments sont également à prendre en compte d’un point de vue employeur.

Nous retrouvons également trois thèmes principaux, à savoir :

• Un enjeu important d’uniformité: tous les collaborateurs devraient pouvoir s’authentifier de la même manière sur toutes les machines et logiciels afin d’avoir une expérience utilisateur commune, un unique processus, support et une seule documentation
• Un investissement non négligeable: une solution d’authentification est coûteuse à acquérir (e.g. badges, bracelets, capteurs) mais aussi à entretenir (e.g. support & serveurs). Ces couts pourront être difficiles à justifier si les employés n’ont pas besoin d’accéder à des ressources sensibles
• Une sécurité physique déjà présente: l’ajout d’un second facteur ou le durcissement du premier peut paraître inutile pour les entreprises qui sécurisent déjà physiquement leurs sites, et supposent donc qu’un individu ayant un accès physique à l’appareil sera digne de confiance

Quelles sont les méthodes d’authentification présentes sur le marché ?

Deux grandes catégories se distinguent :

• Des acteurs « matures », proposant une authentification multifacteur avec un badge couplé à un mot de passe ou à un code PIN stocké localement. Ce choix permet la fusion des accès physiques et logiques, en autorisant par exemple l’accès aux appareils contrôlant les chaines de production via badges d’accès intégrant le standard FIDO2
• Des acteurs qui le sont moins, conservant une authentification faible avec uniquement l’utilisation de mots de passe. Ils restent majoritaires, et les comptes utilisés sont souvent génériques afin de maximiser la rapidité de l’authentification, et donc la productivité

Quelles méthodes d’authentification pour répondre à ces enjeux ?

Plusieurs critères à prendre en considération…

Dans le but de comparer les différentes méthodes envisageables, six critères ont été considérés, avec un accent particulier sur deux enjeux principaux : l’expérience utilisateur et la sécurité.

… afin d’identifier les méthodes d’authentification les plus pertinentes

Sur la base de ces critères, les méthodes d’authentification considérées pertinentes et viables pour les cols bleus peuvent être distribuées comme ci-dessous :

Outre les solutions biométriques, fortement réglementées en France par la CNIL, la carte RFID/NFC (badge) émerge comme offrant la meilleure ergonomie pour un niveau de sécurité satisfaisant. Ceci est en adéquation avec ce qui a pu être observé chez les acteurs « matures » sur cette thématique.

Le badge est extrêmement ergonomique et présente un niveau de sécurité satisfaisant s’il est couplé à un code PIN ou un mot de passe dans le cadre d’une authentification à multi facteurs.

Pour la plupart des acteurs du monde industriel, cette solution est suffisante afin d’augmenter drastiquement la sécurité des accès des opérateurs, tout en restant simple d’utilisation. Si des badges pour les accès physiques sont déjà distribués, il est envisageable de les remplacer progressivement par des badges compatibles avec le standard FIDO2.

Néanmoins, dans des industries particulièrement sensibles où la sécurité est un enjeu critique, certaines solutions innovantes peuvent se démarquer :

La clé biométrique FIDO2  :

• Beaucoup de machines possèdent un port USB et le standard FIDO2 assure une compatibilité avec un grand nombre d’applications
• L’empreinte digitale remplace le code PIN et assure une certaine sécurité même en cas de vol ou de perte de la clé
• Aucune image biométrique n’est sauvegardée et aucun gabarit n’est stocké ailleurs que dans la clé

Le bracelet biométrique reposant également sur le protocole FIDO2 (exemple du bracelet « Nymi », non affilié avec Wavestone) :

• Chaque collaborateur reçoit un bracelet nominatif et s’enrôle avec son empreinte digitale
• Au début de la journée, chaque collaborateur met son bracelet et le déverrouille avec son empreinte digitale
• Tant que le collaborateur n’enlève pas son bracelet, il n’a qu’à le passer à côté des équipements équipés de capteurs NFC afin de s’authentifier avec le standard FIDO2
• Le bracelet est capable de détecter « le vivant » et se verrouille dès qu’il est enlevé
• Aucune image biométrique n’est sauvegardée et aucun gabarit n’est stocké ailleurs que dans le bracelet du collaborateur

Ces solutions sont coûteuses mais présentent un niveau de sécurité et d’ergonomie à l’état de l’art.

Une démocratisation freinée par plusieurs facteurs

Même si des solutions sont disponibles, il existe un retard en matière d’authentification des cols bleus, pouvant s’expliquer par différents freins à leur démocratisation :

• La sensibilité des accès logiques: celle-ci n’est pas toujours suffisante pour justifier des coûts engendrés par la modernisation et le renforcement de l’authentification
• Les priorités des attaquants: les SI de gestions et bureautiques restent les cibles prioritaires des attaquants, ce qui incite les entreprises à concentrer leurs efforts de sécurité sur ceux-ci
• L’obsolescence logiciels et de l’infrastructure: les machines et programmes utilisés sur les lignes de production peuvent être obsolètes. Les entreprises sont donc réticentes à remplacer ces ressources fonctionnelles au risque de se heurter à des problèmes de compatibilité
• La réglementation imposée : la CNIL ne favorise pas le développement des moyens d’authentification biométriques en France^[4] 

Cependant, la modernisation devrait s’accélérer grâce aux nouveaux besoins de sécurité
liés au développement de l’IoT. Le standard FIDO2 poursuit lui aussi sa popularisation, et il existe des solutions innovantes commençant à prendre de l’ampleur sur le marché. Il est enfin à noter que certains opérateurs sur ligne utilisent les mêmes ressources que les populations bureautiques, certaines solutions passwordless comme Windows Hello for Business sont donc envisageables et simples à mettre en place grâce aux capteurs intégrés aux appareils.

La convergence des accès logiques et physiques, la solution pour déclencher la démocratisation à large échelle ?

Les accès physiques des cols bleus sont bien souvent déjà sécurisés puisqu’il s’agit de populations exerçant sur des sites sensibles. Un système de badge est donc dans la plupart du temps déjà en place pour l’accès aux bâtiments et aux zones restreintes, avec sur les lieux les plus critiques, des lecteurs biométriques ou d’autres outils de surveillance (vidéosurveillance, …). Dès lors, la question de la capitalisation et centralisation du contrôle d’accès se pose, et proposer les mêmes moyens d’authentification pour les accès logiques que ceux déjà en place pour les accès physiques présenterait des avantages certains tout en faisant émerger de nouveaux enjeux :

• Une expérience utilisateur améliorée, un même processus pour tous les accès.
• Une gestion des autorisations simplifiée et renforcée.
• Une nécessité de coordonner les équipes chargées de la sécurité physique avec la DSI, de forts enjeux de gouvernance à anticiper.
• Une infrastructure commune à prévoir, tous les réseaux contrôlant les accès à connecter.

[1] Authentication Security Best Practices in the Manufacturing Industry, publié par Chris Collier sur le site HYPR

[2] Fiches Incidents Cyber Industriels, publiées par le Clusif

[3] Recommandations relatives à l’authentification multifacteur et aux mots de passe, publiées par l’ANSSI

[4] Le contrôle d’accès biométrique sur les lieux de travail, publié par la CNIL

Cet article L’authentification des populations cols bleus, un défi incontournable trop souvent négligé ? est apparu en premier sur RiskInsight.

Notamment, avec l’explosion des IoT et les réglementations tels que la DSP2, le besoin de déclencher des authentifications décorrélées du medium d’accès de l’utilisateur se fait de plus en plus présent : en effet, ce dernier ne dispose peut-être pas des interfaces nécessaires, ou peut ne pas être reconnu comme un support suffisamment sécurisé.

La cinématique additionnelle CIBA, Client Initiated Backchannel Authentication Flow a pour but de définir les échanges et les appels permettant de déclencher des tels authentifications. Ce premier article a pour but de décrire brièvement le fonctionnement haut niveau de cette cinématique, et de présenter les apports et les cas d’usage supplémentaire qu’il peut couvrir.

C’est quoi CIBA ?

CIBA signifie Client Initiated Backchannel Authentication. Il s’agit d’un nouveau flux d’authentification et d’autorisation du standard OpenID Connect définit par la fondation Open ID.

Le flux CIBA est le premier flux d’OpenID qualifié de « découplé » car il introduit la notion de Consumption Device (CD) et d’Authentication Device (AD). Le CD est l’appareil sur lequel l’accès à un service (Relying Party, RP) est demandé tandis que l’AD est l’appareil sur lequel l’utilisateur s’authentifie auprès de l’OpenID Provider (OP) et autorise l’accès qui est demandé sur le CD, en donnant son consentement.

Contrairement aux autres flux du standard OIDC, CIBA considère donc que l’utilisateur peut s’authentifier sur un appareil différent de celui sur lequel il veut accéder au service. Par exemple, un utilisateur cherche à accéder à son compte en banque depuis son ordinateur et s’authentifie pour autoriser l’accès depuis son smartphone.

Quels apports ?

Le flux CIBA présente plusieurs intérêts significatifs pour l’authentification des utilisateurs.

Les flux d’authentification OIDC aujourd’hui sont conçus autour de la notion de redirections web entre le service accédé (Relying Party) et le fournisseur d’identité. Ces redirections peuvent se montrer inconfortables et perturbantes pour l’utilisateur qui voit son navigateur ou son application passer d’un site à un autre sans forcément comprendre ce comportement. Avec CIBA, l’appareil que l’utilisateur utilise pour accéder à un service reste sur la page du service demandé en attendant que l’authentification soit réalisée sur l’AD. Cette disparition des redirections améliore également l’acceptation des Relying Party qui ne perdent plus le contrôle et la visibilité des actions de l’utilisateur lorsque ce-dernier doit s’authentifier auprès de l’OP.

Bénéfice par population

L’authentification multi-facteur (MFA) est de plus en plus répandue et recommandée pour accéder à des services sur Internet. Les SMS, les soft-token ou encore les Out-Of-Band push notification sont divers exemples de facteurs d’authentification additionnels, utilisés aujourd’hui en complément d’un mot de passe. Avec CIBA, la présence de ce facteur fait naturellement partie de l’authentification puisque celle-ci s’effectue sur un appareil enregistré comme AD. En demandant à l’utilisateur de s’authentifier sur l’AD avec un mot de passe, un code PIN, un facteur biométrique, … on permet de centraliser les actions d’authentification sur un seul et même appareil tout en permettant de faire du MFA.

Exemples de cas d’usage

Le call center

Lorsqu’un client appelle aujourd’hui un centre d’aide ou de services, l’opérateur vérifie le plus souvent l’identité du client avec diverses questions personnelles (date et lieu de naissance, numéro de sécurité sociale) ou bien à l’aide des questions de sécurité. Cette méthode d’authentification est particulièrement vulnérable à des attaques telles que l’ingénierie sociale.

Grâce à CIBA, il est possible pour l’opérateur de déclencher une demande d’authentification de l’appelant sur son Authentication Device et ainsi s’assurer de façon plus sécurisée de l’identité du client.

Les assistants virtuels

La DSP2 impose aux organismes bancaires de s’assurer de l’identité de la personne effectuant une opération au-dessus de certain montant, ce qui passe obligatoirement par une phase d’authentification (2 facteurs) lors d’un transfert par exemple. Néanmoins, les IoT tels que les assistants vocaux ne disposent pas d’interface permettant à l’utilisateur de saisir leurs identifiants, et forcer le client à valider une demande de transfert sur un portail web via son smartphone ou son pc n’est pas l’expérience utilisateur idéale. CIBA permet de s’affranchir de cette contrainte, car la banque du client est alors en capacité d’envoyer une demande d’authentification directement sur le bon terminal (AD), limitant l’impression de rupture de parcours pour le client.

Conclusion

La cinématique d’authentification CIBA comble de vraies faiblesses du protocole OpenID Connect, tant au niveau de la couverture fonctionnelle que de l’expérience utilisateur. Sa mise en œuvre dans le monde réel devrait se faire rapidement, et de nombreux acteurs du marché regardent déjà comment l’implémenter.

Cet article FAPI-CIBA : Comment authentifier mon utilisateur sans interface ! est apparu en premier sur RiskInsight.

D’ailleurs, s’il y a bien une chose que vous devez protéger, ce sont bien vos administrateurs !

Qu’elles concernent les méthodes d’authentification, les permissions des applications tierces via les API (en autorisant une application tierce à synchroniser des données avec un service de stockage externe par exemple) ou encore la modification des politiques de rétention, Une action d’administration peut considérablement affecter les données et la sécurité du tenant à plus large échelle. S’il est nécessaire d’expliciter encore ce point, un Administrateur général (ou Global Administrator en anglais) a la capacité d’accéder à l’ensemble des données ou de gérer tous les paramétrages d’Office 365, Windows 10, d’Azure AD… mais également d’Azure !

Quelles fonctionnalités natives dans la plateforme de Microsoft ?

Quels modèles de droits au sein de Microsoft 365 ?

A ce jour, Microsoft 365 comporte deux niveaux de droits principaux. Ces deux niveaux permettent schématiquement de déléguer des droits d’administration en s’adaptant aux différents modèles d’organisations (petites / moyennes / grandes, centralisées / décentralisées) :

• Rôles Azure AD : Administration des services Azure AD et Microsoft 365 ;
• Rôles RBAC : Administration des objets au sein des services.

Premier niveau : Utilisation des rôles Azure AD pour gérer les services

La personne à l’origine de l’ouverture du tenant récupère automatiquement le rôle d’Administrateur Général. Il peut alors nommer d’autres administrateurs pour l’accompagner dans ses tâches. Dans la mesure du possible, les droits de Global Admin ne doivent pas être utilisés afin de limiter une surexposition des comptes d’administration. Une bonne pratique, consiste à limiter ce rôle général à un maximum de 3-4 comptes. De plus, pour la quasi-totalité des actions, il existe un rôle d’administration de service équivalent (ex : SharePoint Administrator, User Administrator, etc.).

Ces rôles d’administration de services sont également appelés rôles Azure AD. En effet, chaque service peut être vu comme une application Azure AD. Un administrateur serait ainsi équivalent au propriétaire du service en question. A l’heure de l’écriture de cet article, Microsoft propose 59 rôles différents, ce qui permet d’avoir un bon niveau de ségrégation des droits dans la plupart des cas.

Cependant, les rôles proposés par défaut donnent accès à l’intégralité du service administré pour l’ensemble du tenant et peut donner certains cas donner accès aux données sous-jacentes (notamment pour SharePoint Administrator, Exchange Administrator et User Administrator).

Figure 1 – Exemples de rôles sensibles

Dans le cas d’une maturité avancée, il est possible d’aller plus loin dans la ségrégation des droits en créant des rôles Azure AD personnalisés. Concrètement, cela revient à décider de quelles permissions bénéficie ce rôle (ex : « microsoft.directory/applications/create » permet de créer des applications dans Azure Active Directory).

Le revers de la médaille sera qu’il sera plus compliqué d’auditer l’administration et qu’il sera nécessaire de veiller à l’évolution des services afin de s’assurer que les permissions restent cohérentes avec les besoins des administrateurs.

Second niveau : Utilisation du modèle RBAC pour gérer les objets

Certains services tels que Exchange Online, Intune, les Centres de Securité et de Conformité ou encore Cloud App Security proposent des modèles de droits RBAC spécifiques.

Comme son nom l’indique, le Role Based Access Control (RBAC), permet d’implémenter une gestion des permissions plus fine ; avec la capacité de définir des rôles pour des périmètres définis (exemple sur certains groupes d’utilisateurs). Par exemple, il sera possible de créer « Helpdesk A » et « Helpdesk B » dans Exchange Online pour donner des droits de support à deux équipes distinctes sur un périmètre A et un périmètre B.

Comment provisionner les comptes d’administrations ?

La première question est de savoir comment créer l’identité d’un administrateur. Deux stratégies sont possibles :

• La création d’un compte dans le référentiel d’identité de l’organisation, qui sera ensuite synchronisé avec Azure AD (ex : wavestone.com) ;
• La création du compte directement dans Azure AD. Ce compte sera alors dit « cloud-only » (exemple : wavestone.onmicrosoft.com).

Quel que soit le rôle d’administration, il est recommandé pour un service SaaS comme Microsoft 365 que le compte se situe au plus près de la ressource administrée. Ici, cela revient à utiliser des comptes cloud-only. L’objectif est double : se prémunir d’une éventuelle indisponibilité ou d’une compromission du référentiel d’identité de l’organisation.

Comment attribuer des permissions ?

La deuxième question est de savoir comment attribuer les bons privilèges aux rôles d’administration créés.

Dans le cas de l’administration des services

Afin d’attribuer un rôle AAD, il est possible d’utiliser 3 méthodes (via le portail ou la commande PowerShell correspondante) :

• Le portail Azure (portal.azure.com) : c’est la méthode qui doit être privilégiée, car elle permet l’association de droits au plus près des ressources et l’utilisation de PIM, dont nous parlerons dans la suite de l’article ;
• Le portail Microsoft 365 (admin.microsoft.com) : il est possible de réaliser l’attribution des rôles directement à travers le portail principal d’administration. Cependant cette méthode n’est pas compatible avec PIM ;
• L’utilisation d’outils IAM tiers: ces solutions présentent aujourd’hui des connecteurs avec Office 365 pour réaliser le provisioning des identités et des privilèges. Ces solutions offrent une granularité moindre, ne sont pas compatibles avec PIM et sont source d’erreurs courantes. Par exemple, la synchronisation est généralement en sens unique, ce qui entraîne la réapparition du compte d’administration si celui-ci n’est supprimé que dans Azure AD.

A noter, il est également désormais possible d’assigner un rôle Azure AD à un groupe de sécurité (Cloud uniquement) via une fonctionnalité en preview. Cela pourrait simplifier certains modèles d’administration, dans lesquels l’équipe Communications Unifiées doit par exemple bénéficier du rôle SharePoint Administrator et de Teams Administrator. Attention cependant à la gestion de ce groupe.

Dans le cas de l’administration des objets

Pour les rôles RBAC, la définition des rôles se fait directement dans la plateforme d’administration du service concerné. Il est alors possible d’assigner le rôle en question manuellement ou à un groupe de sécurité, dans le portail ou via une solution IAM.

Figure 2 – Fonctionnalités natives de la solution

Comment bâtir et implémenter son modèle d’administration ?

Quelle stratégie pour définir son modèle de droits ?

La construction d’un modèle de délégation doit se faire sur le principe du moindre privilège. Le cœur du travail est faire l’inventaire des cas d’usages d’administration d’Office 365 et de faire la correspondance entre vos équipes et les droits disponibles.

Cela peut être l’occasion de remettre à plat l’organisation des équipes traitant de l’environnement de travail. Deux constats sont assez significatifs :

• Les terminaux mobiles et les postes de travail sont destinés à être gérés par des solutions unifiées (UEM) comme Intune, Workspace One ou MobileIron, et donc par la même équipe.
• Les outils de sécurité et de conformité sont de plus en plus intégrés nativement dans Office 365. Il est donc nécessaire de faire tomber le mur qui existait entre le monde workplace et le monde sécurité, afin de créer une équipe ayant la même ambition : créer et maintenir une plateforme maîtrisée et sécurisée.

Office 365 a pour particularité de rassembler une multitude de services différents, tels que le stockage de fichier ou d’informations (SharePoint, OneDrive), des outils de communication (Exchange, Teams) mais aussi de sécurité (Defender, Information Protection, etc.). Il est alors indispensable de regrouper les services en catégorie et de définir une matrice de correspondance entre équipe et rôles d’administration.

Concrètement, nous vous conseillons dans un premier temps d’utiliser les rôles Azure AD par défaut pour l’administration des services, et ensuite de définir des rôles plus granulaires avec RBAC et les rôles personnalisés.

Il est également intéressant d’identifier les rôles les plus sensibles, comme ceux permettant l’accès aux données ou paramètres de sécurité (par exemple : Global Admin, Exchange Admin, Security Administrator et Application Administration) afin de pouvoir adapter la sécurisation de ces rôles.

Comment déléguer des droits d’administration sur les objets dans un contexte multi-entité ?

Avant de parler sécurisation à proprement parler, se pose encore une autre question. Bien que la configuration des services et des paramètres de sécurité ne puisse se faire que centralement, les équipes locales ont besoin de faire actions de support : création ou modification d’un compte interne ou invité, réinitialisation des authentifiants, création de groupe Microsoft 365 ou d’une liste de distribution, etc.

Les rôles d’administration de services, les rôles Azure AD, n’offrent pas de ségrégation de privilège par périmètre ; un administrateur Exchange Online sera ainsi en mesure de manipuler l’ensemble des boîtes mails. Il ne sera pas envisageable de donner des dans des organisations complexes ou encore dans des contextes réglementés. Plusieurs stratégies sont disponibles, en fonction de la maturité et de la complexité de l’organisation.

Dans le cas de petites structures, le plus simple reste d’utiliser les fonctionnalités natives :

• Rôles RBAC: les rôles RBAC Exchange et Intune permettent généralement d’avoir le bon niveau de granularité pour gérer les objets dans les portails natifs ;
• Administrative Units: les Unités administratives, enfin en GA depuis fin Septembre, sont l’équivalent du RBAC pour Azure Active Directory. Elles prennent la forme de conteneurs dans lesquels un administrateur a la possibilité de créer ou de modifier des objets, ce qui trouve tout son sens pour les activités de support.

Dans le cas de structures plus importantes, la bonne pratique est de ne pas gérer les objets (utilisateurs, boites mail, groupes, sites SharePoint, etc.) directement dans les portails natifs. Il faut une interface permettant de gérer l’ensemble de ces objets, tout en tenant compte des logiques métiers et du modèle d’administration cible. Ci-dessous, trois exemples d’interface :

• Développement maison d’un « Custom Automation Engine» : cette interface sera décorrélée de de l’IAM et bien souvent une grosse machine à powershell / Graph API ;
• Intégration d’un connecteur à la solution IAM en vigueur afin de présenter une gestion complète des objets en faisant abstraction de leur hébergement direct ;
• Investissement dans une SaaS Management Plateform(SMP) : des éditeurs se sont spécialisés dans la création d’outil de gestion d’Office 365, mêlant fonctionnalités d’administration des objets, de gestion de licences ou encore de supervision sécurité et opérationnelle. Parmi ces solutions, encore peu connues, on retrouve notamment ManageEngine, CoreView et Quadrotech.

A noter : cette interface, dédiée aux équipes de supports, sera distincte d’une interface ouverte à tous les utilisateurs leurs permettant de créer centralement des utilisateurs invités, et des sites SharePoint, des Teams, etc. Concrètement, cette deuxième interface pourra être intégré aux outils de ITSM, à la SMP ou encore être développée à base de Power Apps et de Graph API.

Comment protéger l’accès à ces comptes

10 mesures pour sécuriser les comptes d’administrations

En fonction des licences de sécurité, principalement du bundle EMS, Microsoft fournit un certain nombre de contrôles pour sécuriser les comptes d’administration.

La plupart de ces mesures pourraient également être obtenues via des outils tierces.

Les mesures basiques de la sécurisation du compte d’administration

1. Un compte d’administrateur dédié

Un administrateur doit posséder un compte dédié à l’administration, différent du compte bureautique. Ce compte devrait être cloud-only dans la mesure du possible (ex : wavestone.onmicrosoft.com).

2. Authentification Multi-Facteur

L’authentification à plusieurs facteurs n’est plus une option aujourd’hui, et ce encore moins pour les administrateurs.

Cette mesure est disponible pour tous, pour toutes les licences :

• Via MFA pour Office 365 (également appelé MFA avec héritage par personne) qui force un challenge à chaque connexion ;
• Via les Security Defaults qui impose l’enregistrement d’un facteur additionnel pour tous les utilisateurs et impose le MFA pour les administrateurs à chaque connexion ;

Il est également important également de veiller à la désactivation des protocoles d’authentification héritée qui ne prennent pas en charge le MFA. Ces derniers permettraient en effet de passer outre l’authentification simple.

Il sera également pertinent de limiter les types de facteurs supplémentaires disponibles ; à quoi bon sécuriser les comptes d’administration si le second facteur est l’adresse Gmail de l’administrateur.

Des mesures de sécurisations fortement recommandées

3. Compte sans licence Office 365 

Sans licence, il se sera pas possible pour un administrateur d’accéder aux différents services et données de la plateforme, ou encore d’avoir une boite mail.

A noter, certains services, comme Power Apps ou Power BI, requièrent une licence pour accéder au portail d’administration. En pratique, il peut être intéressant de créer un groupe de sécurité attribuant les licences nécessaires pour les administrateurs.

4. Conditional Access (avec Azure AD P1)

L’accès conditionnel permet d’évaluer le contexte lors de l’accès à un service Office 365, et d’autoriser en fonction l’accès. Il permet par exemple de bloquer l’accès en fonction du type de poste utilisé (géré par l’entreprise ou non), du réseau sur lequel l’utilisateur est connecté, de l’application en question ou encore de son rôle d’administration.

Dans une logique Zero Trust, il ne faudrait pas différencier le réseau interne et le réseau externe, en particulier pour les administrateurs, mais plutôt se concentrer sur l’état du poste de travail et le risque de la connexion.

5. Protection de mot de passe (avec Azure AD P1)

Aure AD Password Protection apporte des contrôles sur les mots de passe. Il sera ainsi possible d’interdire l’utilisation d’un mot de passe courant ou d’un dérivé (avec une liste prédéfinie par Microsoft ou maintenue par l’organisation).

Une bonne pratique consiste à appliquer à minima cette protection sur l’ensemble des comptes d’administration Cloud-only.

6. Azure AD Identity Protection (avec Azure AD P2)

Azure AD Identity Protection permet d’ajouter une notion de risque dans l’évaluation des accès et des comportements des utilisateurs. Concrètement, il sera opportun des définir les politiques suivantes ;

• Risky users : Forcer le changement de mot de passe pour un administrateur susceptible d’être compromis (avec un risque Medium ou High) ;
• Risky sign-in : Forcer un challenge MFA lors d’un accès à risque (ex : IP anonyme ou inhabituelle).

7. Azure AD Privileged Identity Management (avec Azure AD P2):

Azure AD Privileged Identity Management est un service permettant de contrôler l’attribution et l’utilisation des rôles d’administration :

• Attribuer de droits « just-in-time » en donnant un rôle éligible au lieu de permanent ;
• Soumettre l’activation d’un rôle à une validation d’une tierce partie ;
• Mettre en place une date de fin de droit pour un rôle d’administration ;
• Forcer les recertifications des administrateurs.

Il sera pertinent de distinguer les rôles dits sensibles des autres, lors de l’implémentation.

Le suivi des administrateurs éligibles permet en bonus, de prendre conscience de l’utilisation réelle des droits d’administration et donc de nettoyer plus facilement la liste des administrateurs.

A noter, les fonctionnalités de PIM ont récemment été étendus aux différents groupes, ce qui permet de mettre en place du « Just-in-time » pour des cas plus exotiques comme les Super-Users RMS / AIP.

Pour aller encore plus loin

8. Supervision des action administrateurs pour détecter les comportements anormaux

Une fois toutes ces mesures de sécurisation en place, il ne vous reste plus qu’à implémenter de la supervision afin de détecter les non-conformités aux règles précédentes et les comportements anormaux.

Et pour cela, rien de mieux que de se référer à notre article sur le sujet pour comprendre les journaux disponibles.

9. Mettre en place une Privileged Access Workstation

L’administration étant une action par définition critique. Il est nécessaire qu’elle soit réalisée dans un périmètre de confiance. La mise à disposition de PAW, ou poste d’administration, permettra d’aller dans cet objectif.

La configuration du poste d’administration devrait être simple (pas de droits d’administration local, navigation Internet restreinte, ports USB bloqués, modules PowerShell préinstallés, etc.). Mais le fait de restreindre la connexion d’un administrateur Office 365 depuis ce poste peut poser plus de soucis. Pour cela, plusieurs possibilités existent :

• Dans un contexte moderne, une réponse simple est de s’appuyer sur les outils Microsoft : définir un profil de poste d’administration dans Intune et l’assigner aux administrateurs. Avec une règle d’accès conditionnel, il est possible d’exiger un poste conforme lors de la connexion.
• Dans un modèle plus classique, il est possible de mettre en place un silo d’authentification avec les administrateurs et les postes associés. On aurait ainsi un modèle se rapprochant du modèle en tiers bien connu des équipes AD.
• D’autre pistes sont également possibles, même si plus complexes : association d’un certificat et d’un reverse proxy ou encore d’un bastion.

10. Rester informé des bonnes pratiques et des nouveautés

On ne rappellera jamais assez qu’Office 365 étant une plateforme Cloud, elle est en évolution constante. Se tenir au courant permettra de continuer à augmenter son niveau de sécurisation au fil du temps.

Figure 3 – La sécurisation des comptes, des mesures qui se comptent sur les doigts de la main

Focus sur les comptes bris de glace

Une bonne pratique d’administration de la plateforme de Microsoft est la mise en place de comptes d’administrateur permettent en cas d’incident de récupérer le contrôle sur la plateforme.  Ce sont ce que l’on appelle des comptes bris de glace. Ces comptes doivent permettent un total contrôle sur le tenant Office 365 et le rôle de Global Administrator leur est donc attribué.

Ces comptes doivent faire preuve d’une sécurisation, cependant il ne faut pas oublier leur spécificité qui consiste à les utiliser en cas d’incident. Ainsi la sécurisation imposée à ces comptes doit rester compatible avec le caractère urgent de leur utilisation.  Ces comptes doivent donc répondre aux recommandations suivantes :

• Être des comptes cloud-only
• Pas de MFA configuré (ou du moins un MFA tiers)
• Stockage du mot de passe dans un coffre auquel seulement des personnes identifiées de l’équipe sécurité ou Office 365 peuvent accéder
• Mise en place d’alerte afin de vérifier que ces comptes ne sont pas utilisés hors d’une procédure d’incident nécessitant l’utilisation du bris de glace.

Il est également recommandé de ne pas utiliser de convention de nommage spécifique pour ces comptes, ils ne doivent pas attirer l’œil d’un possible attaquant !

Conclusion

La sécurité sur Office 365 repose sur des mesures techniques de protection des comptes administrateurs, ainsi que l’implémentation d’un modèle d’administration cible, ce qui comprend une gouvernance et des processus clairs, des outils pour mettre en place cette délégation de droits, et des dispositifs pour le maintenir dans le temps.

Mais quelles que soient les mesures de protection implémentées, la sécurité repose avant tout sur les administrateurs de la solution. Sensibilisation des administrateurs et contrôles seront indispensables.

Les administrateurs doivent garder à l’esprit que leurs comptes donnent accès à des informations et des actions extrêmement sensibles : ils sont donc la cible privilégiée des pirates informatiques !

O365 étant en constante évolution, chaque nouveauté introduite par Microsoft pourra amener également son lot de problèmes de sécurité qu’il faudra étudier et prendre en compte. Profitez-en pour mettre à jour vos documentations : analyses de risques O365, configuration des services, modèle de délégation…toujours sans oublier de permettre à vos administrateurs de se former !

Cet article Comment maîtriser l’administration dans Microsoft 365 ? est apparu en premier sur RiskInsight.

Fonctionnement du mécanisme de verrouillage de compte utilisateur

Jamais un sans trois

Invoke-CleverSpray – Script PowerShell automatisant la découverte de mots de passe (actuel, N-1 et N-2)

Cet article Invoke-CleverSpray – Jamais 1 sans 3 est apparu en premier sur RiskInsight.

Depuis l’arrivée de Facebook en 2004, Internet a été témoin d’une explosion du nombre de réseaux sociaux, des plus généralistes aux plus spécialisés. Leur adoption et utilisation massive les positionnent comme des véritables mines d’or pour les entreprises, en leur offrant une porte d’accès à des données jusqu’alors inaccessibles (préférences de leurs clients, envies, intérêts…).

À l’heure où l’expérience utilisateur et la connaissance des clients deviennent des problématiques incontournables pour les entreprises, le social login semble être la solution rêvée… mais est-ce vraiment le cas ?

Chapitre 1 : la promesse

En 2018, nous comptons plus de 70 réseaux sociaux, dont les plus connus et utilisés restent Facebook, Google+, Twitter ou encore LinkedIn. Certains réseaux peuvent être même rattachés à des plaques géographiques ou pays particuliers, comme l’Asie avec WeChat, Weibo, Mixi ou et la Russie avec Vkontakte.

À titre indicatif, l’utilisation de réseaux sociaux est passée de 153 millions d’utilisateurs en 2011 à 837 millions en 2013, pour passer largement au-delà du milliard en 2017.

Les réseaux sociaux sont donc devenus de véritables référentiels d’identités, dont certains promettent de détenir l’Identité de référence sur Internet, les motivant à se positionner naturellement comme fournisseur d’identités pour les entreprises. C’est dans ce cadre et sur la base de cette promesse que le social login est né.

L’objectif premier du social login est de permettre à un utilisateur d’accéder aux services d’une marque ou boutique virtuelle le plus simplement possible, à l’aide d’un compte d’un réseau social.

Il s’affiche comme une réponse aux attentes des clients en simplifiant les processus d’enregistrement et d’accès aux services, mais également à celles des entreprises en donnant des moyens d’authentification rapides à déployer afin d’améliorer le taux de conversion des prospects.

Une solution pratique et simple à utiliser

Lorsque nous parlons de social login, nous distinguons deux cas d’usage :

• Social registration: utilisation d’un compte d’un réseau social (ex : Facebook, Google, Twitter, LinkedIn…) pour créer un compte sur une application
• Social login: utilisation d’un compte d’un réseau social pour s’authentifier sur une application pour laquelle le compte applicatif a été déjà créé via social registration

La cinématique décrite ci-après présente les étapes du social registration. La cinématique du social login est similaire et repose uniquement sur les étapes 1, 2 et 3.

Étape 1 – Accès initial au service

L’utilisateur accède à l’application (mobile ou web) d’une entreprise qui lui fournit des services et choisit de créer un compte depuis le réseau social de son choix.

Étape 2 – Authentification

L’utilisateur est alors redirigé vers le réseau social sélectionné pour s’authentifier selon le mécanisme en vigueur (ex : identifiant / mot de passe, code (OTP) envoyé par SMS…).

Dans l’éventualité où l’utilisateur a déjà une session active sur ce réseau social, il sera automatiquement authentifié (SSO – Single Sign On) et passera directement à l’étape suivante.

Étape 3a – Recueil du consentement

Le réseau social informe l’utilisateur que l’application souhaite accéder à des informations de son compte (ex : nom, prénom, date de naissance, liste des amis, préférences…) afin de lui créer un compte applicatif. L’utilisateur doit alors donner son consentement explicite pour que la cinématique se poursuive.

À noter que certains réseaux sociaux comme Facebook offrent la possibilité à l’utilisateur de visualiser en détail les informations que l’application souhaite recueillir afin de pouvoir gérer plus finement son consentement (étape 3b).

Étape 3b – Gestion fine du consentement

L’utilisateur visualise l’ensemble des informations que l’application souhaite recueillir. Il peut alors décocher celles qu’il ne souhaite pas partager. Toutefois, des informations peuvent être obligatoires pour que l’application puisse lui créer un compte applicatif et ne pourront être décochées par l’utilisateur (généralement l’adresse e-mail car souvent utilisée comme identifiant).

Étape 3 / Étape 3c – Redirection vers le service souhaité

L’utilisateur est alors redirigé vers le service souhaité. Éventuellement, l’affichage pourra être personnalisé pour montrer l’intérêt de partager les informations de son compte social (affichage de la photo de profil, contenus personnalisés sur la base des préférences de l’utilisateur…).

Un avantage concurrentiel pour les entreprises

Simplifier le processus de création

La conversion des prospects en clients est l’objectif principal des entreprises. L’un des premiers freins à cette conversion est le processus de création de compte. Selon une étude de WebHostingBuzz, plus de 86% de prospects abandonnent dès cette étape, souvent jugée trop longue et complexe.

Le social registration est une alternative de plus en plus adoptée par les entreprises : abandonner le formulaire de création de compte traditionnel pour mettre en avant l’utilisation d’un compte d’un réseau social. En d’autres termes, passer de plusieurs minutes à quelques clics.

Faciliter l’accès aux services

Simplifier le processus de création de compte n’est pas une fin en soi. Il faut également donner envie aux clients de revenir et consommer les services de l’entreprise, notamment en :

• Offrant une expérience utilisateur omnicanale: ne pas perdre le client en lui imposant des parcours différents en fonction du moyen d’accès utilisé
• Réduisant le nombre de mots de passe à retenir: favoriser l’usage d’un compte (i.e. : couple identifiant / mot de passe) déjà connu de l’utilisateur pour éviter de récréer un nouveau mot de passe

Le social login se positionne comme une solution permettant de répondre à ces problématiques : que ce soit depuis un ordinateur, un smartphone, une tablette, le client bénéficiera de la même expérience utilisateur (même cinématique d’accès), basée sur l’usage d’un compte social pour accéder aux services de l’entreprise, et ses partenaires.

Personnaliser l’expérience utilisateur

L’utilisation du social login permet d’accéder à un nombre important de données qualitatives sur les clients : données d’identité (nom, prénom, date de naissance), données de contact (adresse e-mail, numéro de téléphone…), données de préférences (intérêts, partages, likes) …

Des données jusqu’alors inaccessibles dans une gestion des identités clients classique le deviennent, qui offrent la possibilité aux entreprises de personnaliser davantage leur relation avec leurs clients :

• Affichage et communication personnalisés
• Proposition de contenu personnalisé
• Anticipation ou adaptation de services en ligne avec les intérêts des clients

La personnalisation de l’expérience utilisateur permettra aux entreprises d’instaurer un climat de confiance, proposer des services sur-mesure et fidéliser ses clients dans la durée.

Ils l’ont adopté… ou pas encore

L’adoption du social login est très disparate en fonction du secteur d’activité de l’entreprise et de la nature de ses relations avec ses clients. Nous distinguons deux typologies de clients :

• Les consommateurs: bénéficient des services d’une entreprise sans pour autant avoir de relation directe et/ou de contrat les liant (ex : j’achète une bouteille de soda dans mon magasin préféré, mais l’entreprise qui conçoit ce soda ne me connait pas forcément)
• Les clients directs: bénéficient des services d’une entreprise sur la base d’un lien direct (contrat, comptes bancaires…), nécessitant une relation de proximité entre l’entreprise et le client

Selon une étude Wavestone réalisée en mars 2018 sur un échantillon de 172 marques majeures réparties dans tous les secteurs d’activité, 32% d’entre elles ont adopté le social login.

Ce constat met en lumière une adoption forte par les entreprises ayant des clients de type « consommateurs », dont l’objectif est de vendre rapidement des services de consommation (VOD, matériels, presse…).

À contrario, peu, voire pas du tout, d’entreprises ayant des clients directs adoptent le social login, leur relation débutant par l’établissement d’un contrat (et donc la création d’un compte avec des données vérifiées par l’entreprise (carte d’identité, justificatif de domicile…)). Toutefois, certaines de ces entreprises ont déjà commencé à instruire le social login dans leur feuille de route de services numériques, et il commence à s’imposer comme une norme au regard de l’arrivée d’un nouveau type de clients : la génération Z.

Parmi les entreprises ayant adopté le social login, Facebook et Google+ sortent du lot avec un taux d’adoption respectivement de 100% et 55,4%. Suivent LinkedIn (15,4%), Twitter (12,3%) et Yahoo (9,2%).

Du rêve à la réalité

La transformation numérique et l’évolution de la relation client repositionne l’expérience utilisateur au cœur des réflexions stratégiques des entreprises.

Simplicité, efficacité, fidélité sont les maîtres-mots de la nouvelle relation client, trois enjeux pour lesquels le social login semble être un accélérateur à considérer.

Toutefois, son déploiement n’est pas une évidence, ni même opportun pour toutes les entreprises (en fonction du secteur d’activité, des populations cibles, de la typologie de clients…) et requiert le respect de certaines bonnes pratiques de sécurité et de protection des données personnelles.

Pour plus de détails, rendez-vous au prochain article : « Chapitre 2 : La réalité ».

Cet article Social Login : faire d’un rêve une réalité (1/2) est apparu en premier sur RiskInsight.

Stop aux mots de passe !

S’authentifier, c’est prouver par un moyen convenu que l’on est bien la personne que l’on prétend être. Depuis l’Antiquité, le moyen le plus adopté et utilisé reste sans conteste le mot de passe. Il est cependant source d’agacement pour les utilisateurs et présente de nombreuses limites d’un point de vue sécurité.

Un sentiment partagé de « ras-le-bol »…
Nous avons tous une fois rêvé de ne plus devoir se rappeler quel mot de passe utiliser pour se connecter à nos applications préférées. Mais force est de constater que cela reste toujours un rêve.
La promesse de l’authentification unique est loin d’être tenue en entreprise et l’essor des coffres forts de mots de passe montre bien les difficultés rencontrées par les utilisateurs : multiplicité et pertinence relative des politiques de mot de passe, changement de mot de passe obligatoire, sans compter que réinitialiser son mot de passe peut relever du parcours du combattant.
Néanmoins, le principal avantage du mot de passe reste son côté universel et déjà inscrit dans les habitudes de tout un chacun.

… et un niveau de sécurité limité
De nombreux scénarios de cyberattaques s’appuient à un moment ou à un autre sur la compromission d’un mot de passe, de préférence celui d’un compte à privilèges, en utilisant différentes techniques : tests de combinaisons en grand nombre (brute force), interception de communication (Man-In-The-Middle), reconstitution du mot de passe à partir de son empreinte (Rainbow Table)…

Des mesures de sécurité pour se prémunir de ces attaques existent (chiffrement, hachage, salage, blocage du compte…) mais ne sont pas toujours implémentées systématiquement voire pas toujours de manière satisfaisante. Comme le dit l’adage, « Les mots de passe sont du point de vue de l’entreprise comme des déchets nucléaires : on les enterre profondément et on espère qu’il n’y aura pas de fuite.»

Outre les faiblesses techniques évoquées, un risque majeur réside dans les comportements des utilisateurs : réutilisation du même mot de passe pour plusieurs services, mots de passe trop faibles ou faciles à deviner, incrémentation… Ainsi, lorsqu’un mot de passe est réutilisé sur plusieurs services, le maillon le plus faible fragilise toute la chaîne.

En définitive, l’expérience utilisateur appauvrie et le niveau de sécurité limité poussent les entreprises à chercher de nouveaux moyens d’authentification.

Quels remèdes ?

On divise généralement les moyens d’authentification en 4 catégories :

Ce que je sais

Ces méthodes d’authentification se basent sur une clé ou un code que l’utilisateur connait. Elles représentent la majeure partie des solutions mises en place aujourd’hui aussi bien en entreprise que dans la sphère privée. Parmi les solutions existantes, on peut notamment retrouver le traditionnel mot de passe, le code PIN ou encore les questions secrètes. Ces dernières sont toutefois rarement utilisées car soit trop génériques (« Quelle est votre couleur préférée ? ») soit trop difficiles à retenir.

Ce que je possède

La sécurité repose sur le fait de posséder un matériel particulier. On retrouve notamment les matériels suivants :

• Un smartphone

Le smartphone permet, en entreprise comme dans la sphère privée, de sécuriser la réalisation d’opérations plus sensibles : accéder au réseau interne de l’entreprise, confirmer un paiement en ligne ou une opération bancaire inhabituelle…

Le smartphone peut ainsi être utilisé de différentes façons pour s’authentifier :

• Un token matériel

Un token a souvent la forme d’une mini-calculatrice et permet de générer un code à usage unique (OTP), le token pouvant lui-même être protégé par un code PIN choisi par l’utilisateur. Historiquement très utilisé dans les entreprises (accès VPN notamment) et occasionnellement dans la sphère privée pour la connexion à certains espaces clients, les tokens tendent néanmoins à disparaître au profit des smartphones, éliminant ainsi une logistique coûteuse.

• Une carte à puce

La carte à puce contient un certificat qui sert à prouver l’identité du porteur. Un lecteur de carte est indispensable pour l’authentification ; par ailleurs la gestion des certificats nécessite des infrastructures et des procédures de gestion du cycle de vie (arrivée, départ, perte…). Plutôt réservée au monde de l’entreprise, son usage tend à se limiter à des populations ou des usages ciblés (administration IT, opérations financières…).

• Une clé U2F

Cet objet se présente sous la forme d’une clé USB standard mais au lieu d’être utilisée pour stocker des fichiers, elle stocke une clé unique liée à l’utilisateur. Basée sur un standard défini par l’alliance FIDO, cette solution allie bon niveau de sécurité (notamment une résistance au phishing) et bonne expérience utilisateur (les clés peuvent rester brancher sur un port USB du poste) puisqu’une simple pression sur la clé suffit pour s’authentifier. Notons toutefois qu’il ne s’agit pas d’une reconnaissance d’empreinte digitale.

• Un objet connecté tel qu’une montre

Cette dernière solution, la plus novatrice dans cette catégorie, permet à l’utilisateur de se connecter par le biais d’un objet connecté qu’il possède déjà. Ce moyen d’authentification est très peu utilisé en entreprise mais Apple propose par exemple de déverrouiller son ordinateur en s’approchant simplement avec un objet connecté de la même marque.

Ces solutions basées sur la possession d’un matériel se distinguent essentiellement par leur niveau d’ergonomie. Dans tous les cas, il s’avère indispensable de gérer « l’enrôlement » (le fait de lier l’objet à son porteur), le renouvellement, la perte et le vol du matériel en question.

Ce que je suis

Les caractéristiques physiologiques d’une personne telles que l’empreinte digitale, le réseau veineux de la main, l’iris, le visage, l’empreinte vocale ou encore le rythme cardiaque permettent également d’authentifier une personne. L’usage de ces solutions est pour le grand public principalement limité à l’ouverture de son poste de travail ou de son smartphone (empreinte digitale ou visage). Cependant, ces solutions sont mises en œuvre depuis plusieurs années en entreprise pour contrôler l’accès à des salles ou zones hautement sensibles.

Ce que je fais

Le rythme de frappe au clavier, les mouvements de la souris, le maintien du téléphone, ou encore le toucher sur l’écran sont différents moyens de distinguer un utilisateur légitime d’un usurpateur ou encore d’un robot. Ces solutions de biométrie comportementale nécessitent un volume de données important pour être fiables mais cela tend à s’améliorer grâce aux nouvelles approches de Machine Learning. Ces solutions sont plutôt utilisées comme mesures de sécurité complémentaires à l’authentification (détection d’attaque par robot, détection de partage de comptes…).

En synthèse, la figure ci-dessous représente les différentes solutions d’authentification en fonction de leur niveau de sécurité et de leur simplicité d’utilisation.

Expérience utilisateur et sécurité, ennemis inconciliables ?

Nous pensons qu’il est possible de réconcilier expérience utilisateur et sécurité et proposons ici 4 orientations pour y parvenir.

Orientation 1 : Simplifier l’utilisation des mots de passe

S’il parait illusoire d’imaginer une suppression complète de l’utilisation des mots de passe, il reste possible néanmoins de s’attaquer à certains de leurs défauts. On peut déjà réduire la fréquence de saisie via des mécanismes de fédération d’identité qui permettent d’accéder aussi bien à des services de l’entreprise que des services de partenaires. Par ailleurs, des chatbots voient le jour pour simplifier les processus de réinitialisation de mots de passe et vont dans le sens d’une amélioration significative de l’expérience utilisateur. Quant à la sécurité, la sensibilisation des utilisateurs sur la bonne utilisation des mots de passe reste aujourd’hui une action essentielle pour réduire les risques (social engineering, spam, phishing, vols de mot de passe…).

Orientation 2 : Adapter les exigences de sécurité au contexte

De même que l’on doit adapter sa vitesse sur route aux conditions climatiques, la notion de « risque » doit nous guider dans le niveau de sécurité attendu pour authentifier l’utilisateur. Ainsi, pour consulter des informations non sensibles, un simple mot de passe peut suffire, là ou des opérations sensibles (virement bancaire important…) vont nécessiter d’authentifier l’utilisateur avec plus de certitude en combinant plusieurs facteurs d’authentification. D’autres critères peuvent être pris en compte pour évaluer le risque comme le PC ou smartphone utilisé, la localisation géographique, l’heure de connexion voire même le comportement habituel ou non de l’utilisateur.

Au-delà de la phase d’authentification, le niveau de risque peut également influencer la durée avant nouvelle demande d’authentification (pas besoin de retaper son mot de passe Facebook tant que l’on reste sur le même PC ou smartphone, réauthentification à un webmail tous les X jours seulement…).

Finalement, l’authentification n’est plus vue comme un événement mais comme un processus continu.

Orientation 3 : Laisser à l’utilisateur le choix de son facteur d’authentification

Plutôt que d’imposer un unique moyen d’authentification à tous les utilisateurs, le Bring Your Own Token (BYOT) consiste à laisser chacun choisir celui qui lui paraît le plus adapté à son usage. L’idée reste de proposer un choix parmi des solutions de niveau de sécurité comparable.

Aujourd’hui, Facebook ou encore Google, proposent du BYOT comme second facteur d’authentification via l’enregistrement d’un smartphone ou d’une clé USB sécurisée par exemple.

Dans le monde professionnel, cela reste moins développé pour le moment mais on peut facilement imaginer proposer ce service à des populations ciblées : besoins de mobilités spécifiques, appétence technologique…

Orientation 4 : S’appuyer sur les comptes déjà existants

Il est de plus en plus courant d’utiliser son compte d’un réseau social (Facebook, Google, LinkedIn) pour se connecter à des sites de e-commerce ou à d’autres sites web. Le Social Login permet à la fois de simplifier la création du compte sur le nouveau site en ligne et de limiter le nombre de mots de passe à retenir.

Tous les services en ligne n’ont cependant pas vocation à utiliser le Social Login. Dans le cas de services publics ou parapublics par exemple, on privilégiera plutôt le State Login qui permet par exemple d’utiliser son compte des Impôts, de l’Assurance maladie ou de La Poste pour effectuer différentes démarches administratives en ligne (FranceConnect). Le développement de ces usages est en pleine accélération aujourd’hui.

En conclusion

Si les mots de passe ne sont pas prêts de disparaître complètement, la recherche d’alternatives est en plein essor : les usages et les solutions technologiques évoluent rapidement, des consortiums et de nouveaux standards voient le jour (OAuth2, OIDC) et désormais l’expérience utilisateur est au centre de la réflexion au même titre que les enjeux de sécurité.

Cet article Quels remèdes contre les maux de passe ? est apparu en premier sur RiskInsight.

Kerberos est un protocole d’authentification réseau reposant sur un mécanisme de clés secrètes (chiffrement symétrique) et l’utilisation de tickets. Il fait partie intégrante des système d’exploitation Windows depuis la version Serveur 2000. Différents termes spécifiques sont utilisés pour détailler ce protocole :

• KDC (Key Distribution Center) : Le KDC est un service installé sur les contrôleurs de domaine et permettant l’obtention des différents tickets par un utilisateur.
• TGT (Ticket-Granting Ticket) : Le TGT est un ticket attribué par le KDC à un utilisateur. Ce ticket représente l’identité de l’utilisateur, et lui permet d’effectuer des demandes de TGS auprès du KDC.
• TGS (Ticket-Granting Service) : Le TGS est également un ticket attribué par le KDC pour représenter un utilisateur. Il permet à l’utilisateur de s’authentifier auprès d’un service spécifique, dont le nom est inscrit dans le ticket. Un exemple d’un tel ticket est le suivant :

Le schéma d’une authentification Kerberos classique est le suivant :

Dans la première étape, l’utilisateur envoi au contrôleur de domaine un timestamp chiffré à l’aide du hash NTLM de son mot de passe. Ayant accès à ce hash, le contrôleur de domaine, et plus précisément le KDC, peut déchiffrer l’information reçue et vérifier le timestamp, ce qui prouve l’identité de l’utilisateur. Le KDC fournit alors à l’utilisateur son TGT (étape 2).

L’utilisateur peut alors fournir le TGT préalablement récupéré pour effectuer une demande de TGS (étape 3). Le TGT étant représentatif de l’utilisateur, le KDC peut valider son identité et lui fournir un TGS pour le service demandé (étape 4).

Enfin, l’utilisateur transmet ce TGS comme preuve de son identité auprès du service (étape 5).

Dans le protocole Kerberos, ce sont donc bien les tickets qui permettent d’assurer l’identité d’un utilisateur, au même titre qu’un couple nom d’utilisateur / mot de passe le fait dans une authentification classique.

Introduction aux délégations Kerberos

Microsoft a introduit les délégations Kerberos dans l’objectif de permettre à une application de réutiliser l’identité d’un utilisateur pour accéder à une ressource hébergée sur un serveur différent. Un cas d’usage est par exemple l’accès à des documents hébergés sur un serveur dédié depuis une plateforme SharePoint :

L’utilisateur n’ayant pas d’accès direct au serveur de fichiers, il s’authentifie sur la plateforme SharePoint qui doit alors transmettre l’identité de l’utilisateur au serveur de fichiers.

Cependant, les tickets de service étant délivrés pour une application spécifique, le SharePoint ne peut transmettre directement le ticket qu’il a reçu de l’utilisateur. C’est donc pour répondre à cette problématique que Microsoft a mis en place les délégations Kerberos, qui existent sous deux formes :

• Les délégations non contraintes, apparues avec le système d’exploitation Windows Serveur 2000, et qui donnent l’autorisation à un compte de service de réutiliser l’identité de l’utilisateur sur n’importe quel service du domaine ou de la forêt.
• Les délégations contraintes, apparues avec le système d’exploitation Windows Serveur 2003, et qui permettent un meilleur contrôle en limitant les services sur lesquels un compte de service donné peut s’authentifier en tant que l’utilisateur.

Les délégations Kerberos non contraintes

Le schéma d’authentification d’un utilisateur désirant accéder à une ressource dans le cas d’une délégation Kerberos non contrainte est le suivant :

Lors de la première étape de ce schéma, l’utilisateur effectue une demande de TGT auprès du contrôleur de domaine, en lui transmettant un timestamp chiffré avec le hash NTLM de son mot de passe. Après avoir validé son identité, le contrôleur de domaine fournit un TGT à l’utilisateur (étape 2), comme il le ferait pour une authentification Kerberos classique.

Pour s’authentifier auprès de l’application SharePoint, l’utilisateur demande alors un TGS au contrôleur de domaine, en lui fournissant le TGT précédemment récupéré (étape 3). Dans le cas d’une délégation Kerberos non contrainte, le contrôleur de domaine construit le TGS de l’utilisateur à partir de son TGT, qu’il chiffre à l’aide du hash NTLM du mot de passe du compte de service utilisé par l’application SharePoint (étape 4).

L’utilisateur s’authentifie alors sur l’application SharePoint (étape 5) en transmettant le TGS que lui a fourni le contrôleur de domaine lors de l’étape précédente.

Le compte de service de l’application SharePoint peut déchiffrer ce TGS étant donné qu’il est chiffré avec son propre hash. Il récupère ainsi le TGT de l’utilisateur, qu’il peut fournir au contrôleur de domaine pour effectuer une demande de TGS pour le serveur de fichier (étape 6). Le TGT étant celui de l’utilisateur, le TGS renvoyé par le contrôleur de domaine (étape 7) représente son identité, et non celle du compte de service.

Le compte de service de l’application SharePoint peut alors transmettre ce TGS (étape 8), que le serveur de fichiers validera comme s’il provenait de l’utilisateur lui-même, donnant accès au document demandé (étape 9).  Ayant récupéré ce document, l’application SharePoint peut le fournir à l’utilisateur, pour lequel les phases d’authentification intermédiaires auront été transparentes.

Les délégations Kerberos contraintes

Dans le cas d’une délégation Kerberos contrainte, deux extensions de protocole sont utilisées pour permettre à une application de réutiliser l’identité de l’un de ses utilisateurs :

S4U2Self (Server-for-User-to-Self) qui autorise un service à obtenir un TGS pour lui-même en tant qu’un utilisateur.

S4U2Proxy (Server-for-User-to-Proxy) qui autorise un service à obtenir un TGS pour un autre service en tant qu’un utilisateur.

La cinématique d’authentification et d’accès aux ressources dans le cas d’une telle délégation est alors la suivante :

Dans la première étape de cette cinématique, l’utilisateur s’authentifie après du premier service en lui transmettant ses identifiants. L’authentification n’utilisant pas Kerberos, l’utilisateur n’a pas besoin de s’authentifier auprès du contrôleur de domaine.

Le compte de service demande alors un TGS représentant l’identité de l’utilisateur et permettant de s’authentifier auprès de son propre service (étape 2). Le compte de service possédant l’extension S4U2Self, le contrôleur de domaine accorde ce ticket (étape 3).

Ce même compte de service demande ensuite un TGS représentant l’identité de l’utilisateur et permettant de s’authentifier auprès du second service (étape 4). Après validation de l’extension S4U2Proxy, le contrôleur de domaine accorde ce TGS (étape 5)

Grâce à ce second ticket de service, le compte de service du SharePoint peut accéder aux ressources du serveur de fichier avec l’identité de l’utilisateur (étape 6). Le serveur de fichiers valide les privilèges de l’utilisateur, et transmet le document demandé au compte de service SharePoint (étape 7), qui le transmet à l’utilisateur (étape 8).

Contrairement au cas des délégations non contraintes, l’utilisation de l’extension de protocole S4U2Proxy permet de spécifier les services accessibles au compte de service SharePoint. Ainsi, même si l’utilisateur dispose des privilèges nécessaires pour accéder à un autre serveur, le compte de service ne pourra récupérer de TGS valide représentant l’identité de l’utilisateur. Dans le cas d’une délégation contrainte, cette restriction se fait à l’aide d’un paramètre du compte de service, appelé SPN pour Service Principal Name.

Il est à noter que depuis la version Serveur 2012 du système d’exploitation Windows, un troisième type de délégation Kerberos est proposée, les délégations Kerberos contraintes basées sur les ressources. Le fonctionnement de ces délégations est similaire à celui des délégations contraintes, mais la restriction est effectuée en spécifiant explicitement le compte ayant accès aux ressources.

Exploiter les délégations non contraintes

Les faiblesses induites par les délégations Kerberos non-contraintes sont connues depuis plusieurs années. Sean Metcalf a, par exemple, présenté les dangers de telles délégations à la Black Hat USA 2015. Dans la cinématique d’authentification présentée précédemment, il est en effet évident que le compte de service de l’application SharePoint peut, une fois que l’utilisateur lui a transmis un TGS contenant son TGT, accéder à l’ensemble des services pour lesquels l’utilisateur dispose de privilèges nécessaires.

L’objectif d’un attaquant est alors d’obtenir le TGT d’un administrateur du domaine, ce qui lui permet de se connecter au contrôleur de domaine avec les privilèges maximum pour changer le mot de passe du compte krbtgt afin de pouvoir forger ses propres tickets à la demande.

Pour parvenir à cela, il est d’abord nécessaire d’identifier les services qui disposent de délégations non contraintes. Pour cela, il suffit de filtrer les objets de l’Active Directory à la recherche de paramètres TrustedForDelegation valant True. Ce paramètre indique en effet la présence d’une délégation non contrainte, et est de plus accessible sans privilège particulier, par exemple à l’aide de la commande Get-ADComputer du module ActiveDirectory :

Une fois les services disposant d’une délégation Kerberos non contrainte identifiés, il est nécessaire d’obtenir des privilèges administrateur sur l’un des serveurs sur lesquels ils sont utilisés. Les méthodes de compromission classiques peuvent alors être utilisées, mais ne seront pas abordées dans cet article.

En cas d’accès au service par un administrateur du domaine, l’attaquant sera en mesure d’extraire le TGS fourni à l’aide par exemple de l’outil mimikatz et de la commande suivante :

Comme indiqué dans le scénario d’authentification, ce TGS contient le TGT de l’administrateur, que l’attaquant pourra extraire afin de réaliser une attaque Pass-The-Ticket pour se connecter au contrôleur de domaine.

Les recommandations pour protéger un domaine d’une telle attaque sont alors les suivantes :

• Utiliser des délégations Kerberos contraintes qui sont plus restrictives
• Configurer l’ensemble des comptes à privilèges avec le paramètre « Le compte est sensible et ne peut être délégué » qui empêche la réutilisation de l’identité du compte par une application possédant une délégation

Dans le cas d’un domaine au niveau fonctionnel supérieur à Windows Serveur 2012 R2, le groupe de sécurité « Utilisateurs protégés » peut être utilisé pour les comptes à privilèges étant donné que les délégations ne sont pas autorisées pour les comptes de ce groupe.

Qu’en est-il des délégations contraintes ?

L’utilisation de délégations contraintes semble être une alternative plus sécurisée. Cependant, différents éléments sont à noter concernant ce mécanisme d’authentification, comme l’a présenté Matan Hart lors de la Black Hat 2017. En effet, les deux extensions de protocole utilisées ont été pensées avec les principes suivants :

• Les deux extensions permettent à un service Kerberos d’obtenir des TGS sans même que l’utilisateur n’ait besoin de s’authentifier auprès du contrôleur de domaine.
• L’extension S4U2Self permet au service d’obtenir un TGS pour l’utilisateur sans qu’aucun mot de passe ne soit nécessaire.

De ce fait, un service qui possèderait les deux extensions pourrait obtenir un TGS pour n’importe quel autre service en se faisant passer pour un utilisateur, et ce sans nécessiter son mot de passe.

Matan Hart a publié son outil « Mystique[1] » qui permet d’identifier des configurations à risque pour les délégations. Pour cela, il liste les comptes qui disposent du paramètre TrustedToAuthForDelegation valant True, indiquant une délégation contrainte, ainsi que d’un paramètre MsDS-AllowedToDelegateTo non nul, indiquant l’utilisation d’un SPN, ce qui est obligatoire pour les comptes de délégation.

Il est également à noter que les TGS sont validés selon deux critères, le hash du mot de passe de l’utilisateur, et le SPN possédé par le compte de service qui possède la délégation contrainte. En cas de multiples SPNs associés à un même compte de service, et de mot de passe partagé entre différents comptes, les tickets pour deux services distincts seront complétement interchangeables, ce qui pourrait permettre à un service de réutiliser l’identité d’un utilisateur de manière illégitime.

Ces faiblesses ne sont pas considérées comme des vulnérabilités par Microsoft, et ne sont donc pas amenées à changer. Lors de la création d’une délégation Kerberos contrainte, il est alors nécessaire de faire attention aux points suivants pour se protéger des attaques :

• Configurer les services à l’aide de comptes de service dédiés, évitant ainsi le partage des comptes qui pourrait aboutir à des tickets interchangeables. Il est également important d’assurer une bonne complexité des mots de passe, ainsi qu’une rotation régulière.
• Configurer des SPNs uniques comme étant autorisés pour la délégation, en évitant les SPNs par défaut de Microsoft, et en spécifiant les ports utilisés.
• Comme pour les délégations non contraintes, configurer les comptes à privilèges comme étant des comptes sensibles ne pouvant être délégués.

Conclusion

L’utilisation de délégations contraintes n’est pas totalement à proscrire. Il est cependant nécessaire de bien maitriser leur configuration et les ressources auxquelles elles permettent d’accéder afin d’éviter les travers détaillés dans cet article.

Cet article Compromission d’un domaine Windows à l’aide des délégations Kerberos est apparu en premier sur RiskInsight.

Une évolution indispensable de l’approche « traditionnelle »  de l’authentification

Si les solutions d’authentification classiques (normale, forte ou renforcée) constituent bien une première couche de sécurité essentielle pour la protection des ressources, force est de constater qu’elles affichent aujourd’hui certaines limites :

• L’authentification étant bien souvent le premier niveau de sécurité rencontré par un client (par exemple sur sa banque en ligne), il est aussi fort logiquement le premier à être attaqué. On constate par exemple depuis quelques années une course entre les banques en ligne pour renforcer leurs solutions d’authentification proposées à leurs clients.
• Comme souvent, la course au renforcement de la sécurité au niveau de l’authentification se fait au détriment de l’expérience utilisateur avec des solutions par toujours très ergonomiques, lors de leur activation ou de leur utilisation. Certaines (token matériel, certificats) ne sont par ailleurs pas adaptées aux nouveaux usages mobiles.

Trouver un bon compromis entre niveau de sécurité et expérience utilisateur reste pour autant un point essentiel pour des acteurs tels que des banques en ligne ou les sites de e-commerce qui savent bien qu’une authentification trop complexe risque de décourager un client d’utiliser ses services en ligne, voire de le faire abandonner un achat.

Améliorer la sécurité en ayant un impact limité sur l’expérience des clients, apporter une stratégie de sécurisation complémentaire à l’authentification, telles sont les promesses des solutions de détection de fraude dont le marché est aujourd’hui florissant. Les derniers rapports des analystes tels que Gartner ou Forrester montrent bien l’expansion de ce type de solution, ces derniers évaluant désormais plus de 40 solutions dans leurs études.

La fraude en ligne : quelle stratégie adopter ?

S’il existe aujourd’hui un marché très riche de solutions de détection de fraude en ligne, on retrouve une approche souvent semblable, s’articulant autour de trois piliers.

Le premier enjeu consiste à collecter un maximum d’informations afin de permettre une évaluation du contexte dans lequel se présente un client et d’estimer si les opérations qu’il est en train de réaliser sont légitimes. À ce titre, différents types de données peuvent être pertinentes à collecter :

• Des données liées au contexte de connexion de l’utilisateur, telles que le fingerprint de son device, l’IP, la localisation et l’horaire de la connexion, ainsi que des données techniques permettant par exemple de détecter la présence de malwares connus.
• Des données de type comportemental liées à l’interaction de l’utilisateur avec son device et son environnement : habitude de navigation sur un site web ou biométrie comportementale telle que la manière de frapper au clavier, de bouger sa souris, de remplir des formulaires,…
• Des données métier propres aux opérations réalisées par un utilisateur : type de bénéficiaire ajouté pour un virement, montant d’un achat en ligne,…

Une fois ces données collectées, les solutions de détection de fraude en ligne vont chercher à mettre en œuvre des stratégies permettant d’exploiter en temps réel ces données pour juger de la dangerosité de l’opération en cours. Ces stratégies consistent en général à définir des règles de détection (ex : interdire une opération depuis un pays à risque, lever une alerte en cas de connexion sur de multiples comptes depuis le même device en un cours délai,…) et à utiliser des profils comportementaux dans une logique de scoring. Dans ce second cas, des écarts trop importants par rapport à l’usage « habituel » pourra être considéré comme risqué et déclencher une action de la part de la banque ou du site de e-commerce.

Comment traiter les contextes suspects ?

Ces solutions de détection de fraude en ligne présentent donc de nombreux avantages :

• Tout d’abord, elles ne se substituent pas aux solutions d’authentification classiques, mais on bel et bien pour objectif de renforcer et compléter cette première couche de sécurité.
• Ce renforcement de la sécurité est, dans la majeure partie des cas, transparente pour les utilisateurs, a minima lorsqu’aucun contexte suspicieux n’a été détecté. En cas de détection d’un contexte suspicieux, ces solutions ont également l’avantage de pouvoir adapter les réponses apportées en fonction du niveau de risque quantifié. Ainsi, des contextes de connexion fortement suspects peuvent conduire par exemple à redemander une authentification à l’utilisateur, demander une authentification avec un niveau de sécurité plus élevée, bloquer l’opération ou encore notifier l’utilisateur via un canal tiers. En revanche, lorsque le niveau de risque détecté reste modéré (bien que plus élevé que pour un contexte « normal »), le traitement de ce dernier peut également être transparent pour l’utilisateur, par exemple en alertant simplement le centre antifraude du fournisseur de service sans pour autant bloquer ou alerter l’utilisateur.
• Enfin, une meilleure détection de ces fraudes ou tentatives de fraudes en amont permet d’alléger et simplifier les chaines de traitement des dossiers de fraude en aval, lorsque ces dernières sont avérées.

Parallèlement aux avantages sus-cités, certaines questions ou points d’attention doivent être pris en compte avant de déployer ce type de solutions.

• Des phases pilotes en amont du déploiement sont indispensables afin de s’assurer que les règles implémentées conduisent à des taux de faux positifs / faux négatifs acceptables. Par exemple, des taux de faux positifs trop importants peuvent rapidement dégrader l’expérience utilisateur et générer de l’incompréhension (pourquoi me demande-t-on une seconde authentification ? pourquoi suis-je bloqué ? j’ai reçu une notification par mail, ai-je réellement été piraté ? etc.).
• Ces solutions, si elles ont pour but de réduire le nombre de fraudes, ont également pour conséquence d’augmenter le nombre d’alertes en amont, comme dit précédemment. Il est donc indispensable, pour le fournisseur de service, d’être en mesure de traiter ces alertes remontées et donc dimensionner les équipes en charge de ces traitements en conséquence.
• Enfin, afin de complexifier le contournement (toujours possible !) de ces solutions par les hackers, il est important notamment de diversifier au maximum les types de données collectées, les règles utilisées pour évaluer le risque de fraude, de s’assurer que les traitements de ces données sont bien réalisés côté serveur et non côté client, etc.

Cet article La fraude en ligne : comment la détecter et s’en prémunir ? est apparu en premier sur RiskInsight.

Authentec, une cible inattendue pour Apple

En annonçant le rachat d’Authentec pour 356 millions de dollars, Apple a surpris le marché. Il s’agit en effet d’un achat au prix fort, Authentec réalisant quasiment 70 millions de dollars de chiffre d’affaires et étant actuellement déficitaire avec une perte nette de 10 millions de dollars. C’est  une des opérations les plus importants pour Apple. Cible inattendue, d’autant que la sécurité n’est pas au cœur du métier d’Apple, connu pour ses solutions grand public.

Une stratégie pour acquérir des brevets de premier plan sur la sécurité ?

Authentec est une société bien installée sur le secteur de la téléphonie mobile, elle compte aujourd’hui pour clients des géants du secteur comme Samsung, Nokia, Motorola… Et surtout cette société détient plus de 200 brevets sur de multiples solutions de sécurité (protection des données, communication sécurisée…), et en particulier les brevets « fondamentaux » sur l’authentification biométrique. De là à imaginer qu’Apple voudrait renforcer son arsenal de brevets, il n’y a qu’un pas ! Cela serait une mauvaise nouvelle pour l’innovation… Nous observons tous les jours les effets délétères des guerres que se livrent les grands acteurs du secteur : Oracle et Google, Apple et Samsung, et bien d’autres…

Les récentes annonces font pencher la balance vers l’innovation !

Des documents récemment révélés par la SEC (le gendarme de la bourse aux Etats-Unis) montrent que cette acquisition a été réalisée de manière rapide, apparemment avant tout pour garantir l’approvisionnement en composants auprès d’Apple. Voilà qui pourrait cacher les futures innovations qui seront peut être présentes dans l’iPhone 5 ? En effet, Authentec dispose de technologies qui lui permettent d’intégrer des lecteurs d’empreintes digitales de manière simple dans les smartphones. Les derniers produits présentés permettraient même d’imaginer un lecteur d’empreintes digitales dans le bouton « Home » de nos iPhone !

Une idée qui pourrait plaire à Apple pour simplifier l’authentification de ses clients et ainsi faciliter l’adoption de technologie comme le NFC, mais aussi constituer un avantage distinctif de son futur système de « portefeuille virtuel » Passbook ! L’utilisation d’authentification biométrique pourrait à la fois simplifier la vie de l’utilisateur (plus de mots de passe…)  et rassurer les cybermarchands (diminution des cas de fraude…).

Voilà donc un rachat qui pourrait s’avérer une avancée significative dans l’adoption de mécanismes de sécurité dans le grand public ! Croisons les doigts et attendons peut-être le 12 septembre pour voir si la prochaine « Keynote » révèlera les plans du géant à la pomme dans ce domaine.

Cet article Apple et Authentec : guerre des brevets ou réelle innovation ? est apparu en premier sur RiskInsight.

C’est une erreur assez classique. Authentifier un individu consiste à lui demander une preuve de son identité. Il existe trois catégories de facteurs d’authentification : ce que je sais, ce que j’ai, ce que je suis.

La biométrie peut ainsi permettre d’authentifier une personne, avec cependant une marge d’erreur non négligeable. Ce n’est pas une science exacte : elle dépend de la qualité de la solution mise en œuvre (en particulier des capteurs) et du seuil de sensibilité choisi (un compromis est à trouver entre ergonomie et sécurité).

Une authentification forte nécessite la combinaison d’au moins deux facteurs d’authentification. La biométrie seule ne peut donc pas être considérée comme une authentification forte.

Pourquoi les technologies biométriques ne sont-elles pas plus largement déployées et utilisées ?

Effectivement, la biométrie est encore relativement peu utilisée en entreprise, contrairement aux usages grand public. Les premiers usages sont apparus au milieu du XIXème siècle comme par exemple l’identification systématique de l’empreinte de la main sur des contrats en Inde pour éviter l’usurpation d’identité au moment de toucher les salaires. Les déploiements s’accélèrent aujourd’hui autour des passeports et de cartes d’identité biométriques.

Même si cela a tendance à désormais s’estomper, les utilisateurs sont quelque peu réticents dès qu’on leur parle de biométrie (crainte de l’effet « Big Brother »). Par ailleurs, les règlementations, notamment la CNIL en France, sont très contraignantes : tout usage SI de la biométrie nécessite une demande d’autorisation préalable, et généralement celle-ci n’est pas accordée pour les biométries à trace utilisant des bases centralisées.

Enfin, d’un point de vue technologique, les coûts d’acquisition importants et l’absence de standardisation et d’interopérabilité, demeurent également deux freins notables.

Finalement, quels sont aujourd’hui les usages de la biométrie en entreprise ? Et quelles tendances se dessinent à moyen terme ?

En entreprise, les déploiements restent encore bien souvent circonscrits à des périmètres métiers spécifiques et limités à quelques centaines de personnes (ex : consolidation financière, trading), voire à des vitrines technologiques de la DSI. Seulement quelques entreprises ont déployé des solutions de biométrie / carte à puce sur des périmètres plus larges (quelques milliers de personnes).

Le développement de nouveaux usages domestiques (lecteurs sur les équipements grand public…) et la généralisation des pièces d’identités biométriques vont faire entrer ces technologies dans le quotidien des utilisateurs et lever progressivement leurs craintes. De plus, l’essor de la biométrie sans trace devrait permettre un assouplissement du cadre règlementaire.

Enfin, les coûts des capteurs individuels devraient baisser significativement dans les années à venir. Tout semble donc réuni pour que l’usage de la biométrie en entreprise décolle… Reste à trouver la « killer app » !

Cet article Biométrie : où en est–on dans les entreprises ? est apparu en premier sur RiskInsight.