1 00:00:00,000 --> 00:00:09,700 Welcome to the Azure Security Podcast, where we discuss topics relating to security, privacy, 2 00:00:09,700 --> 00:00:13,280 reliability and compliance on the Microsoft Cloud Platform. 3 00:00:13,280 --> 00:00:15,560 Hey, everybody. 4 00:00:15,560 --> 00:00:17,600 Welcome to episode 82. 5 00:00:17,600 --> 00:00:20,640 This week, it's myself, Michael and Mark. 6 00:00:20,640 --> 00:00:26,240 And this week, we have a guest, a security MVP, Truls, who's here to talk to us about 7 00:00:26,240 --> 00:00:31,640 all things related to security strategy, which I have no doubt Mark and Truls will have a 8 00:00:31,640 --> 00:00:32,640 fun time. 9 00:00:32,640 --> 00:00:36,160 But before we get to our guest, let's take a little lap around the news. 10 00:00:36,160 --> 00:00:38,880 Mark, why don't you kick things off? 11 00:00:38,880 --> 00:00:46,560 So the big news from my side is that the Zero Trust Commandments, which are now a standard, 12 00:00:46,560 --> 00:00:48,240 have been released. 13 00:00:48,240 --> 00:00:53,360 And so what this is, is it's actually a combination of the previous publication on the Zero Trust 14 00:00:53,360 --> 00:00:59,200 Commandments, as well as the Open Group's core principles for Zero Trust, and put together 15 00:00:59,200 --> 00:01:05,680 into a single guiding document and updated, refined, organized, cleaned up a little bit. 16 00:01:05,680 --> 00:01:10,680 And so this is a pretty big deal that we now have our first standard for Zero Trust, which 17 00:01:10,680 --> 00:01:13,040 I'm extremely excited about. 18 00:01:13,040 --> 00:01:15,480 Just for a little bit of context, I'm going to do a mini-speech here. 19 00:01:15,480 --> 00:01:19,720 When I think about what these things are, just to sort of put them in perspective, in 20 00:01:19,720 --> 00:01:24,200 the old days of security, there was a lot of people had a belief somewhere along the 21 00:01:24,200 --> 00:01:28,360 lines of, not exactly, if it doesn't have anything to do with the network perimeter, 22 00:01:28,360 --> 00:01:30,200 it's crap. 23 00:01:30,200 --> 00:01:36,760 So there was this deep, deep faith in the network perimeter keeping us safe, whether 24 00:01:36,760 --> 00:01:40,060 it was said out loud or it was just implied and understood. 25 00:01:40,060 --> 00:01:46,200 And so what happened was, what I see Zero Trust as, and the Open Group, Microsoft, and 26 00:01:46,200 --> 00:01:53,160 many others, is that essentially what's happening is when you kind of tear down that wall and 27 00:01:53,160 --> 00:01:57,920 that mindset of the perimeter can keep us safe, that's Zero Trust. 28 00:01:57,920 --> 00:02:01,080 That's, okay, let's go ahead and reinvent security the way we should have in the first 29 00:02:01,080 --> 00:02:06,160 place minus this one broken, flawed assumption that we can somehow keep a network and everything 30 00:02:06,160 --> 00:02:07,400 on it safe. 31 00:02:07,400 --> 00:02:12,880 And so it really sort of opened up the aperture, which was a good thing, but it also required 32 00:02:12,880 --> 00:02:17,680 us to sort of, the first thing you need to do is you need to bound that world because 33 00:02:17,680 --> 00:02:19,280 security isn't an infinite thing. 34 00:02:19,280 --> 00:02:20,960 It doesn't do everything magically. 35 00:02:20,960 --> 00:02:25,280 And so you need to have some rules that kind of define what this new definition, this new 36 00:02:25,280 --> 00:02:27,920 scope of security actually is and does. 37 00:02:27,920 --> 00:02:31,920 And so that's what we tried to do with the commandments and sort of, that's one of the 38 00:02:31,920 --> 00:02:37,480 reasons why we made that the, one of the first standards that we pushed through is to get 39 00:02:37,480 --> 00:02:39,320 that clear definition. 40 00:02:39,320 --> 00:02:41,520 And these aren't everything to do with security. 41 00:02:41,520 --> 00:02:42,920 There's going to be a lot more to come. 42 00:02:42,920 --> 00:02:47,360 There's guiding principles for architects of all types, security and otherwise. 43 00:02:47,360 --> 00:02:49,320 And then there's a reference model coming and all that. 44 00:02:49,320 --> 00:02:54,200 But what these do, these commandments do, is all of the things that elevate up to a 45 00:02:54,200 --> 00:03:00,500 must or a shall statement, the things that are absolute, hardcore, worthwhile boundaries 46 00:03:00,500 --> 00:03:06,840 to set, which of course took a whole lot of thought and debate and consideration and feedback 47 00:03:06,840 --> 00:03:07,840 from the first round. 48 00:03:07,840 --> 00:03:09,940 And of course, we're always open for more feedback. 49 00:03:09,940 --> 00:03:14,960 But these are the things that basically help provide that new kind of hard boundary of 50 00:03:14,960 --> 00:03:17,520 clarity, which is this is what security does. 51 00:03:17,520 --> 00:03:22,120 If you aren't doing this, or if you're doing something that violates this, you're doing 52 00:03:22,120 --> 00:03:23,240 it wrong. 53 00:03:23,240 --> 00:03:25,280 And so that's really what these commandments are. 54 00:03:25,280 --> 00:03:28,400 Really proud of this work, really looking forward to seeing people use them, getting 55 00:03:28,400 --> 00:03:31,720 feedback on them, continuously improving them as needed. 56 00:03:31,720 --> 00:03:33,840 Yeah, that's the big news there. 57 00:03:33,840 --> 00:03:39,160 And so I'll put a link in the show notes for the commandments themselves, as well as a 58 00:03:39,160 --> 00:03:42,800 post I put on with some commentary on it as well on LinkedIn. 59 00:03:42,800 --> 00:03:44,400 There's a couple of news items. 60 00:03:44,400 --> 00:03:47,100 The first one is around TLS. 61 00:03:47,100 --> 00:03:52,000 So we've now updated the default TLS policy for Azure Application Gateway. 62 00:03:52,000 --> 00:03:56,000 If you're not familiar, there are different predefined policies that start with like App 63 00:03:56,000 --> 00:03:57,640 Gateway SSL policy. 64 00:03:57,640 --> 00:03:59,640 I wish to change that to TLS, but anyway. 65 00:03:59,640 --> 00:04:05,040 Yeah, so it's like App Gateway SSL policy followed by a date, like a year, month, date. 66 00:04:05,040 --> 00:04:11,080 The latest default policy is 2022-01-01. 67 00:04:11,080 --> 00:04:17,560 And the minimum protocol policy is now TLS 1.2 and enables also TLS 1.3 as well. 68 00:04:17,560 --> 00:04:22,080 And also we've really restricted the Cypher suites to some of the sort of more modern 69 00:04:22,080 --> 00:04:26,600 versions like more use of Galois Counter Mode, for example, and some of the ones that use 70 00:04:26,600 --> 00:04:32,960 Cypher block chaining are still using, you know, SHA 384 or an AES 256 and so on. 71 00:04:32,960 --> 00:04:36,840 And one that was in there for a long time, and I'm glad to see that it was gone. 72 00:04:36,840 --> 00:04:40,720 It was there really for backward compatibility with some really, really old devices. 73 00:04:40,720 --> 00:04:42,960 Was one that was using triple DES. 74 00:04:42,960 --> 00:04:46,500 So I'm glad to see that that one has now finally fallen out of favor. 75 00:04:46,500 --> 00:04:52,560 The second item is in public preview, firmware analysis in Defender for IoT. 76 00:04:52,560 --> 00:04:53,560 This is actually pretty cool. 77 00:04:53,560 --> 00:04:55,320 I didn't even know we could even do this. 78 00:04:55,320 --> 00:05:02,560 We can actually take a binary firmware image from an IoT device and conduct automated analysis, 79 00:05:02,560 --> 00:05:05,800 looking for potential security vulnerabilities and weaknesses. 80 00:05:05,800 --> 00:05:07,440 This is actually really, really cool. 81 00:05:07,440 --> 00:05:10,000 I think this is pretty amazing to see that we can do this stuff. 82 00:05:10,000 --> 00:05:13,840 So Mark, one up for the Defender team. 83 00:05:13,840 --> 00:05:14,840 Absolutely. 84 00:05:14,840 --> 00:05:17,080 I love that feature. 85 00:05:17,080 --> 00:05:20,560 I've been waiting for a little while because I was actually, you know, part of managing 86 00:05:20,560 --> 00:05:24,360 the Defender for IoT business for a short period of time. 87 00:05:24,360 --> 00:05:26,360 And you know, I saw the ReFirm lab acquisition. 88 00:05:26,360 --> 00:05:29,320 I'm like, oh, I can't wait for engineering to bring this into the product because that's 89 00:05:29,320 --> 00:05:31,920 going to be awesome and start getting us proactive. 90 00:05:31,920 --> 00:05:32,920 Now we have the news out of the way. 91 00:05:32,920 --> 00:05:35,000 Let's turn our attention to our guest. 92 00:05:35,000 --> 00:05:40,520 This week we have Truls, who's a security MVP from Norway, who's here to talk to us 93 00:05:40,520 --> 00:05:45,760 about a blog post that he wrote earlier in the year called Field Notes on Security Strategy. 94 00:05:45,760 --> 00:05:48,040 And we can obviously take it any direction we want. 95 00:05:48,040 --> 00:05:49,320 Truls, welcome to the podcast. 96 00:05:49,320 --> 00:05:51,640 Thank you so much for joining us this week. 97 00:05:51,640 --> 00:05:54,720 Would you like to take a moment and introduce yourself to our listeners? 98 00:05:54,720 --> 00:05:55,720 Yeah. 99 00:05:55,720 --> 00:05:57,920 So as mentioned, my name is Truls. 100 00:05:57,920 --> 00:06:02,320 I'm a Microsoft MVP based out of Oslo, Norway. 101 00:06:02,320 --> 00:06:07,200 On my day-to-day, I work as a security architect slash engineer slash everything that needs 102 00:06:07,200 --> 00:06:08,200 to be done. 103 00:06:08,200 --> 00:06:12,320 I work in the company called Sopra Stereo in a security operation center. 104 00:06:12,320 --> 00:06:18,440 So it's mainly like MSSP focused, the work that I do, focus on security monitoring, automation 105 00:06:18,440 --> 00:06:19,760 and security tooling. 106 00:06:19,760 --> 00:06:24,880 And given the MVP status, it's mostly in the Microsoft stack. 107 00:06:24,880 --> 00:06:29,960 And as you mentioned, I'm very passionate about security monitoring strategy and security 108 00:06:29,960 --> 00:06:30,960 strategy. 109 00:06:30,960 --> 00:06:32,920 And that's why I wrote the blog post. 110 00:06:32,920 --> 00:06:35,320 Yeah, I really enjoyed reading your post. 111 00:06:35,320 --> 00:06:40,520 This is not just the memes and the choice of the memes, but very much enjoy the line 112 00:06:40,520 --> 00:06:41,520 of thinking. 113 00:06:41,520 --> 00:06:47,040 Do you want to maybe take a moment and talk a little bit about the post and what led you 114 00:06:47,040 --> 00:06:51,640 to write it and the key themes that you're emphasizing there? 115 00:06:51,640 --> 00:06:52,640 Yeah, sure. 116 00:06:52,640 --> 00:06:58,440 So to start with, I think the idea for the post was born with a lot of the, when you 117 00:06:58,440 --> 00:07:05,400 go around viewing different deployments, and this is mainly CM deployments of Sentinel, 118 00:07:05,400 --> 00:07:10,960 you see a lot of people, I think you said before, chasing a silver bullet where it's, 119 00:07:10,960 --> 00:07:18,600 we need every data connector, we need every single point of data, and we need all of the 120 00:07:18,600 --> 00:07:25,040 analytic rules, the default templates enabled, and you'll get the situation where a lot of 121 00:07:25,040 --> 00:07:30,040 people that work in security monitoring will be familiar with this, where you have what 122 00:07:30,040 --> 00:07:36,080 we define as alert fatigue, where you can only handle meaningfully like 50 alerts a 123 00:07:36,080 --> 00:07:39,680 day and you get 200 every hour. 124 00:07:39,680 --> 00:07:45,000 And so you're going to miss a lot of important alerts and you're just skating by on pure 125 00:07:45,000 --> 00:07:46,280 luck basically. 126 00:07:46,280 --> 00:07:51,760 We definitely see that a lot, especially in anything to do with security operations. 127 00:07:51,760 --> 00:07:56,760 I tend to call that one the collection is not detection dynamic. 128 00:07:56,760 --> 00:07:59,880 It's just that you need to be, I call it ruthless prioritization. 129 00:07:59,880 --> 00:08:05,760 Not only are human minds tuned towards scarcity and gathering and pack rat, kind of being 130 00:08:05,760 --> 00:08:07,320 a pack rat to bring more stuff in. 131 00:08:07,320 --> 00:08:12,140 That's sort of a natural human thing, but especially in security, when logs weren't 132 00:08:12,140 --> 00:08:17,480 turned on in the pre-cloud days and all sorts of stuff, we crave more information, more 133 00:08:17,480 --> 00:08:19,280 data, but there's a limit to that. 134 00:08:19,280 --> 00:08:23,360 At some point, there's too many books in the library and you need a librarian to curate 135 00:08:23,360 --> 00:08:24,360 it. 136 00:08:24,360 --> 00:08:28,040 So yeah, we see the exact same stuff. 137 00:08:28,040 --> 00:08:35,520 I think touching on that point, it's interesting in a sense that a lot of people still have 138 00:08:35,520 --> 00:08:41,360 this, I guess kind of backwards old school mentality of, oh, we need the firewall and 139 00:08:41,360 --> 00:08:43,440 the netflow logs. 140 00:08:43,440 --> 00:08:47,040 We need all of these in the CM, we need detection on it. 141 00:08:47,040 --> 00:08:54,120 But given today's state of the infrastructure and the perimeters you work with, the network 142 00:08:54,120 --> 00:08:59,380 is no longer the main perimeter for most companies, it's identities. 143 00:08:59,380 --> 00:09:05,080 So it doesn't make any sense to put that big of an emphasis on the same kind of logs that 144 00:09:05,080 --> 00:09:08,160 we used to emphasize like 10, 15 years ago. 145 00:09:08,160 --> 00:09:14,400 I think that's another thing that really bothered me was that we would see a lot of focus on 146 00:09:14,400 --> 00:09:20,080 these infrastructure heavy logs and not as much focus on just getting a good value first 147 00:09:20,080 --> 00:09:22,720 and foremost out of the identity based logs. 148 00:09:22,720 --> 00:09:27,320 So that was also like a big motivator for getting the thoughts out of my head and onto 149 00:09:27,320 --> 00:09:31,400 the page to sort of like explain where I was at with that. 150 00:09:31,400 --> 00:09:36,720 Yeah, it's almost, I don't know, the analogy that pops into my mind is like, we used to 151 00:09:36,720 --> 00:09:39,560 have one mine with gold in it. 152 00:09:39,560 --> 00:09:42,760 And so we basically set up a perimeter around it and defended it. 153 00:09:42,760 --> 00:09:46,440 Well, we found gold everywhere, you know, where all the organization's data and valuable 154 00:09:46,440 --> 00:09:49,160 assets are and they're everywhere else. 155 00:09:49,160 --> 00:09:53,040 And why do we still have all of our guards around the mine when all this stuff is out 156 00:09:53,040 --> 00:09:54,120 there? 157 00:09:54,120 --> 00:09:55,640 That's not the right intercept point. 158 00:09:55,640 --> 00:10:02,000 I've used to talk about this where I visualize an organization in the olden days or the olden 159 00:10:02,000 --> 00:10:07,520 days makes me feel old, but like a village with a fence around it. 160 00:10:07,520 --> 00:10:11,600 And you have like the firewall where all the traffic goes in and out. 161 00:10:11,600 --> 00:10:14,760 It's like the port and you have a guard there. 162 00:10:14,760 --> 00:10:17,400 And some people might have guards posted on the fence. 163 00:10:17,400 --> 00:10:22,800 I think there's an old like adage or something where they say if you build 15 meter tall 164 00:10:22,800 --> 00:10:26,540 walls, you're just opening a market for 16 meter tall ladders. 165 00:10:26,540 --> 00:10:33,400 But the idea is that before security monitoring, if you even had security monitoring, the logs 166 00:10:33,400 --> 00:10:37,800 you would be gathering were like firewall ingress and egress logs because that made 167 00:10:37,800 --> 00:10:38,800 sense, right? 168 00:10:38,800 --> 00:10:41,600 It's the shaft down to the gold mine, as you said. 169 00:10:41,600 --> 00:10:47,240 So now that we moved away from that and people can access via like proxies and stuff like 170 00:10:47,240 --> 00:10:51,020 that and SharePoint on their phones. 171 00:10:51,020 --> 00:10:57,200 And you can work from home office, you can work from, I don't know, Bermuda if you wanted 172 00:10:57,200 --> 00:11:02,120 to write and still have like decent access to things like mail and SharePoint and stuff. 173 00:11:02,120 --> 00:11:04,800 So it doesn't make sense. 174 00:11:04,800 --> 00:11:09,000 So I guess in that sense, the point I was also trying to make in a post is that not 175 00:11:09,000 --> 00:11:13,520 all log sources are created equal because you need to prioritize them. 176 00:11:13,520 --> 00:11:21,000 And people put too much emphasis on gathering all the logs and then enabling default detectives. 177 00:11:21,000 --> 00:11:23,240 And that's enough. 178 00:11:23,240 --> 00:11:28,400 But I think that's not the right way to work when you're designing like a security strategy 179 00:11:28,400 --> 00:11:30,440 for how you want to monitor your stuff. 180 00:11:30,440 --> 00:11:34,360 The way I look at it is you just have to look at it from an outcome basis. 181 00:11:34,360 --> 00:11:39,720 And we have to ask the question that quite often wasn't asked at the beginning of security 182 00:11:39,720 --> 00:11:46,320 operations as it sort of was emerging as sort of an offshoot of IT operations or of network 183 00:11:46,320 --> 00:11:50,800 operations or wherever it happened to originate within an organization. 184 00:11:50,800 --> 00:11:53,400 We have to ask, why are we doing this? 185 00:11:53,400 --> 00:11:54,400 What is the purpose? 186 00:11:54,400 --> 00:11:55,800 What is the outcome? 187 00:11:55,800 --> 00:11:59,960 And not just the technical outcome, like, oh, we have to handle these alerts. 188 00:11:59,960 --> 00:12:00,960 Why? 189 00:12:00,960 --> 00:12:05,040 You know, kind of do that, what do they call it, the five whys or whatever that Ishikawa 190 00:12:05,040 --> 00:12:06,040 diagram or something. 191 00:12:06,040 --> 00:12:11,680 Sorry, I was part of a Six Sigma project a long time ago when I picked up some terminology. 192 00:12:11,680 --> 00:12:12,680 But like, what is the outcome? 193 00:12:12,680 --> 00:12:14,000 What are we actually trying to do? 194 00:12:14,000 --> 00:12:20,720 And it's you're trying to protect the business from attackers having access to your stuff. 195 00:12:20,720 --> 00:12:27,120 And that's a better North Star than we got to take care of these alerts, right? 196 00:12:27,120 --> 00:12:30,280 Because that then guides you to, okay, what kind of alerts do we need to look at? 197 00:12:30,280 --> 00:12:35,880 Because like you said, we have 200 an hour, we can handle 50 a day. 198 00:12:35,880 --> 00:12:37,160 Which ones do we investigate? 199 00:12:37,160 --> 00:12:38,780 Which ones are worth it? 200 00:12:38,780 --> 00:12:41,640 Because it's all about that, you know, ruthlessly prioritize. 201 00:12:41,640 --> 00:12:43,200 And you know, what do we need to do? 202 00:12:43,200 --> 00:12:49,620 That's the most likely to cause damage to the business to be an attacker that has access 203 00:12:49,620 --> 00:12:50,620 to the goodies. 204 00:12:50,620 --> 00:12:55,200 And it's really interesting because I've read some of your posts on the topics as well, 205 00:12:55,200 --> 00:13:01,520 especially relating to when you talk about security tooling and talking about what security 206 00:13:01,520 --> 00:13:05,200 tool do we need to bring in to solve this issue, which is not the right question, as 207 00:13:05,200 --> 00:13:06,200 you've pointed out. 208 00:13:06,200 --> 00:13:10,320 So it's, I think it's interesting to hear your thoughts on the things I've been sort 209 00:13:10,320 --> 00:13:14,360 of like turning around in my brain for a while, because it's, as I mentioned at the end of 210 00:13:14,360 --> 00:13:18,080 the blog post, it's what I'm writing isn't gospel. 211 00:13:18,080 --> 00:13:20,720 It's not like 100% correct for everyone. 212 00:13:20,720 --> 00:13:25,920 So you need to, the biggest thing you need to take away from it is that you should question 213 00:13:25,920 --> 00:13:29,480 your strategy and you should create your own strategy. 214 00:13:29,480 --> 00:13:34,680 You can't follow one-on-one guides on how to set up security monitoring because it's 215 00:13:34,680 --> 00:13:40,200 not going to be like, it's not going to be a one size fits all kind of thing. 216 00:13:40,200 --> 00:13:43,500 Good example of that is we have two different customers. 217 00:13:43,500 --> 00:13:48,880 One of the customers, they do RDP nesting as like a normal thing for them. 218 00:13:48,880 --> 00:13:54,280 So they RDP into one server and then they RDP from that server onto another server. 219 00:13:54,280 --> 00:13:59,040 Now for most of our customers, this would be a sign of someone is trying to pivot from 220 00:13:59,040 --> 00:14:03,080 one server to another, and this is shady business. 221 00:14:03,080 --> 00:14:06,680 But for this particular customer, this is a normal usage pattern. 222 00:14:06,680 --> 00:14:12,880 So a detection that shows RDP nesting would be not very good for that customer because 223 00:14:12,880 --> 00:14:15,760 it would be like almost only false positives. 224 00:14:15,760 --> 00:14:22,520 So we need to take a step back and do like proper use case design for every single customer, 225 00:14:22,520 --> 00:14:25,040 every single thing you want to monitor. 226 00:14:25,040 --> 00:14:32,840 And as you mentioned previously that it's not about necessarily starting with like tooling 227 00:14:32,840 --> 00:14:35,820 and stuff like that, but it's about finding the north star. 228 00:14:35,820 --> 00:14:38,680 Like what are the things that I want to protect? 229 00:14:38,680 --> 00:14:40,160 Like what is most important? 230 00:14:40,160 --> 00:14:45,720 And then also looking at what kind of business am I in? 231 00:14:45,720 --> 00:14:48,880 What type of threat actors will try to target me? 232 00:14:48,880 --> 00:14:52,500 What are the most likely scenarios based on those threat actors? 233 00:14:52,500 --> 00:14:58,080 What are the most likely scenarios based on the users that I have and the level of security 234 00:14:58,080 --> 00:15:00,400 knowledge in the company as a whole? 235 00:15:00,400 --> 00:15:06,960 So it's more to do with knowing yourself and then designing the security strategy on that 236 00:15:06,960 --> 00:15:11,400 basis instead of just working from tooling. 237 00:15:11,400 --> 00:15:13,400 Yeah, I love that theme. 238 00:15:13,400 --> 00:15:19,400 Like I actually was helping out with a new unified offering, basically a repeatable engagement 239 00:15:19,400 --> 00:15:20,400 that we do. 240 00:15:20,400 --> 00:15:24,280 The Microsoft Unified support, formerly Premiere for those that have been around as long as 241 00:15:24,280 --> 00:15:25,280 I have. 242 00:15:25,280 --> 00:15:31,400 It's on Sentinel adoption and essentially helping people start off as a migration thing. 243 00:15:31,400 --> 00:15:35,200 But we decided to reframe it as an adoption one because it's like, we're not just going 244 00:15:35,200 --> 00:15:40,880 to go ahead and rerun a rule and take whatever Splunk or ArcSight or whatever queries that 245 00:15:40,880 --> 00:15:42,600 you've got. 246 00:15:42,600 --> 00:15:45,040 Let's make sure there's use cases in there. 247 00:15:45,040 --> 00:15:50,000 Let's make sure we're thinking through that because you have to be able to express those 248 00:15:50,000 --> 00:15:55,240 risks in a way that you can technically implement across different platforms. 249 00:15:55,240 --> 00:15:58,960 Because like one of the things that we see a lot of folks that have never worked with 250 00:15:58,960 --> 00:16:04,520 an XDR, for example, there's so many common attacks that you can detect that pretty much 251 00:16:04,520 --> 00:16:06,440 look the same everywhere. 252 00:16:06,440 --> 00:16:07,440 That's your basis. 253 00:16:07,440 --> 00:16:09,300 That's your baseline. 254 00:16:09,300 --> 00:16:15,840 When you get into, okay, once you have those in place, what are you looking for in a custom 255 00:16:15,840 --> 00:16:21,500 query based tool like a Sentinel or what have you that allows you to do custom scenarios 256 00:16:21,500 --> 00:16:22,500 and use cases? 257 00:16:22,500 --> 00:16:27,440 One, you got to be thinking in terms of use cases so you can actually have a common language 258 00:16:27,440 --> 00:16:31,520 because an XDR doesn't work in the same exact query way that a SIM does. 259 00:16:31,520 --> 00:16:34,500 You need a common language across those, but you need to be able to say which ones are 260 00:16:34,500 --> 00:16:39,040 we have covered here so we don't end up writing a bunch of duplicate queries. 261 00:16:39,040 --> 00:16:44,640 The time and effort that we spend to the point you're making is actually on, hey, this is 262 00:16:44,640 --> 00:16:46,920 unique to our organization. 263 00:16:46,920 --> 00:16:51,160 This would always be a false positive, but we also do this. 264 00:16:51,160 --> 00:16:55,280 If the attackers go with the standard thing, that's going to stick out like a sore thumb 265 00:16:55,280 --> 00:16:58,000 if we're looking for it. 266 00:16:58,000 --> 00:17:02,760 How do we write use cases that are custom tailored to our environment for things that 267 00:17:02,760 --> 00:17:08,080 the adversary could not know or would not know and they're going to basically just find 268 00:17:08,080 --> 00:17:12,880 themselves standing out in the middle of a main street going, oh, I thought it was an 269 00:17:12,880 --> 00:17:13,880 alley. 270 00:17:13,880 --> 00:17:16,080 Yeah, completely agree with that. 271 00:17:16,080 --> 00:17:21,800 I love the sort of starting with knowing your infrastructure as well as the threats and 272 00:17:21,800 --> 00:17:25,760 all these other things because you're defending the environment you've got. 273 00:17:25,760 --> 00:17:26,760 Yeah. 274 00:17:26,760 --> 00:17:31,040 I think it's, as you said, the ruthless prioritization thing. 275 00:17:31,040 --> 00:17:38,520 I think it goes for when you're setting up your CM and integrating with Next.dr as well. 276 00:17:38,520 --> 00:17:42,680 It's about prioritizing after you sort of figured out, okay, what's the most important 277 00:17:42,680 --> 00:17:43,680 parts of this? 278 00:17:43,680 --> 00:17:50,520 Let's say, ah, I need to monitor my sign-in logs, my audit logs, my Azure activity logs, 279 00:17:50,520 --> 00:17:52,720 just as an example. 280 00:17:52,720 --> 00:17:57,040 You've identified what you want to protect and then you identify the log sources you 281 00:17:57,040 --> 00:18:02,840 would need and then you can start working on seeing what your user's patterns in those 282 00:18:02,840 --> 00:18:07,240 logs are, what's the baseline and start working on, as you said, the use cases. 283 00:18:07,240 --> 00:18:13,600 Because I think one thing that a lot of people do wrong and not just enabling templates and 284 00:18:13,600 --> 00:18:18,880 then just saying, oh, now we have detection for this thing, but just because you have 285 00:18:18,880 --> 00:18:24,700 an alert doesn't mean you're being a good SOC or MSSP or security team just because 286 00:18:24,700 --> 00:18:26,200 you surfaced an alert. 287 00:18:26,200 --> 00:18:31,640 If most of the alerts you get are false positives, you're doing a very bad job, in my opinion. 288 00:18:31,640 --> 00:18:35,320 Because an alert isn't necessarily actionable. 289 00:18:35,320 --> 00:18:39,940 So it needs to have some level of what do I do when this alert surfaces? 290 00:18:39,940 --> 00:18:42,600 What's the point of making this alert surface? 291 00:18:42,600 --> 00:18:45,880 So we need to have a reason for it, at least in my mind. 292 00:18:45,880 --> 00:18:50,800 So that's where the use case development comes into play, where you would say, ah, we want 293 00:18:50,800 --> 00:18:55,360 to look for these kind of patterns and why do we need to look for them? 294 00:18:55,360 --> 00:18:56,840 OK, this is the reason. 295 00:18:56,840 --> 00:19:00,680 And then what do we do once this emerges? 296 00:19:00,680 --> 00:19:07,480 So a bad use case would be like password spraying against Azure AD identity because we have 297 00:19:07,480 --> 00:19:09,400 multi-factor enabled, right? 298 00:19:09,400 --> 00:19:11,560 It should have, at least. 299 00:19:11,560 --> 00:19:16,680 And then I think what do you do if you get an alert someone's trying to brute force? 300 00:19:16,680 --> 00:19:23,080 Well, I can maybe check that this user hasn't been a part of any leaks, but that's like 301 00:19:23,080 --> 00:19:28,480 the extent of what I can do unless there's someone actually gaining access. 302 00:19:28,480 --> 00:19:30,280 I can't do anything about that. 303 00:19:30,280 --> 00:19:34,040 So it's pointless to have as an actionable alert. 304 00:19:34,040 --> 00:19:36,560 Maybe you want to have an informational alert to see what's going on. 305 00:19:36,560 --> 00:19:41,640 But it's very important that your use case is in the alerts you generate. 306 00:19:41,640 --> 00:19:47,200 No matter where it's at, if it's the CM or the XDR, they need to be actionable. 307 00:19:47,200 --> 00:19:52,560 At least in my mind, that's very important part of a good security monitoring strategy. 308 00:19:52,560 --> 00:19:54,520 Yeah, 100% agree. 309 00:19:54,520 --> 00:20:00,160 Like a couple things that we emphasize in our workshops that I do a lot of development 310 00:20:00,160 --> 00:20:04,960 on is it's got to be incident-centric, not alert-centric, right? 311 00:20:04,960 --> 00:20:09,160 So that you're looking at this through the lens of not just, hey, this thing came up 312 00:20:09,160 --> 00:20:12,720 and it's a password sprayer, or whatever it happens to be, which was hopefully blocked 313 00:20:12,720 --> 00:20:14,480 as you point out. 314 00:20:14,480 --> 00:20:17,420 But this thing came up, is it part of something else? 315 00:20:17,420 --> 00:20:22,440 Because the adversary may trip for alarms in the process of stumbling through the house 316 00:20:22,440 --> 00:20:24,480 trying to find the safe, right? 317 00:20:24,480 --> 00:20:27,320 And so you've got to be thinking of it holistically. 318 00:20:27,320 --> 00:20:36,500 And is this one snapshot of the unicorn's tail something that we need to correlate to 319 00:20:36,500 --> 00:20:40,520 the horn and the hoofs and everything else that we've got for sensors? 320 00:20:40,520 --> 00:20:46,160 And so having that incident-centric mindset we found is definitely super important. 321 00:20:46,160 --> 00:20:50,280 And then the other thing that you reminded me of is the other benefit of use cases is 322 00:20:50,280 --> 00:20:54,560 if you can express this in a simple use case, here's the threat, this, that, and the other, 323 00:20:54,560 --> 00:20:57,560 you can then look and say, hey, is this something we already prevented? 324 00:20:57,560 --> 00:20:58,800 Is this something we could prevent? 325 00:20:58,800 --> 00:21:02,600 Because the last thing you want to be doing is have your sock chase down 100 incidents 326 00:21:02,600 --> 00:21:06,800 a month that you could have just blocked with MFA, right? 327 00:21:06,800 --> 00:21:12,000 The whole point of the sock is to apply that precious resource of those few humans that 328 00:21:12,000 --> 00:21:17,240 you're able to get and train and spend time on and whose brains burn out if you give them 329 00:21:17,240 --> 00:21:19,280 too much stuff, right? 330 00:21:19,280 --> 00:21:22,200 Let's make sure we're protecting them against garbage. 331 00:21:22,200 --> 00:21:23,880 Let's not give them a false positive. 332 00:21:23,880 --> 00:21:26,840 Let's not give them something we could have blocked. 333 00:21:26,840 --> 00:21:29,720 Let's not give them a garbage alert when we could give them a high quality actionable 334 00:21:29,720 --> 00:21:35,520 alert because you have a very finite set of people at the end of the line and you need 335 00:21:35,520 --> 00:21:40,240 to clean up that pipeline and filter out the garbage before it gets to the point where 336 00:21:40,240 --> 00:21:43,120 you actually need a human to pull out a weapon and do something. 337 00:21:43,120 --> 00:21:46,440 Yeah, that's a very good point. 338 00:21:46,440 --> 00:21:52,440 It's funny you mention it because I'm working on a presentation and a blog post right now 339 00:21:52,440 --> 00:21:59,560 about that exact topic about security automation because one thing is the strategy behind it 340 00:21:59,560 --> 00:22:04,640 and the use case development and the data you ingest, which is like, I guess it's a 341 00:22:04,640 --> 00:22:05,880 very big part of it. 342 00:22:05,880 --> 00:22:10,880 But at the same time, as you said, you need some alerts to be informational low to paint 343 00:22:10,880 --> 00:22:13,720 like the part of the picture of the unicorn you're chasing. 344 00:22:13,720 --> 00:22:18,600 So you need some way at least to correlate that data. 345 00:22:18,600 --> 00:22:25,120 And sometimes if a security analyst has to every single time go into virus total and 346 00:22:25,120 --> 00:22:29,280 copy and paste something, they have to do like cross reference searches. 347 00:22:29,280 --> 00:22:33,480 They have to do enrichment that could be done automatically. 348 00:22:33,480 --> 00:22:36,520 It's a waste of time. 349 00:22:36,520 --> 00:22:42,920 And so security automation as well plays a big part in, I think, fighting against alert 350 00:22:42,920 --> 00:22:48,560 fatigue and just making sure that, as you said, the precious finite minutes of human 351 00:22:48,560 --> 00:22:54,000 brainpower can be used to actually do something that requires human brainpower and isn't just 352 00:22:54,000 --> 00:22:59,400 something where you sit and do the exact same thing, just copy and paste and do repeatable 353 00:22:59,400 --> 00:23:01,000 tasks that could be automated. 354 00:23:01,000 --> 00:23:02,960 So that's a very good point. 355 00:23:02,960 --> 00:23:08,360 It kind of calls up the power of the NIST cybersecurity framework, you know, the life 356 00:23:08,360 --> 00:23:13,640 cycle of identify, protect, attack, respond, recover, and soon to be governed if they accept 357 00:23:13,640 --> 00:23:17,760 the proposals of the V2, that's the draft that's out. 358 00:23:17,760 --> 00:23:22,600 And I mean, honestly, I think the original point of the NIST one was because we had a 359 00:23:22,600 --> 00:23:27,400 very prevention-centric mindset in the industry at the time, was to sort of open up the life 360 00:23:27,400 --> 00:23:31,840 cycle so people were thinking holistically, including the back end of it, respond, recover. 361 00:23:31,840 --> 00:23:37,320 But I feel like the pendulum has swung over, especially for folks that work in security 362 00:23:37,320 --> 00:23:39,440 systems, they're only thinking in terms of respond and recover. 363 00:23:39,440 --> 00:23:45,440 And it's like, y'all, you need to be talking to your architect and engineering and operations 364 00:23:45,440 --> 00:23:51,120 counterparts in IT and in security, because the last thing you want to be doing is chasing 365 00:23:51,120 --> 00:23:55,160 the same incident that could have been prevented 100 times over. 366 00:23:55,160 --> 00:23:58,640 So it's sort of like, it's a reminder, but now in the other direction. 367 00:23:58,640 --> 00:23:59,640 Yeah, exactly. 368 00:23:59,640 --> 00:24:06,760 So, Trulls, do you, when you're sort of talking to customers, do many of them use industry 369 00:24:06,760 --> 00:24:10,000 standard set of frameworks or controls? 370 00:24:10,000 --> 00:24:17,200 So for example, one thing that we use a lot is NIST SP800-53, a whole set of different 371 00:24:17,200 --> 00:24:20,760 controls and they're used in the federal government in the US. 372 00:24:20,760 --> 00:24:25,240 They're used for things like directing FedRAMP, FedRAMP low, medium and high. 373 00:24:25,240 --> 00:24:29,880 So they'll take those actual controls and then sort of codify them for moving federal 374 00:24:29,880 --> 00:24:31,520 solutions to the cloud. 375 00:24:31,520 --> 00:24:35,320 Do you sort of, when you're talking to customers, do you come across these kinds of frameworks 376 00:24:35,320 --> 00:24:38,160 or are people kind of winging it themselves? 377 00:24:38,160 --> 00:24:41,560 I think it depends a lot on what kind of industry you're in. 378 00:24:41,560 --> 00:24:49,960 A lot of our customers are in regulated industries, so they will use industry specific standards. 379 00:24:49,960 --> 00:24:54,880 We see a lot of ISO, I think it's 27,001. 380 00:24:54,880 --> 00:24:57,480 We see NIST, obviously. 381 00:24:57,480 --> 00:25:02,720 We see, so usually we are mostly Azure based for our detection parts. 382 00:25:02,720 --> 00:25:07,240 So it's mostly like the vendor for clouds, they've deployed a NIST standard. 383 00:25:07,240 --> 00:25:15,600 But I think also most people are using the Microsoft built-in cloud controls, which are 384 00:25:15,600 --> 00:25:16,680 pretty good. 385 00:25:16,680 --> 00:25:20,640 So I think that's about the extent of what we see. 386 00:25:20,640 --> 00:25:27,960 Also SIS obviously like the different baselines for VMs and stuff, but yeah, it depends. 387 00:25:27,960 --> 00:25:30,080 Center for Internet Security, CIS, I assume. 388 00:25:30,080 --> 00:25:31,080 Yeah, yeah. 389 00:25:31,080 --> 00:25:32,720 So I think you should bring up the Azure controls. 390 00:25:32,720 --> 00:25:35,920 So by that, I assume you mean the Azure Security Bench. 391 00:25:35,920 --> 00:25:39,200 Oh, actually it's now the Microsoft Security Benchmark, right, Mark? 392 00:25:39,200 --> 00:25:43,120 Microsoft Cloud Security Benchmark, I think, is the official new name. 393 00:25:43,120 --> 00:25:44,600 So is that commonly used as well? 394 00:25:44,600 --> 00:25:48,240 Because one of the things I do like about that is that it does map to other controls 395 00:25:48,240 --> 00:25:50,480 like NIST SPA100-53. 396 00:25:50,480 --> 00:25:53,840 Yeah, that's very commonly used. 397 00:25:53,840 --> 00:25:59,080 And I think as a focus for us as well, it's looking at, I think a lot of people in the 398 00:25:59,080 --> 00:26:05,000 security industry, like security people, we like numbers, which is why I made a point 399 00:26:05,000 --> 00:26:06,960 about we're very binary. 400 00:26:06,960 --> 00:26:11,520 If things are secure or not secure, that's just the two default options we have, which 401 00:26:11,520 --> 00:26:15,560 is, I guess, historically why we've been bad at communicating business value. 402 00:26:15,560 --> 00:26:20,560 But yeah, the secure scores, like the identity secure score and the Defender for Cloud secure 403 00:26:20,560 --> 00:26:28,200 score are very good ways to get your platform engineering team or your engineers and architects 404 00:26:28,200 --> 00:26:33,520 to sort of like design around making that score better, because that's something that 405 00:26:33,520 --> 00:26:39,000 you can put as like a key performance index, like making the secure score better. 406 00:26:39,000 --> 00:26:46,960 So I think that fact that you can integrate them with like a scorecard is very like intriguing 407 00:26:46,960 --> 00:26:47,960 to people. 408 00:26:47,960 --> 00:26:51,040 And they want to work to get that score to be good, because it's something that the customer 409 00:26:51,040 --> 00:26:57,800 can easily like, it's very easily like something you can project onto a customer facing dashboard. 410 00:26:57,800 --> 00:27:02,480 And so they can see the score and they can ask why hasn't the score improved? 411 00:27:02,480 --> 00:27:05,000 Why are we still at 89%? 412 00:27:05,000 --> 00:27:07,080 So that's, I think that's a very good thing. 413 00:27:07,080 --> 00:27:10,720 I think a lot of people are working just on improving that score. 414 00:27:10,720 --> 00:27:11,720 Look, I love that. 415 00:27:11,720 --> 00:27:12,720 Look, I'm not going to lie. 416 00:27:12,720 --> 00:27:13,720 I love that. 417 00:27:13,720 --> 00:27:15,800 But I love that with a grain of salt. 418 00:27:15,800 --> 00:27:20,500 I love the idea of having a number that people can aim for and see to improve. 419 00:27:20,500 --> 00:27:27,680 But I've also seen customers spend a lot of time trying to improve that score for something 420 00:27:27,680 --> 00:27:29,600 that actually has very little return. 421 00:27:29,600 --> 00:27:32,520 So they're willing to spend a lot of money to raise that score. 422 00:27:32,520 --> 00:27:36,920 But what they're really doing isn't really improving their security posture that much. 423 00:27:36,920 --> 00:27:41,480 Look, I'm not going to say that's something that I see all the time, but I have seen it 424 00:27:41,480 --> 00:27:42,480 happen. 425 00:27:42,480 --> 00:27:47,080 Like just the quest for increasing a number regardless. 426 00:27:47,080 --> 00:27:51,600 So my only concern there is, hey, if you're going to focus on increasing that score, then 427 00:27:51,600 --> 00:27:54,640 make sure it's the stuff that actually matters for your environment. 428 00:27:54,640 --> 00:27:57,800 One of the things I've seen is because they're, and this is actually going to one of the points 429 00:27:57,800 --> 00:28:02,400 you made in the article, is there's almost a binary view, which for people that grew 430 00:28:02,400 --> 00:28:07,320 up in the technology world isn't particularly surprising because there are truths and absolutes 431 00:28:07,320 --> 00:28:11,320 in the technology world that it will always execute in the exact same way because that's 432 00:28:11,320 --> 00:28:14,600 what the code says. 433 00:28:14,600 --> 00:28:20,920 But the interesting thing is the risk of the organization itself at the very top is dealing 434 00:28:20,920 --> 00:28:26,080 with a very, very complicated world where economic things could change and weather and 435 00:28:26,080 --> 00:28:29,200 all these other kind of risk factors to the organization. 436 00:28:29,200 --> 00:28:32,680 One of which is cybersecurity risk is a business risk. 437 00:28:32,680 --> 00:28:38,280 You've got to translate that sort of fuzziness and probability world down into this sort 438 00:28:38,280 --> 00:28:41,960 of technical absolute thing. 439 00:28:41,960 --> 00:28:45,800 It's always sort of interesting to see that. 440 00:28:45,800 --> 00:28:51,640 I think what you're seeing, Michael, on my perspective is probably just that people recognize 441 00:28:51,640 --> 00:28:55,240 that hey, we need to go ahead and do a bunch of things, great, but then they apply the 442 00:28:55,240 --> 00:29:03,840 old mindset of sort of a literal binary do everything and it has to be 100% correct. 443 00:29:03,840 --> 00:29:08,400 It's probably because they set the expectations poorly to the board or the business leaders 444 00:29:08,400 --> 00:29:11,320 that, hey, listen, if we get this score, we're good. 445 00:29:11,320 --> 00:29:12,760 Well, that's not right. 446 00:29:12,760 --> 00:29:16,800 It's actually this score is a good indicator for us, but it should be considered along 447 00:29:16,800 --> 00:29:21,360 with four or five others and we're constantly looking at what the most important risk is, 448 00:29:21,360 --> 00:29:24,360 which of course we asked you three months ago, we hope. 449 00:29:24,360 --> 00:29:27,480 Hopefully that they're actually understanding what's important to the business. 450 00:29:27,480 --> 00:29:32,920 And so I don't know, I feel like it's that same old kind of technical gremlin mindset 451 00:29:32,920 --> 00:29:36,680 rearing its head again to just sort of go back to the absolutes and binaries. 452 00:29:36,680 --> 00:29:43,640 I think the point about just getting someone to go along with security because it's a business 453 00:29:43,640 --> 00:29:48,320 expense, so you need to communicate it as something that's actually beneficial to the 454 00:29:48,320 --> 00:29:49,520 business. 455 00:29:49,520 --> 00:29:54,440 And then obviously as well with the score, I think it's a good tool where if you need 456 00:29:54,440 --> 00:30:01,760 to actually get some traction, I think you can use these scores easily to get some sort 457 00:30:01,760 --> 00:30:03,600 of momentum on your security work. 458 00:30:03,600 --> 00:30:09,160 But again, very important, it's to sometimes you might get like an 8% increase for doing 459 00:30:09,160 --> 00:30:12,640 something that will have no impact in your environment. 460 00:30:12,640 --> 00:30:18,000 And so do you do that just to make the number go up or do you prioritize elsewhere? 461 00:30:18,000 --> 00:30:22,880 So I think that's the trap you can fall into and that's where other standards come into 462 00:30:22,880 --> 00:30:25,200 play and actually knowing your environment. 463 00:30:25,200 --> 00:30:30,960 So I think a mix, if you're having trouble getting traction, I think the score is a good 464 00:30:30,960 --> 00:30:31,960 startup. 465 00:30:31,960 --> 00:30:36,720 As you evolve, you should maybe look away from the score and look at what's business 466 00:30:36,720 --> 00:30:37,720 critical to you. 467 00:30:37,720 --> 00:30:41,880 It's really like the training wheels to get you started on the bike, but at some point 468 00:30:41,880 --> 00:30:44,520 you need to take them off and ride the bike itself. 469 00:30:44,520 --> 00:30:51,000 Yeah, like get you started moving and then once you start rolling, it's easier to just 470 00:30:51,000 --> 00:30:54,520 do it based on more complex things. 471 00:30:54,520 --> 00:31:01,360 I got actually two last questions I wanted to ask before we get into the final question. 472 00:31:01,360 --> 00:31:06,200 One I was kind of curious how many organizations you run into are actually using kind of a 473 00:31:06,200 --> 00:31:08,000 use case based approach? 474 00:31:08,000 --> 00:31:13,480 And then the other is I'd love to get your comments on the cyclical or iterative approach 475 00:31:13,480 --> 00:31:14,960 that you recommend. 476 00:31:14,960 --> 00:31:20,580 Yeah, so I think a lot of people, at least the organizations we work with, are quite 477 00:31:20,580 --> 00:31:26,360 familiar with use case based approaches to at least the security monitoring. 478 00:31:26,360 --> 00:31:31,900 We do a sort of, how would you call it, like a co-managed SIEM solution. 479 00:31:31,900 --> 00:31:34,920 So their security team and our security team can work together. 480 00:31:34,920 --> 00:31:41,200 And so we have like a process where they can suggest like, oh, this is something that's 481 00:31:41,200 --> 00:31:45,080 important to us to monitor and then we work together to develop the use case. 482 00:31:45,080 --> 00:31:53,840 So I think it's something we see among quite many of the customers we work with. 483 00:31:53,840 --> 00:31:59,400 But outside of like security monitoring, it's not my field of expertise, so I couldn't say 484 00:31:59,400 --> 00:32:01,720 100%. 485 00:32:01,720 --> 00:32:09,360 As for the cyclical approach, I think that's one thing that we forget and a point that 486 00:32:09,360 --> 00:32:14,480 is very closely related to when you're talking about security tooling. 487 00:32:14,480 --> 00:32:20,040 I think we are very good at seeing the new Shiny and running after it and, oh, this is 488 00:32:20,040 --> 00:32:24,880 going to help us protect against this thing instead of looking at our existing tool stack 489 00:32:24,880 --> 00:32:30,680 or the strategies and the designs we already have in place and going over it and seeing 490 00:32:30,680 --> 00:32:32,620 if we could do something better. 491 00:32:32,620 --> 00:32:39,640 So my idea with like suggesting a cyclical approach was that once you go through protecting 492 00:32:39,640 --> 00:32:44,140 your identities as an example, once you've enabled security controls that make sense 493 00:32:44,140 --> 00:32:49,480 to your organization, you have enabled monitoring and detection that makes sense to your organization, 494 00:32:49,480 --> 00:32:51,040 you shouldn't stop at that. 495 00:32:51,040 --> 00:32:56,040 You should go back maybe a month later, three months later, whatever makes sense and what 496 00:32:56,040 --> 00:33:00,680 you can fit in and look, am I still covering all my bases? 497 00:33:00,680 --> 00:33:02,640 Are there new options? 498 00:33:02,640 --> 00:33:07,600 Are there any new developments in the tools I already have that I can use to improve my 499 00:33:07,600 --> 00:33:13,440 security posture and then do that continuously, like put it into a system instead of, okay, 500 00:33:13,440 --> 00:33:18,040 now this is enabled, this is set up, now it's going to work and look, there's the next tool, 501 00:33:18,040 --> 00:33:22,680 I'm going to move over to that because then you'll end up with a lot of tools, decent 502 00:33:22,680 --> 00:33:27,080 security posture that will degrade over time because you're not actually maintaining it. 503 00:33:27,080 --> 00:33:32,840 Yeah, I'm a big fan of continuous improvement because I think it addresses a couple of problems 504 00:33:32,840 --> 00:33:38,440 that are very prevalent in security, which is that sort of, hey, we got the check mark, 505 00:33:38,440 --> 00:33:39,440 we're done. 506 00:33:39,440 --> 00:33:43,080 That's sort of the dark side of checklist thinking because there are a lot of benefits 507 00:33:43,080 --> 00:33:46,200 of checklist thinking, but there is a dark side of, hey, it's done, we don't ever have 508 00:33:46,200 --> 00:33:47,760 to go back and look at it. 509 00:33:47,760 --> 00:33:51,440 We finished our 853, so therefore we're compliant, we're done. 510 00:33:51,440 --> 00:33:57,040 The continuous improvement helps break that, but it also helps break the fear of perfection, 511 00:33:57,040 --> 00:33:59,480 that we have to get this thing perfect the first time out. 512 00:33:59,480 --> 00:34:02,840 Then you spend all the time in the lab doing the thing and you don't actually put it out 513 00:34:02,840 --> 00:34:08,120 there and try it and learn on it and iteratively and cyclically improve. 514 00:34:08,120 --> 00:34:13,320 I'm a huge, huge fan of that continuous improvement type of growth mindset, some call it. 515 00:34:13,320 --> 00:34:17,520 All right, so now it's time to wrap this episode up. 516 00:34:17,520 --> 00:34:20,680 Because as someone who listens to the podcast, you're probably well aware that we have one 517 00:34:20,680 --> 00:34:25,200 little question for you at the end, which is if you had just one final thought to leave 518 00:34:25,200 --> 00:34:27,640 our listeners with, what would it be? 519 00:34:27,640 --> 00:34:33,500 I think it sort of boils down to my mindset when it comes to everything in security and 520 00:34:33,500 --> 00:34:37,600 everything in IT is to keep it simple. 521 00:34:37,600 --> 00:34:42,200 I used to say, or something I learned in the army is keep it simple, stupid, because you 522 00:34:42,200 --> 00:34:46,080 need to remind yourself, don't do things in large batches. 523 00:34:46,080 --> 00:34:50,680 It's easier to just do it in small batches, keep building on it. 524 00:34:50,680 --> 00:34:52,360 Just keep it as simple as you can. 525 00:34:52,360 --> 00:34:54,720 That way it's way easier to get things done. 526 00:34:54,720 --> 00:34:56,680 All right, so let's bring this episode to an end. 527 00:34:56,680 --> 00:34:58,920 Touls, thank you so much for joining us this week. 528 00:34:58,920 --> 00:35:02,320 It was fun listening to you and Mark, just pontificate. 529 00:35:02,320 --> 00:35:04,040 To all our listeners out there, thanks so much for listening. 530 00:35:04,040 --> 00:35:06,280 We hope you found this episode of interest. 531 00:35:06,280 --> 00:35:08,440 Stay safe and we'll see you next time. 532 00:35:08,440 --> 00:35:11,440 Thanks for listening to the Azure Security Podcast. 533 00:35:11,440 --> 00:35:18,280 You can find show notes and other resources at our website azsecuritypodcast.net. 534 00:35:18,280 --> 00:35:23,120 If you have any questions, please find us on Twitter at AzureSecPod. 535 00:35:23,120 --> 00:35:43,440 Background music is from ccmixtr.com and licensed under the Creative Commons license.