Two years ago, we asked whether artificial intelligence (AI) could represent a revolution for IAM in our article “Artificial intelligence: a revolution in IAM? – RiskInsight”. We already emphasized the need for a nuanced approach, based on concrete use cases, test-and-learn logic, and a requirement for trust compatible with the specific challenges of identity and access.

Today, the assessment has become more precise: AI has not caused the disruption that some predicted, but it is beginning to find a real, more targeted, and above all more pragmatic role within IAM.

What we also observe is that AI leads to an expansion of the scope of IAM: IAM must now also address issues related to AI and AI agents. To delve deeper into this point, we invite you to explore our article “Securing AI Agents: Why IAM Becomes Central – RiskInsight”.

As a reminder, AI is progressively establishing itself as a lever for transforming information systems, and IAM is no exception to this trend. Faced with the multiplication of identities driven by transformations of different natures, whether it be infrastructure evolutions with the cloud, business vision changes with the rise of CIAM, or the arrival of new technologies like AI agents, organisations must deal with increasingly rich and difficult-to-maintain authorisation models.

In this context, AI promises to make IAM services more efficient and accessible, whether through intelligent recommendations, conversational assistants, better data utilisation, or processing volumes that are difficult to manage with traditional approaches.

However, these contributions call for caution. IAM directly concerns access security: at this stage, AI must remain an assistance tool, under human supervision, as responsibility cannot be delegated to it. In practice, it still primarily manifests as peripheral components (copilots, chatbots, agents) that enhance existing systems without disrupting critical functions. The challenge is therefore no longer so much about whether AI has a place in IAM, but rather about identifying where and how to apply it in a truly relevant way.

2.    What AI use cases truly make sense in IAM?

The contributions of AI in IAM are unevenly distributed:

• Identity Governance & Administration (IGA) concentrates the bulk of initiatives thanks to its data volumes and frequent decisions (reviews, validations, recommendations).
• Access Management (AM) is also heavily featured, with projects primarily aimed at accelerating and streamlining the user authentication process.
• Privileged Access Management (PAM) is seeing the emergence of more targeted uses, particularly around the detection and monitoring of privileged behaviours.
• The potential of AI in Customer Identity and Access Management (CIAM) remains relatively underexploited, even as it is becoming strategic. This is particularly evident in the emergence of AI agents capable of interacting or acting on behalf of users, especially through chatbots.
• AI currently offers limited value for Trust Services, where processes are already largely automatable without AI, and is positioned more as peripheral support.

To organise these initiatives without ending up with a long list, two main categories of use cases can be identified:

1. Those that aim to resolve current challenges in existing processes.
2. Those that make it possible to address new issues that traditional approaches cannot cover.

The value of AI first emerges from current IAM pain points…

This first family of use cases generally constitutes the most natural entry point, as it relies on existing IAM processes.

AI then plays an accelerating role, by reducing costs and operational burden, while improving the experience, quality of service, and speed of execution, without calling into question the control model.

…to become a lever for overcoming the limitations of traditional approaches

The second category of use cases falls into a different category: here, AI is no longer merely aimed at saving time but unlocks analytical capabilities that are beyond the reach of traditional approaches, by cross-referencing multiple data points (identity, organisation, permissions, usage, events) across large volumes of data. In particular, it enables the large-scale detection of atypical access, such as rare combinations of rights, authorisations inconsistent with a role, or accumulations linked to successive exceptions.

AI also enables the analysis of career trajectories, identifying how certain profiles evolve over the course of job changes, projects or emergencies, to target remedial actions. It also enables intelligent prioritisation of these remedial actions by combining application criticality, data sensitivity and usage signals, whilst in the field of PAM, emerging uses aim to identify behaviours involving unusual privileges to trigger enhanced controls.

Finally, this also paves the way for delegating lower value-added tasks, such as handling Level 1 tickets, for which automation was technically feasible but economically difficult to justify. Today, some AI-powered IAM solutions make this substitution realistic and accessible.

The multiplication of pain points and automation avenues should not lead to the indiscriminate deployment of AI. Some needs can be effectively addressed using simple rules or algorithms, and whenever access is involved, every potential error carries a security risk. It is therefore essential, once use cases have been identified, to select and prioritise them, rather than accumulating initiatives.

3.    Prioritise AI in IAM before it becomes a pile of initiatives

Once relevant use cases have been identified, it is necessary to determine which ones to focus efforts on, as not all justify the same level of investment. Prioritisation can thus be based on two key axes: added value and implementation complexity.

The challenge here lies in the ability to analyse these two aspects rigorously for each use case.

The first axis, relating to value, can thus be understood through several sub-criteria:

• Operational cost reduction: measuring how the use case helps avoid certain recurring costs.
• Efficiency gains and reallocation of efforts: the ability to free up time and redirect teams towards higher value-added tasks.
• Reducing cyber risk: the impact of the use case on reducing identified cybersecurity, IT, or control risk.
• Contribution to regulatory and strategic issues: to what extent does the use case meet a priority regulatory or strategic expectation (e.g., DORA, ECB, audits).
• Impact on the affected populations: assess who the use case serves and with what frequency of use, as modest but daily use by a large number of users can create more value than a more ambitious use case limited to a restricted scope. The main populations to consider are generally IAM administrators, IAM integrators, end-users, and approving managers.

The second axis, complexity can be assessed according to four complementary dimensions, consisting of:

• Technical complexity: the technological effort required to deploy the use case, whether in terms of integrations, architecture, AI models used, or dependencies on the existing information system.
• Organisational complexity: the level of coordination required between teams, scopes, and processes to effectively support the use case.
• Associated risks: cyber, regulatory, or operational risks that may be introduced or reinforced by the implementation of the use case.

As a reminder, this approach aims primarily to guide thinking and structure decision-making; it is only a proposal that must therefore be adapted to each context.

High-impact but quick-to-deploy use cases should be prioritised. Conversely, those requiring significant effort (unavailable data, complex integrations, high security requirements) for limited benefit should be discarded or deferred. To make the trade-off concrete, a “matrix” logic works well:

However, this approach also requires being clear on one point: AI depends heavily on data (quality, completeness, traceability, repositories) and the ability to exploit it securely. Without solid foundations, even a promising use case will remain at the demonstration stage. To generate value in real-world conditions, it must be able to rely on sufficiently robust IAM foundations: data quality, structured repositories, process stability, clarity of the authorisation model, etc. Thus, prioritisation must be confronted with the reality of available solutions and their maturity.

4.    A booming market, with usage still largely unequal

The IAM market is strongly energised by AI, with expanding roadmaps and the emergence of so-called “AI-native” products, designed from the outset to integrate assistance, analysis, and automation mechanisms. These approaches generally address either a targeted need or a differentiation strategy in a rapidly evolving market.

In parallel, traditional IAM solutions are progressively enhancing their offerings with AI functionalities and generally benefit from greater resources than AI-native players to support this transformation, primarily in cloud environments, which are more conducive to their deployment than on-premises architectures.

However, there remains a notable gap between promise and reality in production: most of the functionalities available today are still peripheral assistance (search, summarisation, copilots) rather than AI truly embedded in critical functions.

Adoption also remains gradual, particularly in large organisation, where the priority remains optimising existing systems, stabilising repositories, reducing technical debt, and ensuring compliance. AI-native approaches, still relatively new, must be integrated into a realistic roadmap and a clear operating model. AI should not be seen as a miracle product, but rather as a lever to be incorporated into a global IAM transformation.

5.    Conclusion – From the announcement effect to a controlled trajectory

AI applied to IAM seems to be reaching a turning point. The real challenge is not to accumulate use cases: it is to build a coherent, selective, and sustainable approach. Because it intervenes in access decisions, AI in IAM requires a higher level of caution than in other areas. The promise of automation must never mask the responsibility of humans and organisations. Any recommendation must be understandable, contestable, and justifiable, especially in an audit context. It is necessary to clearly define who validates and who arbitrates, ensure the acceptance of business teams without which AI will be bypassed, ensure regulatory compliance, and rigorously frame the data exposed to assistants to prevent any exfiltration of sensitive information.

To maintain this trajectory, it is not enough to evaluate use cases in isolation: the foundations must be evolved (quality of identity data, repositories, role model, controls), an operational model capable of supervising AI on a daily basis must be defined, and emerging uses, particularly around AI agents, must be secured. AI for IAM should therefore not be thought of as an immediate revolution, but as a gradual progression, from assistance modules to advanced analysis capabilities, ultimately leading to better-controlled automation.

Ultimately, approaching AI in IAM well means moving forward pragmatically, targeting uses that offer the best balance between value and complexity, maintaining control over sensitive decisions, and staying attentive to the real market maturity.

6.    Five priorities to move from AI ambition to IAM results

In summary, here are the key points to bear in mind to adapt to this transformation:

1. Identify AI use cases that truly make sense for IAM, whether they involve improving existing processes or unlocking new capabilities for analysis and automation.
2. Objectively define the value and complexity of each use case to prioritise them for implementation.
3. Build a progressive, controlled, and governed trajectory, rather than accumulating initiatives without an overall vision.
4. The market is structuring itself rapidly: talk to your vendors to understand what they are really offering.
5. Also inquire about emerging new solutions, particularly AI-native ones, and do not hesitate to contact us if you wish to discuss your initial field feedback or broaden your market vision.

Cet article AI for IAM: A pragmatic trajectory rather than a revolution est apparu en premier sur RiskInsight.

Artificial intelligence has now become a structuring lever for companies: 70%¹ have already placed it at the heart of their strategy. So far, most deployments relied on conversational assistants capable of returning information—sometimes enriched with internal data—but whose interactions with the information system (IS) remained limited.

A major shift is now underway with the emergence of agentic AI. Unlike simple chatbots, AI agents do not merely answer questions; they reason, decide to call tools, and trigger actions. They may send an email, schedule a meeting, update a record, initiate a transaction, or soon, carry out even more sensitive operations. Their promise in terms of automation is substantial—and so is their potential impact on the attack surface of the IS.

Because once an AI system acts, central questions arise: on whose behalf is it acting, with which permissions, on what perimeter, and under whose control?

Those questions are even more critical given the rapid evolution of use cases: 51%² of organizations have already deployed an AI agent for employees, while 59%³ of workers acknowledge using non‑approved AI agents. Beyond individual usage, each business unit may be tempted to deploy its own agents to fulfill local needs. This fuels a form of agentic Shadow IT, where agents multiply in a fragmented way, with heterogeneous architectures, variable controls, and frequently incomplete governance.

In this context, Identity and Access Management (IAM) must return to the center of the security strategy. Every piece of data an agent can access, every resource it can modify, every action it can execute must fall under a centralized access control with, traceability, and a governance framework.

This article analyzes the security of AI agents through the IAM lens—not as one brick among others, but as a structural safeguard required to frame their usage and sustainably protect the information system.

From conversational assistants to AI agents: how they interact with the IS

How can an AI agent act on an application?

The ability of an AI agent to interact with enterprise applications relies on the emergence of new protocols, among which the Model Context Protocol (MCP) is gaining prominence. This type of protocol enables an AI agent to communicate with third‑party applications through an intermediate layer, often implemented as an MCP server.

The MCP server acts as an exposure and orchestration component. It receives requests generated by the model, translates them into executable calls, and forwards them to the application’s API. To achieve this, the MCP server provides the model with tools, describing the actions it is authorized to invoke. Once the server is declared in the conversational interface or agent environment, the model can decide—based on user intent and its own reasoning—to call one or several of these tools.

From a security perspective, this raises a key question: how is the end‑user authenticated, and how is this identity propagated—or not—to downstream services? In modern architectures, user authentication typically relies on OpenID Connect (OIDC), while API access authorization relies on OAuth 2.x through access tokens. The challenge for an agent is to ensure that tool invocations and API calls occur through a controlled delegation model.

Is the agent acting with its own rights, with the user’s rights, or through a hybrid mechanism?

Let’s illustrate this with a real-world use case: scheduling a meeting. The user asks: “Schedule a meeting with the team tomorrow at 10 a.m.” The AI agent interprets the request and uses the “Calendar” tool exposed by the MCP server. It sends the minimal structured request (participants, date, time, subject). The MCP server then calls the enterprise calendar API to create the event.

The mechanism seems simple. In practice, it represents a major shift: the model is no longer a passive assistant but an active intermediary between human intention and technical execution.

An inherently opaque operating model

This architecture introduces an immediate security difficulty: in many cases, the integration layer only has partial visibility over the originating context. It receives a structured request but not the full initial prompt, the model’s internal reasoning, or why it selected a specific tool. The IS therefore sees an action without necessarily being able to reconstruct the chain linking user demand, agent reasoning, tool invocation, and final effect.

This loss of context becomes even more problematic when the API call is made using an OAuth token: depending on the architecture, the target service may only see a technical identity (service account / application) rather than the real end‑user. This undermines attribution, abuse detection, and the ability to apply conditional policies differentiating human and agentic actions.

In other words, the agent interacts with the IS in a partially opaque manner, breaking with traditional application patterns and complicating real‑time control, auditing, and accountability.

A fast‑emerging technology introducing new security challenges

AI agents introduce new use cases—and new risks—that must be addressed at the IAM level. Four challenges stand out.

Challenge 1: Inventory of AI agents

Most organizations lack a comprehensive inventory of deployed agents and the tools they connect to.

This lack of visibility arises from two factors:

• usage often develops outside traditional governance processes;
• integration modalities are heterogeneous (MCP, proprietary connectors, local code execution, platform‑native features, etc.).

The issue is not only inventorying the agents themselves but understanding their entire execution chain: interface, exposed tools, target applications, accounts used, data processed, and flows generated. Without visibility, no meaningful governance is possible.

Challenge 2: Attribute and govern AI agent permissions

Traditional IAM systems often lack a native, standardized object to represent an AI agent as a fully governable non‑human identity.

As a result, integration layers are registered as technical apps or service accounts. This leads to well‑known risks: excessive privileges, poor separation of duties, coarse controls, and inability to distinguish a human action from an agentic action.

The risk becomes substantial as the agent may become a privileged indirect access vector into the IS.

Challenge 3: Authenticate AI agents

Authentication presents the third challenge, on two distinct levels. First, the end user must be properly authenticated to ensure that the agent is not operating without an identity. But the agent itself—or at the very least the component acting on its behalf—must also be authenticated so that specific policies, appropriate restrictions, and proportionate oversight requirements can be applied to it.

This dual requirement is unprecedented in its complexity: with AI agents, the system must simultaneously manage the identity of the requester, the identity of the executing system, and the precise relationship between the two.

Challenge 4: Trace agent‑driven actions

The final challenge is that of traceability. In many current architectures, logs primarily allow us to observe the technical call sent to the target service. However, it remains difficult to reliably reconstruct:

• which user originated the request;
• which agent decided to execute it;
• the business context;
• the intermediate reasoning steps.

This lack of auditability undermines detection, investigation, and accountability. When a sensitive action is triggered, it must be possible to determine whether it resulted from a legitimate instruction, a misinterpretation, an autonomous deviation, an abuse of privilege, or a compromise of the input context—for example, through a prompt injection attack.

IAM as the reference framework for securing AI agents

Core IAM principles remain unchanged

In light of this transformation, one point must be made clear: the fundamentals of IAM do not disappear with agent-based AI. On the contrary, they become essential once again.

A well-managed information system is based on a few simple and robust principles:

• centralize authentication via a reference IdP;
• avoid generic accounts when nominative identities are possible;
• enforce least privilege;
• govern entitlements over time;
• ensure robust logs;
• clearly separate roles and execution perimeters.

AI agents do not invalidate these principles—they expose existing weaknesses and require adapting the IAM execution model to a new class of digital actors.

A four‑step security trajectory

1. Inventory use cases and agents

Identify:

• deployed agents,
• environments,
• tools,
• target apps,
• accounts and tokens,
• accessible data.

This inventory exercise is not merely a secondary documentation task; it is a prerequisite for any coherent access control policy. To carry it out, commercial tools are emerging, such as Microsoft’s Agent 365 solution.

2. Introduce a dedicated identity type for AI agents

The second step involves recognizing AI agents as a specific category of non-human entities. This classification is essential because it enables the implementation of differentiated policies: prohibitions on certain actions, restrictions to specific areas, requirements for prior approval, enhanced monitoring, or conditional restrictions.

This distinction is fundamental. A traditional application does not have the same level of autonomy, nor the same risk profile, as an AI agent capable of selecting a tool on its own, chaining together multiple actions, or reacting to an ambiguous context. IAM must therefore be able to determine not only who is acting, but also how the system is acting.

For example, a user may have the right to send an email or create a change request. This does not mean that an agent can execute this action without safeguards. Depending on the sensitivity of the process, a dedicated policy may require human validation, a restricted scope, or a complete prohibition.

3. Link authentication and rights to a central IdP + the end‑user

The third step involves bringing authentication under the purview of a central identity provider, so that access rights are managed consistently. The goal is twofold: to prevent the uncontrolled use of over-privileged technical accounts, and to ensure that the agent operates, as much as possible, within the limits of the permissions held by the user who initiated the request.

This does not mean that the agent must be transparent from a security standpoint. On the contrary, the challenge is to apply a logic such as: “even if the user has the right, the agent does not necessarily have the right to do so alone, in any context, and without additional oversight.

4. Introduce human approval for certain agent‑initiated actions

Securing AI agents cannot rely solely on authentication and authorization. It also requires defining the acceptable level of autonomy based on the criticality of the actions in question.

Three models are typically distinguished

Human‑in‑the‑loop

This is the most secure mode. The agent prepares the action, but its execution is contingent upon explicit validation. This approach should be prioritized for sensitive operations: financial transactions, changes to permissions, external communications on behalf of the company, access to sensitive data, actions with irreversible consequences, etc.

Its key advantage is that final validation is handled by a control interface independent of the agent’s reasoning. Even if the model has been influenced, manipulated, or simply deceived, the user or operator retains control over the decision.

Human‑over‑the‑loop

In this model, humans do not approve each action individually but oversee the execution and retain the ability to interrupt the process immediately. This approach may be suitable for frequent, well-defined, low-risk processes, provided that monitoring is effective, and the shutdown mechanism is fully operational.

Human‑out‑of‑the‑loop

