Have you been wondering where to start when protecting the Microsoft Cloud? One effective approach is to start at the newly named entry point to the Microsoft Cloud – Entra, where Conditional Access is found as a central element.
Among other things, this limits access to authorized persons, devices and platforms and enforces additional protective measures by means of grant controls. This reduces the attack surface and the success rate of attackers. The Azure and M365 environment should have end-to-end protection so that every company is armed against attacks. Microsoft recommends implementing Zero Trust. To that end, Microsoft offers a variety of settings and add-on products. Therefore, it is not easy to choose where to start.
Table of contents
Preliminary Steps to Design Azure Conditional Access
Successfully building Azure Conditional Access requires clarity on what the most sensitive data and services are in the your Microsoft Cloud. There are many roles in Azure with different functions. Therefore, you should define and document which roles your company wants to use. This shows which of these administrators and special accounts are important to protect. Furthermore, it should be known which functions or applications store sensitive information. Do all employees from all over the world need to be able to access the Azure tenant? The access should be restricted as much as possible. If your company also uses Microsoft Intune, there are possibilities to only allow devices that meet a certain minimum security standard. It is therefore important to consider what criteria the company’s devices must meet to be considered secure.
Essential Conditional Access Policies
Specific rules can now be created from the considerations above. Conditional Access Policies (CAP) enforce controls, before the actual access to the resource. This is done directly after the identification of the user when entering the cloud (Entra). Various considerations from the last chapter can be implemented in different security settings. It is therefore advisable to define the Microsoft security components for which the settings should take effect. The following points, graded according to security level, are recommended for implementation in CAP:
The minimum that should be required in the CAP is:
- enforcing multi-factor authentication for all accounts, and
- blocking legacy authentication mechanisms.
For a medium level of security, the additional protective measures are as follows:
- Unused platforms must be blocked.
- Devices for access must meet minimum standards (compliant devices).
- Access must be geographically restricted geographically restricted (allowlist).
- Categories of data criticality must be created for Azure and M365 applications and enforce additional barriers of entry with additional grant controls:
- Possible levels:
- High: at least two or more controls
- Medium: two controls
- Low: zero to one control
- Possible levels:
For a high level of protection, the following additional protective measures should be taken:
- Registration or modification of security information should be secured with at least two controls.
- Registering or changing devices should be secured with at least two controls.
- Administrators or administrative functions should only be performed via privileged access workstations and identities with increased protection. Additionally, there should be as many controls as possible to minimise unauthorized access further and this access should be time-limited as well.
- All recommended policies from Microsoft should be considered.
General Advice on Implementing Conditional Access Policies
Whenever possible, the variant with the fewest exceptions should be selected for a CAP. Since there are mutual overlaps or gaps in many rules, as many scenarios as possible should be tested via the what-if-tool. This ensures that there are no gaps in the ruleset. There are also specific tools for testing certain policies, such as the MFA-sweep for testing multi-factor authentication.
If you want to start form the ground up, consider the blog entry by Daniel Chronlund. It contains a lot of interesting additional information for dealing with the CAP e.g., as infrastructure in the code.
When developing the policies, it is recommended to create them in “report only” mode. Afterwards, it should be checked in the logs or in the what-if-tool whether everything works as intended before they are implemented. This is especially important for administrative access to minimize the risk of locking yourself out.
Microsoft recommends creating two emergency accounts (break glass accounts) and excluding them from all CAP. In this process, the Microsoft protection specifications for emergency accounts should be adhered to.
Conclusion
The main work in implementing conditional access is to work out and consider which identities, data or resources in Azure should be protected, and in what form. The recommendation is to put at least 4 times the effort into these considerations first. As an absolute minimum, multi-factor authentication should be required for all identities in the cloud and legacy authentication mechanisms should be blocked. In order to have your conditional access policies checked, it is advisable to request a targeted configuration review or advice from a penetration testing team. We look forward to hearing from you.
