Hitchhiker's guide to Cloud and Security

Azure Active Directory (Azure AD) includes a feature called Conditional Access Policies that allow administrators to define specific conditions for granting access to specific cloud applications or assign controls to actions or authentication context. These policies evaluate a number of different signals that are available at the point of user authentication to determine whether or not to grant access to the requestor, and if additional controls need to be enforced before granting access.

Some of the signals that are evaluated include:

• User identity or Group membership: This signal checks who is the authenticating user or whether the user is a member of a specific group. Conditional access policies can be setup to apply to all users, select users, guest users, select security groups. This signal is therefore used to determine if a conditional access policies should be enforced or if the user should be excluded from the same. For example, if the user is a member of a specific security group, access can be granted or denied based on that group membership.
• Application: This signal checks the specific application or resource that the user is attempting to access. For example, if the user is attempting to access the Azure Management Portal or a high-sensitive application, access can be granted only to a specific group of users or after additional authentication methods.
• Device state: This signal checks the device the user is attempting to access the resource from. For example, if it is a windows or an iOS device that is not compliant with the organization’s security policies, access can be denied.
• User location: This signal checks the location of the user attempting to access the resource. On Azure, it is possible to define a list of Trusted Locations for an organisation. For example, if an user is attempting to access the resource from any location other than the trusted locations, access can be denied.
• Risk level: This signal evaluates the level of risk associated with the user’s identity and location. The determination of the level of risk is done by Azure using a feature called Identity Protection. Identity Protection evaluates the risk level based on machine learning and other advanced technologies to detect and respond to potential security threats, such as suspicious login activity, compromised credentials, and abnormal usage patterns. For example, if the user is attempting to access the resource from a high-risk location, access can be granted provided the user can successfully complete the authentication process using MFA.
• Authentication method: This signal checks the method of authentication used to access the resource. For example, if the user is trying to access the resource using a method that is not allowed (e.g. password, biometrics, multi-factor authentication etc) access can be denied.
• Network location: This signal checks the network location of the user attempting to access the resource. For example, if the user is attempting to access the resource from a public network, access can be denied.
• Sign-in frequency: This signal checks the number of sign-ins the user has attempted in a specific time frame. For example, if the user is attempting to sign-in too many times in a short period of time, it could be a sign of a brute force attack and access can be denied.
• IP address: This signal checks the IP address of the user attempting to access the resource. For example, if the IP address of the user is coming from a blacklisted IP, access can be denied.
• Session duration: This signal checks the duration of the session, if the user has been logged in for a long time, access can be denied.

By evaluating these signals, conditional access policies can provide a flexible and powerful approach to securing your applications and resources. It allows administrators to set granular policies to control access based on a variety of factors, and to continuously monitor and adapt access controls as necessary to meet changing security needs. Organisation must remember to balance security and convenience, ensuring that these policies enhance security, but at the same time do not disrupt users from accessing the resources they need to perform their duties. It is always a good practise to start with implementing conditional access polies in the “report-only” mode. In this state, the organisation can continue to collect insights that can help them with their decision on whether to enforce a policy or not, or to evaluate if the policy needs any adjustments.

As far as naming conditional access policies on Azure goes, it’s important to use a consistent and clear naming convention. This will make it easier to understand and manage the policies, and will help ensure that the policies are applied correctly. Here are some best practices to follow when naming conditional access policies:

1. Use a consistent prefix or suffix: Use a consistent prefix or suffix to identify the type of policy. For example, you might use “CA-” as a prefix for all conditional access policies.
2. Be descriptive: Use descriptive names that clearly indicate the scope and purpose of the policy. For example, “CA-App1-Grant-MFA” would indicate that the policy is a conditional access policy for App1 that requires multi-factor authentication to be granted access.
3. Use a consistent format: Use a consistent format for naming policies. For example, you might use the format “CA-[Application]-[Condition]-[Requirement]”
4. Use lower case and avoid spaces: Use lower case letters and avoid spaces in the names. Use hyphens to separate parts of the names for easy reading.
5. Versioning: If you have to update the policies in future, it’s good to have version number in the policy name to keep track of the changes and it’s easier to roll back if needed.