The growing excitement about the advent of quantum computers is justified for a subject that is no longer science fiction but involves a new kind of threat.

Indeed, according to the predictions of numerous experts such as the Global Risk Institute, quantum computers should soon be capable of solving the mathematical problems underlying current cryptographic standards – which would consequently render obsolete the traditional systems protecting our communications, our finances and our critical infrastructures. 

For businesses, the urgent question is no longer whether this threat will become a reality, but when. How can we anticipate the operational and structural impact of this technological upheaval, while at the same time responding to the growing number of regulatory recommendations on the subject? What tools should be adopted to guarantee the confidentiality and integrity of data in the near future? It’s a major challenge, but solutions are being studied, such as post-quantum cryptography (PQC), which is already being widely adopted by the international community.

The quantum threat

Today, the security of information systems relies mainly on symmetric and asymmetric (or public key) cryptography and hash functions. These categories are represented by algorithms that are widely used today, in particular AES, RSA, ECC and SHA for hash functions. Massively adopted by the global community and natively integrated into many modern devices, these algorithms have proved their worth for decades in ensuring the confidentiality, authenticity and integrity of data exchanges.

The mathematical problems on which these standards are based are sufficiently complex to ensure that even today’s best supercomputers have no brute-force capability.   

The quantum computer is reshuffling the deck.

These machines are based on physical principles that are fundamentally different from today’s classical computers. Thanks to the phenomena of superposition and entanglement, a quantum processor can process different physical states simultaneously. What is often described as ‘quantum parallelism’ does not correspond to simple classical parallel computing (where several cores execute identical tasks), but to the ability to explore multiple execution paths simultaneously. For some algorithms, this approach can considerably reduce the search space and speed up processing.

A key question then arises: are there already algorithms capable of exploiting these quantum properties, and thus of overcoming current encryption standards?

In 1994, P. Shor, followed by L. Grover in 1996, introduced algorithms incorporating quantum computation processes to solve certain complex mathematical problems. The first allowed large numbers to be factored exponentially faster than a conventional algorithm, while the second optimised the search for an element in unordered sets. Until now, the characteristics of classical computers have made these algorithms impractical, but the emergence of quantum computers will radically change the situation, making them usable.

Indeed, the best supercomputer would take 1.02 x 10¹⁸ years (one trillion years) to break AES-128 by brute force and 10¹⁰ years (10 billion years) for RSA-2048 using today’s best methods. By comparison, a quantum computer running Grover’s algorithm could break AES-128 in 600 years, while Shor’s algorithm would overcome RSA-2048 in just 8 hours with a machine of 20 million qubits.

Faced with this threat, AES and symmetric cryptography, as well as SHA-256 and hash functions, remain viable by doubling the size of the keys used, but asymmetric cryptography needs to be rethought. With this in mind, post-quantum cryptography is emerging as the most promising solution.

What is post-quantum cryptography?

According to the ANSSI, ‘post-quantum cryptography (PQC) is a set of classical cryptographic algorithms including key establishment and digital signatures, which provide conjectured security against the quantum threat in addition to their classical security’.

This therefore refers to all the new asymmetric encryption algorithms capable of guaranteeing security against both traditional attacks and the new quantum attacks. The difference with those we use today lies essentially in the mathematical problems underlying the algorithms, chosen to remain complex to solve, even for a quantum computer.

Why is this solution considered the most promising?

PQC is not the only response being considered to the quantum threat, but it is widely regarded as the most viable solution by the international community. Several factors explain this interest, including

– Continuity with current systems, facilitating its adoption and gradual integration into conventional infrastructures.

– Advanced maturity, with standards already established and supported by the main cybersecurity authorities.

Continuity with current systems

How does this classical type of cryptography protect encrypted data against quantum attacks?

PQC does not imply a paradigm shift in our approach to securing infrastructures. As mentioned earlier, PQC is part of the family of asymmetric cryptography and therefore retains the same operation and objective as current public key algorithms. Its resistance to quantum attacks is ensured by the nature of the underlying mathematical problems, which are different from those used in conventional asymmetric cryptography. This structural difference also means that cryptography can be integrated more seamlessly into today’s digital infrastructures, ensuring a gradual transition to a future in which PQC completely and effectively supplants modern encryption standards.

Advanced maturity

The second major advantage of the PQC is its maturity compared with the other options considered. This year saw the publication of PQC standards by the US National Institute of Standards and Technology (NIST) in August 2024.

This process began in 2017 with 69 initial candidates, 4 of whom were selected to become the new PQC standards. None of the other solutions put forward to counter the coming threat, including quantum cryptography (based on the use of quantum properties as opposed to PQC, which can be implemented on conventional computers), have been the subject of a standardisation process.

Furthermore, national cybersecurity bodies such as ANSSI (France), BSI (Germany), NLNCSA (Netherlands), SFA (Sweden), NCSC (UK), NSA (USA), etc. all agree that CQP is the best way to protect against the quantum threat, and that the priority for businesses should be to migrate to CQP systems.

When and how can this technology be implemented?

The predictions of research bodies on the advent of the quantum threat are still fairly disparate, but all agree that quantum computers capable of executing the algorithms responsible for the future obsolescence of current cryptographic standards, known as Cryptographically Relevant Quantum Computer (CRQC), will render RSA-2048 obsolete, in particular, within the next 15 years. It is difficult to predict exactly when the quantum computer will be ready and will achieve sufficient performance for concrete use cases but cross-referencing the recommendations of organisations such as the NSA with the predictions of experts on the subject means that we can estimate the emergence of the first CRQCs between 2033 and 2037.

Harvest now, decrypt later

However, we do not have 10 years to arm ourselves against this threat. Data in transit today remains exposed to ‘harvest now, decrypt later’ attacks. These are attacks based on the interception and long-term storage of encrypted data, pending technological breakthroughs in decryption that will make it readable in the future.

The data targeted by this type of attack is mainly data in transit, as it is during transport that protocols such as TLS use asymmetric key pairs. It is at this point that the data is ‘quantum vulnerable’ and therefore interesting to intercept and store to decrypt it later. Data at rest, on the other hand, is generally encrypted using symmetrical algorithms, and requires to be exfiltrated to be captured, so it is not the target of these attacks.

The main risk of these attacks remains the violation of long-term data confidentiality. Depending on the sector, particularly financial or industrial, data can remain sensitive for long periods, so access to this information can have multiple serious consequences. It is reasonable to assume that attackers could currently recover a considerable quantity of encrypted data to decrypt it later. It is therefore imperative to start migrating to cryptographic systems that are resistant to quantum algorithms today.

Recommendations from organisations on preparation

CISA, the NSA and the American NIST, to name but a few, are urging companies to get ready now by drawing up a quantum roadmap, led by a dedicated project team, whose aim would be to plan and supervise the organisation’s migration to PQC.

The project framework will need to focus on 3 main areas:

1. Cryptographic inventory: the aim is to understand the organisation’s exposure to vulnerable cryptographic mechanisms. This involves identifying the technologies used in systems, network protocols, applications and programming libraries.
2. Risk analysis: this aims to prioritise the assets and processes to be secured first. The aim is to assess the criticality of the data being protected, and also to anticipate the length of time it will need to be protected. This analysis is based on the cryptographic inventory carried out upstream and enables efforts to be targeted where the impact of a quantum attack would be most critical.
3. Supplier responsibility: the transition to post-quantum cryptography also involves working closely with technology partners. Companies need to ensure that the solutions they use are crypto-agile: can current products be upgraded to systems that are resistant to the quantum threat, or will they need to be replaced to avoid obsolescence?

The migration strategy we recommend at Wavestone takes the main steps outlined by CISA, NSA and NIST, and adapts them to the operational realities of each company:

1. Strategic phase:
   • Understanding and raising awareness: Firstly, this involves training and informing all those involved (management, business teams, technical teams) about the impact of the quantum threat, the issues involved in post-quantum cryptography, and the main regulatory guidelines.
   • Risk assessment and initial inventory: Mapping of cryptographic uses (protocols, libraries, applications, etc.) and identification of sensitive data that must remain confidential over a long period. It is also at this stage that the company’s maturity is assessed and the most critical projects prioritised.
   • Framing the programme: On the basis of the risks identified, the overall roadmap (objectives, budget, organisation) is defined. A dedicated team – or ‘centre of excellence’ – is set up to steer the transition, coordinate the various projects and define the success indicators.

