1 00:00:00,000 --> 00:00:12,640 Welcome to the Azure Security Podcast where we discuss topics relating to security, privacy, 2 00:00:12,640 --> 00:00:16,520 reliability and compliance on the Microsoft Cloud Platform. 3 00:00:16,520 --> 00:00:21,280 Hey everybody, welcome to Episode 47. 4 00:00:21,280 --> 00:00:25,880 This week we have our guest, Chris Hallam, who's here to talk to us about Microsoft Defender 5 00:00:25,880 --> 00:00:26,880 for IoT. 6 00:00:26,880 --> 00:00:29,840 Before we get to Chris, let's take a lap around the news. 7 00:00:29,840 --> 00:00:32,920 Gladys, why don't you kick things off? 8 00:00:32,920 --> 00:00:39,320 So the first thing that I wanted to talk about is the native certificate based authentication, 9 00:00:39,320 --> 00:00:45,120 the one public preview for Active Directory, and this is Azure Active Directory. 10 00:00:45,120 --> 00:00:47,600 I'm super excited about it. 11 00:00:47,600 --> 00:00:53,760 Since now customers do not need to use ADFS in order to authenticate to Azure AD, they 12 00:00:53,760 --> 00:01:00,080 can just use their X509 certificates to authenticate. 13 00:01:00,080 --> 00:01:06,240 It also enables customers to adopt a phishing-resistant authentication. 14 00:01:06,240 --> 00:01:13,000 So now they can use their certificate in conjunction with the, say, Authenticator app or some other 15 00:01:13,000 --> 00:01:20,000 application, and they can use how that phishing-resistant capability. 16 00:01:20,000 --> 00:01:26,440 There's done more work that Microsoft is doing with this Authenticator app to enable more 17 00:01:26,440 --> 00:01:33,280 enhanced capabilities or security, so stay tuned to hear more about this. 18 00:01:33,280 --> 00:01:39,560 If you want to enable the certificate-based capability, just go to Azure AD security, 19 00:01:39,560 --> 00:01:45,240 I think it's authentication method and policy, and you should be able to see the certificate-based 20 00:01:45,240 --> 00:01:47,920 authentication and enable it in there. 21 00:01:47,920 --> 00:01:53,880 There's few configurations that you will have to do, including defining the authentication 22 00:01:53,880 --> 00:01:57,720 and the username binding, but it's pretty easy. 23 00:01:57,720 --> 00:02:02,560 You could also do targeting per user base or groups. 24 00:02:02,560 --> 00:02:06,360 X509 certificates authentication is a real old school. 25 00:02:06,360 --> 00:02:08,880 I mean, it's good stuff, but it's good to see it coming back. 26 00:02:08,880 --> 00:02:14,760 I was actually, I looked after all the certificate integration with IIS back in the day, so this 27 00:02:14,760 --> 00:02:18,840 is really great to see because, again, even though I did say it was kind of old school, 28 00:02:18,840 --> 00:02:23,000 certificate-based authentication with things like smart cards, with keys and hardware is 29 00:02:23,000 --> 00:02:25,600 actually a very strong authentication mechanism. 30 00:02:25,600 --> 00:02:26,600 Definitely. 31 00:02:26,600 --> 00:02:32,640 I think it's more that customers really wanted this in order to get rid of the infrastructure, 32 00:02:32,640 --> 00:02:40,000 but I think there's work being done that is going to come up in the future that eventually 33 00:02:40,000 --> 00:02:44,640 it will remove the need of these certificates or enhance it. 34 00:02:44,640 --> 00:02:50,800 The second thing that I wanted to talk about is livecasts or webcasts that the Microsoft 35 00:02:50,800 --> 00:02:53,920 Sentinel and RISQQ teams had. 36 00:02:53,920 --> 00:03:00,560 It was part of the Microsoft security community for some of you that may know where there's 37 00:03:00,560 --> 00:03:07,760 live webcasts being presented all the time, and this particular one was called Automate 38 00:03:07,760 --> 00:03:13,920 Your Microsoft Sentinel Tree Edge Air Force with RISQ threat intelligence. 39 00:03:13,920 --> 00:03:19,640 I haven't included a link to the recording in our Azure Security podcast site as well 40 00:03:19,640 --> 00:03:22,600 as the Sentinel docs. 41 00:03:22,600 --> 00:03:28,480 In this podcast, they talk about the different type of cyber threat intelligence. 42 00:03:28,480 --> 00:03:35,560 They talk about how different threat intelligence can be used throughout Microsoft Sentinel 43 00:03:35,560 --> 00:03:41,560 in investigation, notebook, workbooks, playbooks, et cetera. 44 00:03:41,560 --> 00:03:48,360 Then the part that I was really excited about is that we're talking how to ingest further 45 00:03:48,360 --> 00:03:51,320 threat intelligence into Sentinel. 46 00:03:51,320 --> 00:03:56,600 This is very important because people need to understand that there's different type of 47 00:03:56,600 --> 00:04:00,000 threat intelligence than Microsoft uses. 48 00:04:00,000 --> 00:04:07,400 Microsoft builds or has its own threat intelligence, and the learnings are captured from all the 49 00:04:07,400 --> 00:04:09,720 Microsoft services. 50 00:04:09,720 --> 00:04:12,240 Mark has a different presentation. 51 00:04:12,240 --> 00:04:20,240 He talks about how we build this threat intelligence from over 24 terabyte of threats signals 52 00:04:20,240 --> 00:04:29,200 that we collect over all the 300 global consumer services, 980 billion emails. 53 00:04:29,200 --> 00:04:36,400 The thing about this is that this threat intelligence is used in order to enhance or enlighten the 54 00:04:36,400 --> 00:04:41,560 incidents and the information provided throughout our security services. 55 00:04:41,560 --> 00:04:50,480 But Sentinel in this case also enable another connector that allows taxi injection. 56 00:04:50,480 --> 00:04:58,080 We recently released, you may have already seen it, but we now have what was called the 57 00:04:58,080 --> 00:05:00,160 Sentinel deception solution. 58 00:05:00,160 --> 00:05:02,040 It is very cool. 59 00:05:02,040 --> 00:05:05,120 Basically it allows you to add honey tokens into Key Vault. 60 00:05:05,120 --> 00:05:08,160 So they are fake secrets in the Key Vault. 61 00:05:08,160 --> 00:05:12,920 And of course, if somebody clicked on them and tried to reveal the secret, it will give 62 00:05:12,920 --> 00:05:14,440 you an alert in Sentinel. 63 00:05:14,440 --> 00:05:18,880 So it's a way of finding out if there's anyone poking around in your environment. 64 00:05:18,880 --> 00:05:20,240 We'll have links in the show notes. 65 00:05:20,240 --> 00:05:24,600 We do have a whole video on how that deception solution works. 66 00:05:24,600 --> 00:05:26,480 So go and check it out. 67 00:05:26,480 --> 00:05:30,720 If it sounds of interest, I always love stuff like honey tokens. 68 00:05:30,720 --> 00:05:35,080 Definitely for all the things we've had in Sentinel, it's pretty different and new. 69 00:05:35,080 --> 00:05:38,200 Go and check that one out. 70 00:05:38,200 --> 00:05:43,600 On the 24th of February, we're doing our what's next in security for Microsoft Digital 71 00:05:43,600 --> 00:05:44,600 event. 72 00:05:44,600 --> 00:05:51,080 We're doing this instead of RSA because you may know that RSA has been postponed to later 73 00:05:51,080 --> 00:05:52,080 in the year. 74 00:05:52,080 --> 00:05:58,600 So definitely go check that out because there'll be some cool things being talked about and 75 00:05:58,600 --> 00:06:01,920 announced seeing as RSA has been postponed. 76 00:06:01,920 --> 00:06:05,520 Another Sentinel thing is, and this one I'm very excited about because we've been waiting 77 00:06:05,520 --> 00:06:09,840 for it for a long time, is the codeless connector for Sentinel. 78 00:06:09,840 --> 00:06:14,880 So what that means is the codeless connector platform or CCP, it allows you to create your 79 00:06:14,880 --> 00:06:17,600 own API-based connectors. 80 00:06:17,600 --> 00:06:23,280 So if Microsoft hasn't made it for you yet and a third party provider hasn't made it, 81 00:06:23,280 --> 00:06:27,600 you can actually make your own and it will appear as an inbuilt connector in Sentinel, 82 00:06:27,600 --> 00:06:32,760 which is pretty cool and something that quite a lot of people have been waiting for. 83 00:06:32,760 --> 00:06:35,800 So I'm very excited that we finally have that. 84 00:06:35,800 --> 00:06:42,280 Then on Defender for Cloud side of things, it's with calling out now that the Kubernetes 85 00:06:42,280 --> 00:06:48,840 workload protection is now available for Arc-enabled Kubernetes clusters. 86 00:06:48,840 --> 00:06:54,840 It used to just be for AKS, the Azure version of Kubernetes, but now that we will actually 87 00:06:54,840 --> 00:06:57,160 do it on anything that's Arc-enabled. 88 00:06:57,160 --> 00:07:01,880 So that gives a lot more flexibility to where you can implement this. 89 00:07:01,880 --> 00:07:07,280 Also, there's more new recommendations in preview about enabling Microsoft Defender 90 00:07:07,280 --> 00:07:12,040 plans on workspaces just again to help you with your hygiene. 91 00:07:12,040 --> 00:07:13,880 I think I will leave it there. 92 00:07:13,880 --> 00:07:17,920 A couple of things that have been top of mind for me. 93 00:07:17,920 --> 00:07:21,920 One of them is kind of a little bit of a key off of the Defender for Cloud stuff. 94 00:07:21,920 --> 00:07:28,520 One of the things that we've seen at organizations is that as all this cool goodness comes in 95 00:07:28,520 --> 00:07:33,760 from Defender for Cloud and other kind of cloud security posture management tools, organizations 96 00:07:33,760 --> 00:07:38,680 tend to get challenged with, okay, who actually uses this? 97 00:07:38,680 --> 00:07:39,680 So this is an awesome tool. 98 00:07:39,680 --> 00:07:40,680 It's great. 99 00:07:40,680 --> 00:07:44,280 I get great visibility into my posture, but who's actually doing the glass watching? 100 00:07:44,280 --> 00:07:46,160 Who's going to fix these things? 101 00:07:46,160 --> 00:07:48,120 Who's going to help the people fix it? 102 00:07:48,120 --> 00:07:52,000 The asset owners that aren't familiar with security. 103 00:07:52,000 --> 00:07:56,760 And so we're finding that a lot of organizations are kind of figuring out how to create a posture 104 00:07:56,760 --> 00:08:02,200 management team or function or discipline within their organization. 105 00:08:02,200 --> 00:08:06,520 And so that's an area that we're working on, spending a lot of time defining it and figuring 106 00:08:06,520 --> 00:08:08,040 out exactly what that means. 107 00:08:08,040 --> 00:08:12,640 And there's a link in the show notes that is kind of our first pass on that, but we're 108 00:08:12,640 --> 00:08:14,720 continuing to define it in a lot more detail. 109 00:08:14,720 --> 00:08:15,720 And what do they do? 110 00:08:15,720 --> 00:08:16,720 Who do they work with? 111 00:08:16,720 --> 00:08:18,040 What are the outcomes? 112 00:08:18,040 --> 00:08:19,040 Those kind of things. 113 00:08:19,040 --> 00:08:23,200 So that's one of the areas that I spent a lot of focus time on. 114 00:08:23,200 --> 00:08:27,840 And then I threw a few of these out on Twitter as well. 115 00:08:27,840 --> 00:08:31,680 We'll throw the link in the show notes, but we're working on a kind of maturity model. 116 00:08:31,680 --> 00:08:35,560 It's hard to call it a normal maturity model because we're taking a slightly different 117 00:08:35,560 --> 00:08:36,560 tack. 118 00:08:36,560 --> 00:08:40,880 We're not just saying, hey, what is dynamic or optimized or some other warm fuzzy word 119 00:08:40,880 --> 00:08:42,600 mean at the top of the list. 120 00:08:42,600 --> 00:08:47,880 But what is the actual journey for each of the different aspects of the CAF, the Cloud 121 00:08:47,880 --> 00:08:52,040 Adoption Framework, essentially as a security program matures? 122 00:08:52,040 --> 00:08:56,080 What are the ways that people go from sort of a compliance focus to you had your first 123 00:08:56,080 --> 00:09:01,080 incident OMG, and then you end up spending so much time in the sock. 124 00:09:01,080 --> 00:09:06,720 And then you realize, hey, we would have a lot less incidents to respond to if we actually 125 00:09:06,720 --> 00:09:10,960 patched and kind of getting into that posture management again. 126 00:09:10,960 --> 00:09:14,560 And then kind of coming to a much more balanced approach and balancing investments across 127 00:09:14,560 --> 00:09:17,280 the team and focus areas and whatnot. 128 00:09:17,280 --> 00:09:21,560 And so we're really trying to capture those journeys as we see them happen at customers 129 00:09:21,560 --> 00:09:23,560 and kind of giving some maturity model scales. 130 00:09:23,560 --> 00:09:28,880 So nothing other than those two preview ones that I threw out on Twitter, kind of on a 131 00:09:28,880 --> 00:09:31,320 whim, but we are working on that. 132 00:09:31,320 --> 00:09:33,400 We'll get it out to you all as soon as we can. 133 00:09:33,400 --> 00:09:34,400 That's all I got. 134 00:09:34,400 --> 00:09:37,160 I got a few news items. 135 00:09:37,160 --> 00:09:43,120 The first one is we actually now have a new hardware security module, another member of 136 00:09:43,120 --> 00:09:45,440 the Azure Key Vault family. 137 00:09:45,440 --> 00:09:49,160 And that is the Microsoft Azure Payment HSM service. 138 00:09:49,160 --> 00:09:53,560 This is there primarily for PCI compliance, pretty specialized. 139 00:09:53,560 --> 00:09:57,600 I can't imagine this being a replacement for Key Vault by any stretch of anyone's imagination. 140 00:09:57,600 --> 00:10:03,400 It is literally a bare metal service using TALIS Pay Shield payments, HSMs. 141 00:10:03,400 --> 00:10:04,400 Again, very specialized. 142 00:10:04,400 --> 00:10:09,960 This is not going to be a general purpose replacement for Key Vault by any stretch. 143 00:10:09,960 --> 00:10:13,280 For those people that need it and don't want to have one on-prem and they want to have 144 00:10:13,280 --> 00:10:19,080 one managed by Microsoft, then this is certainly an option that you can have inside of your 145 00:10:19,080 --> 00:10:20,520 Azure subscription. 146 00:10:20,520 --> 00:10:27,280 We also have some new training available for various exams like AZ900, which is the Microsoft 147 00:10:27,280 --> 00:10:29,400 Azure fundamentals. 148 00:10:29,400 --> 00:10:32,960 Also AZ104, which is the Microsoft Azure administrator. 149 00:10:32,960 --> 00:10:38,960 AZ204, which is certainly of big interest to me, is developing solutions for Microsoft 150 00:10:38,960 --> 00:10:39,960 Azure. 151 00:10:39,960 --> 00:10:45,480 And the last one is AZ400, which is designing and implementing Microsoft DevOps solutions. 152 00:10:45,480 --> 00:10:48,560 So there's a whole bunch of sample exams and tests that you can take. 153 00:10:48,560 --> 00:10:51,320 And again, we'll have the links to that in the show notes. 154 00:10:51,320 --> 00:10:52,880 We also have a new feature. 155 00:10:52,880 --> 00:10:54,280 It actually came out last year. 156 00:10:54,280 --> 00:10:56,240 I don't know why we missed this. 157 00:10:56,240 --> 00:10:59,360 But it's Azure Virtual Network Manager. 158 00:10:59,360 --> 00:11:04,760 Essentially allows you to manage virtual networks essentially from one pane of glass. 159 00:11:04,760 --> 00:11:08,880 Makes life significantly simpler when it comes to managing these things. 160 00:11:08,880 --> 00:11:17,880 One other note is I wrote a blog post last week about how to configure TLS 1.2 and 1.3 161 00:11:17,880 --> 00:11:18,880 in Windows VMs. 162 00:11:18,880 --> 00:11:23,960 I mean in Windows in general, but Windows VM specifically, there's a bunch of customers 163 00:11:23,960 --> 00:11:27,920 who want to use TLS 1.3 and 1.2. 164 00:11:27,920 --> 00:11:32,360 They know they can't use TLS 1.0 and 1.1 for compliance reasons. 165 00:11:32,360 --> 00:11:35,440 But sometimes they want to use TLS 1.2 and 1.3. 166 00:11:35,440 --> 00:11:39,280 Well the problem with TLS 1.2 is some of the Cypher suites are actually pretty lousy. 167 00:11:39,280 --> 00:11:40,280 So how do you configure that? 168 00:11:40,280 --> 00:11:44,320 How do you make sure that Windows is using the correct set of Cypher suites? 169 00:11:44,320 --> 00:11:48,840 So I wrote a blog post on that, which shows you how to use the PowerShell commandlets 170 00:11:48,840 --> 00:11:52,960 to actually configure the Cypher suites and also how to validate that the Cypher suites 171 00:11:52,960 --> 00:11:57,080 are correct by using open SSL as a client. 172 00:11:57,080 --> 00:12:01,880 So you can actually touch the server and see which Cypher suites the server responds with. 173 00:12:01,880 --> 00:12:04,440 So that's all the news I have this week. 174 00:12:04,440 --> 00:12:06,760 So why don't we turn our attention to our guest. 175 00:12:06,760 --> 00:12:11,480 This week we have Chris Hallam, who's here to talk to us about Microsoft Defender for 176 00:12:11,480 --> 00:12:12,480 IoT. 177 00:12:12,480 --> 00:12:18,800 I know that Mark will probably have quite a few opinions as we go through this as well. 178 00:12:18,800 --> 00:12:21,600 So Chris, thank you so much for joining us this week. 179 00:12:21,600 --> 00:12:25,800 Would you mind just spending a moment and introduce yourself to our listeners? 180 00:12:25,800 --> 00:12:27,840 Yeah, absolutely. 181 00:12:27,840 --> 00:12:29,400 I'm really excited to be on the show. 182 00:12:29,400 --> 00:12:34,240 In fact, I didn't realize what a fun crew we had here until we were in the green room 183 00:12:34,240 --> 00:12:35,720 together kind of getting prepped. 184 00:12:35,720 --> 00:12:39,960 And my old friend Mark Simos, I didn't realize you were going to be on the podcast as well. 185 00:12:39,960 --> 00:12:41,560 So Mark and I have worked for years. 186 00:12:41,560 --> 00:12:43,680 And so anyways, this is going to be a lot more fun than I realized. 187 00:12:43,680 --> 00:12:47,760 But anyway, to answer your question, again, the name is Chris Hallam. 188 00:12:47,760 --> 00:12:51,040 And I've been at Microsoft for a really long time working with Mark and many others. 189 00:12:51,040 --> 00:12:52,840 I've been here for over 20 years. 190 00:12:52,840 --> 00:12:54,840 I started my career on server management. 191 00:12:54,840 --> 00:12:56,680 I did that for about a decade. 192 00:12:56,680 --> 00:13:00,200 And then I switched over to security before it became kind of a big thing. 193 00:13:00,200 --> 00:13:05,440 I was one of the early people on Windows security as we transitioned from Windows 7 to 8, which 194 00:13:05,440 --> 00:13:09,400 is where we really transformed the platform and made security probably one of the most 195 00:13:09,400 --> 00:13:11,280 important parts of the product. 196 00:13:11,280 --> 00:13:14,720 And so anyways, it's always kind of at the tip of the spear at the beginning where there's 197 00:13:14,720 --> 00:13:15,920 really only a handful of people. 198 00:13:15,920 --> 00:13:18,000 And of course, now it's transitioned to thousands. 199 00:13:18,000 --> 00:13:20,000 I mean, I can't believe how many people are working on security. 200 00:13:20,000 --> 00:13:22,880 I think we have 3,500 people working on it now. 201 00:13:22,880 --> 00:13:27,360 And it was just a sliver of that back in the 10 years ago. 202 00:13:27,360 --> 00:13:30,480 But anyway, now I live in the product marketing area. 203 00:13:30,480 --> 00:13:35,280 And I've been focusing on end point security for the whole time. 204 00:13:35,280 --> 00:13:40,080 But more recently, I moved over to a new endpoint, which is IoT and OT devices. 205 00:13:40,080 --> 00:13:45,400 And so it gives you kind of a quick tour of my background here at Microsoft. 206 00:13:45,400 --> 00:13:50,800 So one thing we've mentioned a few times on the podcast is IoT and OT. 207 00:13:50,800 --> 00:13:54,560 Would you mind spending a moment sort of explaining the difference between the two? 208 00:13:54,560 --> 00:13:56,640 Yeah, absolutely. 209 00:13:56,640 --> 00:14:02,440 Operational technology or OT sometimes also referred to as ICS, industrial control systems, 210 00:14:02,440 --> 00:14:09,120 are small devices, sometimes larger, designed to drive basically industrial things. 211 00:14:09,120 --> 00:14:12,760 So for instance, if you have a manufacturing plant, let's say it's an automobile plant 212 00:14:12,760 --> 00:14:18,120 like Tesla as an example, that's operational technology that's definitely driving the assembly line. 213 00:14:18,120 --> 00:14:21,000 And that same type of technology is in other industries. 214 00:14:21,000 --> 00:14:27,040 Pharmaceuticals, we're talking about the production of vaccines like COVID-19, OT technology, 215 00:14:27,040 --> 00:14:29,960 ICS technology is used in that scenario. 216 00:14:29,960 --> 00:14:33,040 It's also used in scenarios that people aren't as familiar with. 217 00:14:33,040 --> 00:14:36,200 This technology is also inside the buildings that we work in. 218 00:14:36,200 --> 00:14:45,480 So elevators, any sort of building automation may also be driven by OT technologies and ICS technologies. 219 00:14:45,480 --> 00:14:51,560 If we're to contrast that versus IoT technology, which is in some respects kind of similar, 220 00:14:51,560 --> 00:14:57,720 but generally not for industrial purposes, IoT devices consist of an incredibly broad range of things. 221 00:14:57,720 --> 00:15:02,520 We all know what traditional endpoints are like workstations, servers, mobile devices, 222 00:15:02,520 --> 00:15:07,960 but pretty much everything else that's not in the OT ICS world and is not a traditional endpoint 223 00:15:07,960 --> 00:15:10,600 is probably in that IoT space. 224 00:15:10,600 --> 00:15:21,480 So internet connected printers, cameras in buildings, maybe the locks on doors, voiceover IP devices. 225 00:15:21,480 --> 00:15:25,640 There's just smart TVs that we could talk on and on and on, but that gives you kind of, I think, 226 00:15:25,640 --> 00:15:31,320 a general idea of what the IoT type of devices are. 227 00:15:31,320 --> 00:15:39,560 Can you talk a little bit about Defender for IoT, what challenges it addresses, 228 00:15:39,560 --> 00:15:48,920 how it uses the rest of our technology to interconnect to provide a wider set of signals or information? 229 00:15:48,920 --> 00:15:56,040 Definitely. So Microsoft Defender for IoT today is a product that is focused on the OT technology, 230 00:15:56,040 --> 00:16:00,120 the ICS technology, for these industrial scenarios and maybe building management. 231 00:16:00,120 --> 00:16:04,520 That's its current focus, but later this year we're going to expand its footprint to also cover 232 00:16:04,520 --> 00:16:06,680 the IoT devices we talked about a minute ago. 233 00:16:06,680 --> 00:16:11,560 So all the enterprise IoT devices, smart TVs, voiceover IP, etc. 234 00:16:11,560 --> 00:16:17,480 So it's going to be much broader, but what will it do across these different types of device types? 235 00:16:17,480 --> 00:16:19,880 There's a couple things that Defender for IoT handles. 236 00:16:20,680 --> 00:16:25,240 The first thing it does is it's going to discover all of the devices on your network, 237 00:16:26,120 --> 00:16:27,400 and it's going to classify them. 238 00:16:27,400 --> 00:16:31,720 So that's the first thing is the ability to get an asset inventory for all those devices that are 239 00:16:31,720 --> 00:16:36,280 connected to IP networks, Bluetooth, etc. So that's the first category. 240 00:16:36,280 --> 00:16:40,200 The next capability it has is once you have an understanding of what your inventory is, 241 00:16:40,200 --> 00:16:42,680 of course, we want to know its security posture. 242 00:16:42,680 --> 00:16:47,480 And so we apply vulnerability management to those devices and we come up with an assessment 243 00:16:48,120 --> 00:16:53,160 on whether those devices are patched, whether they're well configured in the most secure 244 00:16:53,160 --> 00:16:56,440 possible state. We can give you insights there, etc. 245 00:16:56,440 --> 00:16:59,880 And then, of course, we do detection and response. 246 00:16:59,880 --> 00:17:05,880 So very much like an EDR product or an endpoint detection response system for traditional endpoints 247 00:17:05,880 --> 00:17:12,280 by like workstation servers, etc. We do the same type of thing for IoT and OT devices. 248 00:17:12,280 --> 00:17:20,280 So we'll look at threat signal coming in to the system, apply ML and AI and determine whether 249 00:17:20,280 --> 00:17:25,560 these devices are safe and secure or maybe whether they're under attack. 250 00:17:25,560 --> 00:17:28,840 And then, of course, then we provide instant response capabilities. 251 00:17:28,840 --> 00:17:32,600 So with all that rich data that we're collecting about what's happening to these devices, 252 00:17:32,600 --> 00:17:38,200 we have effectively huge logs and investigation data that can help us perform automation, 253 00:17:38,200 --> 00:17:41,720 that will allow us to maybe take a device that's been compromised and maybe bring it back to a 254 00:17:41,720 --> 00:17:47,800 pre-breach state. And we can also arm the instant response analysts with the data they need to 255 00:17:47,800 --> 00:17:52,360 correct the issue. And so that kind of gives you, I think, a high level overview of what the product 256 00:17:52,360 --> 00:17:59,400 does. So one of the things that I thought was fascinating because I spent a couple of months 257 00:17:59,400 --> 00:18:06,440 working really deeply with a defender for IoT was there's obviously a lot of key security 258 00:18:06,440 --> 00:18:11,720 scenarios. The SOC analysts getting some visibility into what attacks are happening and 259 00:18:11,720 --> 00:18:15,720 you're kind of assisting with the investigation and kind of getting to ground truth and 260 00:18:15,720 --> 00:18:20,520 helping plan the remediations, etc. Look left, look right, the whole 261 00:18:20,520 --> 00:18:26,120 investigative process. But the thing that was sort of interesting and surprised me a little bit was 262 00:18:27,720 --> 00:18:33,240 the asset discovery and was actually quite valuable. And it wasn't just a security because 263 00:18:33,240 --> 00:18:36,520 obviously security were number one rule if you don't know what you have, you don't know what to 264 00:18:36,520 --> 00:18:43,160 protect and what your risk is, etc. But there was also a lot of value in it that organizations 265 00:18:43,160 --> 00:18:47,880 found for digital transformation projects like, hey, we're getting ready to do a smart factory 266 00:18:47,880 --> 00:18:55,880 or a smart this or smart that, that involved the OT aspects and there's predictive maintenance or 267 00:18:55,880 --> 00:18:59,800 some other thing or adjusting in real time, etc. All the kind of digital transformation 268 00:19:00,520 --> 00:19:07,240 goodness that happens. But we saw folks using Defender for IoT for actually discovering what 269 00:19:07,240 --> 00:19:11,880 their stuff was to kind of aid the planning of that project and figure out how many machines they 270 00:19:11,880 --> 00:19:17,080 actually had and what type and what kind of data that they could get and then kind of plan some 271 00:19:17,080 --> 00:19:21,480 business value projects from there. So I thought that that second aspect it was kind of fascinating 272 00:19:21,480 --> 00:19:27,560 it, you know, security tools actually enabling the business was kind of cool. Absolutely. In fact, 273 00:19:27,560 --> 00:19:32,920 you bring up a great point. We've talked to endless customers about what their needs are for 274 00:19:32,920 --> 00:19:37,880 Microsoft Defender for IoT. And the first thing that comes out of everybody's mouth is, I don't 275 00:19:37,880 --> 00:19:42,600 have visibility to what I've got in my environment. I literally have no clue. Some organizations 276 00:19:42,600 --> 00:19:48,280 quite literally have no clue that they don't even have a list. Some organizations have a spreadsheet 277 00:19:48,280 --> 00:19:52,200 that somebody updates from time to time. And then there's some organizations that have something, 278 00:19:52,200 --> 00:19:57,320 you know, much better. They've got a product like ours or maybe another vendors that maybe 279 00:19:57,320 --> 00:20:05,160 can automate the process of generating that list. And that's obviously crucial. And it's really 280 00:20:05,160 --> 00:20:10,680 funny that a lot of our customers tell us that that's kind of their next concern for this year, 281 00:20:10,680 --> 00:20:15,720 right? They love the idea of detection response, but so many of them don't even have visibility to 282 00:20:15,720 --> 00:20:21,720 their OT environments. That just getting visibility is kind of like their only concern. And of course, 283 00:20:21,720 --> 00:20:25,000 our product does far more than that. And they'll be delighted at that functionality when they deploy 284 00:20:25,000 --> 00:20:30,040 it. But you're so right, Mark, that the first step, if you want to digitally transform, how could 285 00:20:30,040 --> 00:20:35,560 you do that if you don't even know what you already have? And so it is our number one feature 286 00:20:35,560 --> 00:20:39,960 that our customers are asking about. And we recently worked with Ponymon and we had them do some 287 00:20:39,960 --> 00:20:45,640 research. And it also turned up statistically that the number one feature by a vast majority of 288 00:20:45,640 --> 00:20:49,480 customers is just getting that first step, which is visibility to what they have in their environments. 289 00:20:50,200 --> 00:20:55,960 There's plenty of Twitter rants on that as well from some seasoned Gray-haired folks in the security 290 00:20:55,960 --> 00:21:04,600 world. Now, I was also taking a look at the executive order on cybersecurity for critical 291 00:21:04,600 --> 00:21:11,960 infrastructure or for critical ICS systems. So I'm curious, you know, your take on that and 292 00:21:11,960 --> 00:21:18,520 your comments on it. Yeah, the executive order is something that's really great for our industry, 293 00:21:18,520 --> 00:21:24,760 because I kind of mentioned a moment ago, a lot of our customers aren't doing anything yet. Like, 294 00:21:24,760 --> 00:21:28,680 50% of the customers we talk to do not have a solution like Microsoft Defender for IoT 295 00:21:29,400 --> 00:21:34,040 or third party equivalent to get the visibility and the detection response. So they're literally 296 00:21:34,040 --> 00:21:41,480 segmenting their networks away and kind of hoping that through network segmentation and maybe air 297 00:21:41,480 --> 00:21:46,760 gapping, which oftentimes is really not happening, that these devices are tucked away and are going 298 00:21:46,760 --> 00:21:51,480 to be secure. And of course, we're finding out that that's not true, as we've seen in the news. 299 00:21:51,480 --> 00:21:57,160 So the executive order, I think, is a little bit of a shot across the bow to get some of these 300 00:21:57,160 --> 00:22:02,840 late adopters to kind of wake up and say, look, you know, the second network segmentation is not 301 00:22:02,840 --> 00:22:07,960 going to work. We, you know, our environments are not disconnected like they are. We've got an OT, 302 00:22:07,960 --> 00:22:12,520 IT convergence program that's bringing these networks closer together. So anyway, I think 303 00:22:12,520 --> 00:22:17,640 the executive order is great. And I just want to actually drill into a little bit more. Something 304 00:22:17,640 --> 00:22:22,120 that I really liked about it is if I'll just read from it says the primary objective of this 305 00:22:22,120 --> 00:22:25,880 initiative is defend United States critical infrastructure by encouraging and facilitating 306 00:22:25,880 --> 00:22:30,200 the deployment of technologies and systems that provide threat visibility, indications, 307 00:22:30,200 --> 00:22:35,640 detections and warnings, and that facilitate response capabilities for cybersecurity in 308 00:22:35,640 --> 00:22:40,840 essential control systems and operational technology networks. That is exactly what Microsoft 309 00:22:40,840 --> 00:22:47,080 Defender does. We recover all of those bases, which is wonderful. So customers who see this 310 00:22:47,880 --> 00:22:53,000 own critical infrastructure and are looking for a solution, this is something that we've got a 311 00:22:53,000 --> 00:22:58,440 solution that covers all of these bases the executive order covers. Another thing that it mentioned 312 00:22:58,440 --> 00:23:03,160 that is interesting is the federal government will work with industry to share threat information 313 00:23:03,160 --> 00:23:08,840 for priority control. And it kind of goes on and on. But the net net of that is what we're going 314 00:23:08,840 --> 00:23:14,360 to get is we're actually going to get a private public sector collaboration that's going to probably 315 00:23:14,360 --> 00:23:18,760 enable us to innovate more. The government's basically saying here in the executive order 316 00:23:18,760 --> 00:23:23,560 that they're going to share threat information to us. And as Gladys mentioned earlier, 317 00:23:23,560 --> 00:23:29,000 we've got trillions of threat signals we're looking at a day. And it's wonderful. And we 318 00:23:29,000 --> 00:23:33,080 arguably have more threat data than anyone in the world, at least in the domains we're talking about 319 00:23:33,080 --> 00:23:39,720 here. But with this additional information that we can get from government, this is going to make it 320 00:23:40,360 --> 00:23:46,040 so all the vendors in our space can further innovate and protect our customers better than we have 321 00:23:46,040 --> 00:23:51,400 without that type of relationship. And so that's a wonderful news as well. The last thing that's 322 00:23:51,400 --> 00:23:57,400 great is the Homeland Security is going to coordinate with other agencies and they're going to come up 323 00:23:57,960 --> 00:24:03,640 with performance goals for critical infrastructure. So they're going to create a plan and they're 324 00:24:03,640 --> 00:24:08,440 going to give that to everybody who's in that type of situation, critical infrastructure that is. 325 00:24:09,000 --> 00:24:15,800 And that will become some KPIs that they can manage towards. And one thing that's not so great 326 00:24:15,800 --> 00:24:20,600 about the exact order is it says that these organizations should follow. And so that's where 327 00:24:20,600 --> 00:24:24,040 I think the exact order maybe could have been stronger. I would have liked to have seen stronger 328 00:24:24,040 --> 00:24:29,480 language that really pushed people more in the direction of must doing rather than should doing. 329 00:24:29,480 --> 00:24:33,880 So, but anyway, this is great news from the federal government here in the US 330 00:24:34,520 --> 00:24:38,520 to advance our interests as well as our customers, which of course is why we're the whole point of 331 00:24:38,520 --> 00:24:45,560 all this. So one of the things I'd like to get your take on the colonial pipeline and the ransomware 332 00:24:45,560 --> 00:24:51,080 aspect of it or extortion attacks because that's one of my pet peeves, but I'll try not to rant 333 00:24:51,720 --> 00:24:57,800 during the question here. I'd love to get your take on kind of how you view that and how you 334 00:24:57,800 --> 00:25:02,200 think about that. Yeah, ransomware has been a thing that we've been talking about forever. 335 00:25:02,840 --> 00:25:08,360 We've talked about it in the context of our personal data or maybe business data. So we've 336 00:25:08,360 --> 00:25:14,520 thought of it, I think, for a really long time in the context of IT problem. And of course, 337 00:25:14,520 --> 00:25:22,200 when these what was it, WannaCry came out and not Petya came out, right? Those were terrible 338 00:25:22,200 --> 00:25:28,440 ransomware scenarios that really were primarily addressing the or attacking IT things. Now, 339 00:25:29,000 --> 00:25:32,920 there was some OT related impact, right? Because when like for instance, 340 00:25:32,920 --> 00:25:37,720 Merisk that really hobbled their ability to do shipping because their IT network was basically 341 00:25:37,720 --> 00:25:42,600 shut down. And so that kind of prevented a lot of the shipping that they'd like to have done 342 00:25:42,600 --> 00:25:49,720 to get stopped. But at any rate, what we saw with Colonial Pipeline, I think is just another 343 00:25:49,720 --> 00:25:54,840 example I mentioned shot across the bow. Well, there's a really big one. Now organizations 344 00:25:54,840 --> 00:26:02,680 are using ransomware to stop critical infrastructure. And it's costing the organization millions of 345 00:26:02,680 --> 00:26:08,200 dollars a day over the course of weeks potentially. So it's very, very expensive. 346 00:26:08,200 --> 00:26:13,960 And it's so critical for the function of our nation and others who like it who are experienced 347 00:26:13,960 --> 00:26:21,720 this type of attack. And so, I remember years ago, the FBI was saying, oh, don't ever pay the ransom. 348 00:26:23,880 --> 00:26:29,640 That's a really hard thing to not do when a pipeline is shut down because of ransomware. 349 00:26:30,600 --> 00:26:35,480 And so I don't know all the specifics of what they did there. I understand the ransom was paid. 350 00:26:35,480 --> 00:26:39,800 And then it was later seized by the government. But I'm not going to assume that that's going 351 00:26:39,800 --> 00:26:45,160 to play out that way every single time. So at any rate, I think what you see is the 352 00:26:45,160 --> 00:26:48,440 threat actors out there are now seeing that critical infrastructure 353 00:26:49,400 --> 00:26:55,320 creates and attacking it creates a very dire situation where the likelihood of a very handsome 354 00:26:55,320 --> 00:27:01,800 profit or payout is going to happen. And so I expect that we're going to see a lot more of this. 355 00:27:01,800 --> 00:27:05,240 And of course, that's why the executive order came out. I think I remember how 356 00:27:05,240 --> 00:27:09,000 long it was. I think it might have been a week later that executive order came out after the 357 00:27:09,000 --> 00:27:13,160 colonial pipeline. And Mark, correct me if I'm wrong there, but they were in close proximity 358 00:27:13,160 --> 00:27:17,320 for sure. So we're going to see a lot more of this. The extortion is going to get greater 359 00:27:18,040 --> 00:27:23,640 and the disruption to people in an entire region potentially is going to get greater as well. 360 00:27:23,640 --> 00:27:25,160 So we're going to see a lot more of this to come. 361 00:27:25,800 --> 00:27:32,040 The two rants that I have in this space are, as much as ransomware is a huge part of it, 362 00:27:32,040 --> 00:27:36,760 fundamentally, these are extortion attacks. And we've seen all sorts of other ways of making 363 00:27:36,760 --> 00:27:41,320 money other than, hey, pay me for the data that we see them resell the data. We see them do other 364 00:27:41,320 --> 00:27:47,800 kinds of extortion as well, even extorting the customers of some organizations. So I always 365 00:27:47,800 --> 00:27:51,480 try to make sure that we're broadening. Whenever I hear ransomware, I want to make sure people 366 00:27:51,480 --> 00:27:55,160 think ransomware and just extortion in general threaten bad things. 367 00:27:55,160 --> 00:27:58,280 And then the other thing, and it kind of ties into the payment thing. And 368 00:27:58,280 --> 00:28:05,080 you know, absolutely, you definitely don't want to pay the ransom. I mean, that's like your last 369 00:28:05,080 --> 00:28:13,240 ditch, sort of like the choice of last resort, effectively. And like the one thing that I worry 370 00:28:13,240 --> 00:28:17,560 a little bit about, as I've seen, especially sort of business folks that aren't familiar with security 371 00:28:17,560 --> 00:28:24,040 and sort of the ongoing risk and the nature of these kind of things, is we started to see some 372 00:28:24,040 --> 00:28:27,880 business leaders essentially planning to pay the ransom. Like, I'm not going to invest in security, 373 00:28:27,880 --> 00:28:33,960 I'll just pay the ransom, move on. And it's like, no, this isn't quite like paying a kidnapping and 374 00:28:33,960 --> 00:28:38,600 you know, fee if you know, some ship that gets captured off the coast of Africa or something 375 00:28:38,600 --> 00:28:43,080 like that. There's actually a lot of damage to your organization and your operations can be 376 00:28:43,080 --> 00:28:48,600 completely stopped for a period of days, if not weeks or months. And so, you know, the big thing 377 00:28:49,560 --> 00:28:53,320 that we want to make sure that people get the message of is you never plan to pay the ransom. 378 00:28:53,320 --> 00:28:59,320 Yes, you may have to and you may prepare in case you need to, you know, as an organization and 379 00:28:59,320 --> 00:29:04,520 check out the legalities and your jurisdiction or where you operate, etc. But we don't want people 380 00:29:04,520 --> 00:29:08,840 to ever think they should plan to pay the ransom, because you're going to need, you know, you get 381 00:29:08,840 --> 00:29:12,600 hit by one of these things, you're going to need to do all that security stuff you wanted that the 382 00:29:12,600 --> 00:29:16,680 security people are asking for. And you're going to be doing it in a crisis and you're going to be 383 00:29:16,680 --> 00:29:22,600 recovering with the tools that the attackers provided for you and make sure your lawyers and 384 00:29:22,600 --> 00:29:28,280 your PR people say that's a good idea. You know, I mean, so just to, you know, finish up my rant 385 00:29:28,280 --> 00:29:33,640 here, never plan to pay the ransom. You may have to, but, you know, plan to avoid the situation in 386 00:29:33,640 --> 00:29:38,200 the first place and be ready to recover. Yeah, absolutely. And I think deploying technology 387 00:29:38,200 --> 00:29:42,920 like Microsoft Defender for Endpoints and others like it is obviously this is mission critical 388 00:29:42,920 --> 00:29:47,320 preparation that will potentially prevent you from ever getting in case where you have to. 389 00:29:47,320 --> 00:29:51,800 And as I mentioned earlier, about 50% of the organizations we talked to in the OT space 390 00:29:51,800 --> 00:29:57,720 haven't deployed anything like that. And so it is mission critical that they prioritize this year 391 00:29:58,280 --> 00:30:00,840 to get something in their environment. We hope, of course, it's our solution. 392 00:30:01,880 --> 00:30:07,560 But they're going to be attacked. These, these ransoms are very profitable for the organizations 393 00:30:07,560 --> 00:30:13,320 and the plan should be to deliver new technologies to prevent this ever from happening in the first 394 00:30:13,320 --> 00:30:18,920 place. Yep. Be ready to recover. Make sure you can limit the scope of it if they do get in, kind 395 00:30:18,920 --> 00:30:24,360 of an assumed breach and, you know, and then add the prevention stuff. Yeah, that's as part of our, 396 00:30:24,360 --> 00:30:30,520 our ransomware roadmap. Kind of switching subjects for a bit here. Got anything new on the horizon? 397 00:30:30,520 --> 00:30:35,240 Any new capabilities? Because I know like we have the Defender for IoT that, you know, covers the 398 00:30:35,240 --> 00:30:39,240 OT environments, you know, and kind of gathers the network signals there. And we've got the 399 00:30:39,800 --> 00:30:44,840 Defender for Endpoint sort of, hey, anytime you have an MDE agent out there, you can, you know, 400 00:30:44,840 --> 00:30:49,080 gather all the network signals on the local subnet that that agent can pick up on. Is there 401 00:30:49,080 --> 00:30:53,960 anything else on the horizon? Yeah, we, this, this release coming up in June is, is so huge. 402 00:30:55,160 --> 00:30:59,080 Yeah, we could talk for quite a bit. So let me kind of summarize some of the key things. 403 00:31:00,600 --> 00:31:04,840 For OT organizations, I think one of the things that they're going to love the most about this 404 00:31:04,840 --> 00:31:10,520 release is the previous solution was really an on-prem solution. So if you're a large manufacturer 405 00:31:10,520 --> 00:31:17,400 with multiple sites, you're going to have a deployment of MD IoT in each and every one of 406 00:31:17,400 --> 00:31:22,920 those environments. And those environments basically are like little silos from our solution standpoint. 407 00:31:22,920 --> 00:31:29,720 What we're doing in this release is we're moving, not moving, but we're adding a experience in the 408 00:31:29,720 --> 00:31:35,400 cloud that will allow you to aggregate all of that threat data into one place. So if you're an 409 00:31:35,400 --> 00:31:39,560 organization that has many sites, rather than having a site, a console for each site, you're 410 00:31:39,560 --> 00:31:43,800 now going to have a single console that gives you visibility across everything that you have 411 00:31:43,800 --> 00:31:48,680 in your estate. So that's something that large OT organizations, or even medium, 412 00:31:48,680 --> 00:31:53,400 small ones are going to really appreciate. Another thing that I'm really excited about 413 00:31:54,360 --> 00:31:58,840 is when we're talking about operational technology, we're talking about, you know, a whole set of 414 00:31:59,480 --> 00:32:04,840 whole class of devices that most people don't know a lot about. But something that's really 415 00:32:04,840 --> 00:32:10,680 important about these devices is they use proprietary protocols. A lot of these do. And 416 00:32:10,680 --> 00:32:15,400 it's not like an IT network device, an endpoint, right, where we have the same protocols, and it's 417 00:32:15,400 --> 00:32:19,960 all the same across everything. These are completely separate protocols. They may have security baked 418 00:32:19,960 --> 00:32:26,680 into them. They may not, et cetera. And so a product like ours needs to have a deep understanding of 419 00:32:26,680 --> 00:32:31,640 each and every one of these protocols. And these protocols are not static. They're changing over 420 00:32:31,640 --> 00:32:38,200 time. And so the challenge that a lot of products have faced in the past is, you know, starting, 421 00:32:38,200 --> 00:32:43,480 you know, six months ago, they may have been, a vendor may have been up to date with the latest 422 00:32:43,480 --> 00:32:47,720 protocol changes, and their product was up to date. But then two weeks later, there's new 423 00:32:47,720 --> 00:32:52,440 technology. And then another month later, there's new technology. And so there's always this catch 424 00:32:52,440 --> 00:32:58,360 up that vendors have to do. And so it's kind of an untenable problem. And some organizations do it 425 00:32:58,360 --> 00:33:04,040 better than others. But it's still a really, really challenging problem. And so what we've done, 426 00:33:04,040 --> 00:33:08,200 and what we're doing in the next version of the product is we have a project called 427 00:33:08,840 --> 00:33:14,760 Codenamed Project Horizon. And what this is is going to be a community that facilitates the crowd 428 00:33:14,760 --> 00:33:20,760 sourcing of the latest data, the latest protocol information. And while Microsoft has great 429 00:33:20,760 --> 00:33:28,280 relationships with all the device vendors out there, the community can work with us and help us 430 00:33:28,280 --> 00:33:33,880 stay on top of this better than we could do on our own. And so this is going to help us stay 431 00:33:33,880 --> 00:33:38,280 up to date with the latest protocol changes as they come out. So Horizon is a great project that 432 00:33:38,280 --> 00:33:43,960 will, I think, make our product very differentiated in terms of our ability to keep up with protocol 433 00:33:43,960 --> 00:33:49,160 change with these proprietary protocols that are out there in the mini devices out there from 434 00:33:49,160 --> 00:33:53,480 Schneider Electric, et cetera, and so forth. So that's one thing. The next thing, of course, 435 00:33:53,480 --> 00:33:59,880 is the enterprise IoT story. We talked about that a bit, but that's going to expand our portfolio 436 00:33:59,880 --> 00:34:05,560 and really double the device type that we can cover. So that's super exciting. When I talk to 437 00:34:05,560 --> 00:34:12,520 IT network owners like a CISO, they have no visibility to the cameras and the printers and 438 00:34:12,520 --> 00:34:17,320 the endless other IoT devices that they've deployed in their environment. And so our solution will 439 00:34:17,320 --> 00:34:21,000 give them that visibility and the threat and detection response of vulnerability management 440 00:34:21,000 --> 00:34:28,760 across that broad set of devices as well. So there's a lot of excitement about the IT stuff there. 441 00:34:28,760 --> 00:34:33,800 The last thing that I think is worth mentioning is Microsoft Defender for IT is a little different 442 00:34:33,800 --> 00:34:39,000 than other products in the marketplace. A typical NDR product, the network detection 443 00:34:39,000 --> 00:34:44,200 response solution out there, runs as kind of its own isolated solution. And while it's good, 444 00:34:44,200 --> 00:34:48,360 very good at what it does, the reality is, is from a CISO perspective, from an instant 445 00:34:48,360 --> 00:34:55,240 response perspective, that data just rolls into a SIM and really requires analysts to spend a lot 446 00:34:55,240 --> 00:35:01,400 of time trying to aggregate the threat signals, alerts, and these types of things on IoT devices 447 00:35:01,400 --> 00:35:07,080 or OT devices with the broader attacks that they're part of, which very likely maybe started on 448 00:35:07,080 --> 00:35:12,280 the IT network and found a way to hop across networks and get into the OT environment as an example. 449 00:35:12,280 --> 00:35:17,960 So one of the things that we have done is we've integrated Microsoft Defender for IoT 450 00:35:18,520 --> 00:35:24,840 in our XDR solution and our SIM. And so what does that mean? It means a couple of things. 451 00:35:24,840 --> 00:35:29,720 First of all, if you're familiar with extended detection and response capabilities, what this 452 00:35:29,720 --> 00:35:36,360 does is this takes multiple signals from different sources and we're able to add ML and machine learning 453 00:35:36,360 --> 00:35:41,800 and artificial intelligence on top of this. And we have the potential by looking at 454 00:35:41,800 --> 00:35:49,080 looking at multiple signals at once to see attacks that maybe one signal on its own really can't 455 00:35:49,080 --> 00:35:54,280 give us insights into. And so let me let me make it a little more real. So for instance, 456 00:35:54,280 --> 00:35:59,320 with network signal that's used with an NDR product like ours, we may get a sense that there's a 457 00:35:59,320 --> 00:36:05,560 problem on a specific device. But because we're using machine learning and AI, our certainty level 458 00:36:05,560 --> 00:36:09,400 may be very, very high, like, Hey, it's 100%. We know this is a problem or it may be lower, 459 00:36:09,400 --> 00:36:16,280 it may be 80%. And so we have to make a choice as a vendor to surface that 80% certainty event or 460 00:36:16,280 --> 00:36:21,160 not. And sometimes we just don't have enough certainty. And so we don't surface that as alert 461 00:36:21,160 --> 00:36:25,880 because we don't want to generate false positives. Well, another signal as part of an XDR solution 462 00:36:25,880 --> 00:36:29,960 is the endpoint signal that comes from our Microsoft Defender for endpoint. And it's possible 463 00:36:29,960 --> 00:36:35,080 that by using the combination of signals on endpoints, as well as signals from the network 464 00:36:35,080 --> 00:36:41,080 in our MDI IT solution, that we can take the that 80% certainty of that NDR signal, and we can raise 465 00:36:41,080 --> 00:36:47,160 it up closer to 100%. And thus maybe surface alerts that maybe we wouldn't have done in the past, 466 00:36:47,160 --> 00:36:52,760 with a high level certainty with low false positives, etc. So the promise of XDR and 467 00:36:52,760 --> 00:36:58,440 reasing over multiple signals and integrating that into XDR solution, I think will give us the 468 00:36:58,440 --> 00:37:04,840 potential to detect attacks that vendors in the past would have been very hesitant to surface 469 00:37:04,840 --> 00:37:09,720 because of the risk of false positives. So this is a great new exciting thing. And then finally, 470 00:37:10,920 --> 00:37:15,400 by bringing this into XDR and hopefully detecting attacks that we previously couldn't, 471 00:37:16,440 --> 00:37:22,600 we can also combine that with IT and OT network signal. And what does that mean? That means when 472 00:37:22,600 --> 00:37:28,360 the attack begins on the IT network with an email and then the emails clicked on and the 473 00:37:28,920 --> 00:37:33,800 enterprise endpoint, the workstation is compromised, and then the attacker moves 474 00:37:33,800 --> 00:37:39,720 laterally to maybe a unprotected IoT device. So they move laterally and then maybe they 475 00:37:41,000 --> 00:37:46,280 compromise the vulnerability maybe in the network infrastructure and then are able to maybe get into 476 00:37:46,280 --> 00:37:52,120 the OT network with an XDR solution and an integrated SEM, we can show you that end to end 477 00:37:52,120 --> 00:37:57,000 picture, right? We're not just going to shove a random alert in a SEM and have an analyst spend 478 00:37:57,000 --> 00:38:02,520 endless hours or even days trying to create this kill chain in their head. We can actually bring 479 00:38:02,520 --> 00:38:07,240 this all together using automation because we have all these different endpoint types. We have the 480 00:38:07,240 --> 00:38:12,040 different signals and we're able to render that in a single view. And so that's probably, I think, 481 00:38:12,040 --> 00:38:17,320 one of the most exciting features because this is going to result in rapid instant response because 482 00:38:17,320 --> 00:38:21,000 the analysts are going to have all the insights and answers pre-cooked for them. They're going to see 483 00:38:21,000 --> 00:38:26,600 it visually and they're not going to have to do all that laborious work looking at timelines and 484 00:38:26,600 --> 00:38:31,400 trying to figure out what happened. Hey, Chris, if I remember correctly, also there are changes 485 00:38:31,400 --> 00:38:38,040 happening in other defender products in order to enable a defender for IoT. If I remember, 486 00:38:38,040 --> 00:38:45,160 a defender for endpoint has the capability of finding OT devices or IoT devices. Can you talk 487 00:38:45,160 --> 00:38:53,160 a little bit about that? Yeah, absolutely. So one of the challenges with an NDR solution is you need 488 00:38:53,160 --> 00:38:58,040 to tap into the network. And what does that mean? That means I need to take a sensor and I need to 489 00:38:58,040 --> 00:39:06,120 plug it into the stand port on not just one device, but any device, any network device on my network. 490 00:39:06,120 --> 00:39:10,840 So if I'm a large corporation like Microsoft, there's, I don't even know how many network devices 491 00:39:10,840 --> 00:39:14,520 we have in our organization, but that's a lot of sensors being connected to a lot of 492 00:39:14,520 --> 00:39:19,000 routers so that we can really see across all network segments across the entire company. 493 00:39:19,000 --> 00:39:25,560 So it takes time to deploy sensors in a way where you can get complete visibility. One of the things 494 00:39:25,560 --> 00:39:31,880 that's great about a solution like Microsoft Defender for IoT is Microsoft Defender for IoT 495 00:39:31,880 --> 00:39:39,080 can be a sensor as well. And I'm a spoke MDE or Microsoft Defender for endpoint. That solution 496 00:39:39,080 --> 00:39:44,920 is deployed in millions, millions, millions of clients, tens of millions of clients have this 497 00:39:44,920 --> 00:39:53,000 product on it. And so we can actually turn that client into a sensor so that it gives us the 498 00:39:53,000 --> 00:39:58,280 ability to detect IoT devices on the network. So the beauty of our solution, something that makes 499 00:39:58,280 --> 00:40:03,560 it unique is I think some of the third party solutions require that you deploy these network 500 00:40:03,560 --> 00:40:07,720 sensors and it takes a really, really, really long time to get that deployed completely across 501 00:40:07,720 --> 00:40:14,040 your environment. Because we've also added a network sensor in Microsoft Defender for endpoint 502 00:40:14,040 --> 00:40:20,680 client, we can leverage it as a network sensor as well. And it can actually detect or discover 503 00:40:20,680 --> 00:40:26,600 quite a bit of the IoT devices on the network, or at least the enterprise IoT devices on the network. 504 00:40:26,600 --> 00:40:31,240 Now Microsoft Defender for endpoint clients are generally not deployed in OT environments. 505 00:40:31,240 --> 00:40:35,480 So it's not going to give us insights into what's going on in that network. But as far as 506 00:40:35,480 --> 00:40:42,360 IT networks go, those clients are deployed. And then Microsoft Defender for IoT, I can't talk to 507 00:40:42,360 --> 00:40:47,480 that Microsoft Defender for endpoint clients are deployed pervasively across the IT network. And 508 00:40:47,480 --> 00:40:53,480 so we have great optics and great visibility into all the IoT devices, enterprise IoT devices are 509 00:40:53,480 --> 00:40:59,000 on those networks. Now with that said, the way the solution works is it is a passive solution. 510 00:40:59,560 --> 00:41:06,280 And so the only way that we will detect enterprise IoT devices on the IT network is if those devices 511 00:41:06,280 --> 00:41:12,840 are chatting on the network and they come in contact or they communicate with a defender 512 00:41:12,840 --> 00:41:19,800 for endpoint device. If the IoT device was connected only to the internet and never contacted 513 00:41:19,800 --> 00:41:24,520 devices on the IT network like an MDE client, then we wouldn't become aware of that. So 514 00:41:24,520 --> 00:41:29,320 there's still a case to be made to deploy a network sensor on the IT network. In fact, 515 00:41:29,320 --> 00:41:34,440 you should to get complete visibility. But the MDE clients out there in so many organizations, 516 00:41:34,440 --> 00:41:38,760 you know, the tens of millions of clients out there are going to discover a large percentage 517 00:41:38,760 --> 00:41:43,800 of the IoT devices in the environment. In fact, as I mentioned earlier in our public preview, 518 00:41:44,440 --> 00:41:49,480 we have over, it was I said 3 million, but actually I was wrong. It was actually 15 million 519 00:41:50,200 --> 00:41:55,880 devices are part of our public preview. And all of those were discovered through this passive 520 00:41:55,880 --> 00:42:01,880 communication without a dedicated network sensor. So we have great visibility and we can find a lot 521 00:42:01,880 --> 00:42:08,360 of all a lot of the devices, but just not 100% of them. Hey, so Chris, a while ago, you mentioned 522 00:42:08,360 --> 00:42:15,400 printers as one of the things that is part of OT. Obviously, everyone on the podcast, I'm sure, 523 00:42:15,400 --> 00:42:20,280 is familiar with printers and the other things that could be considered OT nowadays. Do you want 524 00:42:20,280 --> 00:42:26,040 to talk a little bit more about that or got any good stories for us? I can maybe mention a couple 525 00:42:26,040 --> 00:42:33,480 of things. Printers, oddly, when I talk to like CSOs or people who are interested in and maybe for 526 00:42:33,480 --> 00:42:39,240 the first time monitoring and securing their IT infrastructure, printers are almost always 527 00:42:39,240 --> 00:42:45,880 the first thing that they ask about. And so printers are the top priority. And it's no wonder 528 00:42:45,880 --> 00:42:51,720 a lot of the more advanced printers out there, they have a very rich operating system, they may 529 00:42:51,720 --> 00:42:58,120 be running Windows 10 on these devices. So they have a very rich operating system. It's very capable. 530 00:42:58,120 --> 00:43:03,560 And so that provides a very interesting environment for an attacker to compromise, 531 00:43:04,280 --> 00:43:08,120 because in most environments, those devices are not being secured with a solution like Microsoft 532 00:43:08,120 --> 00:43:13,800 Defender for IoT. And so they know that if they can compromise that print server device or that 533 00:43:13,800 --> 00:43:20,680 printer that's running a big operating system, that they have a lot of capability and they have a lot 534 00:43:20,680 --> 00:43:28,600 more capability in terms of memory and performance, etc. versus a very small IoT device where they may 535 00:43:28,600 --> 00:43:34,040 not be able to put enough code on that device to maybe do the types of things that they wanted to 536 00:43:34,040 --> 00:43:40,600 in terms of reconnaissance, etc. So the bigger, the more beefy the IoT device, the more interesting 537 00:43:40,600 --> 00:43:46,920 of a target it is, the smaller, the lower performance, lower memory, it's still an 538 00:43:46,920 --> 00:43:52,040 interesting device, but the attacker may feel a little limited in what type of attack they 539 00:43:52,040 --> 00:43:56,520 can unleash from that IoT device. So anyway, so printers are really interesting. 540 00:43:57,400 --> 00:44:02,040 Printers, of course, are on IT networks, and so it's part of our enterprise IoT story. 541 00:44:02,920 --> 00:44:07,960 They're also deployed pervasively in OT environments as well. And so the product that we 542 00:44:07,960 --> 00:44:13,480 have today is already monitoring what a lot of people typically consider kind of an enterprise 543 00:44:13,480 --> 00:44:17,800 IoT device because the reality is a lot of enterprise IoT devices are also sitting on the 544 00:44:17,800 --> 00:44:24,280 OT networks. And so the product that we already have, which focuses on OT, also actually provides 545 00:44:24,280 --> 00:44:28,840 good coverage for those traditional IoT devices that may be on the OT network. 546 00:44:28,840 --> 00:44:37,400 So you mentioned that we have several ways of basically discovering IoT or OT devices. 547 00:44:37,400 --> 00:44:43,720 I think this is critical for many customers, since for them, their critical infrastructure 548 00:44:43,720 --> 00:44:51,080 failure is not an option. So I wanted to make sure the customer understand that there's no 549 00:44:51,080 --> 00:44:59,960 any invasive capabilities for collection of information, as well as discovering some other 550 00:44:59,960 --> 00:45:04,280 information like boot net ability management. Is there anything else that you want to add 551 00:45:04,280 --> 00:45:09,880 about that? Yeah, I think you bring up a good point. And it's something that we have to repeat 552 00:45:09,880 --> 00:45:15,960 again and again and again. I mentioned earlier that maybe 50% of our customer base, those who 553 00:45:15,960 --> 00:45:20,840 have OT environments, don't have any sort of monitoring solution in there. There's a long list 554 00:45:20,840 --> 00:45:27,320 of reasons for it. But one of the big reasons is they're afraid of compromising the production 555 00:45:27,320 --> 00:45:33,560 of their OT environment. If you're an oil and gas company, you know how big those numbers are 556 00:45:33,560 --> 00:45:39,320 in terms of production, you're talking about millions of dollars a day are at risk if production 557 00:45:39,320 --> 00:45:45,240 goes down. And so they have an environment that works. They've segmented it away from the rest 558 00:45:45,240 --> 00:45:51,000 of the world, they think. And so a lot of them ignore deploying Marring solutions because they're 559 00:45:51,000 --> 00:45:55,720 worried that if that Marring solution goes into that environment that it may create just enough 560 00:45:55,720 --> 00:46:01,080 network traffic to cause a latency that may impact the quality of the production. So maybe it doesn't 561 00:46:01,080 --> 00:46:06,680 stop production, but maybe it slows things down. These OT environments are very sensitive. The 562 00:46:06,680 --> 00:46:11,480 devices on them oftentimes do not like to see any other network chatter out there. And so 563 00:46:12,360 --> 00:46:17,240 you mentioned the concept of passive. There's passive monitoring and there's active monitoring. 564 00:46:17,240 --> 00:46:21,560 Active monitoring is where a solution literally goes out there and scans network and is looking 565 00:46:22,120 --> 00:46:26,760 for things. And so all the devices, all the OT devices would be being touched in some way 566 00:46:26,760 --> 00:46:32,440 through some sort of active scan or whatnot. In contrast, passive monitoring, which is what 567 00:46:32,440 --> 00:46:36,840 Microsoft defender Friotida has no impact on the devices that are on the network. 568 00:46:37,560 --> 00:46:43,880 And the way we achieve passive monitoring is we tap into the span port of a router, for instance. 569 00:46:43,880 --> 00:46:48,280 And so the only impact we have is in theory on the router, but of course the router 570 00:46:49,080 --> 00:46:54,760 and the span port have been designed specifically for consumption of that data. And so you're not 571 00:46:54,760 --> 00:46:59,560 going to compromise the performance of your routers by connecting our sensor to it. They were designed 572 00:46:59,560 --> 00:47:05,080 specifically to have that happen. So with a passive monitoring, any customers who are a little nervous 573 00:47:05,080 --> 00:47:08,600 about what might happen when you deploy a solution like Microsoft Defender Friot, 574 00:47:09,720 --> 00:47:13,560 you really don't need to worry about it. I know you need to do diligence and you should, 575 00:47:14,200 --> 00:47:17,320 but I think when you see our design, you understand the nature of it and how it doesn't 576 00:47:17,320 --> 00:47:22,520 actually actively touch any of your devices, you'll be more confident about what a solution 577 00:47:22,520 --> 00:47:27,240 like ours can do for you. One other point I'd like to make that I think is worthy of mentioning 578 00:47:27,240 --> 00:47:32,440 is you mentioned discovery and getting a complete inventory of all the assets. Something that I 579 00:47:32,440 --> 00:47:37,160 didn't mention earlier when we talked about this was it's not just enough to discover 580 00:47:37,160 --> 00:47:42,600 all of the inventory on an OT network. And that's what a lot of vendors like us do. They get a 581 00:47:42,600 --> 00:47:46,040 complete inventory, but there's a couple of things that we're pretty proud of that we think are very 582 00:47:46,040 --> 00:47:53,480 innovative and kind of add differentiation to our solution. Number one is detecting what type of 583 00:47:53,480 --> 00:47:59,400 devices on the network by connecting to a SPAN port and looking at the data there is pretty 584 00:47:59,400 --> 00:48:06,760 challenging, right? To know that that's a Schneider Electric, PCL or whatever, that can be tricky, 585 00:48:06,760 --> 00:48:12,520 right? And so a lot of organizations differentiate themselves in terms of the ability to detect 586 00:48:12,520 --> 00:48:17,400 richly the nature of each device, understand it to make and model and all the things that it is. 587 00:48:18,120 --> 00:48:22,680 Some products just say, hey, here's a device with an IP address, right? Those who do this, 588 00:48:22,680 --> 00:48:28,040 their jobs well can say you what type of device it is. And that's good. And so we believe with our 589 00:48:28,040 --> 00:48:31,800 machine learning and AI that we're differentiated in terms of our ability to give you maybe some of 590 00:48:31,800 --> 00:48:38,280 the richest, most accurate classification of devices that are in the marketplace. So we're 591 00:48:38,280 --> 00:48:42,440 really proud of the work we're doing there. And that work comes online in June. We're going 592 00:48:42,440 --> 00:48:48,120 to be much better in June with an extra release. But there's one other thing I think that needs to 593 00:48:48,120 --> 00:48:53,720 happen. And this is very, very few vendors even try this. It's one thing to get you a list of all 594 00:48:53,720 --> 00:48:59,160 the devices on your network. That's wonderful, great, righteous thing to do. But what you really 595 00:48:59,160 --> 00:49:05,160 want to do is you want to give analysts context about these devices, not just the name and the 596 00:49:05,160 --> 00:49:10,600 make and the model, maybe what firmware builds on it or whatever. Those are table stakes in my 597 00:49:10,600 --> 00:49:16,840 view. What you want to understand is you want to understand the relationships between these devices. 598 00:49:16,840 --> 00:49:23,720 When we talk about OT technology, we're talking about large complex systems. And they form a 599 00:49:23,720 --> 00:49:29,000 hierarchy of sorts, right? And so to be able to understand not only that the devices exist, 600 00:49:29,000 --> 00:49:33,960 but to understand the relationships between them, to understand how they communicate with each other, 601 00:49:33,960 --> 00:49:38,920 how they should communicate with each other, and thus knowing how they should not be communicating 602 00:49:38,920 --> 00:49:46,200 with each other. Having that extra level of context really helps instant response move quickly. So 603 00:49:46,200 --> 00:49:51,720 when an attack happens, because if you understand the connectivity between the devices, the relationships 604 00:49:51,720 --> 00:49:57,880 between the devices, the purposes of those devices, and an instant responder can more quickly stop the 605 00:49:57,880 --> 00:50:01,720 attack because rather than looking a flat list of machines with alerts on them, they'll say, 606 00:50:01,720 --> 00:50:08,040 here's the tip of the spear of the attack. Here's how the attacker is compromising the entire end 607 00:50:08,040 --> 00:50:13,800 to end system. If we stop the attack here, we can stop the attack elsewhere as well at the same time. 608 00:50:13,800 --> 00:50:17,240 And so that's that type of context is something we're working on really hard 609 00:50:17,240 --> 00:50:20,280 with the next release. And I think our customer is going to find that we provide 610 00:50:21,080 --> 00:50:25,000 maybe some of the fastest instant response capabilities in the marketplace with our next 611 00:50:25,000 --> 00:50:32,520 version. So these are a lot of good capabilities. But you also said that a lot of customers 612 00:50:32,520 --> 00:50:38,920 are not doing anything in the environment. So how are we helping them to prioritize 613 00:50:38,920 --> 00:50:42,280 the mitigation and the areas that they should be focusing on? 614 00:50:43,480 --> 00:50:47,560 Right. Yeah. I mean, once you deploy a solution like Microsoft Defender for IoT, 615 00:50:47,560 --> 00:50:51,880 and you start performing vulnerability management, and you give them a list of 616 00:50:52,440 --> 00:50:58,280 weaknesses that they need to address, the next question is, how long is that going to take? 617 00:50:58,280 --> 00:51:03,000 How many resources do I need to apply to this? And then of course, it becomes like, 618 00:51:03,000 --> 00:51:05,880 okay, what's the most important thing to do first? Because I can't address all of this 619 00:51:07,320 --> 00:51:11,320 this week or this month or maybe in the next six months or even longer. Some of these 620 00:51:11,320 --> 00:51:17,160 these recommendations can take very long planning cycles to address the weaknesses that we're able 621 00:51:17,160 --> 00:51:23,160 to identify in the network. And so being able to provide our customers with a threat, prioritize, 622 00:51:23,160 --> 00:51:29,800 risk prioritize approach to going through that list is something that we do and other vendors do it 623 00:51:29,800 --> 00:51:36,280 as well. Something that we do to take it even further. And we don't have the final name for 624 00:51:36,280 --> 00:51:41,720 this feature that's coming in the next version, but we call it attack vector analysis. So attack 625 00:51:41,720 --> 00:51:49,640 vector analysis basically is where we look at the end to end environment. And by assessing it 626 00:51:49,640 --> 00:51:55,240 holistically, we can come up with and based on the vulnerabilities and the configuration 627 00:51:55,240 --> 00:52:00,680 recommendations we have, we can anticipate where if an attacker was able to compromise, 628 00:52:00,680 --> 00:52:06,760 get into the OT network, we can anticipate probably which devices they would identify first 629 00:52:07,720 --> 00:52:14,760 and exploit first. And so we can basically kind of guess like how would they, you know, not get 630 00:52:14,760 --> 00:52:19,800 into the network necessarily, but once they're on the network, what devices are weakest? What devices 631 00:52:19,800 --> 00:52:25,640 are those devices connected to? And if that next device is compromised, what's the impact on production? 632 00:52:25,640 --> 00:52:30,680 And so with this kind of knowledge about the holistic environment, we can tell you, you know, 633 00:52:30,680 --> 00:52:35,800 which devices require which patches first or which configuration changes first rather than telling you 634 00:52:35,800 --> 00:52:41,160 about a go patch this device that's, you know, tucked away and maybe segmented away from everything 635 00:52:41,160 --> 00:52:46,280 and thus the least likely device to be compromised, you know, we can direct you towards the things 636 00:52:46,280 --> 00:52:51,320 that are most likely to get the attacker the control they want and get them to the crown jewels 637 00:52:51,320 --> 00:52:56,600 the quickest. Earlier today, I was talking about threat intelligence. Can you talk a little bit 638 00:52:56,600 --> 00:53:04,360 how threat intelligence is used in defender IoT? To start with, our threat intelligence is based on 639 00:53:04,360 --> 00:53:09,640 on a lot of things. One, it's based on the signal source. You mentioned earlier that we have trillions 640 00:53:09,640 --> 00:53:15,080 of signals coming in a day and not all of those, of course, are related to OT threats or IoT threats. 641 00:53:15,080 --> 00:53:19,880 They're related to endpoint threats and anything and everything. So we have tremendous signal 642 00:53:19,880 --> 00:53:26,760 and arguably the largest signal in the world. And that gives us the potential to gain great insights. 643 00:53:26,760 --> 00:53:33,560 And we have an enormous research team. We have 3,500 researchers, engineers and other 644 00:53:33,560 --> 00:53:37,400 different types of personalities working on security. So we have this amazing force that's 645 00:53:37,400 --> 00:53:42,840 taking advantage of this threat intelligence data signal that we get to make sense of it. And of 646 00:53:42,840 --> 00:53:48,200 course, we apply machine learning and AI and we've got great researchers doing amazing innovation 647 00:53:48,200 --> 00:53:53,080 there. So we have this great potential because of the big data. At the end of the day, this is a 648 00:53:53,080 --> 00:53:58,200 big data problem. And so we've got the data. We have the volume of people and the researchers 649 00:53:58,200 --> 00:54:04,040 and the types of people to make sense of that data. So that's one aspect of threat intelligence. 650 00:54:04,040 --> 00:54:09,000 The next aspect, of course, is not just detecting threats and these types of things. It's also 651 00:54:09,000 --> 00:54:16,440 understanding about the attackers. So we have teams dedicated to tracking threat actors, 652 00:54:17,640 --> 00:54:23,880 understanding their tactics, et cetera. And so some of that knowledge is codified into 653 00:54:23,880 --> 00:54:29,960 detections that make our products generate alerts and enable us to correlate incidents 654 00:54:29,960 --> 00:54:35,080 and these types of things. But it also comes out in other forms. It comes out in written forms 655 00:54:36,120 --> 00:54:40,840 that are shared with our customers so that they can understand the nature of the threat actors, 656 00:54:40,840 --> 00:54:48,440 understand their motivations, understand their tactics, et cetera. So this huge signal base 657 00:54:48,440 --> 00:54:54,280 enables our researchers to compile really great profiles that we can share with our customers. 658 00:54:54,280 --> 00:55:00,520 And so there's that. But one thing I want to mention is a lot of people talk about threat 659 00:55:00,520 --> 00:55:05,320 intelligence in the context of this latter form. It's a document that says what threat actors, 660 00:55:05,320 --> 00:55:11,160 et cetera, are doing. I think the most important part of threat intelligence is what we do when 661 00:55:11,160 --> 00:55:18,440 we codify that threat intelligence and turn that into IOCs, IOAs, other types of things and enable 662 00:55:18,440 --> 00:55:23,320 us to detect the latest threats. So people need to keep in mind that threat intelligence, two forms, 663 00:55:23,320 --> 00:55:27,400 it's information about threat actors, but it's also the codification of that intelligence into 664 00:55:27,400 --> 00:55:33,560 detections that allow us to detect the latest threats. And so Microsoft has a crack team 665 00:55:33,560 --> 00:55:41,000 dedicated to IoT and OT threats. We call them Section 52. And so these are specialists. All 666 00:55:41,000 --> 00:55:48,040 they do is think about IoT OT threats. And so we've just got this great team who's giving us 667 00:55:48,040 --> 00:55:55,240 many insights. And they're not well known yet because we're in a new space. But the analysts 668 00:55:55,240 --> 00:55:58,680 and the researchers, they came from a really well-known company called CyberX. We made an 669 00:55:58,680 --> 00:56:03,400 acquisition about a year and a half ago, or maybe it's almost two years, CyberX. And so 670 00:56:04,520 --> 00:56:08,680 we're not really new. Microsoft maybe knew it, but the people that we acquired as part of the 671 00:56:08,680 --> 00:56:12,840 acquisition, they've been working on this problem set for a really long time. So Section 52 is an 672 00:56:12,840 --> 00:56:17,000 exceptional team producing great results. And I think they'll become more well known 673 00:56:17,000 --> 00:56:21,240 in the future as our customers start to deploy our product and become more familiar with it. 674 00:56:21,960 --> 00:56:26,680 Hey, Chris. So one question we always ask our guests is if you had one thought, 675 00:56:26,680 --> 00:56:28,680 just leave our listeners. What would it be? 676 00:56:29,240 --> 00:56:34,120 Yeah, that's a good question. Let's see. There's so many thoughts I'd like to leave. Here's what I 677 00:56:34,120 --> 00:56:39,320 would say. As I mentioned earlier, we think about 50% of the customers who have the potential to use 678 00:56:39,320 --> 00:56:45,080 a product like Microsoft Defender for IoT don't have any solution out there. And they've used 679 00:56:45,080 --> 00:56:49,560 network segmentation, et cetera, is a way to hide their environment. But as we've seen, 680 00:56:49,560 --> 00:56:54,440 colonial pipeline, and there's endless other stories out there, you really can't afford 681 00:56:54,440 --> 00:57:00,600 to be unprotected. I think my recommendation for those customers in that category is this year 682 00:57:00,600 --> 00:57:07,160 has to be the year that you start doing proof of concepts with a product. And we hope it's ours, 683 00:57:07,160 --> 00:57:11,240 but you've got to get something because as we talked about with the ransomware events that are 684 00:57:11,240 --> 00:57:17,480 now being used to extort money out of companies, this is a real problem. It's not hypothetical 685 00:57:17,480 --> 00:57:23,080 like it was a few years ago. So make this year the year that you deploy if you haven't deployed. 686 00:57:23,080 --> 00:57:29,640 And if you're a company that has a solution out there, we of course want you to continue to look 687 00:57:29,640 --> 00:57:34,520 at other solutions out there. We'd love for you to take a look at ours. I think there's a sea 688 00:57:34,520 --> 00:57:40,600 change in the technology out there. I think the promise of a NDR solution like ours when it's 689 00:57:40,600 --> 00:57:46,600 integrated with the XDR solution, which does can leverage multiple signals to gain insights that 690 00:57:46,600 --> 00:57:53,640 can't be done alone with NDR. When you look at a SIM solution, they can give you visibility 691 00:57:53,640 --> 00:58:00,120 to the end to end kill chain, starting with the email breach and ending up with the production 692 00:58:00,120 --> 00:58:05,000 getting stopped at OT network. And you see everything in between in one visual way that 693 00:58:05,000 --> 00:58:10,520 really helps expedite instant response. I think that customers, we'd love for you to look at our 694 00:58:10,520 --> 00:58:15,080 products, but there are others out there as well that are very different than maybe what you've 695 00:58:15,080 --> 00:58:20,520 seen a few years ago. There's just tremendous innovation in our space with us and other vendors. 696 00:58:20,520 --> 00:58:24,440 And so if you're running a solution that maybe you took advantage from three, four years ago, 697 00:58:25,000 --> 00:58:28,760 there's really new solutions that are breaking through a lot of barriers that you couldn't 698 00:58:28,760 --> 00:58:32,120 break through a couple of years ago. Okay, let's bring this to an end. Thank you so much for joining 699 00:58:32,120 --> 00:58:36,440 us this week, Chris. My head is kind of spinning to be honest with you. It's one of those areas 700 00:58:36,440 --> 00:58:40,680 where I realized there's a lot that I still need to learn. But again, thank you so much for joining 701 00:58:40,680 --> 00:58:45,480 us this week. I really appreciate it. And to all our listeners out there, thank you very much for 702 00:58:45,480 --> 00:58:49,720 listening as well. Stay safe and we'll see you next time. Thanks for listening to the Azure 703 00:58:49,720 --> 00:58:56,920 Security Podcast. You can find show notes and other resources at our website azsecuritypodcast.net. 704 00:58:56,920 --> 00:59:01,720 If you have any questions, please find us on Twitter at azuresetpod. 705 00:59:01,720 --> 00:59:27,080 Background music is from ccmixter.com and licensed under the Creative Commons license.