What should we do with passwords until they are no longer in use? How can we minimise the impact of what is the main sticking point in the user experience, whilst improving the security posture of our organisation?

Why are passwords so common?

Since ancient times, passwords have been used as the means of entry to secret clubs and underground factions. The historical access management system of “if I have the secret, then I have the right to entry” has since transformed into a way of proving one’s identity – “if I have the secret then I am who I say I am”. Inserting characters in a certain order known only to the user with right of access, thus has become the solution to allow them to prove their identity.

Although the weaknesses of this system were quickly realised, if the computer systems were not connected and therefore, they required physical access, the attack surface remained limited in comparison. The password has therefore become a pillar of IT security and is used in almost all services requiring user management.

However, the arrival of networks (the Internet, in particular) and the resulting growth in exposure has turned password-related security weaknesses into real vulnerabilities.

How did we come to burden the user with such complexity?

The number of possible attacks on passwords has gradually led security experts to increase the number of safeguards designed to protect passwords.
As a result, a certain number of measures are now taken to secure passwords and their associated processes, making the user experience even more complex. For instance:

• Minimum number of characters
• Complexity (1 number, a letter, a special character, etc.)
• List of forbidden words
• Recommendation of password uniqueness between services
• Periodic renewal & history

These rules, largely based on past National Institute of Standards and Technology (NIST) recommendations, NIST.SP.800-63-2, 2015, and that could be found in most of framework (UK, French, etc.) negatively impact the user experience. Often unintuitive and different from one service to another, users sometimes find it challenging to understand them: lack of clear explanations on the expected complexity, no display of incorrect attempts remaining before the account is locked, or variations in access channels resulting in differing experiences (accessibility of some special characters different from one terminal to another, for example: the “§” character on an iPhone or an iPad).

And is it effective?

Despite all these measures, the password is still criticized for its low level of security, because it is based on two principles that are not compatible with a high level of security.

The very principle on which the password is based, the shared secret, leads to two attack vectors:

• Data in transit – transmit the secret regularly: the password can then be leaked or stolen via a proxy that is too informative in its logs, caching in the shared memory of a smartphone, or keylogger-type malware, etc.
• Data at rest – storing the enterprise password to verify it: the use of storage methods with low security levels is still too common (reversible encryption instead of non-reversible hash, old sha-1 type protocol, no salting, or worse, plain text storage).

And even more recent hash protocols remain potentially fallible in the face of current computing power. Thus, even with a recent hash protocol like sha256, retrieving an 8-character password from its hash will take… less than a day.

Attackers can then directly retrieve the password, ignoring its complexity (except for the length for brute force and storage if using a recent, robust, and regularly updated hash protocol).

The volume of human beings in the system and their capacity to make mistakes has an even greater impact:

• We are bad generators of randomness: this explains the lists of the most common passwords that appear every year. And, with strong constraints on creation, the possibilities of variations are lower, making the level of entropy decrease. The imposed complexity is counterproductive.
• We have a bad memory: encouraging practices that lower the level of security (use of a derivative or even the same password – 63% of users admit to this practice – post-it notes on the desktop, unencrypted .txt files, etc.)
• We are easy to trick: phishing, spearphishing and social engineering are widespread attack vectors.

If the user provides his password to the attacker, it does not matter if it is 60 characters long or consists of letters from different alphabets.

The complexity of the password has no influence on the most common types of attacks, and therefore only causes inconvenience to the user.

What to do?

As password issues are not new, there are several possible solutions that can be used in conjunction to reduce the problems and their impacts. The delegation of authentication to third-party services (social login, enterprise IAM, etc.), and the implementation of Single Sign-On have facilitated user experience and limited password replay/transitions and places where the password is stored at rest.

The development of second authentication factors (OTP SMS or mail, push notification, hard tokens, etc.), the most recent ones being less intrusive and less disruptive, ensures better security.

In addition to these solutions, which are already proven and widely deployed, and in anticipation of being ready to enter the passwordless world, which alone is a huge project, NIST and other frameworks recently revised their recommendations regarding the required complexity around passwords (NIST.SP.800-63b, 2017, NCSC UK, Password policy: updating your approach, 2018 for example).

So, from a user point of view, the constraints on passwords have been reduced to a minimum number of characters (8) and the rejection of common/compromised passwords. In exchange, user-facing measures offering more freedom to the user are often recommended:

