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.

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

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

What is CIBA?

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

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

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

What contributions?

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

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

Gains by population

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

Use case examples

The call centre

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

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

Virtual assistants

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

Conclusion

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

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

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

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

What are the native functionalities in the Microsoft platform?

Which rights models within Microsoft 365?

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

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

Level One: Using Azure AD roles to manage services

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

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

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

Figure 1 – Example of sensitive rights

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

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

Second level: Using the RBAC model to manage objects

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

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

How to provision the accounts of administrators?

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

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

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

How to assign permissions?

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

In the case of service administration

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

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

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

In the case of the administration of objects

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

Figure 2 – Natives functionalities of the solution

How to build and implement your administration model?

What strategy to define your rights model?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

How to protect access to these accounts ?

10 measures to secure administration accounts

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

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

Basic measures to secure the administration account

1. A dedicated administrator account

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

2. Multi-Factor Authentication

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

This measure is available for everyone, for all licences:

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

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

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

Highly recommended security measures

3. Unlicensed Office 365 account

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

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

4. Conditional Access (with Azure AD P1)

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

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

5. Password Protection (with Azure AD P1)

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

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

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

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

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

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

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

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

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

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

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

To go even further

8. Supervision of administrator actions to detect abnormal behaviour

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

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

9. Setting up a Privileged Access Workstation

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

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

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

10. Keep up to date with good practices and news

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

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

Focus on glass breaking accounts

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

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

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

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

Conclusion

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

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

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

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

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

Fonctionnement du mécanisme de verrouillage de compte utilisateur

Jamais un sans trois

Invoke-CleverSpray – Script PowerShell automatisant la découverte de mots de passe (actuel, N-1 et N-2)

Cet article Invoke-CleverSpray – Jamais 1 sans 3 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.

Kerberos est un protocole d’authentification réseau reposant sur un mécanisme de clés secrètes (chiffrement symétrique) et l’utilisation de tickets. Il fait partie intégrante des système d’exploitation Windows depuis la version Serveur 2000. Différents termes spécifiques sont utilisés pour détailler ce protocole :

• KDC (Key Distribution Center) : Le KDC est un service installé sur les contrôleurs de domaine et permettant l’obtention des différents tickets par un utilisateur.
• TGT (Ticket-Granting Ticket) : Le TGT est un ticket attribué par le KDC à un utilisateur. Ce ticket représente l’identité de l’utilisateur, et lui permet d’effectuer des demandes de TGS auprès du KDC.
• TGS (Ticket-Granting Service) : Le TGS est également un ticket attribué par le KDC pour représenter un utilisateur. Il permet à l’utilisateur de s’authentifier auprès d’un service spécifique, dont le nom est inscrit dans le ticket. Un exemple d’un tel ticket est le suivant :

Le schéma d’une authentification Kerberos classique est le suivant :

Dans la première étape, l’utilisateur envoi au contrôleur de domaine un timestamp chiffré à l’aide du hash NTLM de son mot de passe. Ayant accès à ce hash, le contrôleur de domaine, et plus précisément le KDC, peut déchiffrer l’information reçue et vérifier le timestamp, ce qui prouve l’identité de l’utilisateur. Le KDC fournit alors à l’utilisateur son TGT (étape 2).

L’utilisateur peut alors fournir le TGT préalablement récupéré pour effectuer une demande de TGS (étape 3). Le TGT étant représentatif de l’utilisateur, le KDC peut valider son identité et lui fournir un TGS pour le service demandé (étape 4).

Enfin, l’utilisateur transmet ce TGS comme preuve de son identité auprès du service (étape 5).

Dans le protocole Kerberos, ce sont donc bien les tickets qui permettent d’assurer l’identité d’un utilisateur, au même titre qu’un couple nom d’utilisateur / mot de passe le fait dans une authentification classique.

Introduction aux délégations Kerberos

Microsoft a introduit les délégations Kerberos dans l’objectif de permettre à une application de réutiliser l’identité d’un utilisateur pour accéder à une ressource hébergée sur un serveur différent. Un cas d’usage est par exemple l’accès à des documents hébergés sur un serveur dédié depuis une plateforme SharePoint :

L’utilisateur n’ayant pas d’accès direct au serveur de fichiers, il s’authentifie sur la plateforme SharePoint qui doit alors transmettre l’identité de l’utilisateur au serveur de fichiers.