Here, the agent operates autonomously without immediate human intervention. This level of autonomy should only be considered for very low-criticality use cases, in strictly bounded environments with limited scopes of action, robust compensatory control mechanisms, and explicit tolerance for residual risk.

For a CISO, the logic is simple: the greater the business, regulatory, or security impact, the closer the human oversight must be to the execution.

A clear target state—still constrained by several limitations

Functional obstacles

The target security model can be clearly defined. Its implementation, however, encounters several major functional obstacles.

The first obstacle concerns the lack of granular authorization mechanisms. Today, a user may want to ask an agent to perform a precise action on a precise resource. Yet available mechanisms often require permissions that are far broader than necessary. Processing an email may require opening access to an entire mailbox; scheduling a meeting may imply extended access to the user’s full calendar; interacting with a repository may require read or write permissions far beyond the expressed need. This mismatch is particularly problematic in an agentic context. Because an AI is inherently non‑deterministic in the way it selects and chains actions, overly broad access rights mechanically become a disproportionate risk. Secure adoption therefore requires moving toward finer‑grained, contextualized, temporary authorization mechanisms, proportionate to the specific request being made.

The second obstacle concerns authentication and identity propagation. In many cases, current architectures still rely on technical accounts, shared secrets, or authentication mechanisms that fall short of mature IAM governance standards. The target state, in contrast, requires that each action be explicitly linked to (i) the user originating the request, and (ii) the fact that this action was executed by an agent — which implies distinguishing between the identity of the initiator and the identity of the executing system, while documenting the delegation relationship between the two. In practice, this refers to controlled delegation mechanisms such as OAuth “On-Behalf-Of (OBO)” flows: the agent (or its orchestration layer) calls an API while carrying an authorization derived from the user, but with additional constraints (limited scope, reduced duration, contextual checks, conditional access policies). The objective is to reduce reliance on over‑privileged technical accounts while preserving a usable chain of accountability. At this stage, however, the market does not yet offer a fully homogeneous and interoperable model that covers authentication, fine‑grained authorization, traceability, and agent governance at scale.

A final foundational obstacle is traceability: every action must be linked explicitly to a clear and intelligible chain of responsibility. Without this capability, there can be no robust auditability, no effective control, and no defendable governance in front of business stakeholders, auditors, or regulators. And this obviously comes at a cost for SIEM platforms…

A fragmented market complicating security

From the perspective of enterprises, the difficulty is not only technical: it also relates to the overall maturity of the market. Agentic capabilities are proliferating faster than the security and governance standards needed to frame them in a consistent way. As a result, organizations must deal with heterogeneous solutions, in which identity models, audit capabilities, and control mechanisms vary significantly from one vendor to another.

Will MCP become the standard?

Some vendors expose their applications through MCP servers or comparable mechanisms, while others favor more closed, native integrations within their own ecosystems. In practice, there is still no fully homogeneous framework that satisfactorily covers authentication, authorization, traceability, governance, and the nomenclature of exposed capabilities.

Two trajectories can be envisioned:

• The first would be convergence toward a standardized foundation enabling interoperability across agents, tools, and platforms. Such evolution would facilitate large‑scale deployment, improve user experience, and enable more coherent enterprise‑wide governance.
• The second would be persistent fragmentation. In this scenario, each vendor would continue to favor its own mechanisms, security objects, and integration models. The consequences for organizations would be significant: multiplication of blind spots, heterogeneous controls, difficulty centralizing supervision, and practical impossibility of applying a homogeneous IAM policy across the entire agentic perimeter.

In the short term, market signals point toward co‑existence: interoperability initiatives are emerging, but major vendors continue to build logically integrated ecosystems. For CISOs, this means thinking not only “tool by tool” but also in terms of the ability to govern a portfolio of agents spanning multiple vendors.

Toward enterprise AI agent registries

The rise of AI agents justifies the emergence of a new governance object: the AI agent registry. Because an agent is an autonomous system capable of triggering actions, it can no longer be treated as an invisible application component. It must be identified, qualified, assigned an owner, embedded in a lifecycle, evaluated according to its scope of action, and subjected to specific rules.

Such a registry must ultimately be able to answer several fundamental questions:

• Which agents exist within the organization?
• Who is responsible for them?
• In which environment do they operate?
• Which tools and which data do they have access to?
• Which authentication mechanisms do they use?
• Which human validations are required?
• Which logs do they produce?
• When must they be reviewed, requalified, suspended, or retired?

Some identity providers are beginning to introduce capabilities dedicated to this new category of non‑human identities. This is an important signal. But market maturity remains early, and governance cannot be outsourced entirely to vendors. The real issue is fundamentally organizational: defining a model of responsibility, control, and security that is adapted to the growing autonomy of AI systems.

When should organizations address IAM for AI agents? Right now.

The rise of AI agents marks a major evolution in the transformation of information systems. By shifting from a logic of assistance to a logic of action, these systems fundamentally reshape security concerns: the challenge is no longer limited to controlling the data an AI can access, but also the actions it can execute, the privileges it leverages, and the responsibilities it triggers.

In this context, IAM becomes a structuring pillar. It provides the foundation needed to make agents visible, control their entitlements, trace their actions, and define the conditions under which their autonomy can be accepted. In other words, securing AI agents cannot rely on peripheral measures: it requires an integrated governance approach that combines identity, access control, supervision, and human validation.

For organizations, the objective is not to slow down the adoption of agentic AI, but to frame it within a sustainable trust model. This means making structural decisions today: mapping use cases, integrating agents into IAM frameworks, distinguishing human and non‑human identities, adapting authorization policies, and defining safeguards proportionate to the criticality of the actions delegated.

As architectures become standardized and market offerings mature, the organizations best prepared will be those that treat AI agents not as simple innovative assistants, but as new actors of the information system, subject to the same requirements of security, traceability, and governance as any other critical component.

The question is therefore no longer whether AI agents will find their place in the enterprise, but under what conditions of control. For CISOs, the matter is clear: the ability to industrialize agentic AI will depend less on the performance of the models than on the robustness of the IAM and governance framework put in place to supervise them.

If you, too, are questioning how to manage access for AI agents or wish to deepen the security of these emerging use cases, we would be delighted to connect. Feel free to reach out to share your challenges or to explore together potential approaches tailored to your context.

1. Wavestone – Global AI Survey 2025  – AI Adoption and Its Paradoxes: Global AI survey 2025 | Wavestone)
2. PagerDuty (2025) More than Half of Companies (51%) Already Deployed AI Agents. Pager Duty, March 2025. Available at: 2025 Agentic AI ROI Survey Results (Accessed: 2 January 2026)
3. Cybernews (2025) Unapproved AI Tools in the Workplace. September 2025. Available at: https://cybernews.com/ai-news/ai-shadow-use-workplace-survey/ (Accessed: 2 January 2026).

Cet article Securing AI Agents: Why IAM Becomes Central est apparu en premier sur RiskInsight.

In 2026, Active Directory remains at the heart of the now hybrid identity infrastructure of most large companies and is still widely used as an on-premises identity provider, even when organisations migrate to the cloud. 

Wavestone incident response teams note that 38% of attacks begin with identity compromise (vs. 20% in 2024). More broadly, attackers frequently exploit on-premises identities to move laterally into cloud environments (Microsoft Digital Defence Report 2025 [1]). 

In a context where the hybridisation of identities increases an already vast attack surface, companies must be able to understand the challenges and equip themselves effectively. 

Through this new 2026 overview of Active Directory security tools, we offer you: 

1. An updated map of Active Directory security tools 
2. An overview of major market trends (consolidation, transition to platforms, cloud hybridisation) 
3. Feedback on operational implementation challenges and key success factors 

An overview of AD 2026 security tools, which has been further enhanced  

By analysing the market, we have identified four main use cases for these tools: 

1. Analysis and audit 
2. Hardening and maintaining security  
3. Detection 
4. Response and reconstruction 

A listing of publishers and tools offering features that meet one or more of these four use cases was conducted. It was designed to be as comprehensive as possible, including tools from the best-known and most widely used players on the market as well as those from lesser-known players, proprietary tools and open-source tools, tools with a wide range of features and tools offering a more limited set of features. All relevant tools were thus included in a list, with various information for each one (reputation, description of the tool and use cases covered, hosting, etc.). 

The following overview selected a number of publishers from this list, for the functional coverage they offer and their large use within organisations. 

The Microsoft Entra ID logo is added to tools that offer the possibility of integrating it into their operations in addition to on-premises AD coverage. This is a strong trend in the market. 

1. A dynamic market undergoing consolidation 

The Active Directory market has undergone several changes since 2022, with different major transactions. The aim is most often for publishers to complement their offering or to cover a new need for Active Directory security. 

Among other things, we can note : 

Acquisition of PingCastle by Netwrix [2] : PingCastle, renowned for its expertise in AD security auditing, strengthens Netwrix’s offering. This acquisition enables Netwrix to expand its portfolio with a lightweight, quick-to-deploy tool that is popular with technical teams, while reaffirming its commitment to providing a unified platform covering the entire AD security lifecycle. 

Acquisition of Attivo by SentinelOne [3] : Attivo, a specialist in identity security and lateral movement detection, strengthens SentinelOne’s offering by integrating advanced AD protection capabilities into a unified platform combining EDR, XDR and identity security. 

Acquisition of BrainWave by Radiant Logic [4] : Radiant Logic strengthens identity and governance analysis capabilities. By combining BrainWave’s detailed rights mapping with Radiant Logic’s identity federation, the offering becomes more comprehensive in addressing AD challenges. 

Integration of Stealthbits by Netwrix [5] : By merging with Stealthbits, Netwrix has integrated historical Active Directory auditing and detection components (StealthAUDIT, StealthDEFEND, etc.), strengthening its offering in the protection of identities and sensitive data and moving towards a unified platform focused on AD security. 

2. From specific tools to centralised platforms 

In 2022, our overview of Active Directory security tools mentioned “specialised tools, each addressing part of the equation.” [6]. In 2026, we are seeing the emergence of centralised platforms capable of covering several needs around Active Directory and, often, Entra ID. This dynamic is primarily driven by publishers seeking to broaden their value proposition and differentiate themselves with comprehensive platforms rather than specialised tools offering specific features. 

Some publishers build their platforms through successive acquisitions, such as Netwrix (AD auditing, data protection, vulnerability discovery, PingCastle, etc.) or SentinelOne (EDR/XDR enhanced by Attivo on identity), while others are gradually enhancing their existing offerings to provide modular suites, whether they are administration/monitoring tools such as ManageEngine ADAudit Plus or Quest Change Auditor, which add AD auditing, hardening and detection components across the entire Active Directory ecosystem. 

The promises made by publishers are clear: 

• Centralisation of data (accounts, groups, rights, security events) 
• Unified view of attack paths between AD and Entra ID 
• Simplified management for security, infrastructure and IAM teams via consolidated consoles and dashboards 

From the customer’s point of view, the benefits are obvious, but the reality may be more nuanced: 

• Consolidation can reduce the number of tools and simplify integrations, but it does not eliminate the need for AD expertise or specialised tools (e.g. for post-incident reconstruction). 
• Environments often remain multi-vendor, with a mix of global platforms (XDR, CNAPP, Identity Security) and targeted AD tools, particularly in large groups or organisations that are already heavily equipped. 

In this context, the challenge is not simply to “choose a platform”, but rather to put together a coherent whole, ensuring that: 

• The AD/Entra ID scope is well covered throughout the entire lifecycle (prevention, detection, response, reconstruction). 
• The tools can feed existing processes (SOC, crisis management, PRA, IAM). 
• Dependence on a single publisher is assessed and controlled. 

3. Cloud hybridisation 

With the rise of Entra ID and SaaS applications, identity hybridisation has become the norm: AD accounts and groups are synchronised to the cloud, and the same credentials are used to access on-premises and cloud resources. Numerous recent incidents show that attackers are exploiting these hybrid architectures to pivot between AD and Entra ID, taking advantage of poor configurations or weak alignment between the two worlds. [7] 

This translates into several concrete needs: 

• Joint supervision of AD and Entra ID: ability to correlate signals from the on-premises directory (changes, anomalies, lateral movement attempts) and the cloud (Entra ID Protection signals, connection anomalies, conditional access, etc.).  
• Security policy alignment: hardening of AD (configuration, delegation, privileged accounts) in line with conditional access policies, MFA and Zero Trust requirements.  
• Hybrid reconstruction capabilities: in the event of AD compromise, reconstruction and restoration must integrate Entra ID dependencies (synchronisation, service accounts, applications) to avoid side effects on the cloud, and vice versa. 

Publisher are gradually positioning themselves on this hybridisation. Some are expanding their AD audit engines to include Entra ID (on-premises to cloud) and offer a unified view of identity vulnerabilities: Netwrix Auditor now allows Entra ID to be monitored in parallel with Active Directory with a single view of hybrid threats. Tenable Identity Exposure extends its exposure indicators to specific Entra ID risks, and Semperis Directory Services Protector correlates AD and Entra ID changes in a single console to reduce the hybrid attack surface. 

Other tools start in the cloud (Entra ID, SaaS) and move down to on-premises AD (cloud to on-premises), using a hybrid identity threat detection and response approach: Microsoft Defender for Identity provides a consolidated inventory of AD and Entra ID identities and new detection capabilities on hybrid components (Entra Connect, AD FS, etc.), while CrowdStrike Falcon Identity Threat Protection analyses hybrid accounts present in both AD and Entra ID/Azure AD. 

Operational implementation still has room for improvement 

The Active Directory security market is seeing growing and structured adoption of sophisticated tools. In many organisations, functional coverage is now adequate, or even advanced, across the various aspects of AD security (auditing, hardening, detection, backup). 

However, technological maturity contrasts with operational implementation that is still incomplete. AD disaster recovery plans (DRPs) often remain theoretical, untested, or disconnected from the backup and reconstruction tools deployed. Regular reviews (of privileges, delegations, approval relationships) are still rarely industrialised: they often depend on a few experts, with a limited level of automation. 

The effectiveness of implementation is also impacted by the constant evolution of the ecosystem, between the platformisation of tools and the hybridisation of identities. The challenge for the coming years will therefore be to align tools (both existing and future) with robust, documented and tested processes: 

1. Clarify responsibilities between infrastructure, IAM, security and SOC teams, 
2. Formalise and automate recurring controls (rights reviews, configuration validation, restoration tests). 

Only then will investments in Active Directory security tools, both on-premises and in the cloud, enable true resilience to be achieved. 

Methodology overview 

We have identified four main categories for grouping tools: 

Analysis and audit: 

• Account and Privilege: Inventory of accounts, groups and associated rights to detect excessive or non-compliant privileges. 
• AD Discovery: Exploration of the AD structure (OUs, GPOs, objects) to deduce the architecture, relationships and dependencies. 
• Vulnerability Discovery: Identification of security vulnerabilities (configuration, obsolete accounts, weak passwords, etc.). 
• Attack Path Discovery: Modelling potential attack paths to privileged accounts. 

Hardening and management: 

• Password Management: Management of password policies, synchronisation, password auditing (strength, reuse, compromise, etc.). 
• Rights & Privilege Management: Delegation, access control, role and permission management. 
• GPOs Management: Creation, analysis, modification of group policy objects. 
• Change Management: Change tracking, traceability, change management and migration tools. 

Monitoring: 

• Threat Detection: Proactive detection of suspicious behaviour, privilege escalation, lateral movement. 
• Security Incident Detection: Identification of security incidents, real-time alerts, event correlation. 
• Backup and Recovery: 
• AD Backup & Recovery: Partial or complete backup of AD objects, rapid disaster recovery. 
• Investigation & Forensics: Post-incident analysis, traceability of malicious actions, evidence collection. 

For each of the tools classified, a badge (Microsoft Entra ID logo) is added when the tool offers the possibility of integrating Microsoft Entra ID into its operation. 

Conclusion

The 2026 overview is based on an analysis of 180 tools, compared to 150 in 2022. It was constructed using a similar approach to that of 2002. It is based on a listing of tools on the market. On this basis, and in line with recurring themes in Active Directory security, a categorisation has been established to facilitate reading. 

The list of tools mentioned is not intended to be exhaustive, as the list of tools that can contribute directly or indirectly to Active Directory security is vast. This overview is therefore a summary of the main existing tools, particularly those that Wavestone consultants encounter most often in large organisations (considered, studied, tested or deployed). 

References

[1] Microsoft Digital Defense Report 2025 | Microsoft 

[2] Netwrix Acquires PingCastle | Netwrix 

[3] SentinelOne, Inc. – SentinelOne Completes Acquisition of Attivo Networks 

[4] Radiant Logic Signs Definitive Agreement to Acquire Brainwave GRC – Radiant Logic | Unify, Observe, and Act on ALL Identity Data 

[5] Netwrix annonce sa fusion avec Stealthbits | Netwrix 

[6] Radar des outils pour renforcer la sécurité d’Active Directory – RiskInsight 

[7] Microsoft Incident Response lessons on preventing cloud identity compromise | Microsoft Security Blog 

Cet article Overview of Active Directory security tools – version 2026  est apparu en premier sur RiskInsight.

Attacks targeting these supply chains have opened a new perimeter of risk in information systems. Breaches can lead to intellectual property theft, tampering with source code, service disruption, and privilege escalation into more critical parts of the IT landscape. 

What are the new attack vectors in CI/CD pipelines, and how can they be contained? This article reviews real-world compromise scenarios and provides recommendations to defend against them. 

What risks for CI/CD pipelines? 

The 2020 SolarWinds breach is very often cited as CI/CD compromise, as it revealed the true scale of that such an attack can cause. After supposedly stealing FTP credentials left in plaintext in an old GitHub repository, attackers poisoned SolarWinds’ supply chain by inserting a C2 beacon into Orion, its network management software, before the signing process. 

This backdoor gave adversaries months of undetected access to the internal networks of U.S. government agencies and private companies. 

Incidents like this, along with more recent ones such as Log4Shell, Codecov, and XZ Utils, highlight not only the need for stronger CI/CD security but also for a more adaptive incident response. OWASP published a dedicated overview for CI/CD Security in their Top 10, mapping out the most common areas of risk. 

Figure 1 – Top 10 OWASP CICD-Sec 