2. Quick wins
   • Before embarking on a more extensive transformation phase, we recommend the rapid launch of low-investment initiatives, such as including post-quantum clauses in contracts (with suppliers and partners). The aim is to obtain tangible returns, raise stakeholder awareness and create a positive momentum around the project.

3. Transition programme

• • Test of an initial use case: Selection of a representative use case to deploy the first post-quantum cryptographic algorithms or mechanisms under real conditions.
  • Detailed inventory (second iteration): We then need to refine the mapping of cryptographic components (PKI, key management, network protocols, encryption libraries, etc.) in order to plan the migration precisely.
  • Modernising ‘digital trust’: This involves updating infrastructures (PKI, certificate management, key rotation policies, etc.) and implementing procedures to accommodate new algorithms.
  • Migration and monitoring: Progressive deployment of post-quantum algorithms on critical systems, while maintaining service continuity. This phase is accompanied by controls, performance tests and security checks. Eventually, the entire IS is covered, guaranteeing continuity and regulatory compliance.

This roadmap, which is both pragmatic and in line with the recommendations of the relevant bodies, guarantees a controlled transition to post-quantum cryptography.

Hybridization mentioned in Europe as an important step in the transition

In a joint publication with its European counterparts BSI, NLNCSA, SNCSA and SFA, ANSSI also recommends that preparations for this transition should begin as soon as possible. Although the new PQC standards, including algorithms, implementation instructions and their use, were published by the NIST in August 2024, these bodies are not encouraging the immediate integration of these algorithms into companies’ cryptographic systems. The ANSSI has even announced that it ‘does not approve any direct replacement in the short or medium term’. The reason for this is ‘a lack of cryptanalytical hindsight on several security aspects’; despite its completed standardisation process, PQC is not yet considered mature enough to guarantee security on its own:

– Several algorithms that were finalists (and therefore considered promising) in the NIST standardisation process have been the subject of classic attacks that have been successful. The SIKE algorithm was defeated in 10 minutes, and Rainbow in a weekend.

– Dimensioning, integration of algorithms into communication protocols and the design of secure implementations are other aspects on which progress needs to be made, according to the ANSSI.

Consequently, unlike NIST, ANSSI and BSI, among others, recommend that organisations adopt hybrid systems. This concept consists of ‘combining post-quantum asymmetric algorithms with well-known and well-studied pre-quantum asymmetric cryptography’ (ANSSI). In this way, we can benefit from the effectiveness of current standards against classical attacks, and from the predicted resistance of PQC against quantum attacks.

Hybridization is possible for key encapsulation mechanisms and digital signatures. Each classical operation is replaced either by:

– successive execution

– parallel execution of the 2 algorithms, pre-quantum and quantum.

The second option can be implemented to reduce the loss of system performance. These hybrid schemes also require the players involved to support both types of algorithms.

This is a scheme where ‘the additional performance cost of a hybrid scheme remains low compared with the cost of the post-quantum scheme’. ANSSI believes that ‘this is a reasonable price to pay to guarantee pre-quantum security that is at least equivalent to that provided by current standardised pre-quantum algorithms’.

On the other side of the Atlantic, we are much more nuanced than our European counterparts on this issue. Although the benefits of hybridisation are recognised by the UK and US cybersecurity authorities, the NCSC and NIST insist on the temporary nature of this solution and do not impose hybridisation as a mandatory step before migrating completely to PQC. The NSA explicitly states that it has confidence in PQC standards and does not require the use of hybridisation models in national security systems. In summary, the decision to use these models must be taken taking into account:

– technical implementation constraints

– the increased complexity (two algorithms instead of one),

– the additional cost,

– the need to transition a second time in the future to a total PQC system, which can be a complex exercise in crypto-agility – i.e. the ability to modify one’s cryptographic infrastructure rapidly and without major upheaval in response to changing threats – for some companies.

Regulatory aspects

There are currently no European regulations setting out explicit requirements for post-quantum cryptography. However, some of the various texts on data encryption (NIS2, DORA, HDS, etc.) explicitly require state-of-the-art encryption to be applied.  In particular, DORA requires the constant updating of the cryptographic means used in relation to developments in cryptanalysis techniques. It is therefore possible to consider this as a first step in guiding organisations towards the concept of crypto-agility.

Despite the current lack of requirements, ANSSI is planning a post-quantum transition plan in 3 phases:

1. Phase 1 (in progress)

Effective post-quantum security through hybridisation remains optional and is considered by the agency to be defence in depth. The security approvals issued by ANSSI remain unchanged and only guarantee pre-quantum security.

2. Phase 2 (after 2025)

Quantum resistance becomes a security property. Post-quantum security criteria for PQC algorithms will have been defined by ANSSI and will be taken into account when issuing security visas.

3. Phase 3 (after 2030)

It is estimated that the post-quantum security assurance level will be equivalent to the current pre-quantum level. Hybridization will therefore become optional; security visas may be issued for companies using post-quantum schemes without hybridization.

In addition, depending on the context, ANSSI may decide to grant security visas only for long-term post-quantum security.

In the USA, NIST’s post-quantum transition plan is not definitive, but the obsolescence of RSA and ECC is already projected for 2030, followed by a total implementation ban in 2035; hence the announced target – aligned with the NSA – for completion of the migration to PQC in all federal systems in the same year. Depending on the requirements of different sectors, it may be necessary to make the transition more quickly, depending on the associated levels of risk.

Although 2035 seems a long way off, the full migration to post-quantum cryptography is a long process, and the initial phases of cryptographic inventory, data classification and risk analysis, in particular, require considerable time. It is therefore essential to start today to plan for a successful transition.

The advent of quantum computers is therefore no longer a distant hypothesis, but a certainty that will redefine the foundations of cybersecurity. While the precise timing (2033-2037) remains uncertain, the regulatory pressure from cybersecurity institutions is becoming clearer, and the impact on data confidentiality and integrity is unavoidable. Every day that goes by without adaptation increases the vulnerability of companies to future attacks.

And yet, solutions already exist: post-quantum cryptography, although not yet fully mature – especially when it comes to implementation – offers a promising response to this threat. Standardised and supported by the major international bodies, it represents the first step towards sustainable security in the quantum era.

However, adopting this technology is not simply a matter of technical deployment. It is a strategic transition, an exercise in crypto-agility, and an opportunity for businesses to assert their resilience in the face of technological upheaval.

The question is no longer whether your organisation will be ready when the first quantum computer capable of breaking RSA-2048 sees the light of day. The question is whether it will have anticipated this future, by arming itself now with the tools and plans needed to turn this constraint into a competitive advantage. The future of security starts today.

Contact us

Cet article Quantum computing and post-quantum cryptography: what strategy should companies adopt to deal with these issues? 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.

Demystification of operation 

These technologies aim to identify and extract faces from images or video streams to calculate a facial imprint, encapsulating all of their features, in order to facilitate a subsequent search and identification. 

The idea of using the face as a form of identification in systems, as well as the earliest functional systems, dates back to the early 1960s with the Woodrow Wilson Bledsoe System (1964). The Woodrow Wilson Bledsoe System was capable of recognizing faces by analyzing digitized photos. The system’s approach relied on identifying facial features such as the distance between the eyes and the width of the nose. 

The latest advancements in artificial intelligence, particularly with the advent of Machine Learning and the explosion of shared photos and videos on the internet, have allowed for rapid and widespread development of facial recognition algorithms. 

In practice, these systems will rely on the images captured by our smartphones and cameras, which consist of a grid of pixels, each carrying the values of the three colors: red, green, and blue for the respective pixel. Unlike human vision, the FR system will perceive these images in a completely digital form. The algorithm of RF will typically follow steps for processing: 