• All Unicode characters, including space, must be allowed, without being forced
• The maximum size limit must be at least 64 characters
• Rotations should no longer be time-based, but only in case of compromise
• The user must have at least 10 attempts before being blocked
• Different user experience improvers are to be considered (clear information on the expected complexity, ability to display the password during input, ability to paste values, etc.)

These new recommendations aim to guide users towards the use of longer and more random passwords by reducing constraints. They can be accompanied by the raised awareness and usage of safe passwords, preventing the user having to remember too many passwords.

The remaining recommendations, mandatory to ensure security levels are not reduced, reinforce some of the aspects mentioned above. Those measures also aim to strengthen transmission (encryption, etc.) and storage (hashing, salting) to increase the level of security of the company’s activities and to prevent the use of certain practices that lower security (use of secret questions for password reset, etc.).

Conclusion

If the elimination of the password is a goal, its eradication is far from complete. It is necessary, before reaching this goal, to implement measures that aim to secure user data (for example by implementing multi-factor authentication on sensitive services) while facilitating the process and users to protect themselves. This includes the implementation of elements that prevent the user from logging in too often or creating too many passwords, but also by redesigning the complexity of passwords in order to increase the randomness, and by upgrading the technical means of transmission and storage.

Using existing processes to prepare for future changes is also essential. For example, redesigning the password recovery path to move the user toward passwordless authentication can help make a smooth transition to greater security while improving the user experience.

Cet article The evolution of the NIST password complexity rules: a mandatory step before a passwordless world? est apparu en premier sur RiskInsight.

In particular, with the explosion of the IoT and regulations such as DSP2, the need to trigger uncorrelated authentications from the  user’s medium access become more pressing: indeed, the later may not have the necessary interfaces, or may not be recognized as a sufficiently secured support.

The additional cinematic CIBA, Client Initiated Backchannel Authentication Flow aims to define the exchanges and calls allowing to trigger such authentications. This first article aims to briefly describe the high-level operation of this cinematic, and to present the contributions and additional use cases that it can cover.

What is CIBA?

CIBA is a new authentication flow and authorization of the OpenID Connect standard, defined by the Open ID foundation.

The CIBA flow is the first OpenID flow qualified as ‘’decoupled’’, because it introduces the notions of Consumption Device (CD) and Authentication Device (AD). The CD is the device on which the access to a service (Relying Party, RP) is requested, whereas the AD is the device on which the user authenticates  themselves  with the OpenID Provider (OP) and authorizes the CD-requested access, by giving its consent.

Contrary to the other flows of the OIDC standard, CIBA considers that the user can authenticate on a device different from the one on which he wants to access the service. For example, a user is looking to access his bank account from his computer and authenticate themselves to authorize the access from his smartphone.

What contributions?

The CIBA flow presents several significant interests for users’ authentication.

Today’s OIDC authentications flows are relying on web redirection between the accessed service (Relying Party) and the identity provider. These redirections are not very user-friendly and might be disturbing for the users, who see their browser, or their application go from a page to another without really understanding this behaviour. With CIBA, the device that the user employs to access the service stays on said service’s page, waiting for user authentications to be executed on the AD. The redirections’ disappearance also improves the Relying Party’s acceptance, which does not lose control and visibility of the user’s action when the latter must authenticate themself to the OP anymore.

Gains by population

The multi-factor authentication (MFA) is more and more common and recommended to access internet services. Texts, soft-tokens or Out-Of-Band push notifications are several examples of additional authentication factors, used today in addition to a password. With CIBA, this factor’s presence is a natural part of the authentication, since it is carried out on a registered device like AD. Asking the users to authenticate themself on the AD with a password, a PIN, a biometric factor, etc… allows a centralization of the authentication actions on a single device, while allowing to do some  MFA.

Use case examples

The call centre

Nowadays, when a client rings a call centre, the operator often verifies the client’s identity with several personal inquiries (date and place of birth, social security number) or with security inquiries. This authentication method is particularly vulnerable to attacks, such as social engineering.

Thanks to CIBA, it is possible for the operator to trigger an authentication request for callers on their Authentication Device, and thus ascertain the client’s identity in a more secure fashion.

Virtual assistants