Field insights @ Wavestone

Audits and penetration tests help identify vulnerabilities proactively before attackers can exploit them. By simulating real-world attacks, these assessments provide concrete visibility into how systems can be compromised. 

Our recent client engagements have led to clear findings: 

• In nearly all Cloud and CI/CD audits, vulnerabilities are always discovered in pipelines, often enabling full control of the pipeline, its artifacts, or even underlying infrastructure. 
• In CERT and Red Team interventions, CI/CD pipelines frequently act as accelerators in attack paths. 

Here are two examples observed in the field. 

Example 1: Full AWS compromise through CI/CD abuse 

In this first grey-box example, we compromised an entire AWS Cloud environment (600+ accounts) starting from standard DevOps accounts. 

Figure 2: Full AWS compromise through CI/CD abuse 

Attack path: 

• An attacker pushed malicious code into a GitLab repository, triggering a GitLab CI pipeline that deployed the code into a generic Kubernetes pod. 
• The code opened a reverse shell, giving the attacker remote access to the Kubernetes environment. 
• From there, the attacker exploited excessive privileges granted to the node’s service account (ability to patch tokens in the cluster) and replaced the admin node’s token. 
• On redeployment, the malicious pod lands on the former admin node, still holding admin rights. 
• The attacker escalated privileges and pivoted into AWS, compromising the entire Elastic Kubernetes Service (EKS) cluster and its resources. 

Example 2: Chained attacks across pipeline components 

Figure 3 -Summary of real chained attacks across pipeline components 

In another case (presented at DefCon & BSides 2022), we demonstrated how multiple components of a CI/CD pipeline can be chained together in compromise scenarios. [Video]. 

Recommendations to secure a CI/CD 

CI/CD pipelines have now become systemic components of information systems and can be leveraged to compromise an organization’s most critical resources. 

Our recommendations for securing the CI/CD chain can be grouped into three main themes: identity and access management (IAM), better pipeline design, and continuous monitoring. These align with the ANSSI DevSecOps guidance. 

Figure 4 – Three main recommendations to secure a CI/CD 

Identity and Access Management (IAM) 

Figure 5 – IAM recommendations 

Identity management 

Beyond the traditional rules for managing identity lifecycles, it is strongly recommended to systematically use Single Sign-On (SSO) combined with Multi-Factor Authentication (MFA). This significantly reduces the risk of intrusion into the CI/CD chain, by ensuring that any user accessing code repositories, signing commits, or performing other privileged actions is properly authenticated. 

Access control 

User and service account permissions must be strictly limited to what is necessary for their role within the CI/CD chain, always applying the principle of least privilege. This should be enforced through Role-Based Access Control (RBAC). For example, a developer working on a specific project generally should not have write access to the overall pipeline configuration. 

It is also advisable to segment projects using separate code repositories, and to ensure that the orchestrator account of one project does not hold excessive rights over the deployments of projects it is not associated with. 

Secrets management 

In CI/CD, “secrets” refer to sensitive data such as passwords, API keys, certificates, or access tokens. Since these secrets often enable privileged actions within pipelines, they must be retrieved in an automated and controlled manner. 

Vendors such as HashiCorp provide dedicated secret management solutions that make it possible to store sensitive data centrally, while ensuring encryption in transit and at rest. 

CI/CD pipeline design 

Figure 6 – Design recommendations 

Environment segmentation 

Segregation between users, applications, and infrastructure is essential to minimize the impact of a compromise. In line with ANSSI’s guidance, actions performed by the production CI/CD chain should be treated as administrative actions, and the number of users authorized to access it should be kept to an absolute minimum. Furthermore, communication between environments must be protected with end-to-end encryption. 

Integration of third-party tools 

As the SolarWinds attack demonstrated, many supply-chain compromises originate from a third-party component integrated into a CI/CD pipeline. These tools are indispensable for supply-chain operation: they may be as small as a development add-on, or as central as a version control system or orchestrator. 

Because these tools are often granted high privileges—access to sensitive resources or the ability to perform critical actions within the pipeline—a vulnerability that is left unpatched can be catastrophic. In many cases, the ability to remediate will depend on the vendor, limiting the organization’s own control. A strict governance framework and a Third-Party Cyber Risk Management (TCPCRM) process for third-party tools is therefore necessary. 

Artifact management 

To avoid the risk of distributing malicious artifacts, it is recommended to sign artifacts as early as possible in the pipeline, and to verify those signatures at deployment time to guarantee their integrity. Similarly, regular Software Composition Analysis (SCA) should be performed to prevent the introduction of malicious libraries. 

Monitoring and supervision 

Figure 7 – Monitoring recommendations 

Logging and detection 

Maintaining a high level of visibility and control over all pipeline components is critical for easier maintenance and faster response to attacks. 

A tailored logging strategy should be implemented: logs must contain only the data needed to ensure traceability and accountability in the event of an incident, should be stored securely, and must not contain secrets in plaintext. Logs should be shared effectively with the organization’s Security Information and Event Management (SIEM) system. 

Regular audits and penetration tests are also required to reassess the security posture and identify potential new compromise paths within the CI/CD pipeline. 

Incident response 

Finally, CI/CD pipelines must be included in incident response plans just like any other perimeter of the information system. This means ensuring that source code and configurations are backed up, and that business continuity plans exist in case of a tool failure. 

In conclusion 

CI/CD pipelines have become a genuine cornerstone of modern information systems. They are now systemic components, indispensable for developing and deploying applications. Yet their critical role within IT also makes it necessary to implement appropriate security measures so that they do not themselves become attack vectors. 

Figure 8 – Some systemic CI/CD components 

Beyond the recommendations detailed in this article, further preventive measures can be implemented in the form of hardening guides tailored to specific tools within the pipeline. In addition, adopting a robust training strategy for users, together with structured change management, is essential to ensure the success of these transformations. 

Thanks to Jeanne GRENIER for her valuable contribution to the writing of this article.

Cet article CI/CD: the new cornerstone of the Information system?  est apparu en premier sur RiskInsight.

To this end, there are many existing rights models: MAC, DAC, GBAC, ABAC, etc.

How do you understand these many different rights models in practical terms and apply them to your business?

The models differ in their degree of complexity and in the response they provide to the specific needs and constraints of an organisation or system. The most recent models incorporate issues of security, scalability and compliance in an increasingly complex technological environment.

In this article, we will follow a chronological logic, identifying how authorisation has evolved over the decades to meet the challenges faced by organisations. We will see that, like information systems, rights model approaches have become increasingly complex and now include more and more parameters for deciding whether to grant or deny access.

Models can be grouped into 3 approaches reflecting their progressive sophistication:

– Classic approach: admin-time

– Modern approach: run-time

– Forward-looking approaches: event-time

We will illustrate each of these approaches with emblematic models, highlighting:

1) The response to an initial need

2) The limitations of the model

We conclude with a chronological summary of the approaches and their models.

Classic authorisation approaches: Admin-time

In the 60s and 70s the development of computer systems, marked by the development of the first multi-user systems (Multics, HP-3000), gave rise to the need to rethink user rights.

Innovative security principles, which are still used today, were defined for these systems such as rings of protection, which aim to protect the integrity of the operating system against deliberate and accidental modifications and initiate a rethink of user access policies to resources.

In the first access rights models to emerge, the management of rights remained summary, defined in hard terms by ‘administrators’: this was admin-time, of which the DAC and MAC (60s-70s) and RBAC (90s) models are particularly noteworthy.

Discretionary Access Control (DAC) and Access Control Lists (ACLs)

As its name suggests, the DAC model – for ‘discretionary access control’ – leaves it up to each resource owner to assign permissions to users. This is the basic rights model found on Unix systems, which can be supplemented by the ACL mechanism, or ‘access control lists’. Often associated with DAC, ACLs specify, for a given resource, the users and their rights over the resource, as illustrated below using the Unix example.

Beyond Unix, file-sharing systems such as OneDrive and social networks, where the user can choose who can view or comment on each publication, are other examples of the use of DACs and ACLs.

In fact, the flexibility and granularity of this model are an advantage for local implementations centred on individuals. On the other hand, they become problematic for ensuring a correct level of resource protection on a large scale in more complex systems.

Mandatory Access Control (MAC)

The MAC model, which stands for Mandatory Access Control, is the opposite of DAC. Rather than leaving the assignment of rights to the ‘discretion’ of individual users, resource by resource, limiting system-wide visibility and encouraging errors and vulnerabilities, rules are predefined by administrators according to different security classifications and strictly enforced by a central authority, generally represented by the operating system itself.

It is particularly prevalent in government, military and industrial environments, because it allows tight control over access to sensitive data. It uses labels that characterise the sensitivity of objects and users, according to the rules of the organisation concerned:

– A resource classification level, for example: ‘Unclassified’, ‘Restricted’, ‘Confidential’, etc.

– A level of user authorisation, linked to the existing resource classification levels.

Below we describe Multics and SELinux, two fundamental examples of MAC implementation.

MAC example 1: Multics and protection rings

Already mentioned above as a precursor of multi-user systems (also known as ‘time-sharing’ systems), the Multics project, released in 1969, was the source of many innovative features, particularly in its memory management and security. It prefigured MAC even before the formulation of models such as Bell-LaPadula (1973) and its first formal definition set out in the Department of Defense’s Orange Book (1983), which established US computer security standards.

It is based on the concept of rings of protection, which Multics created, as shown by its logo (image above), and which form the basis of MLS – Multi-Level Security – systems, widely used in highly confidential contexts. It consists of a set of concentric rings representing levels of sensitivity that increase the closer you get to the centre (ring 0) – and therefore the privileges required for access. Mechanisms known as guards or gatekeepers, located at the interface between two rings, closely control the legitimacy of access in both directions, which they grant or deny.

In reality, these rings are of two types:

– Kernel protection rings are physical rings built into processors and used by the operating system to guarantee its integrity against faults (which cause the machine to crash) or modifications, whether intentional or not.

– User space rings are logical rings implemented by the operating system. This is where MAC comes in. By means of labels, each user and each resource is attached to a ring level. From there, rules define the actions that can or cannot be taken, following the example of the Bell-LaPadula model, which emphasises data confidentiality: ‘No read up’ (a user cannot read access to layers higher than his own), ‘No write down’ (he cannot write to layers lower than his own, to avoid leaks).

The image below summarises the principle of protection rings.

 MAC example 2: SELinux, the Linux kernel security module

Initially developed by the NSA in 2001, SELinux was proposed and added to the Linux kernel security modules (LSM, Linux Security Modules) in 2003, and is natively integrated into RedHat distributions such as Fedora.

This is another well-known example of MAC implementation: it allows administrators to assign a security context label to each resource in order to classify them and define the security policies to be applied by the operating system. Even with privileged rights, an application will see its rights restricted to the domain it needs to function (for example, the folders specified), with SELinux detecting and preventing any non-compliant action.

SELinux therefore provides an additional layer of protection in the event that a user or process manages to bypass traditional access controls.

In practice, MAC policies are rarely sufficient on their own, but are superimposed on existing DAC rules, whose flexibility they compensate for.

Two models based above all on the identity of the user or process, on the basis of which they authorise or deny access: this is known as Identity-Based Access Control (IBAC). These models are still limited to local contexts and have little resistance to scaling up.

Role-based Access Control (RBAC)

Formulated in 1992 by David FERRAIOLO and Richard KUHN, two engineers from the American NIST, the RBAC model – role-based access model – was designed to simplify the management of permissions throughout an organisation while reflecting its structure as closely as possible (hierarchy, responsibilities, departments, etc.).

Instead of granting rights directly to an identity, as with IBAC, a method that can quickly become difficult to maintain, we design business roles and the associated privileges. Users then inherit the rights associated with their role within the company, enabling them to access the various applications and enterprise sharing systems considered necessary for their internal activities.

This initial conceptual framework was completed and standardised in 2004 with the ANSI INCITS 359-2004 standard, which takes into account practical business cases and scenarios. For example, it addresses the need to separate responsibilities (SoD, Segregation of Duty), which is fundamental in financial and banking institutions, as well as the principle of least privilege and the inheritance of permissions.

Progressive and increasingly centralised adoption of RBAC

From the 80s and 90s onwards, databases, which were widely adopted by large companies and likely to contain sensitive information to which access was naturally controlled, were pioneers in the implementation of the RBAC model. They illustrate its implementation at the level of isolated applications, with no repercussions for external applications or systems.

The 2000s saw the launch of Microsoft’s Active Directory, starting with Windows 2000 Server. This centralised directory is designed to manage all the organisation’s resources (people, physical resources, applications). Although it is not strictly speaking an RBAC tool, a comparison can be made. The allocation of access rights is based on security groups – which can be perceived as roles – with permission inheritance mechanisms and the concepts of domains, trees and forests designed to represent the logical structures of the company.

Modern IAM solutions, such as Okta, SailPoint IIQ and Microsoft AzureAD, now support RBAC for heterogeneous environments, including cloud services. They illustrate the gradual centralisation of access rights management, which was initially managed locally within applications, and is now increasingly delegated to IAM solutions covering the widest possible spectrum.

RBAC assigns rights based on a business role, whereas IBAC is linked to an identity. The layer of abstraction created between the subject’s identity and an individual’s role means that it can be extracted from restricted contexts (file systems for DAC, operating systems for MAC) and adapted (at last!) to the access control needs of organisations. However, they all share the characteristic of a rigid definition of rights, based on an identity or a role.

In entities where exchanges are increasingly dynamic and fluctuating, this abstraction through roles alone may prove insufficient. New models have emerged to represent more complex organisations, taking into account additional, evolving attributes to assess access rights to a higher accuracy at a given time: we are moving from admin-time to run-time.

New approaches to authorisation: Run-time

The increasing complexity of information systems, and therefore of access, has led to the run-time approach. This approach meets organisations’ needs for dynamic flexibility and security. Unlike the ‘admin-time’ era, characterised by static permissions, the ‘run-time’ era offers real-time management at the time of the access request, based on various contextual elements. This transition to more flexible and precise authorisation models enables organisations for adapting to change and better protect their resources against today’s threats.

Graph-Based Access Control (GBAC)

The GBAC (Graph-Based Access Control) or GraphBAC model is based on the use of graphs to represent the relationships between users, roles and resources within an organisation. These 3 types of entities (users, roles, resources) and the relationships between them form the core of this model: entities can be represented by the nodes of the graph, and the relationships between them by the edges.

Access authorisations to a resource are determined in real time by queries to this graph database, enabling access decisions to be made based on the connections between entities at the time of the request. Users can thus obtain access to a resource according to their role and their relationships with other users or resources in the organisation.

The GBAC model is suited to the dynamic environments of large organisations, where relationships between entities are constantly evolving. On the other hand, it can be complex to implement, and the projects involved are relatively long, with significant costs. In addition, the gradual addition of new relationships can make the graph increasingly difficult to manage, complicating internal audit or recertification activities, for example.

Attribute-Based Access Control (ABAC)

In the ABAC (Attribute-Based Access Control) access model, the management of access to a resource is based on the dynamic combination of attributes. These attributes relate to the user requesting access (role, group), the resource requested (type of resource) and the context in which the request is made (time of day, type of network). This approach makes it possible to authorise or deny access flexibly and in real time.

The model was formalised in 2014 in the publication by NIST (SP 800-162) which provides detailed information for its implementation.

4 components are essential to the operation of this model: Policy Enforcement Points (PEPs), Policy Decision Points (PDPs), Policy Administration Points (PAPs) and Policy Information Points (PIPs).

After interception by the PEP, the access request is transmitted to the PDP, which is responsible for making decisions by analysing the access policies managed by the PAP and often accessible from an access policy database. The PIP provides the PDP with additional information on the user or resource from different sources, enabling it to make decisions in line with access rules. For contextual information, the information system can be connected to other tools or sources (IDS, logs, sensors) that enable this information to be collected at the time of an access request.

ABAC is a particularly interesting model in environments where access needs are varied and evolving, as it enables fine, granular management of authorisations, particularly in the context of PAM (Privileged Access Management), concerning access and critical resources.

However, this level of detail and flexibility comes with challenges such as the ongoing review of attributes and the maintenance of policies, which require constant attention to ensure they meet the needs of the business. Over time, the increasing number of attributes and conditions can make it difficult to maintain a clear and functional ABAC architecture, especially in environments undergoing constant transformation.

In current ABAC architectures, PEPs are generally designed to work only with PDPs from the same vendor, using proprietary protocols, with no support for compatibility between different vendors.

Standardizing the way these different PEPs and PDPs interact, in order to improve system interoperability and reduce dependence on a single supplier, is the aim of the OpenID AuthZEN working group.

OpenID AuthZEN: towards improved interoperability

AuthZen is a working group initiative launched in 2023 by the OpenID Foundation to standardize the interactions between PEPs and PDPs, in order to improve interoperability between systems from different suppliers.

This initiative responds to current problems where authorization services (PEPs and PDPs) are often designed to work only with solutions from the same vendor, limiting their interoperability.

AuthZen was launched to develop a standardised protocol that would facilitate integration and communication between PEPs and PDPs, reducing dependency on single vendor solutions and improving overall authorisation security.

To make these interactions more flexible and universal, AuthZen relies on existing architectures and technologies (OPA/Rego, XACML, etc.) to improve deployment, scalability and interoperability. The first two stages of this standardisation with Open ID AuthZen are the implementation of a simple ‘Request/Response’ and ‘Permit/Deny’ type protocols and a multiple decision approach in order to group several authorisation requests into a single request and receive several decisions in return.

The AuthZen think tank includes security players such as 3Edges, Axiomatic and others. It is also open to players who want to develop authorisation systems and make architectures more secure and interoperable.

Prospects for the evolution of authorisation: Event-time

A new approach to the evolution of access systems is event-time. It is defined as an implementation of dynamic authorisation where access rights are adjusted in real time in response to immediate events or changes that occur. Unlike static or attribute-based approaches, event-time is characterised by a continuous evaluation of access rights, to ensure that all access remains compliant with the policies in place within the organisation.

For example, when a user’s status changes (promotion, departure, mobility, etc.), the system automatically adjusts or revokes their access rights. This proactive, event-based adjustment approach is common in information systems monitoring and security incident management.

Event-time is based on the following key concepts:

