Phishing attacks are well known. The objective of this type of attack is to perform actions from a victim’s account or to retrieve information about the targeted person or company.

Despite their notoriety, they remain very effective for attackers. Indeed, among the attacks investigated by Wavestone CERT, about 51% of them start with the use of valid accounts, which includes phishing attacks.

We are all vulnerable to phishing attacks! An attacker with enough resources and information about their target can generate a trap sophisticated enough to trick them. Similarly, the Office365 and Azure product suites have features that can be exploited in less conventional attacks, the impacts of which users may not be aware.

Employee awareness, while necessary to address the most common threats, is not enough to address some of the more targeted or less traditional types of attacks. Tougher access requirements to cloud-hosted resources, good hygiene in managing access rights, and detection of unusual and suspicious access are all critical to a company’s defence strategy.

Attackers have a wide range of tools and possibilities to access documents stored on a company’s SharePoint, attempt to retrieve sensitive emails, or retrieve employee information. The traditional phishing attack as well as the device code authentication attack will be briefly explained below before looking at the illicit consent grant attacks in more detail.

The traditional phishing attack: a known threat preventable using multi-factor authentication

Traditional phishing attacks are usually based on sending a link directing the targeted victims to a site the attacker controls. Using an authentication login page similar to those used by employees of the targeted company, the attacker retrieves the credentials and passwords of the tricked users.

The traditional phishing attack is simple to implement in the absence of multi-factor authentication

The ease of implementing such an attack on a large scale makes it a tool of choice for untargeted attacks. One method to protect against this type of attack is to enforce the use of a second authentication factor.

It should be noted however that although more complex to implement, the interception of the second authentication factor is technically feasible and will be the subject of an upcoming dedicated article.

The attack via “device code” authentication: a little-known authentication method hijacked by attackers

This attack relies on the device authorization grant functionality[1]. This authentication method allows the authentication of a user on a device without a web browser. A code displayed on this device must then be entered on a computer or smartphone via the dedicated Microsoft site. This device will then have part of the access rights to Office 365 resources corresponding to the user who entered the code.

This functionality is not well known to users and can be exploited by an attacker for malicious purposes:

• The attacker first generates a device code, using the same process used by devices without a web browser.
• Then, the attacker’s objective will be to get the victim to fill in his device code on the https://microsoft.com/devicelogin For example, the attacker could pretend that to access a sensitive document, it is necessary to connect to this link using the code he generated.
• If the target accesses the link, fills in the code and authenticates, this will allow the attacker to impersonate the

Example of a device code phishing attack

This attack is more difficult for an attacker to carry out because of the short lifespan of the device codes: they are only valid for 15 minutes and must therefore be generated shortly before the user enters them. This attack is therefore more easily carried out within the framework of “phoning” attacks or phishing via Teams. For example, the attacker could call the victim, pretending to be part of the company’s IT support team, and ask the user to authenticate on the link indicated and fill in the code of his choice.

To protect against this type of attack, conditional access policies on Azure can be used to prohibit suspicious connections from devices not under the control of the company.

Illicit consent grant attack

In addition to these two methods, the illicit consent grant attack also allows an attacker to illegitimately gain access to an Azure environment. This attack was even initially easier for an attacker to implement than attacks via device code authentication. Faced with the resurgence of this threat, actions were taken in 2020 by Microsoft to limit the conditions for carrying out the attack. While hardened Azure configurations can completely block this threat, the configurations implemented by some companies expose them to this type of attack. What are the prerequisites for the realization of such an attack, what are the possible consequences and how to protect yourself?

What is the illicit consent grant attack?

To understand the principle of this attack, let’s put ourselves in the shoes of an employee who is a victim of such an attack:

• The victim receives a phishing email indicating an urgent action to be taken to keep their Microsoft account activated. Employees are made aware not to click on phishing links and not to enter their passwords on unknown platforms. The link in the format https://login.microsoftonline.com/common/oauth2/v2.0/authorize?client_id=<CLIENT_ID>&redirect_uri=<Attacker_controled_URL>&response_type=code&response_mode=query&scope=Mail.ReadWrite%20Files.Read.All%20Mail.Send%20User.Read contains a Microsoft-associated domain, which reassures the victim.
• When clicking on the link, the victim must authenticate themself. This authentication is often automatic since it benefits from Microsoft’s single sign-on (SSO). The victim then receives a request to grant permissions:

The malicious application asks the user to grant it permissions

• If the victim clicks “Cancel” out of caution, they are redirected to the attacker’s server with a URL like <Attacker_controled_URL>/?error=consent_required &error_description=AADSTS65004%3a+User+declined+to+consent+to+access+the+app.&error_uri=https%3a%2f%2flogin.microsoftonline.com%2ferror%3fcode%3d65004#. The attacker, understanding that the victim has not accepted the prompt to grant them permissions, can then redirect the victim to the phishing page, giving them the impression that the requested permissions must be accepted to proceed to the next step.
• Because of the legitimate domain name and the urgency indicated in the phishing email, the victim of the attack chooses to accept. They then see a message indicating that their account will be kept activated, as suggested in the initial email. The victim then resumes normal activity.

However, this consent allows the attacker to perform actions on behalf of the victim, depending on the permissions granted. Note that the illicit consent grant attack has many advantages for an attacker, including:

• The use of a Microsoft-associated URL when requesting consent, which is considered trusted and therefore implies less distrust on the part of targeted users.
• Obtaining persistent access for 90 days, without knowledge of the user’s password or second authentication factor if no conditional access policy is implemented.
• The ability to directly request Microsoft APIs to automatically retrieve files, emails, and other corporate resources accessible by the tricked user.

Technical sidebar

From a technical point of view, the illicit consent grant attack relies on the ability of an attacker to create an application that requires permission to be granted. Granting the permission is a feature that is regularly used by users without them realizing it, e.g., the Outlook client is allowed by default to retrieve and notify them of new incoming emails.

Here are the key steps when performing this type of attack (which is based on the authorization code grant flow of OAuth 2.0):

• The attacker creates an enterprise application on Azure AD (application registration), configures the permissions they want from users and instantiates a “client_secret” on the application. Some constraints related to this application are detailed below.
• The attacker sets up a server to which users will be redirected following the consent and indication of its URL as a valid redirection URL for the application.
• Following a user’s consent, the user will be redirected to the malicious site and a code will be provided to the attacker. This code is the proof to be shown to Microsoft that the user authorizes the application to do actions on their behalf.
• Using this code and the application’s “client_secret“, the attacker will be able to retrieve an OAuth token. This token is a receipt signed by Microsoft that specifies the actions that the victim authorizes to be done on his behalf. The attacker can also retrieve a “refresh_token” that allows to renewal of the validity of the OAuth token.
• This OAuth token can then be used to send requests to the Graph API in the name of the victim and therefore allows attackers to impersonate the user.

What are the consequences of such an attack?

While some permissions require administrator approval by default, other permissions can be granted directly by users in non-hardened Azure environments. The permissions that can be recovered by the attacker during this type of attack depend on the configuration of the targeted Azure AD tenant.

Here are some examples of possible abuse by an attacker who has managed to retrieve a user’s permissions on a non-hardened environment.

Actions that can be taken following a successful malicious consent attack on an unhardened Azure environment

• Azure Active Directory:
  • The Microsoft Graph User.ReadBasic.All permission allows retrieval of the email addresses of all users in a tenant, allowing the deployment of larger-scale phishing attacks from an initial compromise.
• Outlook:
  • Sending an email on behalf of a user can enable so-called “president fraud” attacks using the Microsoft Graph Mail.Send and Mail.ReadWrite permissions. A compromised employee with a high level of authority could, for example, send an email requesting that a large amount of money be sent urgently to a bank account not listed by the company.
  • Sent emails can also be hidden using Outlook filtering rules that can be modified using the MailboxSettings.ReadWrite permission. The attacker will then be able to redirect all emails related to his attack and associated replies to a different folder in the outbox and inbox.