DSP2 imposes banking organisations to ascertain the identity of the person carrying out an operation over a certain threshold, which mandatorily passes through an authentication phase (2 factors) during a transfer, for example. However, IoT such as the voice assistants do not have an interface allowing the user to input their identifiers, and force the customer to validate a transfer request on a web portal via his smartphone or his PC, which is not the ideal user experience. CIBA is used to free oneself from this constraint, because the customer’s bank is then able to send an authentication request on the adequate terminal (AD), limiting the impression of a break in course for the customer.

Conclusion

The authentications cinematic CIBA fills real weaknesses of the OpenID Connect protocol, both in terms of functional coverage and customer experience. It’s implementation in the real world should happen quickly, and numerous market players are already looking to implement it.

Cet article FAPI-CIBA: How to authenticate my user without an interface? est apparu en premier sur RiskInsight.

In recent years, companies have faced an expansion in the scope of Identity and Access Management (IAM) activities. They no longer concentrate solely on user provisioning and authentication; focus has shifted toward both account review and certification and the use of identity federation mechanisms (for example, SAML). The changes affect both SaaS and those that remain in-house. These two developments mean that ISs have an ever-broader scope—and it’s vital that they are implemented properly to minimize security vulnerabilities.

These developments in IAM are running in parallel with more widespread use of cloud services, which are continually being used in new ways to increase the scope and flexibility of IS access and use. Internal users accessing an IS are increasingly doing so from outside the corporate network—and from an increasingly diverse range of devices.

In addition, new Agile and DevOps technologies are forcing ISs to evolve in a different direction: integrating new technologies (IoT, etc.) and new uses, much more rapidly.

Today, all these developments make an IS one “bubble” among others, interacting with its environment and remotely controlling interactions between decentralized components.

…MAKING APIs ESSENTIAL

This new, decentralized IS model raises the problem of the interconnection of services and applications: How can you ensure a controlled access to data at all times—and in all places?

Today, APIs are already a predominant and essential communication mechanism for any company embracing digital transformation. They are used to process not only public data (branch addresses, transport timetables, etc.) but also personal data (for example, fitness tracker, health insurance, and government benefits apps) and sensitive data (online payments, e-commerce, mobile industrial information, etc.).

And, given their importance to ISs, the challenge of securing APIs becomes more important than ever.

WHAT’S THE RIGHT RECIPE TO SECURE YOUR APIs?

Securing APIs requires a recipe based on four ingredients, all of which must be carefully measured out.

THE SECURITY AS USUAL BASELINE

In a Wavestone benchmarking exercise on web application security, of the 128 applications we audited, serious flaws were observed in 60%. In this respect, and since APIs are just a kind of web applications, the standard web-security recommendations – for example those for OWASP – Open Web Application Security Project, must be taken into account in just the same way.

Essentially, this ensures that a web application’s main areas of risk are covered, and the appropriate security measures determined.

A pinch of OAuth

OAuth is an authorization delegation framework that allows an application to obtain permission to access a resource on behalf of a user.

OAuth2 is designed to cover a wide range of use cases (web applications, mobile, access [or not] via a browser, server-to-server access, etc.), and, to this end, it offers four main process flows to obtain a token (RFC 6749). Together combined with a specification detailing the use of this token (RFC 6750), a document detailing the threat model (RFC 6819), and a dedicated authentication overlay (OpenID Connect), results in a body of documents that runs to some 250 pages, leaving room for a broad range of implementation options and choices.

What’s more, it’s this abundance of options—and lack of constraints—that lead to the security flaws regularly observed in the implementation of OAuth2.0: the misuse of an application, access to personal data of a third-party user, the theft of Facebook/Google cookies when logging in using social media, or the compromise of a user’s account.

The following six recommendations are essential in ensuring the framework is securely implemented:

• Local storage of secret information: The client application is provided with identifiers enabling it to authenticate itself with the OAuth server; so, don’t put this secret information (the service identifier) in the mobile application; and, if you do, consider it compromised
• Redirected URLs: Validate redirected URLs strictly with the application, without the use of wildcards
• Implicit: Avoid implicit grant as far as possible (and strictly reserve it to client-side javascript applications)
• Authorization codes: Validate authorization codes strictly, as well as the associated clients
• State and PKCE: Use these to ensure the integrity of the entire series of process steps
• Authorization ≠ Authentication: Use OpenID Connect to authenticate, but OAuth to delegate access

