Regal digital identity brings together all the information essential to formally authenticate an individual or organization in the digital world. This includes personal identification data, electronic certificates and biometric information. This identity is crucial for securing electronic transactions, facilitating access to online public services and protecting citizens’ rights and privacy.

In France, a program was launched in 2018 to create a high-guarantee digital regal identity. At the same time, France is committed to the introduction of a smart ID card with a chip, which will form the basis of this electronic identification. This authentication mode will be integrated into FranceConnect+ created at the end of 2021, an online identification and authentication service of minimum substantial level.

Examples of use cases depending on the target :

Companies

A potential B2E use case could be re-registration and access recovery. The use of regalian digital identity becomes particularly relevant in companies where employee authentication relies exclusively on FIDO passkeys linked to a device, often their phone. If this device is lost, the employee is unable to authenticate. With regalian digital identity, access recovery is simplified. Employees can use their digital identity to restore their access, then get a new phone and re-enroll their FIDO passkeys. In this way, the re-registration and access recovery process is greatly facilitated, guaranteeing enhanced service continuity.

On the CIAM side, banks could use regalian digital identity to verify the identity of customers when opening online accounts or carrying out sensitive transactions, and thus improve the security level of their service and their KYC (know Your Client) process. Currently in France, customers can use FranceConnect to authenticate themselves with banks such as BNP Paribas when opening online accounts, guaranteeing secure and simplified identity verification. Similarly, e-commerce sites could use the regalian digital identity to enable users to authenticate themselves securely when purchasing products, further enhancing security and reducing the risk of fraud.

In the context of the extended enterprise (a form of organization enabling collaboration between a company, its subsidiaries and its partners), the secure enrolment of partners to access the company’s information systems (IS) is crucial. The challenge is to increase the level of confidence in enrolment, while at the same time making it easier.
The use of the European Identity Wallet or other identity wallet could significantly simplify and secure this process. Partner employees could prove their identity to the company they wish to collaborate with, using their identity wallet. Here’s how it could work:

First of all, for the initial registration employees of partner organizations use their identity wallets to register with the main company’s system. Identity is then verified using electronic certificates and other secure information.
Once registration has been validated, these employees can access the main company’s information systems. The identity wallet enables secure authentication in line with corporate security standards. Or secure enrolment in the company’s local authentication systems.
The identity wallet can also be used to manage and modulate access rights according to the specific roles and needs of partner employees, reducing the risk of over-provisioning and increasing security.

If identity information changes (for example, if an employee changes position or responsibility), access can be updated seamlessly via the identity portfolio, without the need for cumbersome administrative processes.
Imagine a construction company working with various subcontractors on different projects. Subcontractors’ employees can use their identity portfolio to authenticate themselves and access project plans and documents hosted on the main company’s IS. This ensures that only authorized and verified employees have access to sensitive information, and that their access can be quickly modified or revoked if necessary.

Citizens

Regalian digital identities offer citizens numerous advantages, notably by simplifying access to various online services and reinforcing the security of digital transactions. In France, for example, insured persons can use their digital identity via the Ameli service to access their personal space. This enables them to consult their reimbursements, book appointments with healthcare professionals and manage other aspects of their medical cover securely online.

Similarly, for tax purposes, French citizens can use their régalienne digital identity via impots.gouv.fr. This feature facilitates online tax declarations, enabling users to fill in their returns, consult their tax notices and track their payments and refunds simply and securely.

Beyond France, other European countries are also implementing digital identity solutions to improve access to public services. Students, for example, will benefit greatly from the regalian digital identity for their administrative procedures. They will be able to use it to enroll in universities, access their transcripts, and manage their student accounts in a secure and simplified way. What’s more, international students will also be able to use this identity to validate their residency status and access various public and academic services without the hassle of paper procedures.

In Spain, regalian digital identity enables citizens to electronically sign official documents via the FirmaDigital.gob.es service. This solution is used for tasks such as signing rental contracts, submitting administrative documents, and other procedures requiring a legal signature. This makes administrative processes more efficient and secure, eliminating the need for physical signatures and reducing the risk of fraud.

The European Identity Wallet (EUDI)

The European Identity Wallet (EUDI Wallet) is a major initiative by the European Commission to provide EU citizens with a secure, interoperable way of managing their digital identity across borders. Designed to offer a convenient and secure solution, EUDI Wallet will enable citizens to store and share their electronic credentials seamlessly, while preserving their privacy and complying with the EU’s strict data protection standards.
This concept emerges against the backdrop of the increasing digitization of European society and the need to reinforce trust in online transactions. With the diversity of electronic identification systems used across the EU, EUDI Wallet aims to harmonize these systems and facilitate access to cross-border digital services, such as public services, commercial transactions and online interactions with businesses.
The EUDI Wallet will therefore function as a secure digital wallet where citizens can store their identification information such as electronic certificates, biometric data and identity documents. They will be able to use this wallet to authenticate themselves online and access a range of digital services across the European Union.
With the EUDI Wallet, citizens will be able to easily access their healthcare data, such as patient summaries and electronic prescriptions, anywhere in the EU, promoting better continuity of care. In addition, Wallet will enable diplomas and professional qualifications to be securely managed and verified, simplifying the recognition of qualifications and promoting worker mobility. Finally, it will facilitate online transactions by ensuring strong, harmonized authentication, thereby boosting confidence in cross-border e-commerce.

In order to carry out these use cases, the European Commission has defined two main scenarios describing very basically the portfolio’s use flows;

To date, the countries of the European Union have agreed on the content to be included in the European wallet, and have agreed on a global standard for the project, with a target implementation date of 2026. What remains to be done is to finalize the standard, draw up precise technical specifications for it, and develop the technical solutions to be implemented in each European country to ensure compatibility with the established standard.

Conclusion

The introduction of the European Identity Wallet (EUDI Wallet) represents a crucial step towards a more integrated and digitized digital Europe, offering numerous benefits to citizens and businesses across the European Union. In France, the adoption of EUDI Wallet will depend on several key factors. Firstly, the establishment of a robust regulatory framework that complies with data protection standards such as the RGPD will be essential to ensure user confidence and the security of their personal data. In addition, public confidence in the security and reliability of EUDI Wallet will play a decisive role in its widespread adoption. Public awareness and education campaigns on the benefits and security measures of EUDI Wallet could help build this confidence.

However, the most important element for EUDI Wallet will be the rate of adoption by private services. The involvement of private companies is crucial, as they provide a large proportion of the services used daily by citizens. Widespread adoption by the banking, healthcare, education and other private services sectors would ensure wider and regular use of the wallet, making its integration more fluid and natural for users.

The technology is still emerging and not yet mature enough to be implemented immediately. However, given the many potential benefits, it is crucial to follow this technology closely and adopt it as soon as possible. This is particularly true for the banking sector and extended enterprise use cases, where EUDI Wallet could bring significant improvements in security, transaction fluidity and operational efficiency.

Nevertheless, by overcoming these obstacles and taking advantage of the opportunities offered by EUDI Wallet, France could play a leading role in building a more secure, innovative and connected digital Europe for years to come.

Cet article The European identity wallet, the digital identity of the state soon to be in our pockets est apparu en premier sur RiskInsight.

What is the extended enterprise?

The extended enterprise is a group of entities and economic players working together on common projects. Companies have always needed to collaborate by sharing resources and exchanging data. To achieve this, the employees of each of these companies need to be able to interact securely with external users.
These external users can be suppliers, subcontractors, B2B customers, subsidiaries (that do not share the same IS), and so on. Collaboration can take many forms and can be time limited.
Because of this diversity of scenarios, it is neither possible nor relevant to define a single answer to every IAM project for the extended enterprise. The strategy to be adopted by any company wishing to address this issue will depend on its own context and specific use cases.
An extended enterprise IAM strategy can be initiated by answering two key questions: how should IAM governance and delegation be handled with the various partners? And, what type of solution on the market best covers these use cases?

What type of governance?

There are 4 main approaches to IAM governance in the extended enterprise. The choice of one of these approaches will depend mainly on two criteria: the level of IAM maturity of the various stakeholders and the sensitivity of the resources accessed.

Which vendor’s solution?

A number of functionalities clearly distinguish CIAM editor solutions (customer scope) from Workforce IAM solutions (employee scope). These two types of solutions are at opposite ends of the spectrum referring to the criteria analyzed in the diagram below.

Extended enterprise (B2B) use cases can be positioned over a wide range of this spectrum for each criterion, depending on the context. It is therefore difficult to respond to them with traditional workplace IAM or CIAM solutions, however more and more software publishers are offering new dedicated modules to meet these new needs.

What new technologies to facilitate implementation?

One of the key factors in the success of an extended enterprise project is the ability to decentralize IAM processes and mechanisms. The technological advances presented in the table below make it possible to rethink traditional approaches to identity and access management from this angle. They offer more flexible solutions, adapted to the diversity of use cases encountered, thus enabling greater decentralization, particularly with less mature partners, thanks to identity wallets and passkeys:

In this quest for solutions adapted to a wide range of use cases, it is imperative to keep abreast of market developments and constantly assess the relevance of proposed solutions to the specific needs of each context.

Cet article Which IAM for the Extended Enterprise? est apparu en premier sur RiskInsight.

Pourtant, le volet IAM « Identity and Access Management » est souvent relégué au second plan dans les Programmes de mise en conformité LPM/NIS mis en œuvre par les Opérateurs d’Importance Vitale (OIV) / Opérateurs de Service Essentiel (OSE).

Comment comprendre cette situation et quelles leçons en tirer pour construire sa feuille de route IAM pour ses infrastructures critiques ?

L’IAM est un des piliers du volet cybersécurité de la LPM/NIS

Les mesures IAM à mettre en place sur les infrastructures critiques sont décrites dans les quatre règles suivantes :

Auxquelles il convient d’ajouter la règle portant sur les indicateurs (règle 20 pour la LPM et règle 4 pour NIS).

Les bonnes pratiques IAM habituelles à appliquer à tous les accès

Les exigences des trois premières règles reprennent les bonnes pratiques habituelles à appliquer à la gestion des comptes et des droits, tant pour les utilisateurs physiques que pour les processus automatiques accédant aux infrastructures critiques :

• Gérer le cycle de vie des utilisateurs, notamment les mutations et départs
• Affecter les droits selon le principe du moindre privilège
• Revoir (ou recertifier) régulièrement les droits affectés, a minima annuellement
• Contrôler et auditer les droits
• Attribuer des comptes et des moyens d’authentification strictement nominatifs

Le cadre ci-dessous résume les règles concernées :

Ces règles fixent un cadre mais laissent une grande liberté aux Opérateurs pour les décliner dans leur contexte.