• Teams:
  • Reading and sending messages via Teams (Microsoft Graph Chat.ReadWrite) is an effective method for an attacker to impersonate a user. This method can also be used to carry out “president fraud” attacks.
• OneDrive and SharePoint:
  • Read access to files accessible on OneDrive and SharePoint (Microsoft Graph Files.Read.All) can provide access to all files accessible by the user. In addition, SharePoint files are often stored with permissive access rights which could allow attackers to retrieve a large number of files. It is not uncommon, for example, to have access to scripts or configuration files containing passwords in clear text.
  • In addition, SharePoint’s search capabilities, including reading and indexing the content of Office files, can be used to target certain keywords such as “password”.
  • The writing rights on a SharePoint file (Microsoft Graph Files.ReadWrite.All) can also have a significant impact: SharePoint’s versioning features limit the recording of old file versions to 100 versions by default. This means that in case of automated and successive rewrites more than 100 times, the initial version of the file would no longer be recoverable. This would allow an attacker to erase a large amount of data if an account with write rights to sensitive files is compromised. In case of deletion, it would then be necessary to contact Microsoft support to try to recover the data from the daily cold backups.
• OneNote:
  • Synchronized OneNote files (Microsoft Graph Notes.ReadWrite or Notes.Read.All) can contain sensitive information such as meeting minutes, and confidential information, but also technical information such as passwords stored in an unsecured manner.
• Azure Resources:
  • Access to key vaults and storage accounts (Azure Key Vault and Azure Storage user_impersonation) can give access to sensitive elements in case of compromise of developer or technical user accounts. These elements can facilitate the compromise of Azure resources such as virtual machines and serve as a rebound point for an external attacker.

These actions can have serious impacts on a company. In addition, they can facilitate more elaborate attacks by disclosing sensitive information to an external attacker.

If approved by an administrator, more sensitive permissions can be retrieved such as write access to all Azure Active Directory information.

Finally, administrators have the right to grant all users permission to an application of the tenant. In this case, the identity of all users could be impersonated to grant permission.

Microsoft’s implementation of the “risk-based consent step-up” to limit attacks by illicit consent

In response to this threat, Microsoft implemented additional protections in November 2020 to limit the impact of this type of attack. The “risk-based consent step-up” feature aims to raise a warning and ask for an administrator’s validation in case of a permission request that seems fraudulent.

The access request from an unverified application considered sensitive is blocked by default

This applies in the case of a permission request by an unverified application created outside the targeted tenant. By default, all permissions are affected, except for reading the target user’s profile, to facilitate single sign-on (SSO) with third-party applications.

This restriction is implemented by default on all Azure tenants.

Although these restrictions limit attacks, 3 types of applications can still be used for malicious purposes: legacy applications, applications internal to the targeted tenant and verified applications.

• Legacy applications:
  • To allow for backward compatibility, no warning message is displayed for a permission request from an application created before November 2020.
  • Prerequisite for the attacker: have an application created on an Azure tenant before November 2020 or compromise a tenant containing such applications.
• Internal applications of the targeted tenant:
  • These applications are not covered by the “risk-based consent step-up”. By default, all users of an Azure tenant have the right to create an enterprise application on their tenant, which makes it easier to attack an unhardened environment.
  • Prerequisites for the attacker: to have a first compromised account on the IS of the targeted company, to realize that the creation of applications is authorized for standard users and to deploy an internal application to the tenant.
• Verified applications:
  • Verified applications are not covered by the risk-based consent step-up. The Microsoft verification process requires integration into the Microsoft Partner Network.
  • Prerequisite for the attacker: have a verified application or compromise an Azure tenant with verified applications and hijack the use of these legitimate applications.

Possible remediations

To limit the probability and impact of such attacks, the following recommendations can be applied and adapted to the company’s context:

• Allow only applications explicitly approved by administrators. This configuration is the most secure, but the validation step can be a bottleneck since it is usually the Global Administrators and Privileged Role Administrators who must give validation. In practice, some rights can also be granted via Cloud Application Administrators or Application Administrators.

Granting privilege consent by standard users can be blocked via Azure AD configurations

• Limit the permissions which can be granted. An administrator can specify Low-risk permissions that can be granted directly by users.

Granting privilege consent by standard users can be limited to rights considered non-sensitive via Azure AD configurations

• Create a legitimate application validation process and admin consent workflow to track and justify these validations. By tightening up the consent process, it is necessary to jointly implement a simple and intuitive way for users to request exceptions to grant permissions related to legitimate use cases. These exceptions must be tracked and justified to ensure the legitimacy of the requests.
• Regularly review the rights granted to applications (Enterprise applications): permissions granted by users should be reviewed to ensure that only legitimate applications have rights to the tenant’s Office 365 resources.

Regular review of trusted applications on an Azure tenant facilitates checking that the privileges granted are still valid

• Monitor suspicious access to Office 365 resources. For example, it is possible to set up alert rules on the number of files downloaded over a short period of time to identify data exfiltration attempts.
• Limit access rights to SharePoint files to what is strictly necessary: files that are accessible to all users within a company should be checked at regular intervals and access rights to the most sensitive files should be reviewed to ensure that only the necessary people have access.

Conclusion

The various phishing attacks presented in this article are based on a lack of hardening of Azure AD configurations. The implementation of a second authentication factor, while necessary for traditional phishing attacks, is not sufficient to protect against the other attacks presented. For attacks via device code authentication, administrators can implement conditional access policies to limit suspicious connections from devices not under the control of the organization. For illicit consent grant attacks, the most effective measure is to only allow applications approved by administrators.

These three elements of hardening, although simple in appearance, can be the subject of real security projects to consider the existing configurations and usages, in particular by ensuring that existing applications are not blocked by these measures, and by implementing regular review and validation processes for new applications.

Bibliography

https://aadinternals.com/post/phishing/

https://jeffreyappel.nl/protect-against-oauth-consent-phishing-attempts-illicit-consent-attack/

https://positivethinking.tech/insights/what-is-an-illicit-consent-grant-attack-in-office-365/

https://docs.microsoft.com/en-us/azure/active-directory/develop/publisher-verification-overview

https://learn.microsoft.com/en-us/azure/active-directory/manage-apps/user-admin-consent-overview

https://learn.microsoft.com/en-us/security/operations/incident-response-playbook-app-consent

https://www.microsoft.com/en-us/security/blog/2021/07/14/microsoft-delivers-comprehensive-solution-to-battle-rise-in-consent-phishing-emails/

[1] https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-device-code

Cet article Illicit consent grant attacks targeting Azure and Office 365: still a threat? est apparu en premier sur RiskInsight.

The need for collaboration externally entails risks for companies

Companies have always needed to collaborate with each other by sharing resources and exchanging data. To do this, their collaborators must be able to interact securely with users outside their environment.

Several use cases can be applied, including time-bound collaboration with partners, external service providers, suppliers or B2B customers.

Additionally, it is common to observe continuous collaboration between subsidiaries of the same group that have access to the resources and data of the company whilst not necessarily requiring to share the same Information Systems.

Historically, collaboration could be achieved in several ways. However, collaboration also comes with certain disadvantages:

• By successive exchange of emails – which can be inefficient and can result in a loss of control of the data exchanged;
• By using solutions dedicated to share documents with third parties – which can be costly and unsuitable from a user experience point of view;
• By creating a new identity in legacy systems (Active Directory, etc.), and by providing third-party entities with a means to access the company’s IS (VPN, virtual machines, physical machines, etc.) – which can significantly increase the company’s attack surface.

Microsoft introduced Azure AD B2B to address the need for collaboration