1. Capturing the image: It all begins with capturing an image containing a face. This image can come from a photo taken by a camera or be extracted from a video. 
2. Face detection: The algorithm will analyze the image to detect the presence and position of faces. To do this, it will use image processing techniques to search for patterns and characteristic features of faces, such as contours, structural elements (like eyes), and variations in brightness. 
3. Extraction of facial features from the person: Once the face is detected, the algorithm extracts specific characteristics that will allow it to distinguish it from other faces. These characteristics include intelligible elements (eye position, overall shape, etc) as well as elements intelligible only to the AI model (gradients and specific pixel arrangements). 
4. Creation of a facial imprint: Based on the extracted features, the algorithm creates a facial imprint, which is essentially a summary of the face, in a digital format understandable for the model.  
5. Comparison with the database: In order to perform identifications and searches, the obtained facial imprint can be compared with fingerprint or image databases. The matches found will generally indicate a confidence percentage, based on the calculated level of resemblance. 

Nowadays, the underlying mechanics of image processing and machine learning can offer excellent performance in terms of speed and consistency of results. However, like other automated technological services, they can be vulnerable to cyber security threats and may, in some cases, be exploited by an attacker. 

Overview of attacks and weaknesses 

The objective will not be to enumerate all potential attacks on machine learning systems, but to focus on attacks that can target RF algorithms. The main typologies are as follows: 

Adversary attacks:  
The first cracks in the armor of FR algorithms, discovered in the 2010s, involve subtly introducing very slight noise into the images sent to the system. This alteration, nearly invisible to a human, can disrupt the fine features perceived by the model and intentionally lead to errors in understanding and classification by the underlying neural network. If an attacker can alter the sent images, someone with good knowledge of the system could potentially impersonate a user. 

Example of adversary attack 

Occlusion attacks 
Since 2015, researchers have been able to put into practice attacks where occlusion of parts of the face, such as wearing glasses or masks, can deceive certain FR models. Indeed, the model may fail to detect and extract faces from captured images, or extract inconsistent features. In both cases, such attacks allow for subject anonymization. 

Examples of occlusion technique 

 
Face substitution attacks 

Like spy movies, researchers have explored face substitution attacks, using sophisticated techniques to deceive systems by presenting artificial faces that resemble real ones. These techniques can range from simple cardboard masks to custom-made silicone masks replicating a person’s face and details. These attacks have raised concerns about the reliability of facial recognition systems in real-world scenarios. 

Note that some facial recognition systems (such as Microsoft’s Windows Hello) rely on infrared cameras to ensure they are facing a genuine face. 

Procedure for creating a face for a face substitution attack 
 
 

Superposition attacks 

In some cases, simply overlaying a patch on another image can mislead FR algorithms. It is possible to calculate the image that best represents a person or object (in our case, a toaster) from the model’s perspective, and insert this element into the image we want to manipulate. The FR model will tend to focus on this area, potentially completely altering its predictions. 

Example of a superposition attack 

Illumination attacks  

By playing with the surrounding lighting, it is common to be able to alter the performance of a FA algorithm, highlighting the need to take environmental conditions into account. 

Tomorrow, a defense that is equal to the risks   

Faced with these fallible systems, a whole set of protection strategies appear, generally focusing on verifying the consistency and veracity of the images presented. A brief overview of the areas of work for the defense: 

1. Blinking: Blinking can be used as a defense mechanism to verify the authenticity of faces in real-time, as blinking is hard to reproduce and natural way on an image or video. Based on natural blink patterns, facial recognition systems can detect fraud attempts and enhance the security of biometric identification. 
2. Gait analysis: Gait analysis provides an additional layer of defense by checking the consistency between the claimed identity and the way a person walks. This method can help prevent attacks based on imposters or fakes by detecting irregularities in the way a person moves, increasing the security of facial recognition systems. 
3. Dynamic facial features: By using dynamic facial features, such as muscle movements and blinking, face alertness analysis helps distinguish real faces from fakes, preventing attacks based on pre-recorded images or videos. This technique enhances the security of biometric authentication by ensuring that the faces submitted for recognition are alive and live. 
4. Full 3D scan: Full 3D scanning captures the three-dimensional details of the face, providing a more accurate representation that is difficult to counterfeit. Using this technique, facial recognition systems can detect fraud attempts by masks or facial sculptures, enhancing the security of biometric identification. 
5. Trusted complementary biometric techniques: By combining multiple biometric modalities such as facial recognition, fingerprint, and voice recognition, facial recognition systems can benefit from multiple layers of defense. This approach enhances security by reducing the risk of recognition errors and bypass, providing more robust and reliable biometric identification. 

Conclusion 

Due to their “black box” design, AI-based systems, with more recently generative AI, are currently fallible. New types and techniques of attack are emerging, as are defence technologies. 

In the case of facial recognition, it can expose its users to obvious risks of identity theft, with a pro/personal permeability, like any biometric authentication, unlike a simple password.  

With the democratization of “deepfake” technologies, and the erosion of our trust in images, an effort to secure these systems must be ensured, commensurate with the great responsibility that can be given to them. 

Cet article The different faces of Facial Recognition: operation and attacks  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.

A privileged account is a user account that has more privileges than an ordinary user. For example, they can read and modify the security-relevant configuration of a system, perform functions that can affect many users, and so on. As such, these accounts are the favourite of attackers (with 75% of organizations having experienced a breach involving privileged access)​ and so need the maximum amount of security by a business.

This webinar focused on securing access to IT assets such as servers. However, it is important to understand that secure access is also required in many other elements (such as applications) and that there are many different types of privileged access, making security not a one size fits all solution.

Traditional security approaches used by organizations, including the traditional PASM solution, are not solely enough to secure privileged access from attackers because they do not address the 5 key questions that need answering for strong security, which are:

• How to deploy strong authentication?
• How to secure built-in superadmins?
• How to control effective permissions?​
• How to manage a large number of servers?​
• How to closely monitor operations?​

To address this issue, companies can improve the PASM solution to make it more effective at securing privileged access. This is done by:

1. Automating permissions as much as possible: Servers are numerous and change frequently which is the same for users – standardizing and automating permissions will allow them to keep up with the pace.​
2. Addressing other use cases beyond interactive administration: this involves considering other needs to avoid users bypassing the PASM.​ Such examples include scripts using admin credentials, break-glass, and DevOps / machine-to-machine.
3. Designing your account model with least privilege in mind​​: For example, designing it so that there is 1 single nominative centralised account per user​ to simplify management, although this does not propagate lateral propagation. Designing a local generic account would be the most favourable in this instance, although it is the hardest for an organisation to implement and raises the question of who is responsible for the local accounts which makes governance more complex.

Are there any risks to PASM?

There runs the risk at project phase where admins reject the PASM solution because there was insufficient change management to onboard the admins on this solution from the start. To avoid this, onboarding and training admins on the PASM solution from the beginning is critical. Additionally, difficulty to deploy and cost can be a blocker of PASM solutions to organisations. Thus, the simpler the access model, the easier the solution will be to deploy and the less time it will take, meaning costs are reduced. Lastly, an on-premise PASM solution can run the risk of being very heavy and costly in terms of architecture so defining a SaaS solution would be beneficial. Although a thorough security solution, PASM solutions alone may not be the future of security solutions with the emergence of the ZSP strategy…

Zero-standing privilege (ZSP) is an alternative security strategy that aims to replace persistent accounts and privileges with just-in-time and just-enough cases and can be applied at both the user and server level.

User level:

• Zero standing privilege: Users are eligible to a pre-approved set of privileges, but those privileges are not activated by default.​
• Just enough admin: When they need to perform an operation, they can activate the minimal privileges…​
• Just-in-time: …for the required period of time; privileges are automatically revoked then.​

ZSP applied at the user level increases the awareness of users, improves the traceability of organisations’ operations, and helps limit the fat-finger risk.

Server level:

• Zero standing privilege: Accounts do not persist on servers, or they do not have any permission.
• Just enough admin: When a user needs to access the server, an account is created on-the-fly only on the targeted server…
• Just-in-time: … only for the duration of the session.