Cependant, les tickets de service étant délivrés pour une application spécifique, le SharePoint ne peut transmettre directement le ticket qu’il a reçu de l’utilisateur. C’est donc pour répondre à cette problématique que Microsoft a mis en place les délégations Kerberos, qui existent sous deux formes :

• Les délégations non contraintes, apparues avec le système d’exploitation Windows Serveur 2000, et qui donnent l’autorisation à un compte de service de réutiliser l’identité de l’utilisateur sur n’importe quel service du domaine ou de la forêt.
• Les délégations contraintes, apparues avec le système d’exploitation Windows Serveur 2003, et qui permettent un meilleur contrôle en limitant les services sur lesquels un compte de service donné peut s’authentifier en tant que l’utilisateur.

Les délégations Kerberos non contraintes

Le schéma d’authentification d’un utilisateur désirant accéder à une ressource dans le cas d’une délégation Kerberos non contrainte est le suivant :

Lors de la première étape de ce schéma, l’utilisateur effectue une demande de TGT auprès du contrôleur de domaine, en lui transmettant un timestamp chiffré avec le hash NTLM de son mot de passe. Après avoir validé son identité, le contrôleur de domaine fournit un TGT à l’utilisateur (étape 2), comme il le ferait pour une authentification Kerberos classique.

Pour s’authentifier auprès de l’application SharePoint, l’utilisateur demande alors un TGS au contrôleur de domaine, en lui fournissant le TGT précédemment récupéré (étape 3). Dans le cas d’une délégation Kerberos non contrainte, le contrôleur de domaine construit le TGS de l’utilisateur à partir de son TGT, qu’il chiffre à l’aide du hash NTLM du mot de passe du compte de service utilisé par l’application SharePoint (étape 4).

L’utilisateur s’authentifie alors sur l’application SharePoint (étape 5) en transmettant le TGS que lui a fourni le contrôleur de domaine lors de l’étape précédente.

Le compte de service de l’application SharePoint peut déchiffrer ce TGS étant donné qu’il est chiffré avec son propre hash. Il récupère ainsi le TGT de l’utilisateur, qu’il peut fournir au contrôleur de domaine pour effectuer une demande de TGS pour le serveur de fichier (étape 6). Le TGT étant celui de l’utilisateur, le TGS renvoyé par le contrôleur de domaine (étape 7) représente son identité, et non celle du compte de service.

Le compte de service de l’application SharePoint peut alors transmettre ce TGS (étape 8), que le serveur de fichiers validera comme s’il provenait de l’utilisateur lui-même, donnant accès au document demandé (étape 9).  Ayant récupéré ce document, l’application SharePoint peut le fournir à l’utilisateur, pour lequel les phases d’authentification intermédiaires auront été transparentes.

Les délégations Kerberos contraintes

Dans le cas d’une délégation Kerberos contrainte, deux extensions de protocole sont utilisées pour permettre à une application de réutiliser l’identité de l’un de ses utilisateurs :

S4U2Self (Server-for-User-to-Self) qui autorise un service à obtenir un TGS pour lui-même en tant qu’un utilisateur.

S4U2Proxy (Server-for-User-to-Proxy) qui autorise un service à obtenir un TGS pour un autre service en tant qu’un utilisateur.

La cinématique d’authentification et d’accès aux ressources dans le cas d’une telle délégation est alors la suivante :

Dans la première étape de cette cinématique, l’utilisateur s’authentifie après du premier service en lui transmettant ses identifiants. L’authentification n’utilisant pas Kerberos, l’utilisateur n’a pas besoin de s’authentifier auprès du contrôleur de domaine.

Le compte de service demande alors un TGS représentant l’identité de l’utilisateur et permettant de s’authentifier auprès de son propre service (étape 2). Le compte de service possédant l’extension S4U2Self, le contrôleur de domaine accorde ce ticket (étape 3).

Ce même compte de service demande ensuite un TGS représentant l’identité de l’utilisateur et permettant de s’authentifier auprès du second service (étape 4). Après validation de l’extension S4U2Proxy, le contrôleur de domaine accorde ce TGS (étape 5)

Grâce à ce second ticket de service, le compte de service du SharePoint peut accéder aux ressources du serveur de fichier avec l’identité de l’utilisateur (étape 6). Le serveur de fichiers valide les privilèges de l’utilisateur, et transmet le document demandé au compte de service SharePoint (étape 7), qui le transmet à l’utilisateur (étape 8).