Today, using Azure AD B2B allows two or more entities to collaborate within the host company’s Azure tenant.  Shared resources can be apps, documents, SharePoint sites, OneDrive, or Teams teams.

In effect, the Azure B2B solution allows an external user to access the host company tenant through their regular account by creating a “guest” identity within the company’s Azure Active Directory (AAD).

The “client” tenant then fully or partially trusts the “external” tenant for authentication via a token exchange mechanism.

There are three native possibilities for creating a “guest” identity:

• Directly from the Azure portal;
• Via document sharing on OneDrive/SharePoint/Teams;
• Through the use of the GRAPH API.

Figure 1 – Native Operation: Authentication and Identity Creation

At the level of the host tenant, the owner can choose to authorize the sharing of data to external users while also being able to administer guest accounts (creation, deactivation, deletion etc.).

A direct benefit of this solution is the ease of use for users who are familiar with Microsoft environments.

The second advantage is the cost of the solution. A “guest” identity has a licensing cost whereby up to a ceiling of 50,000 “guest” identities, their license is free. Beyond this and depending on the company’s subscriptions, a license may cost between €0.003 and €0.015 / month / user, which is then added on to a fixed fee of €0.029 for each multi-factor authentication attempt. This pricing policy is out of step with the usual price of an M365 license, which is between €10 and €50 / month / user depending on the license plan.

However, Azure AD B2B has a default configuration that is too open, which creates risks for the company

Azure AD B2B introduces several factors that can lead to risk:

• The creation of guest identities is very simple and uncontrolled (no identity manager, no traceability, no restrictions etc.);
• The number of guest identities may increase in an uncontrolled manner, which makes managing their lifecycles difficult.
• The company does not control the security of the initial holder of the “guest” identity;
• No conditional access rules are set up by default (no strong authentication, no restriction of access to the Azure A D portal, etc.);
• The “guest” identity has access to the Azure AD attributes of other users.

These factors create risks for the company’s data since the “guest” identity may have rights to a significant number of documents and information about its host owner.

We can consider two triggering events for the different threat scenarios:

• A malicious “guest” identity;
• A “guest” identity compromised by an attacker.

An attacker would then have the opportunity to:

• Retrieve confidential data that the identity has access to;
• Destroy all data accessible by this identity;
• Compromise AD by assigning roles to this identity;
• Perform social engineering through their access to all user data.

Depending on the level of maturity of the company and the willingness to hedge risk, it is necessary to implement a number of measures

To get started: harden the default configuration

Master the means to add “guest” identities on the tenant

The first step is to cut off access to the Azure portal to non-administrator employees of the company so that it is no longer a vector for creating “invited” identities.

Figure 2 – Restricting access to the Azure AD console

It should be noted that it is also possible to restrict the population who can invite external users to collaborate. However, this will not be applicable to all companies – especially those wishing to decentralize the management of this population. The idea of restricting this population forces the creation of a service dedicated to the creation of these identities. This goes against the very principle of this service, which is to leave it in the hands of the user.

Finally, there is a feature to apply constraints to the email addresses of “guest” identities, via white-listing or domain name blacklisting. However, before embarking on this action, it is necessary to consider the complexity of its implementation and the potential low level of associated risk reduction.

Restrict what these identities can access

It is also possible to restrict what can be accessed by the invited identities, so that they are unable to retrieve a large volume of information on the host tenant.

Figure 3 – Restrict access for “guest” identities

Strengthen authentication and access control of “guest” identities

The multi-factor authentication (MFA) mechanism for a “guest” identity is almost native and reduces the risk of spoofing by an attacker. It is also possible to set up a conditional access policy that specifically targets these “guest” identities.

Figure 4 – Multi-Factor Authentication

However, challenges can still complicate this operation and need to be considered:

• Managing change management on these “guest” populations remains complex to perform, even if user onboarding operations are simple and carefully guided.
• Managing second-factor reset processes in the event of loss or theft can be costly and complex if left unchecked.