Des comptes d’administration dédiés et soumis aux mêmes exigences

La quatrième règle (n°14 LPM et n°11 NIS) traite spécifiquement des comptes d’administration, destinés aux seuls personnels en charge de l’administration des infrastructures critiques : installation, configuration, maintenance, supervision, etc. L’exigence forte est la mise en place de comptes d’administration dédiés à la réalisation des opérations d’administration.

Au-delà du principe de moindre privilège explicitement mentionné, les comptes d’administration doivent respecter les mêmes exigences que les autres comptes telles que décrites précédemment.

Des indicateurs à produire pour surveiller les comptes à risque élevé

Enfin, la règle sur les indicateurs prévoit la définition de plusieurs indicateurs concernant la gestion des comptes présentant un niveau de risque élevé :

• Pourcentage de comptes partagés
• Pourcentage de comptes privilégiés
• Pourcentage de ressources dont les éléments secrets ne peuvent pas être modifiés

Au vu de ces exigences, l’intégration des infrastructures critiques dans les outils IAM (ci-après appelés « l’IAM ») de l’Opérateur apparaît comme la réponse nécessaire ; à compléter par l’application de mesures de durcissement (suppression, désactivation ou changement de mot de passe des comptes par défaut).

NB : les exigences LPM et NIS étant très similaires, nous emploierons par la suite le terme « OIV » pour désigner aussi bien les Opérateurs d’Importante Vitale et les Opérateurs de Service Essentiel, et le terme « SIIV » pour désigner les Systèmes d’Informations d’Importance Vitale et les Systèmes d’Informations Essentiels.

Pourtant, les Opérateurs hésitent encore à raccorder leurs infrastructures critiques à l’IAM

Les règlementations LPM et NIS ont accéléré la mise en place et le déploiement de solutions de bastion d’administration afin de sécuriser les accès d’administration. Cependant, bien que ces projets soient nécessaires, ils ne permettent de répondre que très partiellement aux exigences évoquées précédemment.

Ces règlementations devraient pourtant être un bon driver pour les projets IAM, mais les Opérateurs sont confrontés à deux principaux problèmes :

• La complexité d’intégration des systèmes industriels avec l’IAM – pour les Opérateurs industriels.
• Le risque induit par le raccordement des infrastructures critiques à l’IAM.

Des systèmes industriels complexes à intégrer

Les systèmes industriels présentent en effet des spécificités qui, d’une part complexifient le raccordement à un outil IAM, et d’autre part le rendent moins indispensable. Car, de façon générale :

• le nombre d’utilisateurs est limité ;
• ces systèmes sont cloisonnés, voire isolés du réseau d’entreprise ;
• la maturité sécurité des éditeurs et constructeurs est en retrait, les capacités d’interfaçage sont réduites, tant pour la gestion des comptes que pour la délégation d’authentification ;
• la granularité des droits d’accès est faible, se limitant souvent à autoriser l’accès ou non à l’ensemble du système, et non fonctionnalité par fonctionnalité.

Une intégration potentiellement génératrice de risques

Mais, au-delà de ces considérations propres aux systèmes industriels, les Opérateurs sont parfois réticents à mettre en place cette intégration, car elle est perçue comme génératrice de risques. En effet, si l’outil IAM ne présente pas un niveau de sécurité à la hauteur des règlementations, il pourrait paradoxalement constituer un point d’entrée sur les SIIV et ainsi amener de nouvelles vulnérabilités : création de compte ou attribution de droit illégitime, suppression malveillante de tous les comptes, etc.

Quant à mettre en place un IAM entièrement dédié au périmètre SIIV, cela représente un investissement très conséquent, parfois disproportionné, et qui ne permet pas de tirer tous les avantages d’un IAM mutualisé, par exemples les liens avec les sources autoritaires comme le SI RH.

Différentes approches d’intégration IAM permettent de répondre aux exigences règlementaires en maintenant un niveau de cloisonnement élevé

Dès lors, comment répondre efficacement aux exigences de la LPM et de la directive NIS ? Comment tirer parti des services proposés par les outils IAM sans ouvrir de nouvelle porte sur les infrastructures critiques ?

Nous distinguons différentes approches pour intégrer un système avec les outils IAM.

L’approche « délégation », à l’état de l’art mais fortement couplée

La première approche consiste à déléguer l’authentification et l’autorisation à l’IAM, en l’occurrence au service d’authentification et de contrôle d’accès, via un protocole de Fédération d’Identités (SAML2, OpenID Connect / OAuth2) ou via un raccordement Active Directory / LDAP.

Cette solution permet une gestion des comptes et des accès à l’état de l’art, mais rend le SIIV totalement dépendant de ce service et l’expose aux risques évoqués précédemment. Même en situation de crise, une isolation du SIIV serait difficilement envisageable.

Cette approche est donc plutôt à réserver aux applications qui fonctionnent déjà sur ce principe, typiquement les applications du SI de gestion avec un grand nombre d’utilisateurs. Pour les systèmes industriels, la solution à privilégier est de conserver le service d’authentification au sein du SIIV et d’opter pour une autre approche.

L’approche « provisioning », avec un niveau de couplage à ajuster au contexte

Cette approche consiste à conserver un système d’authentification et de contrôle d’accès propre au SIIV mais provisionné – c’est-à-dire alimenté – par l’IAM : les comptes et droits des utilisateurs sont stockés dans un référentiel interne au SIIV, et la solution IAM les gère au travers d’un connecteur. En fonction du niveau d’isolation souhaité, ce connecteur peut prendre différentes formes :

• Un connecteur automatique, permettant à l’IAM d’écrire directement les informations sur les comptes et accès dans le SIIV. Une isolation temporaire devient possible, en situation de crise ou en cas de détection d’activité anormale (par exemple : suppression massive de tous les comptes). Mais rien n’empêche un utilisateur malveillant ayant la main sur l’IAM de se donner accès au SIIV.
• Des ordres transmis aux administrateurs du SIIV (par ticket ITSM ou par mail) qui réalisent les actions manuellement. Un « sas » d’isolation est ainsi maintenu entre l’IAM et le SIIV, avec une étape de contrôle par les administrateurs.

Cette approche permet de bénéficier des processus de gestion des identités et des accès : validation et traçabilité des demandes d’accès, retrait des comptes et droits en cas de mutation ou de départ, etc. tout en préservant un degré de cloisonnement du SIIV.

L’approche « revue », orientée contrôle a posteriori

L’approche « revue » (également appelée « recertification ») se distingue des autres par le fait qu’elle repose sur une logique de contrôle a posteriori plutôt que de gestion a priori. Il s’agit cette fois d’analyser périodiquement les accès déclarés dans le SIIV afin de vérifier s’ils sont toujours légitimes. Cette vérification peut reposer sur un rapprochement des comptes avec un référentiel de collaborateurs (fichier RH, solution IAM, etc.), ou sur une validation explicite de la part des responsables des utilisateurs.

Ce peut être l’occasion de réaliser des contrôles approfondis (par exemple détection de combinaisons toxiques), de produire des indicateurs et des rapports d’audit.

Adapter son projet IAM – Infrastructures critiques à son niveau de maturité et à la typologie du SIIV

Sur la base de ces différentes options, nous proposons ci-dessous des pistes pour construire la feuille de route de mise en conformité LPM/NIS en fonction du niveau de maturité IAM et de la typologie des SIIV concernés.

Conserver la brique d’authentification et autorisation localement dans chaque SIIV

Il est préférable de conserver un référentiel de comptes et de droits d’accès localement dans chaque SIIV. Cependant, pour les systèmes déjà raccordés à un service mutualisé d’authentification et d’autorisation, le système mutualisé peut être conservé mais l’Opérateur doit lui appliquer les mesures prévues par la LPM et NIS : a minima le cloisonnement réseau, le durcissement, le maintien en conditions de sécurité, l’administration depuis un SI d’administration dédié, l’envoi des logs au SIEM, etc.

Dans un environnement de gestion des identités et des accès non mature, commencer par la revue des comptes et des droits

En l’absence d’outillage de gestion IAM mature, le moyen le plus rapide d’atteindre un premier niveau de maîtrise des risques et de conformité est de définir et mettre en œuvre un processus de revue régulière, sur une base a minima annuelle.

Sur un SIIV au nombre d’utilisateurs limité, le processus peut être déroulé manuellement, avec un niveau de qualité acceptable et une charge de travail raisonnable. Mais pour gérer des volumétries plus importantes, un outillage adéquat est à envisager : il facilite le pilotage des campagnes de revue et garantit la traçabilité des décisions. Il constitue en outre une opportunité pour envisager ensuite la mise en place d’un outil de gestion IAM.

Lorsqu’un outil de gestion IAM est en place, le sécuriser pour y raccorder les SIIV

Lorsque l’Opérateur dispose d’un outillage IAM mature, le provisioning des SIIV par l’IAM est recommandé : l’automatisation, la fiabilisation et la maîtrise que permettent les outils doivent compenser les risques induits par le couplage. A condition toutefois de garantir la sécurité de l’IAM : en complément des mesures techniques précédemment évoquées, l’Opérateur doit configurer l’IAM de sorte à ce que seuls les utilisateurs susceptibles d’accéder au SIIV peuvent demander l’accès, que le propriétaire du SIIV valide les demandes d’accès et puisse consulter facilement la liste des utilisateurs autorisés, et enfin que des contrôles permettent de détecter des anomalies sur les comptes et accès.

Le rehaussement de la sécurité profitera d’ailleurs à l’ensemble du Système d’Informations.

Trouver le bon équilibre risques / bénéfices pour construire son projet IAM – Infrastructures critiques

Ces propositions doivent permettre à tout Opérateur de construire sa feuille de route IAM pour ses infrastructures critiques en trouvant le bon équilibre entre les bénéfices apportés, les risques induits et le coût de mise en conformité.

Cet article Quelle approche pour gérer les identités et les accès sur les infrastructures critiques ? est apparu en premier sur RiskInsight.

Comment l’idée vous est-elle venue ?

GitGuardian souligne l’importance de l’expérience de ses cofondateurs ingénieurs, spécialisés en intelligence artificielle dans la conception de leur solution : « Nous utilisons au quotidien les outils de l’open source, et en particulier la plateforme GitHub », qui reste génératrice de risques pour ses utilisateurs. Certains codes source publiés peuvent contenir une clé privée, suffisante pour « s’introduire dans des systèmes d’information d’entreprise, de la petite start-up aux grands groupes du CAC40 », la solution GitGardian a été créée pour « analyser en temps réel l’ensemble du code open source pour détecter les informations sensibles ».

Quel est le plus grand risque de sécurité pour les banques et pour ses clients selon vous ? Comment répondez-vous à la menace qui pèse sur les banques ?