LIMIT THE ADDITIVES

As soon as this first pinch of OAuth has been swallowed, you need to start thinking about the security measures to meet the most frequent needs.

The Single Sign-On mobile… or, how to enable mobile employees or clients to easily access multiple applications without reauthenticating?

It might be a field agent in a customer-facing role, or making a series of interventions at different sites, all while using a good dozen of applications every day; or it might be a client who’s installed several applications on the public app store and needs to access them all, without having to reauthenticate on each… Today, these are all very common scenarios. Although, since 2008, the techniques that make it possible have varied depending on the possibilities offered by the mobile OS (iOS’s KeyChain, URL parameters, Mobile Device Management, etc.), Apple and Google converged toward a common solution in 2015: the use of the browser system as an anchor point for an SSO session. This is now officially good practice, formalized in “Best Current Practice – OAuth2 for native applications.”

Contextual authentication… or, how to match the access level to the data, according to its criticality

One of the many issues concerning authentication is to simplify, as much as possible, user access to data, while still guaranteeing satisfactory levels of security. Contextual authentication provides an answer to this issue, adapting the level of access to the nature of the transaction: its characteristics, user habits, context, and so on. This is termed LOA (Level of Assurance). A mobile banking application, for example, allows the user to access their bank account, and see account balances, without having to reauthenticate each time these are accessed. However, the application will require authentication when performing a sensitive operation (transferring money between their own accounts, for example), and strong authentication when performing a very sensitive operation (adding an external recipient for a transfer, for example).

The market now offers solutions designed according to a logic where the application client is responsible for initiating the LOA request that corresponds to the data or service it requires. But the real need is to define and apply these data access policies at a single point within the authorization server. This is essential when there’s a need to apply an authentication proportionate to the level of risk (geolocation, is it a known terminal or not, transaction habits, etc.).

Identity propagation… or, how to pass an access token between two (or more) applications.

It is increasingly common that a call to an API triggers a cascade of calls to other APIs, in particular within a micro-service-type architecture setting. The transmission of the identity of the user must then be assured while still maintaining security. And the first three solutions that come to mind have limitations:

• The transmission of the initial token is obviously to be avoided, in view of the very high risk of internal fraud involved.
• Caller authentication alone is not enough either, because a compromised link in the chain can result in the theft of any user’s identity, thus compromising the rest of the chain.
• The generation of a caller token, transmitted along with the initial user’s token, does not assure the integrity of the user/API combination, and does not validate the chain.

However, an advanced initial solution does currently exist, in the form of a new grant type: Token Exchange. This mechanism allows the caller to request an intermediate token, which includes the identity of the user, the caller, and the call chain already made. This new series of process steps makes it possible to centralize the calls policy between micro-services, as well as its application, thereby ensuring the traceability of calls.

Protecting against token theft… or, how to guard against the theft of a token base?

As a rule, the token contains a good deal of information about its holder, entailing significant risks if stolen. More striking still is the fact that, in some contexts (for example, new standards on electronic payments such as those in the modified European Payment Services Directive [PSD2]), a third party (aggregator) may be in possession of many tokens, and the owner of the API is then effectively at the mercy of this third party and its level of security. Because theft is very difficult to detect, there was a need to find other solutions such as Token Binding: a negotiation mechanism using two or three components to link a token to a pair of cryptographic keys, and where the client must prove that it owns the private key that makes up part of this pair by establishing a mutual TLS connection with the API.

WRITING THE RECIPE DOWN

What’s the last ingredient of the recipe? The need to set out a reference architecture for OAuth in order to adapt it to the context of the company’s IS. To do this, the API framework must be defined, by:

• Defining and sharing the security rules: The authorized process steps and the application framework, the security checklists, and the reference architecture must all be formalized.
• Training and equipping developers: There will be a need to organize training sessions, and presentations on the principles to adopt. Project teams can be made autonomous in terms of their integration with the rest of the IS.
• Integrating security resources into Agile sprints: The resources that act as a “security coach” must be identified in order to support the application design, provide ready-to-use solutions, and serve as an accelerator.

IN SUMMARY

In summary, rather like the recipe for a good soup, securing APIs requires a list of ingredients, ranging from the most basic to the most sophisticated, while keeping the needs and context firmly in mind.

Cet article What’s the right recipe to secure your APIs? est apparu en premier sur RiskInsight.

