In order to manage this evolution, the European Union has adopted the Payment Services Directive. In its second version (PSD2), published in 2015, this directive was set to create and regulate the Open Banking sector. The goal was to enable users to provide an access to their banking and accounts data to innovative new actors such as aggregators and payment initiation providers, while ensuring security and competition at a sufficient level in the payment services ecosystem.

Unfortunately, PSD2 limits have started to show, including:

• Unharmonized legislations leading to « Forum shopping » which is a legally grey practice consisting, for a payment services provider, to choose their incorporation country based on the local legislation that would be most favourable to them.
• A gap that was not sufficiently closed between banks, which are in a privileged position to provide payment services to consumers, and third-party providers that depend on them.
• Fraud, with methods changing along with the payment markets, and for which PSD2 provision are now considered as insufficient.

Therefore, the European Union has introduced a draft for a 3rd version of the directive, the so-called PSD3, on June 28th, 2023. A final version is expected for late 2024 or early 2025. The text will be enforceable 18 months after publication, which would be somewhere around Q3 2026.

How will PSD3 be introduced?

Upon reading the draft, it is clear that where PSD2 has introduced completely new and structuring concepts like the notion of Open Banking or Strong Customer Authentication, PSD3 is aiming at updating existing concepts. As indicated on the European commission website, it is

« an evolution, not a revolution ».

The format changes: PSD3 is introduced with a regulation called PSR (Payment Services Regulation). Its content is using a lot of elements already present in either PSD2 or its RTS (Regulatory Technical Standards). The novelty here is in the type of legislation: it is a regulation, which is directly applicable in member states, contrary to directives, which need to be translated into local law. This is one of the solutions the EU has adopted to tackle the previously mentioned harmonization issue.

The regulatory framework for e-money also finds itself simplified. The practical issues caused by the existing differentiation between online payments, regulated by PSD2, and the use of e-money, regulated by the 2009 Electronic Money Directive (EMD) will disappear since PSD3 now covers both types of services.

Additionally, PSD3 brings a few clarifications in its definitions. Though these are not technically new changes, here are some of them:

• Deposit accounts, such as savings accounts, are now explicitly excluded from the definition of payment accounts.
• Aggregators are now defined by their capacity to collect and consolidate banking information on payment accounts and the like, regardless of whom the aggregated information is destined to.
• Multifactor authentication relies on multiple factors in classically defined categories (knowledge, inherence, possession), but it is now clarified that to count as an MFA, authentication factors need not belong to different categories, they only need to be independent (defined as: compromission of one does not affect security of the other).

What will the various payment service providers have to do to comply to PSD3?

Key PSD3 evolutions are technical changes with the aim to protect consumers against fraud.

Therefore, payment services providers will have to develop and provide new services for their users. A first example is an access permissions dashboard enabling them to monitor in real time who is allowed to access their banking and payment account information. Another example is the payee’s name verification service, wherein the name of a payment recipient is compared to the receiving account holder name, and the result of that comparison is made available to the payer to try and prevent identity theft.

Likewise, PSD3 has some provisions planned for strong customer authentication accessibility. All banks will have to be able to provide an adequate strong authentication means for all their users, including people with disabilities, the elderly, people with poor technological skills or without smartphone etc.

The addition of a new actor will shift the repartition of compliance responsibilities: this actor is the Technical Services Provider. They will inherit part of the compliance and audit responsibilities, especially in the case where strong customer authentication is delegated by the bank to their third-party solution.

What will be the impact of those changes?

Through the aforementioned PSD3 changes, banks and other payment services providers are incited to share and exchange information to fight against fraud: some dispositions are already taken to be able to do so while complying with GDPR.

Especially for the payee’s name verification service, Open Banking APIs will have to be updated to allow this verification by the payer’s bank. Since this operation is quite complex, and even more so when the transfer is supposed to be instant, the associated article will enter in force 2 years after the rest of the regulation (not before Q3 2028).

Users will also see new features appear, meaning some time will be needed for them to adapt and get familiar with those features. Some level of support will have to be set up for all involved parties, including users but also customer support teams, to foster a correct understanding and adoption of these features by users.

If the final text is published before early 2025, companies from the payment sector will have until Q3 2026 to achieve compliance with PSD3 and PSR.

It is essential to start considering these changes starting today and ensure a certain level of regulatory watch to stay informed of the various texts (including RTS, guidelines) that will be published by both the European Commission and the European Banking Authority.

[1] 2023 annual report, French Observatory for the security of payment means

Cet article Shift towards the 3rd Payment Services Directive: what will the impacts be? est apparu en premier sur RiskInsight.

At the same time, fraud has grown in scale and complexity. According to the Banque de France, payment fraud will represent a loss of 1.2 billion euros by 2022, a considerable sum which is unlikely to diminish as fraudulent transactions continue to increase. Around 70% of these fraudulent transactions come from online banking.

The fight against fraud is therefore one of the most important concerns for online banking, but other sectors are also beginning to address the issue.

Identity fraud, business fraud

The term fraud is part of everyday language and can have a wide variety of definitions. It’s possible to “defraud” a metro ticket, an insurance policy, or a loyalty account with a major retailer.

When it comes to computer fraud, particularly banking fraud, we distinguish between identity fraud and business fraud.

The former involves manipulation of the issuer’s identity data, the context in which he/she accesses the service, or information relating to his/her authentication and authorization. This can be detected by analyzing the user’s authentication behavior, the machine he is using, the IP address from which he is connecting, and so on.

The second involves manipulating data relating to the transaction itself, the banking profile of the sender and receiver, and the context in which the transaction was carried out. Indicators of business fraud could be, for example, a receiving IBAN from an unusual country, a large transaction amount, etc.

The two types of fraud and their detection rely on different signals, but these two protection mechanisms can and must exchange and feed off each other to provide additional context and enable a more holistic analysis of risk.

This need for synchronization has led to a recent organizational rapprochement between business fraud and IAM teams.

What risks are covered by identity fraud detection?

Identity fraud conceals many different uses. Detecting it therefore covers a wide range of risks that are difficult to apprehend today. Here is a non-exhaustive list of techniques used by attackers that could be detected by an anti-fraud tool:

• SIM swapping: SIM swapping involves convincing the victim’s telephone provider to send a new SIM card to the attacker, who can then validate double authentication requests via OTP by pretending to be the victim.
• MFA fatigue: MFA fatigue involves sending a large number of MFA validation notifications, to the point where the victim ends up accepting the request and inadvertently authorizing access to one of their accounts.
• Social engineering: social engineering is used in attacks targeting an individual, where the attacker gathers information about them and their bank account, then exploits it to extract money from them. An increasingly common example is bank advisor fraud, in which an attacker poses as the victim’s advisor and urges him or her to make a bank transfer, often under the pretext of a risk of… fraud.
• Bots: attack automation opens up new possibilities for attackers, who can target a large number of accounts in a single campaign. By emulating devices or launching massive phishing campaigns, it is becoming increasingly easy to recover personal information and passwords.

Banks in the lead, but joined by new players

Unsurprisingly, the banking sector has a head start on these issues. Firstly, because the impact of fraud is very real, and the bank is a prime target. Secondly, because users are accustomed to, and even reassured by, significant security processes at the expense of their user experience. Finally, because the massive shift to online banking has raised questions that other sectors didn’t have to ask themselves immediately.

Today, fraud detection for an online bank focuses on three key stages of the user journey:

• Enrolling a new device.
• Validating a payment.
• Performing sensitive actions on the account, such as adding a beneficiary for transfers.