Eric Fourier souligne l’interconnexion croissante entre les systèmes bancaires : « cette augmentation de la surface de vulnérabilité attire les hackers et le nombre de cyberattaques augmente tous les ans. Les failles de sécurité que nous détectons exposent régulièrement des données personnelles, pouvant appartenir aux employés de la banque, à ses clients, ou à des tiers. Ces fuites détériorent leurs images et leur font courir un risque légal et stratégique. Ainsi, GitGuardian permet de diminuer ces risques en détectant certaines vulnérabilités au niveau des interfaces entre les systèmes » bancaires.

L’enjeu pour les RSSI aujourd’hui est de parvenir à concilier la facilité d’implémentation, la simplicité d’utilisation des solutions de sécurité avec une technologie sécurisée. Comment convaincre un RSSI de la pertinence de votre solution et de la sécurité du produit ? Quels sont les différenciateurs qui vous démarquent sur le marché ?

GitGuardian met en avant la nature exogène de sa solution face « à l’infrastructure IT dans la mesure où nous analysons des données disponibles publiquement. Il suffit donc de quelques minutes pour l’installer. Nos algorithmes basés sur du Machine Learning nous permettent d’alerter le RSSI et son équipe sécurité d’une vulnérabilité moins de quatre secondes après l’événement, lorsqu’il est encore temps de limiter fortement les dégâts possibles ». Grâce à ce temps de réaction très faible, la solution est la seule sur le marché à fournir un service aussi précis et rapide car « les acteurs traditionnels s’appuient sur l’analyse humaine, qui peut prendre quelques semaines ».

Quelles sont les synergies entre votre innovation et les solutions de sécurité bancaires existantes à l’heure actuelle ?

GitGuardian note l’effort croissant des banques pour protéger leurs clients : « elles luttent contre la fraude bancaire avec des solutions de sécurisation des achats sur Internet, de protection contre les faux sites bancaires ou les tentatives d’hameçonnage. Les banques possèdent aussi des solutions standardisées pour la protection de leurs systèmes d’information, telles que les pare-feus ou le chiffrement des données. Cependant, les banques se protègent péniblement contre les erreurs humaines de leurs milliers d’employés et prestataires répartis sur le territoire français et dans le monde entier. GitGuardian colmate ces brèches en temps réel, avant que des dommages soient causés par des acteurs malveillants ».

Comment voyez-vous la banque de demain ? Quelles opportunités pour la cybersécurité dans la banque de demain ?

La principale tendance qui émerge est celle du numérique et de la transparence. GitGuardian l’explique ainsi : « La banque de demain sera une banque entièrement digitalisée et connectée. Les applications liées au secteur bancaire se multiplient, les exigences des clients s’intensifient et les fraudes bancaires s’amplifient. La banque de demain se doit d’être plus ouverte et transparente, comme en témoigne l’engouement qui s’anime autour de la technologie blockchain. Tout cela se traduit nécessairement par la mise en place de programmes de cybersécurité encore plus élaborés pour protéger la transition et assurer la sécurité de millions de personnes ».

Pour en savoir plus : https://www.gitguardian.com/

Cet article L’interview de GITGUARDIAN – Sécuriser les clés privées est apparu en premier sur RiskInsight.

Comment l’idée vous est-elle venue ?

Georges Bote (ICARE Technologies) raconte que l’idée est venue au fondateur, Jérémy Neyrou « il y a 6 ans de cela, en perdant mes clés de voiture sur une plage Corse complètement déconnectée de tout réseau, après avoir parcouru près d’une dizaine de kilomètres en plein soleil d’été à pied », il imagine un « objet à la fois intuitif et autonome qui permettrait d’embarquer [le] trousseau de clés et [les] moyens de paiement ». C’est ainsi qu’est née Aeklys, « cette bague intelligente qui permet d’embarquer jusqu’à 28 fonctionnalités différentes ».

Quel est le plus grand risque de sécurité pour les banques et pour ses clients selon vous ? Comment répondez-vous à la menace qui pèse sur les banques ?

Georges Bote (ICARE Technologies) s’accorde également à dire que « la fraude à la fois bancaire et sur l’identité des personnes reste le grand risque pour les banques et leurs clients ». C’est pourquoi la bague connectée proposée par ICARE Technologies embarque un mécanisme de désactivation en cas de perte ou de vol, protégeant ainsi son propriétaire contre l’usurpation de ses moyens de paiement sans qu’il ne doive faire opposition d’une quelconque manière que ce soit.

L’enjeu pour les RSSI aujourd’hui est de parvenir à concilier la facilité d’implémentation, la simplicité d’utilisation des solutions de sécurité avec une technologie sécurisée. Comment convaincre un RSSI de la pertinence de votre solution et de la sécurité du produit ? Quels sont les différenciateurs qui vous démarquent sur le marché ?

ICARE Technologies explique que la pertinence de la sécurité de sa solution « réside dans notre technique et différentes certifications bancaires. Notre secure element dispose d’un niveau EAL6+ certifié par l’ANSSI, ce qui nous permet de travailler dans le domaine militaire en plus d’avoir un chiffrement en AES 256 bits ».

Quelles sont les synergies entre votre innovation et les solutions de sécurité bancaires existantes à l’heure actuelle ?

La force du produit d’ICARE Technologies réside dans son innovation et en sa sécurité : « de plus, il caractérise une nouvelle forme de liberté et de sécurité qui est fortement attractive pour les clients potentiels. L’intérêt est donc d’en faire devenir un objet « à la mode » de manière à orienter la connotation sociale de la bague comme une tendance ».

Les synergies existent et la technologie est actuellement en phase de test avec des partenaires bancaires et industriels pour travailler notamment sur la sécurisation de valises informatiques. Georges Bote annonce « la préparation d’un 2ème tour de table et de belles surprises pour notre Go To Market qui sera prévu le 1er trimestre 2019 ».

Pour en savoir plus : https://fr.icaretechnologies.com/

Cet article L’INTERVIEW D’ICARE TECHNOLOGIES – LA BAGUE INTELLIGENTE SECURISEE est apparu en premier sur RiskInsight.

Comment l’idée vous est-elle venue ?

Juliette Delanoë évoque l’importance de la transformation digitale des grands groupes : « de plus en plus de biens et services peuvent être souscrits ou consommés en ligne. En particulier, la vérification des identités en ligne est un enjeu fondamental pour que la révolution digitale soit vecteur de progrès durable pour la société ». La combinaison des expériences des fondateurs a permis de développer un produit permettant via le flux vidéo, d’identifier « et de protéger les individus dans le monde digital, en permettant d’y utiliser les documents d’identité physique régaliens de façon fiable, pratique, et respectueuse de la vie privée ».

Quel est le plus grand risque de sécurité pour les banques et pour ses clients selon vous ? Comment répondez-vous à la menace qui pèse sur les banques ?

Juliette Delanoë met en parallèle l’importance d’avoir des parcours digitaux agréables et rapides pour leurs utilisateurs et la nécessité d’en assurer la sécurité : « l’entrée en relation, étape très critique de l’expérience utilisateur, avait lieu il y a quelques années exclusivement en boutique, mais avec l’arrivée des néo-banques, et de la génération des millenials, cette étape se digitalise et s’automatise rapidement ». Il convient donc de conserver cette opportunité mais de faire attention aux enjeux sécuritaires qui se dessinent et notamment aux « nouveaux types de fraudes propre au digital qui se développent – comme l’utilisation de faux documents d’identité pour ouvrir un compte bancaire en ligne ».

L’enjeu pour les RSSI aujourd’hui est de parvenir à concilier la facilité d’implémentation, la simplicité d’utilisation des solutions de sécurité avec une technologie sécurisée. Comment convaincre un RSSI de la pertinence de votre solution et de la sécurité du produit ? Quels sont les différenciateurs qui vous démarquent sur le marché ?

Ubble propose aux RSSIs de tester la solution en partageant sa conviction profonde que « le mouvement (donc la vidéo) est indispensable à la vérification des visages comme des documents (hologrammes, reflets), et nous développons des technologies qui vérifient les identités non pas sur la base de simples images, mais sur un flux de vidéo en streaming ». En effet, les streams vidéo, la computer vision et le deep learning permettent d’éviter la fraude. Ainsi il n’est pas possible de « présenter un document d’identité qui soit une simple photocopie [ou …] d’utiliser le document de quelqu’un d’autre ». L’atout de la solution réside également dans une expérience utilisateur aisée et agréable pour un client de bonne foi.

Quelles sont les synergies entre votre innovation et les solutions de sécurité bancaires existantes à l’heure actuelle ?

Ubble explique : « nos technologies répondent à une faille sécuritaire nouvellement créée, que les solutions existantes n’adressent pas, ou seulement partiellement. Nos technologies sont en parfaite synergie avec les systèmes mis en place par les banques, et viennent s’ajouter pour combler la faille sécuritaire créée lors de la digitalisation et de l’automatisation de l’entrée en relation ».

Comment voyez-vous la banque de demain en 3 tendances ? Quelles opportunités pour la cybersécurité dans la banque de demain ?

Selon ubble, le futur verra l’apparition d’un nouveau rôle pour la banque : la banque de demain « sera un des services les plus sécurisé dans le monde digital ». La start-up prévoit ainsi que « la banque de demain [sera amenée à jouer] un rôle sécuritaire fort dans le monde digital en général. En tant qu’acteur de confiance qui connaît ses clients, elle pourra attester de leur identité auprès d’autres fournisseurs de services ».

Pour en savoir plus : http://www.ubble.ai

Cet article L’INTERVIEW D’UBBLE – VERIFICATION D’IDENTITE VIA LA VIDEO est apparu en premier sur RiskInsight.

Dans ce contexte, la grande majorité des entreprises a mené des projets d’IAM : les accès aux applications sensibles sont étroitement contrôlés et les niveaux d’accès sont restreints selon les profils des utilisateurs et les actions à réaliser.

Or, trop souvent, ces démarches IAM « oublient » les populations IT qui ont pourtant des accès privilégiés sur l’infrastructure de l’entreprise. Et pour ces derniers, plusieurs spécificités sont à prendre en compte.

Les utilisateurs IT ont des besoins d’accès différents

Les utilisateurs « non-IT » représentent les utilisateurs « standards » du SI : utilisateurs des directions métier ou des fonctions support comme RH, paie, ou comptabilité… Ils accèdent classiquement :

• Aux applications en environnement de production,
• Et via les IHM standard de celles-ci.

Les populations « IT » (service informatique interne, télémaintenance, support…) ont quant à elles des accès très différents :

