1 00:00:00,040 --> 00:00:02,840 We understand that like real time capabilities are extremely 2 00:00:02,840 --> 00:00:08,560 important to prevent reaches, stop reaches and remediate them. 3 00:00:08,840 --> 00:00:13,080 So we have two core capabilities there that I think are different 4 00:00:13,080 --> 00:00:18,760 from the others. One, we use LLMS to improve the 5 00:00:18,760 --> 00:00:22,760 visibility and posture capabilities that you have 6 00:00:23,280 --> 00:00:26,400 compared to your standard IGA and Palm tools today. 7 00:00:26,400 --> 00:00:31,360 But then 2, we are able to do real time detection and response 8 00:00:31,360 --> 00:00:36,160 to identity based threats. And this makes it so that you 9 00:00:36,160 --> 00:00:41,080 you're able to catch anything that your identity like 10 00:00:41,080 --> 00:00:44,960 governance program might might have missed or anywhere anybody 11 00:00:44,960 --> 00:00:48,560 that gets fished, stolen credentials, stolen tokens and 12 00:00:48,560 --> 00:00:51,040 so on. The ability to do it real time 13 00:00:51,040 --> 00:00:54,600 is something that we think is is lacking in industry. 14 00:01:00,040 --> 00:01:06,400 This is identity at the center if it has anything to do with 15 00:01:06,440 --> 00:01:12,360 IAM. This is the go to podcast now 16 00:01:12,360 --> 00:01:16,560 your hosts Jim McDonald and Jeff Stedman. 17 00:01:20,240 --> 00:01:22,080 Welcome to the Identity at the Center podcast. 18 00:01:22,080 --> 00:01:23,560 I'm Jeff, and that's Jim. Hey, Jim. 19 00:01:23,960 --> 00:01:26,480 Hey, Jeff, how are you? Oh, not so bad yourself. 20 00:01:26,960 --> 00:01:29,080 Good. I'm excited for today's episode. 21 00:01:29,160 --> 00:01:32,000 I think the the focus for me is innovation. 22 00:01:32,280 --> 00:01:35,400 I talked to a lot of folks who are listeners of the show. 23 00:01:35,400 --> 00:01:38,360 They want to know what are the new innovations that are 24 00:01:38,360 --> 00:01:40,480 happening? What are the new products that 25 00:01:40,480 --> 00:01:44,280 are bringing innovation into the world of I am. 26 00:01:44,280 --> 00:01:46,440 So we're going to get into this today. 27 00:01:46,920 --> 00:01:48,640 Yeah, for sure. Today's a sponsored episode. 28 00:01:48,640 --> 00:01:51,600 So making that very clear up front, these are episodes where 29 00:01:51,600 --> 00:01:54,240 we dive a little bit deeper into the technologies and the the 30 00:01:54,240 --> 00:01:56,480 players in the space. And there are a lot of them. 31 00:01:56,480 --> 00:01:58,560 So I'm glad that we're able to get some of these folks on and 32 00:01:58,560 --> 00:02:00,280 kind of explain, OK, where are they coming from, their 33 00:02:00,280 --> 00:02:03,000 viewpoints and things like that. So just make it crystal clear, 34 00:02:03,000 --> 00:02:05,080 right? This is sponsored episode today. 35 00:02:05,080 --> 00:02:08,479 We're sponsored by slash ID. They're an identity platform to 36 00:02:08,560 --> 00:02:10,600 protect human and non human identities. 37 00:02:10,680 --> 00:02:15,600 You can find out more about them at slashid.com/IDAC. 38 00:02:16,080 --> 00:02:18,160 And we've got Vincenzo Yoso today. 39 00:02:18,200 --> 00:02:20,560 He's the CEO at slash ID Welcome Vincenzo. 40 00:02:20,560 --> 00:02:22,040 And hopefully I didn't butcher your last name. 41 00:02:22,560 --> 00:02:24,360 You didn't. I'm very impressed. 42 00:02:25,320 --> 00:02:26,240 All right. Well, we're starting off on a 43 00:02:26,240 --> 00:02:28,560 great note. One of the things we also like 44 00:02:28,560 --> 00:02:30,640 to do before we start to get into any sort of conversations, 45 00:02:30,640 --> 00:02:32,360 really find out about the backgrounds of the people that 46 00:02:32,360 --> 00:02:33,920 we talked to that are in the identity space. 47 00:02:33,920 --> 00:02:36,520 It's a wide and varied space. You've got an interesting 1, so 48 00:02:36,520 --> 00:02:38,920 let's start there. How did you get into the digital 49 00:02:38,920 --> 00:02:40,960 identity space? Is this something that you chose 50 00:02:40,960 --> 00:02:45,560 or did it choose you? It definitely choose me. 51 00:02:46,000 --> 00:02:49,080 So I have. I have a bit of a, a strange 52 00:02:49,080 --> 00:02:53,080 background compared to a lot of like your guests in that I, I 53 00:02:53,080 --> 00:02:56,240 started my career in sort of like the offensive security side 54 00:02:56,240 --> 00:03:02,320 of things and then over time got a closer and closer to identity. 55 00:03:02,320 --> 00:03:04,920 So my original background is in security research. 56 00:03:05,720 --> 00:03:09,720 I used to work on vulnerabilities and exploits for 57 00:03:10,000 --> 00:03:13,920 endpoints. Fast forward, I spent a number 58 00:03:13,920 --> 00:03:18,960 of years at Crowd Strike and one of the products that I was 59 00:03:18,960 --> 00:03:21,080 involved with at crowd Strike was the identity protection 60 00:03:21,080 --> 00:03:25,320 product. And that's how I started to be 61 00:03:25,320 --> 00:03:27,000 involved in, in the identity space. 62 00:03:27,280 --> 00:03:30,600 But it's always, it's always has been more from my security 63 00:03:30,600 --> 00:03:34,360 standpoint rather than a traditional identity background. 64 00:03:35,200 --> 00:03:37,560 And so you take that attack mindset, no better way to start 65 00:03:37,560 --> 00:03:39,240 with, like, how do we defend against attackers? 66 00:03:39,240 --> 00:03:41,360 And you also do some work, I think, with Black Hat, right? 67 00:03:41,360 --> 00:03:43,240 As I was just kind of stalking you on LinkedIn a little bit. 68 00:03:43,640 --> 00:03:45,040 Tell me about your Black Hat involvement. 69 00:03:45,560 --> 00:03:47,800 Yeah. So I mean, when I, when I 70 00:03:47,800 --> 00:03:52,240 started back in the days on the security kind of like researcher 71 00:03:52,480 --> 00:03:56,240 track, I used to do a lot of like presentations on attacks 72 00:03:56,240 --> 00:03:58,200 and then like exploitation techniques. 73 00:03:58,880 --> 00:04:01,720 And that's how I got involved with Blackett at the beginning. 74 00:04:01,760 --> 00:04:05,240 And then I have stayed involved throughout the years to give 75 00:04:05,240 --> 00:04:07,400 back to the community and make sure that like we still have 76 00:04:07,560 --> 00:04:11,080 like vibrant talks and and interesting tracks at the 77 00:04:11,080 --> 00:04:13,800 conference. So I've been put to Black Hat in 78 00:04:13,800 --> 00:04:15,320 the past. It's been a couple years. 79 00:04:15,320 --> 00:04:18,560 I always kind of enjoyed it and I've seen some interesting 80 00:04:18,560 --> 00:04:19,800 things there. Maybe if we have time towards 81 00:04:19,800 --> 00:04:22,640 the end, I'll ask you like what are some things maybe that 82 00:04:22,640 --> 00:04:24,000 you've seen that might be kind of interesting there. 83 00:04:24,000 --> 00:04:28,560 But let's talk about slash ID. So what is slash Idi guess? 84 00:04:28,560 --> 00:04:30,360 Tell us a little bit about the the organization that you're 85 00:04:30,360 --> 00:04:32,000 building there and the technology that you're bringing 86 00:04:32,000 --> 00:04:34,280 to the digital identity market. Yeah. 87 00:04:34,280 --> 00:04:38,280 So as I mentioned, we, we come to the space from from our 88 00:04:38,280 --> 00:04:43,360 security background and what we thought was missing when when we 89 00:04:43,360 --> 00:04:46,280 started a company were were really two things. 90 00:04:46,280 --> 00:04:51,040 One, everyone we spoke with had problems with IGA processes in 91 00:04:51,040 --> 00:04:53,480 the in the sense that they weren't particularly effective. 92 00:04:54,040 --> 00:04:56,800 You had a lot of failed implementations and so on. 93 00:04:56,800 --> 00:05:01,360 But more importantly, we had started to see most reaches a 94 00:05:01,360 --> 00:05:05,720 crowd strike being identity related where at least either 95 00:05:05,720 --> 00:05:09,120 the initial vector or at some point throughout the kill chain 96 00:05:09,120 --> 00:05:12,200 you add an identity component. And none of the existing 97 00:05:12,520 --> 00:05:16,760 products were focused on identity security rather than 98 00:05:17,000 --> 00:05:21,600 compliance and management. So tell me about the name, 99 00:05:21,600 --> 00:05:23,920 because slash ID is kind of unique and like there's there's 100 00:05:23,920 --> 00:05:25,440 usually a story behind something. 101 00:05:25,440 --> 00:05:26,960 How did you come up with slash ID? 102 00:05:27,600 --> 00:05:30,640 Yeah. So what we wanted to convey with 103 00:05:30,640 --> 00:05:34,360 the with the name similar to, I don't know if you, if you've 104 00:05:34,360 --> 00:05:38,000 ever read the story of Stripe, but their first name was slash 105 00:05:38,000 --> 00:05:40,520 payment. And the idea there was to bring 106 00:05:40,920 --> 00:05:43,440 kind of like payments to developers and engineers. 107 00:05:43,800 --> 00:05:48,080 And what we wanted to do from day one is to build a platform 108 00:05:48,080 --> 00:05:51,880 that was friendly to security engineers and practitioners, not 109 00:05:51,880 --> 00:05:56,080 just sort of like that click OPS kind of kind of like kind of 110 00:05:56,080 --> 00:05:59,240 product. So I have to say, right, there's 111 00:05:59,240 --> 00:06:02,120 a ton of products in this space of digital identity, too many 112 00:06:02,120 --> 00:06:04,200 almost to keep up with. And so there's a lot of 113 00:06:04,200 --> 00:06:06,040 competition. You know, I'm curious from your 114 00:06:06,040 --> 00:06:09,520 perspective, what is it that you think sets slash ID apart from 115 00:06:09,520 --> 00:06:11,960 your contemporaries? You know, I guess the the blunt 116 00:06:11,960 --> 00:06:13,600 version is what makes you special. 117 00:06:15,160 --> 00:06:16,480 Yeah. So I think it's it's really two 118 00:06:16,480 --> 00:06:21,720 things. 1 is a lot of the other companies in the space focus on 119 00:06:21,720 --> 00:06:25,240 a static view of the identity, whereas coming from a security 120 00:06:25,240 --> 00:06:28,080 background, we understand it like real time capabilities are 121 00:06:28,080 --> 00:06:33,600 extremely important to prevent breaches, stop breaches and 122 00:06:33,600 --> 00:06:37,280 remediate them. So we have two core capabilities 123 00:06:37,280 --> 00:06:39,360 there that I think are different from the others. 124 00:06:39,360 --> 00:06:46,040 One, we use LMS to improve the visibility and posture 125 00:06:47,200 --> 00:06:50,880 capabilities that you have compared to your standard IGA 126 00:06:50,880 --> 00:06:55,240 and pump tools today. But then two, we are able to do 127 00:06:55,240 --> 00:06:58,280 real time detection and response to identity based threats. 128 00:06:59,160 --> 00:07:03,520 And this makes it so that you you're able to catch anything 129 00:07:03,520 --> 00:07:07,960 that your identity like governance program might might 130 00:07:07,960 --> 00:07:12,200 have missed or anywhere anybody that gets fished, stolen 131 00:07:12,200 --> 00:07:14,600 credentials, stolen tokens and so on. 132 00:07:15,040 --> 00:07:19,280 The ability to do it real time is something that we think is is 133 00:07:19,280 --> 00:07:23,880 lacking in industry. So Vincenzo, the question I was 134 00:07:23,880 --> 00:07:27,280 going to ask you was because most of the time when I talk to 135 00:07:27,280 --> 00:07:30,400 entrepreneurs in this space, there's something that they 136 00:07:30,400 --> 00:07:35,200 recognize in the industry that's kind of overlooked or that they 137 00:07:35,200 --> 00:07:39,280 feel they could bring a fresh solution to fix a problem. 138 00:07:39,720 --> 00:07:42,040 The question I was going to ask you is what drew you in? 139 00:07:42,040 --> 00:07:44,800 But I think you answered that when you talked to to Jeff 140 00:07:44,800 --> 00:07:49,080 about, you know, the the IGA situation, not really solving 141 00:07:49,080 --> 00:07:52,640 the problem. I think you talked about the the 142 00:07:52,640 --> 00:07:54,720 breaches being mostly identity related. 143 00:07:54,720 --> 00:07:56,680 So I want to pick on those two areas. 144 00:07:57,000 --> 00:08:02,200 And I've heard it said that, you know, the IGA solutions are 145 00:08:02,200 --> 00:08:08,080 better for driving compliance than solving real security 146 00:08:08,080 --> 00:08:10,320 issues. So the first is that's something 147 00:08:10,320 --> 00:08:14,200 you agree with and and why it? Why is that the case in your 148 00:08:14,200 --> 00:08:16,360 opinion? Yeah, 100%. 149 00:08:16,360 --> 00:08:19,560 I mean, when you look at the history of IGA and I think you 150 00:08:19,560 --> 00:08:24,360 had guests on on on the podcast that were sort of like the, the 151 00:08:24,400 --> 00:08:27,480 real, the, the creators of of IGA as a space. 152 00:08:28,120 --> 00:08:33,880 It was primarily been driven by compliance needs in the wake of 153 00:08:33,880 --> 00:08:38,400 Enron and similar like fraudulent activities for public 154 00:08:38,400 --> 00:08:41,480 companies. So the approach you take when 155 00:08:41,480 --> 00:08:46,040 when you use governance is a very prescriptive, policy based 156 00:08:46,480 --> 00:08:50,440 approach that doesn't, doesn't really work when you deal with 157 00:08:50,960 --> 00:08:52,640 attacks, stereo dynamic in nature. 158 00:08:52,640 --> 00:08:58,520 And what attackers really try to do is to look for gaps in your 159 00:08:58,520 --> 00:09:01,000 posture. And it's something that a 160 00:09:01,000 --> 00:09:05,280 governance platform is not actually able to react to in a 161 00:09:05,280 --> 00:09:06,960 timely manner. Yeah. 162 00:09:06,960 --> 00:09:11,600 And so, I mean, I kind of feel like it's this isn't a black and 163 00:09:11,600 --> 00:09:14,360 white situation, right. I think most of the compliance 164 00:09:14,360 --> 00:09:21,280 regulations try to drive better security through compliance 165 00:09:21,280 --> 00:09:23,760 through kind of these governance processes. 166 00:09:24,040 --> 00:09:27,800 So they at least incrementally make security better, going in 167 00:09:28,120 --> 00:09:32,120 and checking to make sure people have only the access that they 168 00:09:32,120 --> 00:09:35,800 should have. But it seems like most of the 169 00:09:35,800 --> 00:09:39,480 processes from a governance perspective are detective and 170 00:09:39,640 --> 00:09:44,840 they could be, you know, not performed until some periodic 171 00:09:45,120 --> 00:09:47,080 basis, right? Maybe it's once a year. 172 00:09:47,320 --> 00:09:49,840 So checking a list of accounts to make sure that they have the 173 00:09:49,840 --> 00:09:55,360 right entitlements once a year is good, but not great. 174 00:09:56,640 --> 00:09:58,320 Exactly. I, I think you're far on Jim, 175 00:09:58,480 --> 00:10:01,240 like when you, when you, when you look at the problem is an 176 00:10:01,280 --> 00:10:05,840 attacker breaks into an environment at any point in 177 00:10:05,840 --> 00:10:08,040 time, right. They they don't wait for the 178 00:10:08,040 --> 00:10:13,440 compliance audit to come due. And what you see in complex 179 00:10:13,440 --> 00:10:16,720 organizations is that these entitlements change by the day. 180 00:10:17,000 --> 00:10:21,480 And so taking a snapshot once a year or one supporter is nowhere 181 00:10:21,480 --> 00:10:26,400 near enough to be able to detect and attack in real time on top 182 00:10:26,400 --> 00:10:30,080 of it. And I'm sure you've seen this as 183 00:10:30,080 --> 00:10:33,040 well. A lot of IGA has become so 184 00:10:33,040 --> 00:10:35,160 complex. There's often, there's often 185 00:10:35,160 --> 00:10:39,120 just a check box exercise where some manager just says, yes, 186 00:10:39,120 --> 00:10:41,680 this, this person on my team should have access to the 187 00:10:41,680 --> 00:10:46,600 system, but they don't have the ability to really know how our 188 00:10:46,600 --> 00:10:49,760 buck works in that system, what entitlements really mean and and 189 00:10:49,760 --> 00:10:51,840 so on. So you have this double whammy 190 00:10:51,840 --> 00:10:56,680 where snapshot based solutions are not moving fast enough 191 00:10:56,680 --> 00:10:59,200 compared to attackers. And on the flip side, the 192 00:10:59,200 --> 00:11:03,520 complexity of these systems is such that even when you do take 193 00:11:03,520 --> 00:11:06,560 a snapshot to make sure that you're compliant, often the the, 194 00:11:06,600 --> 00:11:10,360 the, the degree of access control that you can really do 195 00:11:10,640 --> 00:11:14,440 is a lot less than what you need for proper security because it's 196 00:11:14,440 --> 00:11:17,880 too complicated to understand the authorization model of each 197 00:11:18,000 --> 00:11:19,480 individual application that you're dealing with. 198 00:11:20,520 --> 00:11:22,280 Yeah. I mean, as you're talking, I'm 199 00:11:22,280 --> 00:11:26,400 sitting here thinking of one of the biggest faux pas within kind 200 00:11:26,400 --> 00:11:31,400 of the idea of governance, which is rubber stamping. 201 00:11:31,840 --> 00:11:35,360 I mean, I think what happens in organizations is there's two 202 00:11:35,360 --> 00:11:41,480 major problems. 1 is the entitlement system is so complex 203 00:11:41,480 --> 00:11:46,400 that people don't really understand that Vincenzo has XYZ 204 00:11:46,400 --> 00:11:48,960 access. Is that appropriate? 205 00:11:48,960 --> 00:11:52,080 Well, if you put that in front of the wrong person or somebody 206 00:11:52,080 --> 00:11:55,920 who doesn't know what XYZ access really means, they say, well, 207 00:11:55,920 --> 00:11:59,280 Vincenzo is a good guy, he wouldn't do anything wrong. 208 00:11:59,600 --> 00:12:03,680 And so they just say keep it or they're afraid that they take it 209 00:12:03,680 --> 00:12:05,920 off. The company's going to stop 210 00:12:05,920 --> 00:12:08,960 being able to pay invoices or something, something crazy, 211 00:12:08,960 --> 00:12:13,880 right? So there's the not having enough 212 00:12:13,880 --> 00:12:16,880 information around entitlement. So the other thing that I find 213 00:12:17,040 --> 00:12:22,760 you don't hear talk about much is that a lot of the decision 214 00:12:22,760 --> 00:12:25,960 making is consolidated in very few hands. 215 00:12:25,960 --> 00:12:32,520 So one person might be reviewing access for too many people, too 216 00:12:32,520 --> 00:12:38,840 many applications and it becomes IAM overload for them. 217 00:12:38,840 --> 00:12:43,200 So they're being asked to do all these reviews and they're often 218 00:12:43,280 --> 00:12:46,720 the most busy people in the organization to begin with. 219 00:12:46,960 --> 00:12:50,720 So now rubber stamping becomes out of control, especially if 220 00:12:50,720 --> 00:12:52,400 you compound it with the first problem. 221 00:12:53,640 --> 00:12:58,880 So I guess my question to you is like, how does slash ID solve 222 00:12:58,880 --> 00:13:00,320 this problem? Do you actually solve it? 223 00:13:00,320 --> 00:13:03,600 Or do you say like the approach is wrong and we do something 224 00:13:03,600 --> 00:13:05,040 different? Yeah. 225 00:13:05,040 --> 00:13:12,080 So I mean 2-2 of of the so like most loved features of our 226 00:13:12,080 --> 00:13:16,040 platform are actually exactly tackling the first problem that 227 00:13:16,040 --> 00:13:18,280 you're talking about Jim. And it's it's a very different 228 00:13:18,280 --> 00:13:23,400 way to approach it, we think. So 1 is we like it. 229 00:13:23,400 --> 00:13:27,720 This sounds very simple and and stupid in many ways, but like 230 00:13:28,520 --> 00:13:29,800 people find a lot of value out of it. 231 00:13:30,120 --> 00:13:34,120 We can automatically generate descriptions for roles, 232 00:13:34,120 --> 00:13:37,440 identities, credentials and groups in your environment so 233 00:13:37,440 --> 00:13:41,960 that you're able to see both us as a identity professional, as a 234 00:13:41,960 --> 00:13:44,320 security professional, as well as a business user. 235 00:13:44,520 --> 00:13:47,360 Hey, what can this identity actually do? 236 00:13:47,360 --> 00:13:50,320 What does it does? Does this identity have access 237 00:13:50,320 --> 00:13:54,000 to in in the environment? And the second thing is to your 238 00:13:54,000 --> 00:13:57,760 point about the complexity of the entitlement systems, often, 239 00:13:57,760 --> 00:13:59,680 especially when you look at like cloud environments, it's almost 240 00:13:59,680 --> 00:14:03,800 impossible to create a use privilege list privilege policy 241 00:14:04,240 --> 00:14:06,280 right from the start. So one of the things that we 242 00:14:06,280 --> 00:14:11,720 help companies do is observe the behavior of their identity over 243 00:14:11,720 --> 00:14:14,800 time, see which entitlements he actually uses, and then 244 00:14:14,800 --> 00:14:19,480 automatically generate a list privilege policy that minimizes 245 00:14:19,480 --> 00:14:22,800 the amount of access that an entity has without disrupting 246 00:14:23,120 --> 00:14:25,320 disrupting it. Which we think is is 247 00:14:25,360 --> 00:14:28,640 fundamentally better approach than trying to be prescriptive 248 00:14:28,640 --> 00:14:34,760 and trying to create roles or groups upfront, especially in 249 00:14:34,760 --> 00:14:38,280 environments that have very complex authorization systems. 250 00:14:38,560 --> 00:14:43,160 That's a great, great overview. So the other thing that you 251 00:14:43,160 --> 00:14:46,960 pointed out was one of the, you know, as one of the things that 252 00:14:46,960 --> 00:14:50,560 really drew you into the industry was the whole data 253 00:14:50,560 --> 00:14:53,800 breach aside. So truly security trying to 254 00:14:53,800 --> 00:14:58,640 solve a security problem that, you know, all organizations at 255 00:14:58,640 --> 00:15:02,840 least need to be thinking about. But you made a statement that 256 00:15:02,840 --> 00:15:04,800 most of them are identity related. 257 00:15:04,920 --> 00:15:08,640 I think I know what that means being the Co host of the 258 00:15:08,680 --> 00:15:12,160 identity to center podcast but I want to know what you mean. 259 00:15:12,680 --> 00:15:16,520 Yeah. So when when you look at the 260 00:15:16,520 --> 00:15:21,280 various industry reports on data breaches throughout the years, 261 00:15:21,280 --> 00:15:23,880 Verizon publishes a very popular 1. 262 00:15:24,840 --> 00:15:28,280 AWS also publishes a very popular one yearly. 263 00:15:29,160 --> 00:15:33,200 Almost all of them across the board mention identity as one of 264 00:15:33,200 --> 00:15:37,040 the primary vector for either the initial compromise or 265 00:15:37,040 --> 00:15:39,600 lateral movement. I'll give you some some stats 266 00:15:39,760 --> 00:15:43,680 which which I find extremely interesting. 66% of the bridges 267 00:15:43,680 --> 00:15:52,040 that Amazon sees in AWS are due to stalling AWS credentials. 268 00:15:52,720 --> 00:15:58,560 About 33% of all the bridges that Verizon tracks have a 269 00:15:59,320 --> 00:16:03,760 credential related issue as the entry point and cross strike 270 00:16:03,760 --> 00:16:07,440 tracks in their global reports lateral movement attempts. 271 00:16:07,680 --> 00:16:10,800 Most of them are actually an anti related where somebody's 272 00:16:10,800 --> 00:16:14,080 using cover roasting or similar techniques to escalate 273 00:16:14,080 --> 00:16:16,480 privileges within an environment. 274 00:16:16,840 --> 00:16:23,480 And so it really feels like from from our standpoint that most of 275 00:16:23,600 --> 00:16:27,800 the identity programs out there are not doing enough on the 276 00:16:27,800 --> 00:16:30,880 security side and that's why we're seeing such a spike in 277 00:16:30,920 --> 00:16:34,280 identity related breaches. Yeah. 278 00:16:35,200 --> 00:16:40,760 You know, I read a recent report which pointed out that I 279 00:16:41,120 --> 00:16:46,200 identity related breaches have dropped over the past five 280 00:16:46,200 --> 00:16:49,120 years. And I feel like I, you know, 281 00:16:49,120 --> 00:16:51,960 they're not as persistently in the news. 282 00:16:52,200 --> 00:16:55,480 But the guidance in that report and guidance that kind of rings 283 00:16:55,480 --> 00:16:59,680 true to me is that even though the the number of them may be 284 00:16:59,680 --> 00:17:04,680 falling, they're the impact, the risk is still there, right? 285 00:17:04,880 --> 00:17:10,240 The impact outweighs maybe the likelihood, and maybe the 286 00:17:10,240 --> 00:17:14,440 likelihood is dropping because of people doing better identity 287 00:17:14,440 --> 00:17:19,640 management. I, I think the, what, what I 288 00:17:19,640 --> 00:17:22,720 will say is if, if you look at like the, the, the latest 289 00:17:23,119 --> 00:17:26,640 Verizon report that just came out, I think like today or, or, 290 00:17:26,640 --> 00:17:32,040 or last night, what you'll see is there is a spike in 291 00:17:32,320 --> 00:17:37,120 vulnerabilities as the primary attack vector as opposed to 292 00:17:37,600 --> 00:17:41,160 credential breaches. But credential breaches are 293 00:17:41,160 --> 00:17:46,360 still so far the number one cause for, for, for, for, for 294 00:17:46,360 --> 00:17:48,680 breaches. I think what what what's 295 00:17:48,680 --> 00:17:52,920 happening over time is we're moving as an industry away from 296 00:17:53,440 --> 00:17:58,480 long lived access tokens to better ways to authenticate 297 00:17:58,480 --> 00:18:03,720 services and machines and so on. But we're still far away from 298 00:18:04,560 --> 00:18:10,440 like identity being sort of like a secure part of the IT stack. 299 00:18:11,680 --> 00:18:13,560 Yeah. I mean, look, the problem is not 300 00:18:13,560 --> 00:18:14,440 going away. By the way. 301 00:18:14,440 --> 00:18:18,800 The the report that I was referencing is the RSMUS Middle 302 00:18:18,800 --> 00:18:21,240 Market Business Index special report. 303 00:18:21,560 --> 00:18:25,400 And kind of the, what I thought was the punchline is even though 304 00:18:26,160 --> 00:18:32,120 the data is positive, there was a spike in in breaches in 2024, 305 00:18:34,200 --> 00:18:37,920 but that the methods being used in these attacks are becoming 306 00:18:37,920 --> 00:18:41,680 more sophisticated. Some attacks may go undetected. 307 00:18:43,000 --> 00:18:45,840 And that highlights the importance of continuously 308 00:18:45,840 --> 00:18:49,200 strengthening security controls. It's that undetected piece, 309 00:18:49,200 --> 00:18:52,000 right? That's the that's the real hook 310 00:18:52,600 --> 00:18:57,640 that you know, people get in the door and then they sit there and 311 00:18:57,640 --> 00:19:01,040 then they conduct their attack later after they realize you 312 00:19:01,040 --> 00:19:03,640 don't even know that I'm in. Yeah, no. 313 00:19:03,720 --> 00:19:08,360 And honestly, Jim, you're, you're really into something on 314 00:19:08,360 --> 00:19:13,840 this because when you look at the average what what people in 315 00:19:13,840 --> 00:19:16,840 the security industry called the well time is the amount of time 316 00:19:16,840 --> 00:19:20,320 that an attacker stays in an environment before being thrown 317 00:19:20,320 --> 00:19:24,000 out for a normal breach that is 10 days. 318 00:19:24,000 --> 00:19:27,000 This is across the board from like Google reports, cross right 319 00:19:27,000 --> 00:19:29,600 reports and so on. When you look at identity based 320 00:19:29,600 --> 00:19:33,280 bridges, most of them take over a month to be discovered. 321 00:19:34,000 --> 00:19:37,840 And the reason for it is that we just don't have the same degree 322 00:19:37,840 --> 00:19:41,000 of detection capabilities that we have compared to endpoint 323 00:19:41,000 --> 00:19:46,560 security or cloud security. So I think a big part of what 324 00:19:46,560 --> 00:19:50,960 we're seeing, Jim, is that these breaches are harder to detect 325 00:19:51,280 --> 00:19:53,760 and potentially a lot more dangerous. 326 00:19:53,960 --> 00:19:57,240 I'll give just one, one I think here example. 327 00:19:57,240 --> 00:20:03,320 Microsoft was under review from CSA because of an identity 328 00:20:03,320 --> 00:20:06,240 related breach where the State Department was compromised. 329 00:20:06,520 --> 00:20:10,600 What I think was interesting there was that the way that 330 00:20:10,600 --> 00:20:15,160 breach was discovered was through a detection rule for 331 00:20:15,160 --> 00:20:17,760 e-mail security that the State Department had internally. 332 00:20:17,760 --> 00:20:20,400 It wasn't. It wasn't until then that 333 00:20:20,400 --> 00:20:24,760 Microsoft realized that they had lost a key, like a private key 334 00:20:25,160 --> 00:20:30,640 that the attacker was using to sign requests to expiratory 335 00:20:30,640 --> 00:20:34,000 data. So that really speaks to the 336 00:20:34,480 --> 00:20:37,680 complexity of these breaches and the lack of detection 337 00:20:37,680 --> 00:20:39,000 capabilities that we currently have. 338 00:20:40,040 --> 00:20:42,360 Yeah, it's pretty amazing. That's a great story that you 339 00:20:42,360 --> 00:20:44,600 shared. You know, I kind of wonder about 340 00:20:44,600 --> 00:20:46,760 that scenario because you hear about it all the time that 341 00:20:47,240 --> 00:20:52,160 breaches aren't detected for 170 days, something like that, that 342 00:20:52,160 --> 00:20:55,080 kind of dwell time. And I always kind of wondered 343 00:20:55,080 --> 00:20:59,960 what drives that from the adversary's perspective. 344 00:21:00,320 --> 00:21:04,120 They want to get in, obviously, but why does it take so long for 345 00:21:04,120 --> 00:21:07,760 them to be detected? Because I'm assuming the 346 00:21:07,760 --> 00:21:12,200 detection really is winds up occurring where they detonate 347 00:21:12,200 --> 00:21:14,920 whatever the full blown attack is. 348 00:21:14,920 --> 00:21:19,280 So is it like in the meantime they're doing research or they 349 00:21:19,280 --> 00:21:22,960 get in so many doors that they can't conduct the attack on all 350 00:21:22,960 --> 00:21:24,680 them? They say, all right, we're, 351 00:21:25,280 --> 00:21:29,960 we've got a backlog of work here in our in our hacker, you know, 352 00:21:30,320 --> 00:21:32,680 project plan. And so four months from now, 353 00:21:32,680 --> 00:21:36,680 we're going to go get that cup to have in your experience. 354 00:21:36,680 --> 00:21:39,120 Why? Why are those well time so long? 355 00:21:39,680 --> 00:21:43,760 So, so you have different classes of of attackers. 356 00:21:43,760 --> 00:21:46,920 You have some attackers that are financially motivated and then 357 00:21:46,920 --> 00:21:50,200 you have attackers that are more politically motivated or have 358 00:21:50,200 --> 00:21:53,400 espionage in mind. For the second class of the 359 00:21:53,400 --> 00:21:58,240 attackers, maintaining access to the system is by far one of the 360 00:21:58,280 --> 00:22:02,760 key statement in their mission. Like they need to stay in that 361 00:22:02,760 --> 00:22:06,480 system once they've compromised. So what they do is everything in 362 00:22:06,480 --> 00:22:10,120 their power to stay stealth and under the radar and not trigger 363 00:22:10,680 --> 00:22:12,840 any detection. Whereas for financially 364 00:22:12,840 --> 00:22:15,920 motivated attackers, they are more interested in sort of like 365 00:22:15,920 --> 00:22:18,040 the equivalent of a smash and grab where like they install 366 00:22:18,040 --> 00:22:23,840 ransomware and similar. And for them, what they try to 367 00:22:23,840 --> 00:22:28,040 do is find a way to that, to get to kind of like your most 368 00:22:28,040 --> 00:22:35,320 sensitive data and then either exportrate that data or use 369 00:22:35,320 --> 00:22:39,880 ransomware to, to, to force you to, to pay up or similar. 370 00:22:39,880 --> 00:22:43,240 And so in those cases, they care a bit less about detection. 371 00:22:43,600 --> 00:22:47,240 And, and so the detection time, the detection time frame is, is 372 00:22:47,240 --> 00:22:51,840 a lot shorter before espionage and positive motivated 373 00:22:51,840 --> 00:22:54,800 attackers. It is part of their MO to stay 374 00:22:54,800 --> 00:22:57,600 as stealth as possible, even though that might mean that 375 00:22:58,080 --> 00:23:01,200 it'll take them longer to accentuate data and what not. 376 00:23:01,800 --> 00:23:06,160 OK, I'm that makes sense. So, So what does slash ID do 377 00:23:06,920 --> 00:23:08,440 given all those different scenarios? 378 00:23:08,440 --> 00:23:14,080 What, what are the things that you're detecting that if I'm an 379 00:23:14,080 --> 00:23:16,400 I am practitioner, I'm going to miss today. 380 00:23:16,400 --> 00:23:20,040 What, what is it? What's that special trigger or 381 00:23:20,040 --> 00:23:23,440 multiple triggers that slash ID is doing for me? 382 00:23:23,440 --> 00:23:26,760 That's going to say, OK, now I see why I spend the money and 383 00:23:26,760 --> 00:23:28,320 invest in that. Yes. 384 00:23:28,600 --> 00:23:30,960 So we do three things on the detection side. 385 00:23:31,240 --> 00:23:34,760 One is we can monitor our privilege identity. 386 00:23:34,760 --> 00:23:38,240 So you can map, you can mark an identity as privileged and any 387 00:23:38,240 --> 00:23:41,640 change done to that identity with respect to creation of 388 00:23:42,120 --> 00:23:46,720 credentials, changes in the policies that they have access 389 00:23:46,720 --> 00:23:50,640 to, entitlements access and so on, we monitor and alert you on 390 00:23:50,640 --> 00:23:52,560 that. So you are always aware of 391 00:23:53,160 --> 00:23:56,640 whether one of your crown rules is being is being used without 392 00:23:57,040 --> 00:23:59,800 sort of like a proper reason in place. 393 00:24:00,120 --> 00:24:07,040 The second thing is we alert you to any behavioral pattern that 394 00:24:07,040 --> 00:24:10,360 we see in an identity that hasn't been seen before. 395 00:24:10,360 --> 00:24:13,360 So it follows this item. We see a service account that is 396 00:24:13,360 --> 00:24:16,280 trying to connect to a machine that has never used in the past 397 00:24:16,280 --> 00:24:21,640 90 days or 180 days. You get a detection that that 398 00:24:21,640 --> 00:24:24,600 you can action on either we'll get to the remediation in a 399 00:24:24,600 --> 00:24:27,360 second, but either manually or automatically through our 400 00:24:27,360 --> 00:24:31,160 remediations. And 3rd, we're we're able to 401 00:24:31,160 --> 00:24:35,280 help you detect life cycle issues. 402 00:24:35,280 --> 00:24:38,920 For instance, we're able to detect identities that haven't 403 00:24:38,920 --> 00:24:44,600 been off border properly, orphan credentials, roles and groups 404 00:24:44,640 --> 00:24:50,680 that haven't been used in a long time, and this helps minimizing 405 00:24:50,680 --> 00:24:54,640 the amount of pivot points that an attacker can have when 406 00:24:54,640 --> 00:24:56,520 they're trying to move laterally in your environment. 407 00:24:57,240 --> 00:25:01,360 Yeah, that, that's fantastic. So that's how I detect it. 408 00:25:01,360 --> 00:25:03,960 And how do I go about remeding it? 409 00:25:03,960 --> 00:25:06,680 And I guess there's two concerts they have. 410 00:25:06,680 --> 00:25:10,080 So if somebody, if I'm detecting OK, somebody's gotten in, 411 00:25:10,080 --> 00:25:13,320 somebody's on the network they've had, they have some 412 00:25:13,320 --> 00:25:16,440 accounts. How do I trace back? 413 00:25:16,720 --> 00:25:20,280 Is this combination tools? Is there a role that slash ID 414 00:25:20,280 --> 00:25:23,960 plays in this or trace back what maybe they've done over time? 415 00:25:25,280 --> 00:25:29,840 Because I guess there's 2 scenarios. 1 is I bring slash ID 416 00:25:29,840 --> 00:25:32,560 to and I look at my current environment. 417 00:25:32,880 --> 00:25:36,280 But then there's the going forward of how do I make sure 418 00:25:36,280 --> 00:25:39,160 that I detect the breaches quickly so there's not someone 419 00:25:39,160 --> 00:25:41,480 sitting on my network for a year. 420 00:25:41,480 --> 00:25:47,200 But if I bring in slash ID and I have been breach, but maybe that 421 00:25:47,200 --> 00:25:51,520 breach hasn't resulted in the big data exfiltration or 422 00:25:51,520 --> 00:25:53,960 ransomware insertion or something like that. 423 00:25:54,960 --> 00:26:00,000 Maybe the, the, the hackers in the process of trying to 424 00:26:00,160 --> 00:26:02,120 escalate privileges, things like that. 425 00:26:02,280 --> 00:26:03,680 How would I know what they've done? 426 00:26:03,680 --> 00:26:05,800 Have they created accounts and things like that? 427 00:26:06,200 --> 00:26:09,640 And then what do you think is the the process for cleaning up 428 00:26:09,640 --> 00:26:10,960 after that? Yeah. 429 00:26:11,560 --> 00:26:16,880 So what we do is we record by looking at log data. 430 00:26:16,880 --> 00:26:20,840 We record the actions of every identity so that the moment a 431 00:26:20,840 --> 00:26:22,840 detection triggers, you're able to look. 432 00:26:22,960 --> 00:26:25,600 Back. In time and see everything that 433 00:26:25,880 --> 00:26:30,520 that led to that to, to, to the potential breach and attack. 434 00:26:30,520 --> 00:26:33,960 So it's easy both for the identity team and the SoC team 435 00:26:33,960 --> 00:26:37,000 to understand what exactly happened in your environment 436 00:26:37,000 --> 00:26:39,120 that led to that specific problem. 437 00:26:39,600 --> 00:26:44,120 When it comes to remediation, we provide three ways to go about 438 00:26:44,480 --> 00:26:48,160 remediation. 1 is remediation playbooks. 439 00:26:48,160 --> 00:26:53,080 These are instructions that your IAM analyst or SoC analyst can 440 00:26:53,080 --> 00:26:58,160 manually follow to remediate a specific finding, whether this 441 00:26:58,160 --> 00:27:00,680 is a posture issue or an active threat. 442 00:27:01,080 --> 00:27:05,040 The second option is fully automated, so you can use our AP 443 00:27:05,040 --> 00:27:09,720 is to automatically remediate on a detection where it triggers. 444 00:27:10,000 --> 00:27:14,400 The advantage of doing that is you stop the attacker on their 445 00:27:14,400 --> 00:27:16,840 track immediately. Like we invalidate tokens, 446 00:27:17,640 --> 00:27:20,360 access tokens, so they can't move anywhere, you remove all 447 00:27:20,360 --> 00:27:22,640 the privilege, all the entitlements from a role, so 448 00:27:22,640 --> 00:27:25,240 they can't use the role to do anything in your system and so 449 00:27:25,240 --> 00:27:28,440 on. But some companies are are 450 00:27:28,440 --> 00:27:31,520 concerned about doing full remediation. 451 00:27:31,520 --> 00:27:37,200 So we provide 1/3 path, which is the ability to remediate in 452 00:27:37,200 --> 00:27:41,960 conjunction with a sort tool or or or manually through our UI, 453 00:27:42,120 --> 00:27:46,040 where you can go in, do your investigation, and then decide 454 00:27:46,200 --> 00:27:51,920 whether to suspend an entity, rotate a secret, quarantine a 455 00:27:51,920 --> 00:27:56,120 role, and so on through our UI or through the sort tool that 456 00:27:56,240 --> 00:27:59,440 you normally use. Is there a way to also automate 457 00:27:59,440 --> 00:28:03,160 that, so if somebody comes in and detects something to, hey, 458 00:28:03,160 --> 00:28:10,040 take, you know, predictive action to say, temporarily 459 00:28:10,040 --> 00:28:13,880 suspend this account until further research is done? 460 00:28:14,840 --> 00:28:15,760 Yeah. So. 461 00:28:16,240 --> 00:28:19,280 So what what you can do is, is when a detection triggers, you 462 00:28:19,280 --> 00:28:24,320 can have actions like suspend a user or a role or or a 463 00:28:24,320 --> 00:28:27,160 credential. And then once the investigation 464 00:28:27,360 --> 00:28:31,800 is done, you can decide whether to restore that identity or keep 465 00:28:31,800 --> 00:28:33,760 it, keep it blocked or delete it. 466 00:28:34,600 --> 00:28:37,200 So one more question, So you mentioned logs. 467 00:28:37,440 --> 00:28:41,200 So is this something that works in concert if I have a SIM 468 00:28:41,200 --> 00:28:46,160 solution on my network or does it have to replace my SIM 469 00:28:46,160 --> 00:28:48,120 solution? So does could it work with 470 00:28:48,120 --> 00:28:51,160 Splunk or no? Just throwing that out there, 471 00:28:51,320 --> 00:28:55,800 Splunk. Or do I have to now send my logs 472 00:28:55,800 --> 00:28:59,440 TO/ID? So we work with your existing 473 00:28:59,440 --> 00:29:02,680 SIM and we can send our detections and alerts to your 474 00:29:02,680 --> 00:29:06,160 SIM so that your SoC team doesn't have to use a different 475 00:29:06,160 --> 00:29:10,760 UI that they're not used to. And we, we, in general, we, we 476 00:29:11,240 --> 00:29:14,840 try to make sure that whatever tooling you already have, this 477 00:29:14,840 --> 00:29:18,360 is true both on the IGA side and the SoC side, We're able to 478 00:29:18,360 --> 00:29:21,280 integrate with them so that you're not changing the UI flows 479 00:29:21,280 --> 00:29:27,200 that you're used to. And so we can dump all of our 480 00:29:27,200 --> 00:29:33,160 findings into your SIM and then the SoC team can use the same to 481 00:29:33,160 --> 00:29:37,760 investigate similarly because we expose everything through AP is 482 00:29:37,960 --> 00:29:40,400 you don't if you don't want to. You don't actually have to use 483 00:29:40,400 --> 00:29:43,000 our UI at all. You can have your Terraform 484 00:29:45,120 --> 00:29:48,320 infrastructure as code. Use our AP is to pull 485 00:29:48,320 --> 00:29:52,040 information or remediate specific actions. 486 00:29:52,520 --> 00:29:56,960 I mean, to me this is like ITDR the vision realize, right? 487 00:29:56,960 --> 00:30:00,320 It's all about having visibility to your environment and 488 00:30:00,320 --> 00:30:03,960 detecting the threats, but working with your existing 489 00:30:03,960 --> 00:30:08,040 infrastructure but adding the identity intelligence on top of 490 00:30:08,040 --> 00:30:11,840 that is kind of that's kind of the approach that you had in 491 00:30:11,840 --> 00:30:14,200 mind. Yes, yes. 492 00:30:14,200 --> 00:30:17,640 What what we really tried to do is augment your existing 493 00:30:17,640 --> 00:30:20,040 tooling. We're not trying to displace 494 00:30:20,040 --> 00:30:22,240 your IGA program. We're trying to make it better 495 00:30:23,000 --> 00:30:26,960 with that intelligence layer there often often is missing. 496 00:30:28,640 --> 00:30:32,600 So if I have all this information right, I guess I can 497 00:30:32,600 --> 00:30:34,520 think about if this is from a measurement standpoint. 498 00:30:35,160 --> 00:30:37,240 All right, I just invested in slash ID. 499 00:30:37,760 --> 00:30:40,640 What do your typical customers say is like, OK, this is how we 500 00:30:40,640 --> 00:30:43,680 measure the success of the of the platform because it's almost 501 00:30:43,680 --> 00:30:46,360 kind of like you hope you don't have to use it, right. 502 00:30:47,560 --> 00:30:51,160 But you end up hopefully with, you know, data that can kind of 503 00:30:51,160 --> 00:30:53,600 come through and say, OK, we're detecting these things. 504 00:30:53,600 --> 00:30:55,280 And what do I do from like a response perspective? 505 00:30:55,560 --> 00:30:59,120 What if you found is sort of like the the key justification 506 00:30:59,200 --> 00:31:02,120 that your customers have said, OK, yeah, this is This is why we 507 00:31:02,120 --> 00:31:03,200 bought it. Yeah. 508 00:31:03,440 --> 00:31:07,440 So we find 3 things that customer mentioned to US. 509 00:31:07,440 --> 00:31:15,480 One is reduce time in IGA tasks. This is both in terms of like 510 00:31:15,480 --> 00:31:20,760 roll out or IGA programs as well as just the time it takes to do 511 00:31:21,240 --> 00:31:23,760 access reviews and access request thanks to the 512 00:31:23,840 --> 00:31:25,360 intelligence layer that we provide. 513 00:31:25,760 --> 00:31:29,280 The second is the reduced timing investigation. 514 00:31:29,520 --> 00:31:34,200 When there is a potential breach finding who actually created an 515 00:31:34,200 --> 00:31:36,400 identity, was that an identity stale? 516 00:31:36,400 --> 00:31:40,320 Is this a false positive or a false negative that saves a 517 00:31:40,320 --> 00:31:43,320 hundreds of hours for both IAM teams and sub teams? 518 00:31:44,840 --> 00:31:52,800 And then lastly, the the, the, the ability to use our 519 00:31:52,840 --> 00:31:56,720 remediations to avoid all the manual effort that analysts have 520 00:31:56,720 --> 00:31:59,200 to do today. Where consider you need to go to 521 00:31:59,200 --> 00:32:02,680 the platform team and ask them to write some terraform to fix 522 00:32:02,920 --> 00:32:08,840 identities or your IMIM team has to go in and manually fix stuff. 523 00:32:08,840 --> 00:32:12,360 Whereas you can use as as a sort of like an obstruction layer to 524 00:32:12,360 --> 00:32:16,680 do all the remediation. Ultimately I think that what 525 00:32:16,680 --> 00:32:20,720 this boils down to is 1 it's much easier for you to be 526 00:32:20,720 --> 00:32:24,200 compliant and prove to your auditors that you are compliant. 527 00:32:24,200 --> 00:32:29,120 And then two, you have the Peace of Mind that you don't have to 528 00:32:29,400 --> 00:32:33,320 to spend time building like custom detections in your in 529 00:32:33,320 --> 00:32:35,760 your sock team to detect that entity based attacks. 530 00:32:36,760 --> 00:32:39,800 That rule set is already built into the product with some sort 531 00:32:39,800 --> 00:32:42,280 of standard capabilities, but I imagine is is if me as a 532 00:32:42,280 --> 00:32:46,120 customer I can add additional policies or rule sets to detect 533 00:32:46,120 --> 00:32:47,520 against too, right? Yeah. 534 00:32:47,520 --> 00:32:51,720 And as I mentioned, you can monitor highly privileged 535 00:32:51,800 --> 00:32:55,720 identities that are really important to you and might not 536 00:32:55,720 --> 00:32:59,560 have sort of like might not have been picked up by our 537 00:33:00,600 --> 00:33:03,280 out-of-the-box detections. How would I go about setting 538 00:33:03,280 --> 00:33:05,240 that up? Is it as simple as coming up 539 00:33:05,240 --> 00:33:07,800 with like a naming rule or maybe a group membership? 540 00:33:07,800 --> 00:33:10,840 Or do I go in and flag individual accounts? 541 00:33:10,840 --> 00:33:12,400 I'm just trying to think of ways like, all right, in the real 542 00:33:12,400 --> 00:33:14,360 world, right? You know, I've got an Active 543 00:33:14,360 --> 00:33:16,800 Directory account and then I have like an Active Directory 544 00:33:16,800 --> 00:33:20,760 account dot Adm, right? And companies tend to follow 545 00:33:20,760 --> 00:33:22,480 patterns. Can I do some sort of like 546 00:33:22,760 --> 00:33:25,240 pattern matching or group membership analysis to say OK 547 00:33:25,560 --> 00:33:28,960 anytime an account like this shows up, I don't have to 548 00:33:28,960 --> 00:33:32,040 remember to put it into this bucket, it will just 549 00:33:32,040 --> 00:33:33,200 automatically go into that bucket? 550 00:33:33,360 --> 00:33:37,320 Yes, So you can, you can do group relationship analysis to 551 00:33:37,720 --> 00:33:40,800 automatically tag certain certain identities. 552 00:33:41,000 --> 00:33:47,560 You can also use our AP is as part of sort of your life cycle 553 00:33:47,560 --> 00:33:51,600 processes to mark specific identities as a privileged. 554 00:33:51,600 --> 00:33:58,360 And then lastly, we do analysis on our side based on the type of 555 00:33:58,360 --> 00:34:02,520 permissions and the type of access that the an entity has to 556 00:34:02,520 --> 00:34:07,000 say Pai information and so on to mark certain identities as high 557 00:34:07,000 --> 00:34:09,679 risk so that you have that full coverage. 558 00:34:10,920 --> 00:34:13,719 OK, so I'm sold. I'm going to get it and I want 559 00:34:13,719 --> 00:34:15,760 to deploy it. What does it look like to set 560 00:34:15,760 --> 00:34:18,199 this up? I guess how long does it take 561 00:34:18,199 --> 00:34:21,480 for me to, you know, get, you know, it's, it's probably an 562 00:34:21,480 --> 00:34:22,880 ongoing thing, right? Identities are forever and 563 00:34:22,880 --> 00:34:23,920 there's always something new coming in. 564 00:34:23,920 --> 00:34:26,199 But what's a reasonable expectation say, OK, I've got 565 00:34:26,199 --> 00:34:30,679 this thing set up and now I've got some actionable data to do 566 00:34:30,679 --> 00:34:33,639 things with. Is it days, weeks, months? 567 00:34:33,639 --> 00:34:36,960 And the curveball in there is how long do you think is 568 00:34:36,960 --> 00:34:40,080 appropriate to detect what I would call, you know, abnormal 569 00:34:40,080 --> 00:34:42,880 behaviour? Is it based on the account the 570 00:34:42,880 --> 00:34:44,280 person, right? There's, there's always that 571 00:34:44,280 --> 00:34:46,199 kind of tuning period, right? So, OK, well, what is normal for 572 00:34:46,199 --> 00:34:47,719 Jeff? Well, Jeff's never normal. 573 00:34:47,719 --> 00:34:49,560 So he doesn't fit into a bucket right? 574 00:34:50,880 --> 00:34:53,520 Yeah. So I think one of those things 575 00:34:53,520 --> 00:35:00,160 that we do uniquely is we're able to ingest historical data 576 00:35:00,440 --> 00:35:01,960 that you already have in your environment. 577 00:35:01,960 --> 00:35:07,080 So a lot of companies have data in their SIM in S3 and so on. 578 00:35:07,080 --> 00:35:10,360 We can ingest that data the moment you connect to us. 579 00:35:10,640 --> 00:35:14,440 And so you can get behavioral information out-of-the-box 580 00:35:14,480 --> 00:35:19,280 immediately, within 24 hours from when you connect to the 581 00:35:19,280 --> 00:35:22,280 environment. The setup itself takes less than 582 00:35:22,280 --> 00:35:24,080 15 minutes. You give us credentials for your 583 00:35:24,080 --> 00:35:29,880 environment and we provision it automatically if it's a cloud 584 00:35:29,880 --> 00:35:32,600 based solution. If it's on Prem, you deploy our 585 00:35:32,600 --> 00:35:36,160 collector which is a docker image and the collector starts 586 00:35:36,160 --> 00:35:41,240 to stream data to us. OK. 587 00:35:41,320 --> 00:35:43,880 So is this something that you can maybe walk us through and 588 00:35:43,880 --> 00:35:45,640 kind of show this how this works? 589 00:35:46,560 --> 00:35:51,200 Yeah, absolutely. I think forgiven that this is a 590 00:35:51,200 --> 00:35:55,360 podcast, I'll try to keep this as brief as possible and not 591 00:35:55,360 --> 00:35:58,480 particularly in in try not to bore people. 592 00:35:58,760 --> 00:36:04,800 But basically once you connect to the to the environment, this 593 00:36:04,800 --> 00:36:08,560 is the typical, typical view you would have for an identity. 594 00:36:10,400 --> 00:36:12,560 As you can see here, this is a AWS role. 595 00:36:12,680 --> 00:36:15,040 It's it's an NHI. We tell you automatically you 596 00:36:15,040 --> 00:36:19,960 created the role, but I mentioned earlier that we use 597 00:36:19,960 --> 00:36:24,720 LLMS to improve kind of like the the readability of this data and 598 00:36:24,720 --> 00:36:27,560 the visibility. So you can see here that our LLM 599 00:36:27,560 --> 00:36:30,880 can automatically generate a description for this role to 600 00:36:30,880 --> 00:36:33,640 tell you exactly what the role does and can do in your 601 00:36:33,640 --> 00:36:35,720 environment. So for our. 602 00:36:35,840 --> 00:36:37,960 People who are listening, I guess I'm looking at like this 603 00:36:37,960 --> 00:36:40,080 dashboard, right? And it's it's essentially 604 00:36:40,080 --> 00:36:44,840 pulling in AWS information and then and then you're doing 605 00:36:44,840 --> 00:36:47,080 things against that, right? You mentioned the LLM and coming 606 00:36:47,080 --> 00:36:50,600 up with, you know, probably more human friendly descriptions of 607 00:36:50,600 --> 00:36:53,040 what things happening on, you know, going into this interface. 608 00:36:53,040 --> 00:36:56,120 And then so OK, I have a bunch of triggers and configures that 609 00:36:56,120 --> 00:36:58,400 I can do right? Yep, Yeah, exactly. 610 00:36:58,400 --> 00:37:02,280 And I mean if you if you take sort of like this, this role 611 00:37:02,280 --> 00:37:04,480 here, like the role doesn't tell us that much. 612 00:37:04,480 --> 00:37:07,880 It's called AWS service role for Amazon, even bridge API 613 00:37:07,880 --> 00:37:11,200 destinations. That's not like super helpful. 614 00:37:11,360 --> 00:37:15,000 Having a human readable description of what this thing 615 00:37:15,000 --> 00:37:17,800 can actually do is already quite helpful. 616 00:37:18,000 --> 00:37:20,880 As I mentioned, you can suspend this role, delete this role. 617 00:37:20,880 --> 00:37:25,760 You can do a bunch of actions on the role and we discussed a bit 618 00:37:25,760 --> 00:37:31,520 about like the the ability to help IGA processes when it comes 619 00:37:31,520 --> 00:37:33,800 to reducing excessive permissions. 620 00:37:34,080 --> 00:37:39,840 You can see here that we can look back in the log data and 621 00:37:39,840 --> 00:37:45,160 see which permissions haven't been used by this role in some 622 00:37:45,160 --> 00:37:46,720 period of time where it's configurable. 623 00:37:47,240 --> 00:37:52,760 And then you can ask our LLM to generate a appropriate policy 624 00:37:52,760 --> 00:37:56,760 that we actually verify in the environment to make sure that 625 00:37:57,880 --> 00:38:00,640 we're not accidentally sort of like removing privileges. 626 00:38:00,800 --> 00:38:06,800 So here you see a full blown AWS policy that is tailored to this 627 00:38:06,800 --> 00:38:10,560 role and achieves least privilege based on the past 628 00:38:10,560 --> 00:38:13,000 seven days of data. So that's one you there's like 629 00:38:13,000 --> 00:38:17,560 functionality from like a Kim system or CIE cloud 630 00:38:17,560 --> 00:38:19,360 infrastructure entitlement management. 631 00:38:20,640 --> 00:38:24,800 So the the the core difference here is that most of the Kim 632 00:38:24,800 --> 00:38:29,960 systems try to tell you what entitlements haven't been used, 633 00:38:29,960 --> 00:38:31,640 but they don't help you with remediation. 634 00:38:32,560 --> 00:38:35,920 Can you do the same thing from other cloud platforms like 635 00:38:35,920 --> 00:38:39,040 Google Cloud as well as Microsoft Azure? 636 00:38:39,400 --> 00:38:42,040 Yes, that's the other powerful, that's the other big 637 00:38:42,040 --> 00:38:45,680 differentiator. We can do it across all the 638 00:38:45,680 --> 00:38:49,080 providers that we support. It's not just AWS specific. 639 00:38:50,000 --> 00:38:54,760 And so you have the same least privilege capabilities across 640 00:38:54,760 --> 00:38:58,040 all the environments. So you click this button that 641 00:38:58,040 --> 00:39:02,440 said get recommendation and then that's where the LLM is chunking 642 00:39:02,440 --> 00:39:04,600 through the data and saying OK, well what should we do about 643 00:39:04,600 --> 00:39:06,320 that? I guess explain me more what 644 00:39:06,320 --> 00:39:08,280 that get recommendation button did on the screen. 645 00:39:08,560 --> 00:39:10,560 Yeah. What that does is it looks at 646 00:39:10,560 --> 00:39:14,160 the historical data, it looks at the existing entitlements for 647 00:39:14,160 --> 00:39:18,400 that identity. It removes all the entitlements 648 00:39:18,400 --> 00:39:22,760 that have not been used in the the period of time you selected, 649 00:39:22,760 --> 00:39:27,240 which can be one day, seven days up to like 90 days. 650 00:39:28,520 --> 00:39:34,320 And what we then do is verify that policy before showing that 651 00:39:34,320 --> 00:39:37,200 to you because obviously, as you know, LLMS can hallucinate. 652 00:39:37,480 --> 00:39:41,000 And so we want to make sure that the policy is actually well 653 00:39:41,000 --> 00:39:44,080 formed and is not accidentally breaking anything in your. 654 00:39:44,080 --> 00:39:47,560 Environment and then basically what you see is like this 655 00:39:47,720 --> 00:39:48,760 essentially like a script, right? 656 00:39:48,760 --> 00:39:51,800 Like here's what we're going to do and then I take that 657 00:39:51,800 --> 00:39:54,680 information, then I can either run it individually or can I 658 00:39:54,680 --> 00:39:56,960 click another button that says, OK, do that. 659 00:39:57,040 --> 00:39:58,760 How would you automate that part of it? 660 00:39:59,280 --> 00:40:03,760 So what you can do is to use use our APIs to automatically deploy 661 00:40:04,680 --> 00:40:06,720 this across across your environments. 662 00:40:07,120 --> 00:40:13,800 I mean, one thing that occurs to me is that this gets you a good 663 00:40:13,960 --> 00:40:18,200 way toward your lease privilege policy. 664 00:40:18,440 --> 00:40:20,880 Didn't get you all the way there, but lease privilege is so 665 00:40:20,880 --> 00:40:25,120 hard to achieve that if you can at least start to clean up 666 00:40:25,520 --> 00:40:29,200 unused roles, roles that you're not even using, that shouldn't 667 00:40:29,200 --> 00:40:33,200 exist in the environment, and this takes you a step closer to 668 00:40:33,200 --> 00:40:35,160 that. Yeah. 669 00:40:35,160 --> 00:40:38,000 And the way we think about it from a, from a security 670 00:40:38,000 --> 00:40:41,560 standpoint is what we're doing here is really reducing the 671 00:40:41,560 --> 00:40:44,080 options for our attacker to move laterally in your environment. 672 00:40:44,320 --> 00:40:46,920 They might still breach an identity, but then they won't 673 00:40:46,920 --> 00:40:49,960 have the same degree of entitlements that they would 674 00:40:49,960 --> 00:40:54,280 have otherwise. And so we get to as close as 675 00:40:54,280 --> 00:41:00,880 possible to less privilege, while while at the same time 676 00:41:01,400 --> 00:41:03,320 sort of like being easy, easy to use. 677 00:41:03,320 --> 00:41:08,040 It's not as as big of a lift as something like IGA. 678 00:41:08,480 --> 00:41:13,280 One thought I had about this is, yeah, the the lateral movements, 679 00:41:14,120 --> 00:41:17,000 absolutely. What I would love to see, so you 680 00:41:17,000 --> 00:41:20,160 have my Christmas wish list, would be take this functionality 681 00:41:20,160 --> 00:41:22,960 and bring it to the on Prem environment. 682 00:41:22,960 --> 00:41:26,440 If we could do this for the on Prem environment that would be a 683 00:41:26,440 --> 00:41:28,080 dream come true. Yeah. 684 00:41:28,600 --> 00:41:32,000 So the the good news is that we can already do it for AD. 685 00:41:32,840 --> 00:41:35,400 So we support. We support AD as well. 686 00:41:37,360 --> 00:41:38,480 There you go. That's huge. 687 00:41:39,600 --> 00:41:41,160 That's very cool. So I know it's a little bit of a 688 00:41:41,160 --> 00:41:43,160 visual demo. So for people who wanted to 689 00:41:43,160 --> 00:41:45,000 follow along, we'll have it up on our YouTube channel. 690 00:41:45,000 --> 00:41:47,320 Come and check that out. But definitely appreciate you 691 00:41:47,320 --> 00:41:49,400 taking the time with us. Vincenzo, I want to ask you a 692 00:41:49,400 --> 00:41:50,600 question before you wrap things up. 693 00:41:50,600 --> 00:41:52,320 We, we try to end things on a lighter note and I don't know 694 00:41:52,320 --> 00:41:56,600 how light this will get, but I'm sure you've seen some strange, 695 00:41:56,600 --> 00:42:00,400 unique, scary, baffling things maybe over your your time with 696 00:42:00,440 --> 00:42:02,120 maybe things like Blackhat and so forth. 697 00:42:02,520 --> 00:42:05,960 What is the most memorable thing that you've maybe seen as as 698 00:42:05,960 --> 00:42:08,960 part of, you know, that environment or maybe you know 699 00:42:08,960 --> 00:42:12,000 that that culture of of attackers and defenders? 700 00:42:12,600 --> 00:42:15,720 Yeah, so the, the there are a lot of like interesting stories 701 00:42:15,720 --> 00:42:18,240 that I'm not sure I can talk about, but but I'll, I'll say 702 00:42:18,240 --> 00:42:22,520 one that is dear to my heart because because it was part of 703 00:42:22,520 --> 00:42:24,400 it. So at the beginning of my 704 00:42:24,400 --> 00:42:29,000 career, I start to participate in this competition called .1 705 00:42:29,000 --> 00:42:32,440 where you need to demonstrate a live exploits against either a 706 00:42:32,520 --> 00:42:35,800 mobile phone or browser. And the way this works is you 707 00:42:35,800 --> 00:42:41,160 fly to Vancouver, you have this like 2 days competition live 708 00:42:41,160 --> 00:42:44,120 where like you run your exploit against the device and hopefully 709 00:42:44,120 --> 00:42:48,960 it works and, and, and you win. What happened to us one year was 710 00:42:49,600 --> 00:42:53,480 the vulnerability got patched literally the night before of 711 00:42:53,480 --> 00:42:57,600 the competition. And so we had to stay up like 48 712 00:42:57,600 --> 00:43:01,200 hours straight to find another vulnerability, rewrite the 713 00:43:01,200 --> 00:43:08,520 exploit and try to try to win. It was, it was a very, it was a 714 00:43:08,520 --> 00:43:13,000 very fun experience for us. But I think he also speaks to 715 00:43:14,320 --> 00:43:19,720 sort of like the, the, the, the complexity of like this world 716 00:43:19,840 --> 00:43:24,760 and how hard it is to like keep up with attackers. 717 00:43:25,880 --> 00:43:27,560 Yeah, it's always that cat and mouse game, right? 718 00:43:27,560 --> 00:43:31,880 But I, I don't, I good on them for patching it and then good on 719 00:43:31,880 --> 00:43:35,160 you, I guess fighting and something else that you could 720 00:43:35,160 --> 00:43:37,320 get in through, you know, in a relatively short order. 721 00:43:37,320 --> 00:43:40,120 So I guess that just highlights, right, the speed for the 722 00:43:40,120 --> 00:43:41,920 detection is such an important part of this is, OK, well, how 723 00:43:41,920 --> 00:43:43,640 quickly can we detect something, right? 724 00:43:43,640 --> 00:43:47,160 That dual time is so important and it becomes more important as 725 00:43:47,160 --> 00:43:51,080 we become more automated and more, you know, let's say bot 726 00:43:51,080 --> 00:43:54,600 and AI driven where these things are happening, you know, very, 727 00:43:54,600 --> 00:43:57,720 very quickly, millisecond speed. And so it can be very difficult 728 00:43:57,720 --> 00:43:59,960 to kind of detect all that was. Is that a fair assessment? 729 00:44:00,320 --> 00:44:05,480 Yes, I like on on on that front. One thing that I think flew 730 00:44:05,480 --> 00:44:09,960 under the radar a bit too much, but recently the Microsoft 731 00:44:10,200 --> 00:44:15,240 Research team used an LLM to find vulnerabilities in bunch of 732 00:44:15,240 --> 00:44:21,080 book loaders. The scary thought is we might be 733 00:44:21,080 --> 00:44:25,080 getting to a point where finding vulnerabilities is actually very 734 00:44:25,080 --> 00:44:29,000 quick, very fast. And so attackers will have two 735 00:44:29,000 --> 00:44:31,640 levers that they can use. On the one hand, it's much 736 00:44:31,640 --> 00:44:36,320 easier to fish people because I get fishing these days is is 737 00:44:36,920 --> 00:44:39,000 almost impossible to to to tell apart. 738 00:44:39,160 --> 00:44:42,280 And then on the other hand, the factor that you use to 739 00:44:42,280 --> 00:44:47,040 compromise is now much easier to to deploy because it's easier to 740 00:44:47,040 --> 00:44:51,240 find vulnerabilities. So I think LMS on the offensive 741 00:44:51,240 --> 00:44:56,000 side are somewhat scary just for the the increasing pace and 742 00:44:56,680 --> 00:44:59,680 making it hard to detect. Yeah. 743 00:44:59,680 --> 00:45:02,280 I mean, gone are the poorly written emails and text 744 00:45:02,280 --> 00:45:04,120 messages, Yeah, with second language. 745 00:45:04,120 --> 00:45:06,560 And now it's, yeah, like I said, very, very difficult to detect. 746 00:45:06,560 --> 00:45:08,520 And it's going to happen at some point. 747 00:45:08,520 --> 00:45:11,360 So you know what, the AIS fight each other and then just let me 748 00:45:11,360 --> 00:45:13,880 know who wins sort of at the end. 749 00:45:14,840 --> 00:45:16,240 Definitely appreciate you taking time with us. 750 00:45:16,240 --> 00:45:18,840 Vincenzo, is there anything that you'd like to get out for people 751 00:45:18,840 --> 00:45:21,520 that we haven't covered yet that the people should know about 752 00:45:21,520 --> 00:45:25,080 Slash ID? No, I think, I think we we 753 00:45:25,080 --> 00:45:28,960 covered everything. I will say maybe one last thing, 754 00:45:28,960 --> 00:45:33,000 which is Jim mentioned that achieving these privileges is 755 00:45:33,000 --> 00:45:35,480 very hard. One of our maybe contrarian 756 00:45:35,480 --> 00:45:37,960 beliefs is that achieving these privileges is impossible, which 757 00:45:37,960 --> 00:45:40,400 is the reason why you need detection and response 758 00:45:40,400 --> 00:45:43,360 capabilities because you'll never be at a place where 759 00:45:43,360 --> 00:45:45,760 everything is perfect. Everything is properly segmented 760 00:45:45,760 --> 00:45:47,920 from under 19 standpoint. And so you need to have the 761 00:45:47,920 --> 00:45:50,360 ability to detect and response and respond to attacks. 762 00:45:51,600 --> 00:45:53,840 I, I can, I can, I can definitely agree with that. 763 00:45:53,840 --> 00:45:56,360 I think, you know, perfection is very difficult to achieve. 764 00:45:56,360 --> 00:45:58,120 So you need something to detect the stuff. 765 00:45:58,120 --> 00:46:00,400 So I'm on board with that one for sure. 766 00:46:00,400 --> 00:46:05,800 So we'll point people to the website slashid.com/IDAC. 767 00:46:05,920 --> 00:46:08,160 We'll have that in our show notes as well as your LinkedIn 768 00:46:08,160 --> 00:46:10,920 profile if people want to reach out, have questions, you know, 769 00:46:10,920 --> 00:46:13,240 maybe share a, a Black Hat war story or two, whatever that 770 00:46:13,240 --> 00:46:15,440 might look like. So definitely, again, appreciate 771 00:46:15,440 --> 00:46:18,000 you taking time with us and thanks everybody for watching 772 00:46:18,000 --> 00:46:20,240 and or listening. So you can find us on the web, 773 00:46:20,440 --> 00:46:24,920 IDC, podcast.com and yeah, we'll talk with everyone and the next 774 00:46:24,920 --> 00:46:25,880 one. Thank you both. 775 00:46:28,440 --> 00:46:31,400 You've been listening to Identity at the Center. 776 00:46:31,760 --> 00:46:35,840 We hope you've enjoyed the show. Make sure to like, rate and 777 00:46:35,840 --> 00:46:39,480 review, and we'll be back soon. But in the meantime, hit the 778 00:46:39,480 --> 00:46:42,880 website at identity@thecenter.com. 779 00:46:43,480 --> 00:46:47,600 See you next time on Identity at the Center.