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,760 reliability, and compliance on the Microsoft Cloud Platform. 4 00:00:14,960 --> 00:00:17,840 Hey everybody, welcome to Episode 67. 5 00:00:17,840 --> 00:00:20,800 This week is just myself, Michael and Sarah. 6 00:00:20,800 --> 00:00:22,840 I'm going to guess, Bronwyn Mercer, 7 00:00:22,840 --> 00:00:25,200 who's here to talk to us about privilege access. 8 00:00:25,200 --> 00:00:27,000 But before we get to Bronwyn, 9 00:00:27,000 --> 00:00:29,000 why don't we take a quick lap around the news? 10 00:00:29,000 --> 00:00:31,440 Sarah, why don't you take things off? 11 00:00:31,440 --> 00:00:33,840 Okay. So, yeah. 12 00:00:33,840 --> 00:00:36,600 So, first, I've got one bit of, 13 00:00:36,600 --> 00:00:39,920 it's news and also an ask to folks. 14 00:00:39,920 --> 00:00:42,840 So, you may know that at Ignite, 15 00:00:42,840 --> 00:00:47,480 we announced the preview of Defender for DevOps. 16 00:00:47,480 --> 00:00:52,760 So, we're actually asking folks to go and try the preview 17 00:00:52,760 --> 00:00:55,600 and actually give us your feedback on it. 18 00:00:55,600 --> 00:00:58,720 So, we'll put the link to the questionnaire 19 00:00:58,720 --> 00:00:59,720 in the show notes. 20 00:00:59,720 --> 00:01:01,400 It can be anonymous as well, 21 00:01:01,400 --> 00:01:04,200 so you don't have to give us your details. 22 00:01:04,200 --> 00:01:07,200 But please give us your free and frank, 23 00:01:07,200 --> 00:01:10,240 the good and the bads about it if you've had a play. 24 00:01:10,240 --> 00:01:13,120 If you haven't, then please go download the preview 25 00:01:13,120 --> 00:01:15,040 and have a go with it, 26 00:01:15,040 --> 00:01:18,040 because the product group for Defender for DevOps 27 00:01:18,040 --> 00:01:19,520 would love to hear your feedback. 28 00:01:19,520 --> 00:01:20,560 So, yeah. 29 00:01:20,560 --> 00:01:23,720 As I said, I'll put the feedback link in the show notes. 30 00:01:23,720 --> 00:01:25,960 And if you've had a play and you want to tell us 31 00:01:25,960 --> 00:01:27,920 what you think, please do. 32 00:01:27,920 --> 00:01:31,080 And that's just, that's me for this week, Michael. 33 00:01:31,080 --> 00:01:31,920 Very cool. 34 00:01:31,920 --> 00:01:32,760 Hey, I've got a few items. 35 00:01:32,760 --> 00:01:33,600 So, the first one is, 36 00:01:33,600 --> 00:01:34,600 and this is actually really good to see actually. 37 00:01:34,600 --> 00:01:38,640 So, as your resource manager, so I'm starting next year, 38 00:01:38,640 --> 00:01:42,000 we'll start deprecating older versions of TLS. 39 00:01:42,000 --> 00:01:44,360 So, TLS 1.0 and 1.1. 40 00:01:44,360 --> 00:01:47,520 You may think, oh, you know, no one's using TLS 1.1 or 1.0. 41 00:01:47,520 --> 00:01:48,680 You'd be surprised. 42 00:01:48,680 --> 00:01:52,760 It amazes me how, from a compatibility perspective, 43 00:01:52,760 --> 00:01:55,480 we have to have like a long, long lead time 44 00:01:55,480 --> 00:01:57,520 to deprecate some of these things. 45 00:01:57,520 --> 00:01:58,960 Yeah, it's a hard problem. 46 00:01:58,960 --> 00:02:01,640 So anyway, that's gonna be linked to that in the show notes. 47 00:02:01,640 --> 00:02:04,280 Another one is back to TLS. 48 00:02:04,280 --> 00:02:08,040 So, application gateway now supports TLS 1.3 49 00:02:08,040 --> 00:02:11,960 and TLS 1.3 Cypher Suite, which is great to see as well. 50 00:02:11,960 --> 00:02:16,520 On a, one of my favorite sort of services in Azure 51 00:02:16,520 --> 00:02:19,280 is Azure Key Vault and Azure Managed HSM. 52 00:02:19,280 --> 00:02:22,320 So, Azure Managed HSM now has the ability 53 00:02:22,320 --> 00:02:27,680 to offload TLS traffic to Managed HSM. 54 00:02:27,680 --> 00:02:29,120 So, there's a library that we've produced. 55 00:02:29,120 --> 00:02:31,160 So, in your code, you can actually do the crypto 56 00:02:31,160 --> 00:02:33,640 inside of Managed HSM, which is actually kind of nice 57 00:02:33,640 --> 00:02:36,720 because that way it reduces one of the performance bottlenecks 58 00:02:36,720 --> 00:02:39,920 certainly in the, you know, the initial kind of handshake 59 00:02:39,920 --> 00:02:41,720 of the TLS communication. 60 00:02:41,720 --> 00:02:45,800 On a personal note, my book with my colleagues, 61 00:02:45,800 --> 00:02:48,240 Heinrich and Simone is finally out. 62 00:02:48,240 --> 00:02:49,000 That's finally done. 63 00:02:49,000 --> 00:02:51,640 I've got my, I've got it in my pinkies right now. 64 00:02:51,640 --> 00:02:53,560 So, designing and developing secure Azure Solutions 65 00:02:53,560 --> 00:02:55,120 is now available for order. 66 00:02:55,120 --> 00:02:57,000 It's great to finally have it done. 67 00:02:57,000 --> 00:02:58,080 Also, on a sort of personal note, 68 00:02:58,080 --> 00:02:59,880 so last week I was in Seattle 69 00:02:59,880 --> 00:03:02,240 and I talked at a SQL Database Conference, 70 00:03:02,240 --> 00:03:03,800 which is actually the first time I've ever actually 71 00:03:03,800 --> 00:03:08,240 spoken to a, what, database, like a pure database conference, 72 00:03:08,240 --> 00:03:09,720 which was actually a lot of fun 73 00:03:09,720 --> 00:03:12,280 because, you know, here's the security guy talking about, 74 00:03:12,280 --> 00:03:14,920 well, security in general, like security discipline 75 00:03:14,920 --> 00:03:16,160 to a database audience. 76 00:03:16,160 --> 00:03:19,080 And it was very well received and I got a lot of feedback 77 00:03:19,080 --> 00:03:22,120 and also, you know, I learned a heck of a lot at the same time. 78 00:03:22,120 --> 00:03:27,160 Also, while I was there, we released SQL Server 2022. 79 00:03:27,160 --> 00:03:28,640 So that's now generally available. 80 00:03:28,640 --> 00:03:32,400 I'll provide a link to a YouTube video 81 00:03:32,400 --> 00:03:33,720 hosted by Anna Hoffman. 82 00:03:33,720 --> 00:03:36,760 She's in the SQL Server team called Data Exposed. 83 00:03:36,760 --> 00:03:39,440 And towards the end, I talk about some of the features 84 00:03:39,440 --> 00:03:44,600 that are in SQL Server 2022 from a security standpoint. 85 00:03:44,600 --> 00:03:46,480 So that's all the news I've got. 86 00:03:46,480 --> 00:03:48,640 So with that, let's hand it over to our guest. 87 00:03:48,640 --> 00:03:50,440 So as I mentioned this week, we have Bronwyn Mercer, 88 00:03:50,440 --> 00:03:53,240 who's here to talk to us about privileged access. 89 00:03:53,240 --> 00:03:55,040 So Bronwyn, first of all, welcome to the podcast. 90 00:03:55,040 --> 00:03:57,000 And second, why don't you give our listeners 91 00:03:57,000 --> 00:03:59,800 a little bit of an overview of what you do? 92 00:03:59,800 --> 00:04:01,920 For sure. Thanks so much for having me. 93 00:04:01,920 --> 00:04:04,360 It's a real privilege to be here 94 00:04:04,360 --> 00:04:09,040 and to be part of a podcast, which I listen to myself. 95 00:04:09,040 --> 00:04:12,880 But to introduce myself as Michael mentioned, 96 00:04:12,880 --> 00:04:13,960 my name is Bronwyn Mercer 97 00:04:13,960 --> 00:04:15,720 and I work as a security architect 98 00:04:15,720 --> 00:04:18,160 in Microsoft's consulting services team. 99 00:04:18,160 --> 00:04:23,160 So I get to work with organizations all around Australia, 100 00:04:23,160 --> 00:04:24,880 New Zealand and APAC. 101 00:04:24,880 --> 00:04:27,160 So I'm based in Sydney, Australia 102 00:04:27,160 --> 00:04:31,320 to help them implement Microsoft technologies. 103 00:04:31,320 --> 00:04:36,320 And what that means is making sure that I help those customers 104 00:04:36,800 --> 00:04:39,120 to bake in security by design. 105 00:04:39,120 --> 00:04:42,480 I've also worked in Microsoft's Compromise Recovery team, 106 00:04:42,480 --> 00:04:44,640 which is a really interesting team 107 00:04:44,640 --> 00:04:48,160 that works with customers to recover them 108 00:04:48,160 --> 00:04:51,600 when they experience a serious cyber attack. 109 00:04:51,600 --> 00:04:53,480 So I bring all of that experience 110 00:04:53,480 --> 00:04:56,640 from recovering customers 111 00:04:56,640 --> 00:04:59,320 into now the proactive side of security 112 00:04:59,320 --> 00:05:04,320 and help customers to defend against 113 00:05:04,320 --> 00:05:06,520 real life examples of breaches. 114 00:05:06,520 --> 00:05:09,160 So yeah, it's really interesting. 115 00:05:09,160 --> 00:05:12,800 And I get to use a lot of cutting edge technologies in my work 116 00:05:12,800 --> 00:05:15,600 and I get to work with organizations 117 00:05:15,600 --> 00:05:20,120 who are pushing the boundaries of what's possible in technology. 118 00:05:20,120 --> 00:05:23,840 So excited to share some stories about privileged access. 119 00:05:23,840 --> 00:05:26,960 It's something that I encounter in every customer 120 00:05:26,960 --> 00:05:30,520 regardless of whether we're working on a identity-based solution. 121 00:05:30,520 --> 00:05:32,680 There's always some element of privileged access 122 00:05:32,680 --> 00:05:34,160 that we have to look at. 123 00:05:34,160 --> 00:05:37,720 I'm Fran, I'm gonna say let's go back to basics 124 00:05:37,720 --> 00:05:40,480 and just level set for the audience. 125 00:05:40,480 --> 00:05:43,880 What is privileged access? 126 00:05:43,880 --> 00:05:46,400 What are we talking about when we say privileged access? 127 00:05:46,400 --> 00:05:49,000 Just so we're all on the same page. 128 00:05:49,000 --> 00:05:50,120 Yeah, it's a good question. 129 00:05:50,120 --> 00:05:53,000 I think there's multiple layers of privileged access 130 00:05:53,000 --> 00:05:56,160 in any environment. 131 00:05:56,160 --> 00:05:58,480 When we talk about privileged access at Microsoft, 132 00:05:58,480 --> 00:06:01,360 we have some models around privileged access. 133 00:06:01,360 --> 00:06:03,000 So our enterprise access model, 134 00:06:03,000 --> 00:06:07,600 which is on our securing privileged access guidance. 135 00:06:07,600 --> 00:06:11,240 And that includes layers like the admins 136 00:06:11,240 --> 00:06:14,760 who have control over your identity systems. 137 00:06:14,760 --> 00:06:17,120 So classic one is like Active Directory 138 00:06:17,120 --> 00:06:18,720 and Azure Active Directory. 139 00:06:18,720 --> 00:06:20,960 If you have admin access at that layer, 140 00:06:20,960 --> 00:06:23,560 you basically have control over the whole environment 141 00:06:23,560 --> 00:06:27,360 since most organizations integrate all of their systems 142 00:06:27,360 --> 00:06:32,360 with a centralized identity access management system. 143 00:06:32,600 --> 00:06:35,320 And then we have administrative access 144 00:06:35,320 --> 00:06:40,120 or the ability to make foundational changes to a service 145 00:06:40,120 --> 00:06:43,760 in a specific application or service. 146 00:06:43,760 --> 00:06:46,640 So that could be maybe your SQL server 147 00:06:46,640 --> 00:06:48,960 since I know Michael likes databases. 148 00:06:50,520 --> 00:06:53,000 So there's those different layers in the environment. 149 00:06:53,000 --> 00:06:57,600 I consider, we used to have this thing called the tier model 150 00:06:57,600 --> 00:07:00,120 in on-prem environments. 151 00:07:00,120 --> 00:07:04,480 And tier zero is really the most privileged type of access, 152 00:07:04,480 --> 00:07:05,920 which is the first one I talked about, 153 00:07:05,920 --> 00:07:09,200 which is your admin access in your identity system. 154 00:07:09,200 --> 00:07:10,520 And then we had tier one, 155 00:07:10,520 --> 00:07:13,880 which is admin access within a specific service, 156 00:07:13,880 --> 00:07:15,520 like a business application. 157 00:07:15,520 --> 00:07:19,160 And then tier two is your admin access 158 00:07:19,160 --> 00:07:20,880 at the user device level. 159 00:07:20,880 --> 00:07:23,280 So maybe it's like your intern admins 160 00:07:23,280 --> 00:07:27,160 who can influence your device security. 161 00:07:27,160 --> 00:07:31,240 So admin access is just a bucket 162 00:07:31,240 --> 00:07:33,720 that encompasses all those different levels 163 00:07:33,720 --> 00:07:38,720 of sensitive, high-privileged access 164 00:07:38,880 --> 00:07:42,240 across different types of systems in your environment. 165 00:07:42,240 --> 00:07:45,680 Let's jump into the fun bit, which is, 166 00:07:45,680 --> 00:07:47,760 and I'm sure people who are listening 167 00:07:47,760 --> 00:07:49,240 can probably think of their own as well, 168 00:07:49,240 --> 00:07:51,320 but can you give us some examples 169 00:07:51,320 --> 00:07:54,360 of some bad privilege access setup 170 00:07:54,360 --> 00:07:56,720 or maybe no privilege access setup? 171 00:07:56,720 --> 00:08:00,880 What are the things you've seen out there in the wild? 172 00:08:00,880 --> 00:08:03,520 I've seen some pretty shocking things. 173 00:08:03,520 --> 00:08:05,120 I'm not gonna lie, 174 00:08:05,120 --> 00:08:07,800 especially in my days working in compromised recovery 175 00:08:07,800 --> 00:08:12,160 where most of the time companies who were breached 176 00:08:12,160 --> 00:08:16,520 had really poor privilege access management processes. 177 00:08:16,520 --> 00:08:18,960 So I've seen things like companies 178 00:08:18,960 --> 00:08:23,040 with 100 domain admins in their active directory 179 00:08:23,040 --> 00:08:26,040 and similar numbers of admins in global admins 180 00:08:26,040 --> 00:08:27,880 in their Azure Active Directory. 181 00:08:29,200 --> 00:08:31,920 I've seen things like, for example, 182 00:08:31,920 --> 00:08:36,520 attackers targeting an on-prem Active Directory, 183 00:08:36,520 --> 00:08:39,280 they gain that level of high-privileged access 184 00:08:39,280 --> 00:08:42,800 and then they remain persistent in that environment 185 00:08:42,800 --> 00:08:46,440 for a really long time, funneling out information 186 00:08:46,440 --> 00:08:48,720 like sensitive government information 187 00:08:48,720 --> 00:08:51,600 or sensitive corporate information 188 00:08:51,600 --> 00:08:56,600 and using that for competitive purposes outside. 189 00:08:57,440 --> 00:09:00,000 And then once they've got that foothold 190 00:09:00,000 --> 00:09:02,960 in the on-prem environment, generally they can then pivot 191 00:09:02,960 --> 00:09:07,960 into cloud-based environments like Azure or AWS 192 00:09:08,000 --> 00:09:11,160 and basically try and take control 193 00:09:11,160 --> 00:09:13,960 across the entire enterprise estate. 194 00:09:13,960 --> 00:09:16,520 So one particular example I can think of 195 00:09:16,520 --> 00:09:21,400 which I always remember is there was an attack 196 00:09:21,400 --> 00:09:23,240 on an Australian organization 197 00:09:23,240 --> 00:09:27,840 and they basically the attacker was able to fish a user 198 00:09:27,840 --> 00:09:30,080 through their on-prem device. 199 00:09:30,080 --> 00:09:34,360 They then enrolled a malicious application into Azure AD. 200 00:09:34,360 --> 00:09:36,440 So application registrations, 201 00:09:36,440 --> 00:09:38,400 if you don't have that locked down, 202 00:09:38,400 --> 00:09:42,360 anyone can pretty much register an application into Azure AD. 203 00:09:42,360 --> 00:09:45,200 And then once they had that application enrolled 204 00:09:45,200 --> 00:09:47,120 with a high level of privileges, 205 00:09:47,120 --> 00:09:50,520 they were able to, it was actually an email application. 206 00:09:50,520 --> 00:09:53,560 So they were able to steal all of this email data 207 00:09:53,560 --> 00:09:57,720 out of the organization's email systems 208 00:09:57,720 --> 00:10:00,800 and unfortunately for this organization, 209 00:10:00,800 --> 00:10:04,080 they use their email mailboxes as a way 210 00:10:04,080 --> 00:10:07,440 to store sensitive citizen data 211 00:10:07,440 --> 00:10:10,920 and the attacker registering the application 212 00:10:10,920 --> 00:10:13,040 and being able to get email data 213 00:10:13,040 --> 00:10:17,160 meant that they had access to a lot of sensitive data 214 00:10:17,160 --> 00:10:22,160 of Australian citizens and they were able to use this data 215 00:10:22,360 --> 00:10:24,280 for things like fraud. 216 00:10:24,280 --> 00:10:27,800 So that attack started in the on-prem environment 217 00:10:27,800 --> 00:10:31,040 and then they were able to pivot into the cloud 218 00:10:31,040 --> 00:10:32,960 through an app registration. 219 00:10:32,960 --> 00:10:36,200 And what we see is a lot of organizations, 220 00:10:36,200 --> 00:10:40,080 they start with on-prem and then they build out 221 00:10:40,080 --> 00:10:43,200 their cloud estate and you also have this high level 222 00:10:43,200 --> 00:10:46,200 integration between on-prem and the cloud 223 00:10:46,200 --> 00:10:49,560 through things like your identity synchronization 224 00:10:49,560 --> 00:10:52,680 between Active Directory and Azure Active Directory. 225 00:10:52,680 --> 00:10:57,400 So I guess the lesson learned from this particular cyber attack 226 00:10:57,400 --> 00:11:00,760 which I was involved in responding to was 227 00:11:00,760 --> 00:11:03,560 if you have sensitive information stored in the cloud, 228 00:11:03,560 --> 00:11:06,360 if your cloud systems are production, 229 00:11:06,360 --> 00:11:09,360 like you've got real workloads sitting there, 230 00:11:09,360 --> 00:11:12,480 you need to make sure that you take a conscious effort, 231 00:11:12,480 --> 00:11:16,080 a conscious approach to securing both your on-prem 232 00:11:16,080 --> 00:11:19,960 and your cloud systems, especially that privileged access, 233 00:11:19,960 --> 00:11:23,840 lock down things like application registrations 234 00:11:23,840 --> 00:11:26,080 which provide high levels of privileges 235 00:11:26,080 --> 00:11:31,080 to your sensitive data and look at your whole environment 236 00:11:31,600 --> 00:11:35,000 holistically rather than just one or the other. 237 00:11:35,000 --> 00:11:38,120 So that, yeah, that was a really interesting breach 238 00:11:38,120 --> 00:11:41,440 that I got to respond to a few years ago. 239 00:11:41,440 --> 00:11:42,720 So I have a little tale. 240 00:11:42,720 --> 00:11:43,760 I was working with a customer, 241 00:11:43,760 --> 00:11:44,720 we're going through a threat model, 242 00:11:44,720 --> 00:11:47,640 we're designing something out and I was looking at 243 00:11:47,640 --> 00:11:49,640 sort of a storage account that was being used in Azure 244 00:11:49,640 --> 00:11:52,120 and we asked some questions about the mitigations 245 00:11:52,120 --> 00:11:55,720 and sort of network accessibility to the storage account. 246 00:11:55,720 --> 00:11:58,160 And we found out this storage account 247 00:11:58,160 --> 00:12:00,200 was actually holding relatively sensitive information 248 00:12:00,200 --> 00:12:02,800 and it was probably accessible to the internet. 249 00:12:02,800 --> 00:12:05,760 So we're on the call and next thing, 250 00:12:05,760 --> 00:12:06,600 one of the developers is like, 251 00:12:06,600 --> 00:12:08,760 hang on a minute, let me go and check. 252 00:12:08,760 --> 00:12:10,800 So he went to go and check from his laptop, 253 00:12:10,800 --> 00:12:12,800 he's actually sharing his laptop screen 254 00:12:12,800 --> 00:12:14,880 and he actually connected to production 255 00:12:14,880 --> 00:12:18,400 from his general purpose laptop. 256 00:12:18,400 --> 00:12:20,240 And so I sent a message to the person 257 00:12:20,240 --> 00:12:21,440 I was mainly working with to say, 258 00:12:21,440 --> 00:12:22,720 hey, you know what I think I said about 259 00:12:22,720 --> 00:12:25,120 the storage account possibly being accessible 260 00:12:25,120 --> 00:12:28,320 to the internet, that kind of pales in comparisons 261 00:12:28,320 --> 00:12:31,600 compared to what I just saw, which is, 262 00:12:31,600 --> 00:12:33,560 some, you know, Joe six pack developer 263 00:12:33,560 --> 00:12:37,320 connecting to production from his general purpose laptop, 264 00:12:37,320 --> 00:12:40,320 rather than from a device which is designed 265 00:12:40,320 --> 00:12:42,600 specifically for sort of admin access, 266 00:12:42,600 --> 00:12:45,480 like to these higher levels of essentially sensitivity. 267 00:12:45,480 --> 00:12:48,080 So yeah, that's kind of one of my favorite little stories 268 00:12:48,080 --> 00:12:49,880 and unfortunately I see that quite a bit. 269 00:12:49,880 --> 00:12:51,840 What about, have you seen that quite a few times? 270 00:12:51,840 --> 00:12:53,120 I definitely have. 271 00:12:53,120 --> 00:12:58,120 I think a lot of organizations like this jump host type pattern 272 00:12:58,360 --> 00:12:59,760 for privileged access. 273 00:13:01,600 --> 00:13:03,920 I think it doesn't help sometimes 274 00:13:03,920 --> 00:13:08,920 that some of the standards that exist out in the industry 275 00:13:08,920 --> 00:13:11,880 recommend having that sort of pattern 276 00:13:11,880 --> 00:13:16,080 where you maybe you browse to a secure environment 277 00:13:16,080 --> 00:13:20,000 and then you do your administration from that environment. 278 00:13:20,000 --> 00:13:22,520 And I think that's now being misconstrued 279 00:13:22,520 --> 00:13:26,240 as you can use a less sensitive device 280 00:13:26,240 --> 00:13:29,040 to access a more sensitive environment 281 00:13:29,040 --> 00:13:31,360 from which you do your administration 282 00:13:31,360 --> 00:13:34,760 when in fact we wanna maintain a level of integrity 283 00:13:34,760 --> 00:13:38,240 all the way from the hardware based device 284 00:13:38,240 --> 00:13:41,560 to that sensitive administration environment 285 00:13:41,560 --> 00:13:45,040 to your sensitive systems. 286 00:13:45,040 --> 00:13:47,600 So I'm sure you're aware Michael 287 00:13:47,600 --> 00:13:50,120 of the concept of a privileged access workstation 288 00:13:50,120 --> 00:13:55,120 which is that secure hardware device 289 00:13:55,360 --> 00:13:57,920 that you use to then go and do your administration. 290 00:13:57,920 --> 00:14:01,520 And that should be hardware, not software 291 00:14:01,520 --> 00:14:04,960 so that the attacker can't take control 292 00:14:04,960 --> 00:14:09,200 of the device you're using to do your administration 293 00:14:09,200 --> 00:14:12,760 and add things like a key logger onto that device, 294 00:14:12,760 --> 00:14:15,560 for example, and capture your session. 295 00:14:15,560 --> 00:14:18,280 The whole access path has to be secure. 296 00:14:18,280 --> 00:14:21,680 I can think of a couple of stories too, Bron 297 00:14:21,680 --> 00:14:23,840 around some of this. 298 00:14:23,840 --> 00:14:25,480 But would you say there's, 299 00:14:25,480 --> 00:14:27,240 I mean, obviously you've just given us some examples 300 00:14:27,240 --> 00:14:30,120 as did Michael, would you say there's any 301 00:14:30,120 --> 00:14:33,520 like typical mistakes that people make? 302 00:14:33,520 --> 00:14:35,120 Obviously you've shared, you know, 303 00:14:35,120 --> 00:14:37,120 people having far too many admins 304 00:14:37,120 --> 00:14:40,760 and you know, with high privilege admins. 305 00:14:40,760 --> 00:14:43,960 But are there sort of common misconceptions 306 00:14:43,960 --> 00:14:45,440 or mistakes people make 307 00:14:45,440 --> 00:14:47,840 that you've seen around privileged access? 308 00:14:48,720 --> 00:14:50,720 I think the jump host one is pretty common. 309 00:14:50,720 --> 00:14:55,720 I also see organizations using a PAM type solution 310 00:14:56,000 --> 00:15:01,000 as a alternative to having a poor based device. 311 00:15:01,880 --> 00:15:05,440 So maybe they'll browse up to a PAM 312 00:15:05,440 --> 00:15:07,640 from their regular user workstation 313 00:15:07,640 --> 00:15:12,040 which means you're accessing a sensitive environment 314 00:15:12,040 --> 00:15:17,040 still from a less sensitive or less secured environment. 315 00:15:17,040 --> 00:15:19,440 So what I've done working with customers 316 00:15:19,440 --> 00:15:23,240 has been looking at ways that we can implement pours 317 00:15:23,240 --> 00:15:26,720 and you would access a PAM from a pour, 318 00:15:26,720 --> 00:15:29,480 but it's not either or it's not, 319 00:15:29,480 --> 00:15:33,840 like you need to have a secure device 320 00:15:33,840 --> 00:15:36,520 and a PAM solution if you wanna use 321 00:15:36,520 --> 00:15:39,560 a PAM solution especially for managing 322 00:15:39,560 --> 00:15:41,520 quite sensitive systems in your environment 323 00:15:41,520 --> 00:15:43,840 like your identity systems. 324 00:15:43,840 --> 00:15:46,080 So there's probably more patterns that I see 325 00:15:46,080 --> 00:15:49,200 like there's some kind of anti-patterns. 326 00:15:49,200 --> 00:15:54,200 The UK equivalent of the ACSC in Australia, 327 00:15:56,440 --> 00:15:58,840 they have some quite good privileged access 328 00:15:58,840 --> 00:16:02,080 anti-patterns published on their website. 329 00:16:02,080 --> 00:16:05,280 So I definitely recommend checking out those 330 00:16:05,280 --> 00:16:09,120 and they include things like browse up patterns 331 00:16:09,120 --> 00:16:12,040 for privileged administration. 332 00:16:12,040 --> 00:16:15,520 And that's probably one of the places 333 00:16:15,520 --> 00:16:18,160 that I would go to have a look at some of those, 334 00:16:18,160 --> 00:16:19,800 some models and patterns. 335 00:16:19,800 --> 00:16:23,920 I guess in terms of more broader privileged access, 336 00:16:23,920 --> 00:16:26,680 one of the other things would be having too many admins 337 00:16:26,680 --> 00:16:29,520 who are permanently assigned privileges. 338 00:16:29,520 --> 00:16:32,160 So today we talk about just in time access 339 00:16:32,160 --> 00:16:33,680 when it comes to privileged access. 340 00:16:33,680 --> 00:16:37,280 And I think tools like PIM that are built into Azure 341 00:16:37,280 --> 00:16:41,040 make that really easy, but often in on-prem environments 342 00:16:41,040 --> 00:16:43,480 it can be quite tricky to implement 343 00:16:43,480 --> 00:16:44,960 that kind of just in time access, 344 00:16:44,960 --> 00:16:48,720 especially if you don't have a third party technology 345 00:16:50,000 --> 00:16:52,280 or a PAM solution in your environment. 346 00:16:53,320 --> 00:16:55,240 And just for anyone who's listening, 347 00:16:55,240 --> 00:16:58,640 can we just recap what those acronyms are? 348 00:16:58,640 --> 00:16:59,640 Just some... 349 00:16:59,640 --> 00:17:03,640 For sure, so a PAM solution is privileged access management, 350 00:17:03,640 --> 00:17:06,440 which can perform a few different functions 351 00:17:06,440 --> 00:17:10,320 like password vaulting, it can do session management, 352 00:17:10,320 --> 00:17:13,200 it can do just in time access to certain roles 353 00:17:13,200 --> 00:17:14,800 in your environment as well. 354 00:17:16,200 --> 00:17:20,600 Yeah, and for those of us who aren't in Australia, 355 00:17:20,600 --> 00:17:23,440 the ACSC, in fact, you know what, Brod, I know who they are 356 00:17:23,440 --> 00:17:26,800 and I can't remember what the acronym stands for right now. 357 00:17:26,800 --> 00:17:30,240 So I just looked up the UK equivalent 358 00:17:30,240 --> 00:17:32,360 is the National Cyber Security Centre. 359 00:17:32,360 --> 00:17:35,800 And in Australia we have the Australian Cyber Security Centre, 360 00:17:35,800 --> 00:17:37,880 which is our proper organization. 361 00:17:37,880 --> 00:17:40,400 It's kind of like the NSA in the US. 362 00:17:40,400 --> 00:17:42,400 Yeah, I was just about to say, it's probably... 363 00:17:42,400 --> 00:17:46,320 Yeah, the US equivalent is probably like the NSA 364 00:17:46,320 --> 00:17:47,520 or something similar. 365 00:17:47,520 --> 00:17:52,360 So essentially, government agencies that help with cyber 366 00:17:52,360 --> 00:17:54,480 and give out guidance and... 367 00:17:54,480 --> 00:17:56,920 That sense, yeah. 368 00:17:56,920 --> 00:17:59,960 And obviously most countries have them, I think, nowadays. 369 00:17:59,960 --> 00:18:02,520 So, well, we've already kind of gone into this a bit, 370 00:18:02,520 --> 00:18:07,520 but, Brod, what is the solution to privilege access? 371 00:18:07,520 --> 00:18:09,920 I mean, obviously that's a big question 372 00:18:09,920 --> 00:18:11,240 and there's many things you can do, 373 00:18:11,240 --> 00:18:13,840 but in simple terms, what would you say 374 00:18:13,840 --> 00:18:16,520 is the best thing folks can do here? 375 00:18:17,800 --> 00:18:19,000 Yeah, good question. 376 00:18:19,000 --> 00:18:22,160 I mean, there's some really simple things you can do 377 00:18:22,160 --> 00:18:24,960 for your organization that make a huge difference. 378 00:18:24,960 --> 00:18:29,160 Things like making sure you have multi-factor authentication 379 00:18:29,160 --> 00:18:31,880 enabled, least privilege, 380 00:18:31,880 --> 00:18:36,080 making sure that people don't have permanently assigned permissions. 381 00:18:36,080 --> 00:18:39,960 But Microsoft actually has some really good guidance 382 00:18:39,960 --> 00:18:43,560 published online, which is our Securing Privileged Access Guidance, 383 00:18:43,560 --> 00:18:47,560 and we used to refer a lot to the model I mentioned earlier, 384 00:18:47,560 --> 00:18:50,760 which is the tiered administrative guidance. 385 00:18:50,760 --> 00:18:54,760 So, we used to refer to the tiered administration model, 386 00:18:54,760 --> 00:18:58,760 which provided the levels of separation 387 00:18:58,760 --> 00:19:01,360 within your Active Directory environment 388 00:19:01,360 --> 00:19:06,360 to make sure that admins weren't logging on to lower tier systems 389 00:19:06,360 --> 00:19:08,560 or less secure systems 390 00:19:08,560 --> 00:19:11,360 and exposing their credentials to those systems. 391 00:19:11,360 --> 00:19:16,360 Nowadays, we have a revised version of our privileged access model, 392 00:19:16,360 --> 00:19:18,960 which is called the Enterprise Access Model, 393 00:19:18,960 --> 00:19:21,560 and some concepts like we want to make sure that we have 394 00:19:21,560 --> 00:19:26,560 high integrity workflows throughout the privileged access process, 395 00:19:26,560 --> 00:19:28,160 making sure you have a secure device, 396 00:19:28,160 --> 00:19:33,560 which is the same level of integrity as the system that you're accessing. 397 00:19:33,560 --> 00:19:37,560 And by that, I mean, you can't tamper with that device, 398 00:19:37,560 --> 00:19:39,960 and so you have a high level of confidence 399 00:19:39,960 --> 00:19:43,160 that the person who's accessing the sensitive system 400 00:19:43,160 --> 00:19:44,560 is who they say they are, 401 00:19:44,560 --> 00:19:49,160 and the device hasn't been tampered with by an attacker. 402 00:19:49,160 --> 00:19:52,760 So, I would definitely recommend having a look at the Enterprise Access Model. 403 00:19:52,760 --> 00:19:57,760 In fact, I actually had a chance to work with a customer earlier this year 404 00:19:57,760 --> 00:20:00,960 on a Greenfield Azure deployment, 405 00:20:00,960 --> 00:20:03,760 and one of the questions the customer had was, 406 00:20:03,760 --> 00:20:06,760 how do we set up our Azure environment 407 00:20:06,760 --> 00:20:11,160 using all of the Microsoft best practices for privileged access management? 408 00:20:11,160 --> 00:20:18,160 So, this was an amazing opportunity to apply those Enterprise Access Model concepts 409 00:20:18,160 --> 00:20:21,160 to setting up privileged access from scratch 410 00:20:21,160 --> 00:20:23,760 using completely cloud-native technologies 411 00:20:23,760 --> 00:20:27,960 without any of the tech debt which we so often encounter 412 00:20:27,960 --> 00:20:32,560 when we're working in on-prem or hybrid environments. 413 00:20:32,560 --> 00:20:36,360 So, what that solution looked like was, 414 00:20:36,360 --> 00:20:38,160 I mentioned privileged access workstations. 415 00:20:38,160 --> 00:20:41,560 We did have pause, and they were completely cloud-managed. 416 00:20:41,560 --> 00:20:44,160 They were managed using Intune, 417 00:20:44,160 --> 00:20:49,960 and we had policies applied to those pause to harden them 418 00:20:49,960 --> 00:20:55,560 to make sure that they had a certain level of integrity, as I mentioned, 419 00:20:55,560 --> 00:20:59,360 and as part of the access into the environment, 420 00:20:59,360 --> 00:21:04,960 we were using conditional access to evaluate the posture of the device. 421 00:21:04,960 --> 00:21:09,360 Does it meet certain compliance policies? Is it fully patched? 422 00:21:09,360 --> 00:21:13,960 Does it have a low risk score according to Defender for Endpoint? 423 00:21:13,960 --> 00:21:18,360 Has the user authenticated using Windows Hello for Business? 424 00:21:18,360 --> 00:21:21,960 All of these signals come together in something 425 00:21:21,960 --> 00:21:25,760 that very much resembles our Zerotrust model, 426 00:21:25,760 --> 00:21:31,560 and that evaluation happens using CA, the Admin Accesses, Azure, 427 00:21:31,560 --> 00:21:36,960 and then in order to access their roles like Global Administrator, 428 00:21:36,960 --> 00:21:42,960 they then use PIM and they have workflows to approve their access 429 00:21:42,960 --> 00:21:45,160 to those privileged roles. 430 00:21:45,160 --> 00:21:48,760 In addition, those accounts which they're using to log on to their device 431 00:21:48,760 --> 00:21:53,560 and access Azure are all cloud-only accounts for privileged access. 432 00:21:53,560 --> 00:21:55,960 So, we're not using any synchronization. 433 00:21:55,960 --> 00:21:58,160 I mean, this environment is cloud-native anyway, 434 00:21:58,160 --> 00:22:02,160 so we didn't have any of the on-prem dependencies, 435 00:22:02,160 --> 00:22:07,360 but that's probably one of the best examples I've seen of an organization 436 00:22:07,360 --> 00:22:12,560 who has set up their privileged access according to Microsoft's public guidance, 437 00:22:12,560 --> 00:22:16,960 and we've used Zerotrust as a foundation, 438 00:22:16,960 --> 00:22:19,760 and we've implemented all of the cloud-native controls 439 00:22:19,760 --> 00:22:22,560 across the privileged access workflow. 440 00:22:22,560 --> 00:22:25,760 And they're really enjoying it so far 441 00:22:25,760 --> 00:22:30,160 because all of their administrators are distributed all across Australia, 442 00:22:30,160 --> 00:22:31,560 and some of them are overseas as well, 443 00:22:31,560 --> 00:22:33,760 and they don't need to worry about things like, 444 00:22:33,760 --> 00:22:36,760 am I on the organization's network? 445 00:22:36,760 --> 00:22:40,760 Like, am I within the trusted IP range of the organization's network? 446 00:22:40,760 --> 00:22:42,160 That doesn't matter anymore. 447 00:22:42,160 --> 00:22:45,760 It's all about, is your device secure? 448 00:22:45,760 --> 00:22:48,560 Have you authenticated using strong authentication? 449 00:22:48,560 --> 00:22:51,360 Windows Hello for Business is great 450 00:22:51,360 --> 00:22:55,560 because it balances the usability and the security aspects. 451 00:22:55,560 --> 00:23:00,760 And then, are you elevating your privileges just in time 452 00:23:00,760 --> 00:23:02,560 and having that access approved? 453 00:23:02,560 --> 00:23:08,560 So that combination has enabled that customer to be very productive 454 00:23:08,560 --> 00:23:10,560 in their privileged access workflows. 455 00:23:10,560 --> 00:23:14,360 So highly recommend having a look at our public guidance, 456 00:23:14,360 --> 00:23:17,960 and I've actually been working on some updates to that guidance 457 00:23:17,960 --> 00:23:21,560 to help with providing some of the lessons learned 458 00:23:21,560 --> 00:23:24,960 from the projects I've worked on through my consulting engagement 459 00:23:24,960 --> 00:23:29,560 so that we can help customers to see those success stories 460 00:23:29,560 --> 00:23:32,360 because I think sometimes if you just read the documentation, 461 00:23:32,360 --> 00:23:35,960 it can be a little bit abstract and you need some good examples. 462 00:23:35,960 --> 00:23:39,160 So keep a look out on our public docs, 463 00:23:39,160 --> 00:23:43,360 like our Securing Privileged Access Docs for updates, 464 00:23:43,360 --> 00:23:44,760 hopefully coming soon. 465 00:23:44,760 --> 00:23:46,560 That's super cool. 466 00:23:46,560 --> 00:23:48,360 I will definitely need to look at that. 467 00:23:48,360 --> 00:23:53,560 So I know that you did sort of just allude to this before 468 00:23:53,560 --> 00:23:57,760 you were talking about a customer that was totally greenfield, 469 00:23:57,760 --> 00:24:01,960 but when you've got a completely greenfield solution, 470 00:24:01,960 --> 00:24:04,760 let's say it's ideal case with zero tech debt, 471 00:24:04,760 --> 00:24:11,960 what would be your like, where would you start if there was zero tech debt? 472 00:24:11,960 --> 00:24:13,760 What's the best thing to do? 473 00:24:13,760 --> 00:24:18,360 Obviously, yeah, you've been lucky enough to work with some customers like that. 474 00:24:18,360 --> 00:24:21,160 Don't think I've ever worked with customers with zero tech debt. 475 00:24:21,160 --> 00:24:22,360 That's very exciting. 476 00:24:22,360 --> 00:24:23,760 What a unicorn. 477 00:24:23,760 --> 00:24:28,560 It was an amazing opportunity and I definitely take those learnings 478 00:24:28,560 --> 00:24:31,960 into my other customers, most of whom are hybrid. 479 00:24:31,960 --> 00:24:36,560 I think the general type of organization that I work with 480 00:24:36,560 --> 00:24:39,560 still has a lot of on-prem infrastructure 481 00:24:39,560 --> 00:24:42,560 and usually they're still running all of their identity systems 482 00:24:42,560 --> 00:24:46,760 out of Active Directory rather than using Azure AD as the master. 483 00:24:46,760 --> 00:24:51,160 That's pretty uncommon in my experience. 484 00:24:51,160 --> 00:24:56,160 But where I would start if I was setting up from scratch is, 485 00:24:56,160 --> 00:24:58,560 I mean, from my experience on that customer, 486 00:24:58,560 --> 00:25:04,360 we started with firstly having separate admin accounts which were cloud only. 487 00:25:04,360 --> 00:25:10,760 So we had on microsoft.com accounts in that customer's tenant. 488 00:25:10,760 --> 00:25:13,560 We had conditional access policies. 489 00:25:13,560 --> 00:25:18,760 So we had a baseline set of conditional access policies for access into the tenant. 490 00:25:18,760 --> 00:25:20,560 We didn't start with pause. 491 00:25:20,560 --> 00:25:23,760 That was a piece that came along later. 492 00:25:23,760 --> 00:25:27,360 But at the very start, when we were building the tenant, 493 00:25:27,360 --> 00:25:32,560 we did have CA policies to evaluate things like multi-factor authentication. 494 00:25:32,560 --> 00:25:40,160 That was priority number one to look at things like where those logins were coming from. 495 00:25:40,160 --> 00:25:41,960 So it was an Australian based customer. 496 00:25:41,960 --> 00:25:48,560 So all of our admins were coming from Australia. 497 00:25:48,560 --> 00:25:55,960 And I think we also had some perhaps device registration requirements, 498 00:25:55,960 --> 00:25:58,760 but it was fairly minimal at the beginning. 499 00:25:58,760 --> 00:26:01,160 We did also set up PIM at the beginning as well. 500 00:26:01,160 --> 00:26:06,360 So we didn't have everyone with global administrator privileges. 501 00:26:06,360 --> 00:26:14,160 It should be pretty rare that you need to have people who are using global admin every single day. 502 00:26:14,160 --> 00:26:21,560 If you're delegating privileges properly, you can request that access and then use it as required. 503 00:26:21,560 --> 00:26:26,360 We also set up PIM for some of the high privileged as a resource roles, 504 00:26:26,360 --> 00:26:30,560 so as our back roles like contributor and owner. 505 00:26:30,560 --> 00:26:34,560 It should be pretty rare as well that you need to have those kind of privileges, 506 00:26:34,560 --> 00:26:36,760 especially in a production environment. 507 00:26:36,760 --> 00:26:42,360 If you're using DevOps type processes to deploy your infrastructure. 508 00:26:42,360 --> 00:26:47,960 So in this case, we were using Azure DevOps to deploy all of our infrastructure. 509 00:26:47,960 --> 00:26:54,160 And so most of the infrastructure updates were coming through the pipelines. 510 00:26:54,160 --> 00:26:56,960 So yeah, at least privilege all the way, I'd say. 511 00:26:56,960 --> 00:26:57,960 Fair enough. 512 00:26:57,960 --> 00:27:03,360 I mean, least privilege is pretty, well, we've been preaching least privilege for a long time, right? 513 00:27:03,360 --> 00:27:06,360 And I think the thing is though, you need to keep watching it. 514 00:27:06,360 --> 00:27:08,560 So it builds up over time. 515 00:27:08,560 --> 00:27:15,560 So even when that system went live, we did have to do another call of user access because even if you have great processes, 516 00:27:15,560 --> 00:27:21,160 you still need to trust that verify and go back and do those regular user access reviews. 517 00:27:21,160 --> 00:27:29,360 There's like a process component as well that you need to look at to operationalize your privileged access management in your environment. 518 00:27:29,360 --> 00:27:37,560 Well, in one of my previous roles, one of my previous employees, we used to do the privilege access review manually. 519 00:27:37,560 --> 00:27:39,160 It took a really long time. 520 00:27:39,160 --> 00:27:41,960 It was something people dreaded doing. 521 00:27:41,960 --> 00:27:47,360 We actually got third party people contractors in to come and do it, which I'm sure was very expensive. 522 00:27:47,360 --> 00:27:55,160 And the great thing is now at least we can, we have tools to make it a lot easier, but it is still iterative, right? 523 00:27:55,160 --> 00:28:02,760 We've still got to keep doing it, keep reviewing it, which I think is your point, right, Bron? 524 00:28:02,760 --> 00:28:03,560 Exactly. 525 00:28:03,560 --> 00:28:10,560 Yeah, I think one of the things about deploying systems in the cloud is it's not just a one-time activity. 526 00:28:10,560 --> 00:28:15,560 You have to have that mindset of continuous optimization. 527 00:28:15,560 --> 00:28:25,760 It's like optimization in a security sense, making sure that you improve your security processes and also like your overall governance, your cost management. 528 00:28:25,760 --> 00:28:31,160 All of the elements are going to running a environment that's well architected. 529 00:28:31,160 --> 00:28:46,960 There's definitely a process component and I think that aligns with agile methodologies, things like continuous security, continuous optimization, all of those mindsets apply to security in the cloud. 530 00:28:46,960 --> 00:28:59,260 And I guess the other aspect of security in the cloud is that vendors like Microsoft are continuously releasing new features and things that you can enable to help you with your security. 531 00:28:59,260 --> 00:29:07,660 So I think of things like Entra, for example, which has come in and provided a bunch of new features that you can use. 532 00:29:07,660 --> 00:29:18,260 If you were just using the features that you used one year ago in the cloud, you're already behind because you're not using all the benefits that you get from your licensing. 533 00:29:18,260 --> 00:29:24,760 So even just reviewing what's available to you from a licensing perspective is extremely valuable. 534 00:29:24,760 --> 00:29:34,460 So you might not need another third party product because Microsoft will introduce something that's included in your E5 licensing bundle, for example. 535 00:29:34,460 --> 00:29:43,160 So it really is that iterative process where you keep building up your capabilities over time. 536 00:29:43,160 --> 00:29:45,460 Yeah, there's a lot going on there. 537 00:29:45,460 --> 00:29:50,060 And even for those of us that work at Microsoft, it can be hard to keep up with everything that changes, right? 538 00:29:50,060 --> 00:29:52,860 Because the rate of change is so quick. 539 00:29:52,860 --> 00:29:54,760 Ron, it has been a pleasure. 540 00:29:54,760 --> 00:30:03,560 But what we always ask our guests before they leave is if you could leave our listeners with one thought, what would it be? 541 00:30:03,560 --> 00:30:08,960 I would say it's all about the process and the technology. 542 00:30:08,960 --> 00:30:15,260 So make sure you have both of those components considered as part of your security strategy. 543 00:30:15,260 --> 00:30:21,860 I guess when it comes to privileged access, make sure you are reviewing your processes 544 00:30:21,860 --> 00:30:28,560 because things like what I mentioned earlier with 100 domain admins or 100 global admins, 545 00:30:28,560 --> 00:30:33,360 that's not just technology weakness, it is also a process weakness. 546 00:30:33,360 --> 00:30:41,160 Make sure you are reviewing regularly how many people have that sort of high level of access in your environment 547 00:30:41,160 --> 00:30:48,960 because that's going to be what an attacker is going to abuse to remain persistent in your environment if they get in. 548 00:30:48,960 --> 00:30:53,360 And today we say it's not just a matter of if, it's a matter of when. 549 00:30:53,360 --> 00:31:01,860 So do think about the technology and the process aspects and try and balance security and usability. 550 00:31:01,860 --> 00:31:05,160 That would be the main things that I would say. 551 00:31:05,160 --> 00:31:16,660 It sounds like a bit of a cliche, but it is all about making sure that your security controls are highly usable and fit for purpose, especially for your business users. 552 00:31:16,660 --> 00:31:18,960 Yeah, I couldn't agree more. 553 00:31:18,960 --> 00:31:25,660 Thank you ever so much, Bron, for joining us this time and thanks everybody for listening. 554 00:31:25,660 --> 00:31:31,560 If you're in the US, enjoy the holiday period that is coming up. 555 00:31:31,560 --> 00:31:40,860 And well, if you're listening to this relatively close to when we release it and stay safe and we'll see you next time. 556 00:31:40,860 --> 00:31:43,760 Thanks for listening to the Azure Security Podcast. 557 00:31:43,760 --> 00:31:50,560 You can find show notes and other resources at our website azsecuritypodcast.net. 558 00:31:50,560 --> 00:31:55,360 If you have any questions, please find us on Twitter at Azure Set Pod. 559 00:31:55,360 --> 00:32:14,960 Background music is from ccmixter.com and licensed under the Creative Commons license.