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.