1 00:00:00,000 --> 00:00:06,200 Welcome to the Azure Security Podcast, 2 00:00:06,200 --> 00:00:09,360 where we discuss topics relating to security, privacy, 3 00:00:09,360 --> 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 46. 5 00:00:16,600 --> 00:00:18,240 This week is myself, Michael. 6 00:00:18,240 --> 00:00:20,720 I'm here with Mark and with Gladys. 7 00:00:20,720 --> 00:00:23,160 Sarah is actually in California at a conference, 8 00:00:23,160 --> 00:00:24,760 so she won't be joining us this week. 9 00:00:24,760 --> 00:00:27,080 We also have a guest, we have Matt Egan, 10 00:00:27,080 --> 00:00:29,680 who's here to talk to us about Microsoft Sentinel and 11 00:00:29,680 --> 00:00:33,120 third party connectors and KQL queries in general. 12 00:00:33,120 --> 00:00:34,800 But before we get to Matt, 13 00:00:34,800 --> 00:00:37,440 let's take a little wrap around the news. 14 00:00:37,440 --> 00:00:38,840 Gladys, why don't you kick things off? 15 00:00:38,840 --> 00:00:42,840 Actually, I'm going to do something a little bit different. 16 00:00:42,840 --> 00:00:45,080 Instead of giving news, 17 00:00:45,080 --> 00:00:49,800 I'm going to talk about something that is affecting many customers. 18 00:00:49,800 --> 00:00:55,160 I've been in calls with many customers that are trying to align 19 00:00:55,160 --> 00:00:58,520 their security to the executive order, 20 00:00:58,520 --> 00:01:02,920 the White House, for those that are not familiar with this. 21 00:01:02,920 --> 00:01:09,360 The White House has released some orders on securing infrastructure. 22 00:01:09,360 --> 00:01:14,400 That has prompted a lot of different organizations like DOE, TSA. 23 00:01:14,400 --> 00:01:18,440 DOE stands for Department of Energy, 24 00:01:18,440 --> 00:01:21,560 TSA, Transportation Security Administration, 25 00:01:21,560 --> 00:01:27,000 CISA, the Cybersecurity Infrastructure Security Agency, 26 00:01:27,000 --> 00:01:30,760 NIST, National Institute of Standard and Technology, 27 00:01:30,760 --> 00:01:34,240 and others have given a lot of different guidance. 28 00:01:34,240 --> 00:01:38,880 While the customers have been trying to align this security, 29 00:01:38,880 --> 00:01:42,600 they often call us and they're asking us, 30 00:01:42,600 --> 00:01:47,240 okay, we need guidance on cirutros and SASE. 31 00:01:47,240 --> 00:01:49,760 What is the difference on this? 32 00:01:49,760 --> 00:01:55,440 Frankly, I often found it really hard to explain it to customer, 33 00:01:55,440 --> 00:01:57,600 what is the difference? 34 00:01:57,600 --> 00:02:01,760 I've been reading a lot of documentation even from Garner 35 00:02:01,760 --> 00:02:05,360 in order to come up with definitions. 36 00:02:05,360 --> 00:02:09,520 Hopefully, this is going to help some customers. 37 00:02:09,520 --> 00:02:13,840 Mark and Michael feel free to chime in with additional information 38 00:02:13,840 --> 00:02:16,720 because we are receiving so many calls. 39 00:02:16,720 --> 00:02:18,560 It's just unbelievable. 40 00:02:18,560 --> 00:02:21,360 Basically, what I was reading, 41 00:02:21,360 --> 00:02:27,680 I found out that SASE is mainly a framework that aims to securely 42 00:02:27,680 --> 00:02:33,000 connect users and endpoints to applications and services, 43 00:02:33,000 --> 00:02:35,080 no matter where they are, 44 00:02:35,080 --> 00:02:40,680 whether they're on-prem or in the internet at home or whatever, 45 00:02:40,680 --> 00:02:45,160 the framework is supposed to secure that communication. 46 00:02:45,160 --> 00:02:50,280 Because they are looking to consolidate all the information, 47 00:02:50,280 --> 00:02:54,280 they are focused heavily on network capabilities. 48 00:02:54,280 --> 00:02:58,640 So you will see a lot of routing, SASE, 49 00:02:58,640 --> 00:03:05,320 content delivery, catching, and other services being interconnected. 50 00:03:05,320 --> 00:03:10,680 Now, cirutros is a framework that assumes everything can be compromised. 51 00:03:10,680 --> 00:03:17,480 And as such, a defense layer approach is used to protect the environment. 52 00:03:17,480 --> 00:03:23,320 Cirutros also relies on the implementation of least privilege. 53 00:03:23,320 --> 00:03:29,800 The key is to mitigate risk by proactively verifying every information, 54 00:03:29,800 --> 00:03:34,240 every attribute available for that entity and phone application, 55 00:03:34,240 --> 00:03:37,400 data network, and infrastructure. 56 00:03:37,400 --> 00:03:43,080 So the amount of verification required depends on the information 57 00:03:43,080 --> 00:03:45,200 available to be verified. 58 00:03:45,200 --> 00:03:50,320 So when you compare both, SASE is a framework that aims to provide 59 00:03:50,320 --> 00:03:53,880 that secure connection in the monitors, 60 00:03:53,880 --> 00:03:56,520 there's a lot of network capabilities. 61 00:03:56,520 --> 00:04:02,040 While cirutros is aimed to also provide that security 62 00:04:02,040 --> 00:04:05,920 through verification by reducing risk. 63 00:04:05,920 --> 00:04:11,720 I found that although both use similar infrastructure, 64 00:04:11,720 --> 00:04:18,120 SASE contains some sources of content from quality of service, 65 00:04:18,120 --> 00:04:22,440 what area, networking, optimization, information 66 00:04:22,440 --> 00:04:25,360 that cirutros may not take advantage of. 67 00:04:25,360 --> 00:04:31,080 While cirutros, because we are implementing least privilege, 68 00:04:31,080 --> 00:04:37,040 there's services like cloud infrastructure, entitlement management, 69 00:04:37,040 --> 00:04:44,120 just-in-time access, and others that may not be necessarily used with SASE. 70 00:04:44,120 --> 00:04:48,480 So in other words, both frameworks may be accomplished 71 00:04:48,480 --> 00:04:50,480 using similar infrastructure, 72 00:04:50,480 --> 00:04:53,880 but each of them has some extra components 73 00:04:53,880 --> 00:04:58,680 not necessarily needed to accomplish the other. 74 00:04:58,680 --> 00:05:01,080 Yeah, if I can add there, Gladys, 75 00:05:01,080 --> 00:05:05,160 the thing that I've seen is that when we were first trying to figure this out, 76 00:05:05,160 --> 00:05:10,040 because I helped contribute to some of the slides and whatnot for Microsoft in this one, 77 00:05:10,040 --> 00:05:13,080 the original place that we started was a FEND diagram, 78 00:05:13,080 --> 00:05:15,800 where they have a lot more in common than they have different, 79 00:05:15,800 --> 00:05:17,680 and that's very true. 80 00:05:17,680 --> 00:05:20,400 And so that's one of the ways to think about it. 81 00:05:20,400 --> 00:05:25,720 SASE also, we found, tends to be a little bit more implementation-specific. 82 00:05:25,720 --> 00:05:29,160 And so like, zero trust is, there's kind of two zero trusts. 83 00:05:29,160 --> 00:05:32,560 One is the big strategy that drives modernization of access control 84 00:05:32,560 --> 00:05:34,920 and sec ops and governance and asset protection, 85 00:05:34,920 --> 00:05:36,920 and all those kind of things. 86 00:05:36,920 --> 00:05:39,920 But people also tend to say, zero trust, 87 00:05:39,920 --> 00:05:43,600 use it for the access control, modernization as well. 88 00:05:43,600 --> 00:05:45,920 So it's kind of like two zero trusts, like a big zero trust, 89 00:05:45,920 --> 00:05:49,400 and then a specific initiative, a smaller one. 90 00:05:49,400 --> 00:05:53,680 And SASE tends to be pretty close to that access control piece 91 00:05:53,680 --> 00:05:57,800 and really focused on that, what is a secure access service edge. 92 00:05:57,800 --> 00:06:00,840 And so that's one of the ways that they sort of overlap. 93 00:06:00,840 --> 00:06:05,960 And SASE does tend to bring in a little bit more of a network bias we've seen. 94 00:06:05,960 --> 00:06:09,960 It's definitely embracing identity and sort of requires really identity as a service. 95 00:06:09,960 --> 00:06:13,480 It's not always explicitly stated, but all these different CASB, 96 00:06:13,480 --> 00:06:17,400 secure web gateway things really kind of require an identity as a service 97 00:06:17,400 --> 00:06:20,120 in the middle to kind of bind it together and pull it together. 98 00:06:20,120 --> 00:06:24,040 So it has a little bit more of an availability piece, 99 00:06:24,040 --> 00:06:27,200 because it's talking about the service edge, not just in secure terms, 100 00:06:27,200 --> 00:06:29,760 but also in performance terms. 101 00:06:29,760 --> 00:06:32,400 And so Microsoft is kind of a fan of both frameworks 102 00:06:32,400 --> 00:06:36,960 because they shine light in two different directions on different problems. 103 00:06:36,960 --> 00:06:39,280 Ultimately, the thing that we found that's kind of cool is, 104 00:06:39,280 --> 00:06:43,680 say you go down a SASE road, but you're still moving towards zero trust 105 00:06:43,680 --> 00:06:46,280 as a big picture kind of initiative too. 106 00:06:46,280 --> 00:06:51,000 So those are some of the things that I've seen in that space. 107 00:06:51,000 --> 00:06:58,200 So being the lookout for our links that we're posting in the Azure Security podcast 108 00:06:58,200 --> 00:07:04,320 because Microsoft has developed most of it, 109 00:07:04,320 --> 00:07:11,160 it has a lot of documentation that can help not only align the security requirements 110 00:07:11,160 --> 00:07:16,520 to all these guidance, but also help you understand the differences. 111 00:07:16,520 --> 00:07:19,440 Actually, I don't really have a news link this week either. 112 00:07:19,440 --> 00:07:21,520 You can chalk it up to laziness or... 113 00:07:21,520 --> 00:07:26,160 But one of the things that's come up is the cyber reference architecture 114 00:07:26,160 --> 00:07:30,360 has gone around a few times on LinkedIn and whatnot. 115 00:07:30,360 --> 00:07:34,840 And there is a SASE diagram in there, which I kind of neglected to mention earlier, 116 00:07:34,840 --> 00:07:37,400 but in the cyber reference architecture, 117 00:07:37,400 --> 00:07:42,520 there is a whole section on SASE and kind of how it does a comparison to zero trust. 118 00:07:42,520 --> 00:07:44,600 One of the things I wanted to talk about a little bit 119 00:07:44,600 --> 00:07:47,960 that is also covered in the cyber reference architecture 120 00:07:47,960 --> 00:07:52,160 and something that we're working on some sort of deeper analysis and content on 121 00:07:52,160 --> 00:07:55,360 is a little bit more around security teams and roles. 122 00:07:55,360 --> 00:08:00,680 One of the things that I've sort of come to a more crystal clear understanding about 123 00:08:00,680 --> 00:08:03,880 in the past, say about a month or so, 124 00:08:03,880 --> 00:08:07,760 is really that security has two operational functions, 125 00:08:07,760 --> 00:08:11,200 two sort of active interacting with the environment, 126 00:08:11,200 --> 00:08:16,280 interacting with the operational team like IT ops, DevOps, et cetera, functions. 127 00:08:16,280 --> 00:08:21,040 One is what most people are familiar with kind of in the reactive side sec ops or SOC, 128 00:08:21,040 --> 00:08:24,480 security operations center or security operations. 129 00:08:24,480 --> 00:08:27,560 And that tends to be all about the live fire incident, 130 00:08:27,560 --> 00:08:29,320 the actual attackers in the environment. 131 00:08:29,320 --> 00:08:31,920 And you definitely need a dedicated operational team, 132 00:08:31,920 --> 00:08:37,800 work with IT ops teams to have ops teams investigate, respond and get that addressed. 133 00:08:37,800 --> 00:08:42,240 But there's also this sort of preventive operations, 134 00:08:42,240 --> 00:08:47,520 which most of the time it usually shows up as just a vulnerability scanning team 135 00:08:47,520 --> 00:08:52,040 that asks the various different IT ops teams to go apply patches. 136 00:08:52,040 --> 00:08:57,600 And the thing that's been interesting is watching that plus sort of all these 137 00:08:57,600 --> 00:09:01,440 cloud security posture management and secure score and all these kind of new 138 00:09:01,440 --> 00:09:05,040 cloud capabilities come in that allow you to have sort of real time on demand 139 00:09:05,040 --> 00:09:08,680 operational view into not just your software vulnerabilities, 140 00:09:08,680 --> 00:09:12,200 but configuration vulnerabilities and sometimes some operational practices 141 00:09:12,200 --> 00:09:16,000 and identifying some of those kind of things that could cause risk. 142 00:09:16,000 --> 00:09:19,040 And so it's been sort of an interesting realization that we really need two 143 00:09:19,040 --> 00:09:21,600 different operational teams and security. 144 00:09:21,600 --> 00:09:25,320 One focusing on that hot live fire incident, 145 00:09:25,320 --> 00:09:28,080 but also focusing on that security posture. 146 00:09:28,080 --> 00:09:31,160 We're calling this posture management, Microsoft, 147 00:09:31,160 --> 00:09:33,600 that's really focused on the preventive side. 148 00:09:33,600 --> 00:09:36,520 Just like the SOC doesn't actually change the environment, right? 149 00:09:36,520 --> 00:09:40,160 It works with the IT operations team to do it, but is kind of there, 150 00:09:40,160 --> 00:09:43,840 and the different parts of the teams are doing glass watching and then working 151 00:09:43,840 --> 00:09:47,840 with the teams, enablement of the teams as well. 152 00:09:47,840 --> 00:09:52,880 We've seen some organizations that apply this really well to application security. 153 00:09:52,880 --> 00:09:58,400 So instead of just having a, here's a scan and a 50 page file to go into your 154 00:09:58,400 --> 00:10:03,240 app development, much more engaged in the DevOps processes and building experts 155 00:10:03,240 --> 00:10:08,600 within DevOps teams and then actively working with the IT operations teams as well. 156 00:10:08,600 --> 00:10:13,840 But ultimately, they found that the number of incidents that happen on one 157 00:10:13,840 --> 00:10:17,680 of these teams that has worked with this sort of application security help 158 00:10:17,680 --> 00:10:23,000 desk or enablement or evangelism team is much lower than the teams and 159 00:10:23,000 --> 00:10:24,720 the DevOps teams that don't. 160 00:10:24,720 --> 00:10:29,040 And so we're really seeing from a bunch of different directions that need for 161 00:10:29,040 --> 00:10:33,480 a formal focus and structure around that sort of preventive operations. 162 00:10:33,480 --> 00:10:35,320 And so we're pulling together as many learnings and 163 00:10:35,320 --> 00:10:37,240 best practices around that as we can lately. 164 00:10:38,320 --> 00:10:42,800 And we've sort of hinted at this in the MCRA stuff with the plan build run type 165 00:10:42,800 --> 00:10:46,000 of things there and we're looking to do even more. 166 00:10:46,000 --> 00:10:49,680 So I have a few items that sort of took my interest over the last few weeks. 167 00:10:49,680 --> 00:10:56,240 The first one is, so as you DevOps was supposed to deprecate TLS 1.0 and 1.1 168 00:10:56,240 --> 00:10:59,880 like three days ago, but they actually rolled back the change because there 169 00:10:59,880 --> 00:11:03,040 were some compatibility problems with some big clients apparently. 170 00:11:03,040 --> 00:11:04,880 That's the extent of what I know. 171 00:11:04,880 --> 00:11:09,000 But yeah, so at some point in the future, there will be a rollout of deprecation 172 00:11:09,000 --> 00:11:10,680 of TLS 1.0 and 1.1. 173 00:11:10,680 --> 00:11:15,120 So only TLS 1.2 and eventually TLS 1.3 will be supported. 174 00:11:15,120 --> 00:11:19,400 The next one is with a product that's near and dear to my heart and as a key vault. 175 00:11:19,400 --> 00:11:22,600 We've now increased the service limits for all customers. 176 00:11:22,600 --> 00:11:28,560 Historically, key vault could only do, for example, a get against RSA say, 177 00:11:28,560 --> 00:11:32,120 software keys of around 2000 every 10 seconds. 178 00:11:32,120 --> 00:11:36,880 This has now been doubled to 4000 get transactions per 10 seconds. 179 00:11:36,880 --> 00:11:42,840 Now, before you start thinking, oh, that's fantastic, let's double our number of 180 00:11:42,840 --> 00:11:47,280 hits that we're going to make against key vault, I would urge against that. 181 00:11:47,280 --> 00:11:49,080 And there's a few reasons for it. 182 00:11:49,080 --> 00:11:54,040 The first one is, key vault is not really designed as a massively transactional 183 00:11:54,040 --> 00:11:57,760 product, it's not like a database that's designed to have massive amounts of throughput. 184 00:11:57,760 --> 00:12:00,600 And to be honest, you're not really going to be rolling keys and secrets and 185 00:12:00,600 --> 00:12:02,640 certificates that often anyway. 186 00:12:02,640 --> 00:12:06,120 So the general rule of thumb there is to actually make a cash connection instead 187 00:12:06,120 --> 00:12:11,160 and actually say, have only hit key vault every five minutes or every 10 minutes. 188 00:12:11,160 --> 00:12:15,240 But certainly not 2000 a second or 2000 every 10 seconds. 189 00:12:15,240 --> 00:12:18,760 And the reason for that is also is if you do start hitting those limits, 190 00:12:18,760 --> 00:12:20,760 key vault will throttle your connection. 191 00:12:20,760 --> 00:12:25,240 So even though we have increased the connections and that's fantastic, 192 00:12:25,240 --> 00:12:30,960 I would still caution against just opening the floodgates, that's not a good thing. 193 00:12:30,960 --> 00:12:37,120 The next thing is in Azure Database for Postgres SQL, in the hyperscale version, 194 00:12:37,120 --> 00:12:41,320 we now have private endpoint support, private link and private endpoint support. 195 00:12:41,320 --> 00:12:45,120 As I mentioned on multiple podcasts, we see this happening across more and 196 00:12:45,120 --> 00:12:46,600 more past services. 197 00:12:46,600 --> 00:12:48,880 And so this is another thing that's great to see. 198 00:12:48,880 --> 00:12:53,960 So that's Postgres SQL for hyperscale, and that is general availability. 199 00:12:55,000 --> 00:12:57,840 The other one under general availability, also for Postgres SQL, 200 00:12:57,840 --> 00:13:01,320 is we now have a whole bunch more certifications. 201 00:13:01,320 --> 00:13:03,200 I'm not going to go through all of these things. 202 00:13:03,200 --> 00:13:09,040 Most of them seem to affect European countries, so AFM and DMB in the Netherlands. 203 00:13:09,040 --> 00:13:11,800 I do not pretend to be familiar with those. 204 00:13:11,800 --> 00:13:15,640 In Switzerland, there's the financial market supervisory authority. 205 00:13:15,640 --> 00:13:20,000 So these are applied to Netherlands, France, Switzerland, Denmark, Belgium and 206 00:13:20,000 --> 00:13:21,280 Poland. 207 00:13:21,280 --> 00:13:25,400 So if you're in those countries or have customers in those countries that require 208 00:13:25,400 --> 00:13:28,760 these kinds of certifications and you use in Postgres SQL, then we have some good 209 00:13:28,760 --> 00:13:29,880 news for you. 210 00:13:29,880 --> 00:13:34,080 So that's basically all the news that I have this week. 211 00:13:34,080 --> 00:13:36,200 So let's turn our attention to our guest. 212 00:13:36,200 --> 00:13:41,400 This week we have Matt Egan, who's here to talk to us about interconnecting 213 00:13:41,400 --> 00:13:44,000 Sentinel with third party connectors. 214 00:13:44,000 --> 00:13:46,080 Matt, hey, welcome to the podcast. 215 00:13:46,080 --> 00:13:50,600 Would you like to spend just a moment and explain kind of who you are and what you do? 216 00:13:50,600 --> 00:13:51,360 Sure. 217 00:13:51,360 --> 00:13:52,640 Thank you so much for having me. 218 00:13:52,640 --> 00:13:54,080 Really appreciate it. 219 00:13:54,080 --> 00:13:55,800 As you mentioned, my name is Matt Egan. 220 00:13:55,800 --> 00:13:59,480 I am what we call a global black belt here at Microsoft, 221 00:13:59,480 --> 00:14:04,280 which is a very fancy title for really just an SMA on our security tools. 222 00:14:04,280 --> 00:14:08,840 So I specialize in the Microsoft threat protection tools, so defender for end 223 00:14:08,840 --> 00:14:15,080 points, defender for office, as well as Microsoft Sentinel, wherein I have a lot 224 00:14:15,080 --> 00:14:19,760 of experience in building on connectors for the systems as well as integrating 225 00:14:19,760 --> 00:14:21,200 with other third party tools. 226 00:14:21,200 --> 00:14:23,240 So really pleased to be here. 227 00:14:23,240 --> 00:14:26,720 So yeah, just for everyone out there, we may end up accidentally calling it 228 00:14:26,720 --> 00:14:27,720 as your Sentinel. 229 00:14:27,720 --> 00:14:31,480 And if you hear that, we mean Microsoft Sentinel, just so you know. 230 00:14:31,480 --> 00:14:34,600 So obviously a big part of Sentinel is ingestion. 231 00:14:34,600 --> 00:14:38,160 And here we are to talk about data connectors and so on. 232 00:14:38,160 --> 00:14:43,440 So do you want to give an overview of what it means to ingest this data? 233 00:14:43,440 --> 00:14:44,360 What does that take? 234 00:14:44,360 --> 00:14:47,280 And what are these sort of prebuilt data connectors that we have? 235 00:14:47,280 --> 00:14:49,240 And why would people use them? 236 00:14:49,240 --> 00:14:53,480 Sentinel has 120 plus prebuilt connectors. 237 00:14:53,480 --> 00:14:58,320 These are ones that have already been set up to ingest data sources from either 238 00:14:58,320 --> 00:15:04,200 first party Microsoft solutions, third party solutions from a number of partners. 239 00:15:04,200 --> 00:15:08,360 We see things from other cloud services, from on-premises services, 240 00:15:08,360 --> 00:15:10,280 even generic data sources. 241 00:15:10,280 --> 00:15:15,360 So things along the lines of Syslog or things that are common event format or 242 00:15:15,360 --> 00:15:17,840 CIF format of data. 243 00:15:17,840 --> 00:15:20,080 All of those connectors are prebuilt. 244 00:15:20,080 --> 00:15:21,840 They're integrated inside of the system. 245 00:15:21,840 --> 00:15:25,120 You can just deploy them from inside of the portal and 246 00:15:25,120 --> 00:15:28,520 start bringing in data from all those different sources. 247 00:15:28,520 --> 00:15:33,000 Now data is of course the lifeblood of any SIM that's out there. 248 00:15:33,000 --> 00:15:37,680 So for anybody who doesn't know Sentinel is a SIM, it's a cloud based SIM. 249 00:15:37,680 --> 00:15:43,120 So we handle everything from the management of the servers, 250 00:15:43,120 --> 00:15:48,560 the clusters, data storage, maintaining that 90 days of rolling data that's part 251 00:15:48,560 --> 00:15:49,080 of the service. 252 00:15:49,080 --> 00:15:52,080 You can go up to about two years if you wanted to, but 253 00:15:52,080 --> 00:15:58,040 we give you 90 days right out of the box, as well as the prebuilt data connectors. 254 00:15:58,040 --> 00:15:59,720 So you can start bringing things in. 255 00:15:59,720 --> 00:16:05,160 These data connectors could be anything from events on your firewalls to events 256 00:16:05,160 --> 00:16:10,040 in your Azure Active Directory or something from your on-premises servers. 257 00:16:10,040 --> 00:16:12,720 And like I said, that's really the lifeblood of the system. 258 00:16:12,720 --> 00:16:16,680 It's all about getting those logs in, those events, and 259 00:16:16,680 --> 00:16:21,120 then being able to do hunting queries, analytics, leveraging things like machine 260 00:16:21,120 --> 00:16:24,560 learning models to find anomalous behavior. 261 00:16:24,560 --> 00:16:27,520 And then raising alerts and taking response actions after that. 262 00:16:27,520 --> 00:16:33,760 So Matt, how would a customer bring data from other products or 263 00:16:33,760 --> 00:16:40,080 even threat intelligence into Sentinel if they're not included in those prebuilt 264 00:16:40,080 --> 00:16:41,400 data connectors? 265 00:16:41,400 --> 00:16:43,400 If you're just looking to get in threat intelligence, 266 00:16:43,400 --> 00:16:46,560 actually there's a couple of ways that we can bring in that data. 267 00:16:46,560 --> 00:16:51,280 We actually have a prebuilt connector for sticks and taxi. 268 00:16:51,280 --> 00:16:56,920 So we can support a taxi feed of 2.1 and higher. 269 00:16:56,920 --> 00:17:01,080 And taxi, I just really wouldn't know, it's the threats. 270 00:17:01,080 --> 00:17:03,240 I can never remember what the acronym for taxi means, but 271 00:17:03,240 --> 00:17:07,920 it's the actual exchange of information between the systems. 272 00:17:07,920 --> 00:17:11,400 And sticks is the structured threat intelligence exchange. 273 00:17:11,400 --> 00:17:15,240 But the taxi protocol is the way that those different records of threat 274 00:17:15,240 --> 00:17:19,480 intelligence are exchanged, and we actually can accept a connection to 275 00:17:19,480 --> 00:17:22,280 a taxi server, bring in threat intelligence that way. 276 00:17:22,280 --> 00:17:24,960 You can also publish data on the graph. 277 00:17:24,960 --> 00:17:29,720 So if you're used to using graph.microsoft.com, you can put IOC's 278 00:17:29,720 --> 00:17:36,200 indicators of compromise onto the graph, and then those will be ingested into Sentinel. 279 00:17:36,200 --> 00:17:42,360 If, however, there is a data source that isn't an already prebuilt one, 280 00:17:42,360 --> 00:17:47,240 or you have another source of threat intelligence or 281 00:17:47,240 --> 00:17:50,360 some sort of enrichment data that you want to put into the environment, 282 00:17:50,360 --> 00:17:56,120 we do actually have a full API that you can leverage to pull data in from other sources. 283 00:17:56,120 --> 00:17:58,840 Or rather, I should say push data in from other sources. 284 00:17:58,840 --> 00:18:03,120 Leveraging that API, you can have a connection directly into the threat 285 00:18:03,120 --> 00:18:08,880 intelligence environment, or you can use the underlying log analytics workspace 286 00:18:08,880 --> 00:18:11,960 tables and push data directly into those. 287 00:18:11,960 --> 00:18:14,440 So you mentioned enrichment. 288 00:18:14,440 --> 00:18:18,240 This is actually a comment that Sarah has brought up in the past. 289 00:18:18,240 --> 00:18:22,160 I want to be honest with you, I'm not 100% sure what this enrichment stuff is. 290 00:18:22,160 --> 00:18:25,000 So could you just give us a brief overview of what you mean by 291 00:18:25,000 --> 00:18:28,520 enrichment and how that is different from any other kind of data? 292 00:18:28,520 --> 00:18:32,240 Let's think about the data that we're bringing into the environment. 293 00:18:32,240 --> 00:18:37,400 We are seeing, for example, let's take a number of events that are coming in from, 294 00:18:37,400 --> 00:18:39,520 say, servers, right? 295 00:18:39,520 --> 00:18:41,960 And we see data about all these different servers. 296 00:18:41,960 --> 00:18:45,760 That record may contain something along the lines of the server name, 297 00:18:45,760 --> 00:18:49,720 an IP address, maybe an event ID, if it's a Windows box, or 298 00:18:49,720 --> 00:18:53,880 that's something coming in from, say, Syslog, it could be a facility code, and 299 00:18:53,880 --> 00:18:55,640 maybe a severity that goes along with it. 300 00:18:55,640 --> 00:18:59,240 And then some additional data that's traveling along with it. 301 00:18:59,240 --> 00:19:04,920 Well, for somebody who doesn't know what those particular machines are, 302 00:19:04,920 --> 00:19:12,040 if I just hand you a machine that is called Server 01, that's not very helpful. 303 00:19:12,040 --> 00:19:14,680 It's a little ambiguous as to what that box could be. 304 00:19:14,680 --> 00:19:16,880 So what I might want to do is I might want to enrich some of the data that I 305 00:19:16,880 --> 00:19:17,600 have in the environment. 306 00:19:17,600 --> 00:19:21,600 Maybe I have a reference to what all those servers are. 307 00:19:21,600 --> 00:19:27,040 That might be a CMDV that I have somewhere outside of my environment, 308 00:19:27,040 --> 00:19:32,440 that I'm going to use to pull in maybe who owns the server. 309 00:19:32,440 --> 00:19:33,320 What is it doing? 310 00:19:33,320 --> 00:19:35,160 Where is it normally talking to? 311 00:19:36,280 --> 00:19:37,960 That could be one type of enrichment. 312 00:19:37,960 --> 00:19:41,120 Another type of enrichment data could be something about a user inside of the 313 00:19:41,120 --> 00:19:41,640 environment. 314 00:19:41,640 --> 00:19:45,200 Maybe it's additional data about that user's role, or 315 00:19:45,200 --> 00:19:49,000 maybe where they work or something along those lines. 316 00:19:49,000 --> 00:19:52,600 Or it could be data about really anything. 317 00:19:52,600 --> 00:19:56,880 As long as it's enriching my investigation, it's giving me a deeper insight, 318 00:19:56,880 --> 00:20:02,600 better views into the network at large, the environment at large, or 319 00:20:02,600 --> 00:20:06,240 maybe even just the threats that I'm seeing inside of my environment. 320 00:20:06,240 --> 00:20:10,720 It could come down all the way to adding in geographical information 321 00:20:10,720 --> 00:20:14,720 associated with IP addresses, which don't get me started on that one. 322 00:20:14,720 --> 00:20:16,680 I could talk about that for hours. 323 00:20:16,680 --> 00:20:20,080 But you might want to pull that sort of information in to say that, hey, 324 00:20:20,080 --> 00:20:23,520 this particular IP address is coming to me from a particular country. 325 00:20:23,520 --> 00:20:28,880 And I want to know that sort of information without my users having to go look it up. 326 00:20:28,880 --> 00:20:31,080 So I've actually been doing a little bit of work in that area just recently. 327 00:20:31,080 --> 00:20:35,520 I was trying to trigger Azure Key Vault, or more accurately, Microsoft Defender for 328 00:20:35,520 --> 00:20:41,800 Key Vault, into sort of making sure that everything worked by using a Tor endpoint 329 00:20:41,800 --> 00:20:45,880 to access a Key Vault, or at least attempt to access Key Vault, I should say. 330 00:20:45,880 --> 00:20:47,480 Would that be an example of enrichment? 331 00:20:47,480 --> 00:20:51,320 So for example, if I had some database or some lookup or some API or 332 00:20:51,320 --> 00:20:56,400 something that had a list of ongoing sort of Tor exit points, 333 00:20:56,400 --> 00:20:58,520 would that be an example of enrichment? 334 00:20:58,520 --> 00:20:59,320 Certainly could be. 335 00:20:59,320 --> 00:21:04,040 Yeah, it would be something where maybe you have getting back to like 336 00:21:04,040 --> 00:21:06,160 what Gladys is saying about threat intelligence. 337 00:21:06,160 --> 00:21:07,560 It's really any data. 338 00:21:07,560 --> 00:21:09,200 It could be threat intel. 339 00:21:09,200 --> 00:21:14,480 I mean, generally, threat intelligence is kind of limited towards people, 340 00:21:14,480 --> 00:21:17,320 normally limited towards things like indicators of compromise. 341 00:21:17,320 --> 00:21:21,440 In other words, something that is definitely bad, meaning that this IP 342 00:21:21,440 --> 00:21:25,640 address is related to the bad actor that's out there. 343 00:21:25,640 --> 00:21:30,960 Or this file hash is related to the malware that somebody may have seen somewhere. 344 00:21:32,080 --> 00:21:34,000 Other types of enrichment data could be exactly that. 345 00:21:34,000 --> 00:21:36,520 It could be those Tor endpoints that you know. 346 00:21:36,520 --> 00:21:42,480 And you might be saying, because they may not be bad in sort of the general parlance, 347 00:21:42,480 --> 00:21:44,640 but they're mostly of interest to you. 348 00:21:44,640 --> 00:21:48,880 You want to know where those particular IP endpoints might be, or 349 00:21:48,880 --> 00:21:51,160 what service they may be related to. 350 00:21:51,160 --> 00:21:52,600 And that's very similar. 351 00:21:52,600 --> 00:21:57,400 I mean, any sort of thing that you could bring into your environment that is of 352 00:21:57,400 --> 00:22:02,800 use to you, I would consider that to be an enrichment feed of data that's inside of there. 353 00:22:02,800 --> 00:22:05,640 I'm curious, for the enrichment data to work, 354 00:22:05,640 --> 00:22:09,440 does you have to actually copy or move the data into Sentinel? 355 00:22:09,440 --> 00:22:14,040 Or can it sort of do lookups in other databases? 356 00:22:14,040 --> 00:22:15,160 It depends. 357 00:22:15,160 --> 00:22:18,720 I always love giving that answer because it depends on what you want to really do. 358 00:22:18,720 --> 00:22:20,960 You can, of course, copy the data in. 359 00:22:20,960 --> 00:22:24,160 I personally think that that's one of the most efficient ways to do it, 360 00:22:24,160 --> 00:22:29,120 just because you can then take advantage of the scale that is behind Sentinel itself, 361 00:22:29,120 --> 00:22:31,440 in terms of speed, reliability, etc. 362 00:22:31,440 --> 00:22:35,280 You can, however, refer to data outside of Sentinel. 363 00:22:35,280 --> 00:22:39,000 It's actually a feature of the Kusto query language, or KQL. 364 00:22:39,000 --> 00:22:43,320 You have the ability to refer to data using a feature called external data. 365 00:22:43,320 --> 00:22:47,160 External data will allow you to refer to, say, 366 00:22:47,160 --> 00:22:51,320 a CSV file that you have inside of Azure Storage Blobs, 367 00:22:51,320 --> 00:22:55,000 or maybe of a JSON file that's somewhere else in another service, 368 00:22:55,000 --> 00:23:02,520 or maybe it's even an API that can respond back with the information in a data type format. 369 00:23:02,520 --> 00:23:06,600 You can use that external data function to refer to that data in place. 370 00:23:06,600 --> 00:23:08,360 Now, the nice thing about that is, 371 00:23:08,360 --> 00:23:11,600 if it's something that's being maintained externally, 372 00:23:11,600 --> 00:23:15,480 for example, we actually have some threat feed data 373 00:23:15,480 --> 00:23:18,840 that we actually have published inside of our GitHub repository, 374 00:23:18,840 --> 00:23:21,440 and we use the external data query to refer to it. 375 00:23:21,440 --> 00:23:24,280 That way, if it's being maintained outside of your environment, 376 00:23:24,280 --> 00:23:25,840 you can just go ahead and refer to it, 377 00:23:25,840 --> 00:23:28,280 get that information, utilize it at the time, 378 00:23:28,280 --> 00:23:31,360 and not ingest it into Sentinel itself. 379 00:23:31,360 --> 00:23:35,280 On the other hand, if you have data that you're maintaining, 380 00:23:35,280 --> 00:23:38,600 and you have the ability to pull it into Sentinel, 381 00:23:38,600 --> 00:23:40,280 I would say go ahead and do that. 382 00:23:40,280 --> 00:23:44,400 One example is I put together an Azure function, 383 00:23:44,400 --> 00:23:48,440 actually, and this is a great example of even how you can extend things out 384 00:23:48,440 --> 00:23:50,840 beyond the prebuilt connectors. 385 00:23:50,840 --> 00:23:55,200 I put together an Azure function that does a registration data access protocol query, 386 00:23:55,200 --> 00:23:57,360 or an Rdap query. 387 00:23:57,360 --> 00:24:02,360 Rdap, if you're not familiar with it, is the new version of Who Is. 388 00:24:02,360 --> 00:24:08,360 Who Is itself, venerable service inside of the internet, has been around forever, 389 00:24:08,360 --> 00:24:10,680 but was originally designed to be read by humans. 390 00:24:10,680 --> 00:24:14,840 If you do a Who Is lookup on a domain or you lookup an IP address, 391 00:24:14,840 --> 00:24:17,800 you get back information that's really, really easy for a human being to read, 392 00:24:17,800 --> 00:24:20,680 but not so easy for a machine to read. 393 00:24:20,680 --> 00:24:25,400 The Rdap query, actually, this new protocol that they have, replaces that, 394 00:24:25,400 --> 00:24:28,200 and it makes it so that you get a JSON notation, 395 00:24:28,200 --> 00:24:31,120 JavaScript object notation, or JSON file, 396 00:24:31,120 --> 00:24:35,360 as a response back for a domain that you're querying on. 397 00:24:35,360 --> 00:24:39,000 If I go and do a lookup on Microsoft.com, 398 00:24:39,000 --> 00:24:42,600 I can find out all the registration information about that domain. 399 00:24:42,600 --> 00:24:46,760 Where was it registered? Who owns it? When was it created? Et cetera. 400 00:24:46,760 --> 00:24:50,080 All that information is returned back to me as a JSON file 401 00:24:50,080 --> 00:24:54,440 that I can either use inside of my query, 402 00:24:54,440 --> 00:24:59,040 or the way that I've done it is I have it so that the system goes out in queries 403 00:24:59,040 --> 00:25:01,400 for every domain that I see in the environment, 404 00:25:01,400 --> 00:25:04,600 and then I have another analytical rule that's running in Sentinel 405 00:25:04,600 --> 00:25:08,320 because the Rdap query is taking it and pushing it back into Sentinel. 406 00:25:08,320 --> 00:25:10,800 I then run a regular analytics over it that says, 407 00:25:10,800 --> 00:25:14,840 hey, if I see a user has gone out to a domain 408 00:25:14,840 --> 00:25:17,920 that has been registered within the last 30 days, 409 00:25:17,920 --> 00:25:20,080 I want you to raise an alert for me. 410 00:25:20,080 --> 00:25:22,000 That's a newly registered domain. 411 00:25:22,000 --> 00:25:25,160 It's a little odd that somebody would be going to it that quickly, 412 00:25:25,160 --> 00:25:28,760 so I want you to actually just let me know that somebody's had that happen. 413 00:25:28,760 --> 00:25:30,720 There's nothing wrong, maybe, with the domain. 414 00:25:30,720 --> 00:25:35,480 It's not necessarily bad, so it doesn't actually qualify as an IOC, 415 00:25:35,480 --> 00:25:37,040 but it is something I want to look into. 416 00:25:37,040 --> 00:25:38,480 You mentioned something really interesting. 417 00:25:38,480 --> 00:25:39,480 I didn't know it existed. 418 00:25:39,480 --> 00:25:44,600 You said that you could call basically some code from KQL. 419 00:25:44,600 --> 00:25:46,680 Now, is that KQL that can do that, 420 00:25:46,680 --> 00:25:49,520 or is that something that's in Sentinel? 421 00:25:49,520 --> 00:25:53,000 And to what degree can you call something from KQL? 422 00:25:53,000 --> 00:25:54,680 So it's in KQL itself. 423 00:25:54,680 --> 00:25:57,320 It's not necessarily limited to just Sentinel, 424 00:25:57,320 --> 00:26:00,320 so you can actually use it from any log analytics workspace. 425 00:26:00,320 --> 00:26:01,920 It's part of the language. 426 00:26:01,920 --> 00:26:05,920 It's designed to refer to data storage, right? 427 00:26:05,920 --> 00:26:10,000 So you can use it to call out to an Azure blob. 428 00:26:10,000 --> 00:26:11,160 You could use an AWS blob. 429 00:26:11,160 --> 00:26:11,760 It could be Google. 430 00:26:11,760 --> 00:26:13,600 It doesn't really matter. 431 00:26:13,600 --> 00:26:19,200 If your API that you're calling is able to return the value 432 00:26:19,200 --> 00:26:22,560 in something that it can utilize, then you can call that. 433 00:26:22,560 --> 00:26:28,200 So there's an IP lookup, actually, that I use all the time, 434 00:26:28,200 --> 00:26:31,920 and it returns the values back as JSON notation. 435 00:26:31,920 --> 00:26:35,120 So what I can do is actually just call external data 436 00:26:35,120 --> 00:26:38,200 using what's called the let keyword. 437 00:26:38,200 --> 00:26:41,960 So I could say, let this value be equal to the return 438 00:26:41,960 --> 00:26:45,600 from this call out to this external source. 439 00:26:45,600 --> 00:26:48,520 Now, I do have to define what the data looks like. 440 00:26:48,520 --> 00:26:50,520 I can't just let it. 441 00:26:50,520 --> 00:26:52,560 It won't understand the data on the other side, 442 00:26:52,560 --> 00:26:55,200 so I do have to know something about the data. 443 00:26:55,200 --> 00:26:59,240 So if it's returning IP info, maybe I have a city, a country, 444 00:26:59,240 --> 00:27:01,600 an ASN, or something like that that's assigned to it. 445 00:27:01,600 --> 00:27:04,720 I have to pre-define that as part of the results. 446 00:27:04,720 --> 00:27:06,720 But as long as I can map those results back, 447 00:27:06,720 --> 00:27:09,160 it can then come into a data table that can then 448 00:27:09,160 --> 00:27:11,720 be used in line with my query. 449 00:27:11,720 --> 00:27:16,240 And that way, I don't have to store that information myself. 450 00:27:16,240 --> 00:27:18,800 Now, there is a drawback to it. 451 00:27:18,800 --> 00:27:23,200 That one drawback is it doesn't accept pipelines 452 00:27:23,200 --> 00:27:24,360 communications. 453 00:27:24,360 --> 00:27:26,880 So in other words, I have to basically be calling 454 00:27:26,880 --> 00:27:29,200 a static IP address. 455 00:27:29,200 --> 00:27:31,360 It can't be something that I can put together, 456 00:27:31,360 --> 00:27:34,800 can catnate a string inline inside of Custo. 457 00:27:34,800 --> 00:27:37,120 I'd actually have to go ahead and have that 458 00:27:37,120 --> 00:27:38,880 as a pre-defined string. 459 00:27:38,880 --> 00:27:41,160 That's not totally insurmountable. 460 00:27:41,160 --> 00:27:42,960 It's really great, again, if I'm calling out 461 00:27:42,960 --> 00:27:46,960 to a fixed storage file or something like that, 462 00:27:46,960 --> 00:27:49,200 because that's what it was originally designed for. 463 00:27:49,200 --> 00:27:50,560 On the other hand, if it's something 464 00:27:50,560 --> 00:27:54,440 that I'm calling out to some sort of a dynamic API, 465 00:27:54,440 --> 00:27:55,920 then it's really not the best case for it. 466 00:27:55,920 --> 00:27:59,040 It's really not the best case from just best practices anyway. 467 00:27:59,040 --> 00:28:01,720 You want to try and reduce those calls as much as possible. 468 00:28:01,720 --> 00:28:04,360 And that's another reason why bringing that data 469 00:28:04,360 --> 00:28:06,520 in the Sentinel can make sense, because we're actually 470 00:28:06,520 --> 00:28:09,320 keeping in line with those best practice recommendations. 471 00:28:09,320 --> 00:28:13,120 It seems that we keep bringing a lot of capabilities 472 00:28:13,120 --> 00:28:15,600 for enriching that data. 473 00:28:15,600 --> 00:28:19,280 Can you talk a little bit about CodeList Connector? 474 00:28:19,280 --> 00:28:20,640 CodeList Connector is great. 475 00:28:20,640 --> 00:28:22,440 That's the new functionality. 476 00:28:22,440 --> 00:28:23,880 It's in preview now. 477 00:28:23,880 --> 00:28:28,320 And what it allows you to do is to create a fully SASS-based 478 00:28:28,320 --> 00:28:32,040 Connector platform leveraging the capabilities that Sentinel 479 00:28:32,040 --> 00:28:33,160 has. 480 00:28:33,160 --> 00:28:35,600 So there's a number of different ways, like I said, 481 00:28:35,600 --> 00:28:37,200 that you can do a data connector. 482 00:28:37,200 --> 00:28:41,240 One could be that I could run it as a playbook inside of Sentinel. 483 00:28:41,240 --> 00:28:45,520 Playbooks are the automation or SOAR capability 484 00:28:45,520 --> 00:28:46,840 that are built into Sentinel. 485 00:28:46,840 --> 00:28:49,560 And they're built off of Azure Logic Apps. 486 00:28:49,560 --> 00:28:50,200 And they're great. 487 00:28:50,200 --> 00:28:52,360 They're very useful, very powerful. 488 00:28:52,360 --> 00:28:56,440 But you can also use those to not only take automated response 489 00:28:56,440 --> 00:28:58,200 actions, but you could use them actually 490 00:28:58,200 --> 00:29:01,760 to digest data from another source. 491 00:29:01,760 --> 00:29:05,240 You can also use Azure Functions, of course. 492 00:29:05,240 --> 00:29:09,080 Azure Functions are serverless compute that you can run. 493 00:29:09,080 --> 00:29:12,040 But the thing is that both of those actually require you 494 00:29:12,040 --> 00:29:14,960 to kind of put together some infrastructure in a way. 495 00:29:14,960 --> 00:29:16,960 I mean, like the Logic Apps require 496 00:29:16,960 --> 00:29:18,840 that you actually put together the playbook for it 497 00:29:18,840 --> 00:29:21,440 and put together the structure. 498 00:29:21,440 --> 00:29:26,280 Azure Function could be putting together the PowerShell script 499 00:29:26,280 --> 00:29:28,960 that you want to run or writing it in C-sharp 500 00:29:28,960 --> 00:29:32,560 or maybe it's in Perl or Python or something like that. 501 00:29:32,560 --> 00:29:33,160 Perl. 502 00:29:33,160 --> 00:29:33,920 That was weird. 503 00:29:33,920 --> 00:29:35,240 I don't know why I said Perl. 504 00:29:35,240 --> 00:29:38,160 But it's in Python. 505 00:29:38,160 --> 00:29:40,000 But what the new codeless connector allows you to do 506 00:29:40,000 --> 00:29:44,960 is you define what your service is using a JSON file again. 507 00:29:44,960 --> 00:29:48,000 And it becomes a fully codeless connector for it. 508 00:29:48,000 --> 00:29:49,560 You don't need to stand up anything. 509 00:29:49,560 --> 00:29:52,680 You tell us what the API is that you need to connect to. 510 00:29:52,680 --> 00:29:54,320 You give us the information about how 511 00:29:54,320 --> 00:29:58,400 you want to connect to it, meaning authentication, tokens, 512 00:29:58,400 --> 00:30:00,240 secret keys, et cetera. 513 00:30:00,240 --> 00:30:02,560 And the system can then go out, make that connection, 514 00:30:02,560 --> 00:30:05,360 and start bringing that data into Sentinel. 515 00:30:05,360 --> 00:30:08,320 What's really cool about it, too, is it doesn't only support 516 00:30:08,320 --> 00:30:09,480 bringing in the data. 517 00:30:09,480 --> 00:30:12,680 It actually supports the new health monitoring as well. 518 00:30:12,680 --> 00:30:14,560 So we can monitor the health of that connection 519 00:30:14,560 --> 00:30:17,480 to tell you if it's good, bad, if it's up or down. 520 00:30:17,480 --> 00:30:20,120 Really, really, really nice system. 521 00:30:20,120 --> 00:30:21,680 It's funny you should bring up Perl. 522 00:30:21,680 --> 00:30:23,600 I used to do a lot of Perl development back in the day 523 00:30:23,600 --> 00:30:25,600 before the days of PowerShell. 524 00:30:25,600 --> 00:30:29,440 I always used to joke that Perl is a right only language. 525 00:30:29,440 --> 00:30:32,720 Once you've written it, you can never understand what you 526 00:30:32,720 --> 00:30:34,040 actually wrote. 527 00:30:34,040 --> 00:30:35,520 I still got a bit of a soft spot for Perl, 528 00:30:35,520 --> 00:30:38,480 but yeah, I think PowerShell's taking 529 00:30:38,480 --> 00:30:39,680 that position in my life. 530 00:30:39,680 --> 00:30:44,160 I'd love to get your opinion on geography-based or geo-based 531 00:30:44,160 --> 00:30:46,240 IP filtering, because I've got some opinions here. 532 00:30:46,240 --> 00:30:48,720 But I want to hear your take on that one. 533 00:30:48,720 --> 00:30:53,080 Yeah, so basically, talking about GeoIP, 534 00:30:53,080 --> 00:30:56,920 it is sort of my personal issue. 535 00:30:56,920 --> 00:30:59,240 And it's not really that I have anything wrong with it. 536 00:30:59,240 --> 00:31:02,080 I think that it is a fine capability 537 00:31:02,080 --> 00:31:05,920 as long as people understand some 538 00:31:05,920 --> 00:31:08,400 of the potential limitations of it. 539 00:31:08,400 --> 00:31:10,080 And somebody can disagree with me. 540 00:31:10,080 --> 00:31:11,080 People always do. 541 00:31:11,080 --> 00:31:14,800 I'm more than happy to hear critiques about how I'm wrong. 542 00:31:14,800 --> 00:31:16,960 But the problem I have with it is 543 00:31:16,960 --> 00:31:19,520 that it comes down to a really fundamental question 544 00:31:19,520 --> 00:31:21,720 about GeoIP-based blocking. 545 00:31:21,720 --> 00:31:24,080 And that's really, what is an IP address? 546 00:31:24,080 --> 00:31:26,160 And then what is geographical data? 547 00:31:26,160 --> 00:31:30,080 And how are the two attached to each other? 548 00:31:30,080 --> 00:31:33,040 When you look at an IP address, it 549 00:31:33,040 --> 00:31:36,520 is completely fungible to sort of steal the term of the day. 550 00:31:36,520 --> 00:31:38,160 It is not a non-fungible token. 551 00:31:38,160 --> 00:31:38,760 It's fungible. 552 00:31:38,760 --> 00:31:41,880 You can replace an IP address with another IP address, 553 00:31:41,880 --> 00:31:46,560 because they are different things that are really just 554 00:31:46,560 --> 00:31:48,440 attached to the network for communications. 555 00:31:48,440 --> 00:31:49,960 And that's what they're there for. 556 00:31:49,960 --> 00:31:52,960 The geographic data, however, is fixed place and time. 557 00:31:52,960 --> 00:31:54,760 Or fixed place and time? 558 00:31:54,760 --> 00:31:55,120 Sure. 559 00:31:55,120 --> 00:31:56,400 Places are moving temporally. 560 00:31:56,400 --> 00:31:56,920 No. 561 00:31:56,920 --> 00:32:00,520 It's a fixed geographical location on the planet 562 00:32:00,520 --> 00:32:04,960 that is then to which the IP address is then tied. 563 00:32:04,960 --> 00:32:08,760 For some reason, people think that it's now non-fungible, 564 00:32:08,760 --> 00:32:12,120 that it's never going to change, that it could never be wrong. 565 00:32:12,120 --> 00:32:14,280 And that's not quite true. 566 00:32:14,280 --> 00:32:17,160 We have to look at the fact that when IP address information 567 00:32:17,160 --> 00:32:20,480 or when GeoIP data was first sort of put together, 568 00:32:20,480 --> 00:32:22,040 it all comes out of a database. 569 00:32:22,040 --> 00:32:24,880 So IP addresses are assigned by IANA. 570 00:32:24,880 --> 00:32:28,800 That's the International Association of Number Authority, 571 00:32:28,800 --> 00:32:30,480 something like that. 572 00:32:30,480 --> 00:32:35,400 And they have a database of all the different IP address 573 00:32:35,400 --> 00:32:37,240 blocks around the world. 574 00:32:37,240 --> 00:32:39,600 And those different IP address blocks 575 00:32:39,600 --> 00:32:42,560 have information, interestingly enough, inside of who 576 00:32:42,560 --> 00:32:45,560 is about to whom they've been assigned. 577 00:32:45,560 --> 00:32:48,240 And when we take that information, 578 00:32:48,240 --> 00:32:50,840 we can then discern at a certain level 579 00:32:50,840 --> 00:32:54,600 that this IP address, or at least this block of IP addresses, 580 00:32:54,600 --> 00:32:57,280 belongs to this country. 581 00:32:57,280 --> 00:32:59,680 Well, that's assuming that there's never 582 00:32:59,680 --> 00:33:04,200 a transfer of that IP address from either one 583 00:33:04,200 --> 00:33:06,920 of the regional authorities, because they're not all 584 00:33:06,920 --> 00:33:08,360 in one major place anymore. 585 00:33:08,360 --> 00:33:10,600 I mean, IANA used to be like one org. 586 00:33:10,600 --> 00:33:12,360 Now it's actually broken out into different groups 587 00:33:12,360 --> 00:33:13,080 around the world. 588 00:33:13,080 --> 00:33:14,880 There's Aaron here in the United States. 589 00:33:14,880 --> 00:33:16,760 There's RIPE in Europe. 590 00:33:16,760 --> 00:33:18,520 There's AFRNIC. 591 00:33:18,520 --> 00:33:22,560 There is APNIC for Asia Pacific, each one of which 592 00:33:22,560 --> 00:33:25,360 has different IP address blocks that have been assigned to them. 593 00:33:25,360 --> 00:33:28,640 And sometimes they actually do interregister our transfers, 594 00:33:28,640 --> 00:33:31,040 where there'll be a block of IP addresses that maybe was 595 00:33:31,040 --> 00:33:34,480 assigned to Japan at one point, and now it 596 00:33:34,480 --> 00:33:36,560 is assigned to the United States. 597 00:33:36,560 --> 00:33:38,880 During that transfer, well, the transfer 598 00:33:38,880 --> 00:33:40,360 doesn't really take much time. 599 00:33:40,360 --> 00:33:42,680 It's an IP address, once again. 600 00:33:42,680 --> 00:33:44,800 But the registration information might take time 601 00:33:44,800 --> 00:33:46,080 to change. 602 00:33:46,080 --> 00:33:48,560 Also, it's only at the country level. 603 00:33:48,560 --> 00:33:52,360 The individual registrars might have information about to whom 604 00:33:52,360 --> 00:33:56,440 they've assigned a block, and that may give you information 605 00:33:56,440 --> 00:33:58,640 about the city, or at least the city that's 606 00:33:58,640 --> 00:34:00,440 on the registration record. 607 00:34:00,440 --> 00:34:02,840 The further information about to whom 608 00:34:02,840 --> 00:34:04,960 it's been assigned inside of that country 609 00:34:04,960 --> 00:34:07,240 could be completely random at that point. 610 00:34:07,240 --> 00:34:11,600 It all depends on which ISP they were assigned to, 611 00:34:11,600 --> 00:34:13,560 or which registrar they were assigned to, 612 00:34:13,560 --> 00:34:16,280 and how accurate that detailed that data is. 613 00:34:16,280 --> 00:34:18,000 Now, that's how that all started, 614 00:34:18,000 --> 00:34:20,480 was people went out and they mined all this data out 615 00:34:20,480 --> 00:34:25,200 of the different registrars and used that as a basis of creating 616 00:34:25,200 --> 00:34:27,480 a lot of the GOIP databases. 617 00:34:27,480 --> 00:34:29,800 They've been augmented over the years 618 00:34:29,800 --> 00:34:32,120 by people doing things like war driving. 619 00:34:32,120 --> 00:34:35,920 War driving is going around with a Wi-Fi connection, 620 00:34:35,920 --> 00:34:39,200 and recording geographic information along with any 621 00:34:39,200 --> 00:34:42,400 of the networks that you see or can get connected to. 622 00:34:42,400 --> 00:34:45,640 And some of that has actually proven to be fairly useful. 623 00:34:45,640 --> 00:34:47,480 The only problem with that, though, 624 00:34:47,480 --> 00:34:50,120 is, again, it's only as good as the source data. 625 00:34:50,120 --> 00:34:52,200 If there's not a lot of source data to go with it, 626 00:34:52,200 --> 00:34:54,440 or if that source data is inaccurate, 627 00:34:54,440 --> 00:34:56,280 it's now somewhat questionable. 628 00:34:56,280 --> 00:34:59,720 And if you are getting back to my original point, 629 00:34:59,720 --> 00:35:03,400 if you're using this as a source of truth, 630 00:35:03,400 --> 00:35:08,400 well, the question there is it's about truthiness. 631 00:35:08,400 --> 00:35:12,840 It's truthful only as far as the source data is truthful. 632 00:35:12,840 --> 00:35:18,200 I've seen, for example, a lookup that I did on one IP address. 633 00:35:18,200 --> 00:35:19,840 It came out of a certain country, 634 00:35:19,840 --> 00:35:23,440 and that IP address, one of them had it in the capital 635 00:35:23,440 --> 00:35:24,960 of that country. 636 00:35:24,960 --> 00:35:29,400 And another source actually had it about 2,000 miles away 637 00:35:29,400 --> 00:35:31,200 from the capital of that country. 638 00:35:31,200 --> 00:35:35,000 And it's like, well, those are pretty far spaced pieces 639 00:35:35,000 --> 00:35:36,200 of information there. 640 00:35:36,200 --> 00:35:37,480 So if you're doing things, you know, 641 00:35:37,480 --> 00:35:40,360 or trying to do things down at that sort of tight geo level, 642 00:35:40,360 --> 00:35:41,880 it's going to be really, really difficult. 643 00:35:41,880 --> 00:35:44,320 If you try and do it at the country level, 644 00:35:44,320 --> 00:35:49,920 maybe you have a need to block something from perhaps, 645 00:35:49,920 --> 00:35:54,280 maybe it's an ITAR restricted country or an OFAC person 646 00:35:54,280 --> 00:35:57,080 who might be associated with a country or something like that, 647 00:35:57,080 --> 00:35:58,640 those might be useful. 648 00:35:58,640 --> 00:36:02,360 But it's only as good as the source data itself. 649 00:36:02,360 --> 00:36:04,320 And even there, there's some potential issues 650 00:36:04,320 --> 00:36:07,520 around things like IPv4 and IPv6. 651 00:36:07,520 --> 00:36:09,600 Yeah, like the way that I think about it, 652 00:36:09,600 --> 00:36:11,280 when there's always like one of these, you know, 653 00:36:11,280 --> 00:36:13,760 grand internet debates, I always fall back on sort 654 00:36:13,760 --> 00:36:18,480 of the cost of attack is, does it actually create cost 655 00:36:18,480 --> 00:36:20,440 or, you know, friction, pain in the butt, 656 00:36:20,440 --> 00:36:23,240 whatever you want to call it for the attacker, right? 657 00:36:23,240 --> 00:36:25,200 And if so, it has some value. 658 00:36:25,200 --> 00:36:29,800 And then the next question is, how hard is it or easy is it 659 00:36:29,800 --> 00:36:30,920 to do? 660 00:36:30,920 --> 00:36:33,400 And so, you know, so the way I think about it is like, 661 00:36:33,400 --> 00:36:36,440 okay, if I've, it's definitely gonna create a little bit 662 00:36:36,440 --> 00:36:38,480 of annoyance if you block a particular country 663 00:36:38,480 --> 00:36:40,840 and you expect adversaries from that country, 664 00:36:40,840 --> 00:36:43,520 or you expect you might get adversaries from that country. 665 00:36:43,520 --> 00:36:45,560 And if you absolutely know that, listen, 666 00:36:45,560 --> 00:36:48,600 we're a small regional bank, for example, 667 00:36:48,600 --> 00:36:52,040 we don't have people coming in from outside of, you know, 668 00:36:52,040 --> 00:36:53,920 the US or something like that. 669 00:36:53,920 --> 00:36:56,320 Okay, yeah, you can maybe put a detection on it 670 00:36:56,320 --> 00:36:59,440 or possibly a block, especially if you're getting a whole lot 671 00:36:59,440 --> 00:37:03,040 of noisy attacks from, you know, a given part of the world 672 00:37:03,040 --> 00:37:04,880 where you just don't do business. 673 00:37:04,880 --> 00:37:07,360 So like, I'm okay with like, if it's easy 674 00:37:07,360 --> 00:37:10,720 and it's not gonna break stuff, yeah, 675 00:37:10,720 --> 00:37:13,520 you're gonna add some friction. 676 00:37:13,520 --> 00:37:16,880 But like, would I bet my security posture 677 00:37:16,880 --> 00:37:18,880 and, you know, my critical crown jewels on it? 678 00:37:18,880 --> 00:37:19,720 Oh, no. 679 00:37:19,720 --> 00:37:20,560 Yeah, exactly. 680 00:37:20,560 --> 00:37:21,400 And that's kind of my point, right? 681 00:37:21,400 --> 00:37:24,680 Is that it's a, it comes down to that level of, 682 00:37:24,680 --> 00:37:27,960 I think the truthiness also leads to the level of comfort 683 00:37:27,960 --> 00:37:29,760 that goes along with the data. 684 00:37:29,760 --> 00:37:32,840 As you pointed out, if you're a small entity 685 00:37:32,840 --> 00:37:36,400 that never does business outside of a certain area, 686 00:37:36,400 --> 00:37:38,280 it is just easier just to go ahead and say, 687 00:37:38,280 --> 00:37:39,480 I'm gonna block all these things. 688 00:37:39,480 --> 00:37:41,120 They never should be there. 689 00:37:41,120 --> 00:37:44,240 Although I do have to ask sort of the, what if question 690 00:37:44,240 --> 00:37:47,440 of well, what if one of your customers just happens 691 00:37:47,440 --> 00:37:50,720 to be traveling in an area that you've blocked. 692 00:37:50,720 --> 00:37:52,800 Now we've completely disabled, you know, 693 00:37:52,800 --> 00:37:54,600 their capability to do business with us 694 00:37:54,600 --> 00:37:57,720 and we've made their life more inconvenient. 695 00:37:57,720 --> 00:38:02,720 If it's something of, you know, maybe I'm concerned about it 696 00:38:03,320 --> 00:38:05,440 from a data exfiltration standpoint, 697 00:38:05,440 --> 00:38:08,840 I don't want my data going to this other place. 698 00:38:08,840 --> 00:38:11,760 Well, from the point of putting a roadblock 699 00:38:11,760 --> 00:38:13,120 in front of the attacker, 700 00:38:13,120 --> 00:38:14,800 there are these things called VPNs. 701 00:38:14,800 --> 00:38:18,120 And people will use them to do things 702 00:38:18,120 --> 00:38:20,800 like get around all sorts of geo blocks. 703 00:38:20,800 --> 00:38:22,240 You know, if they're willing to do it to watch 704 00:38:22,240 --> 00:38:25,400 a television show or a movie in another country, 705 00:38:25,400 --> 00:38:27,280 I'm fairly certain that an attacker is willing 706 00:38:27,280 --> 00:38:29,920 to do the same thing to get your data 707 00:38:29,920 --> 00:38:32,320 and get out of the, you're blocking. 708 00:38:32,320 --> 00:38:35,760 What I would say makes more sense to me at least is, 709 00:38:35,760 --> 00:38:37,640 and this is sort of along the lines of, you know, 710 00:38:37,640 --> 00:38:41,640 endpoint security and assume breach is assume attack, right? 711 00:38:41,640 --> 00:38:44,640 Assume that anything that's going anywhere in the world 712 00:38:44,640 --> 00:38:47,000 is potentially a malicious actor 713 00:38:47,000 --> 00:38:49,520 who might be taking your stuff 714 00:38:49,520 --> 00:38:51,240 or might be trying to attack you. 715 00:38:51,240 --> 00:38:53,440 And if you see any sort of anomalous behavior, 716 00:38:53,440 --> 00:38:56,120 irrespective of where it is in the world, 717 00:38:56,120 --> 00:38:57,600 treat it as exactly that. 718 00:38:57,600 --> 00:38:58,880 It's anomalous behavior. 719 00:38:58,880 --> 00:39:02,240 It doesn't matter to me if it was from my own country, 720 00:39:02,240 --> 00:39:05,160 from, you know, another country, 721 00:39:05,160 --> 00:39:07,000 if it's from my neighbor next door, 722 00:39:07,000 --> 00:39:09,680 an anomaly is an anomaly is an anomaly. 723 00:39:09,680 --> 00:39:12,080 And I need to treat them all sort of the same way. 724 00:39:12,080 --> 00:39:15,480 When he talks about, you know, geo fencing and so on, 725 00:39:15,480 --> 00:39:18,800 the way I look at it is application security. 726 00:39:18,800 --> 00:39:20,000 You know, people often talk about, you know, 727 00:39:20,000 --> 00:39:21,720 security through obscurity. 728 00:39:21,720 --> 00:39:22,560 And I've heard people say, 729 00:39:22,560 --> 00:39:25,160 oh, you can't do security through obscurity. 730 00:39:25,160 --> 00:39:27,320 And I'm like, no, you actually can do security 731 00:39:27,320 --> 00:39:28,160 through obscurity. 732 00:39:28,160 --> 00:39:30,280 So long as it's not your only defense. 733 00:39:30,280 --> 00:39:31,680 And as long as you don't tell anybody. 734 00:39:31,680 --> 00:39:32,840 Yeah, that's a good point. 735 00:39:32,840 --> 00:39:34,120 But the point is when what we're doing here 736 00:39:34,120 --> 00:39:37,160 with this sort of geo IP isolation slash blocking 737 00:39:37,160 --> 00:39:39,320 slash fencing, whatever you want to call it, 738 00:39:39,320 --> 00:39:41,880 you know, it's okay just long as, you know, 739 00:39:41,880 --> 00:39:45,440 you're not betting the entire organization on, 740 00:39:45,440 --> 00:39:47,360 you know, on that one defense. 741 00:39:47,360 --> 00:39:49,560 Oh yeah, it's gotta be, it's gotta be layered. 742 00:39:49,560 --> 00:39:50,480 And correct me if I'm wrong here, 743 00:39:50,480 --> 00:39:51,960 but the way I look at it as you and Mark 744 00:39:51,960 --> 00:39:53,160 were talking about it, 745 00:39:53,160 --> 00:39:55,320 it sort of reminds me of an example 746 00:39:55,320 --> 00:39:58,280 of something that may be good enrichment data, right? 747 00:39:58,280 --> 00:40:01,400 It's not, it may help you make a decision, 748 00:40:01,400 --> 00:40:03,000 but it's not, you know, 749 00:40:03,000 --> 00:40:05,560 it's not like got a security guarantee around it. 750 00:40:05,560 --> 00:40:06,720 Yeah, exactly. 751 00:40:06,720 --> 00:40:07,720 Well, and that's the thing about, 752 00:40:07,720 --> 00:40:09,760 I think I mentioned this a little bit earlier, 753 00:40:09,760 --> 00:40:11,640 talking about like the databases and, you know, 754 00:40:11,640 --> 00:40:14,160 all the information, the geo data that's out there. 755 00:40:14,160 --> 00:40:15,560 There's one thing to consider here too, 756 00:40:15,560 --> 00:40:17,120 is that as time evolves, 757 00:40:17,120 --> 00:40:21,480 some of this data becomes less and less useful 758 00:40:21,480 --> 00:40:24,160 and less and less capable really, 759 00:40:24,160 --> 00:40:26,440 from a detection standpoint. 760 00:40:26,440 --> 00:40:30,600 What I mean by that is most of the geo IP data 761 00:40:30,600 --> 00:40:34,280 that's out there that folks are using is based on IPv4. 762 00:40:35,200 --> 00:40:38,640 So that's your standard, you know, octets of data, 763 00:40:38,640 --> 00:40:41,720 you know, so you're 182, 168, 1.1s. 764 00:40:41,720 --> 00:40:45,880 And what we are seeing now is that of course, 765 00:40:45,880 --> 00:40:49,600 because of the exhaustion of the IPv4 address space, 766 00:40:49,600 --> 00:40:52,360 we're moving everybody to IPv6. 767 00:40:52,360 --> 00:40:55,280 Well, that creates a little bit of a problem, 768 00:40:55,280 --> 00:40:57,160 because, well, if you think about it, 769 00:40:57,160 --> 00:40:58,600 just from a mathematical standpoint, 770 00:40:58,600 --> 00:41:00,960 IPv4 is two to the 32nd power, 771 00:41:00,960 --> 00:41:03,680 so about 4 billion addresses that are out there. 772 00:41:03,680 --> 00:41:06,160 4 billion is a huge number, it's a lot of stuff, 773 00:41:06,160 --> 00:41:08,440 but it's something that we can actually even think of 774 00:41:08,440 --> 00:41:10,320 mathematically in our heads as humans, 775 00:41:10,320 --> 00:41:14,400 and we can have a database that has 4 billion IP addresses 776 00:41:14,400 --> 00:41:16,900 in it and we can say that they belong to, you know, 777 00:41:16,900 --> 00:41:19,960 these particular groups or particular people. 778 00:41:19,960 --> 00:41:23,560 Now, when we start moving over to IPv6 though, 779 00:41:23,560 --> 00:41:26,000 we're talking two to the 128th, 780 00:41:26,000 --> 00:41:30,440 that's 340 undecillion IP addresses. 781 00:41:30,440 --> 00:41:34,240 That is a number that is so big that it takes about, 782 00:41:34,240 --> 00:41:39,240 I think it's five commas to get into the quadrillions 783 00:41:40,240 --> 00:41:41,880 or somewhere along those lines. 784 00:41:41,880 --> 00:41:44,600 I'm not a mathematician, so don't hold me to it. 785 00:41:44,600 --> 00:41:47,120 But the problem then becomes you've got this now massive 786 00:41:47,120 --> 00:41:49,160 database of information. 787 00:41:49,160 --> 00:41:50,720 Now, of course, it can be done the same way 788 00:41:50,720 --> 00:41:52,160 that an IPv4 database can be done. 789 00:41:52,160 --> 00:41:55,320 You can do it by, you know, octets and subnets 790 00:41:55,320 --> 00:41:59,280 and, you know, class A type, you know, information. 791 00:41:59,280 --> 00:42:01,120 That's still a lot of data. 792 00:42:01,120 --> 00:42:05,200 And in this modern world also where things are 793 00:42:05,200 --> 00:42:07,240 from an IP address standpoint, 794 00:42:07,240 --> 00:42:10,480 stuff isn't even fixed in a fixed place anymore. 795 00:42:10,480 --> 00:42:13,000 Mobile devices, mobile PCs, 796 00:42:13,000 --> 00:42:16,320 you've now got just this huge domain space 797 00:42:16,320 --> 00:42:18,240 that you've got to try and figure out. 798 00:42:18,240 --> 00:42:20,600 And I think it lends itself towards that, you know, 799 00:42:20,600 --> 00:42:22,720 you have to assume attack all the time and just say, 800 00:42:22,720 --> 00:42:24,920 look, I'm not gonna really care too much 801 00:42:24,920 --> 00:42:28,040 about the IP address that this is coming from. 802 00:42:28,040 --> 00:42:29,800 And instead, I'm just gonna treat it all 803 00:42:29,800 --> 00:42:32,920 as potentially suspicious or potential attacks. 804 00:42:32,920 --> 00:42:33,880 Yeah, when you look at it that way, 805 00:42:33,880 --> 00:42:35,360 I think what you just said is that, you know, 806 00:42:35,360 --> 00:42:37,920 we can have a database of four billion or so entries, 807 00:42:37,920 --> 00:42:40,720 but we can't have a database of a, 808 00:42:40,720 --> 00:42:42,880 whatever the number was, squintillion or something. 809 00:42:42,880 --> 00:42:44,480 340 undecillion. 810 00:42:44,480 --> 00:42:46,480 Okay, that too. 811 00:42:46,480 --> 00:42:47,480 You just can't do that, right? 812 00:42:47,480 --> 00:42:49,160 So it becomes totally unmanageable. 813 00:42:49,160 --> 00:42:51,280 That's a good point, yeah. 814 00:42:51,280 --> 00:42:53,520 So now one thing we always ask our guests is 815 00:42:53,520 --> 00:42:55,640 if you had one final thought you'd like 816 00:42:55,640 --> 00:42:58,400 to leave our listeners with, what would it be? 817 00:42:58,400 --> 00:43:01,040 So a final thought, I would say probably the biggest one 818 00:43:01,040 --> 00:43:05,320 would be don't forget the basics in security. 819 00:43:05,320 --> 00:43:09,520 By that, what I mean is it's not always going to be 820 00:43:09,520 --> 00:43:12,960 about the latest, greatest, finest security tool 821 00:43:12,960 --> 00:43:14,080 that you might see out there, 822 00:43:14,080 --> 00:43:18,000 or the flashiest thing that's out there. 823 00:43:18,000 --> 00:43:21,400 A lot of security comes down to still doing the basics, 824 00:43:21,400 --> 00:43:23,120 getting them right, operationalizing them, 825 00:43:23,120 --> 00:43:26,440 making them not just something that you do all the time 826 00:43:26,440 --> 00:43:29,080 or do every once in a while, but you do it all the time. 827 00:43:29,080 --> 00:43:31,200 Something that you actually internalize, 828 00:43:31,200 --> 00:43:35,040 good cyber hygiene, internalize good device 829 00:43:35,040 --> 00:43:38,120 and user and app security postures. 830 00:43:38,120 --> 00:43:42,040 And that it's not something that is easy to do. 831 00:43:42,040 --> 00:43:44,880 It's not something that you can necessarily flip a switch 832 00:43:44,880 --> 00:43:46,720 and make it suddenly happen, 833 00:43:46,720 --> 00:43:50,680 but it will pay for itself quite a bit 834 00:43:50,680 --> 00:43:53,760 by taking the little bit of extra effort to put those in. 835 00:43:53,760 --> 00:43:56,800 All right, with that, let's bring this episode to an end. 836 00:43:56,800 --> 00:43:59,200 Matt, thank you so much for joining us this week. 837 00:43:59,200 --> 00:44:03,480 I especially like your thoughts on geo-fencing 838 00:44:03,480 --> 00:44:06,560 and geographic restrictions based on IP addresses. 839 00:44:06,560 --> 00:44:07,880 So again, thank you so much for joining us 840 00:44:07,880 --> 00:44:09,200 and to our listeners out there. 841 00:44:09,200 --> 00:44:11,000 Thank you so much for joining us this week. 842 00:44:11,000 --> 00:44:13,200 Stay safe and we'll see you next time. 843 00:44:13,200 --> 00:44:16,080 Thanks for listening to the Azure Security Podcast. 844 00:44:16,080 --> 00:44:19,840 You can find show notes and other resources at our website, 845 00:44:19,840 --> 00:44:22,000 azsecuritypodcast.net. 846 00:44:22,880 --> 00:44:24,440 If you have any questions, 847 00:44:24,440 --> 00:44:26,760 please find us on Twitter at Azure SecPod. 848 00:44:27,640 --> 00:44:30,600 Background music is from ccmixter.com 849 00:44:30,600 --> 00:44:40,040 and licensed under the Creative Commons license.