Introduction
This article is relevant only for organizations that are actively using or beginning to use Conditional Access Policies.
In the ever-changing cybersecurity landscape, it is critical to stay ahead of potential attack vectors. The increase in cloud-based infrastructure means this area is more targeted. The purpose of this article is to help organization’s limit their exposure to this threat.
APT29 (a threat group attributed to Russia’s Foreign Intelligence Service) is famous for utilizing cloud attacks against huge companies, for example, the attack against Microsoft itself. As more attacks of this nature are published, it is typical for other attackers to follow suit and start exploiting these misconfigurations in creative ways.
OBS! Read this before you implement policies
Before you dive into the policies, please make sure you read the information below titled Break-Glass Account and Report-Only Mode.
Report-Only Mode – avoid breaking down business operations
It is important to understand that, when creating policies and enforcing them, they will trigger any user in scope when they log in. Therefore, the conditions set should allow users the ability to continue.
To avoid breaking business operations and minimize disruption for users, it is wise to always set Conditional Access Policies in Report-Only mode to start with. This way it is possible for the administrator to evaluate that impact, before enforcing them in the environment.
You can read more about Report-Only mode in this link:
What is Conditional Access report-only mode? – Microsoft Entra ID | Microsoft Learn
The Break-Glass Account – check your parachute before you take off!
A Break-Glass account must exist before implementing policies to fulfill a set of conditions to allow further entrance in our tenant. The Break-Glass account is used as an Emergency Account, which can be used in case of locking yourself out of your tenant or for any other reason that would lock you out.
Examples on configurations for a Break-Glass account:
- Exclude from all Conditional Access Policies
- Store Credentials safely: Password Manager, or physically in a vault.
- Validate that the account works with current credentials on a quarterly basis
- If changes in IT staff have occurred: Job change, new hire or departure
- Must be a Cloud-Only account
- Give Global Administrator Role permenently instead of eligible.
Follow the guide via the link below for more information about a properly configured Emergency/Break-Glass account.
Manage emergency access admin accounts – Microsoft Entra ID | Microsoft Learn
“Must do” Conditional Access Policies
To help organizations avoid falling into the most obvious traps from these malicious actors, we have written a list of absolute ‘must do’ “Conditional Access Policies” in relation to Azure.
1. Require MFA for privileged users
The first baseline policy that must be implemented is requiring MFA for privileged users (Directory Roles). This is because Administrators have permission to perform tasks that can change the environment; therefore, they must be the most secure.
In Entra ID, it’s possible to create policies that target specific roles, rather than users or groups. These roles are called ‘Directory Roles.’ Using roles instead of users and groups, removes the potential for forgetting to enable a user for MFA, for example, when a user is promoted with a Directory role of significance.
As minimum, the following roles should be included in this policy:
- Global Administrator
- Application Administrator
- Authentication Administrator
- Billing Administrator
- Cloud Application Administrator
- Conditional Access Administrator
- Exchange Administrator
- Helpdesk Administrator
- Password Administrator
- Privileged Authentication Administrator
- Privileged Role Administrator
- Security Administrator
- SharePoint Administrator
- User Administrator
There are many more directory roles to choose from, and you can choose as many as you want.
By selecting them all, you would ensure that no one with a directory role would be able to avoid MFA.
To create this policy, follow guidelines below:
- Create a new policy
- Give it a proper name
- Select Users and choose “Select users and groups” set a mark in Directory Roles and find all the roles you want to be hit by this policy (Might as well take them all). Remember to exclude your Break-Glass account.
- Under “Target resources” select “All cloud apps”.
- Under “Grant” choose Grant Access and “Require multifactor authentication”
- Lastly, set the policy in “Report-Only mode” and create.
2. Require MFA for all users
To follow suit on the MFA for privileged accounts, it’s also strongly advised to have MFA for all users who are using Cloud apps, for example, OneDrive, Teams, SharePoint Outlook. Even though standard users might not manage operational procedures that could affect the operations of a business, those users are still sending mails, sharing items etc., through those applications.
This data could be sensitive and should not get into the wrong hands. Other important measures to prevent leaking sensitive data can be taken, however MFA remains a valuable tool to safeguarding your environment better.
Using MFA, you can protect against common attacks like:
- Keyloggers
- Credential stuffing
- Phishing
- Spear phishing
- Brute Force and dictionary attacks
To create this policy, follow guidelines below:
- Create new policy
- Give it a proper name
- Select “All users” and Exclude your Break-Glass account.
- Under “Target resources” select “All cloud apps”
- Under “Grant” choose Grant Access and “Require multifactor authentication”
- Lastly, set the policy in “Report-Only mode” and create.
3. Block Exchange ActiveSync and legacy authentication protocols
It is important to block Exchange ActiveSync, since it’s not something we should use in general. If not blocked, it can be used to Bypass our MFA setup, since the Exchange ActiveSync does not support this form of modern authentication. Exchange ActiveSync is used by applications like Samsung Mail, Apple Mail, and other mails alike.
Legacy Authentication protocols like POP3, IMAP, and SMTP should also be blocked, as they do not support modern authentication either and could be used by adversaries to bypass MFA. Legacy authentication should always be disabled.
To create this policy, follow guidelines below:
- Create new policy
- Give it a proper name
- Select “All users” and Exclude your Break-Glass account.
- Under “Target resources” select “All cloud apps”.
- Under “conditions” select “Client Apps” – Set Configure to “Yes” and put a mark in “Exchange ActiveSync clients” and “Other clients.”
- Under “Grant” choose “Block Access”
- Lastly, set the policy in “Report-Only mode” and create.
4. No persistent browser session for unmanaged devices
To prevent users from having long-lasting sign-in to browsers with their Company accounts on unmanaged devices, we recommend implementing browser sessions with time limits. This means that whenever users are using an unmanaged device to login to company related items through the browser, they can only be logged on for a limited period.
To create this policy, follow guidelines below:
- Create new policy
- Give it a proper name
- Select “All users” and Exclude your Break-Glass account.
- Under “Target resources” select “All cloud apps”.
- Under “Conditions” we must set a filter for device rule syntax. Select “Filter for devices” and set configure to “Yes” in the Rune Syntax builder, set Property to “IsCompliant”, Operator to “Not Equals” and value to “True”. This should create the Rule Syntax as seen in below picture:
- Under Sessions, we must state the sign in frequency, and the persistent browser sessions.
Click on “Sign-In frequency” set a mark in “Periodic reauthentication” and set the value to 2 hours. Then mark the “Persistent browser session” and in the drop-down menu below, select “Never persistent.”
- Lastly, set the policy in “Report-Only mode” and create.
5. Other recommended Conditional Access Policies
There are many useful Conditional Access Policies to enforce in a tenant, however, not every policy fits into any tenant, and not all can be used due to license requirements. The following list includes other recommended policies, to help enforce a strong defense against attackers:
- Block access from unknown and unsupported devices
- Require compliant or hybrid joined devices
- Block access by location, specifically geological (China, Russia, North Korea, Iran, etc.)
- Require MFA for Intune Enrollment (Registering or Join devices)
- Require MFA for risky sign-in
- Require MFA when registering security information (Self-service password Reset)
- Require PAW for Administrators (Privileged Access Workstations)
- Block Authentication when sign-in risk is high.
Summary
Though all tenants are not the same, due to different licenses, the use of Conditional Access Policies can prevent most attacks trying to get a foothold into your organization, either through user manipulation or exploitation. It is critical to enable the bare minimum requirements for your tenant and help prevent the most heated attack vectors against users.
Each organization differs from another and requires an approach that is unique. This effectively means that each organization can have unique needs when implementing Conditional Access Policies and may therefore exclude specific users.
Be aware that, for every exclusion you decide to make, the less effective your defense becomes. For every exclusion, you are accepting an increase in risk, and that risk should be explainable and justified.
Vil du ringes op?
Benyt kontaktformularen, og vi vil ringe dig op inden for 48 timer.
Seneste kommentarer