ZSP applied at the server level avoids the compromising of an account in the case of a breach, avoids bypassing of PAM tools, and avoids gaps between theoretical and effective solutions.

Is ZSP the future of privileged access management?

ZSP is designed for the future of IT where lots of users have access to lots of changing resources and it enables efficient user of Zero Trust approaches. However, ZSP does not address all use cases (such as machine-to-machine) and it is still immature in its development, meaning solutions are different and field experience is lacking.

Subsequently, Wavestone’s optimum strategy advice is to first define your global PAM strategy, followed by a solid PASM solution to effectively secure privileged access to your servers and then considering the introduction of a bit of ZSP in the estate. For example, at the user level for high privileges or for users with occasional needs and at the server level for cloud instances

Webinar accessible here: https://www.thesasig.com/calendar/event/23-10-11-networks/

Cet article Securing privileged access: approaches to a multifaceted challenge 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.

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

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

What is CIBA?

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

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

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

What contributions?

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

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

Gains by population

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

Use case examples

The call centre

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

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

Virtual assistants

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

Conclusion

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

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

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.

Le lieu de travail et ses outils de collaboration

C’est formidable de pouvoir travailler de n’importe où, avec n’importe quel appareil et de disposer de la technologie nécessaire quand on en a besoin. Plus qu’un luxe, c’est une nécessité dans la situation actuelle de travail à distance intensifié, ou pour les organisations internationales dont les utilisateurs sont très mobiles, répartis et fluides. Alors que tant de changements se produisent pendant la crise, votre lieu de travail devrait soutenir la reconfiguration de votre entreprise en permettant au personnel, aux partenaires, aux fournisseurs de travailler avec différentes applications, différentes équipes, etc.

Le mot “lieu de travail” utilisé dans ce contexte ne se limite pas aux postes de travail et aux outils de collaboration. Il s’étend à des domaines plus larges tels que l’architecture d’entreprise, la sécurité des applications et la gestion des identités et des accès. On peut dire que nous parlons de la base informatique plus large et des capacités numériques, pour soutenir et répondre aux besoins des entreprises – le lieu de travail n’est peut-être que la partie visible de l’iceberg.

L’héritage sur l’héritage ajoute de la complexité

Du côté de l’utilisateur, dès que vous passez par plusieurs cas d’utilisation, par exemple l’accès à un système existant sur place ou à une application Software as a Service, vous êtes susceptible d’avoir besoin de plusieurs comptes et donc d’une expérience utilisateur lourde.

Du côté de l’exploitation informatique, c’est également un fardeau de la faire fonctionner : les postes de travail sont encore la plupart du temps un dispositif physique lié à un domaine rigide de l’entreprise ; ils doivent être configurés, puis expédiés au personnel distant ou à des parties externes, et les comptes doivent encore être approvisionnés dans des environnements cibles, avec des droits d’accès définis de manière appropriée. Tous les éléments ci-dessus sont généralement des processus différents qui se répètent pour chaque fournisseur ou partenaire, ce qui entraîne autant de dispositifs et de configurations.

Plus important encore, dans quelle mesure cette situation désorganisée et chevauchante est-elle sûre ? Avoir une visibilité et un contrôle sur qui a accès à quoi, de bout en bout et pour tous les environnements, est un défi en raison des cas d’utilisation cloisonnés. Et à mesure que les utilisateurs rejoignent et quittent l’entreprise, que les applications évoluent, le niveau de sécurité diminue probablement en raison du manque de précision des comptes et des droits.

D’après notre expérience chez Wavestone, tous ces défis découlent de l’accumulation de nouveaux cas d’utilisation et de nouvelles technologies, mis en œuvre en silo, pour leur propre usage ou pour un groupe limité de cas d’utilisation. La plateforme, qui a d’abord été conçue pour une utilisation principale, s’est maintenant transformée en une plateforme à utilisations multiples avec un modèle et des processus mal adaptés. De nombreuses organisations peuvent aujourd’hui être fières de pouvoir compter sur une plate-forme fédérée et une expérience d’accès moderne pour les applications en nuage d’un côté – et sur une expérience différente, mais raisonnablement bonne, du côté des applications internes. Cependant, souvent, les deux ne sont pas intégrés et ne bénéficient donc pas des avantages que nous avons décrits dans l’introduction. Nous pensons que cela est dû à l’absence d’un modèle/architecture véritablement partagé pour soutenir une expérience moderne, dans tous les cas d’utilisation.

Figure 1 – Exemple de modèle d’entreprise dans lequel chaque entité gère séparément les identités et leur accès : duplication des processus

Un modèle pour une expérience de rationalisation

Pour cette raison et pour l’avenir de l’expérience utilisateur, chez Wavestone, nous croyons en un modèle basé sur la ou les Tours de Contrôle d’Identité.

Une tour de contrôle d’identité est une plate-forme permettant de faire respecter vos politiques d’accès. Son but est de vérifier les demandes d’accès provenant de sources d’identité fiables et de déterminer si cette identité est autorisée à accéder à une ressource numérique cible. Pour reprendre la métaphore, un pilote désireux d’obtenir une autorisation de décollage soumettra son plan de vol en utilisant un canal de confiance, et après son approbation et d’autres vérifications par les contrôleurs, le pilote pourra procéder au décollage. Si nous devions transposer cette métaphore en numérique, nous parlerions d’un utilisateur : pour que ledit utilisateur puisse accéder à la plate-forme X, il devrait utiliser un processus d’entreprise qui est lui-même fiable par une tour de contrôle d’identité. Cet utilisateur fournit son “plan d’accès” (par exemple, un jeton de session) à la tour de contrôle d’identité. Après que la tour de contrôle d’identité a vérifié l’authenticité du “plan d’accès” par rapport à ses politiques d’accès, elle effectuera d’autres vérifications de contexte, telles que : l’heure de la demande, le lieu d’origine de l’accès, le niveau de confiance du dispositif, etc. Si ces vérifications mettent en évidence quelque chose d’inhabituel ou d’incohérent dans l’authentification de l’utilisateur, des demandes supplémentaires peuvent être faites pour permettre à l’utilisateur d’entrer (ré-authentification ou renforcement).

La tour de contrôle d’identité est sous votre contrôle et détient les conditions d’accès, c’est-à-dire les politiques d’accès et accepte les utilisateurs de sources spécifiques grâce à une relation de confiance préétablie entre les organisations.

Par exemple, dans le schéma ci-dessous, imaginez une situation dans laquelle un fournisseur développe un nouveau service dans votre environnement en nuage. Les utilisateurs du fournisseur conserveraient leur dispositif et le processus d’authentification qu’ils utilisent dans leur environnement d’entreprise, tandis que la tour de contrôle d’identité (TIC) imposerait un contrôle d’accès à l’environnement en nuage – sans avoir à utiliser et à gérer un compte différent et à se ré-authentifier. Pour les environnements avec des privilèges très granulaires comme AWS, construire une TIC découplée n’est peut-être pas une approche réaliste et la TIC est alors probablement la plateforme d’identité d’Amazon qui est gérée par votre organisation et liée au fournisseur d’identité du fournisseur. Le modèle de la tour de contrôle d’identité est essentiellement une extension de la fédération, mise en œuvre pour couvrir tous les cas d’utilisation.

Figure 2 – Accès d’un utilisateur partenaire à une ressource du fournisseur de services dans le nuage via une tour de contrôle d’identité

Dans un autre scénario, comme le montre ce schéma, considérons un candidat qui postule à un emploi dans votre organisation, grâce à un portail de recrutement que vous proposez. Il déposerait une candidature sur votre portail en utilisant son identité numérique soutenue par le gouvernement, et une fois qu’il aurait donné son accord pour accéder à son profil LinkedIn, vous pourriez obtenir un CV numérique. Pour le candidat, il suffit de montrer sa pièce d’identité et de donner une copie de son CV, plutôt que de remplir le(s) formulaire(s) d’inscription en demandant une nouvelle fois les mêmes informations d’identité standard et en risquant de faire une faute de frappe dans ses coordonnées – ou même de devoir envoyer des copies de documents sensibles comme son passeport.

