AZURE AD CONSENT AND APPLICATION REGISTRATION SECURITY REVIEW

This document encompasses the security review requirements and due diligence, the security analysts will have to practice while handling the consent and app registration requests.

Before getting into the details, lets first understand the various type of consents and the security risks it may bring to the environment based on how they are granted.

There are several types of Azure AD consents.

1) User Consent: This type of consent is given by individual users who are members of an Azure AD tenant. They can grant consent for an application to access their own data or perform actions on their behalf.

2) Admin Consent: This type of consent is given by an administrator of an Azure AD tenant. This type of consent is required when an application requires access to directory data or the ability to perform actions on behalf of all users in the tenant.

3) Application Consent: This type of consent is given by an administrator of an application and is used to allow the application to access directory data or perform actions on behalf of users in a different tenant.

4) System Consent: This type of consent is automatically granted by Azure AD when the application is installed and is used to allow the application to access directory data or perform actions on behalf of users in the same tenant.

It is important for security operations to be aware of the security risks associated with granting consent for applications to access directory data and perform actions. The following are some key security risks to consider:

1. Data Leakage: When an application is granted consent to access directory data, it has the potential to leak sensitive information such as usernames, email addresses, and phone numbers. (Which could lead to personal data breach & can trigger regulatory implications)
2. Data Corruption: When an application is granted consent to perform actions on behalf of users, it has the potential to corrupt or modify data in the directory.
3. Malicious Applications: Malicious applications can be disguised as legitimate applications, and once granted consent, they can access directory data and perform actions on behalf of users. (which could lead to illicit consent grant attacks )

Also unused OAuth apps and credentials can be a backdoor for an adversary to gain access to an organization’s environment to exfiltrate data or use privileged credentials to access sensitive data in another app.

To mitigate these security risks, security administrators should take the following steps before approving any Azure AD consents or app registrations:

1. Carefully review the permissions requested by the application and ensure that they are necessary and appropriate for the application to function.
2. Verify the identity of the application publisher and the authenticity of the application.

Monitor the activity of the application to detect any unusual or suspicious behavior

CONSENT GRANT BEST PRACTICES

1. Look for suspicious URLs in the Reply URL/Redirect URL. Look for spell errors, redirect domain etc to verify if the app is genuine.
   
   2) Check if the domain is a) compromised b) domain recently registered c) temporary hosted
   
   3) Look for terms of service/service agreement link in the app registration. Most genuine application will have a well-defined documentation.
   
   4) Check if the contents are unique and specific to the application/publisher. — Always look for blue check mark in the consent grant screen
   
   5) Look for consented users if the app already exists in the tenant- Check the users and see if they are risky users.
   
   6) Always check for publisher verification in the consent grant page.
   
   7) Do not grant tenant wide admin consent grant for apps when not needed. Assigning required users through ‘ User assignment’ would be much more secure to reduce the attack surface.
   
   8) Application consent is riskier than delegated consent. Review the 3rd party security controls/ platform security and the data being exchanged ( like sensitive data, PII etc ) before granting access.
   
   9) Exercise caution while approving tenant wide permissions like Directory.ReadWrite.All, User.ReadWrite.All*, Domain.ReadWrite.All* etc.
   
   10) Some low impact permission lists are below
   
   User.Read, User.ReadBasic.All, Open_id, Email, Profile, Offline_access

AZURE AD APP REGISTRATION BEST PRACTICES

1) Always register applications to local tenant scope. Multi-tenant scope would be needed only if we want to publish apps outside your tenant

2) Maintain an owner list for all apps so we know whom to reach out during an incident.

3) Ensure to keep an inventory of approved Azure AD applications

4) Keep the client secret/ certificates securely and away from the application code

5) App ID and client secrets must be stored encrypted in the application and when possible, in a Key vault solution; these in combination can be used as a backdoor bypassing MFA to gain access to cloud applications.