– Listeners: system components that monitor events in time and analyse important changes (mobility, promotions, departures, etc.) from various sources, in particular HR systems.

– Triggers: actions in response to an event identified by a listener, such as the revocation of access rights on the actual day a user leaves.

– Shared Signals: enabling different systems to share information about events in real time.

– Continuous evaluation: constant checking of access rights to ensure that each action or access remains in compliance with policies.

Frameworks and standards play a key role in implementing event-time by providing a structure for implementing the concepts in systems:

The Shared Signals Framework (SSF) is directly linked to the concept of shared signals, which enables systems via an API to share information about events in real time to ensure consistent access management. The continuous evaluation of this information is supported by CAEP (Continuous Access Evaluation Protocol), a protocol for standardising the writing of status changes. RISC (Risk and Incident Sharing and Coordination) is a generic protocol for standardising the transmission and reception of security incidents between these different systems, thereby enhancing the overall responsiveness of an information system.

Event-time is not based on a specific model such as RBAC or ABAC, but can function as a complementary access management layer to these traditional access systems, making them more dynamic and aligned with real-time situations.

The evolution of authorisation models, from traditional approaches to modern, dynamic methods, reflects the ongoing adaptation of IAM and access systems to the growing and changing needs of organisations.

Admin-time approaches laid the foundations for resource security with models such as DAC and MAC. RBAC introduced structured rights management, which is widely adopted in organisations today due to its relatively simple application.

With the advent of the runtime, access decisions became more refined, based on attributes specific to users, resources and context, as with the ABAC and GBAC models. However, these increasingly sophisticated models have led to the emergence of numerous proprietary solutions, limiting the interoperability of authorisation components and creating a dependency on specific technologies. This has led to the emergence of initiatives such as the AuthZen working group, which is working to develop standards.

The event-time approach provides real-time responsiveness, enabling systems to automatically adjust access in response to specific events. CAEP and the Shared Signals Framework facilitate this dynamic by standardising the exchange of information between systems, thereby strengthening security and compliance.

An overview of these different approaches and their associated models is presented in the timeline below, together with a summary table of the different models discussed.

By combining these different approaches, you can implement more secure, flexible and proactive access management, capable of responding to current and future identity-related challenges. These developments also highlight the importance of adopting adaptive and interoperable authorisation solutions to ensure effective protection of resources while meeting the operational requirements of teams.

These developments raise an essential question about the ability of organisations to anticipate these changes and integrate these new access management dynamics.

Whether you are still using admin-time models, exploring runtime options, or considering moving to event-time management, it is crucial to choose a model that meets your specific needs. It is also very important to anticipate the consequences for the management of this model over time (review of rights, measurement of data quality, review of policies, definition of expected reactions, etc.).  

What type of model do you use? 

Don’t hesitate to contact us to find out more and understand how to apply these authorisation models to your organisation’s context!

Cet article Access management: how is authorisation evolving to meet the challenges and needs of organisations? est apparu en premier sur RiskInsight.

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.

This trend can be explained by a desire to digitalize factories and develop connected industry that has rarely been accompanied by the modernization of the associated industrial systems: attacks are made simpler, their consequences stronger. And in the case of ransomware, a lack of authentication is often the starting point of the kill-chain: too weak or based on shared authentication factors between operators, accounts become susceptible to phishing attacks.

This observation can also be found by analyzing the “Industrial Cyber IS incident files”^[2] shared by Clusif. These include the takeover of the production system of a German steel mill, which could have been avoided if a second authentication factor had been required when carrying out critical actions on the industrial site.

The need to secure and modernize authentication methods for blue-collar workers is therefore crucial, in order to limit the risk of theft of these often poorly protected accounts, without adversely affecting the overall productivity of on-site operators.

The aim of this article is therefore, after going into more detail on the current context and the constraints linked to these populations, to compare the different solutions available today for these uses, to analyze the obstacles to the democratization of the methods deemed the most promising, and to share our vision and recommendations for catching up as best we can.

What is authentication?

Authentication means certifying your identity to a computer system before you can access secure resources. Throughout this article, we’ll be talking about multi-factor authentication when at least two of the four authentication factors below are combined:

• What I know (password, PIN, scheme, etc.)
• What I have (personal device, USB key, smart card, badge, etc.)
• What I am (facial recognition, fingerprint, vein network, etc.)
• What I do (eye movement, signature, typing dynamics, etc.)

Note: the level of security depends on the robustness of the factors and their independence when combined^[3].

Blue-collar workers: a diverse range of uses…

When we talk about the blue-collar population, we mean all manual workers who don’t have their own professional workstation (e.g. mechanical, industrial and personal care professions). These populations have different authentication requirements to the so-called white-collar populations, as they mostly use an office information system with multiple devices shared between different employees:

• Mobile workstations and tablets (access to production management software (MES), etc.)
• Fixed control workstations (machine tool control, management, etc.)
• Shared office workstations (time and attendance, training, etc.)

Operators must therefore be able to authenticate themselves on control stations, for example directly connected to the machine tools using a network card, but also independently of their location within the site on mobile stations.

… with multiple constraints

In order to make the best possible assessment of the various authentication solutions available to blue-collar workers, it is important to bear in mind their specific professional constraints.

These can be broken down into three main areas:

• Pace constraints: working under automatic cadence and complying with production standards precludes the use of long or untimely processes.
• Constraints linked to the wearing of PPE (personal protective equipment) such as gloves or masks: these can prevent the use of certain biometric factors (facial recognition, fingerprint, etc.) or make the use of passwords less ergonomic (use of gloves on touch screens or keyboards).
• Constraints linked to regular changes of workstation: regularly changing workstation means having to authenticate several times a day on different workstations. What’s more, if this authentication is local, prior enrolment will have to be carried out for each of them.

Beyond blue-collar constraints, there are other factors to consider from an employer’s point of view.

There are also three main themes:

• An important issue of uniformity: all employees should be able to authenticate in the same way on all machines and software, in order to have a common user experience, a single process, support and documentation.
• Significant investment: an authentication solution is costly to acquire (e.g. badges, wristbands, sensors) but also to maintain (e.g. support & servers). These costs may be difficult to justify if employees don’t need to access sensitive resources.
• Physical security already in place: adding a second factor or hardening the first may seem pointless to companies that already physically secure their sites, and therefore assume that an individual with physical access to the device will be trustworthy.

What authentication methods are available on the market?

Two main categories stand out:

– “Mature” players, offering multi-factor authentication with a badge coupled with a password or a locally stored PIN code. This choice enables physical and logical access to be merged, for example, by authorizing access to devices controlling production lines via access badges integrating the FIDO2 standard.

– Less mature players, who maintain weak authentication using passwords only. They remain in the majority, and the accounts they use are often generic, to maximize authentication speed and thus productivity.

What authentication methods are needed to meet these challenges?

Several criteria to consider…

In order to compare the various possible methods, six criteria were considered, with particular emphasis on two main issues: user experience and security.

… to identify the most relevant authentication methods

Based on these criteria, the authentication methods considered relevant and viable for blue-collar workers can be distributed as follows:

In addition to biometric solutions, which are heavily regulated in France by the CNIL, RFID/NFC cards (badges) are emerging as offering the best ergonomics for a satisfactory level of security. This is in line with what has been observed among “mature” players in this field.

Coupled with a PIN code or password, it enables multi-factor authentication and, for most industrial players, represents an easy-to-use solution for increasing operator access security.

However, it may not be sufficient in particularly sensitive industries, where some innovative solutions may stand out:

The FIDO2 biometric key:

• Many machines have a USB port, and the FIDO2 standard ensures compatibility with a wide range of applications.
• The fingerprint replaces the PIN code, ensuring security even if the key is lost or stolen.
• No biometric images are saved, and no templates are stored anywhere other than in the key.

The biometric wristband is also based on the FIDO2 protocol (example of the “Nymi” wristband, not affiliated with Wavestone):

• Each employee receives a wristband and enrolls using his or her fingerprint.
• At the start of the day, each employee puts on their wristband and unlocks it with their fingerprint.
• As long as employees do not remove their wristbands, they simply pass them by equipment equipped with NFC sensors to authenticate themselves with the FIDO2 standard.
• The wristband is able to detect “life” and locks as soon as it is removed.
• No biometric image is saved, and no template is stored anywhere other than in the employee’s wristband.

These solutions are costly, but offer state-of-the-art security and ergonomics.

Democratization held back by several factors

Although solutions are available, blue-collar authentication is still lagging behind, due to a number of factors:

• Logical access sensitivity: this is not always sufficient to justify the cost of modernizing and strengthening authentication.
• Attackers’ priorities: management and office information systems are still the main targets of attackers, prompting companies to concentrate their security efforts on these areas.
• Software and infrastructure obsolescence: the machines and programs used on production lines may be obsolete. Companies are therefore reluctant to replace these functional resources, at the risk of running into compatibility problems.
• Imposed regulations: the CNIL does not encourage the development of biometric authentication systems in France^[4].

However, modernization is set to accelerate thanks to new security requirements linked to the development of the IoT. The FIDO2 standard is also becoming increasingly popular, and innovative solutions are beginning to gain market momentum. Finally, it’s worth noting that some online operators use the same resources as the office population, so passwordless solutions such as Windows Hello for Business are both feasible and easy to implement, thanks to the sensors integrated into devices.

Is the convergence of logical and physical access the solution to trigger large-scale democratization?

Physical access for blue-collar workers is often already secure, since they work on sensitive sites. In most cases, a badge system is already in place for access to buildings and restricted areas, with biometric readers or other surveillance tools (video surveillance, etc.) installed on the most critical sites. This raises the question of capitalizing on and centralizing access control, and offering the same means of authentication for logical access as those already in place for physical access would offer clear advantages, while also raising new challenges:

• Improved user experience, with the same process for all accesses.
• Simplified and reinforced authorization management.
• Physical security teams need to be coordinated with the IT department, and strong governance issues need to be anticipated.
• A common infrastructure is required, with all networks controlling the accesses to be connected.

[1] Authentication Security Best Practices in the Manufacturing Industry, published by Chris Collier on the blog HYPR

[2] Industrial Cyber IS incident files, published by the Clusif

[3] Recommendations for multi-factor authentication and passwords, published by the ANSSI

[4] Biometric access control in the workplace , published by the CNIL

Cet article Authenticating blue-collar workers: a challenge too often neglected? 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.

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

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

Examples of use cases depending on the target :

Companies

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

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

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

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

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

Citizens

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

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

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

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

The European Identity Wallet (EUDI)

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

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

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

Conclusion

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

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

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

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

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

What is the extended enterprise?

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

What type of governance?

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

Which vendor’s solution?

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

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

What new technologies to facilitate implementation?

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

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

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

Drawing from its experience in the field of digital identity, Wavestone is publishing its first edition of the CIdO Radar in 2024. This radar follows the same methodology as the CISO Radar published by the firm for the past 10 years and offers an in-depth look at the underlying trends driving the digital identity ecosystem.

In this article, we invite you to explore some impactful and structuring topics for the IAM landscape, with two currently trending  subjects (passwordless and CLM) and moving towards the future topics they foreshadow in the emerging section of the radar (respectively predictive anti-fraud and post-quantum cryptography).

Passwordless, a major evolution not so simple to achieve

For decades, the password has been the central authentication factor for users (and often still is). Passwords have then been complemented into multi-factor authentication strategies to compensate for the inherent weaknesses of this authentication method (low complexity, reuse, phishing risks, etc.). New tools have thus been added to the user authentication process: OTP via SMS or email, push notifications, soft and hard tokens, etc. Despite the increased security level provided by the addition of these new authentication factors, the password remains both a weakness if discovered (it remains reusable on an account without MFA where it is enrolled) and a burden for the user’s experience, as they must remember it and securely store it.

All these reasons have led vendors to imagine secure authentication methods not relying on the use of a password. Eliminating the password allows companies to improve the user experience for their employees, enhance authentication security by reducing the attack surface, and benefit from a positive image in the market. The user finds themselves in an environment where they no longer need to remember a multitude of complex passwords and where they are no longer at risk of having their account stolen through phishing attacks. The use of FIDO2 (Fast Identity Online 2) technology is based on asymmetric cryptography which is currently the most widespread alternative to passwords. This technology is driven by the FIDO Alliance (Google, Microsoft, Amazon, Apple, etc.) and, relies on the use of physical security keys locally storing the private key associated with each service. Ultimately, this  allows a user to log into all their accounts without a password, their login, or email address (simply by using the physical key they possess and a second factor such as biometrics).

However, implementing passwordless authentication comes with significant organizational questions for a structure. How to manage account recovery if this account does not rely on a password? If an employee loses their security key, how can access to their account be restored without being able to use the associated private key? This major issue of “credentials recovery” is inseparable from any passwordless policy and assumes that an organization has anticipated each step of it,  such as: purchasing and distributing authentication media, managing their loss/theft/destruction, obsolete media rotation processes, account backup solutions, double enrolment for critical accounts and management of employee departures, etc.

Passwordless authentication is a trending topic and is being deployed in many organizations. For many, the next step involves establishing fraud detection capabilities before they occur (also called “predictive anti-fraud”).

Predictive anti-fraud, how to prevent fraud before it occurs?

Predictive Anti-Fraud corresponds to proactive monitoring of systems aimed at identifying and stopping fraud before it occurs, rather than relying solely on post analysis of malicious activities that have already happened. These surveillance capabilities are particularly relevant for securing online business activities involving money transfers (such as pooling funds, loyalty accounts, online payments, etc.) in sectors like retail or luxury for instance (as they are often less mature on this subject than banks). We are currently witnessing an increase in phishing attacks aimed at stealing customer account data to misuse their contents (loyalty card fraud, for example, is a real concern for players in the retail sector).

Access management solutions are increasingly capable of detecting fraud patterns and halting illicit activities before completion. All these capabilities rely on machine learning (involving a training phase for the tools) and involve three key stages:

• Detection: Systems can detect behaviours deviating from typical user/customer journeys and as well as sequences of suspicious actions. Detection relies on the customer context (browser used, network, cookies, etc.), the dynamic context (IP address, device used, user behaviour, typing speed, strength of authentication performed, etc.), and the business context (type of requested transaction, amounts, modifications of sensitive information, etc.).
• Analysis: Automatic analysis is conducted with the assignment of a confidence score to the current user profile.
• Response: Response rules are defined to best address alert triggers, with automatic responses for obvious or critical situations (e.g., additional authentication factor, session termination), or manual responses for cases requiring human decision-making.

The main challenge of predictive anti-fraud is the correct  calibration of machine learning tools and their adaptation to the specific business context. Placing too much emphasis on security could cause a disproportionate amount of  negative impact on the service: a high number of false positives affecting user experience and an increase in service complexity and slowdowns (captcha, step-up authentication, significant network consumption, longer processing times). The definition of relevant security and detection rules must be accompanied by a model based on machine learning, as specific as possible to the use case. Given the increasing complexity of attacks, the key to an effective predictive anti-fraud strategy lies in the solutions’ ability to detect and correlate weak signals. For example, some vendors are now capable of detecting fraud attempts during false customer service calls by correlating the users’ actions with whether they are on a phone call.

Certificate Lifecycle Management (CLM), a new market for an old issue

Many companies are currently facing an explosion in the number of electronic certificates within their IT systems. These certificates (and associated cryptographic keys) serve various purposes such as machine-to-machine authentication, user authentication, data signing and encryption, websites security, application micro-services, etc. This increase in the number of electronic certificates significantly increases the workload for the teams in charge of their management. The lifecycle of an electronic certificate includes several stages such as:

1. Requesting the certificate from a PKI (Public Key Infrastructure)
2. Receiving the certificate and associated keys
3. Deploying the certificate within its scope (either as a replacement for an expiring certificate or on a new scope)
4. Decommissioning and revoking the old certificate (if applicable)
5. Continuously monitoring the certificate and its future expiration date
6. Reproducing this process for each certificate before its expiration.

Manual management of tens (or even hundreds) of thousands of electronic certificates poses numerous challenges. This type of management is highly resource-intensive, relies on repetitive tasks, and is prone to human errors. It is not uncommon for certificates to slip through the cracks of teams and go unrenewed, or simply remain undeclared within the IT system (shadow IT). For all these reasons, an organization with a large fleet of electronic certificates should consider adopting a CLM solution.

CLM solutions offer many features to facilitate and ensure the reliability of certificate lifecycle management. Some of these features include:

• Certificate discovery tools, allowing a company to have a comprehensive view of its certificate fleet (even for undeclared certificates).
• The use of protocols automating all certificate-related actions (mentioned above).
• Numerous connectors enabling clients to seamlessly integrate these solutions within their IT systems.
• Governance and rights management modules for certificates.
• Alerting capabilities serving as a safety net for teams.

The “Zero Trust” philosophy, often requiring securing communications between services through mutual authentication using electronic certificates (with the increasingly frequent use of microservices architectures, the explosion of non-human accounts, etc.), tends to increase the number of electronic certificates within organizations. Utilizing dedicated certificate lifecycle management tools rather than manual tracking can reduce certificate-related incidents by 90% and decrease incident processing time by 50%, according to Gartner[2].

For more details on CLM solutions, you can read Wavestone’s article dedicated to this subject here.

The implementation of a CLM solution signifies a step forward in securing infrastructures, but more importantly, it can be leveraged towards crypto agility (the ability to quickly replace or update encryption algorithms or protocols to address evolving threats). Crypto agility is a theme that we should expect to encounter more and more frequently in the medium term, largely due to the development of quantum computers.

And what’s next? Technological challenges ahead, such as post-quantum cryptography

While organizations strive to adopt robust IAM strategies, considering current technological threats is no longer sufficient. The impending topic of quantum computing (even if it seems still a few years away from now) is set to disrupt all our encryption practices, necessitating early anticipation of measures to be implemented for the 2030 decade. The use of quantum computers and their famous qubits (which can simultaneously take on values of 0 or 1) already allows for much more efficient cryptographic calculations than traditional computers.

It is important to note that symmetric cryptography is not as much at risk from quantum threats, and increasing the size of encryption keys will allow this encryption mode to resist quite effectively. However, classic RSA and Elliptic Curve asymmetric cryptography is truly threatened: key exchange, authentication, and digital signature which rely on that classic asymmetric cryptography are already at risk for specific use cases. The Shor’s algorithm could enable a quantum computer to break RSA 2048-based encryption in a matter of hours.