Il est aujourd’hui indispensable pour les entreprises de connaitre au mieux leurs clients afin de leur proposer des services toujours plus personnalisés et ainsi augmenter leurs taux de transformation.

En quoi l’arrivée de systèmes centralisés de gestion des identités clients (Customer Identity and Access Management ou CIAM) peut être une première réponse à cette problématique.

Vers une gestion unifiée des données clients

Une organisation historiquement en silos

De par la spécificité des métiers de l’entreprise, de nombreuses solutions de gestion de la relation client ont émergé ces dernières années : CRM, email et vidéo marketing, e-commerce, mobile et web analytics…

Cette multiplicité des technologies a entraîné un silotage des données des clients ; en d’autres termes, il est aujourd’hui difficile pour une entreprise de disposer d’une vue unique de ses clients. En effet, une entreprise européenne posséderait en moyenne 4,5 solutions marketing^[1], soit autant de vues de chaque client.

Avoir une vision unifiée des clients est une première étape indispensable pour les entreprises afin d’être en mesure de leur proposer des offres pertinentes.

Par ailleurs, le taux de transformation depuis les canaux numériques reste faible du fait d’un ciblage incomplet, d’offres en décalage avec les intérêts du client et d’un manque de confiance envers la marque.

Afin d’allier la transformation numérique et business, positionner l’identité du client au centre de l’organisation est une manière de traiter ces points défaillants.

Le client au centre de l’organisation

Aujourd’hui, le nombre important de solutions marketing tend à multiplier les sources de données : points de vente, canaux numériques (sites web, mobiles), service après-vente…

Le client se retrouve alors dans un modèle en « toile d’araignée » : plusieurs sources, plusieurs systèmes, plusieurs bases de données et donc plusieurs identités.

Afin d’améliorer la connaissance de leurs clients, les entreprises doivent adopter un modèle plus unifié, combinant facilité d’accès et partage des données clients : le modèle « centralisé ».

Ce modèle vise à mettre une interface unique (CIAM) entre les sources de données et les solutions marketing qui aura pour objectifs de centraliser les données clients, améliorer leur qualité et créer de la valeur business en les agrégeant dans une même identité.

Une solution CIAM couvre 3 briques technologiques :

• Enregistrement et accès: fournit des services d’enregistrement et de connexion, indépendamment du moyen d’accès (site web, mobile…) : API/SDK, fédération d’identité, social login…
• Stockage et traitement: fournit des services de stockage et de traitement des données : profiling, mise en qualité, agrégation…
• Intégration: fournit des connecteurs permettant au CIAM d’échanger des données avec les différentes solutions marketing de l’entreprise.

Un tel modèle permettra à l’entreprise de mieux connaitre ses clients et les fidéliser (Know Your Customers, ou KYC).

Mieux connaitre ses clients grâce au CIAM

Globalement, l’ensemble des services offerts par le CIAM répond à des besoins business importants : mieux connaitre les clients, simplifier leur parcours et créer une relation de confiance.

Un CIAM pour… mieux connaitre les clients

Un client satisfait est un client fidèle, mais pour le satisfaire, encore faut-il le connaitre et anticiper ses attentes. Pour cela, le CIAM vise à contribuer à l’amélioration de la connaissance des clients que nous découpons en 4 grandes étapes :

Étape 1 : client anonyme

L’entreprise ne connait pas le client mais uniquement un utilisateur qui accède à ses services. Elle ne peut donc récupérer des informations restreintes (cookie).

L’objectif est alors de proposer un moyen simple d’identifier l’utilisateur (ex : inscription à une newsletter).

Étape 2 : client identifié

Le client crée un compte utilisateur par le biais d’un compte d’un réseau social ou en remplissant un formulaire. À cette étape, l’entreprise présente les conditions d’utilisation de ses données pour consentement, récupère des informations de contact (nom, prénom, date de naissance, e-mail, téléphone) et rattache les informations récupérées en étape 1 à l’identité du client.

L’objectif est alors de le faire revenir via une newsletter ou l’envoi d’offres en lien avec son historique de navigation pour établir son profil.

Étape 3 : client connu