While the banking sector is undoubtedly the most affected and the most protected, other sectors are beginning to address the issue of fraud detection. Retail, e-commerce, and luxury goods, for example, are all in the crosshairs of attackers. This is forcing these sectors to devise new processes and invest in the fight against fraud, in turn driving the evolution of solutions and practices to limit the impact on business.

New technological advances: protocols and algorithms

The pressure of attacks explains much of the interest in fraud detection solutions. These have developed rapidly, embedding more and more functions and demonstrating a growing capacity to combat the complex attacks that are on the rise.

Recent technological advances in fraud detection are manifold, but two main mechanisms have made these solutions more powerful: the ability to exchange information between detection bricks, and the precision of risk estimation algorithms.

The first mechanism is a product of the current trend towards standardization of detection protocols and signals, enabling the various IS bricks to pool the information gathered and the appropriate reactions. The Shared Signals working group (Okta, Cisco, Disney, OpenID Foundation, etc.), for example, has produced a framework used in two protocols: Continuous Access Evaluation Protocol (CAEP) and Risk Incident Sharing and Coordination protocol (RISC).

The second mechanism – the precision of algorithms – is based on the growing number of criteria that can be exploited. A few years ago, a detection engine relied on IP analysis, geolocation and a few identity attributes. Today, the criteria are multiplied, including the user’s own behavior (mouse movements, typing speed), analysis of the devices used (model, OS, browser), account history, common user paths, as well as a panoply of weak signals from other applications or IS bricks. This multiplication of signals entering the algorithms enables a much more refined analysis of each transaction, and an ever more pertinent estimation of risk.

AI and orchestration in the fight against fraud

Increasing the number of criteria helps to improve algorithms, but to get the most out of this information it is essential to take advantage of the capabilities of Machine Learning and artificial intelligence. Each criterion becomes a dimension enabling AI to dynamically learn user behaviours (such as common paths, mouse click locations or typing speed) and what constitutes a normal, non-risky access context, in order to better detect anything that deviates from it.

Despite AI’s ability to produce a decision from a very large number of parameters, it remains a victim of the setbacks of all decision algorithms: false positives. And with the interest of new sectors, which need to balance security and user experience to limit negative impacts on business, the management of false positives is an issue in its own right for software publishers. Today, detection models can be adjusted in several ways: by training them recurrently, to adapt them to new use cases; by playing with the weights of the criteria, according to the customer’s context; and by going back over the decisions taken by the algorithm in order to report false positives.

Beyond these adjustments, fraud detection solutions offer great flexibility in terms of orchestration, i.e. the reaction to be implemented in response to the algorithm’s recommendations. In this way, it is possible to limit the impact on users, by using invisible challenges for low-risk transactions, and by limiting constraining requests such as MFA or deferred manual processing to high-risk transactions. Orchestration also makes it possible to implement the tool progressively: reactions can be limited to raising alerts transmitted to a SIEM tool, for example, to refine the algorithm, then moving on to effective, real-time blocking.

Conclusion

The fight against fraud is a subject that concerns many sectors. While the banking sector is ahead of the game, with e-commerce and luxury goods following suit, any organization can be targeted by fraud. This implies a wide range of use cases and issues to which fraud detection solutions can often, but not always, respond.

The sector of activity, the context, the recurrence and type of attacks, the impact and associated risk, as well as the resources that can be deployed – all these dimensions need to be taken into account to contextualize countermeasure solutions. These solutions may be expensive or unsuitable, despite the innovative mechanisms put in place, and other remediation mechanisms may need to be considered depending on the context.

This is the case with anti-bot solutions, for example, or risk-based authentication mechanisms, or simply the redesign of certain business processes to make them intrinsically more resilient to fraud. These remedies can accompany a fraud detection solution or be sufficient to counter the cases of fraud observed in the context studied.

Cet article Fighting fraud: a new challenge for digital identity? est apparu en premier sur RiskInsight.

So, despite some success stories and the cardinal role of identity in business transformation, IAM remains a disparaged theme in organizations, synonymous with a “necessary evil” rather than a “key issue” for the company.  

How can we restore IAM’s reputation? How can we explain it better, and give it its rightful place in the enterprise? 

The paradox of identity 

An essential driver of transformation programs… 

This situation is paradoxical as identity plays a fundamental role in current transformation programs, presenting three major assets. 

• It is first of all a pillar of cybersecurity by allowing: 
  • Have a homogeneous knowledge of all users, centralizing essential information such as name, manager, title and many other characteristics specific to each; 
  • Guarantee the uniqueness of individuals through the publication of a single repository; 
  • Control and adapt user access throughout their lifecycle; 
  • Be part of a Zero Trust approach by ensuring that only the right people, with the right level of rights and the right level of authentication access to the appropriate resources. 
• It is also an essential business facilitator, particularly for: 
  • Accelerate cloud service adoption and deployment of new applications through automatic account creation and simplified entitlement (often through an IGA – Identity Governance & Administration tool); 
  • Facilitate the controlled opening of the IS to and towards third parties: partners, suppliers or in case of creation of Joint Ventures; 
  • Improve, thanks to CIAM (Customer Identity and Access Management), the customer relationship and regulatory compliance by simplifying the progressive creation of accounts and compliance with privacy regulations such as the GDPR in France. 
• Finally, efficient identity management is a prerequisite for a state-of-the-art user experience, combining comfort and security requirements: 
  • Seamless and seamless access to all its applications and data, regardless of its access context; 
  • Access rights granted automatically and available on the day of arrival; 
  • A single portal to make and follow up your ad-hoc requests. 
  • Pertinent dashboards and targeted review campaigns to meet regulatory requirements without over-soliciting managers and process owners. 

… but a theme unfairly considered 

Despite the significant advantages it represents, the theme of identity is rarely at the centre of companies’ concerns. It is rather perceived as a necessary evil, or even occupies a place of «ugly duckling». Thus, it is common to note the pitfalls when Identity is insufficiently well managed, and even more common to consider as normal and acquired the benefits it produces. 

Beyond the simple constant, it is necessary to understand the reasons that led to this situation of lack of investment, sponsorship, even recognition. 

First explanation of the paradox: the dispersion of expected gains towards different beneficiaries. Indeed, the IAM is, by nature, very transversal in the company. To succeed, it must embrace a wide range of topics and therefore mobilize many stakeholders. If each of them will see gains; none will stand out enough to bear primary responsibility. For example: 

• The identity makes it possible to simplify the customer relationship, subject of major interest for a marketing/ digital manager, but not the compliance manager. 
• The latter will see identity as a significant advantage in meeting the CAC’s access review requirements. 
• The IT department will expect consistent and automatic management of the allocation of accounts and rights, synonymous with financial gains, particularly in terms of licenses, support, etc.  
• As for the CISO, its priority will be to remove access in the event of departure and the application of the principle of “less rights granted or the early detection of “suspicious” behaviour. 

Second explanation: like any transformation, which is transversal, the launch and success of an identity project is conditioned by essential prerequisites. 

The difficulty and effort required to achieve these prerequisites depend on the context of each company; but the prerequisites themselves are relatively constant and can be articulated around 4 axes: 