Post-quantum cryptography is currently focusing on solutions to adapt encryption to the future capabilities of quantum computers. ‘Store Now, Decrypt Later’ which means that we can decrypt in 10 years what is captured now, even encrypted, or the capability to modify (in 10 years) the author or the content of a digital signature are risks that should already be considered today, especially with the time needed to handle the migration to post-quantum algorithm. In 2022,  NIST published a list of 4 such encryption algorithms, resistant to quantum computers: CRYSTALS-Kyber for general encryption, CRYSTALS-Dilithium, FALCON, and SPHINCS+ for electronic signature. These algorithm should be confirmed during 2024.

The main current recommendation to ensure the transition to post-quantum encryption is to perform hybrid encryption, i.e., to use both classical and post-quantum encryption algorithms to secure communications. While this issue is not yet at the heart of current IAM challenges, it is important to monitor its evolution, especially since some major vendors are already entering the market and introducing a new term: QCaaS (Quantum Computing as a Service).

Cet article 2024 CIdO Radar 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.

To dive deeper into IAM, our experts have created an IAM maturity assessment tool.

Interview with Anatole CATHERIN, Manager and IAM expert for almost 10 years at Wavestone.

Hi Anatole, thanks for your time! First of all, can you explain what IAM really is?

Identity and Access Management (IAM) is a discipline that sits at the crossroads of three worlds:

1. Cybersecurity strengthening: It comprises managing identities, the rights granted to these identities and user access to company resources. Each user has access confined to the limits of their role within an organization. To successfully achieve this, organizations need to know who, within their information system, can perform which actions and why. IAM is therefore an essential component of cybersecurity, especially during implementation of a Zero Trust policy.
2. Business enablement: Identity and Access Management is also a business enabler and a facilitator for successful digital transformation within organizations as it increases operational process efficiency to employees and customers. For example, IAM enables the control and fluidity of arrivals, departures or mobility by ensuring that new employee benefit from accurate accesses. In case of subsequent mobility or departure, the relevant accesses are removed and no information is lost.
3. UX enhancement: IAM facilitates a seamless user experience for employees within an organization. Moreover, the best IAM systems operate behind the scenes to enable work on arrival and enhanced connectivity based on security requirements.

Why is it so difficult to build an IAM system that works?

As you can imagine, the challenge and complexity of IAM is striking (and maintaining) the balance between security and fluidity of navigation.

To successfully implement IAM, it is important to assess the current state. With good reason, clients have difficulty measuring the effectiveness of their existing IAM system. There is no dedicated benchmark in the market evaluation.. The NIST pillars are high-level and do not cover all the challenges related to IAM; the existing benchmarks only deal with the cybersecurity aspect of IAM and ignores the impact on the operational efficiency of an organization’s internal procedures and the fluidity of the user experience.

The goal in creating the IAM Framework was to create a framework that evaluates the entire discipline and that can be used to build an efficient roadmap.

Can you tell us a bit about the IAM maturity assessment tool?

More than a tool, it’s a framework and a tool-based methodology that supports customers and provides them an overview of their IAM maturity.

The Framework enables the understanding of an organization’s current state (which IAM perimeters are deployed (or not), which IAM axes require further work, etc.). It provides an overview, with the right framework, the right angle and the right resolution to cover all IAM topics.

The maturity assessment consequently allows the prioritization of workstreams that culminates in an IAM action plan!  Thanks to this framework, we can identify the main areas for improvement, while accounting for organizational nuances by introducing the notion of scope.

In short, it meets three objectives: Evaluate, Improve and Extend IAM to other perimeters (beyond internal and service providers, with customers or partners). It was intended to be exhaustive to highlight our customers’ shortcomings and subsequently measure their progress and the effectiveness of their transformation program.

Our ambition is to make it the primary evaluation standard, entirely dedicated to IAM, with a sufficient level of granularity to cover all issues!

How is it structured?

Concretely, our tool is composed of about fifty questions that cover the 6 IAM themes:

1. Governance
2. Identity management
3. Entitlement management
4. Access control
5. Privileged access management
6. Reporting and controls

It can be used in several cases, here are 2 examples:

Can you tell us about the last time you used it with a concrete example?

We tested the questionnaire in the field through several missions, during which the use of the IAM Framework helped accelerate the process. These missions comprised:

• the definition of an IAM roadmap for a large energy company
• the framing of a migration to an IAM tool for a banking group, which allowed the measurement of gaps between their existing solution and the new one
• IAM maturity assessment for an insurance company, to identify friction points and areas for improvement and to establish a roadmap

For these three projects, the assessment grid made it possible to identify all addressable topics (regardless of whether the client was aware of them at the outset) in order to provide an actionable roadmap covering all IAM issues. In other words, the Framework can be used as an analysis framework for the implementation of a project.

We plan to launch new missions on the subject and we are looking forward to supporting new customers in their journey to improve their IAM structure!

A final word?

I will end by reminding you of the key components of the Framework:

• It is “ready to use”: the fifty questions encompassed in the framework designed by Wavestone experts covers all IAM topics
• It offers a standardized and formalized vision of its maturity on the subject of access and identity management: this assessment is also an opportunity to involve all the key players impacted by IAM: cyber teams, IT teams, internal audit teams and business teams,
• It facilitates the prioritization of actions within a transformation program:as explained above, it can be used at different times and can therefore be used as a support for a broader reflection,
• Finally, it is a flexible means of use: It can be used at a very high level (a strategic level) or to develop very specific actions.

Want to evaluate yourself? Please contact us!

Cet article [INTERVIEW] IAM Maturity Assessment – Where do you stand and why is it crucial? est apparu en premier sur RiskInsight.

The obviousness of IAM, and the difficulty of the transformations it implies

Faced with the evolution of growing threats and use cases (Mobility, Teleworking, Cloud Computing etc.), incorporating IAM is no longer just an option. Instead, it is now a given that incorporating an efficient and agile identity and access management is a major differentiator for organisations.

In essence, IAM is at the crossroads of all structuring transformations. Firstly, it is a major pillar for moving towards a zero-trust approach. Secondly, it is a “basic” essential for effectively serving its users and providing them with constant comfort during all phases of transformation. Finally, it is obviously a differentiator in the creation of the relationship with customers.

IAM can no longer simply allow itself to “follow at a distance” amidst the transformations of the Enterprise i.e., by offering a minimal level of service that is often difficult to evolve. Instead, it must be efficient, agile, and able to anticipate complex situations that may arise. For instance, M&As, the multiplication of APIs, or the shift to a “platform” economy model. These situations imply an in-depth rethink of the IAM service. For example, the IAM’s scope and ambition, policy and governance, delivery mode (on-premise vs. SaaS), service offering, and economic model etc.

Deployment of IAM services in major accounts

Market maturity: know how to evaluate your maturity in relation to the market in order to launch your transformation programme on a solid and objective basis

The vast majority of large accounts have already carried out one or more projects that have led to the deployment of IAM services. However, these deployments are often partial, and the maturity of the deployment can vary greatly from one entity to another. Historically, these projects are in fact confronted with a strong heterogeneity of the existing ones (in terms of organisations, processes, and I.S.), and do not have the necessary legitimacy to make practices converge. Furthermore, IAM was often seen as a “one shot” project with resources that were often insufficient to follow and adapt to changes in the company (reorganisation, M&A, application changes, etc.). These factors could lead to a “disconnect” between the IAM subjects that are too static and the real needs that are constantly evolving.

The deployment of an IAM service is not simply a matter of deploying a “box” in production. Instead, in order to gain the most benefit, it is necessary to rethink and simplify its organisation and processes. Therefore, it is imperative to ask the following questions:

• How to manage the arrival of a new employee?
• How to manage the internalisation of a service provider?
• How can you model your business profiles? How to make them evolve over time?
• How to involve managers and data managers in the IAM process?
• How to deal with the loss of strong authentication means?
• What standards should be imposed to simplify the connection of applications to the IAM?
• How to ensure compliance with internal rules and regulations?

For a few years now, we have seen a real awareness and a desire on the part of our clients to take hold of IAM in order to make it more efficient, streamlined, and agile. This implies being able to arbitrate and carry out an in-depth transformation. In concrete terms, over the last 3 years, two-thirds of our clients have launched such IAM transformation programmes. These multi-year initiatives have gained in ambition, structure, investment, and visibility and now rank high in the “Top 5” of major IT transformation projects.

To launch such programmes, the first step is being able to assess its real maturity, entity by entity, before being able to define a realistic transformation trajectory that unites the stakeholders. In a very simplified way, we can distinguish 4 levels of maturity:

• Fragmented: the organisation does not have a consolidated approach
• Rationalised: the organisation’s IAM is simplified and centrally managed on core services
• Extended: the organisation’s IAM capabilities are adapted to an evolving I.S.
• Controlled: the organisation’s IAM is efficient, agile, and reduces workload through automation

As a trend, we consider that most large companies lie on the intermediate levels of “Rationalised” and “Extended” and aim for a “mastered” target that is based on:

• A central, unique, and optimised IAM infrastructure
• Delegated day-to-day management within each entity

5 keys to successfully operationalise your IAM strategy

IAM is a vast subject in which it is easy to get lost. Moreover, the operational reality of IAM is often poorly understood. Meanwhile, the complexity of the transformation is underestimated.

To mitigate these risks, we propose 5 major keys:

• Define your IAM ambition and ensure that this ambition is consistent with the resources allocated (sponsor, ability to move the lines, human & financial resources etc.)
• Take the time to understand the operational reality of IAM
• Organise yourself in a transformation programme capable of addressing all facets
• Prepare for an in-depth transformation by accepting to move forward in stages alongside any compromises and, therefore, any renunciations to deal with the sum of the constraints
• Rely on real data to explain its trade-offs and to anticipate possible quality shortfalls

Relying on IAM providers: trends and risks

The IAM vendor market is becoming more structured and is translating into the Cloud

The IAM provider market, like other specialised markets, is evolving as a result of changes in information systems. For instance, moving to the Cloud, offering more APIs, integrating data analysis and AI functionalities to simplify and automate decision making etc.

In addition to these considerations, two trends specific to the IAM vendor market are emerging:

• Firstly, the leading Access Management players are looking to progressively extend their functional coverage towards Identity Management or PAM functionalities
• Secondly, there are more and more players covering specific functional needs, such as IAI (Identity Analytics & Intelligence), CIAM, or the desire to have a platform directly developed in Service Now

The move to the cloud indicates changes in the architecture of IAM solutions

An increasingly great number of vendors are offering IAM solutions in the cloud. This movement aims to offer the same functional coverage as on-premise applications in SaaS mode. Depending on the services offered, they are structured around two components:

• A “Cloud” part that carries all the functionalities and stores the customers’ data
• An onsite “gateway” which provides a link with the historical system in place (for provisioning, for example). This allows for better control of data exchanges and therefore contributes to securing the architecture

Hence, the aforementioned two-component architecture presents the same risks as any other Cloud service and must be addressed in the same way: What service levels are guaranteed? Where is my data stored? What about the protection of my data and compliance with standards (GDPR in particular)? Under what conditions can I change suppliers?

The geopolitical context increases these risks and poses a potential service interruption in the application of possible international sanctions.

And the IAM of the future: what developments?

Tomorrow, IAM will continue its transformation towards greater agility, Cloud, standards & integration, decision support, and automation – thanks to enhanced AI capabilities. As far as the authentication system is concerned, a strong authentication is now a “basic” and we expect two major developments:

• A rather technical evolution with “passwordless” that aims to make passwords disappear. This includes, on a technical front, a passwordless world in application databases and in inter-application flows.
• An evolution in the means of authentication given to users. Smartphones have become an established authentication factor. However, not all enterprise populations are well equipped. While the “smart card” medium is losing ground, secure dongles (a hardware component that plugs into computers or televisions, generally on an input/output port) seem to be gaining traction for those populations without smartphones instead.

Finally, in the longer term, IAM will certainly evolve under the impetus of the “privacy-by-design” approach, which is becoming increasingly interesting and more frequent. This comes with good reason, especially with the with the growing generalisation of citizen identity (with an ad hoc level of enrolment) for commercial uses.

Cet article IAM has finally made it to the top of the IT department’s major transformation projects! est apparu en premier sur RiskInsight.

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

Why are passwords so common?

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

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

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

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

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

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

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

And is it effective?

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

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

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

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

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

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

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

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

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

What to do?

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

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

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

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

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

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

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

Conclusion

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

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

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

IAM is a far-reaching concept. This understanding must be put into practice when running such a programme, to avoid quickly falling into common pain points. Let’s take a closer look.

IAM programme challenges: some typical examples

Three main drivers which are putting demands on IAM are business change, cyber security, and user experience. However, organisations often undertake IAM programmes driven, exclusively or primarily, by the desire to migrate to a new solution. With technical debt or tooling the only real concern, IAM programmes can face issues very quickly.

1/ Broad impacts of migrating to a new solution

Often the desire is to simply migrate to a new tool or perform a major upgrade of the existing technical asset, whilst leaving all other elements of the IAM service unchanged. This can have unwanted effects on these other aspects. For example, a new tool will likely bring about new approval processes, which will require staff training on a new user interface. It could even require entirely new leavers and joiners’ processes for HR. This pain point ultimately boils down to a lack of assessment of the impact of the technology change, in the context of wider IAM ecosystem.

2/ An ever-growing list of requirements

When an organisation realises that IAM change is not limited to the tooling, this can often open the floodgates to an unrealistic number of new objectives. Stakeholders end up demanding more of the programme (such as better user experience and increased ITSM integration) – despite these new objectives not being originally identified and catered for. The programme can become a vehicle to voice dissatisfaction with the existing end-to-end IAM service, causing scope creep. This dynamic can quickly bring pain to the programme across change management, budget, and solution architecture.

3/ Forcing a like-for-like implementation

Once interactions between the new IAM solution and its perimeter services are fully functioning, you still need to consider differences in design philosophies between the new and the old tool. Key product design differences must be catered for. If not, organisations can end up requiring custom code and complex configurations on the new solution, simply to match the previous setup. This can impact on vendor support, maintenance, overall performance – and not to mention the need to retain a huge body of knowledge on the complex customisation. By going down this road, you can cause more trouble than that you are trying fix. A true butterfly effect of issues can be on the cards when trying to force a like-for-like on different tools.

The key to avoiding these common pain points is to acknowledge that IAM must be viewed as a transversal topic, which impacts technology, people, and processes.

What is the recommended approach then?

Key to success is the acknowledgement that IAM improvement is a far-reaching programme. The implementation of new solutions is only the tip of the iceberg, and key impacts should not be underestimated. Under the covers, we believe the key streams of the transformation are:

/ IAM solution renewal: the deployment (or upgrade) of the new IAM solution. This includes solution architecture, engineering, and technical migration.

/ Modelling of rights: existing access rights must be translated into the new IAM ecosystem, such as business roles and application profiles.

/ IAM data cleansing: the stream to review, cleanse, and validate reliability and correctness of existing user data. For example, recertifying the role of a user and validating their line manager to ensure the correct person is approving access requests.

/ New processes and change management: this includes new ways to request and review access to applications, new processes to manage leavers and joiners, and training staff.

/ Interoperability with other services and assets in the IS: for example, integrating the new IAM tooling with the SOC may require re-engineering the log ingestion into the SIEM and API calls. Another typical piece of work is to coordinate with concurrent AD migrations or upgrades.

We recommend structuring the IAM programme such that each of these topics is covered by an individual project. The design authority of IAM policies should operate at the programme level, with clear inputs to help guide all streams.

Critical to success is also strong sponsorship and a publicized vision of the objectives. Because IAM programmes touch so many organisational domains, it is essential that the programme manager and PMO function are supported at the executive level.

Finally, flexibility is key to manage changing circumstances and constraints. Here’s other tips to ensure the programme can remain on track to meet its intended objectives:

/ Find a good middle ground between legacy assets, the ideal target state & the capabilities of the new solution: the target state should be based on what best helps deliver the end-to-end IAM service to the business.

/ Evaluate the possibility of integrating new solutions with existing services, even if not originally envisaged in the ideal target state. Simplify and rationalise where possible. This will help in both the short term and the long term.

/ Do not rule out the possibility of retaining existing tools which were originally due for decommission, if it supports the overarching IAM objectives: sometimes it is best to maintain some existing assets, rather than decommission and migrate for the sake of IT modernisation.

In this article we have seen how defining key objectives is vital for the success of the programme. Understanding the breadth of IAM change is crucial, both for structuring the programme, and delivering on time and on budget. This approach will also allow programme managers and each stream lead to implement flexible measures to migrate from a legacy ecosystem and legacy applications to the new sol

Cet article Identity and Access Management: keys to a successful transformation programme est apparu en premier sur RiskInsight.

IAM transformation: what are the main drivers?

Businesses are changing at pace, and speed-to-market is strongly dependant on IT systems built on robust and scalable identity services. Whether it’s new a web service available to customers, a significant expansion, or a back-office merger – the requirement to scale IAM services quickly and efficiently is ever-present.

At Wavestone, we witness three drivers, often in combination, which demand more from Identity & Access Management:

1. Cybersecurity risks
2. Business change
3. End user experience

Let’s dive into each of these in more detail:

1/ Evolving cybersecurity and information system models

Information systems are increasingly open and fragmented. Cloud adoption and distributed architectures are contributing to this fundamental shift. Security is adapting its principles and the notion of zero trust is now well established. Identity and access management is a key enabler for zero trust.

Information systems are consumed by thirds parties, customers, and employees. Identity is central to critical data exchange and confidentiality amongst diverse entities. It is therefore necessary to have a unique identity for each entity across the entire information system. While architectures evolve – the ultimate IAM objective does not: the right person or entity, with the appropriate level of rights, to access the right resource, in the right context. Crucially, this principle must be met on an ongoing basis.

Each machine and user’s unique identity is also critical for traceability. An organisation should be able to identify, authenticate and authorise any user, from any other entity, when accessing a resource. The ability to centrally log, audit and monitor these events from across the information system is essential.

2/ Identity-as-a-service to the business