• Elles opèrent les infrastructures (serveurs, bases de données), et le code applicatif, sur lesquels reposent les applications ;
• Elles accèdent à tous les environnements et en particulier production et hors-production (ces derniers contenant souvent des données de production ou à caractère sensible ou personnel) ;
• Très souvent, elles opèrent avec des niveaux de droits (des « privilèges ») très élevés, présentant donc un niveau de risque non négligeable.

Ainsi, la terminologie « accès à privilèges » désigne tout accès technique, sur une infrastructure ou une brique logicielle, dans des environnements de production ou hors-production.

Ces accès sont parfois créés pour des individus, ou pour les applications elles-mêmes (une application a besoin de plusieurs comptes techniques, comme pour écrire dans une base de données).

On distingue différents niveaux d’accès « à privilèges ». Les plus critiques, de niveau « administrateur », offrent un contrôle total d’un ou plusieurs serveurs, et donc potentiellement plusieurs applications. Les accès IT de niveau « standard » sont moins sensibles mais restent à surveiller. Ces derniers pourraient permettre, par exemple, de consulter des informations sensibles dans une base de données.

Accès IT, risques métier

Par définition, la maitrise des accès privilégiés des populations IT doit être au cœur des préoccupations des entreprises.

Parmi les risques les plus importants, nous retrouvons :

• Les risques opérationnels, sans impact sur la production

Exemple : des traces d’exploitation sont supprimées par erreur ou un serveur non critique est éteint.

• Les risques sur l’activité de l’entreprise

Exemple : indisponibilité de la plateforme de flux des paiements / transaction suite à un redémarrage des serveurs par erreur.

• Les risques de non-conformité aux régulations

Exemple : mise en évidence d’un accès non-justifié sur un périmètre régulé suite à un audit interne.

• Des actions frauduleuses

Exemple : délit d’initié commis grâce à une information sensible consultée directement depuis une base de données.

Sans compter les risques plus larges autour du système d’information : vol de données, ransomwares et autres actions malveillantes. Parce qu’ils sont puissants (et permettent notamment de désactiver les mesures de sécurité), les accès à privilèges sont des cibles de choix en cas de cyber-attaque.

Aujourd’hui, la plupart des responsables d’application sensibles sont en mesure de rendre des comptes quant à l’usage des accès métier dans leur application. De la même manière, les responsables d’application et les responsables d’infrastructure doivent pouvoir répondre à des questions simples telles que :

• Qui utilise réellement des accès à privilèges sur mon périmètre ?
• Combien de comptes à privilèges existent sur mon périmètre ?
• Les mots de passe de ces comptes sont-ils changés régulièrement ?
• Quels sont les niveaux d’accès nécessaires pour mon application ou mes services, et qui ne peuvent pas être retirés sans conséquence pour la production ?

Plusieurs particularités à prendre en compte

Avant de se lancer dans un projet de mise sous contrôle des accès à privilèges, il est bon d’avoir conscience de certaines spécificités qui ne s’appliquent pas pour les accès métier.

À commencer par le cycle de vie de certains accès à privilèges. Dans le monde des accès métier, le cycle de vie est lié au statut RH de leur unique propriétaire. Mais dans le monde IT, il existe des accès partagés entre plusieurs personnes (pour des besoins opérationnels spécifiques), ou bien qui sont utilisés par l’application elle-même pour fonctionner. La durée de vie de ces accès-là est plutôt liée à la durée de vie de l’application concernée, ou bien parfois à la durée d’un projet.

Certaines contraintes opérationnelles sont aussi à prendre en compte. Notamment en ce qui concerne :

• La gestion de la production, qui ne souffre aucun délai. Dans le monde des accès métier, les niveaux d’accès sont généralement liés à la fiche de poste des utilisateurs, et c’est aussi le cas pour les populations IT. Mais dans certaines circonstances, les utilisateurs IT doivent pouvoir obtenir de nouveaux accès sans délai. Par exemple, en cas de panne d’une application critique, les équipes IT doivent pouvoir intervenir au plus vite avec toute la latitude nécessaire. Ce qui peut nécessiter des élévations de privilèges. Dans ce contexte, des processus de validation seraient trop longs (avec validation du responsable hiérarchique, puis éventuellement un autre niveau de validation…). Une autre approche peut consister à autoriser ce type de demande sans validation préalable, mais tracer et contrôler à posteriori l’usage qui a été fait de cet accès.

• Le grand nombre de ressources cibles. Certaines applications reposent sur un grand nombre de serveurs de production, et au moins autant de serveurs hors-production. Des applications peuvent aujourd’hui créer ou supprimer des serveurs virtuels à la volée, en fonction de la charge. Dans ce cas, il serait vite ingérable d’imposer aux utilisateurs des demandes d’accès pour chaque ressource cible. Une solution peut consister à gérer des demandes d’accès à des groupes de ressources (par exemple un groupe Active Directory qui représente tous les serveurs de production d’une application, lequel groupe pourrait même être déployé automatiquement sur les nouveaux serveurs par un orchestrateur).

Surtout, l’hétérogénéité de l’environnement peut rendre le modèle d’accès complexe. En effet, articuler la gestion des accès à privilèges autour d’un modèle cohérent, implique de composer avec :

• Des serveurs qui hébergent parfois plusieurs applications. Dans ce cas, un besoin d’accès à une seule application se traduit, en pratique, par des accès indus à plusieurs applications. Dans le cas d’applications critiques, il vaut donc mieux investir dans des serveurs dédiés (virtuels ou non, face aux risques portés par les administrateurs des plateformes de virtualisation).

• Des ressources hétérogènes avec leurs propres particularités. Serveur Windows, Unix, base de données Oracle, middleware Tomcat, des équipements réseau, voire des conteneurs comme Docker… La liste des technologies à prendre en compte est longue.

• Pour une même ressource, différents comptes à créer. Un utilisateur peut souvent intervenir sur une même ressource via différents moyens. Pour un même serveur, on pourra offrir la possibilité de s’y connecter directement (protocoles SSH, RDP…), via l’intermédiaire d’un serveur de rebond (et dans ce cas, c’est sur ce serveur qu’il faut créer un accès utilisateur), ou encore via une interface logicielle d’administration (c’est d’ailleurs la voie du DevOps).

• Des populations hétérogènes et des besoins qui évoluent rapidement. Le modèle d’accès est difficile à uniformiser, notamment parce que différents types de population, comme des administrateurs d’infrastructures ou des développeurs, ont des besoins différents. Par exemple, un administrateur Windows opère tous les serveurs Windows, quelle que soit l’application, alors qu’un développeur intervient sur plusieurs technologies dans la limite d’une application. Mais il est aussi difficile d’uniformiser le modèle d’accès pour une même population, car les développeurs de 2 applications différentes peuvent avoir des besoins différents.

Les accès à privilèges : un challenge pour la sécurité ?

Accès standards métier et accès à privilèges sont les 2 faces de la même pièce. Et les accès à privilèges en sont la face sombre, car ils sont à la fois plus sensibles et techniquement plus complexes à gérer.

Face à cet état des lieux, la prise de conscience des entreprises est inégale. Les mieux informées sont les équipes techniques IT qui utilisent les comptes à privilèges, et qui sont souvent favorables au statuquo.

Au-delà de la Direction des systèmes d’information, ce sont les Directions en charge des processus internes, de la qualité ou encore le contrôle interne, qui ont un rôle clé de sponsoring à jouer.

Le législateur, lui, commence aussi à s’y intéresser. Ainsi la Loi de programmation militaire, qui concerne les opérateurs d’importance vitale, impose une mise sous contrôle des accès à privilèges les plus critiques.

Mais alors comment s’y prendre, pour mettre les accès à privilèges sous contrôle ? Nous y reviendrons dans un prochain article.

Cet article Accès à privilèges : la face sombre de l’IAM est apparu en premier sur RiskInsight.

Historiquement la discipline de la gestion des identités et des accès (IAM ou identity and access management en anglais) s’est constituée autour du besoin de maîtriser qui accède (comment et) à quoi dans le système d’information de l’entreprise.

Du côté de la gestion des identités, les projets se sont initialement attelés à l’automatisation du provisioning et des tâches à faible valeur ajoutée. La discipline s’est ensuite peu à peu tournée vers les processus de demande et d’approbation de droits d’accès et plus récemment vers les problématiques de revue et recertification des comptes et habilitations.

Sur le sujet du contrôle d’accès, nous sommes passés par une première ère où l’authentification fut centralisée (sur un annuaire partagé par exemple), puis déléguée (à une solution de WebSSO) et enfin standardisée avec l’utilisation des mécanismes de fédération d’identités (eg. SAML) autant pour les applications SaaS que pour les applications restées en interne.

Dans le même temps, ces dernières années, le système d’information de nos entreprises s’est énormément ouvert à Internet : SaaS, IaaS, utilisateurs internes en mobilité, partenaires & clients accédant au SI, applications mobiles, etc. Et l’IAM a pu à chaque fois proposer des solutions à ces nouveaux usages et nouvelles orientations sans forcément nécessiter de remettre en cause l’existant et ses principes fondamentaux. Le marché s’est d’ailleurs petit à petit consolidé et nous sommes dans une situation de relatif calme… avant la tempête.

Les évolutions du SI

Nous estimons en effet que nous n’en sommes qu’au début de ces transformations.

Sous l’impulsion du Cloud d’une part, nous allons vers encore plus de SaaS, une utilisation du IaaS majoritaire par rapport aux datacenters historiques, une réelle adoption du PaaS (sous la forme d’applications conteneurisées, et server-less apps), des utilisateurs internes accédant majoritairement depuis l’extérieur et une explosion du nombre de terminaux accédant au SI (toujours plus de clients dont le parcours est digitalisé, explosion à venir du nombre d’objets connectés, OpenData, etc.)

Et sous l’impulsion de nouvelles méthodologies agiles et DevOps, le SI n’évolue plus de la même manière. Les cycles de développement et déploiement se sont considérablement raccourcis, les interactions entre le métier et la DSI se heurtent de moins en moins à l’opposition historique, et traditionnellement française, entre MOA et MOE. Ces nouvelles méthodes se sont d’ores et déjà répandues dans l’entreprise et il est difficile d’y résister.

Si la mission de l’IAM n’a guère changé : maîtriser qui accède à quoi dans le SI, il y aura beaucoup plus de « qui », de « quoi » et le SI ne sera plus qu’une bulle parmi d’autres interagissant avec son environnement et devant maîtriser, à distance, des interactions entre des composants décentralisés.

L’IAM de demain

Dans ce nouvel environnement où les métiers pilotent l’innovation technologique et imposent leurs exigences, où il est même parfois prescripteur de solutions technologiques, l’IAM doit se faire une nouvelle place. Dans ces architectures majoritairement Cloud, l’IAM doit démontrer qu’elle permet de maîtriser cette orientation et même d’apporter des plus-values par rapport à la situation précédentes.