• Data quality: both for data consumed by IAM (organizations, structures, identity data from HR…) and for data that IAM must make available (application account identifiers, attributes in applications…).
• In-depth knowledge of end-to-end processes: this is essential to anticipate the impact of future changes on users, but above all to be able to change and harmonize ways of doing things, and not to continue with what already exists “because that’s the way it’s always been done”.
• Mastery of the applications to be connected: it is necessary to mobilize both technical knowledge (technologies used, APIs available…) and functional knowledge (user populations, data model, authorization model…).
• Last but not least, the ability to impose a “normative” IAM framework, to find a compromise and to arbitrate both on the target (operational model, functional framework, attributes and management rules, arrival/mobility/departure processes, standardized connection framework for applications…) and on the trajectory and success indicators (priorities, subdivision…). To put it in a nutshell: “It’s not IAM’s job to heal what has been poorly thought out or what has become inadequate over time“. 

Third and last explanation: a complete identity management is based on several complementary technological bricks. With varied origins and somewhat ambiguous names, it is not always easy for a non-expert in the field to understand precisely the contribution of each of these bricks: 

• IGA – Identity Governance & Administration: Identity Governance 
• IAI – Identity Analytics & Intelligence: Data analysis and control 
• PAM – Privileged Access Management: Privileged Account Management 
• AM – Access Management: Authentication and Access Control 
• CIAM – Customer Identity & Access Management: Client identity management 

What’s more, these names have evolved over time, sometimes legitimately to reflect major developments, sometimes more as a result of publishers wishing to differentiate their value proposition. The emergence of new functionalities (real-time detection, consent management, etc.) and the innovations proposed by software publishers are also changing the lexical field of IAM. 

How to give identity its rightful place in the company? 

To overcome this paradox, the usual avenues (high-level sponsors, more resources, evangelization, etc.) are necessary but often insufficient. More structural transformations are needed. 

Unify the strengths of identity under one banner 

IAM topics have emerged in scattered order in companies, and have matured at very different rates. The result is that, all too often, teams remain isolated. 

It is therefore imperative to bring together all identity-related teams and budgets under a single umbrella. And if, as the saying goes, there’s strength in numbers, the aim is not just to be visible, legitimate and have a say in the organization. 

Synergies abound: 

• Make identity a perennial and recurring topic, at the very least at the level of the CIO CoDIR, and in all company evolutions.
• Define a global value proposition, proposing a unified offering that is more legible for business lines and application managers, who will be able to rely on a single point of contact.
• Be part of a long-term strategy to take advantage of software publishers’ roadmaps, create a continuous improvement approach and prepare for future corporate changes: reorganizations, mergers & acquisitions, new ERP…
• Improve the consistency of IAM services and manage with end-to-end service indicators.
• Guarantee a high level of expertise by enhancing team know-how, building loyalty and offering richer development perceptives. 

This far-reaching transformation can appear delicate and a source of risk for companies with less mature IAM systems. This is why it is possible to initiate it gradually, starting from one of the following axes: 

• Bringing together under a single organization the teams working on the various IAM themes: IGA, IAI, AM, PAM and even CIAM.
• Unify the teams in charge of projects and those in charge of “RUN” in order to offer a “product” approach to each identity service, and to be part of a continuous improvement logic.
• Extend IAM teams’ responsibility for data control, so that they can commit to indicators and, ultimately, to the quality of service provided and perceived. 

On this last point, however, IAM teams cannot assume responsibility for the quality of the company’s data and repositories. They must, however, guarantee the quality of the service rendered, by ensuring both the proper operation of IAM services (the “container”) and the quality of the data manipulated (the “content”). IAM teams must therefore be equipped and organized to supervise, control and alert the quality of data received, as well as the use made of it. 

An advantageous unification but which obligates 

This ambition for unification, which puts IAM in the spotlight, de facto obliges the Identity manager to be exemplary in his role and responsibilities: 

• With regard to customers: have a clear service offering, take into account feedback and realities in the field, define and respect a roadmap of evolutions, provide “meaningful” service quality indicators, i.e. those that make sense in the day-to-day life of the business, promote gains and benefits…
• Regarding other stakeholders in the company (HR, Purchasing, Cybersecurity, Regulatory Compliance, Audit and Control…): communicate, materialize and help to appropriate the Identity value proposition on a day-to-day basis and during structural transformations (reorganizations, acquisitions…), find ways to compromise, show the “win-win” character of process and operational model evolutions, share everyone’s roles and responsibilities, illustrate the impacts in the event of breaches… 
• For its teams: have a robust operating model, balance responsibilities between internal employees and external service providers, build a genuine HR ambition for the medium and long term (validation of expertise, talent management, building career paths, enhancing the value of the IAM channel…). 

Conclusion 

The unification of IAM services is a fundamental trend, and within 3 years a large majority of large companies will have converged towards this model, at least partially. 

This movement is not always the result of a desire to reposition identity within the organization on a long-term basis. It is sometimes imposed by teams to compensate for a lack of resources or expertise, or in the hope of keeping costs down; in such cases, it reinforces the feeling of lack of consideration. 

And yet, there are many opportunities to demonstrate the need for an in-depth rethink of IAM ambition, and to give it its rightful place: technical obsolescence of IAM tools, corporate strategy to switch to Cloud solutions, difficulties in accompanying structuring transformations in the organization, new regulatory requirements, or the results of a simple satisfaction survey among users or application managers…  

Do you dare to seize them? 

Cet article ​​How to give identity its rightful place in the company​  est apparu en premier sur RiskInsight.

Although opinions are divided between the enthusiastic, the fearful and the sceptical of AI, the most optimistic argue that artificial intelligence can improve our work processes and facilitate sometimes repetitive actions by posing as an enabler to the completion of our tasks.

But can these advances be applied to IAM? Can we delegate the management of our identities and accesses in whole or in part, when the protection of user data has become a major concern?

AI and IAM: a new challenge for companies

A fundamental question arises when it comes to thinking about the relationship between AI and IAM: insofar as IAM systems exist to establish digital trust, whether towards our employees, customers or partners, is it possible to guarantee that AI-based solutions will ensure this same level of trust?

Despite the possible questions, we believe it’s imperative to consider the possibilities offered by AI. IAM teams need to open up to these new challenges and adopt a “Test & Learn” approach based on concrete use cases. Collaboration with IAM editors, integrators or internal Data or AI teams is necessary to explore all the possibilities.

What’s more, we’re convinced that the current environment offers fertile ground for the adoption of this approach:

• Corporate management and businesses are seeking to understand the potential impact of AI on different aspects of the business, and IAM teams need to be able to provide answers.
• The development of Cloud offerings for identity and access management, and the increased convergence of Access Management (AM) and Identity Governance and Administration (IGA) solutions, are creating a favourable environment for the development of AI. Training algorithms can access more data, facilitating the production of value.
• The threat landscape is evolving ever faster – with AI in particular – and IAM teams are faced with ever more needs in terms of compliance, security, user experience and operational efficiency.

So it seems natural to ask whether AI can help solve these challenges by looking at real-life use cases. In this article, we’ll take a closer look at the possibilities offered by AI, the key levers likely to be impacted by its use, and how it might (or might not) change the way we operate around IAM.

The contribution of AI to the 3 key challenges of IAM

The analysis of different use cases taking into account AI for IAM has been thought around the 3 drivers of IAM:

• Cybersecurity and compliance
• User experience
• Operational and business efficiency

The use cases presented below are the fruit of the reflections of some forty consultants and IAM professionals who were invited to question the contribution that AI can make to IAM through various workshops.

Be a lever for cybersecurity and compliance

Use case 1: Continuous verification

At present, there are numerous mechanisms in place to monitor a user’s behaviour using various criteria (location, device used, etc.). Adding artificial intelligence to a continuous verification process would maximize the potential for surveillance during and after user authentication by:

• Aggregating a wealth of information about the user (behavioural analysis of keystrokes or mouse clicks, usual connection times, suspicious behaviour within the application, etc.)
• Providing appropriate automatic remediation (request for re-authentication, session termination, alerting security teams, etc.).

A number of software publishers are currently offering or planning to offer continuous verification functionalities. The aim is to use AI to continuously assess risks and apply security policies at login, but also during an active user session. These features reduce the risk of unauthorized access and so-called “post-authentication” threats, such as session hijacking, account hacking or authentication fraud.

Use case 2: Informed access approvals & reviews

Decision-making can pose challenges for both a manager and the user themselves, particularly when it comes to assigning or requesting rights.

Managers, for example, may not always have an in-depth knowledge of the specific rights to be granted to a member of their team, and it may be necessary to seek help in determining the best approach when assigning these rights.

What’s more, reviewing rights is a process that is generally unpopular with the various business units, even more so when it’s done manually. Managers may sometimes opt for a “default” validation of their team’s rights, due to a lack of time or knowledge.

This is where artificial intelligence can come in, offering fast and effective assistance to the managers concerned. It can provide recommendations for a user, taking into account various factors such as the number of people on his or her team with similar rights, the rights recently assigned to collaborators working with him or her, or the rights required for his or her activity. This assistance in assigning and reviewing rights and accesses provides valuable guidance for managers. It reinforces the legitimacy of user access rights, as well as security.

It’s worth noting that AI-based decision support is one of the most popular use cases currently being promoted by software publishers.

Enhance the user experience

Use case 3: Documentation of permissions

It is essential for users to have a comprehensive and detailed understanding of their authorizations and accesses. This enables them not only to know their access rights, but also to identify any gaps in their activities. A simple list of rights can sometimes be confusing for most users. However, the use of generative artificial intelligence could enable the rapid creation of an “intelligent” schema, offering a clear visualization of the rights accessible to the user, with a visual distinction according to certain criteria such as:

• Level of rights (consultation, modification, administration, etc.)
• Area of application (purchase management, payment validation, etc.)
• Right criticality
• Period of validity of rights
• Conditions for granting rights (approval cycle)
• History of rights used

In this way, AI could greatly facilitate users’ understanding of rights, by providing a clear, structured and contextualized view of their authorizations.

Use case 4: Dynamic authorization

Being blocked from accessing a SharePoint document, application or group due to a lack of rights is not a trivial situation, and can severely hamper the user experience, especially when processing times are important. However, when the resources accessed are not critical, artificial intelligence has a real role to play in automating access efficiently. For example, based on the fact that people in the same team or working on the same project have certain accesses, AI could temporarily grant access to a user to avoid any blockage. At the same time, suggestions could be offered to the user to make the request and gain extended access.

In addition, this dynamic approach to authorization may offer advantages in terms of license savings. If the allocation of a right in an application requires the use of a license, a temporary (“just-in-time”) allocation enables the user to use the license only as long as necessary for his or her tasks, before reallocating it to another user. In addition to improving the user experience, this approach can also generate significant budget savings.

Be a business enabler and improve efficiency

Use case 5: Birthrights automation

Joiner-Mover-Leaver (JML) processes are of crucial importance within corporate IAM processes. Among other things, they aim to control and facilitate changes in a user’s status according to a defined set of rules. This includes activating or deactivating access and assigning the appropriate level of rights according to the principle of least privilege, for example, by removing obsolete rights following internal mobility.

Users must therefore not be “blocked” (by a lack or absence of rights) when they arrive or move, as this would have a major impact on their activities.

Artificial intelligence could play a major role in these JML processes, by analysing the background of users occupying the same position/department, who have already received a set of rights on arrival. These analyses could generate suggestions for rights and accesses to be assigned to a new arrival in the same department. In addition, artificial intelligence could suggest improvements to mobility processes by suggesting a set of rights corresponding to the roles assigned in the new department, or even facilitate the evolution of business roles by proposing modifications to their composition.

Use case 6: IAM support assistant

Interactive chatbots are gaining increasing prominence within companies, assisting users in various processes such as incident creation or document retrieval.

However, thanks to artificial intelligence, these chatbots could also provide valuable support to cybersecurity and support teams by speeding up information retrieval. For example, cybersecurity teams could ask the chatbot to provide all user’s sensitive/privileged authorizations, while support teams could ask why a user is pending clearance for an application.

The considerable time currently spent by these teams searching for relevant information, retrieving the right incident tickets and reviewing user histories could thus be significantly reduced. These chatbots would be able to query IAM solutions, incident management tools and other enterprise tools to retrieve the necessary data. This would enable teams to concentrate on higher value-added tasks and resolve incidents more efficiently.

***

Far from being exhaustive, these few examples illustrate the diversity of application areas for AI within IAM. Other use cases could also benefit from AI, such as :

• Detection of incompatible access rights (Segregation of Duties): Identify incompatible rights according to business activities, proactively detect conflicts in user authorizations and propose remedies.
• Data quality optimization: Improve data quality by automatically reconciling large volumes of data, correcting duplicates or orphan data, reporting discrepancies or abnormal volumes, automatically cleansing and correcting data.
• IAM-system baseline security analysis: Evaluate the configuration of the IAM system against standards, best practices, vendor recommendations and external observations, and offer suggestions for strengthening security.

It’s important to note that ease of implementation and interest in all of the use cases mentioned vary according to a company’s . For example, in the industrial sector, the focus may be on process efficiency and safety, sometimes to the detriment of the user experience, due to complex and historical processes based on older technologies.

Nevertheless, in the workshops we organized around the topics of AI and IAM, here’s what emerged in terms of estimated feasibility and added value on the 9 use cases presented above:

What can we expect in the future?

AI enables and will increasingly enable us to respond to the 3 pillars of IAM (security & compliance, user experience and operational efficiency). Some use cases are already being proposed by vendors and will continue to evolve, others are on their roadmap, and still others are limited to technical constraints and remain at the stage of promising ambitions for the time being.

However, to focus solely on promises would be to put blinders on, and it is imperative to recognize and anticipate the risks induced by the use of AI in IAM right now: notably the possibility of deceiving authentication measures, the development of innovative identity-based attacks (high-quality phishing, deep voice fake, etc.) and the ability to exploit data and vulnerabilities within IAM systems and policies. There are also fears of biased decision-making in granting access, and of access management for AI that needs to be interconnected on all sides. These risks are also complemented by the risks inherent in AI: corruption of output data, theft of information by understanding the limitations/weaknesses of the AI model, the possibility of misleading the AI’s recognition capability… These risks have been addressed in greater depth in another article we recommend: Securing AI: the new challenges of cybersecurity.

What’s more, some use cases appear to be highly specific to the context and IAM maturity of each company, which may be a limitation for the time being towards software publishers, who generally target more generic use cases. Companies could then turn to in-house development solutions, but this choice is currently too costly, with no guaranteed return on investment.

Because of the associated risks, the lack of regulation, the fundamental role of IAM and a strong dependence on the context of each company, the current trend in AI in IAM is leaning more towards suggestion and decision support rather than autonomous decision-making, but for how long? The rapid emergence of AI and its increasingly frequent integration into our landscape begs the question of how long we have before trusting AI to get the right level of reactivity, detection and resolution… to cope with AI.

Cet article Artificial intelligence: a revolution in IAM? est apparu en premier sur RiskInsight.