Figure 3 – Un scénario alternatif présentant la relation de confiance entre une plateforme d’identification gouvernementale et l’entreprise

Un modèle, trois piliers clés

Forts de nos connaissances et de notre expérience, nous pensons que ce modèle devrait reposer sur trois piliers clés : une identité unique dans tous les systèmes, un modèle commun et flexible d’accès à l’information et l’établissement d’une relation de confiance à 360°.

Une Architecture d’Identité Unique : elle est réalisée en suivant une règle simple : ne pas dupliquer les données d’identité. Moins vous créez de fiches d’identité pour une même personne physique, plus l’expérience numérique sera simplifiée – car des étapes lourdes commencent à apparaître lorsqu’un compte, un dispositif ou une action d’authentification supplémentaire est nécessaire pour que l’utilisateur accède à la ressource cible. La clé d’une donnée d’identité unique est d’essayer de réutiliser les données de sa source (qui fait autorité) au lieu de les dupliquer/copier dans vos propres systèmes. Par exemple, les fournisseurs ou partenaires travaillant avec votre organisation ont probablement déjà des identités numériques professionnelles pour leur propre usage informatique – quelles seraient les conditions pour les exploiter au lieu de les recréer ?  Les deux piliers suivants contribuent à répondre à cette question.

Un modèle commun et flexible : Le deuxième pilier consiste à utiliser un modèle commun et flexible pour permettre/restreindre l’accès à l’information. Pour assurer la flexibilité, un modèle de contrôle d’accès basé sur les attributs (ABAC) permet des règles granulaires et est bien adapté à une approche adaptative et basée sur les risques. Pour que cela fonctionne, il est toutefois essentiel de définir la “grammaire” du modèle d’autorisation : quels sont les attributs réels utilisés pour fournir des accès qui ont un sens au niveau de l’entreprise ? Comment se traduisent-ils en “privilèges” ? Quels sont leurs formats/valeurs ? Lorsque la tour de contrôle d’identité est fournie par un fournisseur de cloud (par exemple, par un fournisseur de cloud comme Azure ou AWS), la grammaire est souvent déterminée par ledit service. En outre, pour que ce modèle soit le plus répandu possible dans les cas d’utilisation, tant du côté de la source d’identité que de la fourniture d’accès du côté du service cible, nous recommandons de mettre en œuvre votre plate-forme en suivant les normes du marché afin de maximiser l’interopérabilité (SAML, OpenID Connect, OAuth, FIDO, etc.).

Une relation de confiance à 360° : Enfin, le dernier pilier consiste à assurer l’établissement d’une relation de confiance à 360°. En d’autres termes, il faut faire preuve de diligence raisonnable et établir des seuils de confiance pour accepter l’interconnexion (“confiance technique”) des plateformes d’identité. La diligence raisonnable doit s’étendre à tous les processus en amont qui permettent d’alimenter la plateforme en identités, par exemple les processus RH/achats pour vérifier les identités, jusqu’au processus d’intégration informatique lui-même – parce que la confiance dans une plateforme d’identité est une première étape pour que ces identités puissent accéder à vos ressources numériques, vous devez être dans la tolérance du risque qu’elle comporte. Cette relation de confiance doit ensuite être mise en œuvre par le biais des attentes en matière de niveau de sécurité, de l’auditabilité des clauses contractuelles, et être appliquée par le biais de la gouvernance de la gestion des services des fournisseurs. Avec des exigences aussi strictes, une organisation doit être prête à intégrer temporairement des fournisseurs ou des partenaires au sein de sa propre plate-forme, pendant que les fournisseurs ou partenaires remettent leurs processus et plates-formes en conformité.

Deux facteurs clés de succès

Afin de mettre en œuvre ces trois piliers clés, Wavestone a identifié deux facteurs clés de succès : être parrainé par un niveau de gestion approprié et renforcer la résilience et la protection de la vie privée dès la conception. Un programme de transformation visant à établir ce modèle aurait des implications et des exigences dans plusieurs départements de votre organisation (RH, approvisionnement, juridique, informatique, risques, sécurité, etc.), et devrait donc être parrainé par la direction générale et mené avec une approche panorganisationnelle.

En outre, comme toujours, la plateforme de support doit être conçue et construite en tenant compte dès le départ des questions de sécurité, de confidentialité et de résilience.

Réflexions finales

Comme vous avez pu le comprendre tout au long de cet article, il est essentiel d’examiner l’expérience de l’utilisateur de bout en bout et d’un cas d’utilisation à l’autre pour vraiment rationaliser les services numériques. Cela peut être réalisé grâce à un changement d’organisation pour imposer une identité unique à tous les systèmes, un modèle commun et flexible d’accès à l’information et l’établissement d’une relation de confiance à 360° avec les tiers.

Pour aller plus loin dans votre réflexion sur le sujet et comprendre l’état actuel de votre organisation, réfléchissez à ces questions et essayez d’y répondre : en choisissant des utilisateurs de différents services, à quoi ressemble l’expérience numérique quotidienne typique ? Combien de temps faut-il à mon organisation pour embarquer des sous-traitants et des tiers ? Comment mon organisation donne-t-elle effectivement accès à ses données et ressources aux utilisateurs externes ? Combien d’identités doubles existe-t-il dans mon parc informatique ? 

Cet article Les facteurs clés pour créer une expérience utilisateur transparente et sécurisée est apparu en premier sur RiskInsight.

DIFFERENT STRATEGIES TO safeguard AGAINST DEEPFAKES

Concurrently with the legal framework, public and private organisations get organised to put forward solutions allowing to detect and prevent the malicious spread of deepfakes. We can distinguish four strategies to safeguard against deepfakes.

1/ Detecting the imperfections

Detecting the deepfakes by their imperfections is one of the main existing methods. Some irregularities remain in the generated contents, such as the lack of blinks and of synchronisation between the lips and the voice, distortions of the face and accessories (arms of the glasses), or the inaccuracy of the context (weather, location).

The deepfakes are however built to learn from their mistakes and generate a content that is increasingly alike the original, making the imperfections less perceptible. The tools using this deepfake detection strategy can be effective but require a constant improvement to detect ever more subtle anomalies.

We can cite in this category Assembler, a tool intended for journalists developed by Jigsaw (branch of Alphabet, parent company of Google). It enables to verify the authenticity of contents through their analysis via five detectors, amongst which the detection of anomalies of patterns and colours, of copied and pasted areas, and of known characteristics of deepfakes algorithms.

2/ Screening and comparative analysis

Comparing the contents with a database of authentic content or by looking for similar content on search engines to see whether they have been manipulated (for instance, by finding the same video with a different face) is another strategy allowing to pre-empt deepfakes.

In 2020, the AI Foundation should make available a plugin, Reality Defender, to integrate to web browsers and over time to social networks. It will allow the detection of manipulations of contents, targeting first the politicians. Users will be led to adjust the sensitivity of this tool, according to the manipulations they will want to detect or not, not to be notified for every manipulation of content, notably for the most ordinary manipulations (photo retouch on a web page done on Photoshop for example).

3/ Watermarking

A third method consists in marking the contents with a watermark, or digital tattoo, to facilitate the authentication process by filling in their source and following the manipulations undertaken on these contents.

A team from the New York University works on a research project to create a camera embedding a watermarking technology meant to mark the photographed contents, in order not only to authenticate the original photography, but also to mark and follow all the manipulations carried out on it throughout its lifecycle.

4/ Involving the human factor

Involving the users in the detection process allows both mitigating deepfakes’ impacts by making them realise that the alteration of the acceded contents is possible, and to reduce deepfakes’ occurrence by allowing them to report the ones they suspect.

The plugin Reality Defender already mentioned will give users the possibility to report the contents they judge as fake so as to inform the other users – which once added to the analysis realised by the tool, will be able to see if the contents have been reported by other users, offering a second level of indication.

