These new mobile uses, increasingly based on smartphones and tablets, introduce new risks that must be controlled. Indeed, the company’s attack surface increases considerably because of the very nature of these devices. The main risks associated with the use of mobile devices include : 

• Theft or loss of the device, and therefore in particular of locally stored data, which may lead to remote access to company data 
• The use of unmanaged mobile devices. This lack of control may enable risky behaviours such as the use of uncontrolled networks (e.g., public Wi-Fi), the installation of unmanaged third-party applications, delays in O/S security updates, or even mobile device jailbreaking 
• Risky wired or wireless data exchange with other devices (e.g., USB synchronisation with a computer, AirDrop, etc.) 

The observations below confirm the reality of these threats. Indeed : 

• 53% of mobile devices have access to more sensitive data than a year ago (source: Akamai), 
• 45% of organisations have recently faced a mobile-related compromise (source: CTM), 
• 85% of mobile phishing attacks occur outside email apps, through other vectors linked to mobile uses (source: Verizon). 

Securing mobile devices cannot be effective without a clear corporate strategy defining authorised uses, control levels and associated responsibilities. 

Mobile security has been postponed for a few years, with efforts focused on workstations, even though it can directly threaten the security of the information system. Thus, while GPOs (Group Policy Objects) were commonly used to manage computer fleets, mobile devices did not simply inherit this approach. 

To meet this need, historical providers of computer security solutions (Microsoft, Ivanti, IBM, etc.), as well as new players (ManageEngine), offer SaaS or on-premises software to address the need to manage and secure mobile devices: MDM solutions (Mobile Device Management). 

Beyond actively contributing to securing a company’s mobile fleet, MDM improves the user experience by ensuring that users have an up-to-date device that continuously complies with company requirements. 

In this article, we explain how to secure corporate mobile devices using an MDM solution, which is a must-have in the race to secure information systems, and share recommendations on their configuration. 

Mobile usage policies : a corporate strategy to define 

In companies, mobile device usage policies have evolved significantly. 

Today, we distinguish three of the most common usage models in organisations (detailed at the end of this section in Figure 1): 

• COBO – Corporate-owned, business only 
• COPE – Corporate-owned, personal enabled 
• BYOD – Bring your own device 

First, it is necessary to define the company’s strategy for these mobile uses: are mobile accesses authorised and legitimate from a business perspective? If so, many additional questions must be addressed when defining the corporate strategy: 

• Which users are authorised (VIPs only, all internal users, external users as well, etc.)? 
• Which types of mobile devices are authorised (company-owned, personal, or both)? 
• Which applications or data may be accessed (email only, the full collaborative suite, etc.)? 

This strategy is central to provide direction and guide the subsequent security efforts. It will make it possible to better target the risks applicable to the company, better control its information system and define rules that are consistent with authorised or unauthorised uses, while providing users with clarity on accepted and prohibited practices. 

Figure 1 : Mobile device management profiles 

Securing mobile devices through 4 tools : MDM, MAM, EMM and MTD 

Before going into detail on MDM-like tools, it is worth to remind that several complementary solutions exist for securing mobile devices. These tools operate at several stages: 

• MDM (Mobile Device Management) : fleet management and corporate device security tool (mainly at OS level) 
• MAM (Mobile Application Management) : application management and security tool (mainly at application level) 
• EMM (Enterprise Mobility Management) : a tool centralising MDM and MAM functionalities 
• MTD (Mobile Threat Detection) : a tool for detecting attacks on mobile devices, similar to Endpoint Detection & Response (EDR) for laptops (OS and application layers) 

The figure below illustrates this ecosystem within a mobile device: 

Figure 2 : The enterprise mobility security ecosystem 

An MDM, MAM or MTD does not address the same needs and secures the mobile fleet at different levels. The next sections of this article focus only on MDM. 

MDM solutions address the need to secure devices owned by the company, and therefore the COBO and COPE policies described above. 

A key consideration on BYOD: it is important to keep in mind that devices not owned by the company cannot be fully configured by the company. To secure the BYOD use case, i.e. access to company data and applications from an unmanaged device, MAM solutions can address the need by securing applications and creating a professional container. 

In the rest of this article, the BYOD case is considered out of scope. Since the device belongs to the user or to a partner company, the company does not truly control the configuration and security of these devices, as it can hardly require the user to install certain configurations or applications, or to share certain device data. However, it is possible to harden access to the information system to make BYOD usage impossible, but this requires an in-depth impact analysis, considering all use cases (multi-factor authentication on mobile, management of partners and external providers, conflicts between fleet management tools, access to training, etc.). 

Mobile Device Management at the heart of securing corporate mobile devices 

Mobile Device Management tools make it possible to effectively administrate and secure a complete fleet of mobile devices through three core functions, which are detailed below: 

• Fleet management : know and configure the devices accessing the information system, and deploy company or third-party applications. 
• Compliance control : ensure that devices comply with the company’s security policies and standards. 
• Security and hardening : implement security measures on devices to strengthen protection against threats. 

Note: The following paragraphs aim to present features offered by most MDM solutions; the availability of the desired features should be verified before subscribing to any MDM solution. 

Administering the corporate mobile device fleet: inventory, administration and provisioning 

In response to security and regulatory requirements for device management, MDM centralises many mobile device management features in a single interface: 

• Deploy/remove : MDM facilitates the provisioning of new corporate devices for IT teams, potentially remotely with installation of company configurations and business applications, as well as the removal of these configurations and the deletion of company-related data when needed, for example at end of device life, in case of suspected compromise or theft (wipe-out function). 
• Manage : MDM inventories all corporate mobile devices and presents their key attributes, for example OS type, OS version, owner name, encryption status, IMEI, last connection date, etc., while ensuring compliance with the General Data Protection Regulation (GDPR). 
• Monitor : alerts can be configured in MDM solutions to monitor the health of the fleet and identify any deviation from the rules previously defined by the company. 
• Support : MDM includes remote-control and device diagnostic features to facilitate interventions by IT teams. 