Contrairement au cas des délégations non contraintes, l’utilisation de l’extension de protocole S4U2Proxy permet de spécifier les services accessibles au compte de service SharePoint. Ainsi, même si l’utilisateur dispose des privilèges nécessaires pour accéder à un autre serveur, le compte de service ne pourra récupérer de TGS valide représentant l’identité de l’utilisateur. Dans le cas d’une délégation contrainte, cette restriction se fait à l’aide d’un paramètre du compte de service, appelé SPN pour Service Principal Name.

Il est à noter que depuis la version Serveur 2012 du système d’exploitation Windows, un troisième type de délégation Kerberos est proposée, les délégations Kerberos contraintes basées sur les ressources. Le fonctionnement de ces délégations est similaire à celui des délégations contraintes, mais la restriction est effectuée en spécifiant explicitement le compte ayant accès aux ressources.

Exploiter les délégations non contraintes

Les faiblesses induites par les délégations Kerberos non-contraintes sont connues depuis plusieurs années. Sean Metcalf a, par exemple, présenté les dangers de telles délégations à la Black Hat USA 2015. Dans la cinématique d’authentification présentée précédemment, il est en effet évident que le compte de service de l’application SharePoint peut, une fois que l’utilisateur lui a transmis un TGS contenant son TGT, accéder à l’ensemble des services pour lesquels l’utilisateur dispose de privilèges nécessaires.

L’objectif d’un attaquant est alors d’obtenir le TGT d’un administrateur du domaine, ce qui lui permet de se connecter au contrôleur de domaine avec les privilèges maximum pour changer le mot de passe du compte krbtgt afin de pouvoir forger ses propres tickets à la demande.

Pour parvenir à cela, il est d’abord nécessaire d’identifier les services qui disposent de délégations non contraintes. Pour cela, il suffit de filtrer les objets de l’Active Directory à la recherche de paramètres TrustedForDelegation valant True. Ce paramètre indique en effet la présence d’une délégation non contrainte, et est de plus accessible sans privilège particulier, par exemple à l’aide de la commande Get-ADComputer du module ActiveDirectory :

Une fois les services disposant d’une délégation Kerberos non contrainte identifiés, il est nécessaire d’obtenir des privilèges administrateur sur l’un des serveurs sur lesquels ils sont utilisés. Les méthodes de compromission classiques peuvent alors être utilisées, mais ne seront pas abordées dans cet article.

En cas d’accès au service par un administrateur du domaine, l’attaquant sera en mesure d’extraire le TGS fourni à l’aide par exemple de l’outil mimikatz et de la commande suivante :

Comme indiqué dans le scénario d’authentification, ce TGS contient le TGT de l’administrateur, que l’attaquant pourra extraire afin de réaliser une attaque Pass-The-Ticket pour se connecter au contrôleur de domaine.

Les recommandations pour protéger un domaine d’une telle attaque sont alors les suivantes :

• Utiliser des délégations Kerberos contraintes qui sont plus restrictives
• Configurer l’ensemble des comptes à privilèges avec le paramètre « Le compte est sensible et ne peut être délégué » qui empêche la réutilisation de l’identité du compte par une application possédant une délégation

Dans le cas d’un domaine au niveau fonctionnel supérieur à Windows Serveur 2012 R2, le groupe de sécurité « Utilisateurs protégés » peut être utilisé pour les comptes à privilèges étant donné que les délégations ne sont pas autorisées pour les comptes de ce groupe.

Qu’en est-il des délégations contraintes ?

L’utilisation de délégations contraintes semble être une alternative plus sécurisée. Cependant, différents éléments sont à noter concernant ce mécanisme d’authentification, comme l’a présenté Matan Hart lors de la Black Hat 2017. En effet, les deux extensions de protocole utilisées ont été pensées avec les principes suivants :

• Les deux extensions permettent à un service Kerberos d’obtenir des TGS sans même que l’utilisateur n’ait besoin de s’authentifier auprès du contrôleur de domaine.
• L’extension S4U2Self permet au service d’obtenir un TGS pour l’utilisateur sans qu’aucun mot de passe ne soit nécessaire.

De ce fait, un service qui possèderait les deux extensions pourrait obtenir un TGS pour n’importe quel autre service en se faisant passer pour un utilisateur, et ce sans nécessiter son mot de passe.

Matan Hart a publié son outil « Mystique[1] » qui permet d’identifier des configurations à risque pour les délégations. Pour cela, il liste les comptes qui disposent du paramètre TrustedToAuthForDelegation valant True, indiquant une délégation contrainte, ainsi que d’un paramètre MsDS-AllowedToDelegateTo non nul, indiquant l’utilisation d’un SPN, ce qui est obligatoire pour les comptes de délégation.