Some initiatives carried by cooperation of cross-sector actors combine these four strategies for a maximal efficiency against deepfakes. Some are already used or tested by journalists. It is the case of InVID, initiative developed within the scope of the European Union Horizon 2020 program of financing of research and innovation, used by the French press agency (AFP).

Solutions and strategies are therefore emerging, the market is developing, and new innovative solutions should appear very shortly with the results of the Deepfake Detection Challenge. This contest anti-deepfake was launched by Facebook upon the approach of the American presidential election, and more than 2,600 teams signed up. Results the 22^nd of April!

Below a table presenting examples of initiatives combining different strategies to safeguard against deepfakes.

Different means to protect one’s activity

The risk deepfakes present for businesses is genuine, and a few actions can be taken to protect one’s activity and mitigate its impacts from now on.

• Estimating the exposure: The use cases of deepfakes and the worst-case scenario of their use must be determined on the perimeters of the company, taking the fraud and undermining risks into consideration, and identifying the appropriate security strategies.

• Raising awareness: The collaborators must be made aware of the detection of deepfakes (to avoid the cases of fraud) but also of the limitation of shared contents on social media that can be reused to create deepfakes (to avoid the undermining). Just like anti-phishing campaigns, this awareness campaign focuses both on the detection of technical faults (form) of the deepfakes (although they will be led to disappear with the improvement of techniques), but mostly on the detection of the suspicious nature of information (content), encouraging the audience’s suspicion, cross checking of information and notification of the suspicions to the appropriate teams (what to do if I see a suspect video of my head of communications on the social networks during the weekend? What to do if I receive a vocal message of my chief asking me to execute a punctual operation that is slightly out of my perimeter?).

• Adapting the verification processes: The existing anti-fraud plans can be redesigned to be applied to deepfakes. For instance, for a Fake President fraud via deepfakes, one of the recommendations is to suggest to the interlocutor to hang up and call him back (if possible on a known number, and after an internal check). For the most sensitive fraud scenarios, these reaction processes must be finely defined, and the concerned collaborators regularly trained to the reflexes to adopt. Tools such as the ones defined earlier can also be used to verify all or any part of the media used by the collaborators.

• Protect the contents: The contents representing collaborators shared internally or externally by the company can be controlled to avoid them being reused to generate deepfakes. Businesses can limit the diversity (angle of the people and types of media) of the data potentially usable by malicious actors, and play on the digital quality (definition) of the shared contents. In fact, the more the malicious actors benefit from diverse and good quality contents representing the collaborators, the more it facilitates their reuse to generate deepfakes. Moreover, businesses can limit their means of communication to an official channel, verified social networks and their official websites – which creates contents’ consumer habits for the audience, that will be suspicious of all diffusion out of these habits.

• Anticipate the crises: The communications requirements in the case of a proven incident linked to deepfakes must be anticipated, and the management of the deepfake case must include the “generic” communications scenarios addressed in the crisis communication plans.

Cet article Deep dive into deepfake – How to face increasingly believable fake news? (2/2) est apparu en premier sur RiskInsight.

The recent events linked to the COVID-19 outbreak have proven the necessity of acceding to reliable and true news for all the society. More than the epidemic, we have witnessed an « infodemic », rapid spread of false or misleading information on the social networks, raising the question of the trust given to the platforms relaying the news and of the authenticity of the information they pass on.

The use of deepfakes is a topical phenomenon affecting firstly the general public. It is inherently linked to the importance gained by the social and online media in our daily life.

In September 2019, we counted near 15,000 deepfake videos online, twice more than in December 2018. If 96% of these videos were pornographic deepfakes posted on specialised websites, the extent of the affected topics has however increased to reach all the famous social networks (YouTube, Vimeo, Dailymotion).  Amongst the deepfakes posted on YouTube, 20% already represented politicians, business owners and journalists[1]. Their disinformation power on the general public allows them to influence major political and societal events from the moment they star famous personalities.

Deepfakes keep getting better, while the tools to generate them become more accessible (such as Lyrebird, for the audio deepfakes, Zao, for face-swapping, and the most recent one, Avatarify, integrated to Zoom and Skype, for the video). Their harmful power weighs more and more not only on public actors and organisations, but also on private ones, and must be taken into account in every business sector.

A RISK WORTH CONSIDERING FOR BUSINESSES

Deepfakes can also be used against businesses. They offer a new playground for malicious actors, particularly through two means of action:

• The improvement of Fake president frauds, whose impacts and probability are increased by deepfakes. The fraud becomes more credible thanks to photos, videos and audios copying the person who is impersonated. The targeted collaborators therefore consider these contents as an authentication in itself of the interlocutor, and the chances of successful attacks are increased – which is an incentive to ask for larger sums. Besides, the tools to generate deepfakes being accessible to the large public, the use of these frauds by malicious people increases.
• The undermining of the business through relayed false information can strongly damage its image, leading to a certain number of consequences, notably financial and legal. We can wonder what would be the impacts of an ExCom member’s video speech sharing fake results or strategic orientations on the price of his firm’s share or on the trust of its prospects; or those of the disclosure of a product anomaly on the direct order intake. Moreover, denying the rumours is harder when deepfakes are used. Today, many businesses still feel afar from the subject: How many have already wondered what would the impacts of a deepfake be on their activities?

A legal framework IN PROGRESS

The states start putting together an answer to the deepfake concern and legislating to regulate their diffusion. Some countries such as China criminalise the diffusion of deepfakes without notifying the audience about it (since the 1^st of January 2020). In the United States, the treatment of the deepfakes’ question is speeding up as the presidential election of November 2020 approaches, and it is dealt with both at the federal level (bills prohibiting the diffusion of deepfakes in California, Virginia and Texas) and at the national one (the DEEPFAKE Accountability Act[2]  is being discussed by the Congress to “combat the spread of disinformation through restrictions on deep-fake video alteration technology”). In France, the question of deepfakes is included in the law of the 22^nd of December 2019, related to the fight against the manipulation of information – and is therefore not dealt with specifically.

These legal frameworks remain dawning and heterogeneous, and only represent one part of the answer to provide to this technology. More than condemning their malicious use, the issue is mostly to be able to detect and avoid them.

In this first part, we have given an overview of the risks presented by deepfakes for the businesses. In the second part of the article, we will focus on the technical and organisational means available today to safeguard oneself.

[1] Study published by Deeptrace in September 2019.

[2] Defending Each and Every Person from False Appearances by Keeping Exploitation Subject to Accountability Act.

Cet article Deep dive into deepfake – How to face increasingly believable fake news? (1/2) 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.

UMA2.0 : an extension of OAuth2

Before taking the shovel and digging deeper, remember that UMA2.0 was actually designed as a new grant type of OAuth2 and not as a new protocol. If you already know OAuth 2.0, then you can understand UMA2 in less than 10 minutes. I promise.

Here’s the UMA2.0 grant type in one typical flow:

1. The client initiates a request against the resource without a token
2. The resource server requests a permission ticket from AS by sending it the requested resource details (requested scopes and resource registered id)
3. The resource server sends back an error response including the AS location and a permission ticket
4. The client optionally requests a Requesting Party Token (RPT, see it as UMA’s custom form of an access token) directly against the authorization server’s token endpoint using the permission ticket.
5. The client redirects the user agent to the authorization endpoint on the Authorization Server to request a token and the authorization server interacts with the requesting party to gather whatever is needed to take an authorization decision (authentication, attribute gathering, etc.) (wait, this sounds familiar)
6. The authorization server redirects the user-agent to the client redirection URI including an updated permission ticket (I know this…)
7. The client requests a requesting party token against the authorization server’s token endpoint using the updated permission ticket (I definitely remember now…)
8. The authorization servers responds with the RPT and a PCT (Persisted Claims Token, details follow) (so one ephemeral code against two tokens, mmh, been there…)
9. The client requests the resource server with the RPT (UMA2 actually recommends to conform to plain OAuth2 practice like RFC 6750 Bearer Token usage or PoP)
10. The resource server optinnaly requests the Authorization server to validate the RPT (using the OAuth2 introspection endpoint) (following RFC 7662 Token Introspection extended by UMA2) or can do that locally depending on the token’s format.

