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:16,600 Hey everybody, welcome to Episode 45. 5 00:00:16,600 --> 00:00:19,720 This week is myself, Michael, Sarah, and Mark. 6 00:00:19,720 --> 00:00:21,000 We also have a guest, 7 00:00:21,000 --> 00:00:23,320 Kristen Burke, who's here to talk to us about 8 00:00:23,320 --> 00:00:27,160 Zero Trust in a SOC, Security Operations Center. 9 00:00:27,160 --> 00:00:28,840 But before we get to Kristen, 10 00:00:28,840 --> 00:00:31,200 let's take a quick lap around the news. 11 00:00:31,200 --> 00:00:32,800 Sarah, why don't you kick things off? 12 00:00:32,800 --> 00:00:35,800 It's one of those weeks when I'm going to talk about my baby, 13 00:00:35,800 --> 00:00:37,800 I'm going to talk about what's new in Sentinel, 14 00:00:37,800 --> 00:00:42,680 a couple of things that are actually worth mentioning if you are using it. 15 00:00:42,680 --> 00:00:47,960 One of my very talented colleagues has 16 00:00:47,960 --> 00:00:52,240 created a workbook and a tutorial for KQL. 17 00:00:52,240 --> 00:00:54,320 KQL is Kusto Query Language, 18 00:00:54,320 --> 00:00:56,960 we use it in Sentinel and other Microsoft products. 19 00:00:56,960 --> 00:01:01,040 It's worth learning if you're using Microsoft Things. 20 00:01:01,540 --> 00:01:06,240 We've got a nice blog post which we'll link to in the show notes, 21 00:01:06,240 --> 00:01:09,400 and the workbook is actually already found in the product. 22 00:01:09,400 --> 00:01:14,240 So it can help you go learn some KQL if you're getting up to speed on it. 23 00:01:14,240 --> 00:01:19,720 Also, if you're using multiple workspaces in your Sentinel deployment, 24 00:01:19,720 --> 00:01:23,160 you can now look at 30 workspaces simultaneously. 25 00:01:23,160 --> 00:01:24,280 It used to be 10. 26 00:01:24,280 --> 00:01:28,760 So in particular, that's pretty useful if you're a service provider, 27 00:01:28,760 --> 00:01:34,600 or maybe if you're an organization that has multiple workspaces, 28 00:01:34,600 --> 00:01:37,920 or multiple tenants, if you've got different entities. 29 00:01:37,920 --> 00:01:43,480 Then another cool thing that's gone into public preview is the Health Data Table. 30 00:01:43,480 --> 00:01:47,640 What it does is it helps you monitor your connector health. 31 00:01:47,640 --> 00:01:51,120 So we get asked for this all the time. 32 00:01:51,120 --> 00:01:55,000 If I turn on this connector, if it stops sending or something goes wrong, 33 00:01:55,000 --> 00:01:56,440 how will I know? 34 00:01:56,440 --> 00:01:59,920 So now that Sentinel Health Data Table will help you do that. 35 00:01:59,920 --> 00:02:02,840 So check that one out too, very cool. 36 00:02:02,840 --> 00:02:05,040 I'm just going to keep it nice and brief this time. 37 00:02:05,040 --> 00:02:06,480 Yeah. So from my side, 38 00:02:06,480 --> 00:02:09,600 nothing specific on the news links perspective, 39 00:02:09,600 --> 00:02:15,000 but how did the interesting realization that we're refining out? 40 00:02:15,000 --> 00:02:17,280 I've been working on some updates to 41 00:02:17,280 --> 00:02:19,120 the Cloud Adoption Framework Secure Guidance, 42 00:02:19,120 --> 00:02:26,200 our guidance for the security program level teams and structures and goals and metrics, 43 00:02:26,200 --> 00:02:28,920 and also having some similar discussions within 44 00:02:28,920 --> 00:02:31,720 the Open Group Zero Trust Architecture Forum. 45 00:02:31,720 --> 00:02:38,440 One of the points of clarity I came to through all these discussions was that security really 46 00:02:38,440 --> 00:02:44,920 has two different operational arms within the security organization function. 47 00:02:44,920 --> 00:02:47,040 One of them, most people recognize, 48 00:02:47,040 --> 00:02:51,400 and actually Chris and Sierra who's spent some time in our Microsoft SOC, 49 00:02:51,400 --> 00:02:52,840 and there's the SOC, 50 00:02:52,840 --> 00:02:55,320 dealing with the actual incidents to realize risk, 51 00:02:55,320 --> 00:02:59,360 the oh gosh, there is an attacker live real and dealing with it. 52 00:02:59,360 --> 00:03:01,360 But then there's the other half of it. 53 00:03:01,360 --> 00:03:06,600 This one I feel like has been missing from a lot of security organizations for a long time, 54 00:03:06,600 --> 00:03:10,000 is proactive preventive or we're calling, 55 00:03:10,000 --> 00:03:14,560 process management because security doesn't own the IT operations environment. 56 00:03:14,560 --> 00:03:18,240 They don't own the servers or the databases or anything like that. 57 00:03:18,240 --> 00:03:22,560 The uptime of that usually lands on IT ops or sometimes DevOps teams. 58 00:03:22,560 --> 00:03:28,000 But security actually does need to have an operational team that's monitoring that stuff, 59 00:03:28,000 --> 00:03:29,280 that's looking for the risk, 60 00:03:29,280 --> 00:03:31,640 that's helping those teams correct the risk, 61 00:03:31,640 --> 00:03:33,560 coming up with plans, et cetera. 62 00:03:33,560 --> 00:03:37,320 That's one of the things that was an interesting realization is there really are 63 00:03:37,320 --> 00:03:41,480 two distinct and important functions in there. 64 00:03:41,480 --> 00:03:45,600 But that was the big realization for me since the last time. 65 00:03:45,600 --> 00:03:49,920 I have a few items that peaked my interest over the last few weeks. 66 00:03:49,920 --> 00:03:52,000 The first is in public preview, 67 00:03:52,000 --> 00:03:55,000 support for managed identities and Azure cash for Redis. 68 00:03:55,000 --> 00:03:57,080 I did not see this one coming. 69 00:03:57,080 --> 00:04:00,600 I've been talking the last few months about, 70 00:04:00,600 --> 00:04:03,400 we're seeing more PaaS services supporting 71 00:04:03,400 --> 00:04:06,360 managed identities and obviously now Redis cash has got that. 72 00:04:06,360 --> 00:04:08,440 What this means is that you can have 73 00:04:08,440 --> 00:04:12,880 an RBAC policy on a storage account that only allows that Redis cash to 74 00:04:12,880 --> 00:04:14,760 actually write to it and nothing else. 75 00:04:14,760 --> 00:04:16,360 This is really great to see. 76 00:04:16,360 --> 00:04:17,800 Again, I've mentioned this many times, 77 00:04:17,800 --> 00:04:21,240 but we've seen more and more PaaS services support managed identity. 78 00:04:21,240 --> 00:04:23,280 So that way you don't have to worry about the credential. 79 00:04:23,280 --> 00:04:26,560 This is great to see one that I honestly did not see coming. 80 00:04:26,560 --> 00:04:32,160 Next one is also in public preview is managed certificate support in API management. 81 00:04:32,160 --> 00:04:36,440 If you're using TLS into the front end of any system for that matter, 82 00:04:36,440 --> 00:04:39,920 managing certificates especially as they're getting close to expiry, 83 00:04:39,920 --> 00:04:42,120 tends to leave people sweating. 84 00:04:42,120 --> 00:04:44,080 Well, we've now got basically 85 00:04:44,080 --> 00:04:48,280 automated certificate support including free certificate provisioning. 86 00:04:48,280 --> 00:04:50,400 So this is another great thing to see. 87 00:04:50,400 --> 00:04:56,520 Next one is now in GA is FIPS enabled node pools and Azure Kubernetes. 88 00:04:56,520 --> 00:04:58,680 Normally, Sarah would talk about this, 89 00:04:58,680 --> 00:05:01,640 but this is crypto so it's in my wheelhouse. 90 00:05:01,640 --> 00:05:05,480 We now have the ability to run FIPS 140-2. 91 00:05:05,480 --> 00:05:07,840 I'm surprised that it's 140-2. 92 00:05:07,840 --> 00:05:14,160 My guess is the evaluation must have happened before September 2021. 93 00:05:14,160 --> 00:05:16,640 It's now been replaced by FIPS 140-3. 94 00:05:16,640 --> 00:05:20,240 But basically what this is is you have cryptographic algorithms, 95 00:05:20,240 --> 00:05:22,560 and then you have some implementations of those in modules. 96 00:05:22,560 --> 00:05:23,920 So for example, in libraries. 97 00:05:23,920 --> 00:05:27,360 Well, those libraries also need to be evaluated to make sure that they 98 00:05:27,360 --> 00:05:29,800 are correct implementation of the algorithms. 99 00:05:29,800 --> 00:05:34,960 That's what gets you the FIPS 140-2 or FIPS 140-3 verification. 100 00:05:34,960 --> 00:05:38,760 So that's now available in AKS. 101 00:05:38,760 --> 00:05:42,040 Really important for people like government customers. 102 00:05:42,040 --> 00:05:45,120 So for example, for part of FedRAMP compliance. 103 00:05:45,120 --> 00:05:47,880 So this is really great to see. 104 00:05:47,880 --> 00:05:51,400 Next one and the last one is, 105 00:05:51,400 --> 00:05:53,600 I did not see this one coming either. 106 00:05:53,600 --> 00:05:58,840 There are price reductions for Azure confidential compute VMs. 107 00:05:58,840 --> 00:06:05,880 In some instances for the DCS version 2 and the DCS version 3 series VMs, 108 00:06:05,880 --> 00:06:08,280 these are the ones that support confidential compute. 109 00:06:08,280 --> 00:06:11,360 We're seeing price reductions up to about 33 percent, 110 00:06:11,360 --> 00:06:16,000 which brings them much more in line with general purpose VMs. 111 00:06:16,000 --> 00:06:20,680 This can only help with the adoption of confidential computing workloads, 112 00:06:20,680 --> 00:06:23,480 especially if you want to run things like SQL, 113 00:06:23,480 --> 00:06:26,800 Azure SQL DB with always encrypted and secure enclaves. 114 00:06:26,800 --> 00:06:31,680 You have to use a DCS series VM. 115 00:06:31,680 --> 00:06:33,680 So the cost of that is going to come down, 116 00:06:33,680 --> 00:06:35,240 well, approximately 33 percent. 117 00:06:35,240 --> 00:06:38,680 That's fantastic. That actually went into effect on the first of January this year. 118 00:06:38,680 --> 00:06:42,600 So the price reduction is retrospective. 119 00:06:42,600 --> 00:06:45,640 So that's all the news I have. 120 00:06:45,640 --> 00:06:48,640 So with that, let's now turn our attention to our guest. 121 00:06:48,640 --> 00:06:50,560 This week we have Kristen Burke, 122 00:06:50,560 --> 00:06:57,160 who's here to talk to us about how to help your SOC during a zero-trust transition. 123 00:06:57,160 --> 00:06:59,000 Kristen, welcome to the podcast. 124 00:06:59,000 --> 00:07:02,880 Can you spend a little moment to explain what you do and how you've been at Microsoft? 125 00:07:02,880 --> 00:07:04,560 Thank you so much for having me. 126 00:07:04,560 --> 00:07:07,440 I've been at Microsoft for eight years now, 127 00:07:07,440 --> 00:07:10,800 and I've been in security for about 18 years. 128 00:07:10,800 --> 00:07:12,640 So the last four years, 129 00:07:12,640 --> 00:07:16,600 I've worked as a SOC architect for our DSR, 130 00:07:16,600 --> 00:07:19,520 Digital Security and Resilience Internal SOC. 131 00:07:19,520 --> 00:07:22,360 So at Microsoft, there are a bunch of different SOCs actually, 132 00:07:22,360 --> 00:07:29,040 but we're the SOC that takes care of the corporate identities and workstations and any policies. 133 00:07:29,040 --> 00:07:30,280 So we're the most like, 134 00:07:30,280 --> 00:07:32,920 if you go to a different company that doesn't have five SOCs, 135 00:07:32,920 --> 00:07:36,800 you were the most like the corporate SOC for any other company. 136 00:07:36,800 --> 00:07:40,560 I've been an architect for the SOC and instant response teams, 137 00:07:40,560 --> 00:07:42,280 that's Security Operations Center. 138 00:07:42,280 --> 00:07:47,040 A lot of times when I'm talking about zero trust or the zero trust transition, 139 00:07:47,040 --> 00:07:50,480 I'm talking about Microsoft's internal transition, 140 00:07:50,480 --> 00:07:54,880 what we have done with our own corporate environment, 141 00:07:54,880 --> 00:07:56,160 with our own corporate network, 142 00:07:56,160 --> 00:08:01,720 and making sure that we have good policies for moving forward on a zero trust or 143 00:08:01,720 --> 00:08:05,280 bust as Brett Arsenault or CISO likes to say. 144 00:08:05,280 --> 00:08:07,080 One of the things I wanted to ask you about, 145 00:08:07,080 --> 00:08:11,040 Kristen, we've put the security operations or 146 00:08:11,040 --> 00:08:15,720 security operations center SOC under zero trust as part of like an overall sort of 147 00:08:15,720 --> 00:08:19,280 big zero trust modernization plan. 148 00:08:19,280 --> 00:08:21,320 Of course, there's also zero trust access control, 149 00:08:21,320 --> 00:08:27,800 which is like a kind of sitting next to a kind of parallel initiative to the security operations piece. 150 00:08:27,800 --> 00:08:33,400 I wanted to see what your thoughts are on that and how Microsoft views that sort of 151 00:08:33,400 --> 00:08:36,240 from that sort of CISO's perspective, 152 00:08:36,240 --> 00:08:40,920 as well as the other kind of interactions with the other elements of zero trust. 153 00:08:40,920 --> 00:08:45,760 I'd love to kind of hear your perspective on how SOC and zero trust interact in different ways. 154 00:08:45,760 --> 00:08:47,360 At least at Microsoft, 155 00:08:47,360 --> 00:08:54,680 I think that we have several different teams and DSR is a larger team where you have people who 156 00:08:54,680 --> 00:08:58,200 basically run security policies or security initiatives, 157 00:08:58,200 --> 00:09:00,760 and then the SOC is separate from that. 158 00:09:00,760 --> 00:09:03,560 I think that at Microsoft, 159 00:09:03,560 --> 00:09:07,800 it has been more of these people who drive security principles and initiatives 160 00:09:07,800 --> 00:09:14,280 driving zero trust at the company and really the decisions being made at the CISO and CVP level 161 00:09:14,280 --> 00:09:16,800 for what we're going to do for zero trust. 162 00:09:16,800 --> 00:09:23,680 But I think that to some extent, having the SOC and the help desk under that, 163 00:09:23,680 --> 00:09:31,080 super involved in making sure that they are very engaged and sort of step together with the policy makers, 164 00:09:31,080 --> 00:09:33,200 I think is super important. 165 00:09:33,200 --> 00:09:37,800 And I think that if you have SOC in your planning and when you're sharing with people, 166 00:09:37,800 --> 00:09:41,120 your ideas for zero trust and your principles for zero trust, 167 00:09:41,120 --> 00:09:43,960 and you have the SOC in there as part of that sort of V team, 168 00:09:43,960 --> 00:09:48,760 then I think that's the perfect place for them to be because I think almost everything you do is zero trust. 169 00:09:48,760 --> 00:09:54,200 All of the initiatives you take, like reducing the VPN usage and least privilege and MFA, 170 00:09:54,200 --> 00:09:56,120 all has impact on the SOC. 171 00:09:56,120 --> 00:09:59,600 One of the things that was, I might be jumping ahead a little bit here, 172 00:09:59,600 --> 00:10:06,800 but I know Microsoft is looking to sort of move beyond VPN and kind of deprecate them, 173 00:10:06,800 --> 00:10:09,160 I think is one way to talk about that, 174 00:10:09,160 --> 00:10:15,560 but essentially really trying to go beyond the VPN and get remote access done in a different way. 175 00:10:15,560 --> 00:10:20,720 Can you talk a little bit about like Microsoft's efforts in there and how that works? 176 00:10:20,720 --> 00:10:24,520 Sure. So it began with the decision to do that. 177 00:10:24,520 --> 00:10:29,560 Obviously, having VPN was not any different than having somebody connect to the corporate network. 178 00:10:29,560 --> 00:10:33,160 And therefore, from a zero trust perspective, that doesn't work. 179 00:10:33,160 --> 00:10:37,560 That's still connecting you to the corporate network and assuming that the corporate network is secure. 180 00:10:37,560 --> 00:10:42,560 So what started happening was Microsoft started to deprecate the use of VPN 181 00:10:42,560 --> 00:10:46,720 by stopping devices from having the VPN automatically connect. 182 00:10:46,720 --> 00:10:49,640 I think it was automatically connecting on your device. 183 00:10:49,640 --> 00:10:53,520 As soon as you turned your device on, I think it automatically connected to the VPN for years, 184 00:10:53,520 --> 00:10:56,200 since I think I've started here. 185 00:10:56,200 --> 00:10:58,560 And they stopped doing that. 186 00:10:58,560 --> 00:11:04,320 And then I think one of the policies they decided or they took was that they were going to also deprecate, 187 00:11:04,320 --> 00:11:08,320 even like having the VPN config on a device. 188 00:11:08,320 --> 00:11:13,000 So it's sort of this step-by-step approach to try to get people used to the idea 189 00:11:13,000 --> 00:11:21,120 that they don't have to have VPN to access corporate applications or internal resources. 190 00:11:21,120 --> 00:11:24,000 It's hard for people, I think, any kind of culture shift like that. 191 00:11:24,000 --> 00:11:25,920 And Microsoft is difficult to manage. 192 00:11:25,920 --> 00:11:30,720 And I also think it's a little bit difficult for some of the application owners and the internal resources 193 00:11:30,720 --> 00:11:33,360 to realize that they aren't going to depend on VPN. 194 00:11:33,360 --> 00:11:34,720 So it's working from both sides. 195 00:11:34,720 --> 00:11:39,920 It's working on the side of let's reduce the footprint on endpoint devices. 196 00:11:39,920 --> 00:11:45,520 And then from the other side, also making sure that the resource owners are understanding 197 00:11:45,520 --> 00:11:48,400 that they shouldn't depend on VPN for connectivity anymore. 198 00:11:48,400 --> 00:11:52,560 They should be using device health as an access restriction. 199 00:11:52,560 --> 00:11:56,160 So I'm not a networking person by any stretch of anyone's imagination. 200 00:11:56,160 --> 00:11:56,640 All right. 201 00:11:56,640 --> 00:11:59,600 So VPN gives me a tunnel to the corporate resources. 202 00:11:59,600 --> 00:12:02,880 And so we're now saying you something different that's not VPN. 203 00:12:02,880 --> 00:12:06,080 So I have two questions, which probably leads to a third question. 204 00:12:06,080 --> 00:12:08,400 So the first question is, so what are we using instead? 205 00:12:09,600 --> 00:12:14,800 To which zero trust principle are we enforcing? 206 00:12:14,800 --> 00:12:17,360 Or more accurately, if you want to look at it from a negative perspective, 207 00:12:17,360 --> 00:12:22,640 what zero trust principle are VPNs violating? 208 00:12:23,440 --> 00:12:26,640 And the third question is, and this is a much broader question, 209 00:12:26,640 --> 00:12:30,240 is what does the Microsoft take on zero trust? 210 00:12:30,240 --> 00:12:34,240 I know that I read documentation from this company and that company 211 00:12:34,240 --> 00:12:35,840 and this federal organization. 212 00:12:35,840 --> 00:12:38,480 And I say, oh, they all have their own interpretation of zero trust. 213 00:12:39,040 --> 00:12:42,320 So what is our interpretation of zero trust? 214 00:12:42,960 --> 00:12:45,760 So I'm not the Microsoft zero trust expert. 215 00:12:45,760 --> 00:12:48,400 So I may or may not be able to answer your last question. 216 00:12:48,400 --> 00:12:51,120 Effectively, we have like eight blogs on it for inside track. 217 00:12:51,120 --> 00:12:54,000 So I'm absolutely happy to send links to you. 218 00:12:55,280 --> 00:12:57,040 But we are using the internet. 219 00:12:57,040 --> 00:13:01,600 So basically, instead of VPN, because VPN leads you to believe 220 00:13:01,600 --> 00:13:06,400 that if you connect to VPN, your device is managed secure, has secure access. 221 00:13:06,400 --> 00:13:10,720 And that's not the case because the corporate network is not secure. 222 00:13:10,720 --> 00:13:13,200 Because that's the sort of what zero trust is, 223 00:13:13,200 --> 00:13:14,880 is that you don't trust the corporate network. 224 00:13:14,880 --> 00:13:17,120 Because it isn't to be trusted. 225 00:13:17,120 --> 00:13:18,480 It is a soon breach. 226 00:13:18,480 --> 00:13:22,640 And so we're using the internet and making sure that devices are healthy. 227 00:13:22,640 --> 00:13:25,120 And we have MFA and we have conditional access. 228 00:13:25,120 --> 00:13:28,560 And that we have healthy devices that have Microsoft Defender for endpoint on them. 229 00:13:28,560 --> 00:13:30,960 We have healthy devices that are BitLocker encrypted. 230 00:13:30,960 --> 00:13:34,080 So it's more focused on the device itself and making sure that it is 231 00:13:34,080 --> 00:13:39,680 appropriate to join or corporate network than it is just having any device connect to VPN. 232 00:13:39,680 --> 00:13:41,280 And therefore, we assume that it's secure. 233 00:13:41,840 --> 00:13:42,720 Does that help? 234 00:13:43,360 --> 00:13:44,480 Yeah, it helps a lot. 235 00:13:44,480 --> 00:13:46,240 Yeah, because I think it's always important to sort of, 236 00:13:46,960 --> 00:13:49,280 you know, make a statement about something, you know, 237 00:13:49,280 --> 00:13:55,600 sort of hark back to the actual policy or belief that's being violated or enforced. 238 00:13:56,400 --> 00:13:57,920 Mark, do you have an opinion? 239 00:13:57,920 --> 00:13:58,960 Of course you got an opinion. 240 00:13:58,960 --> 00:14:00,560 Yeah, I've always got an opinion. 241 00:14:02,560 --> 00:14:06,240 One of the things that I've learned is that there's been sort of an implicit, 242 00:14:06,240 --> 00:14:08,720 you know, kind of slightly to your point, Michael, 243 00:14:08,720 --> 00:14:11,520 there's been this implicit assumption in security 244 00:14:11,520 --> 00:14:15,120 that because it is on the network, therefore it is trusted, right? 245 00:14:15,120 --> 00:14:20,480 And that's been the implicit, not opinion, the implicit assumption 246 00:14:20,480 --> 00:14:24,720 that's been shattered by attackers and is now being recognized with the assumed breach 247 00:14:24,720 --> 00:14:26,240 or assumed compromise mindset. 248 00:14:27,040 --> 00:14:31,840 And, you know, we used to use network access, or you're on the network as a proxy for, 249 00:14:31,840 --> 00:14:33,440 you know, you're a trusted managed device. 250 00:14:34,080 --> 00:14:38,240 And so it's really sort of the recognition that we've had this hidden assumption 251 00:14:38,240 --> 00:14:41,120 that is, in my opinion, the foundation of zero trust, 252 00:14:41,120 --> 00:14:44,400 and it's setting us back to square one is like, okay, we tried a shortcut 253 00:14:44,400 --> 00:14:47,040 with whether we meant to or not, didn't work. 254 00:14:47,680 --> 00:14:54,000 And now how do we actually do security, assuming we can't rely on the network as this, 255 00:14:54,000 --> 00:14:58,720 you know, and all be all trust signal or, you know, 80% trust signal that we did. 256 00:14:59,760 --> 00:15:00,960 That's how I think about it. 257 00:15:00,960 --> 00:15:04,960 So, so, Kristen, you know, just kind of wrap up on that, the VPN topic. 258 00:15:04,960 --> 00:15:08,880 I wanted to kind of bring it back to the sock that we talked about at the beginning. 259 00:15:09,440 --> 00:15:16,400 You know, like, so how did this shift from VPN, you know, to all these different things? 260 00:15:16,400 --> 00:15:19,280 And I got to share my one tip before I finish the questions. 261 00:15:19,280 --> 00:15:19,840 Sorry. 262 00:15:19,840 --> 00:15:23,760 Like the one thing I learned from like Carmichael Patton and some of the others was that 263 00:15:23,760 --> 00:15:28,480 the VPN logs were actually a treasure trove to figure out what apps people are actually 264 00:15:28,480 --> 00:15:30,080 still using on the corporate network. 265 00:15:30,080 --> 00:15:33,760 And so that was a really good, you know, place to mine to figure out, okay, 266 00:15:33,760 --> 00:15:37,360 what apps are people using the most so that we can burn down the right apps in the order, 267 00:15:37,360 --> 00:15:39,120 as opposed to just some arbitrary list. 268 00:15:40,400 --> 00:15:41,280 So that's my tip. 269 00:15:41,280 --> 00:15:42,160 That's my value add. 270 00:15:42,160 --> 00:15:43,120 Let me show you, I get that right. 271 00:15:43,120 --> 00:15:46,400 So what you're saying is, you know, if we've got, say, three internal apps, 272 00:15:46,400 --> 00:15:48,880 and obviously they're gonna have a lot more than that, but let's just humor me. 273 00:15:49,440 --> 00:15:52,160 And you see hits on A and B, but nothing on C. 274 00:15:53,120 --> 00:15:55,200 You know, C is not being used, right? 275 00:15:55,200 --> 00:15:57,280 You know, it's not being used because it's not being hit. 276 00:15:57,280 --> 00:15:58,400 You're not seeing the network traffic. 277 00:15:58,400 --> 00:15:59,680 Is that kind of what you're saying? 278 00:15:59,680 --> 00:16:00,960 Yeah, there's two sides to that. 279 00:16:00,960 --> 00:16:05,520 One is that we know C isn't being used or it's not being used by people that are working from home, 280 00:16:05,520 --> 00:16:08,160 which, you know, for a period was just about everybody. 281 00:16:08,800 --> 00:16:13,840 But it was also telling us that A and B are the ones we should work on publishing or modernizing 282 00:16:13,840 --> 00:16:16,960 or, you know, upgrading to the cloud or what have you. 283 00:16:16,960 --> 00:16:21,040 And by modernizing, you mean that it doesn't need VPN anymore, just to be clear. 284 00:16:21,040 --> 00:16:21,280 Yeah. 285 00:16:21,280 --> 00:16:25,760 And it may be, hey, we're going to replace that with a SaaS application because there's a better one, 286 00:16:25,760 --> 00:16:26,000 right? 287 00:16:26,000 --> 00:16:28,560 And we know that's the top of the list because it's the most used thing. 288 00:16:28,560 --> 00:16:30,720 And so we should bump up the priority of it. 289 00:16:30,720 --> 00:16:33,680 Maybe that's the one we should publish through the Azure AD app proxy. 290 00:16:33,680 --> 00:16:37,680 But whatever our modernization plan is of which there's six or eight different options, 291 00:16:38,160 --> 00:16:41,600 you know, what people are using the VPN for. 292 00:16:41,600 --> 00:16:44,880 If you're trying to get rid of the VPN, you go after your biggest hitters first 293 00:16:44,880 --> 00:16:47,200 and you deal with the ones that people are using. 294 00:16:47,200 --> 00:16:49,680 And so people are dependent on it less and less and less. 295 00:16:50,400 --> 00:16:50,960 Make sense? 296 00:16:51,840 --> 00:16:53,280 I guess that was a question for me. 297 00:16:53,840 --> 00:16:54,240 Yes. 298 00:16:54,240 --> 00:16:54,960 Yes. 299 00:16:58,960 --> 00:16:59,200 Okay. 300 00:16:59,200 --> 00:17:02,320 So let me finish my original question before I completely lose my train of thought. 301 00:17:03,600 --> 00:17:08,320 So as all these things are happening and the apps are moving and people are starting to use 302 00:17:08,320 --> 00:17:13,280 the VPN less and all this kind of stuff, like how did that impact, you know, 303 00:17:13,280 --> 00:17:18,080 the visibility and the detections and the response processes in the SOC? 304 00:17:19,680 --> 00:17:20,480 I'm curious about that. 305 00:17:20,480 --> 00:17:27,120 So, and this is one of the reasons to take your SOC on the journey along with you. 306 00:17:28,240 --> 00:17:37,920 So a lot of these deprecation goals or deprecation schedules perhaps didn't necessarily make it 307 00:17:38,400 --> 00:17:41,120 to the entire SOC for them to understand what was happening. 308 00:17:41,120 --> 00:17:44,880 And so even the, hey, we're going to deprecate the VPN. 309 00:17:44,880 --> 00:17:50,160 Like when you go and look for attacker activity, you can look in the VPN logs, 310 00:17:50,160 --> 00:17:51,520 but that is not the whole story. 311 00:17:51,520 --> 00:17:56,480 And I think that having someone who is joining those two thoughts, right? 312 00:17:56,480 --> 00:17:57,360 Like I see what's happening. 313 00:17:57,360 --> 00:17:58,640 I see we're deprecating VPN. 314 00:17:58,640 --> 00:18:03,760 I see we're making people have healthy devices before they access these resources. 315 00:18:03,760 --> 00:18:05,440 Now you need to look at this other telemetry. 316 00:18:05,440 --> 00:18:09,440 Now you need to look at app telemetry perhaps, or you need to look at the, 317 00:18:10,480 --> 00:18:13,760 you know, the network URLs that you're seeing in Microsoft Defender for Endpoint. 318 00:18:13,760 --> 00:18:15,680 And VPN is not a dependency. 319 00:18:15,680 --> 00:18:18,960 Therefore, when you go in VPN logs and you're like, I don't see anything. 320 00:18:18,960 --> 00:18:20,160 I think we're good. 321 00:18:20,160 --> 00:18:25,360 That's not necessarily true because VPN is not the dependency that people need to get to these 322 00:18:25,360 --> 00:18:26,400 resources. 323 00:18:26,400 --> 00:18:30,240 So I think just, just a larger understanding of that of like, as you transition, 324 00:18:30,240 --> 00:18:31,840 you transition your SOC with it. 325 00:18:32,640 --> 00:18:34,800 The SOC really depends on telemetry. 326 00:18:34,800 --> 00:18:37,040 Telemetry is the most important thing. 327 00:18:37,040 --> 00:18:42,320 And so I think that having someone who is continually updating what telemetry matters, 328 00:18:42,320 --> 00:18:43,520 this telemetry is getting smaller. 329 00:18:43,520 --> 00:18:47,440 This telemetry is what you need to use now when you're looking for something as opposed to these 330 00:18:47,440 --> 00:18:50,960 playbooks, because SOCs are so dependent on playbooks in a lot of ways, 331 00:18:50,960 --> 00:18:56,240 making sure somebody's updating those to be, to go along with your zero trust transition. 332 00:18:56,240 --> 00:18:56,720 Gotcha. 333 00:18:56,720 --> 00:19:01,040 So it's not just the, hey, we need to make sure we're dealing with a new perimeter and all this 334 00:19:01,040 --> 00:19:06,240 stuff, but, you know, the specific details as well that, hey, you know, we've, you know, 335 00:19:06,240 --> 00:19:10,240 as we change out the specific solutions that we've got the logs, the playbooks, etc. 336 00:19:10,240 --> 00:19:14,320 You know, changing out and following where the enterprise is going. 337 00:19:14,320 --> 00:19:14,560 Yes. 338 00:19:14,560 --> 00:19:20,160 So yeah, one of the questions I wanted to get some insight on, because I know like one of the 339 00:19:20,160 --> 00:19:24,960 big transformations, you know, for SOCs is, you know, shifting from a very network heavy, 340 00:19:24,960 --> 00:19:29,840 network focused SOC, you know, with those being the sort of the sources of data, 341 00:19:30,480 --> 00:19:32,720 into a little bit more identity driven. 342 00:19:32,720 --> 00:19:36,400 Because when you talk about SaaS apps and mobile devices accessing SaaS apps, 343 00:19:36,400 --> 00:19:38,400 there's no network intercept, right? 344 00:19:38,400 --> 00:19:41,920 It's a cloud provider and a mobile device on, you know, some 345 00:19:41,920 --> 00:19:44,240 telecos network, telephone companies network. 346 00:19:45,440 --> 00:19:51,920 You know, how, I'm curious how that shift from network to identity, you know, 347 00:19:51,920 --> 00:19:57,040 looked from the SOCs perspective, and, you know, like what kind of, you know, skills and tools 348 00:19:57,040 --> 00:19:59,840 and things you had to change to kind of keep up with that. 349 00:19:59,840 --> 00:20:04,320 I think it's, I mean, it goes along the lines, the same lines as the VPN, right? 350 00:20:04,320 --> 00:20:10,720 If the SOC doesn't know what's happening, then they can't be aware of it and they can't 351 00:20:10,720 --> 00:20:13,680 and they can't know what telemetry they need to switch to. 352 00:20:13,680 --> 00:20:18,960 And I think that, you know, like you said, like they were digging through network logs 353 00:20:18,960 --> 00:20:23,680 and they would be digging through NetFlow data and that, but instead now it's more focused on 354 00:20:23,680 --> 00:20:29,840 the endpoint detection and using the endpoint detection, using the Microsoft Cloud app security 355 00:20:29,840 --> 00:20:32,800 proxy, you know, using those types of things more. 356 00:20:32,800 --> 00:20:37,840 I think it's just a matter of someone has to be, like outside of the SOC, 357 00:20:37,840 --> 00:20:42,640 because they're not doing the analysts, you know, tasks every day, but they have to be knowledgeable 358 00:20:42,640 --> 00:20:44,720 about what changes are happening on the network. 359 00:20:44,720 --> 00:20:50,160 Like they have to be on a V team with the networking team, with the identity management team 360 00:20:50,160 --> 00:20:54,640 and see the new things that are coming out and then know how to translate that into, okay, 361 00:20:54,640 --> 00:20:58,320 well, if we're not going to see network, really network traffic is not going to be the biggest 362 00:20:58,320 --> 00:21:04,160 focus anymore, I need to be able to translate that into a SOC perspective where I need to say, 363 00:21:04,160 --> 00:21:06,960 okay, you're not going to use this anymore, you're going to use this telemetry, 364 00:21:06,960 --> 00:21:11,520 this is what this telemetry means, you need to go to AAD and you need to be digging through those 365 00:21:11,520 --> 00:21:17,360 logs and those become more important and sort of convincing or not convincing because I'm sure 366 00:21:17,360 --> 00:21:21,600 they'll be convinced, but, you know, teaching the SOC that that's the new place they need to look, 367 00:21:21,600 --> 00:21:26,880 because especially at Microsoft, when we are cloud first, we're always going first into everything 368 00:21:26,880 --> 00:21:33,360 where Windows 11 first, you know, and on our own endpoints, it's somebody has to be on top of that 369 00:21:33,360 --> 00:21:37,680 at all times to make sure that people, the SOC knows where the telemetry is. So to your point, 370 00:21:37,680 --> 00:21:43,600 it's really about having someone in the middle saying, hey, everybody, these changes are coming, 371 00:21:43,600 --> 00:21:48,400 having awareness of the changes that are coming, being sure that you know that and you're well 372 00:21:48,400 --> 00:21:54,480 informed and then translating that into SOC capabilities, SOC playbooks and SOC telemetry, 373 00:21:55,360 --> 00:22:00,400 I think it's just really pivotal. And I assume there's like training and readiness as well, 374 00:22:00,400 --> 00:22:04,400 because if folks are, you know, familiar with networking and they're not familiar with like 375 00:22:04,400 --> 00:22:09,840 the terminology and the architecture and the flows for authentication, they probably need to have 376 00:22:09,840 --> 00:22:18,000 some training and whatnot, right? Yes, when I was a SOC architect, I would set up training sessions, 377 00:22:18,000 --> 00:22:24,640 maybe every two weeks, to make sure that we were covering some of these different capabilities and 378 00:22:24,640 --> 00:22:28,800 scenarios and what is conditional access even and how do you use it and what does it actually mean 379 00:22:28,800 --> 00:22:34,400 for the user? And I think we try as much as we can, but to your point, you're 100% accurate, 380 00:22:34,400 --> 00:22:40,320 is that there are things that people have known forever. They came into the SOC with this knowledge 381 00:22:40,320 --> 00:22:45,360 and you're right. I mean, if you're not giving them training sessions, if you're not updating 382 00:22:45,360 --> 00:22:49,840 their knowledge, then yes, they will still be thinking kind of the old school mentality and it 383 00:22:49,840 --> 00:22:55,040 gets very difficult to look for threats when you're thinking about the old ways of doing things. 384 00:22:55,040 --> 00:22:59,600 Hey, so you brought up something really interesting there. You said, when I was a security architect, 385 00:22:59,600 --> 00:23:04,800 sorry, SOC architect, so a couple of questions. One, what does that mean? I mean, what is that? 386 00:23:04,800 --> 00:23:08,720 What was it? What is a day in the life of a SOC architect look like? That's number one. 387 00:23:09,280 --> 00:23:17,520 And number two, how does zero trust ideas change what a SOC architect needs to consider on a daily 388 00:23:17,520 --> 00:23:22,400 basis? So a SOC architect, I call myself that. I'm actually not even sure what my job was, but 389 00:23:22,400 --> 00:23:32,080 it was four years of originally the job was making sure that the SOC feedback to our product teams 390 00:23:32,080 --> 00:23:38,160 was delivered appropriately. So like for customers, we have the CXE team, the customer engagement team, 391 00:23:38,720 --> 00:23:45,520 who gives great feedback on how different customers are using our products. I did that for the SOC. 392 00:23:45,520 --> 00:23:52,880 So basically, it was just making sure that every time that they came up with a new piece of software, 393 00:23:52,880 --> 00:23:57,200 even at the beginning of Microsoft Defender for Endpoint, when it was just starting out, 394 00:23:57,200 --> 00:24:02,800 then putting it on devices and making sure that the right feedback was given to the product teams. 395 00:24:02,800 --> 00:24:09,520 And then it sort of grew from there into, okay, what data does the SOC need? What data sets do 396 00:24:09,520 --> 00:24:15,120 they need? What telemetry are we missing? In this last incident that occurred somewhere and we were 397 00:24:15,120 --> 00:24:20,800 looking for IOCs on our network, like where could we find them or where couldn't we look for them? 398 00:24:20,800 --> 00:24:27,280 And getting more telemetry. And then it kind of grew into being that person that is sort of the 399 00:24:27,280 --> 00:24:31,520 in-between between things we're rolling out on the network and things that the SOC needs to know about. 400 00:24:32,080 --> 00:24:38,640 And so I tried to be that person as well. So it was kind of whatever the SOC needed as a job 401 00:24:38,640 --> 00:24:44,640 was my job is the answer. I'm not sure what it is at a different company, but that's what I had to do. 402 00:24:44,640 --> 00:24:49,200 Architect is actually a really good name for that. Architects tend to be gap sellers. 403 00:24:49,200 --> 00:24:56,480 Yes, exactly. And your second question was how do the Zero Trust sort of ideas affect the SOC? 404 00:24:56,480 --> 00:25:01,920 Just overall. So I think we covered VPN, but I think things like network segmentation can be 405 00:25:01,920 --> 00:25:07,680 absolutely critical for the SOC. If you are in the SOC and you are looking for something with 406 00:25:07,680 --> 00:25:13,120 indicators or an attacker and you don't know that there's network segmentation between two spaces 407 00:25:13,120 --> 00:25:18,240 on your network and you think that an attacker could move from one network segment to the other 408 00:25:18,240 --> 00:25:21,920 because you don't know it's segmented. You think it's flat and you think everything's connected, 409 00:25:21,920 --> 00:25:25,440 then that is really difficult. You might go down a rabbit hole that you didn't need to go down. 410 00:25:25,440 --> 00:25:30,640 You did not need to do all this investigation into something where there is network segmentation 411 00:25:30,640 --> 00:25:34,800 and so there is no connectivity and the attacker would not be able to get there. 412 00:25:34,800 --> 00:25:42,640 So it's about a lot of times saving time as well. I think in a conditional access way as well, 413 00:25:42,640 --> 00:25:48,080 sometimes devices don't have access to resources if they're unhealthy, but making sure that your 414 00:25:48,080 --> 00:25:53,360 SOC has really, really good telemetry on what is healthy and what is not. A lot of times you'll 415 00:25:53,360 --> 00:25:59,360 look in Azure AD and it will say that something is connected, but if you use Intune as well, 416 00:25:59,360 --> 00:26:05,200 then it isn't actually connected because AD will tell you that and it's true from an AD perspective, 417 00:26:05,200 --> 00:26:09,680 but Intune obviously manages your devices. So I think that making sure that it's super, 418 00:26:09,680 --> 00:26:15,200 super clear to the SOC that yes, this has access, no, this doesn't have access because it is completely 419 00:26:15,200 --> 00:26:22,000 pivotal to a risk assessment and to any kind of investigation knowing what the attacker has access 420 00:26:22,000 --> 00:26:28,000 to or does not. Michael, did that answer your question? It actually really has. This is an area 421 00:26:28,000 --> 00:26:33,040 I don't really spend a lot of time on and I know that Mark does. So this is actually really useful 422 00:26:33,040 --> 00:26:37,920 for me, incredibly useful. I've learned a lot so far. So yeah, that really did answer my question. 423 00:26:37,920 --> 00:26:38,480 I'm so glad. 424 00:26:39,040 --> 00:26:44,320 One thing I want to just ask and kind of, I think it's probably a confirmation thing, but my 425 00:26:44,320 --> 00:26:50,240 understanding, especially based on your last comments there, is pretty much a SOC is always, 426 00:26:50,240 --> 00:26:59,120 I think of that quote from the matrix that, hey, time is always against us, right? Because 427 00:26:59,120 --> 00:27:02,720 there's always more work, more things you could investigate than you possibly could. 428 00:27:03,280 --> 00:27:07,120 And so you're constantly triaging. You're constantly prioritizing. You're constantly 429 00:27:07,120 --> 00:27:12,880 trying to say, do I need to continue this thread or do I need to drop it and move to the next thing? 430 00:27:12,880 --> 00:27:18,800 I mean, is that a good description of kind of the day-to-day within the SOC? 431 00:27:18,800 --> 00:27:26,400 Yes, that is 100% accurate. And we just simply do not have time to spend cycles on things that 432 00:27:26,400 --> 00:27:32,560 are not as risky as others. And so prioritization is probably the most important thing when you get 433 00:27:32,560 --> 00:27:39,760 to the point of triaging alerts and events. So yes, that is accurate. So having this understanding of 434 00:27:40,480 --> 00:27:46,240 what attacker can go where, what account works where, if this account had multi-factor or didn't, 435 00:27:46,240 --> 00:27:51,120 or this account had access to a resource or didn't is super, super crucial to be able to 436 00:27:51,120 --> 00:27:55,680 prioritize those alerts, to be able to make sure that you're working on the highest priority alerts. 437 00:27:55,680 --> 00:28:00,080 Yeah, because waste is your enemy because waste keeps you away from the mission, basically. 438 00:28:00,800 --> 00:28:06,880 Yes. And you always have to watch for burnout of the SOC. I think when the SOC gets frustrated, 439 00:28:06,880 --> 00:28:10,720 because, oh, I didn't even have to look at that because it's not even connected and they didn't 440 00:28:10,720 --> 00:28:15,920 know it's a frustration. And you try to keep your SOC from feeling that frustration because 441 00:28:15,920 --> 00:28:20,800 burnout is always sort of just something that you really have to worry about for SOC analysts, 442 00:28:20,800 --> 00:28:25,280 because they just have so much volume of learning, especially at an enormous company like Microsoft. 443 00:28:26,000 --> 00:28:29,920 It's really, really important to make sure that they're looking at very, very high fidelity, 444 00:28:30,480 --> 00:28:36,720 critical alerts. Yeah, I think the rule of thumb that I heard from our SOC director that has since 445 00:28:36,720 --> 00:28:43,840 retired was 90% true positive is what we target for our inbound tier one, I think it was, 446 00:28:43,840 --> 00:28:48,560 was alerts that if it doesn't have a track record of being 90% true positive, it's probably not 447 00:28:48,560 --> 00:28:55,120 going to get on their metrics and pop in their queue. Is that still true or? 448 00:28:55,120 --> 00:29:05,120 Yes, we try our best to do that as you can imagine having really good methodology for your fidelity 449 00:29:05,120 --> 00:29:10,960 calculations, having really good sort of proof of fidelity calculations, because as you can imagine, 450 00:29:10,960 --> 00:29:16,640 if something happens and something isn't on boarded because of fidelity reasons, you need to be able 451 00:29:16,640 --> 00:29:21,920 to prove why it's not on boarded for fidelity reasons. So making sure that that is documented 452 00:29:21,920 --> 00:29:27,440 excessively and revisited a lot too. It may not have great fidelity today, but it may have great 453 00:29:27,440 --> 00:29:31,600 fidelity in a month. And so making sure that that's something you revisit as well is really important. 454 00:29:32,240 --> 00:29:36,000 Yeah, because I mean, it's the attacker's job to essentially break you on that because the 455 00:29:36,000 --> 00:29:40,560 attacker wants to avoid your detections and they don't want to be reliably detected. And so you're 456 00:29:40,560 --> 00:29:45,360 pretty much like wrestling with them every day. Yes, it's fun, but it's challenging. 457 00:29:46,560 --> 00:29:52,880 So, Kristen, we've talked a lot about different challenges, different issues. How do you think 458 00:29:52,880 --> 00:29:59,600 about preventing these things? Are we looking at change management or other sort of process things? 459 00:30:01,520 --> 00:30:04,880 How do you think about sort of heading off some of these if I'm in a 460 00:30:04,880 --> 00:30:09,920 sort of average organizational sock that's sort of working their way through the maturity curve 461 00:30:09,920 --> 00:30:14,480 and trying to get better at what they're doing, shifting tools, etc? Like, what were some of 462 00:30:14,480 --> 00:30:18,880 the lessons learned that you'd share there? I think one thing that Microsoft does that I really 463 00:30:18,880 --> 00:30:25,760 appreciate to try to keep things from happening like if the deprecation of VPN and making sure that 464 00:30:25,760 --> 00:30:29,280 everybody, not stopping that from happening, but making sure that everybody is on board with that. 465 00:30:29,840 --> 00:30:37,360 One thing we do is it's called Client Cab and it's basically an advisory board that takes every 466 00:30:37,360 --> 00:30:41,520 anything that anybody wants to roll out on the corporate network is supposed to go through that 467 00:30:41,520 --> 00:30:48,080 advisory board. And so people are supposed to come and they're supposed to create an ADO item 468 00:30:48,080 --> 00:30:52,720 and give all the risk analysis of it and say, this is what I want to roll out. This is what we're 469 00:30:52,720 --> 00:30:57,600 doing. This is why we're doing it. Come and give an analysis of what actions they want to take. 470 00:30:57,600 --> 00:31:02,480 For instance, network segmentation or the VPN deprecation or conditional access policies, 471 00:31:02,480 --> 00:31:07,360 additional access policies, anything that affects users and making sure that not only is the sock 472 00:31:07,360 --> 00:31:10,800 on board with that and they really have a vote in, hey, we can't do that this week. 473 00:31:10,800 --> 00:31:15,200 We're completely overwhelmed with something. Can you push it to next week? But also, honestly, 474 00:31:15,200 --> 00:31:19,680 I haven't really talked much about the help desk, but I think in a lot of ways the help desk is left 475 00:31:19,680 --> 00:31:24,640 behind as well. Your help desk is the first place when people, when anything is broken, 476 00:31:24,640 --> 00:31:28,960 when people can't do anything, when you're deprecating VPN and people are like, I can't get 477 00:31:28,960 --> 00:31:33,520 my VPN to work. I don't understand what's happening. Help desk is the first line of people that's 478 00:31:33,520 --> 00:31:38,000 going to hear that. So I think definitely making sure that all of those teams are involved and have 479 00:31:38,000 --> 00:31:44,000 a vote and are informed just to involve as many people as possible to make sure that everybody 480 00:31:44,000 --> 00:31:49,120 is not only on board, which they totally should be, but are well informed and aware of what's 481 00:31:49,120 --> 00:31:53,120 happening and then can give you feedback on, hey, we've seen 10 tickets for this this week. 482 00:31:54,080 --> 00:31:58,880 Help us make this better for users. This needs to be a better experience before we roll it out 483 00:31:58,880 --> 00:32:02,960 further. So that's just really important. And I just wanted to highlight the help desk too, 484 00:32:02,960 --> 00:32:09,120 because I think the help desk takes a bulk of the work when a lot of these things happen, 485 00:32:09,120 --> 00:32:12,560 much like the SOC does. And I just want to support them as much as I can. 486 00:32:13,360 --> 00:32:18,480 And you said ADO. I assume you mean Azure DevOps, kind of the way we track changes. 487 00:32:18,480 --> 00:32:20,000 Okay. Yes. Thank you for clarifying. 488 00:32:20,720 --> 00:32:26,000 So I'm going to have to ask the question because obviously this was the question I would ask, 489 00:32:26,000 --> 00:32:34,160 but tell us about Sentinel and how that's been used in the Microsoft SOC and how that relates 490 00:32:34,160 --> 00:32:37,120 to everything we've already talked about. You knew I had to bring it in. 491 00:32:37,760 --> 00:32:41,280 Sentinel is great. Obviously, we made our transition. We have another blog that I can 492 00:32:41,280 --> 00:32:46,400 give you the link to, Michael, to post. We have a blog about how we moved from ArcSight to Sentinel. 493 00:32:46,960 --> 00:32:52,000 And we did that in July. It was the final kind of changeover. We ran them side by side and then 494 00:32:52,000 --> 00:32:58,080 we moved over completely to Sentinel. It's been incredibly useful for us, especially in the telemetry 495 00:32:58,080 --> 00:33:03,520 aspect of being able to have those connectors that will directly connect a lot of our raw data 496 00:33:03,520 --> 00:33:08,880 from our products into Sentinel and being able to query them all together and write detections 497 00:33:08,880 --> 00:33:14,880 on top of them all together in one spot has been really, really helpful for our team. It's made the 498 00:33:14,880 --> 00:33:20,000 SOC much more efficient, being able to come up with a detection that they want to onboard and 499 00:33:20,000 --> 00:33:23,760 then having all of the data there for the engineering team to be able to write that detection. 500 00:33:24,560 --> 00:33:30,720 So I think it's really been changed a lot of methodology we've used and made us faster 501 00:33:30,720 --> 00:33:36,880 and made us better at writing detections. And in the blog, you'll see how much data we ingest, 502 00:33:36,880 --> 00:33:42,800 which is an extraordinary amount of data and how efficient and effective Sentinel is at ingesting 503 00:33:42,800 --> 00:33:47,520 that and providing it for the SOC in almost real time for them to be able to query. So it's been 504 00:33:47,520 --> 00:33:52,240 really great for us. I'm sure there'll be another blog on the transition, but May Lau, 505 00:33:52,240 --> 00:33:56,480 one of my co-workers did an amazing job on that. So I'll absolutely send that link and it's been 506 00:33:56,480 --> 00:34:01,440 really great for us. So we really appreciate the tool and are looking forward to using even more in 507 00:34:01,440 --> 00:34:07,440 the future with risk IQ integration and any other acquisitions we make. It's great. Every time we 508 00:34:07,440 --> 00:34:11,040 add something to it, it's fantastic. This has been really useful for me and Linda. Linda, 509 00:34:11,040 --> 00:34:15,360 great deal. I have no doubt that everything that you do will have an impact on my day-to-day work 510 00:34:15,360 --> 00:34:23,840 there, right? Yes. You will be both a victim and a beneficiary of the Zero Trust rollout, Michael, 511 00:34:23,840 --> 00:34:28,160 but you will see changes on your devices, but all for the better. It'll make us all more secure. 512 00:34:29,520 --> 00:34:34,880 So it's very exciting because we all want better security on the corporate network and we want to 513 00:34:34,880 --> 00:34:40,080 be able to sort of be the leaders in this space. So we do it and then other customers do it when 514 00:34:40,080 --> 00:34:45,120 we show them how successful it is. So one thing we always ask our guests is, if you had one final 515 00:34:45,120 --> 00:34:50,880 thought to leave our listeners with, what would it be? Zero Trust is really, really important for 516 00:34:50,880 --> 00:34:56,720 all companies to try to at least aspire to in some form. Even if you can't get there all the way with 517 00:34:56,720 --> 00:35:03,760 Zero Trust immediately, taking some of these particular principles like MFA for all accounts 518 00:35:03,760 --> 00:35:09,200 and having sort of going to network segmentation, if you can, micro segmentation, and making sure 519 00:35:09,200 --> 00:35:14,720 they have really good telemetry for all of your devices and identities is really, really important, 520 00:35:14,720 --> 00:35:19,440 but just make sure that you bring all the teams along with you. Make sure that you have a V team 521 00:35:19,440 --> 00:35:24,720 of the SOC and the help desk and any network team and anyone else that has a stake in this and make 522 00:35:24,720 --> 00:35:29,840 sure that everybody is brought along and everybody is bought in so that it works the best for everybody 523 00:35:29,840 --> 00:35:33,280 and we can keep everybody secure because it's really, really important. Zero Trust is really 524 00:35:33,280 --> 00:35:36,640 important. Just make sure you bring everybody with you. Again, thank you so much for joining us, 525 00:35:36,640 --> 00:35:40,080 Sweet Kristin. Really appreciate you taking the time. I know you're busy. As I mentioned, 526 00:35:40,080 --> 00:35:45,200 I've learned a lot and I have no doubt that Sarah got to validate her use of Sentinel. 527 00:35:46,720 --> 00:35:51,200 You and Mark just basically geeked out anyway. But again, thank you so much for joining us. 528 00:35:51,200 --> 00:35:55,440 And to all our listeners out there, thank you so much for listening. Take care and we'll see you next time. 529 00:35:55,440 --> 00:36:00,960 Thanks for listening to the Azure Security Podcast. You can find show notes and other resources at 530 00:36:00,960 --> 00:36:08,000 our website azsecuritypodcast.net. If you have any questions, please find us on Twitter at 531 00:36:08,000 --> 00:36:21,840 azuresetpod. Background music is from ccmixter.com and licensed under the Creative Commons license.