Educate users about risks and best collaboration practices

The major complexity of the Azure AD B2B solution is the lack of a mechanism for managing “guest” identities. Users are therefore the main actors of the management strategy and must be informed at the right level by emphasizing:

• Collaboration best practices: when should they use the solution, how to create a guest, and more;
• Proper management of their access: they must be removed as soon as possible in order to avoid subsequent illegitimate access;
• Disabling identities when they are no longer in use, especially for service providers/partners, ensuring that the documents produced are not lost.

Protect the data that guests can access

We must also not forget to protect the data to which a legitimate guest can have access to, which gives rise to several measures:

• It is possible to set up constraints for “guest” identities via conditional access rules that include: mandatory use of thin clients (web clients), the prohibition of data downloading, constraints on the terminals to be used, etc.
• If the company has deployed the Azure Identity Protection (AIP) classification tool, an alternate solution is to create a privacy label that encrypts the data for “guest” identities. This label can also be used to restrict certain actions for this population: modification restriction (via associated permissions), download restriction (via a DLP rule), etc.

Moving a step further, a Cloud Access Security Broker (such as Microsoft’s MS Defender for Cloud Apps) can enable the implementation of advanced and targeted rules, such as preventing uploads to specific Sharepoint spaces as an example.

Managing the Lifecycle of Guest Identities: 3 Scenarios to Consider

As mentioned earlier, the key topic is managing the lifecycle of “guest” identities i.e., the creation, deletion, and review of access. As such, there are 3 scenarios to be considered. These scenarios depend on the desired risk coverage, the level of maturity of identity and access management, and the cost of implementing the scenario.

Figure 5 – Guest Identity Lifecycle Management Scenarios

Scenario 1 – Stay pragmatic on a budget: use native tools and configurations

In this scenario, the company creates a certain group typology for “External” groups, and therefore to the creation of guests. The distinction can be made by the use of language by the group. For example: all external groups must start with “X_”.

It can thus carry out checks more easily on this limited perimeter of groups.

The main prerequisite is to block the addition of “guest” identities to “Internal” groups. This is possible in two ways:

• If the company has deployed the AIP classification tool on SharePoint and Teams spaces: a dedicated label can be used to prevent external sharing on these spaces. For example, the creation of an “Indull” label that blocks sharing with “guest” identities;  – LINK
• Via a PowerShell script: block sharing with “guest” identities for “Internal” groups by identifying them via classifications. – LINK

Creating a “guest” identity

The only way to create a “guest” identity is to add them as external users to “External” group types.

If the company needs to give its tenant access to a subsidiary or an entire entity, it is possible to regularly synchronize their AD or Azure AD, and thus create their identities as a “guest” in the tenant of the company.

Deleting a “guest” identity

The process of deleting identities is simple through the deletion of inactive “guest” identities. For example, using a PowerShell script based on the frequency of “Sign-In Activity”. Alternatively, it is also possible to remove “guest” identities that do not have access to any group via a PowerShell script.

Review of “guest” access

It is possible to expire access for “guest” identities on SharePoint groups or OneDrives after 60 days. Note that the owner of the SharePoint or OneDrive group will be notified of the expiration 21 days beforehand.

Figure 6 – Guest Access Expiration

Finally, it is possible to use the “Guest Access Review” feature for external groups. It should be noted, however, that this feature requires advanced licenses (AAD P2) assigned to the users who carry out the reviews i.e. all the owners of the groups (normally a small number).

This scenario is an efficient way that reduces guest risk, maintains a near-native solution, and doesn’t require too much investment.

Scenario 2 – To go further in the level of security: develop a guest management application

In this second scenario, the company wants to have complete control over the lifecycle management of “guest” identities. To do this, the company creates an application (for example by using Power App) to manage this lifecycle, making it the single point of creation and deletion.

Once this lifecycle is in place, it is necessary to set the SharePoint sharing setting to “Existing guest only” mode, allowing only content to be shared with “guest” identities that already exist in the Azure AD tenant. This prevents the creation of new identities through this vector.