By providing up-to-date data on the mobile fleet, MDM can help meet various regulatory requirements, particularly regarding knowledge of and ability to manage the fleet, as well as reaction capability in the event of compromission. Several regulations, for example ISO 27002 (section 5.9 Inventory of Information & Other Associated Assets), require companies to identify and manage their devices. 

This centralisation provides an overall view of the fleet, while also enabling classification for better administration. In particular, device tagging or grouping systems make it easy to manage subsets of devices that may have configuration variations or exceptions (depending on business needs, for example network teams, VIP users, etc.). 

Compliance policies : assessing the compliance of mobile devices accessing company data and applications 

More than just fleet management software, MDM solutions can assess the mobile fleet against corporate security policies, known as compliance policies. 

Highlighting non-compliant devices can be essential in order to take targeted action: for example, removing their access to the information system through conditional access if the device is jailbroken or does not run the latest OS versions. Since this assessment can be performed at each device connection, fleet compliance can be considered continuously up to date. 

This major MDM feature should be fully leveraged. A non-compliant device represents a risk to the company and its information system (presence of unpatched vulnerabilities, etc.). To avoid harming team productivity, the user can be notified as soon as non-compliance is detected, and access rights to company data can be removed through conditional access if the non-compliance is not resolved, by adjusting the compliance status validity period. 

Configuration profiles : configuring devices deployed by the company

When corporate mobile devices are provided to employees, a configuration should be applied to protect these devices and align them with a predefined baseline: this is made possible through configuration profiles. 

To secure mobile devices, it is possible to customise the baseline in order to professionalise the device, across various platforms (iOS, Android). Common baseline hardening measures include: 

• Hardening of security configurations and feature restrictions; 
• Deployment of company configuration; 
• Restriction of third-party application installation outside the application store. 

Devices can then check for the latest configuration profile updates and apply them (frequency to be defined – recommendation: once a day). This setting helps ensure the device remains as close as possible to security best practices at all times. 

We recommend the following measures when using an MDM solution: 

• Push the security configuration during device enrolment, including at least: 
• Hard drive encryption 
• Hardened authentication policy (six-digit passcode or biometrics, with simple passcodes blocked) 
• Deploy OS and application patches directly 
• Detect and block non-compliant devices (at minimum, jailbroken devices) 
• Deploy an action plan for non-compliant devices (alerts, blocking, etc.) 

In summary, MDM is a fundamental building block and a prerequisite for securing access to the information system 

MDM solutions offer numerous interfaces, particularly with other security tools. 

In particular, to fully benefit from MDM, it is common and recommended to interface it with the company’s Identity Provider (IDP). Integrating MDM with the identity and access management solution for the information system enables conditional access based on device compliance or attributes (for example, removing remote access to company data for mobile devices that do not comply with the compliance policies defined in the MDM). This contributes to Zero Trust strategies by strengthening the company’s posture through greater control over access to its information system. 

It is also possible to connect the MDM tool with Mobile Threat Defense (MTD) solution. This interface with a complementary mobile device protection tool enables information to send back device compliance and health information to the MDM, or whether it presents compromise risks (malware, connection to an unsecured network, etc.). This analysis of the device and its risks can then condition access to the corporate information system. 

Finally, although accumulating MDM solutions is not recommended, it is sometimes necessary to interface the MDM solution with other MDM solutions in order to centralise information and manage the entire fleet centrally. For example, it is common to interface Microsoft Intune with Apple Business Manager MDM, which may contain the full database of iOS devices. 

Conclusion : key elements to effectively secure a mobile device fleet 

In a context of increasing mobility in companies, MDM clearly stands out as a must-have in the race to secure access to corporate information systems. 

More than a simple centralised inventory of mobile devices, this solution also simplifies the end-user experience by providing a hardened and secure turnkey device that complies with corporate policies. 

To implement an MDM solution effectively, organisations should : 

• Cover all mobile devices in the fleet (all types, brands, platforms and business functions): the robustness of an information system is assessed by its weakest links 
• Formalise a mobile device management policy adapted to the company’s needs, without major constraints for end users, in order to avoid user misbehaviours and reduce business impact 
• Translate this policy into configuration profiles and compliance policies, and keep them up to date 
• Raise user awareness of the chosen corporate policy by sharing a corporate mobile device usage charter with users, explaining the benefits of centralised management and respect for user privacy, which requires a clear corporate strategy 
• Consider mobile security as a whole, and in particular address BYOD in parallel to avoid workarounds through this channel, by combining MDM deployment with MAM deployment, in order to cover, for example: 
• The risk of data leakage (local storage on an unmanaged device, synchronisation with personal cloud services such as Google Drive, unintentional sharing via unsecured applications) 
• The risk of data interception over unsecured connections (cafés, hotels, transport) 
• The risk of malware propagation across the information system 
• In summary, while MDM is now an essential foundation for securing corporate mobile devices, its effectiveness depends above all on a clear corporate strategy and a sufficient level of device hardening. 

The most mature organisations can then complement this foundation with MAM and MTD solutions, following a progressive approach adapted to their challenges (in particular, deploying MAM to enable BYOD use cases). It should be noted that MTD solutions are currently not widely deployed, with priority given to implementing the MDM and MAM combination which, when properly configured, can cover a large majority of mobile use cases, from managed corporate phones to personal phones. 

Cet article Securing mobile devices : Introduction to MDM (Mobile Device Management)  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.