1 00:00:00,000 --> 00:00:06,200 Welcome to the Azure Security Podcast, 2 00:00:06,200 --> 00:00:09,380 where we discuss topics relating to security, privacy, 3 00:00:09,380 --> 00:00:13,720 reliability, and compliance on the Microsoft Cloud Platform. 4 00:00:13,720 --> 00:00:17,040 Hey everybody. Welcome to Episode 38. 5 00:00:17,040 --> 00:00:18,840 This week we have myself, Michael, 6 00:00:18,840 --> 00:00:20,360 we have Gladys and Mark. 7 00:00:20,360 --> 00:00:23,200 Sarah this week is actually flying across the Pacific Ocean. 8 00:00:23,200 --> 00:00:24,880 So we'll hear more about her story, 9 00:00:24,880 --> 00:00:26,360 hopefully in a couple of weeks. 10 00:00:26,360 --> 00:00:27,480 This week we have a guest, 11 00:00:27,480 --> 00:00:30,240 we have Daniel Wood who is here to talk to us about 12 00:00:30,240 --> 00:00:33,160 Azure Active Directory Conditional Access. 13 00:00:33,160 --> 00:00:34,600 But before we get to Daniel, 14 00:00:34,600 --> 00:00:37,040 let's take a look at the news. Gladys, what we got? 15 00:00:37,040 --> 00:00:42,080 I wanted to talk about Azure defenses for ransomware attack. 16 00:00:42,080 --> 00:00:45,800 Basically, we've been releasing a lot of different guidance and 17 00:00:45,800 --> 00:00:50,280 other information for protecting different workloads. 18 00:00:50,280 --> 00:00:56,960 Recently, we released an e-book that lays out key Azure native 19 00:00:56,960 --> 00:01:00,920 capabilities and defenses for ransomware attacks. 20 00:01:00,920 --> 00:01:05,560 It provides some guidance how to proactively leverage 21 00:01:05,560 --> 00:01:11,480 capabilities to protect the assets on Azure Cloud. 22 00:01:11,480 --> 00:01:18,000 It explains how can assets in the Cloud be targeted, 23 00:01:18,000 --> 00:01:20,800 how the attacks succeed, 24 00:01:20,800 --> 00:01:25,360 different Azure native ransomware protection, 25 00:01:25,360 --> 00:01:27,840 including built-in capabilities, 26 00:01:27,840 --> 00:01:29,960 Azure Security Center detection, 27 00:01:29,960 --> 00:01:31,960 recommendations and reports, 28 00:01:31,960 --> 00:01:34,000 Sentinel Unified View. 29 00:01:34,000 --> 00:01:36,960 So there's quite a bit of information in here. 30 00:01:36,960 --> 00:01:40,640 It's only about 30 pages with lots of images, 31 00:01:40,640 --> 00:01:43,160 so it shouldn't take long to read. 32 00:01:43,160 --> 00:01:45,520 In addition, in public preview, 33 00:01:45,520 --> 00:01:48,240 we are providing a scale management of 34 00:01:48,240 --> 00:01:51,360 Azure Monitor Alerts in Backup Center. 35 00:01:51,360 --> 00:01:53,080 A few months ago, 36 00:01:53,080 --> 00:01:55,800 Azure Backup released in preview 37 00:01:55,800 --> 00:01:59,160 new alerting solution built-in on Azure Monitor, 38 00:01:59,160 --> 00:02:03,840 which enable users to act on critical backup incidents. 39 00:02:03,840 --> 00:02:06,400 Well, now with this integration, 40 00:02:06,400 --> 00:02:11,680 we provide the ability to view backups related alerts at scale, 41 00:02:11,680 --> 00:02:16,120 across both, and also slice and dice alerts by 42 00:02:16,120 --> 00:02:20,880 backup as specific properties such as workload type, 43 00:02:20,880 --> 00:02:24,000 but both location, etc. 44 00:02:24,000 --> 00:02:29,120 We also provide quick visibility at scale into 45 00:02:29,120 --> 00:02:34,040 the active backups security alerts that require attention. 46 00:02:34,040 --> 00:02:38,240 We also are providing the ability to configure and 47 00:02:38,240 --> 00:02:42,120 manage notification as well as how to get 48 00:02:42,120 --> 00:02:44,720 actionable interfaces that enable 49 00:02:44,720 --> 00:02:47,560 navigation to virtual machines or 50 00:02:47,560 --> 00:02:50,160 storage account that require attention. 51 00:02:50,160 --> 00:02:54,000 Thanks, Gladys. A few things caught my interest over the last couple of weeks. 52 00:02:54,000 --> 00:02:56,920 The first one is to do with Azure SQL Database. 53 00:02:56,920 --> 00:03:01,440 They've now added some new roles that allow you to query 54 00:03:01,440 --> 00:03:05,120 pretty sensitive metadata but without granting the need, 55 00:03:05,120 --> 00:03:07,240 or without the need, I should say, 56 00:03:07,240 --> 00:03:10,400 for admin access, like full admin access. 57 00:03:10,400 --> 00:03:12,320 This is a really good example of 58 00:03:12,320 --> 00:03:14,440 least privilege essentially granting people 59 00:03:14,440 --> 00:03:15,840 just the privilege they need to do 60 00:03:15,840 --> 00:03:17,680 just the job they need to get done. 61 00:03:17,680 --> 00:03:19,280 It's great to see that. 62 00:03:19,280 --> 00:03:22,040 Next one is Azure Site Recovery. 63 00:03:22,040 --> 00:03:25,680 Now, we'll enable TLS 1.2 by default. 64 00:03:25,680 --> 00:03:29,480 In fact, only TLS 1.2 as of November the 15th, 2021. 65 00:03:29,480 --> 00:03:32,680 You have about six weeks to get that done. 66 00:03:32,680 --> 00:03:36,000 It's not huge. I doubt many people will actually have a problem here, 67 00:03:36,000 --> 00:03:40,280 but just be aware that that's coming down the pike. 68 00:03:40,280 --> 00:03:43,800 Next is for Azure Virtual Machines. 69 00:03:43,800 --> 00:03:48,080 There's now the ability to automatically perform key rotation. 70 00:03:48,080 --> 00:03:50,680 It's managed automatically by Azure, 71 00:03:50,680 --> 00:03:52,400 and that's for customer managed keys. 72 00:03:52,400 --> 00:03:58,080 The next one is Azure Purview has now just gone generally available. 73 00:03:58,080 --> 00:04:00,720 We had back in May, 74 00:04:00,720 --> 00:04:04,000 we had Gopal Shankar who was here to talk to us, 75 00:04:04,000 --> 00:04:07,160 and also Avin Chandakar was here to talk to us 76 00:04:07,160 --> 00:04:10,560 about Azure Purview and Azure Information Protection. 77 00:04:10,560 --> 00:04:13,040 It's nice to see that's now gone GA. 78 00:04:13,040 --> 00:04:14,520 It's a fantastic product. 79 00:04:14,520 --> 00:04:15,760 It's there for data governance, 80 00:04:15,760 --> 00:04:18,480 being able to classify and identify data 81 00:04:18,480 --> 00:04:21,800 and the lineage of the data within your organization. 82 00:04:21,800 --> 00:04:23,640 A couple of things from my side, 83 00:04:23,640 --> 00:04:25,720 both focused on OT, 84 00:04:25,720 --> 00:04:28,520 operational technology and IoT security. 85 00:04:28,520 --> 00:04:30,560 For those that weren't aware, 86 00:04:30,560 --> 00:04:35,600 Microsoft acquired a company called CyberX about a year ago or so. 87 00:04:35,600 --> 00:04:37,440 They've got some great technology. 88 00:04:37,440 --> 00:04:42,200 We've got some great technology that helps with securing your OT environment. 89 00:04:42,200 --> 00:04:46,480 Scata, ICS, Supervisory Control and Data Acquisition, 90 00:04:46,480 --> 00:04:48,080 Industrial Control Systems, 91 00:04:48,080 --> 00:04:51,360 those computers that control physical machinery 92 00:04:51,360 --> 00:04:54,960 or monitor it, sensors and whatnot. 93 00:04:55,360 --> 00:04:59,840 There's a couple of different things that we published recently. 94 00:04:59,840 --> 00:05:04,200 One is the Defender for IoT Ninja training. 95 00:05:04,200 --> 00:05:08,160 There's I think somewhere in the order of 30 videos or so, 96 00:05:08,160 --> 00:05:14,120 and then documents and PowerPoint slides and other resources as well, 97 00:05:14,120 --> 00:05:16,160 to learn about this technology, 98 00:05:16,160 --> 00:05:19,200 learn about actually securing these environments. 99 00:05:19,200 --> 00:05:22,600 All free downloadable, watchable stuff. 100 00:05:22,600 --> 00:05:25,560 We got a link for that in the show notes. 101 00:05:25,560 --> 00:05:30,520 Then also, I recorded a video with Fid Elabdelaoui, 102 00:05:30,520 --> 00:05:33,400 who actually is a former CSO of Duke Energy, 103 00:05:33,400 --> 00:05:35,760 one of the largest power companies, 104 00:05:35,760 --> 00:05:36,960 if not the largest in the US. 105 00:05:36,960 --> 00:05:41,720 I can't remember, but he's actually an executive security advisor over at Microsoft now. 106 00:05:41,720 --> 00:05:45,880 He and I talked about the OT reference architecture, 107 00:05:45,880 --> 00:05:48,840 security reference architecture that we included in 108 00:05:48,840 --> 00:05:51,120 the cyber reference architecture, the MCRA. 109 00:05:51,120 --> 00:05:54,000 We really go through all the different nuances, 110 00:05:54,000 --> 00:05:57,240 what security controls are there and possible, 111 00:05:57,240 --> 00:06:00,960 which ones don't work, what's different between IT and OT. 112 00:06:00,960 --> 00:06:04,120 A couple of resources to help in that space now. 113 00:06:04,120 --> 00:06:07,120 Now that we have the news out the way, 114 00:06:07,120 --> 00:06:08,280 let's get to our guest. 115 00:06:08,280 --> 00:06:09,640 This week we have Daniel Wood. 116 00:06:09,640 --> 00:06:11,320 Daniel is here to talk to us about 117 00:06:11,320 --> 00:06:14,000 Azure Active Directory Conditional Access. 118 00:06:14,000 --> 00:06:15,440 Daniel, welcome to the podcast. 119 00:06:15,440 --> 00:06:18,400 We'd like to spend a moment and introduce ourselves to our listeners. 120 00:06:18,400 --> 00:06:20,320 Absolutely. Thanks guys for having me on. 121 00:06:20,320 --> 00:06:21,520 It's great to be here. 122 00:06:21,520 --> 00:06:23,880 Hey everybody, my name is Daniel, 123 00:06:23,880 --> 00:06:27,640 and I'm a program manager on the identity security team. 124 00:06:27,640 --> 00:06:29,800 I'm one of the product owners for 125 00:06:29,800 --> 00:06:31,760 Azure Active Directory Conditional Access. 126 00:06:31,760 --> 00:06:36,040 This is a topic that I'm really excited about. 127 00:06:36,040 --> 00:06:39,360 I'm going to be asking a lot of questions, Daniel. 128 00:06:39,360 --> 00:06:43,480 Why don't we start with explaining a little bit about 129 00:06:43,480 --> 00:06:47,960 what Azure Active Directory Conditional Access is? 130 00:06:47,960 --> 00:06:52,160 Sure. Conditional Access is a security feature in 131 00:06:52,160 --> 00:06:55,520 Azure Active Directory and it basically lets organizations 132 00:06:55,520 --> 00:06:58,320 control which users have access to 133 00:06:58,320 --> 00:07:00,960 which resources under certain conditions. 134 00:07:00,960 --> 00:07:04,000 Then you can also enforce controls such as 135 00:07:04,000 --> 00:07:06,000 multi-factor authentication or 136 00:07:06,000 --> 00:07:09,160 compliant devices or other sorts of controls as well. 137 00:07:09,160 --> 00:07:14,960 The main reason why customers love conditional access is because, 138 00:07:14,960 --> 00:07:17,160 the users are no longer just accessing 139 00:07:17,160 --> 00:07:21,040 on-premises apps from a desktop computer at the office. 140 00:07:21,040 --> 00:07:25,560 Over the past number of years, 141 00:07:25,560 --> 00:07:28,360 we've seen a trend where users are now accessing 142 00:07:28,360 --> 00:07:31,680 company resources from personal devices and 143 00:07:31,680 --> 00:07:36,120 mobile devices in the office and on the go or at home. 144 00:07:36,120 --> 00:07:38,040 This is all at the same time that 145 00:07:38,040 --> 00:07:39,840 adversaries are increasingly trying to 146 00:07:39,840 --> 00:07:42,480 access those same resources as well. 147 00:07:42,480 --> 00:07:46,120 It's really possible to use conditional access to 148 00:07:46,120 --> 00:07:48,480 lock down access to just the right people 149 00:07:48,480 --> 00:07:51,360 needing the right resources under the right conditions. 150 00:07:51,360 --> 00:07:55,320 One thing that I have seen is that people are not aware 151 00:07:55,320 --> 00:07:58,720 of common verifications that they could use. 152 00:07:58,720 --> 00:08:01,440 They are aware of some basic ones. 153 00:08:01,440 --> 00:08:04,600 Can you describe some of the verifications? 154 00:08:04,600 --> 00:08:07,000 Yeah, absolutely. As I was mentioning, 155 00:08:07,000 --> 00:08:09,680 when you configure a conditional access policy, 156 00:08:09,680 --> 00:08:11,960 there are a number of controls that you 157 00:08:11,960 --> 00:08:15,080 can require during authentication. 158 00:08:15,080 --> 00:08:17,520 Probably the most common one that you hear about 159 00:08:17,520 --> 00:08:21,480 being talked about would be requiring multi-factor authentication. 160 00:08:21,480 --> 00:08:24,680 There's a lot of nuances there like you could require 161 00:08:24,680 --> 00:08:28,200 multi-factor authentication when there's 162 00:08:28,200 --> 00:08:30,520 a high-risk sign-in or medium-risk sign-in, 163 00:08:30,520 --> 00:08:35,240 or every hour or once a day or at the end of your session. 164 00:08:35,240 --> 00:08:37,640 But then there are also a number of other controls as well. 165 00:08:37,640 --> 00:08:40,480 You can require compliant devices, 166 00:08:40,480 --> 00:08:42,680 those that are managed by Intune. 167 00:08:42,680 --> 00:08:45,960 You can require hybrid Azure AD join devices. 168 00:08:45,960 --> 00:08:48,720 You can also restrict access from 169 00:08:48,720 --> 00:08:52,600 specific lists of approved client applications. 170 00:08:52,600 --> 00:08:56,760 You can even enforce terms of use or other custom controls as well. 171 00:08:56,760 --> 00:09:01,360 So how do we recommend deploying conditional access? 172 00:09:01,360 --> 00:09:03,720 How much effort it requires? 173 00:09:03,720 --> 00:09:05,160 Yeah, that's a great question. 174 00:09:05,160 --> 00:09:08,200 I would say a lot of the customers that I talked to, 175 00:09:08,200 --> 00:09:10,880 in some cases can be a little bit worried or nervous 176 00:09:10,880 --> 00:09:13,720 about turning on a conditional access policy because, 177 00:09:13,720 --> 00:09:15,360 maybe before turning it on, 178 00:09:15,360 --> 00:09:17,840 most people were used to just having access and they didn't have 179 00:09:17,840 --> 00:09:21,520 to worry about getting prompted or needing a compliant device. 180 00:09:21,520 --> 00:09:23,640 So there's definitely this sense, 181 00:09:23,640 --> 00:09:25,880 perhaps among admins that it might be 182 00:09:25,880 --> 00:09:28,040 difficult to deploy conditional access. 183 00:09:28,040 --> 00:09:30,920 When in reality, we've actually done a lot of work to make 184 00:09:30,920 --> 00:09:35,640 it really easy and simple to deploy and also make it a predictable outcome. 185 00:09:35,640 --> 00:09:38,560 So one of the things that I always say is that one of 186 00:09:38,560 --> 00:09:44,120 the first oaths that an IT admin takes is very similar to a doctor. 187 00:09:44,120 --> 00:09:47,320 You take this Hippocratic oath to first do no harm. 188 00:09:47,320 --> 00:09:51,360 We think the same thing really applies to conditional access admins as well. 189 00:09:51,360 --> 00:09:57,560 Ultimately, these admins are trying to create the best experience for their users. 190 00:09:57,560 --> 00:10:00,240 So one of the ways that we recommend 191 00:10:00,240 --> 00:10:03,560 deploy conditional access is to use what we call report only mode. 192 00:10:03,560 --> 00:10:08,080 So what you can do is you can first turn on a policy in the audit mode, 193 00:10:08,080 --> 00:10:12,200 where it will log how many users would have been prompted for MFA, 194 00:10:12,200 --> 00:10:14,680 how many users would have been blocked by your policy, 195 00:10:14,680 --> 00:10:17,080 how many users would the policy have applied to, 196 00:10:17,080 --> 00:10:21,040 and then it generates a report and all these logs where the admin 197 00:10:21,040 --> 00:10:24,520 can look at the summary of the activity and they can understand 198 00:10:24,520 --> 00:10:27,560 whether they configure the policy the way that they wanted to, 199 00:10:27,560 --> 00:10:30,960 or whether they need to go in and maybe adjust the policy so 200 00:10:30,960 --> 00:10:35,880 that it doesn't apply to certain applications or under certain conditions. 201 00:10:35,880 --> 00:10:39,680 So once you've run the policy in report only mode, 202 00:10:39,680 --> 00:10:41,880 we also have another tool called the what if tool, 203 00:10:41,880 --> 00:10:45,760 which basically lets you plug in a user and some sign-in situations. 204 00:10:45,760 --> 00:10:48,240 You could say, I want to pretend what happens if I'm 205 00:10:48,240 --> 00:10:51,320 a guest user signing in from outside the corporate network 206 00:10:51,320 --> 00:10:56,000 from my personal mobile device accessing some corporate sensitive data, 207 00:10:56,000 --> 00:10:58,560 and you can click the what if tool and it will basically 208 00:10:58,560 --> 00:11:00,360 simulate the authentication and tell you 209 00:11:00,360 --> 00:11:02,240 which policies would apply and what would happen. 210 00:11:02,240 --> 00:11:04,120 So after you do those two steps, 211 00:11:04,120 --> 00:11:06,600 most customers have a good sense of what the policy is going to do. 212 00:11:06,600 --> 00:11:09,800 You could go ahead and slowly roll out your policy. 213 00:11:09,800 --> 00:11:13,160 Some customers like to start off turning on a policy in 214 00:11:13,160 --> 00:11:15,760 a test tenant to get a feel for what it looks like, 215 00:11:15,760 --> 00:11:17,800 or if you're rolling it out in production, 216 00:11:17,800 --> 00:11:19,240 you can roll it out and bring. 217 00:11:19,240 --> 00:11:23,960 So you could start out with a small group of users in one organization, 218 00:11:23,960 --> 00:11:26,360 and then you can slowly add groups to 219 00:11:26,360 --> 00:11:27,960 your conditional access policy until it's 220 00:11:27,960 --> 00:11:31,120 deployed throughout your organization or wherever you want it to play. 221 00:11:31,120 --> 00:11:33,360 I love that do no harm idea. 222 00:11:33,360 --> 00:11:34,640 I think that's fantastic. 223 00:11:34,640 --> 00:11:38,240 I think that's something that actually a lot of security people could probably learn from. 224 00:11:38,240 --> 00:11:42,320 I mean, the number of customers that I work with where security is there to 225 00:11:42,320 --> 00:11:45,640 kind of like just say no and almost shut the business down. 226 00:11:45,640 --> 00:11:48,840 You could argue that that's doing a lot of harm to the business. 227 00:11:48,840 --> 00:11:49,840 So I love that idea. 228 00:11:49,840 --> 00:11:52,520 I think it extends way beyond conditional access though. 229 00:11:52,520 --> 00:11:54,600 But yeah, I just love that thing. It's great. 230 00:11:54,600 --> 00:11:56,920 Yeah, absolutely. We're thinking about applying 231 00:11:56,920 --> 00:12:00,760 that same thought process to other security features as well. 232 00:12:00,760 --> 00:12:04,000 You can imagine there should be a report only mode for every security feature. 233 00:12:04,000 --> 00:12:05,920 Yeah. Well, let's take another example. 234 00:12:05,920 --> 00:12:07,280 I mean, as your policy, 235 00:12:07,280 --> 00:12:08,240 I've seen people say, yeah, 236 00:12:08,240 --> 00:12:09,640 we just turn this as your policy on. 237 00:12:09,640 --> 00:12:11,320 If we break stuff, then we break stuff. 238 00:12:11,320 --> 00:12:14,960 It's like, no, you can't just go breaking stuff left and right. 239 00:12:14,960 --> 00:12:17,640 Do it in a well thought out way. 240 00:12:17,640 --> 00:12:19,240 But again, I just love that idea. 241 00:12:19,240 --> 00:12:20,400 It's like, do no harm. 242 00:12:20,400 --> 00:12:21,600 I think it's fantastic. 243 00:12:21,600 --> 00:12:25,440 I think you have a lot more security professionals thought that way. 244 00:12:25,440 --> 00:12:29,040 I think there'll be a lot less friction between business owners and security in the long run. 245 00:12:29,040 --> 00:12:30,160 But yeah, so I love that. 246 00:12:30,160 --> 00:12:32,440 I think security folks out there who are listening to this, 247 00:12:32,440 --> 00:12:33,240 take that to heart. 248 00:12:33,240 --> 00:12:36,720 I think that's fantastic advice and a fantastic sort of mantra to live by. 249 00:12:36,720 --> 00:12:38,480 I really, really do. 250 00:12:38,480 --> 00:12:42,200 It is good to turn on all these conditional access, 251 00:12:42,200 --> 00:12:45,800 but how can administrator get insight whether it's working 252 00:12:45,800 --> 00:12:49,280 or how well it's working in the environment? 253 00:12:49,280 --> 00:12:50,680 So over the past year, 254 00:12:50,680 --> 00:12:55,720 we've made a number of investments in our reporting capabilities for conditional access. 255 00:12:55,720 --> 00:12:58,840 And we have a number of ones that exist today 256 00:12:58,840 --> 00:13:02,400 and also a number that we're going to be announcing in just a few weeks at Ignite. 257 00:13:02,400 --> 00:13:04,600 So if you're interested in conditional access, 258 00:13:04,600 --> 00:13:08,000 I encourage you to tune in and we have some really big announcements coming. 259 00:13:08,000 --> 00:13:10,240 But in terms of what we have available today, 260 00:13:10,240 --> 00:13:14,600 we have an insights and reporting workbook that's built in through conditional access. 261 00:13:14,600 --> 00:13:18,640 And this basically allows you to see an overview of the impact 262 00:13:18,640 --> 00:13:20,920 of your conditional access policies for your tenant. 263 00:13:20,920 --> 00:13:23,600 So what you can do is you can select, say, 264 00:13:23,600 --> 00:13:26,360 an individual conditional access policy, 265 00:13:26,360 --> 00:13:28,560 maybe one that blocks legacy authentication. 266 00:13:28,560 --> 00:13:31,680 And you can say, OK, for this conditional access policy, 267 00:13:31,680 --> 00:13:36,400 I want to understand what are the common applications that were blocked? 268 00:13:36,400 --> 00:13:38,040 Which are my users that were impacted? 269 00:13:38,040 --> 00:13:40,360 And so you can use this dashboard in this workbook, 270 00:13:40,360 --> 00:13:43,240 which is built on top of Log Analytics to analyze your data. 271 00:13:43,240 --> 00:13:47,440 And as I sort of alluded to, 272 00:13:47,440 --> 00:13:48,800 if you stay tuned to Ignite, 273 00:13:48,800 --> 00:13:51,600 we're going to be releasing a brand new conditional access dashboard, 274 00:13:51,600 --> 00:13:55,920 which will have a number of recommendations and actions that you can take 275 00:13:55,920 --> 00:13:57,600 as a conditional access admin, 276 00:13:57,600 --> 00:14:01,680 basically responding to insights that we've collected from your sign-in logs 277 00:14:01,680 --> 00:14:03,920 and the activity of your users in your tenant. 278 00:14:03,920 --> 00:14:06,440 So you mentioned sign-in logs. 279 00:14:06,440 --> 00:14:12,000 When exactly does the verification take place? 280 00:14:12,000 --> 00:14:16,720 Are there triggers through the session and starting the session? 281 00:14:16,720 --> 00:14:20,240 Or if something changed within the session? 282 00:14:20,240 --> 00:14:21,920 That's a great question. 283 00:14:21,920 --> 00:14:24,160 And it really has evolved over time. 284 00:14:24,160 --> 00:14:26,000 I would say at the very beginning, 285 00:14:26,000 --> 00:14:28,480 and this is probably what most admins are used to, 286 00:14:28,480 --> 00:14:32,040 is conditional access is evaluated at the beginning of the session. 287 00:14:32,040 --> 00:14:33,680 You can sort of think about conditional access 288 00:14:33,680 --> 00:14:37,040 as being the front door to the applications. 289 00:14:37,040 --> 00:14:38,680 So yeah, so you sign in, 290 00:14:38,680 --> 00:14:41,360 maybe you have an interactive prompt and you get a token 291 00:14:41,360 --> 00:14:42,800 for the application that you're accessing, 292 00:14:42,800 --> 00:14:45,480 and conditional access is absolutely evaluated there. 293 00:14:45,480 --> 00:14:48,200 But also when that access token expires 294 00:14:48,200 --> 00:14:51,200 and you use a refresh token to get another access token, 295 00:14:51,200 --> 00:14:53,160 that happens silently in the background. 296 00:14:53,160 --> 00:14:54,560 And every time you get a new token, 297 00:14:54,560 --> 00:14:58,160 conditional access is evaluated again and again. 298 00:14:58,160 --> 00:15:00,040 But as you mentioned, 299 00:15:00,040 --> 00:15:02,360 there may be some security events, 300 00:15:02,360 --> 00:15:03,880 maybe in the middle of your session, 301 00:15:03,880 --> 00:15:06,720 and you may want to cut off access. 302 00:15:06,720 --> 00:15:09,000 And so we've been investing in something called 303 00:15:09,000 --> 00:15:12,080 Continuous Access Evaluation, or CAE, 304 00:15:12,080 --> 00:15:16,440 which basically provides near instant revocation 305 00:15:16,440 --> 00:15:18,720 for sessions to certain apps, 306 00:15:18,720 --> 00:15:20,760 starting with Microsoft first party apps 307 00:15:20,760 --> 00:15:23,080 like SharePoint, Teams, Exchange, 308 00:15:23,080 --> 00:15:26,560 when we notice some sort of sensitive security event. 309 00:15:26,560 --> 00:15:28,880 So this could include things like 310 00:15:28,880 --> 00:15:32,240 we notice that you have elevated user risk, 311 00:15:32,240 --> 00:15:35,880 maybe we discovered your password or credentials 312 00:15:35,880 --> 00:15:38,520 on the dark web, and so we've updated your user risk. 313 00:15:38,520 --> 00:15:40,440 Or maybe you reset your password, 314 00:15:40,440 --> 00:15:42,120 or your device came out of compliance, 315 00:15:42,120 --> 00:15:43,600 or maybe you were terminated, 316 00:15:43,600 --> 00:15:45,760 and your account should definitely not have access 317 00:15:45,760 --> 00:15:47,480 to any applications. 318 00:15:47,480 --> 00:15:50,640 So this near instant revocation channel through CAE 319 00:15:50,640 --> 00:15:52,200 is a really good way to make sure that 320 00:15:52,200 --> 00:15:54,120 we can enforce these policies 321 00:15:54,120 --> 00:15:55,800 in the middle of the session. 322 00:15:55,800 --> 00:15:57,960 And the one last thing I'll say is, 323 00:15:57,960 --> 00:15:59,960 last night we announced something called 324 00:15:59,960 --> 00:16:02,480 authentication context, which is basically 325 00:16:02,480 --> 00:16:05,720 a new way for conditional access to become evaluated 326 00:16:05,720 --> 00:16:07,120 within an application. 327 00:16:07,120 --> 00:16:08,920 So you can imagine, let's say a SharePoint site 328 00:16:08,920 --> 00:16:10,960 where first you access SharePoint, 329 00:16:10,960 --> 00:16:14,240 and maybe one conditional access policy will apply. 330 00:16:14,240 --> 00:16:15,920 But then within SharePoint, 331 00:16:15,920 --> 00:16:19,680 you may want to access some sensitive content, 332 00:16:19,680 --> 00:16:21,520 or perform some sensitive action, 333 00:16:21,520 --> 00:16:24,360 and that can actually trigger an authentication context, 334 00:16:24,360 --> 00:16:26,920 which will then go and evaluate conditional access again. 335 00:16:26,920 --> 00:16:29,800 So really conditional access has become 336 00:16:29,800 --> 00:16:33,200 a really powerful tool for evaluating access. 337 00:16:33,200 --> 00:16:34,400 At the beginning of the session, 338 00:16:34,400 --> 00:16:37,280 but also during authentication context triggers, 339 00:16:37,280 --> 00:16:40,760 and now with continuous access evaluation for CAE, 340 00:16:40,760 --> 00:16:43,080 we can do near instant revocation events 341 00:16:43,080 --> 00:16:45,360 for security events as well. 342 00:16:45,360 --> 00:16:46,880 If I'm right, so conditional access 343 00:16:46,880 --> 00:16:48,480 is an Azure Active Directory thing. 344 00:16:48,480 --> 00:16:52,000 So how does this relate to Active Directory, if at all? 345 00:16:52,000 --> 00:16:54,320 Our customers have the requirement 346 00:16:54,320 --> 00:16:56,840 that their users are accessing apps from anywhere, 347 00:16:56,840 --> 00:16:57,840 and they're all sorts of apps. 348 00:16:57,840 --> 00:17:01,200 You have SaaS apps, you can have line of business apps, 349 00:17:01,200 --> 00:17:03,440 and also on-premises applications. 350 00:17:03,440 --> 00:17:07,560 So if you're asking about how you can apply 351 00:17:07,560 --> 00:17:09,160 conditional access policies to protect 352 00:17:09,160 --> 00:17:11,680 your on-premises resources, absolutely. 353 00:17:11,680 --> 00:17:13,080 And we have a solution built in 354 00:17:13,080 --> 00:17:15,800 through Azure Active Directory called App Proxy, 355 00:17:15,800 --> 00:17:18,320 where basically you can set up a configuration 356 00:17:18,320 --> 00:17:21,520 so when your users are signing in, 357 00:17:21,520 --> 00:17:24,280 they first get routed through Azure AD signing, 358 00:17:25,360 --> 00:17:27,200 when they try to access an endpoint 359 00:17:27,200 --> 00:17:28,520 for an app that's sitting on-prem, 360 00:17:28,520 --> 00:17:30,280 you would first go to conditional access, 361 00:17:30,280 --> 00:17:32,120 and you can enforce any of the same policies 362 00:17:32,120 --> 00:17:33,880 that you would for any other application, 363 00:17:33,880 --> 00:17:35,280 and then if you succeed, 364 00:17:35,280 --> 00:17:36,960 then you would be granted an access token 365 00:17:36,960 --> 00:17:38,320 to that app on-prem. 366 00:17:38,320 --> 00:17:40,000 I really love App Proxy. 367 00:17:40,000 --> 00:17:44,200 It's basically an edge type of security approach, 368 00:17:44,200 --> 00:17:45,920 especially when we build it 369 00:17:45,920 --> 00:17:49,720 or when you use conditional access. 370 00:17:49,720 --> 00:17:52,320 Let's talk a little bit about MFA. 371 00:17:52,320 --> 00:17:54,760 What are MFA rankings? 372 00:17:54,760 --> 00:17:56,360 How do you use them? 373 00:17:56,360 --> 00:17:58,760 As I mentioned before, multi-factor authentication 374 00:17:58,760 --> 00:18:01,720 is probably the most common control 375 00:18:01,720 --> 00:18:05,480 for conditional access, and on my team, 376 00:18:05,480 --> 00:18:07,960 one of the things that we're really laser focused on 377 00:18:07,960 --> 00:18:10,680 is increasing the percentage of sign-ins 378 00:18:10,680 --> 00:18:12,480 that are protected by MFA. 379 00:18:12,480 --> 00:18:17,480 Our research shows us that you get 99.99% protection 380 00:18:19,560 --> 00:18:22,760 by using MFA as opposed to single-factor authentication. 381 00:18:22,760 --> 00:18:23,720 So it's a really great way 382 00:18:23,720 --> 00:18:25,960 to prevent your account from being compromised. 383 00:18:25,960 --> 00:18:27,800 But with that being said, 384 00:18:27,800 --> 00:18:30,640 we favor some authentication methods over others. 385 00:18:30,640 --> 00:18:34,560 So one of the things that we've been really focused on 386 00:18:34,560 --> 00:18:38,160 is introducing passwordless authentication methods. 387 00:18:38,160 --> 00:18:40,640 These are methods like the Authenticator app, 388 00:18:40,640 --> 00:18:43,480 Windows Hello for Business, and FIDO tokens. 389 00:18:43,480 --> 00:18:45,520 These are all really strong. 390 00:18:45,520 --> 00:18:47,160 They're phishing resistant, 391 00:18:47,160 --> 00:18:49,160 and they no longer rely on a password, 392 00:18:49,160 --> 00:18:51,160 and they're really strong methods. 393 00:18:51,160 --> 00:18:52,680 And then there are some other methods 394 00:18:52,680 --> 00:18:54,080 that are really popular, 395 00:18:54,080 --> 00:18:56,760 but you may want to consider switching out of, 396 00:18:56,760 --> 00:18:59,480 such as SMS or text messages. 397 00:19:00,600 --> 00:19:02,480 It's not very common that we see SIM jacking, 398 00:19:02,480 --> 00:19:04,800 but it is definitely a security concern. 399 00:19:04,800 --> 00:19:09,320 And we think that it's probably a more seamless experience 400 00:19:09,320 --> 00:19:11,040 for you to be using other solutions 401 00:19:11,040 --> 00:19:12,360 like the Authenticator app. 402 00:19:12,360 --> 00:19:14,280 I'm so glad that you mentioned 403 00:19:14,280 --> 00:19:17,560 that the Authenticator is phishing resistant. 404 00:19:17,560 --> 00:19:21,360 I have seen customers that have been a bit confused 405 00:19:21,360 --> 00:19:26,000 with Authenticator since you could have the SMS authentication 406 00:19:26,000 --> 00:19:27,320 or phone authentication, 407 00:19:27,320 --> 00:19:30,160 and they don't realize the difference. 408 00:19:30,160 --> 00:19:31,600 Yeah, absolutely. 409 00:19:31,600 --> 00:19:34,280 And there's a bunch of benefits that you also get 410 00:19:34,280 --> 00:19:35,800 from using the Authenticator app. 411 00:19:35,800 --> 00:19:38,560 For example, I think we'll soon be releasing the capability 412 00:19:38,560 --> 00:19:41,920 for you to report notifications that you got out of the blue 413 00:19:41,920 --> 00:19:45,280 that may have been prompted by an adversary trying to sign in. 414 00:19:45,280 --> 00:19:47,080 You can even see your sign-ins 415 00:19:47,080 --> 00:19:50,000 or risky sign-ins recently from within the app as well. 416 00:19:50,000 --> 00:19:53,000 It's a much more integrated authentication experience. 417 00:19:53,000 --> 00:19:57,560 So one thing that I see customers get confused 418 00:19:57,560 --> 00:20:01,960 is there's conditional access that are user-based, 419 00:20:01,960 --> 00:20:06,240 but there's also conditional access through Intune. 420 00:20:06,240 --> 00:20:09,080 Can you explain how the interconnect 421 00:20:09,080 --> 00:20:10,760 or are they separate? 422 00:20:10,760 --> 00:20:12,200 They work together? 423 00:20:12,200 --> 00:20:16,360 So if you're in the Microsoft Endpoint Manager console, 424 00:20:16,360 --> 00:20:18,200 you will see that you do have the capability 425 00:20:18,200 --> 00:20:20,400 to create conditional access policies, 426 00:20:20,400 --> 00:20:22,240 and the two are really the same. 427 00:20:22,240 --> 00:20:25,240 And we've created a great integration 428 00:20:25,240 --> 00:20:27,240 with our partners over at Intune 429 00:20:27,240 --> 00:20:30,280 so that you can require users to be coming 430 00:20:30,280 --> 00:20:32,520 from a compliant device when they sign in. 431 00:20:32,520 --> 00:20:34,720 And so you can require that as one of the grant controls 432 00:20:34,720 --> 00:20:36,240 in conditional access. 433 00:20:36,240 --> 00:20:40,560 And the way that works is we share intelligence and signals 434 00:20:40,560 --> 00:20:42,000 about that device, 435 00:20:42,000 --> 00:20:46,200 and basically all it is is the Intune team sets a flag 436 00:20:46,200 --> 00:20:47,960 in Azure AD that basically tells us 437 00:20:47,960 --> 00:20:50,520 whether the device is compliant or not. 438 00:20:50,520 --> 00:20:53,280 And when you sign in, we look at that device fingerprint. 439 00:20:53,280 --> 00:20:56,560 We cross-reference that with our device directory, 440 00:20:56,560 --> 00:20:59,920 we can tell whether that device is compliant 441 00:20:59,920 --> 00:21:01,280 with all the rules in Intune. 442 00:21:01,280 --> 00:21:02,760 And then based off of the result, 443 00:21:02,760 --> 00:21:05,840 we can either let you in or tell you that you've been blocked 444 00:21:05,840 --> 00:21:07,640 and you need to update your device. 445 00:21:07,640 --> 00:21:08,920 If I remember correctly, 446 00:21:08,920 --> 00:21:13,040 we also integrate with NDE or Defender for Endpoint, 447 00:21:13,040 --> 00:21:15,720 and we could do conditional access 448 00:21:15,720 --> 00:21:18,880 if it shows indication or compromise. 449 00:21:18,880 --> 00:21:19,760 Is that right? 450 00:21:19,760 --> 00:21:23,280 Yeah, so we have a number of partners that we work with 451 00:21:23,280 --> 00:21:26,120 to gather signal intelligence that helps inform 452 00:21:26,120 --> 00:21:28,800 the risk profile of the user and of the sign. 453 00:21:28,800 --> 00:21:32,280 So for example, if your device has malware 454 00:21:32,280 --> 00:21:35,400 or it's not the proper version 455 00:21:35,400 --> 00:21:38,240 or there's suspicious activity that we've noticed 456 00:21:38,240 --> 00:21:39,760 related to that device, 457 00:21:39,760 --> 00:21:41,840 that does inform some of the signals 458 00:21:41,840 --> 00:21:45,400 for risk protection and identity protection for Azure AD. 459 00:21:45,400 --> 00:21:47,520 So for example, if you were to create a policy 460 00:21:47,520 --> 00:21:50,560 that blocks access to maybe low risk 461 00:21:50,560 --> 00:21:54,800 or medium risk signs and your device had malware 462 00:21:54,800 --> 00:21:56,720 or a virus or something like that, 463 00:21:56,720 --> 00:21:59,800 that would actually trigger a risk event in Azure AD 464 00:21:59,800 --> 00:22:01,480 and you'd be able to block access. 465 00:22:01,480 --> 00:22:02,440 So with conditional access, 466 00:22:02,440 --> 00:22:04,920 what kind of principles can I apply 467 00:22:04,920 --> 00:22:07,200 conditional access policies to? 468 00:22:07,200 --> 00:22:10,880 So up until now, policies were really just applied 469 00:22:10,880 --> 00:22:13,960 for users accessing applications. 470 00:22:13,960 --> 00:22:16,400 But we've seen over the last year 471 00:22:16,400 --> 00:22:19,040 that adversaries are really taking advantage 472 00:22:19,040 --> 00:22:21,200 of service principles and applications 473 00:22:21,200 --> 00:22:23,880 to access sensitive resources in your environment. 474 00:22:23,880 --> 00:22:27,440 And so we are about to release conditional access 475 00:22:27,440 --> 00:22:28,640 for service principles 476 00:22:28,640 --> 00:22:30,200 and what we'll be calling conditional access 477 00:22:30,200 --> 00:22:31,640 for workload identities, 478 00:22:31,640 --> 00:22:35,000 which will give admins the ability to now finally 479 00:22:35,000 --> 00:22:37,080 apply conditional access policies 480 00:22:37,080 --> 00:22:39,320 to your service principles in your environment, 481 00:22:39,320 --> 00:22:40,640 which are then accessing 482 00:22:40,640 --> 00:22:43,120 other sensitive resources or applications. 483 00:22:43,120 --> 00:22:45,600 So this is a whole new paradigm shift 484 00:22:45,600 --> 00:22:46,640 for conditional access 485 00:22:46,640 --> 00:22:50,320 and it's a way to provide much more comprehensive coverage 486 00:22:50,320 --> 00:22:52,520 to make sure that any identity type, 487 00:22:52,520 --> 00:22:54,760 whether that's a user or a service account 488 00:22:54,760 --> 00:22:58,480 or service principle is accessing your sensitive resources 489 00:22:58,480 --> 00:23:00,680 and you can control that access. 490 00:23:00,680 --> 00:23:05,240 But we wouldn't necessarily apply the same requirements, 491 00:23:05,240 --> 00:23:06,080 right? 492 00:23:06,080 --> 00:23:08,560 I mean, so for example, if there's a requirement 493 00:23:08,560 --> 00:23:11,880 that says something that seems like a risky sign-in 494 00:23:11,880 --> 00:23:14,840 from a user requires a multifactual authentication, 495 00:23:14,840 --> 00:23:17,640 we couldn't apply that to say a service principle there, right? 496 00:23:17,640 --> 00:23:18,480 Great question. 497 00:23:18,480 --> 00:23:19,680 So you're totally right 498 00:23:19,680 --> 00:23:23,800 that the conditions and the controls for policies 499 00:23:23,800 --> 00:23:26,480 that apply to users are very different 500 00:23:26,480 --> 00:23:29,000 than the conditions and controls 501 00:23:29,000 --> 00:23:31,240 that may be applicable for service principles. 502 00:23:31,240 --> 00:23:34,760 And so you will see that right out of the gate 503 00:23:34,760 --> 00:23:36,480 when we first introduced conditional access 504 00:23:36,480 --> 00:23:37,680 for service principles, 505 00:23:37,680 --> 00:23:42,280 there's a much more limited set of conditions and controls. 506 00:23:42,280 --> 00:23:45,240 And that's because obviously service principles 507 00:23:45,240 --> 00:23:47,040 are different from users in many ways. 508 00:23:47,040 --> 00:23:50,400 They don't provide multiple authentication methods 509 00:23:50,400 --> 00:23:51,240 when they sign in. 510 00:23:51,240 --> 00:23:53,280 There's no sequence of orders. 511 00:23:53,280 --> 00:23:55,640 But also they don't forget the password ever, right? 512 00:23:55,640 --> 00:23:59,200 So typically the service principle gets it right every time 513 00:23:59,200 --> 00:24:00,720 and it's really easy to distinguish 514 00:24:00,720 --> 00:24:02,400 between risky service principle behavior 515 00:24:02,400 --> 00:24:03,600 versus risky user behavior 516 00:24:03,600 --> 00:24:05,800 because service principles aren't usually guessing wrong 517 00:24:05,800 --> 00:24:08,960 and they're not usually misspelling the password 518 00:24:08,960 --> 00:24:11,080 by a couple of letters and stuff like that. 519 00:24:11,080 --> 00:24:15,120 So we will absolutely be changing the conditions 520 00:24:15,120 --> 00:24:16,200 and controls that are applicable 521 00:24:16,200 --> 00:24:18,880 for policies that apply to them. 522 00:24:18,880 --> 00:24:20,800 And I think some of the main use cases 523 00:24:20,800 --> 00:24:23,360 for service principle policies would be admins 524 00:24:23,360 --> 00:24:26,240 who want to just block access to service principles 525 00:24:26,240 --> 00:24:27,960 from outside the trusted name location. 526 00:24:27,960 --> 00:24:29,480 So that's probably the policy 527 00:24:29,480 --> 00:24:31,920 that we're gonna release with first. 528 00:24:31,920 --> 00:24:34,760 And then over the next year and a couple of months 529 00:24:34,760 --> 00:24:38,200 we'll be introducing some additional capabilities as well. 530 00:24:38,200 --> 00:24:39,520 Yeah, some customers I've worked with 531 00:24:39,520 --> 00:24:41,400 have been, I'm not gonna say suspicious, 532 00:24:41,400 --> 00:24:44,360 but kind of guarded about the use of service principles. 533 00:24:44,360 --> 00:24:46,960 So I think having this sort of in your tool bag, 534 00:24:46,960 --> 00:24:48,800 I think it's actually a huge benefit 535 00:24:48,800 --> 00:24:50,880 to some of those customers who do have some concerns 536 00:24:50,880 --> 00:24:54,520 about protecting credentials related to service principles. 537 00:24:54,520 --> 00:24:56,400 This is really great to see. 538 00:24:56,400 --> 00:24:58,040 Yeah, and as I said before, 539 00:24:58,040 --> 00:24:59,680 just tune in during Ignite 540 00:24:59,680 --> 00:25:01,600 because we'll have a lot to announce on this subject. 541 00:25:01,600 --> 00:25:02,840 So just stay tuned. 542 00:25:02,840 --> 00:25:04,760 Daniel, can you talk a little bit 543 00:25:04,760 --> 00:25:07,520 about using conditional access 544 00:25:07,520 --> 00:25:11,160 to verify whether the user is logging in 545 00:25:11,160 --> 00:25:12,760 from a particular device, 546 00:25:12,760 --> 00:25:16,440 for example, using a secure access workstation? 547 00:25:16,440 --> 00:25:20,440 Yeah, so we've released another new condition recently, 548 00:25:20,440 --> 00:25:22,880 specifically for device filters. 549 00:25:22,880 --> 00:25:26,400 And we have the capability to now finally restrict access 550 00:25:26,400 --> 00:25:28,880 from certain types of devices as well. 551 00:25:28,880 --> 00:25:30,280 As we were talking about before, 552 00:25:30,280 --> 00:25:31,560 we've shared a lot of information 553 00:25:31,560 --> 00:25:33,120 with our device partners. 554 00:25:33,120 --> 00:25:36,160 And now that admins have the ability 555 00:25:36,160 --> 00:25:39,520 to tag devices as secure access workstations, 556 00:25:39,520 --> 00:25:41,800 we can now start to apply policies 557 00:25:41,800 --> 00:25:44,280 based off of that attribute. 558 00:25:44,280 --> 00:25:46,040 And so that's one way that you would be able 559 00:25:46,040 --> 00:25:50,200 to restrict access to some of these specific workstations. 560 00:25:50,200 --> 00:25:52,120 Yeah, I was gonna ask you about that. 561 00:25:52,120 --> 00:25:56,120 I think, like you just mentioned, it uses an attribute. 562 00:25:56,120 --> 00:26:00,120 So actually there could be other use cases 563 00:26:00,120 --> 00:26:04,200 for testing different things. 564 00:26:04,200 --> 00:26:06,880 Absolutely, and in fact, attributes are not specific 565 00:26:06,880 --> 00:26:09,080 to devices you can imagine adding attributes 566 00:26:09,080 --> 00:26:12,080 to your applications, attributes to your users. 567 00:26:12,080 --> 00:26:14,080 And certainly attributes to your devices. 568 00:26:14,080 --> 00:26:17,040 So you're totally right that having the ability 569 00:26:17,040 --> 00:26:19,360 to now tag objects in the directory 570 00:26:19,360 --> 00:26:22,360 and apply policies to them is a really big step forward. 571 00:26:22,360 --> 00:26:24,280 And so definitely stay tuned 572 00:26:24,280 --> 00:26:26,920 for a really big announcement we'll be making there. 573 00:26:26,920 --> 00:26:31,040 So I'm a huge fan of taking stuff that could be seen 574 00:26:31,040 --> 00:26:33,080 as being far from technical, 575 00:26:33,080 --> 00:26:36,600 perhaps even marketing terms like zero trust. 576 00:26:36,600 --> 00:26:38,000 You know, zero trust has some really strong 577 00:26:38,000 --> 00:26:38,960 technical underpinnings. 578 00:26:38,960 --> 00:26:42,200 So what sort of technical aspects of conditional access 579 00:26:42,200 --> 00:26:44,120 would you say apply to zero trust? 580 00:26:44,120 --> 00:26:44,960 Yeah, absolutely. 581 00:26:44,960 --> 00:26:47,200 So it is a little easy to get skeptical and say, 582 00:26:47,200 --> 00:26:49,360 okay, great, well, zero trust, 583 00:26:49,360 --> 00:26:51,600 what does that really mean for an IT admin 584 00:26:51,600 --> 00:26:52,800 who's sitting at the controls 585 00:26:52,800 --> 00:26:56,040 of a conditional access policy trying to implement it? 586 00:26:56,040 --> 00:26:58,560 And I would say if you look at the principles 587 00:26:58,560 --> 00:27:00,080 behind zero trust, there is a couple 588 00:27:00,080 --> 00:27:02,320 that you can directly address in conditional access. 589 00:27:02,320 --> 00:27:04,880 So, you know, the first one is really 590 00:27:04,880 --> 00:27:07,760 requiring strong authentication all the time. 591 00:27:07,760 --> 00:27:10,120 You can absolutely do that with conditional access. 592 00:27:10,120 --> 00:27:13,040 You can require multi-factor authentication sometimes, 593 00:27:13,040 --> 00:27:15,360 all the times, of certain conditions. 594 00:27:15,360 --> 00:27:17,600 And you can also verify explicitly. 595 00:27:17,600 --> 00:27:20,040 When we're thinking about zero trust, 596 00:27:20,040 --> 00:27:22,040 one of the other core principles is that you're not making 597 00:27:22,040 --> 00:27:24,040 any assumptions about who you trust 598 00:27:24,040 --> 00:27:26,120 depending on where they're signing in from. 599 00:27:26,120 --> 00:27:28,960 So rather than just allowing access 600 00:27:28,960 --> 00:27:30,320 from inside your corporate network, 601 00:27:30,320 --> 00:27:32,880 but maybe blocking or requiring MFA 602 00:27:32,880 --> 00:27:34,520 outside of the corporate network, 603 00:27:34,520 --> 00:27:36,240 if you're really trying to implement zero trust, 604 00:27:36,240 --> 00:27:37,960 what we would recommend doing is ignoring 605 00:27:37,960 --> 00:27:40,840 those location boundaries and instead focusing 606 00:27:40,840 --> 00:27:42,520 on the strength of the authentication 607 00:27:42,520 --> 00:27:45,040 by looking at signals like the device state 608 00:27:45,040 --> 00:27:47,560 or whether the device is hybrid Azure AD joint, 609 00:27:47,560 --> 00:27:50,080 stuff like that, which is a much stronger indicator 610 00:27:50,080 --> 00:27:53,200 of whether you can trust that user signing in. 611 00:27:53,200 --> 00:27:55,600 So, Daniel, one thing we ask all our guests 612 00:27:55,600 --> 00:27:57,560 is if you had like just one final thought 613 00:27:57,560 --> 00:27:59,680 to leave our listeners with, what would it be? 614 00:27:59,680 --> 00:28:02,640 Turn on MFA, just three words. 615 00:28:02,640 --> 00:28:04,520 And I talked about this earlier in the podcast, 616 00:28:04,520 --> 00:28:06,640 but it's really one of our biggest focuses 617 00:28:06,640 --> 00:28:07,560 across the team. 618 00:28:07,560 --> 00:28:09,760 Just making sure that people are who they say they are 619 00:28:09,760 --> 00:28:10,600 when they sign in. 620 00:28:10,600 --> 00:28:12,880 The easiest way to do that is to require MFA. 621 00:28:12,880 --> 00:28:13,720 So that's it. 622 00:28:13,720 --> 00:28:16,320 I mean, some people like, their final thoughts 623 00:28:16,320 --> 00:28:17,920 are like a final stream of thoughts. 624 00:28:17,920 --> 00:28:21,680 Is yours literally just that, like turn on MFA? 625 00:28:21,680 --> 00:28:23,320 Turn on MFA. 626 00:28:23,320 --> 00:28:24,960 It's gonna be simpler than that, I guess. 627 00:28:24,960 --> 00:28:27,680 But to your point, I've seen some of the figures 628 00:28:27,680 --> 00:28:30,720 that show the incredible security benefits 629 00:28:30,720 --> 00:28:33,280 that come from enabling MFA. 630 00:28:33,280 --> 00:28:36,720 So yeah, I would tend to concur. 631 00:28:36,720 --> 00:28:38,600 Well, with that, thank you so much for joining us this week, 632 00:28:38,600 --> 00:28:40,160 Daniel, I know you're very busy 633 00:28:40,160 --> 00:28:43,720 and I know you got some exciting things coming up at Ignite. 634 00:28:43,720 --> 00:28:46,200 So thanks again for taking the time to talk to us 635 00:28:46,200 --> 00:28:47,480 and to all our listeners out there. 636 00:28:47,480 --> 00:28:49,160 Thank you for listening to this podcast. 637 00:28:49,160 --> 00:28:50,000 Hope you found it useful. 638 00:28:50,000 --> 00:28:51,160 I know I certainly did. 639 00:28:51,160 --> 00:28:53,320 Stay safe out there and we'll see you next time. 640 00:28:53,320 --> 00:28:56,240 Thanks for listening to the Azure Security Podcast. 641 00:28:56,240 --> 00:28:59,960 You can find show notes and other resources at our website, 642 00:28:59,960 --> 00:29:02,160 azsecuritypodcast.net. 643 00:29:03,040 --> 00:29:04,600 If you have any questions, 644 00:29:04,600 --> 00:29:06,880 please find us on Twitter at AzureSecPod. 645 00:29:07,800 --> 00:29:10,760 Background music is from ccmixter.com 646 00:29:10,760 --> 00:29:21,480 and licensed under the Creative Commons license.