Figure 7 – Restricting Sharing Opportunities

Creating a “guest” identity

In this scenario, users use the dedicated application to create the “guest” identities by entering an end date. The user then designates the owner of the identity created.

Deleting an “invite” identity

To delete identities, it is possible to trigger an automatic workflow before the end date by asking the owner of the identity in question whether to delete it or extend its end date. It should be noted that if the owner has left the company without making the change of ownership, consideration can be given to reassigning the guest to his or her supervisor.

Review of “guest” access

With this type of “in-house” application, it is complicated to go much further in the management of the lifecycle – especially when it comes to access review.

It is still possible, as in Scenario 1, to expire guest access or to use the “Guest Access review” feature (with the same constraints as stated above).

To go further, we can also consider the use of third-party tools such as IDECSI or Sharegate that make it possible to manage these access journals automatically and intuitively.

This scenario changes the native behavior and enables better control of the lifecycle, but at a significant blow with regard to the deployment and the management of the change to be implemented.

Scenario 2′ – Integrating “guest” identities into traditional IAM processes

The last scenario to consider is a variant of the previous scenario, where the company still wants to have control over the lifecycle management of “guest” identities. In this case, the company can integrate “guest” identity management into its identity and access management (IAM) tools in the same way as “external” identities.

The IAM tool then becomes the authoritarian source for this type of population and its management is done directly there.

In this scenario, as in the previous one, you must also set the SharePoint sharing setting to “Existing guest only” mode.

Creating a “guest” identity

Identities are created on external creation forms from IAM tools by choosing the “guest” type for the identity. The “guest” identity can then be provisioned automatically in the Azure AD by IAM tools.

Deleting a “guest” identity

The removal of the identity is also done by the IAM tool according to the positioned end date and the workflows already defined.

Reviews of “guest” access

In the event that the company’s IAM tools are used to manage rights on Sharepoint spaces, it is possible to use the access review capabilities of these tools to review access to sensitive resources for which “guest” identities have access.

Alternatively, a second option is to use access governance features via IAM solutions, such as Sailpoint OneIdentity, or via dedicated Identity and Access Governance solutions, such as Brainwave or Varonis. We can imagine retrieving the rights assigned directly in the Azure AD and having them verified to the owners of the resources through these tools.

This scenario is a variant of Scenario 2, which allows the most mature companies in identity and access management to capitalize on existing tools and processes.

Finally, do not neglect the surveillance of this exposed population

It is useful to build a form of adapted reporting using KPIs and dashboards. A pool of information is available natively in the Azure AD (date of last connection, activity on the tenant as well as on Office 365 via the “unified audit logs”). This information can be interacted with via visualization tools, like Power Bi, for the generation of dashboards.

Secondly, it is important to monitor the activities of these particularly exposed populations. Two levels of detection can be set up depending on monitoring capabilities:

• Implement native DLP rules or classic alert scenarios in the Microsoft console: some alert scenarios are preconfigured, such as mass deletion of documents, elevation of privilege etc.
• Implement advanced DLP rules and detection scenarios or specific thresholds for guests with the support of the company’s SOC. For example, the data download threshold allowed for a guest may be lower than the threshold allowed for an intern.

We can imagine the use of the Azure AD Identity Protection module to trigger alerts for guests with a high level of risk.

In conclusion, AAD B2B greatly facilitates collaboration, but its configuration needs to be hardened to reduce the level of risk induced by the solution

AAD B2B greatly simplifies collaboration with users outside the company, but entails risks related to the default operation of the solution. To control these risks, it is necessary to reduce the level of open access, and to control the lifecycle of these identities at a deeper level, depending on the potential level of investment that is planned. Finally, it is necessary to focus on monitoring via native tools or tools used by the company given the high exposure of these populations.

Cet article MS365 101: Manage Azure AD B2B Guest Identities est apparu en premier sur RiskInsight.