Do you see the authorization code flow? Let me highlight it to you:

Yes, steps 5 to 8 are VERY much like the OAuth2 authorization code grant.

If you agree to the following approximations, there are really no other major differences:

• Access Token (AT) becomes Requesting Party Token (RPT) (one with customized token introspection results)
• Refresh Token (RT) has now a companion Persisted Claims Token (PCT) (which is really a specialization of the refresh token class)
• Authorization code becomes (a kind of mutable) Permission ticket

So yes it is not the same. Yes there are some steps before the highlighted part and it is a tiny bit longer.

UMA2.0 : much more than OAuth2

Now User-Managed Access has been designed for a reason. And that reason is not to just rename a few OAuth2 artifacts. There are some differences that enable UMA2.0 to work beyond OAuth2 standard capabilities.

Let’s have a closer look at the differences:

• Step 1-3 : The client can get information in a standardized manner about the way to obtain a token (specifically the Authorization Server location) by contacting the resource with a token-less request while if following OAuth2 RFC 6750, no information should be given back by the resource (insufficient scope might be returned only if a token was provided)
• Step 4 : The client can try to get a token without starting a dance involving the user-agent. Maybe there’s no user authorization or consent to gather or maybe a previously delivered token (the PCT) was sufficient to get a new token. If this call is successful, you go straight to step 9 and this can actually be compared to the OAuth2 assertion flow (RFC 7523 JSON Web Token Profile)
• Step 5 : Only if required the end user is bothered to interact with the Authorization Server through the user-agent, to authenticate, gather claims about himself, consent, etc. while in OAuth2, the user-agent is solicited even if no user interaction is required and that can damage user experience
• Step 8 : an additional PCT can be handed over to the client in order to ease subsequent RPT deliveries for the same requesting party but for a different target resource (whereas a refresh token would only refresh an RPT for a given requesting party and target resource)
• Before step 1, a resource can register endpoints against an authorization server in a standard manner following Federated Authorization for UMA2.0 (but that could be covered in another article)

What the UMA2 standard achieves (and is actually designed for) is the separation of the requesting party and the resource owner (where OAuth2 considers them to be only one person). And this differentiation allows us to address more use-cases than OAuth2 allows by default:

• A document owner can share it with other people; for example, a patient can share (different) medical data with his/her spouse, relatives or doctor
• An application owner can design rules allowing certain enterprise employees (or business partners) to access an application/API
• A resource owner can aggregate the management of resource sharing under a single authorization server, even if the resources live in many domains
• An application can get additional permissions and upgrade the access token scopes without involving the user-agent in an OAuth2 dance if the authorization policies allows it
• All the above permissions can be granted asynchronously (whereas OAuth2 user consent is only synchronous within the token request flow)

Special thanks to Eve Maler for her insight while writing this article.

Cet article Demystifying UMA2.0 est apparu en premier sur RiskInsight.

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

Chapitre 1 : la promesse

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

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

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

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

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

Une solution pratique et simple à utiliser

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

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

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

Étape 1 – Accès initial au service

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

Étape 2 – Authentification

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

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

Étape 3a – Recueil du consentement

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

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

Étape 3b – Gestion fine du consentement

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

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

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

Un avantage concurrentiel pour les entreprises

Simplifier le processus de création

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

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

Faciliter l’accès aux services

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

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

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

Personnaliser l’expérience utilisateur

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

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

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

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

Ils l’ont adopté… ou pas encore

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

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

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

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

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

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

Du rêve à la réalité

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

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

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

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

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

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.

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

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

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

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

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

La fraude en ligne : quelle stratégie adopter ?

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

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

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

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

Comment traiter les contextes suspects ?

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

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

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

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

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

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

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

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

Un capteur biométrique aux usages multiples

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

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

Performances et limites de Touch ID

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

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

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

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

Des évolutions dans le futur ?

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

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

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

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

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

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

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

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

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

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

L’approche par les risques

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

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

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

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

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

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

L’approche par la justification et la prise de conscience

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

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

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

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

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

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

L’approche en amélioration douce

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

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

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

Cet article Identity and Acces Governance : tour d’horizon des approches projet est apparu en premier sur RiskInsight.

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

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

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

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

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

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

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

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

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

Dans quels contextes l’IAG est-elle pertinente ?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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.

Des tentatives infructueuses

La carte d’identité nationale électronique sécurisée est un projet d’identité numérique français datant de 2003. Cette carte d’identité devait contenir des informations biométriques. Ces données devaient également être conservées dans un fichier centralisé, solution perçue comme une atteinte aux libertés individuelles par nombre d’associations. Le projet a été arrêté puis relancé à de nombreuses reprises jusqu’en 2012. Le Conseil constitutionnel donna alors un coup d’arrêt définitif au projet en le censurant.

En parallèle, certains citoyens français ont pu expérimenter l’utilisation d’un certificat électronique « pour un usage unique » dans le cadre de leur déclaration d’impôts en ligne. L’expérimentation a finalement été abandonnée en raison de processus jugés trop complexes pour les utilisateurs (notamment lors d’un changement d’ordinateur) et trop coûteux pour le fournisseur (notamment en matière de support aux utilisateurs).

En 2010, un nouveau projet d’identité numérique, baptisé IDéNum est lancé. Deux ans plus tard, peu d’avancées concrètes à constater, sans qu’aucune raison officielle ne soit donnée.

L’échec des précédents projets gouvernementaux n’a cependant pas découragé les initiatives privées. Ainsi, La Poste propose un service de courrier recommandé en ligne, via une identité numérique baptisée « IDN ». Les informations personnelles sont vérifiées via plusieurs mécanismes, notamment la présentation d’une pièce d’identité à domicile à un facteur. Son utilisation reste cependant limitée à cet usage très ciblé.

2013 : un nouvel envol ?

Le gouvernement tente de relancer le projet IDéNum depuis début 2013. Le projet, financé par un partenariat public-privé, doit permettre de « préserver notre souveraineté nationale face aux alternatives étrangères et non sécurisées ».

Le projet adopte une approche innovante : garantir la fiabilité des Identités émises sans imposer l’État comme autorité de confiance. Ainsi, IDéNum devrait proposer un ou plusieurs « labels » reprenant des critères de qualité, de confidentialité, d’interopérabilité ou encore de contrôle fixés par l’État. Charge aux fournisseurs d’Identités privés de répondre à ces critères pour être labélisés et ainsi pouvoir émettre des Identités numériques fiables et reconnues.

Cette identité numérique devrait permettre d’accéder aux services administratifs de l’État, et plus largement à n’importe quel service privé qui y aura souscrit. C’est donc bien le « label » qui porte le niveau de fiabilité associé à l’identité numérique. D’où, peut-être, la possibilité de promouvoir plusieurs labels, correspondant à des critères de qualité différents, et adaptés à différents usages. Le « label » devrait aussi définir les « droits et devoirs » des fournisseurs de services souhaitant utiliser IDéNum. Ainsi, il permettrait d’encadrer l’usage et la diffusion des données recueillies.

Caractère universel, maîtrise de ses informations personnelles et fiabilité : 3 conditions de succès

Quels que soient les choix retenus, trois points cristallisent la relation à l’objet « identité numérique », et donc son futur niveau d’adoption : le caractère universel de son usage, la confiance de l’utilisateur dans le système – matérialisée par la maîtrise de ses informations personnelles -, et la confiance des fournisseurs de services utilisant ce même système, matérialisée par la fiabilité des informations.

Le caractère quasi universel d’une identité numérique – c’est-à-dire la possibilité de l’utiliser pour tout, tout le temps sans limite ni contrainte – est une condition sine qua non à une adoption de masse. Aussi, la question de l’interopérabilité, avec fournisseurs de services et entre pays, est primordiale. Le projet se doit donc d’emporter l’adhésion de nombreux acteurs publics comme privés. Pour cela il doit notamment offrir une prise en main et une utilisation des plus simples, pour les utilisateurs et également pour les fournisseurs de services. Par ailleurs, les initiatives de chaque pays européen doivent être compatibles et offrir un unique standard d’interopérabilité. En 2012, la Commission européenne a d’ailleurs publié un projet de règlement visant à définir un cadre européen pour l’identité numérique.