Notre vision de l’IAM de demain s’articule autour de sept thèmes. Trois besoins exprimés par le métier et quatre nouvelles disciplines au sein de l’IAM.

L’agilité

Le métier attend de pouvoir proposer de nouveaux produits en un temps toujours plus court et ce qu’il a obtenu sur les applications métier est aujourd’hui attendu de tout le SI, y compris les services d’infrastructure et de sécurité et donc de l’IAM.

C’est l’occasion de passer d’un IAM monolithique, complexe à sortir de terre et très difficile à manœuvrer pour embrasser une architecture plus légère basée, par exemple, sur des micro-services.

La gestion des identités clients (Customer IAM ou CIAM)

La transformation numérique engagée par de nombreuses entreprises aujourd’hui a poussé le métier à interagir avec ses clients de plein de manières différentes et via toujours plus de canaux différents.

Une expérience utilisateur parfaite et la simplification du parcours client sont requis. L’optimisation des conversions clients et les taux de retours deviennent des indicateurs clés sur lesquels le métier insiste pour obtenir de l’IAM plus d’efforts.

Les objets connectés (Internet of Things ou IoT)

Que votre entreprise se lance dans la fabrication d’objets connectés ou qu’elle ne fasse que fournir des services consommés par ces objets, un certain nombre de questions vont devenir incontournables :

• Comment s’assurer que l’objet avec lequel je communique et celui qu’il prétend être ? Dans mon cas d’usage, est-ce finalement si important de le savoir ?
• Comment m’assurer de tenir la charge face au volume d’objets déployés ?
• Comment assurer la sécurité de bout en bout ?
• Quel cycle de vie doit-on anticiper ?

Ce sont des questions passionnantes qui imposent de savoir revenir à la planche à dessin et prendre en compte des hypothèses extrêmement différentes de celles de l’IAM classique.

IDentity as a Service

Comme nous l’avions prédit il y a quelques années, les entreprises n’hésitent plus à exporter leur IAM dans le cloud pour des questions de sécurité mais reviennent à la bonne question : en ai-je besoin ? Que vais-je gagner ?

Si le marché de l’IDaaS est encore jeune, les offres actuelles ne couvrant que très partiellement le spectre de l’IAM, tous les indicateurs montrent que cela ne va pas durer et que toute la gamme de fonctionnalités de gestion des identités aujourd’hui manquantes (provisioning on-premises, demande et approbation de droits, gouvernance des identités, etc.) sera bientôt couverte. Il reste à savoir si gestion des identités et contrôle d’accès seront packagés ou proposés par des acteurs différents et à choisir le(s) bon(s) acteur(s)…

APIs

Les APIs représentent déjà un format de communication prépondérant et incontournable pour toute entreprise lancée dans sa transformation numérique : échange avec les partenaires, applications mobiles, applications IHM client-side, OpenData, etc. Si vous ne vous êtes pas encore lancés, il va falloir sérieusement songer à plonger dans ce sujet !

Malgré des manques perçus par rapports aux standards des web-services des années précédentes (spécifiquement aux nostalgiques de la suite WS-*), il faut se résoudre à embrasser la vague REST/JSON, il faut se lancer dans Oauth2 et vous poser la question du API first pour tous vos projets.

Standards

La guerre des standards est éternelle. Et tout standard qui s’impose aujourd’hui a vocation à être challengé et remplacé plus tard par un autre. Cela n’empêche pas de bons standards de voir le jour, d’être adoptés et de permettre de correctement répondre aux problématiques de l’IAM.

Sur le sujet du contrôle d’accès en particulier, tant sur le volet de l’authentification proprement dite que de la propagation de cette authentification au travers du SI, plusieurs standards et protocoles sont matures et d’ores et déjà adoptés par une bonne part du marché. FIDO, U2F, OpenID Connect pour ne citer que ceux-là sont parmi les plus prometteurs de par leur ouverture, la maturité des technologies sous-jacentes ou encore les acteurs qui les ont conçus collectivement.

Identity & Access Intelligence

C’est sans doute le domaine de l’IAM qui offre les perspectives les plus excitantes. L’application des algorithmes du machine learning, la détection de signaux faibles, des réseaux neuronaux et bien d’autres encore pour faire émerger de nouveaux usages, de nouvelles possibilités en lien avec les identités de nos utilisateurs (ou objets) et leur comportement.

Détecter les scénarios de fraude avant même qu’ils ne se concrétisent, anticiper les risques et fermer la porte avant même que quelqu’un ne l’emprunte réellement. Il y a sans doute encore un peu de science-fiction dans les scénarios présentés par les éditeurs mais ce marché en pleine ébullition regorge de pépites et de bonnes surprises.

En synthèse

Ces sept thèmes, incontournables selon nous, requièrent d’ores et déjà une expertise à la fois pointue et très spécifique. Dans les prochaines semaines, nous éclairerons progressivement ces différents sujets pour donner les clés d’analyse et d’action sur l’IAM de demain, que ce soit en phase de cadrage, d’expérimentation ou de premières mises en œuvre.

Cet article Quel IAM pour demain ? 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.

Touch ID, un lecteur d’empreintes simple et plus sûr

Selon Apple, Touch ID est plus sécurisé qu’un code à quatre chiffres : la probabilité que le capteur confonde deux empreintes digitales est de 1 sur 50 000 et elle augmente à « 1 sur 10 000 lorsqu’un utilisateur non autorisé devine un code d’accès à 4 chiffres ». Il faut néanmoins préciser que ces deux chiffres ne sont pas réellement de même nature car le premier représente une probabilité de fausse détection tandis que le second correspond à la probabilité de trouver le bon code de déverrouillage, et donc de pouvoir se ré-authentifier par la suite.

Utiliser Touch ID est également relativement simple. Lorsque le doigt est apposé sur le bouton d’activation de l’écran d’accueil, une photographie haute résolution de l’empreinte digitale est prise, puis comparée à un gabarit référence généré au moment de l’enregistrement de l’utilisateur. Concernant la confidentialité de ces données, la documentation technique précise que lors du processus d’enregistrement, c’est la modélisation mathématique de l’empreinte digitale qui est hébergée dans l’enclave sécurisée du processeur, au plus proche du capteur, et non les empreintes digitales des utilisateurs.

Un capteur biométrique aux usages multiples

Avec le lancement de l’iPhone 6 et d’iOS 8, les usages évoluent. Jusqu’à présent, le capteur permettait uniquement de s’authentifier et de payer ses achats sur l’Apple store, l’iTunes Store et l’iBooks Store. Désormais, l’arrivée d’Apple Pay permet de réaliser tous types d’achats en validant ses paiements via Touch ID, notamment grâce à l’intégration d’une puce NFC (pour le moment, Apple Pay n’est disponible qu’aux États-Unis). Il devient également possible de sécuriser l’accès à des applications tierces.

Les nouvelles fonctionnalités que pourraient offrir ces capteurs biométriques sont nombreuses, telles que déverrouiller une voiture ou effectuer un virement bancaire. La question de la sécurité devient donc cruciale.

Performances et limites de Touch ID

En dépit des tests et des études montrant que cette technologie est robuste et que les taux de faux positif et de faux négatif restent bas, Touch ID possède quelques limites.

L’authentification peut être avortée si le lecteur biométrique porte des traces de poussières, de graisse…Le capteur est également insensible à la chaleur corporelle et ne fait donc pas la différence entre la peau et les corps inertes. Enfin, comme pratiquement tous les lecteurs d’empreintes digitales, il est possible de le piéger. De nombreux experts en sécurité ont posté des vidéos montrant leurs tentatives réussies de piratages à partir de fausses empreintes digitales. Le « Chaos Computer Club » a ainsi réussi à tromper Touch ID en photographiant en haute résolution une empreinte digitale et en moulant cette dernière.

Nous avons, nous aussi, voulu tester la fiabilité de cette technologie avec de fausses empreintes digitales réalisées en gélatine alimentaire et en colle à bois. Le processus est fastidieux et les résultats varient en fonction de la qualité des copies et de leur fidélité par rapport à l’originale, mais nous sommes bien parvenus à déjouer le capteur biométrique.

Ainsi, une personne mal intentionnée pourrait parvenir, moyennant de nombreux efforts, à s’authentifier sur les appareils utilisant la biométrie par Touch ID. Cela implique cependant de pouvoir récolter une empreinte digitale nette, claire et épaisse qui puisse être facilement dupliquée, ce qui est au quotidien difficile à trouver.

Des évolutions dans le futur ?

Simple d’usage et efficace, la technologie Touch ID est une belle avancée pour la sécurité des terminaux mobiles. Malgré ses limites, les usages cités précédemment (accès aux données personnelles sur les terminaux, paiements mobiles…) ne devraient théoriquement pas souffrir de problèmes majeurs de sécurité pour le grand public.

Cependant, pour des populations sensibles ou dans des contextes à risques, il faut avoir conscience des limites concrètement démontrées. Il aurait été souhaitable que la sortie de l’iPhone 6 améliore de façon notable la sécurité et les performances du capteur biométrique. Malheureusement, à part une plus grande sensibilité impliquant une diminution du taux de faux négatifs (la résolution du capteur étant plus grande), il n’y a pas eu de modifications substantielles. Dans le futur, une approche combinant l’empreinte et un code pourrait être une évolution intéressante et simple à mettre en œuvre.

Enfin, si l’on souhaitait renforcer la sécurité de manière significative, on aurait pu s’orienter vers des technologies biométriques « sans traces » (réseau veineux, reconnaissance d’iris…etc). Mise à part l’usabilité de la plupart de ces technologies qui ne permet pas à l’heure actuelle de les intégrer sur un smartphone, la question essentielle est de savoir si le grand public est prêt à les accepter et à les utiliser. Affaire à suivre…

Cet article Touch ID marque-t-il la sécurité de son empreinte ? est apparu en premier sur RiskInsight.

D’où proviennent les échecs en matière d’IAM ? Pourquoi parler d’IAG ?

L’analyse de ces échecs révèle deux causes majeures. La première : l’inadéquation entre les ambitions visées et les moyens alloués. Elle se traduit concrètement par l’absence de gouvernance et de sponsoring transverse, de vision stratégique moyen terme reflet des enjeux métier ou encore de dynamique de construction et d’amélioration dans la durée.