Au fur et à mesure des échanges avec le client, le CIAM va récupérer ses préférences (via les produits consultés, l’affichage d’un bouton « J’aime » à l’instar des réseaux sociaux qui permet au client d’indiquer simplement son intérêt pour le produit, etc.). Le profil du client commence à se dessiner et des actions de marketing plus ciblées peuvent commencer.

L’objectif est maintenant de connaitre au mieux le client et faire vivre ses données.

Étape 4 : client fidélisé

La mise à jour des préférences du client va permettre de cibler davantage les actions marketing et de le fidéliser en proposant des offres personnalisées et attractives.

Cette étape se réalise sur le long-terme, dans une approche de construction dynamique du profil du client.

Un CIAM pour… simplifier le parcours client

Un des principaux intérêts du CIAM est de simplifier le parcours client, élément fondamental à la transformation numérique.

À l’enregistrement : faire simple, faire vite !

La première raison de perte de clients potentiels est un processus d’enregistrement compliqué (trop d’informations demandées, CAPTCHA à saisir…).

Afin de simplifier ce processus, les solutions de CIAM proposent des fonctionnalités d’enregistrement en 3 clics basés sur les comptes des réseaux sociaux (ex : Facebook, Twitter, LinkedIn, Google…).

Les réseaux sociaux seront privilégiés comme source d’information du client.

À l’usage : éviter l’effet RELOU !

S’il y a une chose à ne pas retenir dans la mise en place d’un CIAM, c’est d’imposer un nouveau mot de passe au client.

Les solutions CIAM facilitent l’accès aux services en proposant des méthodes de connexion également basées sur les réseaux sociaux. Mais attention, les clients ne doivent pas avoir à se rappeler du réseau social qu’ils ont utilisé lors de l’enregistrement.

C’est à ce moment-là que les solutions CIAM permettent de rendre le plus transparent possible l’accès des clients en apportant la capacité de rattacher tous comptes de réseaux sociaux d’un client à son identité (ex : si le client s’enregistre avec Facebook, il devra pouvoir se connecter plus tard avec Twitter).

Se connecter en 1 clic pour éviter l’effet RELOU (« Réellement, Encore un Login à OUblier ! »), voilà de quoi retenir vos clients.

Un CIAM pour… créer une relation de confiance

La fidélisation d’un client passe par l’instauration d’une relation de confiance avec ce dernier en respectant le bon usage de ses données.

Aujourd’hui, le cadre légal est en pleine évolution, particulièrement en Europe avec l’arrivée de la GDPR (General Data Protection Reglementation).

L’un des points important de la GDPR est l’obligation faite d’obtenir le consentement de l’utilisateur pour tout usage de ses données.

En conséquence, le client doit à tout moment pouvoir :

• Être tenu informé des termes d’utilisation de ses données
• Accéder à ses données et pouvoir les rectifier
• Restreindre l’accès d’un service à tout ou partie de ses donnée
• Être oublié

Le respect de ces réglementations est donc primordial pour augmenter la confiance des clients qui, in fine, sont devenus la source de données principale des solutions CIAM. Cette confiance permet à l’entreprise de recueillir le maximum d’informations sur le client et d’ainsi augmenter ses taux de transformation.

CIAM et IAM traditionnel : est-ce différent ?

Bien que les solutions IAM traditionnelles et CIAM proposent des briques fonctionnelles proches (gestion des identités, authentification, publication de données…), elles présentent néanmoins des différences technologiques et d’usages significatives :

En conséquence, l’extension d’un IAM traditionnel pour gérer les identités des clients n’est évidemment pas judicieuse et induirait immanquablement un projet coûteux, la mise en place d’un système hybride non agile et ne garantirait pas l’atteinte des besoins couverts nativement par un CIAM.

En synthèse

Fidéliser un client nécessite de le connaitre. Les solutions de CIAM apportent des moyens technologiques pour centraliser et unifier la vision d’un client au sein d’une organisation, tout en respectant les évolutions des réglementations actuelles et en simplifiant le parcours client.

Malgré leurs bases communes à l’IAM traditionnel, les solutions CIAM restent des outils à enjeux marketing. Leur mise en place nécessite de sortir du cercle IT pour inclure les métiers (marketing, communication, services supports) ainsi que le juridique.

[1] PAC, No more Silos – Towards a Holistic Customer Experience Strategy, 2016

Cet article Customer IAM : l’IAM, pilier de la transformation business ? est apparu en premier sur RiskInsight.