De plus, les utilisateurs doivent avoir confiance dans la maîtrise de leurs informations personnelles. La multiplication des comptes en ligne a conduit les internautes à diffuser massivement des informations personnelles, qui sont parfois monnayées à des tiers. L’identité numérique, qui fournit des informations qualifiées, ne doit pas devenir une source d’information à tout-va. L’utilisateur devra pouvoir choisir quelles informations il souhaite communiquer en fonction du service accédé et donc contrôler la diffusion de ses informations personnelles.

Aujourd’hui, un site de poker en ligne qui souhaite vérifier que vous êtes majeur vous demande de fournir une photocopie de votre carte d’identité. Cette dernière contient bien plus d’informations que la simple réponse à la question « Êtes-vous majeur ? ». Une identité numérique pourrait autoriser une granularité bien plus fine dans la diffusion des informations personnelles. De la même manière, un site de vente en ligne a besoin de connaître votre adresse postale, mais non votre date de naissance ou votre statut marital. Autre point d’attention : les adhérences entre les sphères privées, publiques ou professionnelles. Un fournisseur de services (par exemple de la sphère professionnelle) ne devrait a priori pas avoir connaissance des autres usages associés à une identité. L’identité numérique doit donc garantir souplesse, transparence et confidentialité sur les informations diffusées.

Enfin, l’adoption par les fournisseurs de services passe par un niveau de confiance élevé dans la fiabilité des informations recueillies. Par exemple, pour les services les plus critiques, permettre d’interroger le fournisseur d’Identités numériques pour garantir la validité de l’information fournie. À l’instar des cartes d’Identité physique, le vol ou la falsification seront autant de menaces pesant sur l’identité numérique. D’où la nécessité de définir un cadre légal, autant pour protéger les utilisateurs que les fournisseurs de services.

Alors, l’identité numérique, un levier pour de nouveaux usages ?

IDéNum doit permettre de dématérialiser encore plus de procédures, avec un niveau de confiance adapté, et accélérer ainsi l’émergence de nouveaux services sur internet (B2C notamment). Les entreprises vont en particulier y trouver un levier pour faciliter la relation client. L’identité numérique devrait simplifier des processus de souscription, et améliorer la confiance mutuelle : l’utilisateur dans l’usage de ses données personnelles et les fournisseurs de services dans la qualité des informations recueillies.

Mais soyons pragmatiques et n’attendons pas IDéNum pour avancer. Les Identités numériques existent déjà, même si elles ne sont pas qualifiées ou réputées fiables. Et pour certains usages, c’est déjà bien suffisant. Quels risques à permettre à un prospect de sauvegarder un devis et de s’authentifier avec son compte Google ? Si vous employez des étudiants saisonniers durant les congés estivaux, est-ce plus risqué d’utiliser des comptes génériques avec un mot de passe trivial, ou de leur permettre de s’authentifier avec leur compte Facebook ou LinkedIn ? Cette tendance est d’ailleurs déjà associée à un acronyme : « BYOID » pour Bring Your Own IDentity.

Au-delà des concepts, les fondamentaux « traditionnels » de l’identité doivent rester au cœur des réflexions : comment proposer une Identité unique et pérenne ? Comment garantir le lien avec le cycle de vie des utilisateurs dans l’entreprise ? Ou encore comment garantir un niveau d’authentification en cohérence avec les services offerts et les risques associés ? Autant de questions qui devront servir de guide à la définition de l’identité numérique de demain.

Cet article Identité numérique : quel état des lieux aujourd’hui en France ? est apparu en premier sur RiskInsight.

Des principes de bases partagés mais des divergences dans leur application

De nombreux pays tentent, à leur échelle, de répondre aux enjeux de l’identité numérique. Ces initiatives partagent les mêmes principes de base, calqués sur ceux de l’identité réelle. En revanche, elles divergent sur la mise en application de ces principes : acteurs autorisés à émettre des identités numériques, stockage des données personnelles, caractère universel ou non, etc. Ces spécificités ont pour objectif de façonner une identité numérique au plus près de la culture de chaque pays.

L’émission des identités numériques : par l’État, mais pas uniquement

Contrairement au monde réel, ce sont les acteurs privés qui ont été force d’initiative sur Internet. Par exemple Yahoo, Facebook, Google ou d’autres sites proposent d’ores et déjà de vous authentifier sur des sites tiers. Mais attention, si ce mode de fonctionnement apporte un réel confort aux utilisateurs, ces identités restent déclaratives, sans réellement améliorer le niveau de confiance associé. En effet, personne n’a vérifié que vous êtes bien la personne que vous prétendez être.

Comment alors vérifier les informations fournies et améliorer la fiabilité des identités ?

C’est souvent l’État qui se charge de vérifier et délivrer les Identités numériques de confiance. Toutefois, et principalement pour des raisons culturelles, cette responsabilité peut être déléguée à des entreprises privées, parfois sous contrôle de l’État. C’est notamment le cas au Royaume-Uni, où il n’existe pas de carte d’identité. La dernière tentative du gouvernement pour introduire une carte d’identité en 2010 n’a pas survécu à son impopularité. Le gouvernement s’est alors tourné vers les modèles américains et canadiens, en choisissant de confier la délivrance d’Identités numériques à des acteurs privés. Ainsi, il est possible de se connecter certains sites administratifs de l’État avec une Identité numérique fournie par Paypal ou The Post Office.

Des données personnelles stockées de manière centralisée ou portées par chacun

Autre point structurant de divergence entre les initiatives : le stockage des données d’identité.

Le plus souvent, les informations d’Identité numérique se présentent sous la forme d’une carte à puce. Celle-ci contient peu ou prou les mêmes informations qu’une carte d’identité traditionnelle, ainsi que des certificats électroniques protégés par un code PIN. Elle peut être intégrée à la carte d’identité physique, ou être contenue dans un support dédié (carte à puce, clé USB, carte SIM du téléphone portable…).

À contrario, l’Inde a pris le parti de centraliser les données biométriques de ses citoyens dans une base de données unique. D’ici 2015, le gouvernement espère enregistrer dans un fichier centralisé les empreintes digitales et rétiniennes de la moitié de la population. Avec un terminal biométrique, toute administration ou commerçant affilié peut alors identifier une personne. Notons que, en l’état actuel, un tel dispositif ne pourrait être transposable en France, la CNIL interdisant l’utilisation d’une base de données biométrique centralisée, sauf pour « fort impératif de sécurité »¹.

Déployer l’identité numérique : l’exemple Estonien 

L’initiative de l’Estonie se démarque cependant par son niveau d’adoption et le caractère universel de l’usage de l’identité numérique, tant dans le monde numérique que dans le monde réel. Grâce à un badge remis à tout citoyen (ou à la carte SIM de leur mobile), les estoniens sont en mesure depuis 2002 de certifier dans le monde numérique leur identité, et toute information personnelle qui s’y rattache (âge, sexe, domicile, etc.). Plus qu’une carte d’identité dématérialisée, cette identité numérique est pleinement intégrée à leur quotidien. Moyens de transport, transactions bancaires, déclarations fiscales, inscriptions à l’université, créations d’entreprise, etc. Elle permet même de voter aux élections nationales.

L’Estonie fait figure d’exception,  les niveaux d’adoption restant généralement faibles et les déploiements limités à des usages ciblés. L’Identité numérique existe malgré tout aujourd’hui dans plusieurs pays, et notamment en Europe. Qu’en est-il de la France ? Des initiatives sont-elles à y souligner ? La réponse est oui.

À suivre au 3^ème épisode…

Cet article Identité numérique : de nombreuses initiatives à travers le monde 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.

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

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

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

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

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

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

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

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

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

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

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

Comment lever les derniers freins ?

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

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

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

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

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

Cet article Dématérialisation et signature électronique : vers l’explosion des usages grand public ? est apparu en premier sur RiskInsight.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Le cloud : un booster pour les projets IAM

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

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

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