Cet article Wavestone publishes its 2020 Belgian Cybersecurity Startup Radar est apparu en premier sur RiskInsight.

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

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

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

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

…MAKING APIs ESSENTIAL

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

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

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

WHAT’S THE RIGHT RECIPE TO SECURE YOUR APIs?

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

THE SECURITY AS USUAL BASELINE

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

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

A pinch of OAuth

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

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

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

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

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

LIMIT THE ADDITIVES

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

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

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

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

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

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

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

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

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

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

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

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

WRITING THE RECIPE DOWN

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

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

IN SUMMARY

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

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

In the context of IAM, organisations have traditionally focused on managing identities and controlling who accesses what (and how).

In terms of identity management, organisations first focused on automation of provisioning tasks and other low value tasks. The focus then gradually turned to access rights request and approval processes. More recently, organisations have turned their attention to accounts and access rights review and recertification.

In terms of access control, organisations have migrated from centralised authentication (e.g. in a shared directory) to delegated authentication (e.g. to a Web Single Sign-On (SSO) solution). We are now at a stage where authentication is standardised with identity federation protocols (e.g. SAML) equally applicable to SaaS applications as internally hosted applications.

In recent years, information systems have opened up to the Internet while at the same time their authentication has become more standardised: organisations must now contend with SaaS, IaaS, external Information Systems (IS) access by partners and clients, a mobile workforce and mobile applications. And IAM professionals have devised solutions for these new use cases without necessarily challenging the fundamental principles of the existing paradigm. In effect, the market has witnessed a gradual evolution. And whilst we are currently experiencing a relatively calm state of affairs, major change is brewing.

Figure 1: 2005-2015 – an opening of the Information System under control

The evolving ‘IS’ landscape influencing IAM

The IS landscape is undergoing a new wave of transformation;

Driven by Cloud adoption, we are heading towards further adoption of SaaS, majority use of IaaS relative to historic datacentres, real adoption of PaaS (in the form of containerised applications and server-less apps), and ever increasing remote access by employees. There is also a surge in the number of end-points accessing information systems (more customers whose interactions are digitalised, Internet of Things, OpenData, etc.).

And driven by new agile methodologies and DevOps, information systems no longer evolve in the same way. Development and deployment cycles have been considerably shortened and interactions between business lines and IT are less confrontational than they used to be. These new methods are increasingly the norm and it is difficult to resist them.

Although IAM’s primary goal has not changed much, namely controlling who accesses what in the IS, there will be many more variants of “who” and “what” in the future. Core IS will be merely one “bubble” among others (refer to diagram below) interacting with its wider environment and remotely controlling interactions between decentralised components.

Figure 2: A decentralised Information System

7 factors shaping the future of IAM

IAM must find its sweet spot in a new environment where the requirements of business lines drive technology innovation. The business lines might even impose technology solutions onto IAM teams.

In predominantly cloud-based architecture, IAM must demonstrate control over this dynamic and bring added-value to this new world.

There are seven key factors that will shape the future of IAM; three of which relate to the needs of the business lines and four of which are new IAM challenges.

Agility

Business lines now expect to offer new products and services in ever-shorter timeframes. This poses two parallel challenges for IS:

1. Maintaining quality of service for existing business line products, and
2. Adapting to meet the need of new business line products.

This is an opportunity for IS to move away from a monolithic IAM framework that is often complex to implement and very difficult to handle by embracing a lighter architecture to support the new business demands (e.g. micro-services).

Client Identity Management (Customer IAM or CIAM)

Digital transformation is driving the business lines to interact with their customers in many new ways and through ever more channels.

A flawless user experience and the simplification of the customer journey are required. Optimisation of customer acquisition and churn rates become key indicators for CIAM to address.

Internet of Things (IoT)

Whether an organisation is building connected objects or offering services on top of them, a number of questions will become unavoidable:

• How to ensure that the object I am communicating with is the one it purports to be? Is it important to be absolutely certain?
• How to scale the IS to manage the growing volume of deployed objects?
• How to ensure end-to-end security?
• What object lifecycle should we anticipate?

These are fascinating questions which force us back to the drawing board to consider different hypothesis beyond the usual IAM framework.

Identity as a Service (IDaaS)

As we predicted a few years ago, the criteria for exporting IAM to the cloud is no longer restricted to security considerations. Equally important questions are: do I really need to do it? how will I benefit?

Although the IDaaS market is still in its infancy, with current offerings only partially covering the IAM spectrum, all indicators suggest the IAM offering of the near future will plug the gaps in the form of on-premises provisioning, rights requests and approval, identities governance, and more. What remains to be seen is whether identity management and access control will be packaged together or offered by separate providers and which provider(s) will be the most reliable.

Application Programming Interface (APIs)

APIs already represent a vitally important communication medium for any company committed to the digital transformation journey: exchange with partners, mobile applications, client-side applications, OpenData, etc.

Despite perceived gaps compared to web-service standards from previous years (in particular in the eyes of WS-* suite nostalgics), it is necessary to embrace the REST/JSON wave, to dive into Oauth2 and to bring up the API first topic in all your projects.

Standards

The fight between standards is eternal. Any standard used today is destined to be challenged and replaced later by another. However, this does not prevent good standards from emerging which, if adopted, can enable a correct response to IAM issues.

On the topic of access control, several standards and protocols for authentication, as well as propagation of authentication, are mature and already adopted by a large share of the market.

FIDO (Fast ID Online), U2F (Universal 2^nd Factor) and OpenID Connect are amongst the most promising standards in terms of their adoption rate, the maturity of the underlying technologies and the players who have collectively created them.

Identity & Access Intelligence

This is probably the most exciting and fast moving IAM area. Machine learning algorithms, detection of weak signals, neural networks and other emerging technologies can lead to new use cases linked to user (or object) identity and behaviour. Examples include pre-emptive fraud detection and risk anticipation, even “closing the door” before someone attempts to enter. Whilst there is an element of science-fiction to some of the scenarios presented by vendors, this is nonetheless a vibrant and highly promising market.

Figure 3: 7 factors shaping the future of IAM

Conclusion

Identity and Access Management (IAM) is developing at a fast pace as a result of new technology developments, digital transformation and the evolving cyber threats. Large organisations need to review their IAM strategy to take into account the current and future requirements of a digitally enabled business. Instead of focusing on “point” solutions to address these challenges one at a time, organisations need to take a more considered and holistic view of developments. An effective strategy can transform your IAM platform into an asset that enables mobility and productivity whilst also helping to overcome security challenges and integrate future IAM demands.