Businesses are experiencing core transformation which require more agility & shorter time-to-market. For example, several retailers are seeking new digital avenues to market due to an evolving e-commerce landscape and operational challenges brought about by the COVID-19 pandemic. Identity services must be able to support large business initiatives and cater for innovation at scale.

Complex business change cannot be slowed down by extended security or infrastructure delivery times. Identity must be an enabler, and not synonymous with delay. Any project must be able to rely on identity services which are provided as an available commodity to the business, and not newly designed and deployed for each initiative.

Consolidation and standardisation of IAM solutions and processes is critical to implementing this model. This includes consistent and robust management and is dependent on technology-agnostic methods and protocols – based on the latest, secure, industry standards (such as SAML, OIDC and OAuth).

The provision of identity services must become embedded in the organisation’s operating model and practices such as Agile, DevOps @ scale and innovation @ scale: IAM delivered as a service to the business.

3/ User experience demands are now centre stage

The third, crucial, driver of IAM transformation is user experience. The focus is on organisations to provide employees with the same quality of authentication and authorisation services that external customers have often enjoyed in the past. The objective is to allow end users to prove their identity easily and effortlessly, and access required services, from anywhere, and from any device. This forms the basis for a genuine continuous experience that supports new ways of collaborating, also accelerated by remote working.

Easy and smooth registration processes, as well as consistent authentication across different applications, should be provided to customers to simplify their experience and build brand loyalty. This same principle holds for employees and third parties.

Passwordless technologies and unique application logins are examples of solutions on the rise; Innovative risk-based and contextual approaches can streamline accesses, which can have a significant, positive, impact on user experience by reducing authentication requests.

What steps to IAM transformation?

Understanding your current maturity is a key step towards delivering on the above. Over years of supporting IAM initiatives with clients, we have built our IAM maturity improvement journey, which is comprised of 4 maturity steps.

• Fragmented: the organisation lacks a consolidated approach to IAM across solutions, governance, and standards.

• Rationalized: the technology landscape supporting IAM is simplified and managed centrally to aid user experience across all applications and users. Consolidation provides satisfactory oversight capabilities.

• Extended: the organisational IAM capabilities cater for an evolving information system: any user, any device, any service.

Many organisations currently have elements of these capabilities, but rarely deployed globally.

• Mastered: the organisation has adopted next-gen solutions, which provide strong security benefits and a smooth user experience – all whist reducing the workload on IT operations thanks to intelligent automation.

At the time of writing, these are adopted on a case-by-case basis or serve as an aspirational step on IAM roadmaps.

Each of the above steps requires a deep transformation of the environment: change of governance, change of processes, and deployment or migration of supporting technologies. To be a success, we believe it needs to be addressed as a dedicated IAM transformation programme.

Stay tuned for our next publication, where we share what good looks like for an IAM transformation programme…

Cet article Identity and Access Management: back in the spotlight est apparu en premier sur RiskInsight.

Let’s continue here with a few additional questions – and answers – to explore the subject in greater depth.

How many roles do I need to create? How many roles should each user have?

It may be tempting to design a model that can handle every use case identified during a requirements collection phase. However, we should bear in mind that the model will have to live and evolve with new applications, new organizational units, etc.

There is no general rule on the number of roles to assign to each user. It is perfectly possible to build your model so that only one role is assigned per user, just as it is possible to assign several.

However, a compromise must be found between creating overly specific roles, which quickly fall into the “1 role for each user” pitfall, and creating overly general roles that do not bring much benefit and lead to over-allocation of rights.

Aiming for 80% of rights allocated via the role model and 20% of discretionary rights should already prove to be a good goal.

Bottom Up or Top Down, which method should I use?

There are two main methods that can be considered when creating an authorization model.

The “Bottom Up” approach starts from the existing rights and analyzes them to derive a model. For example, if all employees in the Accounting department have the same rights, then a role dedicated to this department can be created, which will contain the corresponding permissions. In this approach, data quality is a prerequisite for successful modeling, as wrongfully assigned rights would add noise to the model and reduce its relevance.

The “Top Down” approach starts by defining the theoretical authorization model, on which the necessary authorizations are then projected. For example, a role for the Accounting department can be created and include the permissions that business representatives deem necessary to accomplish their mission.

In practice, it is common to adopt an intermediate approach.

It is also recommended to work iteratively and to validate the approach on a pilot scope before generalizing it. The involvement of business representatives in the definition and validation of the roles plays a key role here.

What tools do I need?

The high volume of rights to be processed and the multiple iterations required imply the use of a tool that can either be sourced from the market or developed internally (Excel tables, database, scripts…). A prior analysis of the needs will ensure the adequacy of this tool.

In addition to the ability to create roles or rules for assigning rights, which is increasingly facilitated using algorithms that take advantage of machine learning, the chosen tool must facilitate the data quality cleaning phase before the actual modeling phase. It is also useful to have a simulation function that highlight the over- or under-allocations generated by the new model compared to current assignments.

In nominal mode, the IAM solutions on the market offer various possibilities that can used advantageously: role hierarchy, automatic ABAC-style allocations, suggested allocations, multiple role dimensions, etc. However, care must be taken not to fall for a model too complicated to use and administer.

If the choice of the IAM solution that will handle the model has already been made, it is necessary to ensure that this solution can handle all the desired complexity, even if it means making some simplifications or adjustments to the model.

Should I build my authorization model before, during, or after the implementation of my new IAM solution?

Generally speaking, it is preferable to design your authorization model before the implementation of a new IAM solution as the model can strongly influence the choice of the tool, depending on the adequacy of the technical possibilities and the functional expectations.

If data quality is satisfactory, the implementation of the model itself can then take place at the same time as the implementation of the IAM solution. If necessary, it is possible to plan a transition phase where the old tool can coexist with the new one. The perimeters ready for the transition to the new model can thus processed in the new tool, which gives more time for the migration of perimeters that require more work and time, although a migration schedule should be defined and closely monitored to avoid any drift that would prolong this situation for too long.

How much time should I plan?

The implementation of an authorization model is usually substantial project that requires the consideration of many factors and has a significant impact on all the stakeholders involved in the authorization environment (application managers, user support, business lines, etc.).

It is essential to take your time during the framing and design phase in order to ensure the success of your project.

The modeling phase can be long and tedious, especially if the volume is high in terms of the number of roles or the number of entities to be covered, or if the data quality is unsatisfactory and requires remediation.

Change management should not be neglected, given the impacts that are clearly visible to users. Training and a strong support phase are most of the time necessary once the model has been implemented.

What governance should I establish to bring my authorization model to life?

An authorization model is never static. The authorization catalog is updated as new applications are developed or decommissioned, the information system and business undergo evolutions, and reorganizations are carried out. Right from the design phase, it is necessary to reflect on the principles of current governance to avoid building a model that is too complex and impossible to maintain over time.

While the management of the model is often handled by a team dedicated to authorizations, the involvement of other stakeholders is essential, particularly on the part of the business, which must communicate any changes in its needs. The appointment of authorization correspondents within the business departments can be a way of encouraging this involvement.

Final words

The perfect implementation of an authorization model probably does not exist. Even if there is no major interdiction, finding a compromise between expectations and possibilities remains a delicate exercise that requires careful planning, preparation and monitoring.

In a nutshell, here are five good practices for the success of an authorization model redesign project:

1. Allocate sufficient time for the project.
2. Frame and steer the project with the greatest care to avoid deviations in terms of ambition, priorities, workloads or deadlines.
3. Communicate with and involve the right IT and business contributors.
4. Know when to say “no” if covering a need would risk deteriorating the ease of use or the maintainability too much.
5. Do not neglect the change management with the end-users.

It is worth note that these good practices remain perfectly applicable to any IAM project in general!

Cet article Redesigning your authorization model: the key issues (2 /2) est apparu en premier sur RiskInsight.

DAC, RBAC, OrBAC, ABAC or GraphBAC? Flagship authorization models evolve regularly and each one brings its share of challenges, promises, and complexity.

Over the last twenty years or so, during which the RBAC/OrBAC models seem to have prevailed, the difficulties of designing, implementing and maintaining an authorization model have remained the same, and there are few examples of perfectly satisfactory achievements.

There are many questions about designing or redesigning one’s authorization model. In these two articles, we try to answer the most frequent ones.

Before we do that, let’s go back to some basic notions about authorization models.

What is an authorization model?

A layer of abstraction…

An authorization model is a layer of abstraction that comes above technical entitlements (application rights, transactions, groups, etc.). It is made up of carefully defined objects (roles, profiles, etc.), with a name in natural language, and often organized hierarchically.

… which simplifies the management of authorizations…

This layer of abstraction makes it possible to rationalize the number of objects to handle.

For the business, it becomes easier to understand the available authorizations and to request or validate the appropriate rights.

For IT and support teams, the burden of allocating authorizations is reduced overall. The implementation of automation tools can support a large part of the daily requests, allowing specific requests to be processed more carefully.

… and improves security

Beyond the regulatory and normative dimensions of authorization management, often highlighted by Auditors during their work, the lack of control of authorizations is an open door to intrusions and misuse of the information system.

Knowing one’s authorizations is a prerequisite for securing them, and the implementation of a model makes it possible to simplify the controls, particularly during review campaigns. It is indeed much easier for a manager to validate the allocation of a meaningful business role, rather than of a transaction with a very technical name.

Overview of possible models

DAC: Discretionary Access Control, aka no model at all!

What if the best model was the absence of a model? In some limited cases, especially if the number of authorizations or users is very limited, one can very well do without designing a model that would add an unnecessary layer of complexity. This implies, however, that the authorizations are sufficiently meaningful.

RBAC: Role-Based Access Control

The RBAC model allows to group the authorizations required to perform a function within a company (business, mission, project…) in “roles”. These roles are then assigned in lieu of discretionary authorizations. They can be organized hierarchically, for example by subdividing “business roles” into “application roles”.

OrBAC: Organization-Based Access Control

The OrBAC model is a variant of the RBAC model in which the entities that make up a company are one of the modeling dimensions. Each user then has one or more roles depending on which team(s) they belong to.

ABAC: Attribute-Based Access Control

The allocation of authorizations via the ABAC model is handled through a set of rules based on attributes related to users, resources themselves, or the environment. This allocation is often “dynamic”, meaning that the authorization to access an application or part of an application is evaluated at the moment the user tries to access it. In practice, it is possible to set up an ABAC model that takes advantage of user’s roles, as in the RBAC model.

GraphBAC: Graph-Based Access Control

The GraphBAC or GBAC model is based on the representation of authorizations using a graph linking objects (file, user account…) through various relationships (link between collaborator and manager, belonging to a structure, possession of a file…). The authorizations are then the result of queries on this graph, which allows to give access to a resource according to its relationship with other objects.

Market vision

The table below compares in a very synthetic way the different authorization models that we have just seen.

The most common questions about authorization models

What should my empowerment model be used for?

Setting up an authorization model can be complex, costly, and time-consuming. Therefore, it is crucial to study the needs in depth and to clearly define expectations. As mentioned in the introduction, the implementation of an authorization model can help address access security issues, meet regulatory objectives, but also simplify the user experience and improve the efficiency of Identity & Access Management (IAM) processes. One of the key success factors for an authorization modeling project is the ability to express the expectations precisely, using KPIs if necessary: reducing the time required for a manager to grant accesses when an new employee joins to 15 minutes, mitigating 90% of risks considered critical, etc.

Who should I involve to build, instantiate, and keep my model alive?

Given the cross-cutting nature and scale of the transformation induced by a change or creation of an authorization model, a strong governance is necessary.

It is preferable to involve a sponsor with high visibility from the EXCOM, who will be able to provide support, and obtain strong engagement from the business, the first concerned by the changes, and from application managers, who will be heavily involved during the design and implementation phases. Key contacts can also be identified, so that they can help different teams within the organization (HR, IT, Internal Control…).

Beyond the project phase, it is also necessary to identify the actors who will be in charge of keeping the model alive. A key success factor in the implementation of an authorization model is the identification of role owners. If each role includes only authorizations from a single application, one can easily to turn to the application manager, but in most cases, each role is made up of authorizations from various applications.

The ideal is to find someone who has both knowledge of business processes, company organization, applications, and an understanding of security rules: it’s a difficult exercise! Otherwise, a small team combining the different area of expertise should be able to perform this function.

Do I have to include “fine-grained authorizations”? The “perimeters”? How granular should my model be?

The world of entitlements is as vast as the multitude of existing applications, and the use cases that an authorization model must cover are numerous.

The topic of fine-grained authorizations and perimeter management regularly comes up during the design phase: should they be included in the model or not? There is no predefined answer.

It is perfectly conceivable, in some cases, to restrict the model only to the binary access to the application (yes/no), and to leave the management of the fine-grained authorizations and perimeters in the hands of the application manager and their team. The request form may then provide a text field to provide additional information. This results in less auditability, but the management of requests is simplified.

If we decide to include the concept of perimeter, we must choose between a cross-implementation, in which we create as many roles as there are combinations between authorizations and perimeters (possibly increasing significantly the number of roles), and a separate implementation, where the authorizations are created on one hand and the perimeters on the other.

It is probably best to deal with this issue separately, even if it means creating roles combined with their perimeter in the future, depending on the real use cases: the resulting model thus has a more reasonable size.

What should I include in my model? What about physical accesses and physical assets?

Including all the authorizations within one’s model is extremely difficult, if not impossible given the wide variety of cases, and for the sake of project efficiency.

The goal of the model must always be kept in sight. For example, if the goal is to improve the user experience when requesting rights, it is better to prioritize the processing of business-oriented authorizations, which are likely to be allocated frequently, over little-used technical authorizations.

In addition, it may be tempting to include physical access (premises, specific rooms, etc.) or physical assets (badges, PCs, telephones, etc.) in its authorization model, as they are part of the means that employees must have to work, just like logical accesses.

Again, there are no major prohibitions, and some companies may well manage access to their premises within their authorization model, but as a general rule, physical access and assets are rarely part of it.

An IAM solution may however help manage them properly:

• By centralizing requests, sent to different actors or systems upon arrival of a collaborator. This “arrival package” then includes both logical accesses (accounts and default rights) as well as physical resources.
• By providing a reference source for data and events related to a person. This information, especially arrival/departure dates, is shared with badge management systems to manage the badge lifecycle.

We have just addressed four initial questions to carry out a project to overhaul an authorization model. Other questions will be detailed in a second article, to be published shortly.

Cet article Redesigning your authorization model: the key issues (1/2) est apparu en premier sur RiskInsight.

In fact, if there’s one thing you need to protect, it’s your administrators!

Whether it concerns authentication methods, third-party application permissions via APIs (allowing a third-party application to synchronize data with an external storage service, for example) or changing retention policies, an administrative action can significantly affect the data and security of the tenant on a larger scale. If it is necessary to make this point even more explicit, a Global Administrator has the ability to access all data or manage all the settings of Office 365, Windows 10, Azure AD… but also Azure!

What are the native functionalities in the Microsoft platform?

Which rights models within Microsoft 365?

To date, Microsoft 365 has two main levels of rights. These two levels schematically allow the delegation of administrative rights by adapting to different organisational models (small / medium / large, centralised / decentralised):

• Azure AD roles: Administration of Azure AD and Microsoft 365 services;
• RBAC roles: Administration of objects within services.

Level One: Using Azure AD roles to manage services

The person behind the opening of the tenant automatically takes over the role of General Administrator. He can then appoint other administrators to accompany him in his tasks. As far as possible, Global Admin’s rights should not be used in order to limit overexposure of the administration accounts. It is good practice to limit this general role to a maximum of 3-4 accounts. In addition, for almost all actions there is an equivalent service administration role (e.g. SharePoint Administrator, User Administrator, etc.).

These service administration roles are also known as Azure AD roles. Each service can be viewed as an Azure AD application. An administrator would thus be equivalent to the owner of the service in question. At the time of writing this article, Microsoft offers 59 different roles, which provides a good level of segregation of rights in most cases.

However, the default roles provide access to the entire Admin Service for the entire tenant and may in some cases provide access to the underlying data (e.g. for SharePoint Administrator, Exchange Administrator and User Administrator).

Figure 1 – Example of sensitive rights

In the case of advanced maturity, it is possible to go further in the segregation of rights by creating personalised Azure AD roles. In concrete terms, this means deciding what permissions this role has (e.g. “microsoft.directory/applications/create” allows you to create applications in Azure Active Directory).

The downside will be that it will be more complicated to audit the administration and that it will be necessary to monitor the evolution of services to ensure that permissions remain consistent with the needs of administrators.

Second level: Using the RBAC model to manage objects

Certain services such as Exchange Online, Intune, Security and Compliance Centres or Cloud App Security offer specific RBAC rights models.

As its name suggests, Role Based Access Control (RBAC), allows for the implementation of more refined permissions management; with the ability to define roles for defined perimeters (e.g. for certain user groups). For example, it will be possible to create “Helpdesk A” and “Helpdesk B” in Exchange Online to give support rights to two separate teams on a perimeter A and a perimeter B.

How to provision the accounts of administrators?

The first question is how to create an administrator’s identity. Two strategies are possible:

• The creation of an account in the organisation’s identity repository, which will then be synchronised with Azure AD (ex: wavestone.com);
• The creation of the account directly in Azure AD. This account will then be called “cloud-only” (example: wavestone.onmicrosoft.com).

Regardless of the administration role, it is recommended for a SaaS service such as Microsoft 365 that the account be located as close as possible to the administered resource. Here, this amounts to using cloud-only accounts. The objective is twofold: to protect against a possible unavailability or of a compromise of the organisation’s identity repository.

How to assign permissions?

The second question is how to assign the right privileges to the administrative roles created.

In the case of service administration

In order to assign an AAD role, it is possible to use 3 methods (via the portal or the corresponding PowerShell command):

• The Azure portal (portal.azure.com): this is the method that should be favoured, as it allows the association of rights as close as possible to the resources and the use of PIMs, which we will discuss in the rest of the article;
• The Microsoft 365 portal (admin.microsoft.com): it is possible to carry out the assignment of roles directly through the main administration portal. However, this method is not compatible with PIM;
• The use of third party IAM tools: these solutions now have connectors with Office 365 to perform identity and privilege provisioning. These solutions offer less granularity, are not compatible with PIM and are a source of common errors. For example, synchronisation is typically one-way, resulting in the administration account reappearing if it is only deleted in Azure AD.