Il est également à noter que les TGS sont validés selon deux critères, le hash du mot de passe de l’utilisateur, et le SPN possédé par le compte de service qui possède la délégation contrainte. En cas de multiples SPNs associés à un même compte de service, et de mot de passe partagé entre différents comptes, les tickets pour deux services distincts seront complétement interchangeables, ce qui pourrait permettre à un service de réutiliser l’identité d’un utilisateur de manière illégitime.

Ces faiblesses ne sont pas considérées comme des vulnérabilités par Microsoft, et ne sont donc pas amenées à changer. Lors de la création d’une délégation Kerberos contrainte, il est alors nécessaire de faire attention aux points suivants pour se protéger des attaques :

• Configurer les services à l’aide de comptes de service dédiés, évitant ainsi le partage des comptes qui pourrait aboutir à des tickets interchangeables. Il est également important d’assurer une bonne complexité des mots de passe, ainsi qu’une rotation régulière.
• Configurer des SPNs uniques comme étant autorisés pour la délégation, en évitant les SPNs par défaut de Microsoft, et en spécifiant les ports utilisés.
• Comme pour les délégations non contraintes, configurer les comptes à privilèges comme étant des comptes sensibles ne pouvant être délégués.

Conclusion

L’utilisation de délégations contraintes n’est pas totalement à proscrire. Il est cependant nécessaire de bien maitriser leur configuration et les ressources auxquelles elles permettent d’accéder afin d’éviter les travers détaillés dans cet article.

Cet article Compromission d’un domaine Windows à l’aide des délégations Kerberos 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.

Authentec, une cible inattendue pour Apple

En annonçant le rachat d’Authentec pour 356 millions de dollars, Apple a surpris le marché. Il s’agit en effet d’un achat au prix fort, Authentec réalisant quasiment 70 millions de dollars de chiffre d’affaires et étant actuellement déficitaire avec une perte nette de 10 millions de dollars. C’est  une des opérations les plus importants pour Apple. Cible inattendue, d’autant que la sécurité n’est pas au cœur du métier d’Apple, connu pour ses solutions grand public.

Une stratégie pour acquérir des brevets de premier plan sur la sécurité ?

Authentec est une société bien installée sur le secteur de la téléphonie mobile, elle compte aujourd’hui pour clients des géants du secteur comme Samsung, Nokia, Motorola… Et surtout cette société détient plus de 200 brevets sur de multiples solutions de sécurité (protection des données, communication sécurisée…), et en particulier les brevets « fondamentaux » sur l’authentification biométrique. De là à imaginer qu’Apple voudrait renforcer son arsenal de brevets, il n’y a qu’un pas ! Cela serait une mauvaise nouvelle pour l’innovation… Nous observons tous les jours les effets délétères des guerres que se livrent les grands acteurs du secteur : Oracle et Google, Apple et Samsung, et bien d’autres…

Les récentes annonces font pencher la balance vers l’innovation !

Des documents récemment révélés par la SEC (le gendarme de la bourse aux Etats-Unis) montrent que cette acquisition a été réalisée de manière rapide, apparemment avant tout pour garantir l’approvisionnement en composants auprès d’Apple. Voilà qui pourrait cacher les futures innovations qui seront peut être présentes dans l’iPhone 5 ? En effet, Authentec dispose de technologies qui lui permettent d’intégrer des lecteurs d’empreintes digitales de manière simple dans les smartphones. Les derniers produits présentés permettraient même d’imaginer un lecteur d’empreintes digitales dans le bouton « Home » de nos iPhone !

Une idée qui pourrait plaire à Apple pour simplifier l’authentification de ses clients et ainsi faciliter l’adoption de technologie comme le NFC, mais aussi constituer un avantage distinctif de son futur système de « portefeuille virtuel » Passbook ! L’utilisation d’authentification biométrique pourrait à la fois simplifier la vie de l’utilisateur (plus de mots de passe…)  et rassurer les cybermarchands (diminution des cas de fraude…).

Voilà donc un rachat qui pourrait s’avérer une avancée significative dans l’adoption de mécanismes de sécurité dans le grand public ! Croisons les doigts et attendons peut-être le 12 septembre pour voir si la prochaine « Keynote » révèlera les plans du géant à la pomme dans ce domaine.

Cet article Apple et Authentec : guerre des brevets ou réelle innovation ? 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.