Welcome to the Azure Security Podcast,
where we discuss topics relating to security, privacy,
reliability, and compliance on the Microsoft Cloud Platform.
Hey everybody. Welcome to Episode 38.
This week we have myself, Michael,
we have Gladys and Mark.
Sarah this week is actually flying across the Pacific Ocean.
So we'll hear more about her story,
hopefully in a couple of weeks.
This week we have a guest,
we have Daniel Wood who is here to talk to us about
Azure Active Directory Conditional Access.
But before we get to Daniel,
let's take a look at the news. Gladys, what we got?
I wanted to talk about Azure defenses for ransomware attack.
Basically, we've been releasing a lot of different guidance and
other information for protecting different workloads.
Recently, we released an e-book that lays out key Azure native
capabilities and defenses for ransomware attacks.
It provides some guidance how to proactively leverage
capabilities to protect the assets on Azure Cloud.
It explains how can assets in the Cloud be targeted,
how the attacks succeed,
different Azure native ransomware protection,
including built-in capabilities,
Azure Security Center detection,
recommendations and reports,
Sentinel Unified View.
So there's quite a bit of information in here.
It's only about 30 pages with lots of images,
so it shouldn't take long to read.
In addition, in public preview,
we are providing a scale management of
Azure Monitor Alerts in Backup Center.
A few months ago,
Azure Backup released in preview
new alerting solution built-in on Azure Monitor,
which enable users to act on critical backup incidents.
Well, now with this integration,
we provide the ability to view backups related alerts at scale,
across both, and also slice and dice alerts by
backup as specific properties such as workload type,
but both location, etc.
We also provide quick visibility at scale into
the active backups security alerts that require attention.
We also are providing the ability to configure and
manage notification as well as how to get
actionable interfaces that enable
navigation to virtual machines or
storage account that require attention.
Thanks, Gladys. A few things caught my interest over the last couple of weeks.
The first one is to do with Azure SQL Database.
They've now added some new roles that allow you to query
pretty sensitive metadata but without granting the need,
or without the need, I should say,
for admin access, like full admin access.
This is a really good example of
least privilege essentially granting people
just the privilege they need to do
just the job they need to get done.
It's great to see that.
Next one is Azure Site Recovery.
Now, we'll enable TLS 1.2 by default.
In fact, only TLS 1.2 as of November the 15th, 2021.
You have about six weeks to get that done.
It's not huge. I doubt many people will actually have a problem here,
but just be aware that that's coming down the pike.
Next is for Azure Virtual Machines.
There's now the ability to automatically perform key rotation.
It's managed automatically by Azure,
and that's for customer managed keys.
The next one is Azure Purview has now just gone generally available.
We had back in May,
we had Gopal Shankar who was here to talk to us,
and also Avin Chandakar was here to talk to us
about Azure Purview and Azure Information Protection.
It's nice to see that's now gone GA.
It's a fantastic product.
It's there for data governance,
being able to classify and identify data
and the lineage of the data within your organization.
A couple of things from my side,
both focused on OT,
operational technology and IoT security.
For those that weren't aware,
Microsoft acquired a company called CyberX about a year ago or so.
They've got some great technology.
We've got some great technology that helps with securing your OT environment.
Scata, ICS, Supervisory Control and Data Acquisition,
Industrial Control Systems,
those computers that control physical machinery
or monitor it, sensors and whatnot.
There's a couple of different things that we published recently.
One is the Defender for IoT Ninja training.
There's I think somewhere in the order of 30 videos or so,
and then documents and PowerPoint slides and other resources as well,
to learn about this technology,
learn about actually securing these environments.
All free downloadable, watchable stuff.
We got a link for that in the show notes.
Then also, I recorded a video with Fid Elabdelaoui,
who actually is a former CSO of Duke Energy,
one of the largest power companies,
if not the largest in the US.
I can't remember, but he's actually an executive security advisor over at Microsoft now.
He and I talked about the OT reference architecture,
security reference architecture that we included in
the cyber reference architecture, the MCRA.
We really go through all the different nuances,
what security controls are there and possible,
which ones don't work, what's different between IT and OT.
A couple of resources to help in that space now.
Now that we have the news out the way,
let's get to our guest.
This week we have Daniel Wood.
Daniel is here to talk to us about
Azure Active Directory Conditional Access.
Daniel, welcome to the podcast.
We'd like to spend a moment and introduce ourselves to our listeners.
Absolutely. Thanks guys for having me on.
It's great to be here.
Hey everybody, my name is Daniel,
and I'm a program manager on the identity security team.
I'm one of the product owners for
Azure Active Directory Conditional Access.
This is a topic that I'm really excited about.
I'm going to be asking a lot of questions, Daniel.
Why don't we start with explaining a little bit about
what Azure Active Directory Conditional Access is?
Sure. Conditional Access is a security feature in
Azure Active Directory and it basically lets organizations
control which users have access to
which resources under certain conditions.
Then you can also enforce controls such as
multi-factor authentication or
compliant devices or other sorts of controls as well.
The main reason why customers love conditional access is because,
the users are no longer just accessing
on-premises apps from a desktop computer at the office.
Over the past number of years,
we've seen a trend where users are now accessing
company resources from personal devices and
mobile devices in the office and on the go or at home.
This is all at the same time that
adversaries are increasingly trying to
access those same resources as well.
It's really possible to use conditional access to
lock down access to just the right people
needing the right resources under the right conditions.
One thing that I have seen is that people are not aware
of common verifications that they could use.
They are aware of some basic ones.
Can you describe some of the verifications?
Yeah, absolutely. As I was mentioning,
when you configure a conditional access policy,
there are a number of controls that you
can require during authentication.
Probably the most common one that you hear about
being talked about would be requiring multi-factor authentication.
There's a lot of nuances there like you could require
multi-factor authentication when there's
a high-risk sign-in or medium-risk sign-in,
or every hour or once a day or at the end of your session.
But then there are also a number of other controls as well.
You can require compliant devices,
those that are managed by Intune.
You can require hybrid Azure AD join devices.
You can also restrict access from
specific lists of approved client applications.
You can even enforce terms of use or other custom controls as well.
So how do we recommend deploying conditional access?
How much effort it requires?
Yeah, that's a great question.
I would say a lot of the customers that I talked to,
in some cases can be a little bit worried or nervous
about turning on a conditional access policy because,
maybe before turning it on,
most people were used to just having access and they didn't have
to worry about getting prompted or needing a compliant device.
So there's definitely this sense,
perhaps among admins that it might be
difficult to deploy conditional access.
When in reality, we've actually done a lot of work to make
it really easy and simple to deploy and also make it a predictable outcome.
So one of the things that I always say is that one of
the first oaths that an IT admin takes is very similar to a doctor.
You take this Hippocratic oath to first do no harm.
We think the same thing really applies to conditional access admins as well.
Ultimately, these admins are trying to create the best experience for their users.
So one of the ways that we recommend
deploy conditional access is to use what we call report only mode.
So what you can do is you can first turn on a policy in the audit mode,
where it will log how many users would have been prompted for MFA,
how many users would have been blocked by your policy,
how many users would the policy have applied to,
and then it generates a report and all these logs where the admin
can look at the summary of the activity and they can understand
whether they configure the policy the way that they wanted to,
or whether they need to go in and maybe adjust the policy so
that it doesn't apply to certain applications or under certain conditions.
So once you've run the policy in report only mode,
we also have another tool called the what if tool,
which basically lets you plug in a user and some sign-in situations.
You could say, I want to pretend what happens if I'm
a guest user signing in from outside the corporate network
from my personal mobile device accessing some corporate sensitive data,
and you can click the what if tool and it will basically
simulate the authentication and tell you
which policies would apply and what would happen.
So after you do those two steps,
most customers have a good sense of what the policy is going to do.
You could go ahead and slowly roll out your policy.
Some customers like to start off turning on a policy in
a test tenant to get a feel for what it looks like,
or if you're rolling it out in production,
you can roll it out and bring.
So you could start out with a small group of users in one organization,
and then you can slowly add groups to
your conditional access policy until it's
deployed throughout your organization or wherever you want it to play.
I love that do no harm idea.
I think that's fantastic.
I think that's something that actually a lot of security people could probably learn from.
I mean, the number of customers that I work with where security is there to
kind of like just say no and almost shut the business down.
You could argue that that's doing a lot of harm to the business.
So I love that idea.
I think it extends way beyond conditional access though.
But yeah, I just love that thing. It's great.
Yeah, absolutely. We're thinking about applying
that same thought process to other security features as well.
You can imagine there should be a report only mode for every security feature.
Yeah. Well, let's take another example.
I mean, as your policy,
I've seen people say, yeah,
we just turn this as your policy on.
If we break stuff, then we break stuff.
It's like, no, you can't just go breaking stuff left and right.
Do it in a well thought out way.
But again, I just love that idea.
It's like, do no harm.
I think it's fantastic.
I think you have a lot more security professionals thought that way.
I think there'll be a lot less friction between business owners and security in the long run.
But yeah, so I love that.
I think security folks out there who are listening to this,
take that to heart.
I think that's fantastic advice and a fantastic sort of mantra to live by.
I really, really do.
It is good to turn on all these conditional access,
but how can administrator get insight whether it's working
or how well it's working in the environment?
So over the past year,
we've made a number of investments in our reporting capabilities for conditional access.
And we have a number of ones that exist today
and also a number that we're going to be announcing in just a few weeks at Ignite.
So if you're interested in conditional access,
I encourage you to tune in and we have some really big announcements coming.
But in terms of what we have available today,
we have an insights and reporting workbook that's built in through conditional access.
And this basically allows you to see an overview of the impact
of your conditional access policies for your tenant.
So what you can do is you can select, say,
an individual conditional access policy,
maybe one that blocks legacy authentication.
And you can say, OK, for this conditional access policy,
I want to understand what are the common applications that were blocked?
Which are my users that were impacted?
And so you can use this dashboard in this workbook,
which is built on top of Log Analytics to analyze your data.
And as I sort of alluded to,
if you stay tuned to Ignite,
we're going to be releasing a brand new conditional access dashboard,
which will have a number of recommendations and actions that you can take
as a conditional access admin,
basically responding to insights that we've collected from your sign-in logs
and the activity of your users in your tenant.
So you mentioned sign-in logs.
When exactly does the verification take place?
Are there triggers through the session and starting the session?
Or if something changed within the session?
That's a great question.
And it really has evolved over time.
I would say at the very beginning,
and this is probably what most admins are used to,
is conditional access is evaluated at the beginning of the session.
You can sort of think about conditional access
as being the front door to the applications.
So yeah, so you sign in,
maybe you have an interactive prompt and you get a token
for the application that you're accessing,
and conditional access is absolutely evaluated there.
But also when that access token expires
and you use a refresh token to get another access token,
that happens silently in the background.
And every time you get a new token,
conditional access is evaluated again and again.
But as you mentioned,
there may be some security events,
maybe in the middle of your session,
and you may want to cut off access.
And so we've been investing in something called
Continuous Access Evaluation, or CAE,
which basically provides near instant revocation
for sessions to certain apps,
starting with Microsoft first party apps
like SharePoint, Teams, Exchange,
when we notice some sort of sensitive security event.
So this could include things like
we notice that you have elevated user risk,
maybe we discovered your password or credentials
on the dark web, and so we've updated your user risk.
Or maybe you reset your password,
or your device came out of compliance,
or maybe you were terminated,
and your account should definitely not have access
to any applications.
So this near instant revocation channel through CAE
is a really good way to make sure that
we can enforce these policies
in the middle of the session.
And the one last thing I'll say is,
last night we announced something called
authentication context, which is basically
a new way for conditional access to become evaluated
within an application.
So you can imagine, let's say a SharePoint site
where first you access SharePoint,
and maybe one conditional access policy will apply.
But then within SharePoint,
you may want to access some sensitive content,
or perform some sensitive action,
and that can actually trigger an authentication context,
which will then go and evaluate conditional access again.
So really conditional access has become
a really powerful tool for evaluating access.
At the beginning of the session,
but also during authentication context triggers,
and now with continuous access evaluation for CAE,
we can do near instant revocation events
for security events as well.
If I'm right, so conditional access
is an Azure Active Directory thing.
So how does this relate to Active Directory, if at all?
Our customers have the requirement
that their users are accessing apps from anywhere,
and they're all sorts of apps.
You have SaaS apps, you can have line of business apps,
and also on-premises applications.
So if you're asking about how you can apply
conditional access policies to protect
your on-premises resources, absolutely.
And we have a solution built in
through Azure Active Directory called App Proxy,
where basically you can set up a configuration
so when your users are signing in,
they first get routed through Azure AD signing,
when they try to access an endpoint
for an app that's sitting on-prem,
you would first go to conditional access,
and you can enforce any of the same policies
that you would for any other application,
and then if you succeed,
then you would be granted an access token
to that app on-prem.
I really love App Proxy.
It's basically an edge type of security approach,
especially when we build it
or when you use conditional access.
Let's talk a little bit about MFA.
What are MFA rankings?
How do you use them?
As I mentioned before, multi-factor authentication
is probably the most common control
for conditional access, and on my team,
one of the things that we're really laser focused on
is increasing the percentage of sign-ins
that are protected by MFA.
Our research shows us that you get 99.99% protection
by using MFA as opposed to single-factor authentication.
So it's a really great way
to prevent your account from being compromised.
But with that being said,
we favor some authentication methods over others.
So one of the things that we've been really focused on
is introducing passwordless authentication methods.
These are methods like the Authenticator app,
Windows Hello for Business, and FIDO tokens.
These are all really strong.
They're phishing resistant,
and they no longer rely on a password,
and they're really strong methods.
And then there are some other methods
that are really popular,
but you may want to consider switching out of,
such as SMS or text messages.
It's not very common that we see SIM jacking,
but it is definitely a security concern.
And we think that it's probably a more seamless experience
for you to be using other solutions
like the Authenticator app.
I'm so glad that you mentioned
that the Authenticator is phishing resistant.
I have seen customers that have been a bit confused
with Authenticator since you could have the SMS authentication
or phone authentication,
and they don't realize the difference.
Yeah, absolutely.
And there's a bunch of benefits that you also get
from using the Authenticator app.
For example, I think we'll soon be releasing the capability
for you to report notifications that you got out of the blue
that may have been prompted by an adversary trying to sign in.
You can even see your sign-ins
or risky sign-ins recently from within the app as well.
It's a much more integrated authentication experience.
So one thing that I see customers get confused
is there's conditional access that are user-based,
but there's also conditional access through Intune.
Can you explain how the interconnect
or are they separate?
They work together?
So if you're in the Microsoft Endpoint Manager console,
you will see that you do have the capability
to create conditional access policies,
and the two are really the same.
And we've created a great integration
with our partners over at Intune
so that you can require users to be coming
from a compliant device when they sign in.
And so you can require that as one of the grant controls
in conditional access.
And the way that works is we share intelligence and signals
about that device,
and basically all it is is the Intune team sets a flag
in Azure AD that basically tells us
whether the device is compliant or not.
And when you sign in, we look at that device fingerprint.
We cross-reference that with our device directory,
we can tell whether that device is compliant
with all the rules in Intune.
And then based off of the result,
we can either let you in or tell you that you've been blocked
and you need to update your device.
If I remember correctly,
we also integrate with NDE or Defender for Endpoint,
and we could do conditional access
if it shows indication or compromise.
Is that right?
Yeah, so we have a number of partners that we work with
to gather signal intelligence that helps inform
the risk profile of the user and of the sign.
So for example, if your device has malware
or it's not the proper version
or there's suspicious activity that we've noticed
related to that device,
that does inform some of the signals
for risk protection and identity protection for Azure AD.
So for example, if you were to create a policy
that blocks access to maybe low risk
or medium risk signs and your device had malware
or a virus or something like that,
that would actually trigger a risk event in Azure AD
and you'd be able to block access.
So with conditional access,
what kind of principles can I apply
conditional access policies to?
So up until now, policies were really just applied
for users accessing applications.
But we've seen over the last year
that adversaries are really taking advantage
of service principles and applications
to access sensitive resources in your environment.
And so we are about to release conditional access
for service principles
and what we'll be calling conditional access
for workload identities,
which will give admins the ability to now finally
apply conditional access policies
to your service principles in your environment,
which are then accessing
other sensitive resources or applications.
So this is a whole new paradigm shift
for conditional access
and it's a way to provide much more comprehensive coverage
to make sure that any identity type,
whether that's a user or a service account
or service principle is accessing your sensitive resources
and you can control that access.
But we wouldn't necessarily apply the same requirements,
right?
I mean, so for example, if there's a requirement
that says something that seems like a risky sign-in
from a user requires a multifactual authentication,
we couldn't apply that to say a service principle there, right?
Great question.
So you're totally right
that the conditions and the controls for policies
that apply to users are very different
than the conditions and controls
that may be applicable for service principles.
And so you will see that right out of the gate
when we first introduced conditional access
for service principles,
there's a much more limited set of conditions and controls.
And that's because obviously service principles
are different from users in many ways.
They don't provide multiple authentication methods
when they sign in.
There's no sequence of orders.
But also they don't forget the password ever, right?
So typically the service principle gets it right every time
and it's really easy to distinguish
between risky service principle behavior
versus risky user behavior
because service principles aren't usually guessing wrong
and they're not usually misspelling the password
by a couple of letters and stuff like that.
So we will absolutely be changing the conditions
and controls that are applicable
for policies that apply to them.
And I think some of the main use cases
for service principle policies would be admins
who want to just block access to service principles
from outside the trusted name location.
So that's probably the policy
that we're gonna release with first.
And then over the next year and a couple of months
we'll be introducing some additional capabilities as well.
Yeah, some customers I've worked with
have been, I'm not gonna say suspicious,
but kind of guarded about the use of service principles.
So I think having this sort of in your tool bag,
I think it's actually a huge benefit
to some of those customers who do have some concerns
about protecting credentials related to service principles.
This is really great to see.
Yeah, and as I said before,
just tune in during Ignite
because we'll have a lot to announce on this subject.
So just stay tuned.
Daniel, can you talk a little bit
about using conditional access
to verify whether the user is logging in
from a particular device,
for example, using a secure access workstation?
Yeah, so we've released another new condition recently,
specifically for device filters.
And we have the capability to now finally restrict access
from certain types of devices as well.
As we were talking about before,
we've shared a lot of information
with our device partners.
And now that admins have the ability
to tag devices as secure access workstations,
we can now start to apply policies
based off of that attribute.
And so that's one way that you would be able
to restrict access to some of these specific workstations.
Yeah, I was gonna ask you about that.
I think, like you just mentioned, it uses an attribute.
So actually there could be other use cases
for testing different things.
Absolutely, and in fact, attributes are not specific
to devices you can imagine adding attributes
to your applications, attributes to your users.
And certainly attributes to your devices.
So you're totally right that having the ability
to now tag objects in the directory
and apply policies to them is a really big step forward.
And so definitely stay tuned
for a really big announcement we'll be making there.
So I'm a huge fan of taking stuff that could be seen
as being far from technical,
perhaps even marketing terms like zero trust.
You know, zero trust has some really strong
technical underpinnings.
So what sort of technical aspects of conditional access
would you say apply to zero trust?
Yeah, absolutely.
So it is a little easy to get skeptical and say,
okay, great, well, zero trust,
what does that really mean for an IT admin
who's sitting at the controls
of a conditional access policy trying to implement it?
And I would say if you look at the principles
behind zero trust, there is a couple
that you can directly address in conditional access.
So, you know, the first one is really
requiring strong authentication all the time.
You can absolutely do that with conditional access.
You can require multi-factor authentication sometimes,
all the times, of certain conditions.
And you can also verify explicitly.
When we're thinking about zero trust,
one of the other core principles is that you're not making
any assumptions about who you trust
depending on where they're signing in from.
So rather than just allowing access
from inside your corporate network,
but maybe blocking or requiring MFA
outside of the corporate network,
if you're really trying to implement zero trust,
what we would recommend doing is ignoring
those location boundaries and instead focusing
on the strength of the authentication
by looking at signals like the device state
or whether the device is hybrid Azure AD joint,
stuff like that, which is a much stronger indicator
of whether you can trust that user signing in.
So, Daniel, one thing we ask all our guests
is if you had like just one final thought
to leave our listeners with, what would it be?
Turn on MFA, just three words.
And I talked about this earlier in the podcast,
but it's really one of our biggest focuses
across the team.
Just making sure that people are who they say they are
when they sign in.
The easiest way to do that is to require MFA.
So that's it.
I mean, some people like, their final thoughts
are like a final stream of thoughts.
Is yours literally just that, like turn on MFA?
Turn on MFA.
It's gonna be simpler than that, I guess.
But to your point, I've seen some of the figures
that show the incredible security benefits
that come from enabling MFA.
So yeah, I would tend to concur.
Well, with that, thank you so much for joining us this week,
Daniel, I know you're very busy
and I know you got some exciting things coming up at Ignite.
So thanks again for taking the time to talk to us
and to all our listeners out there.
Thank you for listening to this podcast.
Hope you found it useful.
I know I certainly did.
Stay safe out there and we'll see you next time.
Thanks for listening to the Azure Security Podcast.
You can find show notes and other resources at our website,
azsecuritypodcast.net.
If you have any questions,
please find us on Twitter at AzureSecPod.
Background music is from ccmixter.com
and licensed under the Creative Commons license.