Note that it is also now possible to assign an Azure AD role to a security group (Cloud only) via a preview feature. This may simplify certain administrative models, such as where the Unified Communications team needs the SharePoint Administrator role and Teams Administrator. However, be careful with the management of this group.

In the case of the administration of objects

For RBAC roles, the definition of roles is done directly in the administration platform of the service concerned. It is then possible to assign the role in question manually or to a security group, in the portal or via an IAM solution.

Figure 2 – Natives functionalities of the solution

How to build and implement your administration model?

What strategy to define your rights model?

The construction of a delegation model must be based on the principle of least privilege. The core of the work is to make an inventory of the cases of Office 365 administration usage and to match your teams with the available rights.

This can be an opportunity to rethink the organisation of teams dealing with the working environment. Two observations are quite significant:

• Mobile terminals and workstations are intended to be managed by unified solutions (UEM) such as Intune, Workspace One or MobileIron, and therefore by the same team.
• Security and compliance tools are increasingly integrated natively in Office 365. It is therefore necessary to break down the wall that existed between the workplace world and the security world, in order to create a team with the same ambition: to create and maintain a controlled and secure platform.

Office 365 has the particularity of bringing together a multitude of different services, such as file or information storage (SharePoint, OneDrive), communication tools (Exchange, Teams) but also security (Defender, Information Protection, etc.). It is therefore essential to group the services into categories and define a correspondence matrix between team and administration roles.

Concretely, we advise you first to use the default Azure AD roles for service administration, and then to define more granular roles with RBAC and custom roles.

It is also interesting to identify the most sensitive roles, such as those allowing access to data or security settings (for example: Global Admin, Exchange Admin, Security Administrator and Application Administration) in order to be able to adapt the security of these roles.

How to delegate administration rights on objects in a multi-entity context ?

Before talking about security in the strict sense of the word, there is another question. Although the configuration of services and security parameters can only be done centrally, local teams need to carry out support actions: creation or modification of an internal or guest account, resetting of authenticators, creation of a Microsoft 365 group or a distribution list, etc.

The service administration roles, the Azure AD roles, do not offer privilege segregation by perimeter; an Exchange Online administrator will therefore be able to handle all mailboxes. It will not be conceivable to give them in complex organisations or in regulated contexts. Several strategies are available, depending on the maturity and complexity of the organisation.

In the case of small structures, it is easiest to use the native functionalities:

• RBAC roles: RBAC Exchange and Intune roles generally provide the right level of granularity to manage objects in native portals;
• Administrative Units: Administrative Units, finally in GA since the end of September, are the equivalent of RBAC for Azure Active Directory. They take the form of containers in which an administrator can create or modify objects, which makes sense for support activities.

In the case of larger structures, good practice is not to manage objects (users, mailboxes, groups, SharePoint sites, etc.) directly in native portals. What is needed is an interface that allows all these objects to be managed, while taking into account the business logic and the target administration model. Below are three examples of interfaces:

• In-house development of a “Custom Automation Engine”: this interface will be decorrelated from the IAM and very often a large powershell / Graph API machine;
• Integration of a connector to the current IAM solution in order to present a complete management of the objects by disregarding their direct hosting;
• Investment in a SaaS Management Platform (SMP): software publishers have specialised in the creation of management tools for Office 365, combining object administration, licence management and security and operational supervision functions. Among these solutions, which are still relatively unknown, are ManageEngine, CoreView and Quadrotech.

Please note: this interface, dedicated to support teams, will be distinct from an interface open to all users allowing them to centrally create guest users, SharePoint sites, Teams, etc. In concrete terms, this second interface could be integrated with ITSM tools, SMP or even be developed based on Power Apps and Graph API.

How to protect access to these accounts ?

10 measures to secure administration accounts

Depending on the security licenses, mainly the EMS bundle, Microsoft provides a number of controls to secure administration accounts.

Most of these could also be obtained via third-party tools.

Basic measures to secure the administration account

1. A dedicated administrator account

An administrator must have an account dedicated to administration, different from the office automation account. It should be cloud-only where possible (e.g. wavestone.onmicrosoft.com).

2. Multi-Factor Authentication

Multi-factor authentication is no longer an option today, and even less so for administrators.

This measure is available for everyone, for all licences:

• Via MFA for Office 365 (also called MFA with per-person inheritance) which forces a challenge at every connection;
• Via Security Defaults which forces an additional factor to be registered for all users and imposes the MFA for administrators at each login;

It is also important to ensure that legacy authentication protocols that do not support MFA are disabled. These would allow single sign-on to be bypassed.

It will also make sense to limit the types of additional factors available; what is the point of securing administration accounts if the second factor is the administrator’s Gmail address.

Highly recommended security measures

3. Unlicensed Office 365 account

Without a licence, it will not be possible for an administrator to access the different services and data of the platform, or to have a mailbox.

Please note that some services, such as Power Apps or Power BI, require a licence to access the administration portal. In practice, it can be interesting to create a security group that allocates the necessary licences for administrators.

4. Conditional Access (with Azure AD P1)

Conditional access allows you to evaluate the context when accessing an Office 365 service and to authorise access accordingly. For example, access can be blocked depending on the type of workstation used (whether managed by the company or not), the network on which the user is connected, the application in question or the user’s administrative role.

In a Zero Trust logic, there should be no differentiation between the internal and external network, especially for administrators, but rather focus on the status of the workstation and the risk of connection.

5. Password Protection (with Azure AD P1)

Azure AD Password Protection provides controls over passwords. It will thus be possible to prohibit the use of a current password or a derivative (with a list predefined by Microsoft or maintained by the organisation).

A good practice is to apply this protection to all Cloud-only administration accounts as a minimum.

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

Azure AD Identity Protection adds a notion of risk in the evaluation of user access and behaviour. Concretely, it will be advisable to define the following policies;

• Risky users: Force password change for an administrator likely to be compromised (with a Medium or High risk);
• Risky sign-in: Forcing an MFA challenge during risky access (e.g. anonymous or unusual IP).

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

Azure AD Privileged Identity Management is a service to control the assignment and use of administrative roles:

• Allocate just-in-time rights by giving an eligible role instead of a permanent one;
• Submit role activation to third party validation;
• Set up an end date for an administrative role;
• Force recertifications of administrators.

It will be relevant to distinguish the so-called sensitive roles from the others during implementation.

The monitoring of eligible administrators allows, as a bonus, to become aware of the real use of administration rights and therefore to clean up the list of administrators more easily.

It should be noted that the PIM functionalities have recently been extended to the different groups, which makes it possible to set up “Just-in-time” for more exotic cases such as RMS / AIP Super-Users.

To go even further

8. Supervision of administrator actions to detect abnormal behaviour

Once all these security measures are in place, all that remains is for you to implement supervision to detect non-compliance with the previous rules and abnormal behaviour.

And for this, nothing better than to refer to our article on the subject to understand the available logs.

9. Setting up a Privileged Access Workstation

Administration is by definition a critical action. It must be carried out within a perimeter of trust. The provision of PAW, or administration post, will enable us to achieve this objective.

The configuration of the administration station should be simple (no local administration rights, restricted Internet browsing, blocked USB ports, pre-installed PowerShell modules, etc.). But restricting the connection of an Office 365 administrator from this workstation may cause more problems. There are several possibilities for this:

• In a modern context, a simple answer is to rely on Microsoft tools: define an administration workstation profile in Intune and assign it to the administrators. With a conditional access rule, it is possible to require a compliant workstation when connecting.
• In a more traditional model, it is possible to set up an authentication silo with administrators and associated workstations. In this way, we would have a model similar to the third-party model well known to AD teams.
• Other approaches are also possible, even if more complex: association of a certificate and a reverse proxy or even a bastion.

10. Keep up to date with good practices and news

It cannot be repeated often enough that Office 365 is a Cloud platform and is constantly evolving. Keeping up to date will continue to increase its level of security over time.

Figure 3 – The security of accounts, measures that can be counted on the fingers of one hand

Focus on glass breaking accounts

A good practice in the administration of the Microsoft platform is the setting up of administrator accounts that allow control over the platform to be regained in the event of an incident.  These are called glass-breaking accounts. These accounts should allow full control over the Office 365 tenant and are therefore assigned the role of Global Administrator.

These accounts must be secure; however, we must not forget their specificity which consists in using them in the event of an incident. Thus, the security imposed on these accounts must remain compatible with the urgent nature of their use.  These accounts must therefore comply with the following recommendations:

• To be cloud-only accounts
• No MFA configured (or at least a third party MFA)
• Storage of the password in a safe which only identified members of the security team or Office 365 can access
• Setting up alerts to check that these accounts are not used outside of an incident procedure requiring the use of glass breakage.

It is also recommended not to use a specific naming convention for these accounts, they should not catch the eye of a possible attacker!

Conclusion

Security on Office 365 is based on technical measures to protect administrator accounts, as well as the implementation of a target administration model, which includes clear governance and processes, tools to implement this delegation of rights, and mechanisms to maintain it over time.

But whatever protection measures are implemented, security rests first and foremost with the administrators of the solution. Awareness raising and controls for administrators will be essential.

Administrators must bear in mind that their accounts give access to extremely sensitive information and actions: they are therefore the preferred target of hackers!

As O365 is constantly evolving, each new feature introduced by Microsoft may also bring with it its share of security problems that need to be studied and taken into account. Take the opportunity to update your documentation: O365 risk analysis, service configuration, delegation model…always without forgetting to allow your administrators to train!

Cet article How to manage administration in Microsoft 365? est apparu en premier sur RiskInsight.

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

Quels besoins pour l’IAMoT ?

Il est possible de définir l’IAM comme une discipline permettant de « donner les bons droits, aux bonnes personnes, aux bons moments ». L’IAMoT vient ajouter une composante à cette définition pour permettre de « donner les bons droits, aux bonnes personnes et aux bons objets, aux bons moments ».

Mettre en œuvre des solutions pour permettre une gestion adaptée des identités des objets connectés se traduit donc par le besoin de prendre en compte :

• La gestion des identités des objets et de leur état (voir l’article détaillant le cycle de vie des objets) ;
• La gestion du contrôle d’accès et des habilitations :
  • des objets sur le SI et sur ses données ;
  • des objets sur les autres objets et leurs données ;
  • des employés/partenaires de l’entreprise sur l’objet et ses données ;
  • des clients finaux sur l’objet et ses données ;
• La gouvernance des identités des objets et la pertinence des droits associés dans le temps.

Tout comme pour l’IAM, pour chacun de ces domaines, il va être nécessaire de définir des processus, une organisation associée et des outils adaptés aux contraintes technologiques du projet.

La question est donc maintenant : vers quelles solutions s’orienter pour répondre à mes besoins ?

Des plates-formes IoT orientées connectivité et gestion de flotte

Le premier réflexe est de se tourner vers les services que peuvent fournir les plates-formes de gestion d’objets connectés.

En étudiant ces plates-formes plus en détail, nous avons fait le constat que leur priorité est déjà de couvrir les services essentiels pour la gestion de la flotte des objets connectés :

• gérer la connectivité multi-protocolaire des objets avec le SI de l’entreprise (SigFox, LoRa, 3/4/5G…) ;
• maîtriser l’inventaire des objets déployés et en assurer la configuration ou la mise à jour via un module de « Device Management » (LWM2M, OMA-DM, TR-069/CWMP…) ;
• permettre la remontée et la mise à disposition des données générées par l’objets (DTLS, CoAP, MQTT, AMQP…).

Ces fonctions s’accompagnent de solutions techniques d’authentification de l’objet sur les plates-formes mais celle-ci n’offrent aucune opportunité de couverture des besoins métier.

Dans ce cas, que font les acteurs traditionnels de l’IAM et du CIAM ? Puis-je me tourner vers leurs solutions qui sont aujourd’hui orientées sur la couverture des besoins des utilisateurs ?

Des marchés IAM et CIAM en mutation pour couvrir une infime partie du besoin IoT

Les éditeurs historiques de solutions IAM et CIAM ont compris l’énorme opportunité que représente l’IAMoT et orientent progressivement leurs offres et le discours associé sur ce marché. Néanmoins, nous constatons qu’ils ne couvrent encore que très partiellement les besoins identifiés ci-dessus et que selon leur capacité à innover le délai de mise en œuvre des nouveautés pourra être important.

Forts de leurs savoir-faire technologiques, ils se concentrent aujourd’hui quasi-exclusivement sur le volet contrôle d’accès. Ils offrent ainsi des solutions pertinentes pour permettre l’authentification applicative des objets sur le SI et la délivrance de jetons d’autorisation dont la gestion du contenu relève encore d’un défi propre à chaque projet. Sur les autres volets de l’IAMoT tels que la gestion de l’identité et de l’état des objets, la gestion du modèle de rôles liant objets / utilisateurs / identités internes / identités externes, ou la gouvernance des droits dans le temps, il est urgent que leur offre s’étoffe.

Dès lors, comment peut-on couvrir des besoins IAMoT bien présents malgré les lacunes du marché ?

Une hétérogénéité des usages rendant complexe la normalisation des pratiques et la standardisation des solutions

La diversité des usages et donc des modes de fonctionnement des objets connectés est évidemment à l’origine de la difficulté des éditeurs à proposer une offre générique adaptée à ses clients. Mais les projets IoT sont là et il n’est pas envisageable d’attendre que le marché prenne forme.

Mais si l’harmonisation est actuellement impossible au niveau global du marché, un effort peut être consenti au niveau de l’entreprise afin d’essayer d’harmoniser les réponses pour l’ensemble de ses usages IoT. Ainsi tout en cherchant à tirer parti de ce que propose le marché IAMoT, il est nécessaire d’envisager le développement modulaire des briques manquantes et en priorité celles ayant trait à la gestion des relations « objets / utilisateurs / identités internes / identités externes ». Attention toutefois à ne pas succomber aveuglement à l’utilisation des frameworks bas-niveau propriétaires proposés par les plates-formes IoT. Chacun devra être vigilant à conserver un niveau d’abstraction et d’autonomie suffisant pour ne pas être lié ad vitam æternam à un éditeur unique. Ce point d’attention est d’autant plus important dans un marché peu mature et en explosion où les bonnes idées se font et se défont.

Que faut-il retenir ?

Aucune solution du marché ne couvre l’intégralité des besoins fondamentaux de l’IAM of Things. Les plates-formes IoT se limitent aux fonctions de connectivité des objets, de gestion de flotte et de remontée de données. Les plates-formes IAM et CIAM n’offrent quant à elles que des réponses technologiques aux besoins d’authentification et d’autorisation.

Afin de combler les manques, chaque entreprise devra évaluer le besoin de se lancer dans le développement de ses propres modules applicatifs. Un effort tout particulier devra être entrepris pour atteindre un niveau adapté de généricité des modules pour l’ensemble de leurs usages et d’indépendance vis-à-vis des solutions éditeur.

Cet article IAM of Things, un marché émergeant mais un besoin déjà présent est apparu en premier sur RiskInsight.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Des systèmes industriels complexes à intégrer

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Connected objects bring a whole range of new perspectives for the evolution of processes and working methods for businesses and users. Indeed, they are now able to interact with their environment to exchange information or perform actions. These interactions are characterized by relationships between corporate information systems, employees, end users and even other objects. To ensure the security of such exchanges, it is absolutely necessary to implement access control mechanisms which implies knowing and managing the identities of all connected objects of a fleet as well as their users.

This identity management discipline is well known within companies and linked to the IAM field (Identity & Access Management), that means the lifecycle management of the identities of employees and partners (traditional IAM) or end clients (Customer IAM). It must now be applied to the fleets of connected objects: it is the IAM of Things (IAMoT).

Figure 1 – Traditional IAM, Customer IAM and IAMoT: three strongly related fields

A connected object, yes… but to WHAT?

The interactions between a connected object and its environment can be grouped into 3 main categories.

1 – An object connected to the company’s IS

This is the first use case that comes to mind. Each object communicates with the IS via a unique identity that represents it and is associated to its access rights. This implies the implementation of principles for the creation, referencing, management, control and piloting of theses identities. We must know the condition of an object or the identity of its owner at any time.

In a standard technological chain such as “objects – relays – IoT platform – applications”, the IoT platform offers a central point for managing all objects identities.

In this context, it is also essential to manage the authentication of objects to applications, and therefore to define the principles of creating the secrets that will be used.

Figure 2 – Standard technological chain

2 – An object used by customers

For this type of object, appears a strong relationship with the Customer IAM field. Indeed, the object must be able to verify the user’s identity against the CIAM and determine the services to which the customer has subscribed.

In case of shared usage of the same object, a role and data model involving different types of end-users must also be considered.

Let’s take the example of a connected vehicle:

• The vehicle driver wants to use the GPS service. Before granting access to the service, the vehicle must answer many questions. What is the identity of the driver and what personal profile should I use (in order to load his previous rides for instance)? Is he the owner of the vehicle, the driver of a rental car, or has he borrowed it for a one-time use? Has the driver subscribed to the GPS services from the manufacturer and what is his level of service (routes calculation only, or also alerts for danger zones)?

3 – An object in interaction with the company’s employees and partners

Last use case, each object can interact with the company’s employees, service providers or partners. The relationship with the traditional IAM domain managing the authorizations and roles of the company’s partners and employees is therefore essential.

The use cases of an object require the creation of a role model to answer the question: which rights for which populations of users on which functionalities of the object?

Let’s take again the example of a connected vehicle:

• If repairs are needed, the mechanic must be able to view the latest vehicle’s operating indicators before the breakdown for diagnostic purposes. Is this garage part of the manufacturer’s network or independent? Is the mechanic allowed to access all GPS information or only the technical indicators of the engine? Can the customer consent or at least be informed of such access to his vehicle’s data?

This example also highlights that access rights may be closely linked to a time frame (only for the duration of the repair) or to the nature of the data (privacy protection of GPS data).

IAM of Things also means processes!

