Step up your Conditional Access game

by Niklas Tinner 2 years ago 5 min read

Prerequisites

Before we start, I would like to mention that there are currently already two posts online, that deal with Conditional Access:

Important aspects to Conditional Access, introduction to the topic and thoughts from the field
Conditional Access examples field based Conditional Access policies which I recommend

My plan for this post is to give a technical-oriented project guide on how to start with Conditional Access. This also requires you to be familiar with the general concept. After reading & understanding, you should be ready to secure your environment! Conditional Access is state of the art, when we talk identity & access management.

Collect data & information

Initially you should know how MFA and Conditional Access can benefit your cloud security posture. One thing in advance: MFA is the easiest way to achieve security. So this is why we concentrate on this. But there is so much more and maybe MFA constitutes a challenge for your users. In the first step we are going to discuss some of the key points.

Conditions

But which information is important? I will ask you some questions, which you can then use later to define a concept and subsequently a control set.

Which types of user do you have in your environment?
Usually there are:
- Privileged users (some type of admin role)
  - -> should always need MFA
- Dedicated users (user affinity, e.g. niklas.tinner@oceanleaf.ch)
  - -> actions taken if sign-in is suspicious
- Shared-/general users (e.g. info@oceanleaf.ch)
  - -> should not be accessible outside of the corporate area (IP-ranges)
- External users (AAD guests)
  - -> MFA when they access confidential information
Where are corporate sites? (geographically and IP-ranges)
Does your organization has multiple sites? Are there any front-line workers, that don't always have the same working space? Usual location categories include:
- Corporate IP-ranges (marked as trusted location in CA)
  - -> actions will probably not be triggered
- Domestic country
  - -> actions will probably be trigged (when users access information from home)
- Foreign/unknown country
  - -> actions must be taken
- Banned locations
  - -> sign-in blocked (Define a set of countries where sign-ins never take place).
Which app or task is affected?
At the heart, it's all about authentication to a resource, so it's relevant to identify the workload/app/service that is affected by the Conditional Access policy. It's even possible to set the Client apps (Modern authentication clients Browser or mobile clients and desktop apps | Legacy Authentication clients Exchange Active sync, all Other clients and protocols like POP, IMAP or SMTP) If you want to secure every resource, it's the easiest way is to target 'all cloud apps'.
What is the expected/targeted condition?
Last but not least, we should talk about the condition, that you allow or disallow. Basically you have to option to specify the Device Platform (Android, iOS, Windows Phone, Windows, MacOs) and Device state (Hybrid Azure AD Joined, or marked as compliant).

Get logs and test stage

Perhaps you don't know the answers to all this questions. But this is where logs can help out. My attempt would be to overview the sign-in logs of different groups of users and know their behaviour. For more information, a log querry on Log Analytics Workspace is what you want to go for.

Next, always run the policies in 'Report-only' mode, so you can get a rough idea of the impact of the policy, without having a real field impact. But we also need to analyze the logs.

For a deeper dive, take a look on Logs & Monitoring in Azure AD.

Example 1: investigate, where logins come from geographically
This chart shows, over a period of time, where sign-in attempts came from geographically. Now it's your turn to decide, whether those were legitimate or not.

sign-in-location

//Signins form locations, piechart
SigninLogs
| where Location != ''
| summarize count() by Location
| render piechart

Example 2: Sign-in logs, detailed
In the 'SigninLogs' table you can see all available information on a sign ins. Filter with '| project' or do a 'where' to refine the output.

sign-in-logs-1

Control set

Grant

There are three possibilities for a grant control:

Block access - no sign-in allowed, blocked after authentication
Usecase: Sometimes it's the easiest way, to completely block certain conditions, for example: privileged access, which comes from a foreign or unknown location. Or countries that no worker ever will ever log on from.
Require controls - Here you need one or more methods of: MFA, HAADJ or compliant device, approved client app or password change.
Usecase: Sign-in from outside of the corporate area or access to confident resources.
Grant access - Allow access.

Session

To have granular control, there is the possibility to intervene the session with CA.

Use app enforced restrictions - Custom admin configurations for apps. (Microsoft proprietary)
Use Conditional Access App Control - Works together with Defender for Cloud Apps, including reverse proxy architecture to configure access and session in cloud apps.
Sign-in frequency - time, until a user needs to sign-in again
Persistent browser session - remain signed in, even after closing the browser
Customize continuous access evaluation - revoke tokens in real-time
Disable resilience defaults - behavior on an Azure AD outage

Once more said, always exclude your breaking glass admin!

Concept considerations

Start enforcing in an organization

Conditional Access is compulsory for modern Microsoft cloud tenants. Sooner or later your organization should think about the implementation of policies and control sets. Based on my experience, it's important that those security requirements come from the management level. The IT department should worry about the technical realization and also give effective, modern and explainable examples of whats possible with this technology to the management. Also inform and communicate to people, when new policies are planned to set live. The people should understand what's affected and what the right (secure) way is, to work.

Design a coordinated system of policies

Another thing to mention is the use of too much or ineffective policies. You should get rid of any of those. I determined, that it is key to have a coordinated CA policy set. You should know what each of those is doing and also at the same time, no attack surface should get unveiled. (e.g.: special user groups or applications are forgotten). Try to design multiple concepts. This will be a benefit to: the understanding, the documentation and future adaption and show the strengths and weaknesses of the system.

Pro tip: CA templates

There is a relatively new feature, where a common set of Conditional Access policies are available as a template from Microsoft. Especially for new environments, this is what you want to go for:

ca-policy-templates