Cet article 7 drivers transforming Identity & Access Management (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.

L’approche « mise sous contrôle de l’existant »

Cette approche vise à vérifier l’efficacité opérationnelle de l’IAM par rapport aux règles prédéfinies (format des identifiants, nomenclatures des comptes, droits réels…).

C’est une démarche de mise en qualité des données. Elle consiste à comparer les données réelles d’une part (comptes dans les applications…) et les référentiels qui régissent l’IAM (liste des demandes d’habilitations…).

Pour les organisations ne disposant pas de service IAM, cette approche permet de s’assurer de la bonne réalisation des opérations manuelles. Elle permet de détecter et de corriger les éventuels biais survenus au cours du temps : erreur de saisie dans le nom d’un utilisateur, erreur dans l’attribution d’un droit, non-suppression d’un compte en cas de départ…

Pour les organisations possédant des outils IAM, elle permet de s’assurer du bon fonctionnement de ce dernier. Elle sera notamment d’une aide précieuse lors des investigations en cas de dysfonctionnement ou de plainte d’un utilisateur. En effet, l’IAG conserve l’historique des identités et des droits. Elle permet donc d’identifier immédiatement si une identité a été modifiée, pour quelles raisons et quelles en sont les conséquences.

Enfin, cette approche de l’IAG permettra de s’assurer de la bonne prise en compte des  événements non-standard (rachat de société et fusion des bases d’identités…) traités dans l’IAM via batch technique et souvent dépourvus de contrôles.

L’approche par les risques

Cette approche vise à donner de la visibilité sur les droits sensibles et à s’assurer du respect des règles de maîtrise des risques liées aux habilitations.

C’est une approche qui peut être conduite que l’on dispose ou non d’une solution d’IAM conventionnelle.Elle consiste à consolider les droits réels des applications sensibles pour pouvoir les comparer aux règles de l’entreprise.

Plusieurs actions sont ensuite envisageables : suppression des droits suspects, demande de dérogation temporaire, re-certification des droits à risques. Ou encore, si la règle s’avère inapplicable, adaptation de celle-ci et des moyens de mitigation associés.

Un point remarquable est que l’IAG s’inscrit dans une démarche d’audit, a posteriori de la demande d’habilitation. Cela permet de grandement simplifier les processus d’approbation et de certification ainsi que les workflows de gestion des demandes ; les cas d’exception pourront alors être détectés et instruits dans une démarche d’audit et de révision de droits.

Enfin, selon son contexte, une organisation devra choisir où porter son effort. Sur le  stock, c’est à dire sur la mise en conformité des droits déjà attribués. Ou sur le flux, c’est à dire sur les nouvelles attributions de droits sensibles. En effet, l’IAG conservant les historiques des droits, elle pourra quotidiennement identifier les nouvelles attributions de droits et déclencher les processus ad hoc.

Une approche par le flux, si elle ne permet pas de traiter l’existant déjà attribué, s’avère beaucoup plus simple à conduire : les demandes sont récentes, les approbateurs présents… Il est donc aisé de comprendre le contexte et les raisons ayant conduit à la demande. Elle pourra également constituer un premier palier quick-win du projet IAG.

L’approche par la justification et la prise de conscience

Si cette approche vise également à améliorer la maîtrise des risques, elle adopte une démarche plus douce.

En effet, parfois, l’application stricte des règles de contrôle et de séparation des tâches s’avère délicate : parce qu’il est convenu d’une application « souple », ou simplement parce que de telles règles ne sont pas suffisamment formalisées.

Dans ce cas, il est possible d’agir par réaction  par rapport aux demandes d’habilitations formulées. Ainsi, l’IAG va mettre en lumière des incohérences potentielles et permettre de les instruire unitairement.

À titre d’illustration, quelques exemples d’incohérences potentielles : personne du service RH qui reçoit un droit sur une application de gestion des stocks, personne qui reçoit un droit possédé par moins de 1% des personnes de son entité, personne recevant un droit administrateur sur une application, personne qui change de fonction mais qui conserve ses habilitations précédentes…

Ainsi, cette approche permet de challenger les demandes d’habilitation soumises et t de s’assurer que le principe du « juste droit » (les habilitations dont j’ai besoin et pas plus) est bien respecté.

À mesure de la prise de conscience et de la maturité de l’organisation, elle pourra se transformer en une approche plus coercitive.

L’approche en amélioration douce

L’approche en amélioration douce fait le choix de l’amélioration continue pour offrir une meilleure efficacité opérationnelle. Pour cela, elle analyse et compare les pratiques IAM constatées au quotidien dans l’entreprise. Elle vise ainsi à améliorer l’IAM en améliorant ses processus et la modélisation des habilitations.

À titre d’illustration, quelques exemples d’analyse de pratiques constatées : deux profils d’accès toujours possédés simultanément et qui pourraient constituer un profil métier, profils possédés par moins de 0,1% des personnes et qui pourraient être supprimés ou masqués, profils métiers redondants en termes de profils d’accès, profils possédés par plus de 80% des personnes d’une équipe et qui pourraient être recommandés en cas d’embauche…

Cette approche peut paraître plus avancée, et donc requérir un niveau de maturité important. Dans la pratique, les solutions d’IAG sont suffisamment souples pour permettre des démarches empiriques, en échange constant avec les Métiers.
Et le premier objectif n’est pas de tout analyser et comparer. Mais bien de se concentrer sur les cas les plus courants, les plus visibles, les plus significatifs pour les utilisateurs au quotidien.

Cet article Identity and Acces Governance : tour d’horizon des approches projet 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.

Un apport des DLP complémentaire à la lutte contre l’intrusion et au contrôle d’accès

Une fuite d’information peut provenir de trois sources différentes. L’attaquant externe est souvent celui qui vient à l’esprit en premier. Cependant, l’expérience montre que ce sont les utilisateurs internes, autorisés ou non, qui font fuir le plus d’information.

Suivant la position de celui qui fait fuir l’information, trois grandes étapes peuvent être enchaînées : intrusion, accès à l’information, diffusion de l’information – dont la nécessité dépend des accès initiaux de l’acteur à l’origine de la fuite d’information. À chacune de ces étapes, des solutions de sécurité permettant de réduire le risque existent.

Il convient d’agir à toutes les étapes d’une fuite d’information en s’appuyant sur des mesures allant de la sécurité physique aux solutions de Digital Right Management (DRM), en passant par le chiffrement de flux, le cloisonnement, ou encore la gestion des accès et des habilitations…

Si de telles mesures sont déjà mises en œuvre, les outils de DLP permettent alors essentiellement de se prémunir contre des erreurs ou malveillances d’utilisateurs ayant un accès légitime à l’information. En ce sens, ils permettent d’apporter une protection au plus proche de la donnée.

Des solutions fonctionnellement matures

Les mécanismes de contrôle des DLP sont mis en œuvre à travers des règles ou politiques centralisées permettant d’analyser les traitements faits sur la donnée quelle que soit sa nature ou son support.

Grâce à des agents déployés sur le réseau et/ou sur les postes de travail, le DLP va pouvoir empêcher la copie d’un fichier sur un périphérique externe, l’envoi d’un document sensible par email, l’impression d’un document ou encore la publication d’une information confidentielle sur les réseaux sociaux.

Après analyse et filtrage des données par la solution DLP, différentes mesures de prévention peuvent être prises, avec un impact plus ou moins élevé pour l’utilisateur : alertes, demande de justification, blocage…

Enfin, il convient de noter que les acteurs du marché mettent de plus en plus l’accent sur le contexte d’utilisation de la donnée. Certains éditeurs proposent ainsi des fonctionnalités de gouvernance au sein de leur solution de DLP permettant par exemple de savoir exactement où se trouvent les données sensibles et qui y a accès.

Le marché des DLP est donc de plus en plus mature : la couverture fonctionnelle proposée est élevée et évolutive, la gestion de l’impact sur les collaborateurs de plus en plus souple. Néanmoins, les retours d’expérience restent limités par rapport à ce que l’on pourrait attendre.

La raison de ce paradoxe vient du fait que les métiers sont trop souvent insuffisamment impliqués dans les projets de DLP, alors même que ces projets n’ont que peu de chance d’aboutir sans eux, en particulier vu le volet RH nécessairement associé.

Adopter une approche par les résultats pour mobiliser les métiers

Il est illusoire de vouloir protéger toutes ses données dans tous les cas d’usage imaginables. Une approche purement technique visant un périmètre exhaustif n’a que peu de chance de convaincre, particulièrement dans la conjoncture économique actuelle.

Une approche par les résultats mêlant ciblage précis, démarche outillée, accompagnement et visibilité est donc à favoriser dès la sélection de la solution. Une fois les objectifs atteints sur un périmètre prioritaire, on peut envisager de l’élargir.

La première étape, primordiale, est donc la définition du périmètre prioritaire de données à protéger et des cas d’usage fonctionnels à traiter. Identifier les dix données les plus critiques, s’appuyer sur des situations fonctionnelles avérées, commencer par un nombre limités de supports pour réduire les aléas techniques sont autant de facteurs clés de succès.

La définition des processus de surveillance (politiques d’interaction avec les utilisateurs, processus en cas d’alerte…) ne doit également pas être négligée. Sur ce volet, et dès le début du projet, il est important de mobiliser les fonctions RH de l’entreprise pour valider le mode de mise en œuvre de la démarche DLP (alerte, blocage, journalisation…), construire les processus de gouvernance associés et au final envisager un passage devant les instances représentatives du personnel.

Lorsque le cadrage global du périmètre fonctionnel est effectivement achevé, la phase de sélection de la solution peut être entamée. Une démarche outillée impliquant la réalisation d’une maquette est indispensable pour s’assurer de l’adéquation de la solution aux cas d’usages fonctionnels identifiés et évaluer les résultats envisageables.

En cas de résultats satisfaisants, un déploiement progressif est à envisager avec un leitmotiv : la sensibilisation des utilisateurs.

Enfin, en mode récurrent, l’intégration à un SOC (Security Operation Center) peut permettre de bénéficier de la maturité de la gestion opérationnelle de la sécurité pour optimiser la surveillance d’une part et l’accompagnement et la visibilité fournis aux métiers d’autre part.

Cet article Le paradoxe des projets de Data Leak Prevention (DLP) : une problématique clé, des solutions matures… mais une mise en œuvre qui fait encore peur est apparu en premier sur RiskInsight.

La sécurité, une question négligée après la phase de contractualisation

Les limites posées par le SaaS sont aujourd’hui bien connues : difficultés d’adaptation du service aux besoins de l’entreprise, absence de possibilités d’audit, questions réglementaires, etc.

Pourtant, de plus en plus de services cloud sont adoptés, sans que la sécurité ne soit nécessairement un frein. Pour cela, une démarche classique d’analyse de risque est menée en évaluant les contraintes légales / réglementaires,  les mécanismes de protection des données, la gestion de la sécurité par le fournisseur, ou encore les conditions de réversibilité de la donnée.

Cette démarche est de plus en plus maîtrisée : de nombreux retours d’expérience et un outillage qui se professionnalise* amènent à faire des choix éclairés, en toute connaissance de cause des risques encourus, et donc parfois acceptés.

Malheureusement, la démarche sécurité s’arrête souvent là : à partir du moment où le sujet a été traité lors de la contractualisation, on considère qu’un bon niveau est assuré, puisque l’on a exigé du prestataire de s’en occuper !

Le maintien de la sécurité dans le temps est un enjeu régulièrement oublié, alors même qu’il est en partie du ressort de l’entreprise, et pas seulement à la charge du fournisseur.

Des sujets à inscrire dans la durée

Pour s’assurer que la solution cloud est déployée avec le bon niveau de sécurité, et maintenir celui-ci dans le temps, quatre grands thèmes sont à aborder en priorité. S’il s’agit de bonnes pratiques habituelles sur un SI d’entreprise, il faut aujourd’hui les adapter, voire les renforcer pour le SaaS.

•  La gouvernance : les services SaaS doivent être intégrés aux procédures de sécurité et des processus liés au service fourni. Il peut par ailleurs être utile de mener des actions de sensibilisation dans certaines situations.

• L’administration fonctionnelle du service est bien du ressort de l’entreprise : le fournisseur n’est pas en mesure de faire les choix fonctionnels à votre place (et ce n’est souvent pas ce qu’on lui demande) ! Pour l’aspect sécurité plus encore, c’est à l’entreprise de définir  et mettre en œuvre les fonctionnalités avancées disponibles, de restreindre les services au minimum requis par l’utilisateur, de former ses administrateurs… Ces aspects sont souvent les plus négligés, comme nous le constatons lors des audits que nous réalisons.
• Des contrôles réguliers peuvent et doivent aussi être mis en œuvre sur les parties auditables des services. Il s’agit en particulier de vérifier que les paramètres de sécurité sont inchangés, d’exploiter les logs sécurité, et de revoir les habilitations. S’il le permet, enfin, ne pas hésiter à auditer son fournisseur (visites de site, voire tests d’intrusion).
• Il reste enfin à traiter le sujet de l’IAM, enjeu transverse du Cloud, souvent peu ou mal maîtrisé de par sa complexité. Même si cette voie est souvent suivie, il faut pourtant éviter de recréer un compte dans le Cloud pour chaque utilisateur. Pour « synchroniser » les identités de l’entreprise dans le Cloud, il faut également éviter la multiplication des connecteurs  (et notamment ne pas en redévelopper un par fournisseur), sous peine de créer une situation ingérable. Deux approches sont aujourd’hui à prioriser : soit l’utilisation d’un outil de fédération d’identités interne (qui réalise la connexion avec la majorité des fournisseurs de SaaS), soit l’externalisation de l’IAM… dans le Cloud (!) en « Identity as a Service »

Le RSSI, garant de la cohérence des projets

Dans le cas du SaaS, le rôle des responsables sécurité de l’information est double.

D’une part, il s’agit d’accompagner les projets, en leur apportant des solutions transverses : un certain nombre de points peuvent être mutualisés en amont. C’est tout particulièrement le cas des sujets tels que l’IAM, qui doivent faire l’objet d’une approche unifiée et cohérente –  et surtout pas projet par projet.  C’est également le cas des questions légales qui doivent faire l’objet d’une réflexion globale amont.

D’autre part, la SSI demeure la garante du niveau de sécurité dans le temps : la Gestion Opérationnelle de la sécurité devra faire l’effort de partir à la conquête des nuages !

* On peut citer notamment le guide publié par l’ANSSI et la « Cloud Control Matrix » maintenue par la Cloud Security Alliance

Cet article SaaS et sécurité : entreprises, ne mettez pas vos responsabilités dans les nuages ! est apparu en premier sur RiskInsight.

Mettre en œuvre la carte CPS au travers d’un projet de gestion des identités et des accès

Le SI, tout en connaissant de profondes transformations, devient un enjeu majeur dans les hôpitaux : informatisation continue des services de soins, ouverture du SIH, dématérialisation des échanges et interopérabilité, renforcement des exigences réglementaires, etc. Ces évolutions facilitent le partage de l’information médicale mais rendent sa protection plus difficile.

La mise en œuvre d’un espace de confiance numérique pour le partage des données de santé devient alors une nécessité. Cette nécessité devient un prérequis dans le cadre du programme Hôpital Numérique et de la certification HAS (Haute Autorité de Santé).

La mise en place d’une gestion des identités et des accès, qui associe l’utilisation d’un dispositif d’authentification forte comme la Carte de Professionnel de Santé, permet de créer un espace de confiance numérique qui répond aux problématiques suivantes :

• Respecter les nouvelles règlementations ;
• Simplifier et sécuriser l’accès au SIH ;
• Accélérer les processus de gestion des droits ;
• Diminuer la charge d’administration et réduire les coûts de support.

Mener un projet de gestion des identités et des accès adapté au monde hospitalier

La gestion des identités et des accès associe des processus, des technologies et une stratégie de gestion des identités numériques et de spécification de leur usage pour accéder aux ressources informatiques de l’entreprise.

Mener un tel projet s’avère généralement plus complexe que la plupart des autres projets informatiques en raison du nombre et de la diversité des référentiels d’identités numériques, des solutions techniques mises en œuvre et des besoins des entités gouvernantes amenées à collaborer.

Notamment, les acteurs concernés par un tel projet dans le monde hospitalier sont nombreux : la Direction Générale, la Commission Médicale d’Établissement (CME), le Département d’Information Médicale (DIM), les directions gérant le personnel salarié et non salarié de l’établissement (Direction des Affaires Médicales, Direction des Ressources Humaines), le corps médical et soignant, la Direction des systèmes d’information (ou le service informatique), etc.

Par ailleurs, certains thèmes à aborder sont spécifiques aux établissements de santé :

• Comment instruire ce projet dans le cadre d’une mise en réseau de l’établissement au sein d’une ou plusieurs communautés hospitalières ?
• Faut-il limiter l’utilisation de la carte à l’accès aux postes de travail ou bien ai-je intérêt à étendre son usage comme pour l’accès aux locaux ?
• À qui dois-je la fournir ?
• Comment m’assurer que la carte CPS facilitera l’accès aux postes de travail ?
• Quelles applications dois-je prendre en compte dans mon projet ?

Un projet d’établissement nécessitant un engagement de moyens ainsi qu’une implication de tous les acteurs pour le rendre maîtrisable

Mettre en œuvre la carte CPS au travers d’un projet de gestion des identités et des accès se révèle être un projet stratégique d’établissement, porteur d’enjeux à la fois techniques, organisationnels et de conduite du changement, et à ce titre requiert une phase préalable de cadrage qui permettra :

• De définir le périmètre et évaluer la dimension du projet : état des lieux, besoins et les attentes, axes d’amélioration, périmètre fonctionnel cible, macro-évaluation charges, coûts, délais ;
• D’inscrire le projet dans une démarche globale : acteurs à mobiliser, instances de pilotage, possibilités de mutualisation.

Et vous, où en êtes-vous de la mise en œuvre de la carte de Professionnel de Santé au sein de votre établissement ?

Cet article La carte CPS : un projet d’établissement ou un projet informatique ? est apparu en premier sur RiskInsight.

Long, cher, compliqué : trois qualificatifs qui façonnent encore l’imaginaire autour de l’IAM. Si l’écart entre les ambitions des projets et les moyens alloués est certainement le premier facteur de cette désillusion, les difficultés historiques du marché à répondre aux nouvelles exigences exprimées par les métiers sont également à incriminer.          

Les dernières évolutions des acteurs leaders du marché, comme l’apparition de challengers innovants, bousculent ces idées reçues et créent une nouvelle dynamique.

Un marché historique tiré par des besoins IT mais peu adapté aux utilisateurs métiers

Gérer ses identités, prendre en compte les mouvements, donner des habilitations a minima, contrôler les droits d’accès aux ressources de l’entreprise… ces attentes ne sont pas une nouveauté.

Pour  y répondre, les outils historiques ont été conçus, sous l’influence des directions IT, pour optimiser les tâches récurrentes à faible valeur ajoutée. Ils se caractérisent donc par des capacités riches d’interfaçage avec les ressources existantes dans le SI, sans velléité particulière d’offrir des interfaces aux utilisateurs finaux, et souvent au prix d’un effort d’intégration important. Aussi, l’effet de volume de comptes traités est indispensable pour rechercher un équilibre économique.

Sous l’impulsion des métiers, ce paradigme a été fortement bousculé. En effet, les enjeux visés sont radicalement différents. En premier lieu, redonner aux managers – et aux responsables des données sensibles – la maîtrise de la gestion des habilitations. En deuxième lieu, respecter et donner des preuves du respect des cadres réglementaires. Enfin, s’inscrire dans une démarche valorisante de maîtrise des risques, c’est-à-dire se focaliser sur les identités et les accès sensibles et prendre en compte les exigences du contrôle interne ou de l’inspection générale.

Face aux attentes des métiers, le marché de l’IAM  s’adapte à marche forcée

Au-delà de l’effet marketing, l’apparition du terme IAG (Identity & Access Governance) symbolise à lui seul les faiblesses de la réponse du marché – et son obligation à évoluer.

Pour faire face à ce mouvement, les acteurs historiques ont bien naturellement étoffé leurs offres, au moyen de rachats ou de développements internes. Et si certains acteurs proposent aujourd’hui des solutions cohérentes, les résultats sont très contrastés voire parfois même peu convaincants. Comme s’ils avaient appliqué une surcouche sur une base non adaptée…

En parallèle, de nouveaux acteurs challengers se positionnent en misant principalement sur la simplicité et l’ergonomie : des moteurs de workflow souples, pouvant s’adapter aux différentes organisations d’un client ; des interfaces plus ergonomiques, inspirées par exemple du e-commerce (avec panier, moteur de recherche) ; des tableaux de bord adaptés à l’utilisateur connecté (suivi des demandes, des approbations…).
Ces solutions permettent généralement de travailler plus rapidement et plus étroitement avec les métiers. Elles peuvent nécessiter moins d’effort d’intégration mais demandent une réelle expertise fonctionnelle et technique des fonctionnalités et concepts mis en œuvre. Par ailleurs, leur portefeuille de connecteurs est souvent moins riche, mais est-ce une réelle limitation dans la pratique ?

Enfin, des acteurs de niche apportent des réponses justes et innovantes aux points de faiblesse des solutions historiques : « Gouvernance, Risque, Conformité » est leur crédo préféré. Pour ce faire, ils proposent des solutions peu intrusives sur le SI et à la mise en œuvre rapide.
Ils incarnent naturellement de réels leviers d’amélioration pour les organisations ayant déjà déployé une solution historique sans atteindre pleinement leurs ambitions initiales.
Mais ils offrent aussi de nouvelles approches projet en s’appuyant sur les droits effectifs sur le SI. En réalisant une photo consolidée du SI, ils permettent à moindre frais d’identifier les comptes présents (actifs, inactifs, orphelins…), les droits assignés, les risques liés aux droits incompatibles accumulés par certains utilisateurs…
Cette approche peut entraîner la prise de conscience nécessaire au déclenchement d’un projet IAM plus vaste.

Les enjeux de demain : embrasser pleinement les attentes des métiers tout en contribuant à la transformation de l’IT

Les métiers se sont appropriés les enjeux de l’IAM et imposent leurs exigences (interfaces simples, processus calqués sur les organisations, approche par les risques…).
Demain, il faudra embrasser pleinement leurs attentes en offrant des solutions simples, rapides d’évolution et ergonomiques. Mais aussi des solutions riches fonctionnellement : re-certification, profiling, aide à la détection de fraude, implémentation des règles de contrôles avancées…

Ces enjeux cruciaux ne doivent cependant pas masquer la contribution nécessaire de l’IAM à la transformation de l’IT : la consumérisation des identités, l’authentification basée sur les risques (risk-based authentication), la prise en compte du Cloud dans l’authentification sans couture ou encore l’émergence de l’IdM-as-a-service.

Un équilibre subtil à trouver, propice à l’émergence de nouveaux leaders ?

Cet article Le marché de l’IAM s’est-il enfin libéré de son carcan IT ? est apparu en premier sur RiskInsight.