All IAM experts will agree: there is no IAM without a thorough study of the lifecycle of the identities involved. Our conviction is that IAMoT must study all the processes involving the object over its entire life cycle. Indeed, throughout the life of an object, the nature of interactions with its environment is likely to evolve according to its condition. For example, a brand-new object should be associated with its main user via a pairing process that ensures a level of trust consistent with the issues at stake…

Let’s use for the last time the example of the connected vehicle:

• A person has just acquired a second-hand connected vehicle from a private owner. In the context of this resale, it is necessary for the new purchaser to ensure that all accesses to services will be properly revoked for the previous owner. The detection of the resale event must therefore trigger a process of un-pairing the former owner.

Figure 3 – Ingredients for the IAM of Things recipe

The IAM of Things, a new discipline based on mastered concepts

This article highlights the identity management issue for the IoT and underlines the existing links with other fields of the IAM. It is important to keep in mind that even if the fundamental principles of the IAM also apply to the identity of connected objects, responses adapted to each project’s context must be carefully studied.

Cet article What is IAM of Things? est apparu en premier sur RiskInsight.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Calling time on passwords

Authentication means using an agreed method to prove that someone is the person they claim to be. From the earliest times, the most widely used method has been, almost certainly, the password. However, passwords are an irritation for users and have numerous security limitations.

A collective sense of having “had enough”…

We all imagine, from time to time, not having to rack our brains for the right password when we connect to our most used applications. But it’s clear that this remains just a fantasy at present.
The promise of single sign-on is a long way from being a reality in corporate settings, and the increasing popularity of password vaults reveals something of the challenges faced by users: the multiplicity and patchy relevance of password policies, obligatory password changes, not to mention the irritation of having to reset passwords.
Having said that, the password’s main advantage remains its universal applicability and familiarity.

…but with a limited degree of security

Many cyber-attack scenarios rely, at some point or other, on a password—ideally that of a privileged account—being compromised. Various techniques are employed: high-volume combination tests (Brute Force), intercepting communications (Man in The Middle), and reconstituting passwords from their footprints (Rainbow Table).

Security measures to guard against these attacks exist (such as encryption, hashing, salting, and blocking accounts), but these are not always implemented systematically—or satisfactorily. As the saying goes, “From a corporate point of view, passwords are like nuclear waste: just bury them deep and hope they don’t leak.”

In addition to the technical weaknesses already discussed, user behavior presents a major risk: reusing the same password for different applications, passwords that are too weak or easy to guess, incrementation, etc. When a password is reused for several applications, it acts as the weakest link—thus weakening the whole chain.

Ultimately, the poor user experience and limited level of security offered by passwords are forcing companies to look for new authentication methods.

What are the options?

Authentication methods are generally divided into four categories:

What I know

These authentication methods are based on a key or code that the user knows. They represent the bulk of the solutions used today in both professional and private setting. Today’s solutions include traditional passwords, PIN codes, and secret questions. The latter, however, are rarely used, because they are either too generic (for example, “What’s your favorite color? “) or too difficult to remember.

What I own

Here, security is based on a specific piece of equipment being in the user’s possession. In particular, we are seeing the following in use:

• Smartphones

Smartphones allow—both in professional and private settings—the securing of the most sensitive operations: accessing internal company networks, confirming online payments, or carrying out non-typical banking operations.

Smartphones can be used to achieve authentication in a number of ways:

• Authentication tokens

A token often takes the form of a mini-calculator that makes it possible to generate a single-use code (OTP), with the token itself protected by a PIN code chosen by the user. Historically widely used in companies (for VPN access in particular), and occasionally in the private sphere to connect to particular customer areas, tokens are, nonetheless, giving way to smartphones, which provide a less expensive method.

• Smartcards

Smartcards contain a certificate that is used to prove the holder’s identity. A card reader is essential for this type of authentication; moreover, certificate management requires infrastructure and life-cycle-management procedures (covering issue, withdrawal, loss, etc.). Normally reserved for the corporate world, their use tends to be limited to specific groups or uses (IT administration, financial operations, etc.).

• U2F keys

This item comes in the form of a standard USB stick, but instead of storing files, it stores a unique key linked to the user. Based on a standard developed by the FIDO Alliance, the solution combines a robust level of security (including resistance to phishing attacks) with a good user experience (the keys can remain connected to one of the device’s USB ports) because a simple key press is sufficient for authentication. Note, however, that this does not involve fingerprint recognition.

• A connected object, such as a watch

This last solution—the most innovative in this category— allows users to connect via a connected object that they already own. As an authentication method it’s little used in corporate settings, but Apple, for example, offers an option to unlock a computer by simply approaching a device with another Apple connected object.

Solutions like this, based on the possession of a device, are differentiated mainly by their degree of ergonomics. In any case, it’s essential to manage “enrollment” (the linking of the object to its holder), replacement, loss, and theft of the relevant device.

Who I am

The physiological characteristics of a person, such as a fingerprint, the vein pattern of a hand, irises, faces, the signature of a voice, or even a heart rate, also make it possible to authenticate a user. The use of these solutions, for most people, is limited to opening their workstation or smartphone (via a fingerprint or face recognition). However, companies have used such solutions for a number of years to control access to rooms or highly sensitive areas.

What I do

Keystroke rhythms, mouse movements, using a phone, or touching a screen, are different ways to distinguish a legitimate user from an impostor or robot. These behavioral, biometric solutions require a large amount of data in order to be reliable, but this is improving, thanks to new Machine-Learning-based approaches. These solutions are used more as security measures that complement authentication (detecting robotic-attacks, account sharing, etc.).

As a summary, the figure below shows the different authentication solutions according to their level of security and ease of use.

User experience and security, a circle that can’t be squared?

We believe that it is possible to reconcile the user experience with security. Below we set out four possible routes to achieving it.

Route 1: simplifying the use of passwords

While it seems too fantastic to imagine the use of passwords being completely abandoned, some of their failings can be addressed. The frequency of data entry can already be reduced via identity-federation mechanisms that provide access to both corporate and partner services. In addition, chatbots are emerging to simplify the password resetting process, and are helping drive significant improvements in user experience. As for security, raising users’ awareness about the proper use of passwords is still an essential activity if risks (from social engineering, spam, phishing, password theft, etc.) are to be reduced.

Route 2: adapting the security requirements to the context

Just as you have to adapt your road speed to the weather conditions, the concept of risk can guide us in the level of security needed to authenticate a user. Thus, to access non-sensitive information, a simple password will suffice; but more sensitive operations (a bank transfer involving a significant amount, for example) will require the user to be authenticated with greater certainty, using a combination of several authentication factors. Other criteria can be taken into account to assess risk, for example the PC or smartphone being used, the geographical location, the time of connection, or even whether the user is exhibiting their habitual behavior.

Beyond the authentication phase, the level of risk can also influence the time allowed before issuing a new authentication request (no need to retype a Facebook password as long as the user stays on the same PC or smartphone, reauthentication via webmail every X days only, etc.).

In the end, then, authentication is no longer seen as an event but as a continuous process.

Route 3: let the use choose the authentication method

Rather than imposing a single authentication method on all users, Bring Your Own Token (BYOT) lets users choose the one that best suits their needs. The idea is to offer a choice of solutions with comparable levels of security.

Today, Facebook and Google offer BYOT as a second authentication factor, using a registered smartphone or secure USB key, for example.

In the world of work, this method remains less developed at present, but it’s easy to imagine such a method being offered to specific groups: those with particular work mobility requirements, the technological appetite for it, etc.

Route 4: make use of accounts that exist already

It’s more and more common for people to use their social media accounts (Facebook, Google, or LinkedIn, for example) to connect to e-commerce sites or other websites. A Social Login enables the creation of an account on the new site to be simplified, and limits the number of passwords to be remembered.

However, not all online services are designed to use a Social Login. Public or parapublic services for example, favor a State Login which allows users to log in using a tax, health, or similar identifier, and to carry out a range of online administrative activities. And these uses are in continuous development.

In conclusion

While passwords are not set to disappear completely, the search for alternatives is gathering pace: uses and technological solutions are evolving rapidly, consortia and new standards (such as OAuth2 and OIDC) are emerging, and, these days, the user experience, as well as security, is core to the thinking.

Cet article Painsswords: a look at the alternatives to passwords? 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.

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

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

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

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

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

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

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

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

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

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

Accès IT, risques métier

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

Parmi les risques les plus importants, nous retrouvons :

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

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

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

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

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

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

• Des actions frauduleuses

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

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

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

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

Plusieurs particularités à prendre en compte

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Vers une gestion unifiée des données clients

Une organisation historiquement en silos

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

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

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

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

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

Le client au centre de l’organisation

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

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

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

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

Une solution CIAM couvre 3 briques technologiques :

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

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

Mieux connaitre ses clients grâce au CIAM

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

Un CIAM pour… mieux connaitre les clients

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

Étape 1 : client anonyme

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

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

Étape 2 : client identifié

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

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

Étape 3 : client connu

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

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

Étape 4 : client fidélisé

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

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

Un CIAM pour… simplifier le parcours client

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

À l’enregistrement : faire simple, faire vite !

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

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

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

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

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

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

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

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

Un CIAM pour… créer une relation de confiance

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

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

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

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

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

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

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

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

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

En synthèse

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

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

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

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

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.

Le principal frein rencontré jusqu’ici était de voir toutes ses données externalisées. Ce frein est petit à petit en train de disparaître lorsque l’on se rend compte qu’elles le sont déjà. En effet, le système RH comme le CRM sont, pour bon nombre d’entreprises, déjà dans le cloud ! Les données critiques liées au métier de l’entreprise sont elles-mêmes déjà externalisées à travers les solutions de messagerie et autres suites collaboratives en mode SaaS. Pour quelles raisons l’IAM échapperait-il à cette révolution ?

Identity Access Management As A Service (IAMaaS) : qu’est-ce que cela représente réellement ?

Les offres d’IAM en cloud permettent de gérer et fédérer différentes ressources. Si elles sont bien utilisées, elles peuvent être un vrai accélérateur pour les métiers de l’entreprise. Mais comme tout service dans le cloud, il y a des avantages (coûts, mises à jour régulières, etc.) et des inconvénients (contrôle des données, protocoles et formats parfois non standards, etc.).

Les clients et les partenaires, tout comme les employés ou prestataires, peuvent bénéficier de la fédération d’identités. De même, des connecteurs spécifiques sont mis en œuvre pour les applications SaaS ou on-premises, utilisées par l’entreprise. Les utilisateurs peuvent se connecter via n’importe quel type de terminal. Il reste quelques incontournables pour profiter pleinement d’un IAMaaS et en garder la maîtrise : la capacité de faire des revues de comptes, la disponibilité des connecteurs de provisioning vers les applications et la maîtrise de l’envoi dans le cloud de données à caractère personnel.

Externalisation de l’IAM : penser avant tout à la maturité du SI

La capacité du SI à adopter des standards et des protocoles ouverts est un sujet clé pour réussir un déploiement d’IAM dans le cloud.

Il faut donc, après avoir choisi un premier périmètre d’application, s’assurer que ce dernier respecte les normes et bonnes pratiques en vigueur concernant l’authentification et la gestion des identités. De même l’existence d’un référentiel interne centralisé, afin de communiquer avec la solution d’IAM, sera nécessaire dans la majorité des cas.

Enfin, en prenant la problématique dans l’autre sens, c’est aussi une opportunité de fournir très rapidement aux nouveaux projets une plate-forme mâture supportant les derniers standards : fédération, authentification mobile, provisioning, etc.

Anticiper les risques : plus qu’un besoin, une nécessité

En comparaison avec des solutions on-premises, certains risques seront couverts de la même manière voire potentiellement mieux par une solution cloud : la disponibilité du système et la compromission des données. Les fournisseurs sont souvent plus mâtures que l’entreprise sur le sujet de la résilience des infrastructures et ont anticipé le cloisonnement vis-à-vis des administrateurs dès la conception du service.

D’autres risques doivent en revanche être spécifiquement adressés comme :

• Laréversibilité: il faut s’assurer qu’il est possible à tout moment de récupérer ses données dans un format exploitable et il ne faut faire aucun compromis sur l’utilisation de standards.
• L’isolation des données: cette dernière est parfois très difficile, voire impossible à contrôler ; néanmoins il est possible de s’assurer de manière contractuelle de l’isolation de ses données par rapport aux autres clients du fournisseur.
• La conformité: dans le cadre de certaines obligations (CNIL notamment) il est nécessaire de s’assurer que les données externalisées seront hébergées dans le respect de la norme (en Europe pour la CNIL). Une approche face à cela est de recourir au chiffrement des données avant envoi mais ce n’est pas forcément simple à exploiter dans une solution IAM.

Une opportunité pour moderniser son IAM

L’IAMaaS est une réelle opportunité qui permet d’offrir un service stable, standard et moderne aux différents métiers de l’entreprise.

De même, les utilisateurs étant habitués aux applications en cloud (accessibles partout, tout le temps et depuis tout terminal), la mise en place d’une fédération gérée par l’IAM en cloud et d’un portail IAM de ce type ne perturbera pas, ou très peu, leurs habitudes.

Enfin, en plus de des interfaces simples et efficaces proposées aux utilisateurs, les solutions d’IAMaaS mettent à disposition des API REST modernes, adaptés aux applications web (HTML5/Angular.js) ou aux applications mobiles, permettant à celles-ci d’interagir directement dans la gestion des identités. De quoi accompagner la transformation numérique que toute entreprise aborde aujourd’hui.

De nombreux acteurs sont aujourd’hui sur ce marché actif et l’offre fonctionnelle est très riche : Okta, Salesorce, Microsoft, Ping Identity, Memority, RSA, Cap Gemini, etc.

L’option cloud est aujourd’hui incontournable – ne serait-ce qu’en phase de cadrage IAM – et il faut désormais justifier la pertinence et le besoin de rester sur des infrastructures on-premises.

Cet article IAM dans le Cloud : est-ce le moment de se lancer ? 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.

Microsoft fait partie de ces acteurs de l’IAM pour le cloud. En raison de son rôle déterminant dans le SI « On-Premises » des entreprises, nous allons nous pencher de plus près sur sa solution : Windows Azure Active Directory (WAAD).

WAAD : une solution IAM-as-a-Service pour le cloud

Contrairement à ce que pourrait indiquer son nom, la solution Windows Azure Active Directory n’est pas un Active Directory hébergé dans Azure, la plate-forme cloud de Microsoft.

Officiellement lancée le 8 avril 2013, WAAD est décrit par Microsoft comme « une solution complète et sécurisée pour la gestion des identités et des accès dans le cloud. Elle combine des services d’annuaires principaux, une gouvernance des identités avancée, une gestion et une sécurisation des accès aux applications ».

Microsoft propose donc WAAD comme solution d’IAM-as-a-Service permettant, entre autres, de couvrir les applications hébergées dans le cloud. Contrairement à son approche « brique à brique » traditionnelle pour les services IAM On-Premises, dans laquelle chaque service est fourni par un produit spécifique, Microsoft adopte là une approche plus globale comme le démontre le tableau suivant :

Windows Azure Active Directory permet ainsi aux entreprises de :

• Étendre au cloud les identités gérées localement au sein d’un Active Directory On-Premises ;
• Gérer les identités et accès depuis le cloud, à la fois pour les applications cloud de Microsoft (Office 365, Dynamics CRM Online, Windows Intune), pour un nombre important d’applications SaaS du marché, mais également pour toute application que l’entreprise raccorde à WAAD ;
• Apporter une connexion unique (SSO) aux applications hébergées dans le cloud, voire aussi, dans certains cas, aux applications On-Premises ;
• Protéger les applications les plus critiques avec une solution d’authentification forte.

Notons que certains services proposés sont antérieurs à la date de lancement officielle puisqu’ils ont été introduits dès 2010 pour offrir les fonctionnalités de gestions des identités et des accès à Office 365. C’est ainsi que Microsoft a pu afficher les chiffres de 265 milliards d’authentifications réalisées et de 2,9 millions d’organisations clientes à la date de lancement de la solution.

Comment mettre en œuvre WAAD ?

Deux modes d’implémentation sont envisageables en fonction des usages que l’entreprise souhaite couvrir.

La première possibilité est une implémentation en stand alone, sans aucun lien avec les annuaires ou briques d’identités présentes dans le SI de l’entreprise. Cette absence de lien avec les infrastructures de l’entreprise permet de bénéficier rapidement d’une solution IAM pour le cloud. Néanmoins, cela impose de gérer spécifiquement le cycle de vie des identités (créations, modifications, suppressions), des mots de passe (initialisations, réinitialisations) et des habilitations (affectations de groupes).

La seconde possibilité consiste à « étendre les identités locales vers le cloud ». Ce type d’implémentation permet de déployer simplement des applications cloud et ce de façon transparente pour les utilisateurs. Pour cela, une synchronisation unidirectionnelle entre un Active Directory géré localement et WAAD est mise en place (via l’outil DirSync). Dès lors, les processus de gestion du cycle de vie des identités déjà en place au sein de l’entreprise se retrouvent étendus au cloud.

Et afin de permettre un accès sans couture aux utilisateurs à la fois aux applications cloud et aux applications hébergées dans le SI de l’entreprise, il est nécessaire de disposer d’une infrastructure de fédération des identités On-Premises.

Par ailleurs, il est possible d’utiliser un module d’authentification forte. Un téléphone est alors indispensable quel que soit le mode d’authentification choisi : One-Time Password par SMS, OTP par appel téléphonique ou encore notifications sur smartphone. Notons que ces fonctionnalités reposent sur la solution de l’éditeur PhoneFactor, racheté par Microsoft en octobre 2012.

Rappelons que Windows Azure Active Directory reste une solution d’IAM pour le cloud parmi d’autres. Dans un marché où des mouvements sont à prévoir dans les mois qui viennent, on peut se demander quels sont les véritables bénéfices de ces solutions, et ce qui les distingue les unes des autres. Des questions qui seront abordées dans un prochain article…

Cet article Identité dans le cloud : le marché se structure, quid de l’approche de Microsoft ? 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.

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.

Le certificat au coeur de la confiance numérique

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

Structurer une offre de services sous 3 axes

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

Les 3 règles d’or de la construction

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

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

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

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

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

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

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

La confiance a de l’avenir

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

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

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

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

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

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

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

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

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

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

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

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

Le cloud : un booster pour les projets IAM

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

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

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