This blog has been written in collaboration with the Jisc Trust & Identity and Cyber Security teams.
Jisc has recently become aware of a potential security risk associated with the default Azure Active Directory (AAD) security settings that are commonly in place across our membership. If your organisation uses AAD (or plans to use it), then please read this information and/or pass it onto relevant team(s) within your organisation for action as a matter of priority.
The Issue
The default configuration setting for User Consent within Azure Active Directory enables all users (including students) to connect third-party applications to your Azure tenancy without any administrator involvement. These applications then have the ability to read data about users such as names, email addresses and other information populated in user profiles.
Most organisations deploy AAD with default settings for User Consent and do not apply more restrictive settings that enable administrators to first review the legitimacy of applications before connecting them to the domain. There are two main issues at play here:
- Firstly, there have been cases where these default settings were exploited to execute malicious code and to harvest user details for subsequent use in phishing campaigns. In other cases, the data has been disclosed to third parties for marketing and other purposes.
- Secondly, although individuals may technically have agreed to share their data when they connected to each app, it is unlikely that many will have read the full Terms and Conditions where that information could have been found. Given recent publicity over unwanted data sharing between apps, a setting that limits sharing may be better for both users and the institutions whose systems are involved.
Microsoft’s recommendation
Microsoft recommends applying more restrictive User Consent settings to reduce the attack surface. However, new tenancies are still deployed with the most permissive configuration as default.
Note that enabling the more restrictive User Consent settings is a prospective measure only. It will prevent new applications from being granted access without appropriate review, but applications that have already been permitted (prior to restricting User Consent) will retain access. Therefore, you also need to audit all applications that have been enabled and remove any that are of dubious origin.
Our Recommendations
All organisations, when deploying any solution, should be assessing their deployment against best practice (in particular least privilege). All recognised standards that Jisc is aware of would flag the default User Consent settings as a risk. Note that Secure Score only logs this as “Do not allow users to grant consent to unmanaged applications” (in reference to the admin consent workflow), while Azure Defender flags it in greater detail under regulatory compliance including subsequent controls which should be deployed to ensure applications and consent are controlled correctly within Azure AD.
Therefore, we recommend that you:
- Apply more restrictive defaults to User Consent. New applications will need approval by Azure AD administrators before they are granted access to read profile data [1]; you can configure the admin consent workflow to manage this [2]. More specifically:
- Ensure that ‘Users can register applications’ is set to ‘No’
- Ensure that ‘Users can consent to apps accessing company data on their behalf’ is set to ‘No’
- Ensure that ‘Users can consent to apps accessing company data for the groups they own’ is set to ‘No’
- Note that making the above changes to increase control and security may obviously impact productivity and the existing workflows that users may have come to expect.
- Audit all existing applications connected to your Azure AD domain and remove applications that are not relevant to the learning, research, and business objectives of your organisations [3]. If your organisation is A3/E3+ licensing, then consider O365 Cloud App Security Policy for “OAuth app anomaly detection” with effective alerting and governance actions applied. This will not only apply to new applications but also existing established applications.
The above is a clear example of the shared responsibility model which applies to all use of public cloud; all aspects of Azure AD (or any other cloud component) should be critically reviewed before they are deployed. This includes enabling or disabling functionality which isn’t always on “out-of-the-box”, including services such as Multi-Factor Authentication and the Admin Consent Workflow. It is the responsibility of the customer to deploy Azure AD in line with best practice. If you have any questions and queries, please feel free to email cloud@jisc.ac.uk.
[1]: Recommended reading on potential risks associated with the defaults noted here are available in the following blog post https://bit.ly/3lpUjKd. Technical details for making this change within Azure AD can be found in Microsoft technical documentation at https://bit.ly/38zFL7m
[2]: Further details on this can be found in the Microsoft technical documentation at https://bit.ly/3xtHKmN
[3]: Technical details for how to view and manage existing granted permissions can be found in the Microsoft technical documentation at https://bit.ly/35r2pMq.