La seconde : l’absence de métrique et d’outillage simple permettant de démontrer et de communiquer sur la situation réelle des habilitations, les apports ou encore le bien-fondé des choix retenus. C’est à ce second écueil que doit répondre l’IAG (Identity and Acces Governance. Par effet de rebond, elle doit également fournir les indicateurs opérationnels pour mieux mobiliser les bons relais dans le management et dans les métiers.

Qu’est-ce que l’IAG ? Quelles fonctionnalités en attendre ?

De manière simplifiée, l’IAG (parfois également appelée Identity & Access Intelligence ou encore Identity Analytics & Intelligence voire Governance Risk & Compliance) vise à fournir les moyens nécessaires au pilotage des données et des usages de l’IAM.

Pour ce faire, elle se positionne comme une « tour de contrôle transverse », alimentée autant par les référentiels Qualité et les règles du contrôle interne que les données de l’IAM et des applications. Au-delà du contrôle, l’IAG doit également offrir des moyens de remédiation.

Concrètement, une solution d’IAG va importer l’ensemble des comptes et habilitations pour les comparer avec les règles métiers; et en les croisant avec les schémas d’organisation, elle proposera des bilans structurés des écarts et des risques.

Elle doit ainsi permettre de prendre en compte l’ensemble des règles et contrôles métiers de l’entreprise (combinaisons toxiques de pouvoirs, accès limités à certaines populations, certaines plages horaires…). Mais aussi de corréler et de présenter les données opérationnelles de l’IAM, et de chaque application, à l’aune de ces règles. Enfin d’organiser et suivre les actions de remédiation nécessaires à la correction des éventuels écarts.

C’est donc un service essentiel pour s’assurer du bon fonctionnement et du bon usage du système IAM, corriger les biais de données et, in fine, améliorer la qualité perçue du service rendu. C’est également une clé pour réaliser rapidement un diagnostic de l’existant et ainsi déclencher une prise de conscience des efforts à réaliser.

Dans quels contextes l’IAG est-elle pertinente ?

Une approche IAG se révèle intéressante autant pour les organisations n’ayant pas engagé de démarche IAM, que pour celles ayant déjà conduit certains chantiers.

Pour les premières, le recours à l’IAG permet de conduire des démarches plus opérationnelles, en prise directe et immédiate avec l’existant en matière de comptes et de droits sur les applicatifs.

Ainsi, cette approche bottom-up permet de réaliser un diagnostic concret, argumenté d’exemples parlants. La prise de conscience est donc simplifiée pour les Métiers. L’ensemble des ingrédients est alors réuni pour engager une démarche d’amélioration plus structurante.

Pour les secondes, nombre d’initiatives pâtissent d’un manque d’indicateurs de suivi d’usage et de qualité. Ce manque est nuisible à la « qualité perçue » du système IAM. Il se révèle également des plus handicapants en cas de suspicion de dysfonctionnement et lors des phases d’investigations associées. Ainsi, l’IAG se pose comme une réponse à ce manque de visibilité.

Alors, l’IAG, «potion magique» pour réussir son projet de gestion des identités ?

En informatique, rien n’est magique ! Toutefois, avec ses fonctionnalités avancées d’analyse et de restitution, l’IAG offre enfin les moyens de mesurer l’efficacité de sa gestion des identités.Et, au prix d’une démarche adaptée, elle permet une prise de conscience parlante par les Métiers et le management.

Les Directions en charge des processus internes, de la qualité ou encore le contrôle interne ont alors un rôle clé de sponsoring à jouer. Elles doivent supporter les initiatives IAG et garantir leur pérennité dans le temps.

En effet, quelques semaines suffisent pour mettre en lumière les menaces et les incohérences majeures portés par les habilitations. Et quelques mois permettent de corriger ces écarts. Mais c’est dans la durée que doit se conduire une stratégie IAG, pour inscrire sa gestion des identités dans une démarche vertueuse d’amélioration durable.

Découvrez bientôt, sur Solucom Insight, comment adapter sa démarche projet pour en tirer le meilleur parti.

Cet article IAG: la gestion des identités a-t-elle enfin des yeux et des oreilles ? est apparu en premier sur RiskInsight.

Pourquoi la gestion des identités et des habilitations des ERP ne doit-elle pas être négligée ?

Les ERP comme SAP sont devenus incontournables dans beaucoup d’entreprises, particulièrement dans les grands groupes. Tout le monde les utilise : de la gestion des achats à celle des contrats, en passant par le contrôle des factures, le mouvement des stocks ou la gestion des ressources humaines, les ERP permettent de tout gérer. À tel point que pour un utilisateur au cœur de ces fonctions, l’ERP peut devenir son principal outil de travail, et représente la majeure partie de « son SI ». Une ville dans la ville du SI, en somme.

Des métiers comme les achats ou la distribution sont potentiellement sensibles, et sont de fait réglementés. La loi de sécurité financière en France, ou la loi Sarbanes-Oxley aux États-Unis, responsabilisent les utilisateurs, mettent en place le contrôle interne et contribuent à la prévention des conflits d’intérêt. Pour être en mesure de se conformer à ces règlementations, il est nécessaire de contrôler les opérations réalisées via les ERP.

Mais encore faut-il savoir qui fait quoi dans l’ERP… ce qui n’est pas toujours le cas. La criticité des opérations impose de donner au sein de l’ERP les bons droits d’accès, aux bonnes personnes, au bon moment, et de contrôler la bonne application des règles. Cela implique, entre autres, de maintenir un référentiel d’utilisateurs dans le temps, de définir des processus d’habilitation à différents niveaux de validation, ou encore de définir des processus de gouvernance qui permettent de faire évoluer la gestion des habilitations de l’ERP en phase avec l’organisation opérationnelle. Avec une attention particulière sur le modèle d’habilitation et l’accompagnement aux utilisateurs.

La richesse des modèles d’habilitation peut induire trop de complexité : comment trouver le bon équilibre ?

Les ERP permettent beaucoup de souplesse dans la définition du modèle d’habilitation. Dans le cas de SAP, le modèle est défini, notamment, via des rôles « pères » et des rôles « fils » liés par des notions d’héritage, et qui instancient un ensemble de transactions sur un périmètre donné. Ou encore des rôles composites qui regroupent plusieurs rôles « fils ». Chaque entreprise utilisant SAP est ainsi en mesure de définir son modèle d’habilitation avec la granularité et la richesse nécessaire à son contexte.

Et c’est bien là le risque. Cette souplesse ne doit pas inciter à définir un modèle d’habilitation (trop) complexe pour l’entreprise. Elle rendrait en effet  la gestion des demandes plus compliquée au jour le jour et induirait au bout du compte un risque de non-conformité aux réglementations.

Nous avons déjà rencontré des situations où les responsables du modèle métier  se désapproprient le sujet, laissant le modèle à la dérive. De même dans le cas des responsables de la ségrégation des tâches (qui limitent le cumul par une même personne de fonctions incompatibles, comme par exemple être en mesure d’éditer une facture et de la payer), cette complexité peut entraîner des attributions abusives de droits. Trop souvent, nous observons la situation « je valide parce que je ne comprends pas… et ne veux pas empêcher les utilisateurs de travailler ».

Le modèle d’habilitation doit donc être cadré et maintenu dans le temps. Un cadre « ferme et simple » fixera des principes et limitera les dérives. Il  définira les rôles types en fonction des métiers et les processus associés, sans essayer de prendre en compte toutes les exceptions de chaque métier.

Par ailleurs, une organisation qui fasse évoluer le modèle dans le temps est aussi nécessaire : la complexité peut résulter d’évolutions successives sans vision d’ensemble. Par exemple dans SAP, le modèle d’habilitation évolue notamment via la mise à jour de rôles simples, lesquels contiennent des droits fins (transactions), répercutés dans plusieurs rôles composites, impactant in fine plusieurs métiers.

Un travail en silo où les évolutions seraient dictées par les besoins spécifiques de quelques fonctions conduirait à un modèle d’habilitation cacophonique. Une organisation et des processus de gouvernance permettent d’éviter cela en contrôlant et en validant collectivement les évolutions. Les acteurs d’une telle gouvernance peuvent inclure des responsables des processus métiers, qui associent la connaissance du terrain à celle du modèle d’habilitation. On pourra y associer un acteur du contrôle interne.

Une équipe transverse s’assure en complément que les responsabilités définies sont bien attribuées et vivent au gré des arrivées, mobilités et départs.

Accompagner les utilisateurs : la clé pour garantir que les outils soient utilisés à bon escient

Les utilisateurs aussi ont besoin de comprendre les habilitations elles-mêmes  et de connaître les acteurs liés aux processus. À défaut de réponse à ces questions, les utilisateurs se tourneront vers le chemin le plus court, parfois même en contournant les processus. Les utilisateurs qui ne savent pas quels rôles correspondent à leur besoin ont tendance à demander les mêmes que leur collègue de bureau, ou bien leur prédécesseur. Ceux qui souhaitent obtenir rapidement un rôle donné seront enclins à le demander directement à la personne effectuant l’attribution finale. Avec le temps, des droits dont les utilisateurs n’ont pas besoin, voire  incompatibles entre eux, s’accumulent.

Permettre aux utilisateurs de travailler correctement sur un ERP implique aussi de les former à l’utilisation des outils. Cela parait naturel pour les transactions métier qu’ils utilisent tous les jours. Mais c’est tout aussi nécessaire pour les démarches de demande d’accès liées à l’ERP qu’ils n’utilisent qu’occasionnellement, et qu’ils ont tendance à oublier.

Enfin la gestion du changement doit permettre de faire vivre les référentiels documentaires et le réseau des utilisateurs clé.

Les projets de gestion des identités et des habilitations du SI ne devraient pas hésiter à intégrer les ERP dans leur périmètre… et réciproquement. En effet ces projets sont encore trop souvent menés de manière disjointe pour les ERP d’une part, et le reste du SI d’autre part. Les gestions des identités et des habilitations doivent pourtant être mises en cohérence opérationnellement, tout utilisateur d’un ERP étant d’abord un utilisateur du SI. Sans surprise, leurs problématiques sont d’ailleurs similaires… et leurs réponses aussi ! Les questions des organisations, des processus et des interfaces techniques entre les deux environnements méritent donc d’être instruites. Bien que ces questions dépendent du contexte, un début de réponse serait à minima de décliner les mêmes processus de gestion des identités. Sans oublier que la gestion des accès doit être considérée comme un pan complet de la conduite du changement et de la formation.

Cet article SAP : le parent pauvre de la gestion des identités et des accès ? est apparu en premier sur RiskInsight.

Et puis sont venus les partenaires externes et leurs employés. Dans le cas d’usage classique, un constructeur d’avion doit pouvoir collaborer avec l’ensemble de ses sous-traitants : il faut leur permettre l’accès aux applications, gérer ou faire gérer leurs comptes et leurs droits. La fédération des identités ainsi que ses standards et protocoles ont permis de répondre à cette problématique. La gestion des identités si elle devait prévoir de nouveaux processus n’a été que faiblement impactée (la volumétrie restait d’un ordre de grandeur comparable, les utilisateurs restaient des humains maîtrisés, etc.)

Aujourd’hui, un premier palier doit être franchi pour gérer une volumétrie beaucoup plus forte et des utilisateurs d’un nouveau type : les clients. Des centaines de milliers voire des millions d’identités. Il faut maintenant gérer l’identité d’un client et pouvoir l’authentifier et l’autoriser sur les applications mises à sa disposition. Il faut savoir l‘authentifier simplement de son point de vue (e.g. via un réseau social) et faire le lien avec son compte traditionnel dans le CRM pour gérer la relation. Les opérateurs télécoms et les banques et leurs bases clients sont devenues le nouveau cas d’usage classique : les accès aux applications via Internet et terminaux mobiles sont dans l’air du temps.

Au-delà de ce changement d’échelle, les caractéristiques de ces identités de clients sont différentes des traditionnelles identités de l’entreprise : le nombre d’applications accédées et de rôles est plus faible. Par ailleurs, plus question de devoir gérer des cas particuliers, tous les clients sont logés à la même enseigne et ce pour le plus grand bénéfice des projets IAM qui vont enfin voir se réduire fortement leur complexité fonctionnelle.

Enfin, un deuxième palier s’annonce déjà : la gestion des identités des objets connectés. Le CES 2014 qui s’achève ces jours-ci nous en offre de multiples illustrations : brosses à dent, cocottes minutes, lits, ampoules, etc. Tous les objets du quotidien sont désormais connectés. Par ailleurs, la complexité et les facultés de ces objets nous environnant sont telles aujourd’hui que de nouvelles approches sont nécessaires.

Les premiers objets connectés étaient de simples capteurs : température, pression, cellules infrarouge, compteurs, etc. Généralement non connectés directement à Internet, ils émettaient de l’information dans un protocole spécifique à destination d’une passerelle qui elle avait pour rôle de centraliser les données et de les transmettre via Internet à un serveur de traitement.

Nouveaux usages et nouveaux besoins

L’identification de ces objets est alors très sommaire, allant de la simple déclaration d’adresse MAC jusqu’à l’utilisation d’une clé de chiffrement des échanges pour les installations les plus sophistiquées.

Les objets connectés sont maintenant non seulement émetteurs de données de plus en plus complexes mais également destinataires de commandes et d’action à réaliser, de correctifs et patches de sécurité, etc.

Dernier cas d’usage classique à la mode : la voiture connectée informe directement le constructeur ou le concessionnaire qu’un sous-composant est en mauvaise santé ou qu’une révision est nécessaire.

Ces objets doivent pouvoir être joints depuis n’importe où (et ne plus être masqués par une passerelle) et par ailleurs, les capacités d’attaques cybercriminelles ayant fortement augmentés ces dernières années, la sécurité des échanges et l’authentification préalable des objets est devenu un prérequis. Et nous voilà donc avec des milliers d’objets disposant d’une identité !

Cet article Des objets et des hommes est apparu en premier sur RiskInsight.

Que peut apporter le SIRH à ma solution IAM ?

Pour remplir ses objectifs, mon IAM doit être en mesure de répondre à des questions simples  en apparence: qui est cet utilisateur, quel est son nom, son prénom, son matricule ? Quelle est sa fonction dans l’entreprise, quel métier exerce-t-il, et par extension, quelles applications devra-t-il utiliser, ou encore quelles listes de diffusion seront adéquates pour lui ? Qui est son supérieur hiérarchique, et peut-être futur valideur pour ses demandes d’habilitations ? Quelle est son organisation de rattachement ?

Obtenir ces réponses est un premier besoin… mais n’est pas le seul ! Ses informations évoluent : un nouveau collaborateur intègre l’entreprise dans une semaine, il faut lui donner le plus rapidement possible ses accès SI pour qu’il puisse travailler ; Mademoiselle Durand, anciennement contrôleuse de gestion, devient responsable de la comptabilité… il faut lui donner ses nouveaux accès, certes, mais également supprimer les droits qui lui sont devenus inutiles, voire qui pourraient devenir « dangereux » par rapport à son nouveau poste (SoD). Monsieur Thomas, lui, quitte définitivement l’entreprise – or il avait accès (et à distance) à une application critique du SI : ses accès doivent être supprimés dès son départ !

Ces éléments et leurs mises à jour sont généralement présents dans le SIRH d’une entreprise, notamment en raison du lien de celui-ci avec la paie, qui a besoin de savoir qui payer (et quand arrêter de payer), qui est responsable des augmentations d’untel ou d’untel, quelle entité sera facturée, etc. Avec de tels enjeux financiers à la clé, un soin particulier est généralement accordé au maintien à jour de ce référentiel… une opportunité pour mon IAM !

Des atouts certains… mais des limites à avoir en tête

Les liens possibles entre SIRH et IAM sont donc bien réels. Mais attention cependant à ne pas oublier un point essentiel : systèmes d’information et ressources humaines sont deux univers différents, portés par des métiers différents, avec des enjeux, des objectifs, des vocabulaires différents.

Comme nous l’avons dit, le référentiel SIRH est souvent lié à la paie, et cette relation permet d’illustrer les limites des liens qui pourront, ou non, être tissés entre mon SIRH et mon outil d’IAM.

Première limite, là où la paie n’a besoin d’avoir dans son périmètre que les personnes qui seront payées par l’entreprise, mon IAM, lui, se doit de connaître tous les utilisateurs de mon SI, qu’ils soient prestataires, intérimaires ou salariés.

La notion de métier ou encore de hiérarchie n’est pas forcément identique dans le SIRH et  pour l’IAM. Pour le SIRH, Mme Mercier est supérieure hiérarchique de Mlle Durand, car c’est elle qui est responsable de ses augmentations… mais au quotidien, c’est M. Simon son manager ! Et c’est bien lui qui sera légitime pour valider les demandes d’habilitations de Mlle Durand. Les priorités ne sont pas non plus toujours les mêmes entre ces deux univers : un nouvel arrivant doit avoir ses accès SI (et donc être créé dans l’IAM) dès son arrivée… en revanche, il y a souvent moins d’urgence à le créer dans le SIRH, car il ne percevra son premier salaire qu’à la fin du mois…

Lorsque qu’il s’agit de parler de mobilité interne, les deux mondes peuvent également avoir quelques différends. Un collaborateur change d’équipe projet, tout en restant rattaché au même département ? Au niveau du SIRH, ce n’est pas une mutation, son métier reste la même. D’un point de vue SI, a contrario, ce changement constitue un petit bouleversement : son responsable opérationnel (et valideur) n’est plus le même, et l’utilisateur n’a plus les mêmes besoins en termes d’applications métiers. À l’inverse, un changement de nom d’organisation pour toute une filiale n’a quasiment aucun impact sur le SI, alors que tous les utilisateurs sont impactés dans le référentiel RH.

Comment s’interfacer avec le SIRH ?

Comme nous l’avons vu, le SIRH est capable de fournir énormément d’informations structurantes pour ma solution d’IAM, mais possède des spécificités à ne surtout pas négliger. Afin de tirer pleinement parti de cette source d’information et réussir un interfaçage propre, efficace et limitant au maximum les malentendus entre ces deux mondes, trois éléments sont nécessaires :

• Dans un premier temps, définir les éléments structurants pour l’activité opérationnelle et qui seront exploités par l’IAM : les organisations de rattachement des utilisateurs, leurs supérieurs hiérarchiques, les dates d’arrivées et de départ, etc.

• Il est ensuite primordial de se doter de l’organisation, des processus et outil d’IAM flexible, capable de s’adapter aux différences évoquées précédemment. La solution IAM doit ainsi permettre la création d‘identités en avance de phase, ou encore la modification manuelle de certains attributs d’identité. Elle doit conserver une certaine marge de manœuvre sur la gestion de ses identités, ne pas avoir une dépendance trop rigide vis-à-vis du SIRH.

• Enfin, une attention particulière doit être portée à la réconciliation entre les identités du SIRH et celles de l’IAM. Qu’un utilisateur soit créé « en avance » dans l’IAM, ou que certains de ses attributs soient modifiés manuellement, le lien avec le SIRH doit être assuré… faute de quoi, gare aux doublons et aux identités fantômes. Définir une clé unique de réconciliation entre les identités est indispensable pour un interfaçage efficace… et pérenne !

Le SI RH peut se révéler d’une aide précieuse pour la gestion du cycle de vie des utilisateurs grâce aux informations dont il dispose sur les personnes et sa connaissance des mobilités et départs. À condition toutefois de bien comprendre les processus RH sous-jacents, leurs particularités par rapport au monde du SI, et de s’y adapter dans une logique de gestion des identités et de contrôle des accès, sujet qui fera l’objet d’un prochain article.

Cet article Interface avec le SIRH : une opportunité pour l’IAM ? est apparu en premier sur RiskInsight.

Le certificat au coeur de la confiance numérique

Au centre de la confiance numérique repose le fameux « certificat ». Cette carte d’identité numérique, délivrée par les infrastructures de gestions de clés (IGC ou encore PKI),  permet de garantir qu’une personne, un équipement ou un service est bien celui qu’il prétend être dans le monde numérique.  Ce certificat est stocké sur des supports variés, pouvant être physiques (carte à puce, clé USB, badge) ou logiques (fichier). Il a le rôle d’une carte d’identité présentée lors de l’accès à des services ou à des informations pour prouver son identité.

Structurer une offre de services sous 3 axes

Pour tirer le meilleur parti des investissements réalisés, nos retours d’expérience montrent que l’entreprise doit s’attacher à construire son catalogue de service de confiance numérique en trois volets.  Premier volet, la fourniture simple de certificats. Les utilisateurs finaux pourront alors utiliser ces certificats dans leurs propres systèmes ou pour leurs projets techniques. C’est par exemple le cas de projets d’applications web métiers, d’authentification réseaux (802.1x)… Deuxième volet, la fourniture de services de confiance destinés à l’utilisateur et intégrant des certificats. Il s’agit par exemple de projets badges uniques (bâtiment, restauration, système d’information…), de chiffrement de messagerie ou de poste de travail. Le certificat est alors intégré de manière transparente dans les services fournis. Troisième et dernier volet, la fourniture de services « métiers » intégrant la confiance numérique. La dématérialisation des processus (bulletins de paye, facturation), les coffres forts numériques ou le stockage à valeur probante sont des exemples parlants.

Les 3 règles d’or de la construction

Mais au-delà de cette catégorisation, quels sont les éléments clés de la constitution de ces services ?

Règle n°1 : identifier les premiers « quick wins »

Le premier défi rencontré est celui de l’identification initiale et de l’extension du périmètre des services. L’implication des acteurs sécurité permet de recenser les besoins et préciser les volumétries, selon différentes typologies d’utilisateurs. L’identification de « quick wins » permet de cibler les premiers investissements à travers la valeur ajoutée des services qu’ils offriront. A cet égard, on peut envisager de ne retenir d’abord qu’un nombre limité de fonctionnalités de sécurité, au profit de fonctionnalités dites « de confort ». On pourra ainsi, dans un premier temps, coupler accès distant au SI (VPN) et messagerie sécurisée (signature et chiffrement de mails) et dans un second temps, une fois les identités numériques largement déployées, s’atteler à la greffe de services de sécurité éventuellement plus poussés : chiffrement de données, signature de documents, signature de code.

Règle n°2 : privilégier l’ergonomie et la facilité d’usage

En outre, l’ergonomie des outils doit rester au cœur des préoccupations : simplicité d’emploi, transparence de l’intégration au poste de travail, mais également gestion des accès de secours. Car si l’implémentation de ces derniers constitue souvent une atteinte au niveau de sécurité des outils, force est d’avouer qu’une offre rendant l’oubli du support cryptographique (carte à puce, clé USB.) bloquant pour l’utilisateur, compromettra l’acceptabilité de la solution toute entière, notamment auprès des utilisateurs les plus exigeants. lesquels sont aussi souvent les plus influents. C’est pourquoi  une étude précise des besoins des métiers permettra d’identifier le meilleur compromis entre niveau de sécurité et types d’accès de secours exigés par les utilisateurs. Notons également l’importance du dispositif utilisé, clé du succès de l’offre : un projet de badge unique, offrant par exemple, l’accès aux bâtiments, le paiement à la cantine et la sécurisation de la messagerie, comprend de vraies complexités organisationnelles mais apporte une valeur ajoutée considérable

Règle n°3 : le RSSI, sponsor de choix

Last but not least, notons que le RSSI doit, autant que possible, servir d’appui moteur au déploiement des services, que ce soit de façon directe, par exemple par le biais d’une participation au financement du projet abaissant ainsi le coût utilisateur, ou de façon indirecte, via la promulgation de règles de sécurité imposant in fine l’utilisation des services de confiance. Ce sponsoring est d’autant plus crucial que la plupart du temps, l’appétence des utilisateurs finaux pour les services de confiance numérique est relativement modeste et ne suffit pas à donner un élan au projet

La confiance a de l’avenir

Le monde a commencé sans l’homme et s’achèvera sans lui”, nota le crépusculaire Levi-Strauss. “L’homme a commencé sans l’informatique et s’achèvera sans elle”, pourrons-nous dire de façon analogue. Nous avons montré plus haut que, si la confiance est d’ores et déjà au coeœur de beaucoup de services offerts par les DSI, cela n’occulte en rien le fait que cette notion dépasse largement l’IT. Les technologies changent mais les principes et processus perdurent, aussi le périmètre des services de confiance s’étend-il inéluctablement aux usages métiers les plus divers, à travers la dématérialisation notamment. Le chemin est, nous l’avons vu, semé d’embûches, mais pour l’offreur avisé, c’est donc un succès assuré. Ad augusta per angusta ! (*)”

(*) “Vers la gloire, par des chemins étroits” (Victor Hugo, Hernani)

Cet article Services de confiance numérique : pour que le contrat de confiance règne ! est apparu en premier sur RiskInsight.

Forts de premiers projets réussis, les années 2010 marquent une rupture en la matière, puisque l’on voit alors se développer rapidement l’utilisation conjuguée de la dématérialisation et de la signature électronique à destination du grand public. Cela s’explique par  trois facteurs.

Un cadre réglementaire aujourd’hui maîtrisé

En 2001, la législation française institutionnalisait la signature électronique  par les articles 1316-1 et 1316-4 du code civil et le décret n°2001-272 du 30 mars 2001. Elle rendait alors la signature électronique équivalente à la signature papier, sous condition du respect des principes d’identification fiable du signataire et d’intégrité des données. Pourtant, la frilosité l’emportait, faute de retours d’expérience suffisants dans l’application de ce cadre juridique.

Il faudra attendre 10 ans pour voir se déployer plus largement la signature électronique. Quelques jurisprudences, bien qu’encore peu nombreuses, confortent les entreprises : celle de décembre 2010, par exemple, concernant  la reconnaissance juridique de la notification électronique d’une demande de résiliation (exemple d’un abonnement téléphonique) portant une signature électronique (http://www.resilier.com).

Des premiers succès rassurants dans le B2B et les administrations

Ces dernières années, des projets plutôt B2B ont vu le jour. Les grandes entreprises ont mis en œuvre des solutions de dématérialisation et de signature électronique pour des usages professionnels (ex : signature de remises réglementaires pour les établissements financiers, signature d’ordres de paiement pour les trésoriers d’entreprise, signature de contrats entre professionnels). Ces solutions s’appuient sur l’utilisation de certificats électroniques, preuve de l’identité numérique personnelle de son porteur, indispensable à la signature électronique.

Déjà éprouvées par les entreprises, ces solutions sont désormais matures et peuvent être réutilisées pour de nouveaux usages destinés au grand public.Le grand public est prêt et demandeur !

Le grand public est aujourd’hui habitué et enclin à l’achat de biens et de services sur internet, ainsi qu’à l’utilisation de processus administratifs dématérialisés en ligne (Mon Service Public, déclaration des impôts, consultation de données personnelles de santé, facturation électronique des fournisseurs d’énergie et d’internet…).

De plus, conscients des risques de fraude et d’usurpation d’identité, le grand public est dès lors sensibilisé à l’utilisation de moyens de sécurité lors de transactions en ligne, tels que l’envoi de code par SMS, l’utilisation de carte bancaire virtuelle, de clavier numérique, de certificat électronique, etc.

Enfin, le grand public montre une appétence de plus en plus forte pour l’obtention de biens et de services rapidement, voire même de façon immédiate.

Les banques françaises (BNP Paribas, LCL…) participent fortement à cet essor ; elles offrent, depuis plusieurs années déjà, la gestion en ligne des comptes bancaires (suivi de comptes, opérations de virement…) ; et plus récemment, elles proposent la souscription en ligne à des services bancaires (ex : livret d’épargne, prêt à la consommation, assurance) à leurs clients particuliers, grâce à la signature électronique mise en œuvre par l’utilisation de certificats électroniques personnels. Cette  offre répond pleinement aux attentes du grand public.

Comment lever les derniers freins ?

Il reste aujourd’hui un frein majeur au développement de la signature électronique en France : la distribution et la gestion des  parcs de certificats pour le grand public.

Des opérateurs de téléphonie mobile (SFR en France, Turkcell en Turquie) ont ainsi créé des partenariats avec des fournisseurs de puces SIM cryptographiques (Oberthur, Gemalto), afin de fournir à leurs abonnés des mobiles embarquant une solution de signature.

Ces offres, reposant sur une collaboration entre opérateurs mobiles et banques, permettent aux abonnés d’accéder à des services sécurisés en ligne grâce à leur mobile, tel que l’achat en ligne et la banque en ligne, sans aucune transmission d’informations bancaires.

Par ailleurs, le gouvernement français renouvelle sa volonté de développer l’usage du numérique avec la préparation d’un nouveau plan France Numérique 2020, qui sera dévoilé d’ici 2012, avec la perspective d’y voir s’inscrire des projets concrets de confiance numérique.

Ces innovations et projets dans la confiance numérique permettront certainement de lever les derniers freins quant à la distribution et la reconnaissance des certificats électroniques.  En effet, c’est grâce à la demande du grand public et l’implication des grands acteurs du B2C et de l’administration (G2C) que la signature électronique pourra décoller !

Cet article Dématérialisation et signature électronique : vers l’explosion des usages grand public ? 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.

La difficulté de la prédictibilité des coûts dans le cloud

Le modèle du cloud nécessite une attention forte pour ne pas perdre au bout de quelques temps les gains économiques escomptés, voire éviter une réelle dérive des coûts. Dans le cloud, comme au sein du SI historique, une gestion fiable des identités est ainsi essentielle pour garantir durablement la maîtrise du nombre d’accédants à ces services.

Bien évidemment, elle vise également à renforcer la protection de l’accès aux informations qui y sont stockées. Elle y est même encore plus indispensable, vu l’absence de garde-fous traditionnellement rencontrés, comme par exemple la « porte d’entrée » Active Directory ou le contrôle d’accès physique.

Gérer les identités dans le cloud : quelles stratégies gagnantes ?

Comment le faire concrètement ? Plusieurs solutions sont envisageables :

–       Gestion manuelle sur le site du service cloud par les équipes de l’entreprise. C’est certes efficace pour lancer rapidement des initiatives cloud, mais il faut prévoir de rencontrer, tout aussi rapidement, toutes les limites bien connues de la gestion manuelle : écart, difficultés de maintien, complexité des revues…

–       Gestion automatisée via un service de provisioning/deprovisioning avec des contrôles a priori (validations) et/ou a posteriori (contrôles et recertifications) : l’accès aux services cloud piloté par les processus et les outils IAM de l’entreprise. Mêmes solutions que dans le SI historique… et mêmes vigilances et bonnes pratiques pour éviter toute désillusion !

–       Gestion automatisée via un service de fédération d’identités : certainement aujourd’hui la solution à privilégier quand cela est possible, puisqu’elle apporte des réponses satisfaisantes aussi bien sur les problématiques de gestion au quotidien qu’en termes d’expérience utilisateur. Après des années de balbutiements où les entreprises n’allaient quasiment jamais plus loin qu’un prototype, les derniers dix-huit mois marquent le réel envol de la fédération avec des réalisations significatives.

–       Gestion automatisée et fédérée par un tiers de confiance, jouant le rôle d’intermédiaire entre l’entreprise et les différents offreurs de services cloud. Des acteurs commencent à se positionner sur ce sujet, mais la classique question de la confiance se pose !

Le cloud : un booster pour les projets IAM

Sujets à traiter, bon sens et bonnes pratiques, priorisation et angles d’attaque, risques et écueils à éviter : la gestion des identités dans le cloud doit relever les mêmes challenges que dans le SI historique.

Et si le cloud était un levier formidable pour d’une part simplifier et fiabiliser les processus et outillages IAM actuels, et d’autre part faire décoller l’usage de nouveaux services IAM de type reporting et recertification ?

Cet article Cloud computing : maîtriser ses coûts grâce à une bonne gestion des identités est apparu en premier sur RiskInsight.