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.

Scanning uden credentials

“Unauthenticated scanning”, også kendt som scanning uden credentials, er den mest simple og mindst præcise scanningsmetode. Her foretages scanningen uden at scanningssoftwaret er logget ind på hver af de enheder, der scannes for sårbarheder. Denne type scanning bruges typisk fordi den er hurtig at udføre og kræver færre ressourcer. Der gøres udelukkende brug af offentligt tilgængelige interfaces på enhederne, samt de informationer, den ellers kan samle om aktiverne ”udefra”.

Denne type scanning kan kortlægge, hvilke enheder man har eksponeret mod internettet, og identificere gængse sårbarheder, som påvirker enhederne. Det kan være i form af f.eks. SQL injections, cross-site scripting (XSS), eller andre kendte sårbarheder på de versioner af software, der køres på enhederne.  

Det giver et realistisk billede af, hvad en hacker vil finde på sin scanning, da de typisk ikke har fået fat i credentials endnu, når de scanner. Men formålet med en sårbarhedsscanning er oftest at få så meget med som muligt og holde god hygiejne – low effort, high reward – og hvis man ønsker mere realistiske scenarier, er det de manuelle pentest, der kommer i spil. Derfor er det næsten altid at fortrække, at kunne scanne med credentials.

 

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:

  1. Create new policy
  2. Give it a proper name
  3. Select “All users” and Exclude your Break-Glass account.

  4. Under “Target resources” select “All cloud apps”

  5. Under “Grant” choose Grant Access and “Require multifactor authentication”

  6. 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:

  1. Create new policy
  2. Give it a proper name
  3. Select “All users” and Exclude your Break-Glass account.

  4. Under “Target resources” select “All cloud apps”.

  5. Under “conditions” select “Client Apps” – Set Configure to “Yes” and put a mark in “Exchange ActiveSync clients” and “Other clients.”

  6. Under “Grant” choose “Block Access”

  7. 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:

  1. Create new policy
  2. Give it a proper name
  3. Select “All users” and Exclude your Break-Glass account.
  4. Under “Target resources” select “All cloud apps”.

  5. 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:

  6. 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.”
  7. 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.

13 + 4 =