1 00:00:14,080 --> 00:00:18,280 All right, here we go. Welcome everyone to another episode of Adventures and 2 00:00:18,399 --> 00:00:22,039 deva Ops. I'm your host, Will Button and today joining me in the 3 00:00:22,079 --> 00:00:27,359 studio our special guest Ory Moncli. How are you or very well? Nice 4 00:00:27,399 --> 00:00:31,679 to speak to you, you too, welcome, Welcome. Can you give 5 00:00:31,719 --> 00:00:37,479 us a little introduction, a little bit about your background? Sure? Absolutely? 6 00:00:37,880 --> 00:00:43,479 First of all, I'm doing software development and anything related to tech since 7 00:00:43,520 --> 00:00:48,200 I was since I can remember myself, sally. It was just a hobby 8 00:00:49,159 --> 00:00:55,799 a long time, it became a profession and last twenty plus years I'm doing 9 00:00:55,840 --> 00:01:00,320 different kinds of engineering work in the industry, starting as a software developed and 10 00:01:00,439 --> 00:01:06,400 in the recent years i'm mostly managing development teams. My current position, I'm 11 00:01:06,719 --> 00:01:15,239 heading the engineering team at a Kinness in Security. Still enjoying writing software and 12 00:01:15,319 --> 00:01:19,879 learning more about different areas of technologies, things that are renewing all the time. 13 00:01:19,640 --> 00:01:23,799 So that's my passion and that's what I do for a living, right, 14 00:01:23,879 --> 00:01:27,680 And that's a hard balance, having a management role but still being able 15 00:01:27,719 --> 00:01:36,040 to maintain or enjoy your technical skills. Agree. I mean, I can 16 00:01:36,120 --> 00:01:42,000 see that management is an easy gateaway for somebody that doesn't love doing something like 17 00:01:42,079 --> 00:01:47,599 that, and kind of switching roles to something else for me out of choice. 18 00:01:47,920 --> 00:01:51,760 I'm trying to keep myself up to date. I'm very down to the 19 00:01:51,840 --> 00:01:56,359 details. I like to keep maybe small projects not in the critical path of 20 00:01:56,680 --> 00:02:00,159 the development, still keeping my hands dirty and doing some work. But it's 21 00:02:00,200 --> 00:02:04,519 a matter of choice eventually, if you like it and you find the time 22 00:02:04,560 --> 00:02:07,400 to do it, Yeah, for sure, for sure. So one of 23 00:02:07,439 --> 00:02:13,919 the things we're going to talk about today was security in the CICD pipeline. 24 00:02:15,479 --> 00:02:21,319 Right right, I mean security, This to me comes with the context of 25 00:02:21,400 --> 00:02:27,039 doing things the right way, sometimes corredated to doing things a little bit slower 26 00:02:27,080 --> 00:02:31,319 than usual because it has to be the right way, and a lot of 27 00:02:31,360 --> 00:02:36,280 hurdles for their teams. Right, you need to do things, You need 28 00:02:36,319 --> 00:02:42,159 to get confirmation from different authorities making sure that this is appropriate. This is 29 00:02:42,199 --> 00:02:46,919 according to the standards, according to whatever rule least privilege, zero, standing 30 00:02:47,039 --> 00:02:53,599 credentials, et cetera. Our job at a Kills, among other things, 31 00:02:53,759 --> 00:03:00,680 is to make the security standards high, or keep the security standards high without 32 00:03:00,039 --> 00:03:05,560 the negative impact on velocity, like making it simple, making it easy, 33 00:03:05,960 --> 00:03:10,199 and in some cases making it even easier than usual. Path right, instead 34 00:03:10,240 --> 00:03:15,960 of thinking where I should store this whatever, a secret, whatever piece of 35 00:03:15,000 --> 00:03:21,159 information that I have, what would be the right repository, the right storage. 36 00:03:21,639 --> 00:03:24,479 Now you have a place to do that, and it integrates well with 37 00:03:24,599 --> 00:03:32,520 a lot of technologies, authentication types, different infrastructures, platforms, cloud, 38 00:03:32,520 --> 00:03:38,080 the providers, etc. Yeah, for sure. And I think the like 39 00:03:38,159 --> 00:03:44,360 putting it in cic D, I think really opens up some interesting possibilities for 40 00:03:44,400 --> 00:03:47,439 you because then you can automate it, and I think that's where security really 41 00:03:49,280 --> 00:03:52,599 I think that's really where you can start to gain ground on security. Like 42 00:03:52,639 --> 00:03:59,039 you mentioned, if you can make the right thing the easier choice than doing 43 00:03:59,080 --> 00:04:03,039 it the wrong way, that's really where you start to see the gains from 44 00:04:03,080 --> 00:04:09,599 that. Yeah. Absolutely. I think that in the recent years we see 45 00:04:09,680 --> 00:04:15,439 a lot of growth and adoption of a lot of develop tools, develops, 46 00:04:15,439 --> 00:04:21,120 tool change, should I say, things related starting from configuration management to CICD, 47 00:04:21,240 --> 00:04:28,199 platforms, container orchestrations. A lot of technologies evolving in this domain, 48 00:04:29,319 --> 00:04:35,199 and this becomes a very convenient tool for automation, not necessarily just for releasing 49 00:04:35,240 --> 00:04:42,360 an artifact production, but also to have like jobs to help maintaining the usual 50 00:04:42,439 --> 00:04:48,399 work the build environment, and related to that, and as such, it 51 00:04:48,519 --> 00:04:55,240 becomes an interesting target for potential hackers. Right, if you gain access to 52 00:04:55,279 --> 00:05:01,120 this centralized platform that has access to your cloud service, provide to databases in 53 00:05:01,160 --> 00:05:06,639 the organization, a lot of that, that's that's an easy target for hacking 54 00:05:06,879 --> 00:05:13,279 credentials and accessing those systems. That's what I think we should we should, 55 00:05:13,519 --> 00:05:16,800 Yeah, we should look at when when talking about security, how to protect 56 00:05:16,920 --> 00:05:25,240 the identities, workload identities, how to protect different environments. Uh, and 57 00:05:25,319 --> 00:05:30,519 to do that without adding overhead on the process. Yeah, right on. 58 00:05:31,279 --> 00:05:40,000 So what would be your for someone who's just acknowledging the security should be part 59 00:05:40,120 --> 00:05:45,480 of your organization? What would be the number one thing you would point the 60 00:05:45,519 --> 00:05:50,720 map first, or the first thing to say, hey start here. Ideally 61 00:05:51,160 --> 00:05:57,759 it would be mapping what kind of sensitive information, sensitive data? What kind 62 00:05:57,759 --> 00:06:04,959 of different identities and permissions you have spread across your systems? Because creating identities 63 00:06:04,959 --> 00:06:11,439 and giving access is very easy, right. You simply create another application, 64 00:06:11,480 --> 00:06:15,079 another tool, I request access, and all of a sudden it fails up 65 00:06:15,120 --> 00:06:21,279 with touns of identities without much of control over it. Like when I ask 66 00:06:21,639 --> 00:06:28,720 a develops person how many applications do you have and what kind of permissions each 67 00:06:29,120 --> 00:06:33,720 in every application has to perform on a different type of infrastructure. That's not 68 00:06:33,800 --> 00:06:41,639 a simple question to answer because in many cases you simply don't have the visibility. 69 00:06:42,959 --> 00:06:47,160 This problem is sometimes referred to as a secret sproll problem because you have 70 00:06:47,199 --> 00:06:55,240 a lot of different storages to maintain secrets, to keep access, different different 71 00:06:55,319 --> 00:07:00,519 kinds of ways to manage policies access policies. One cloud provider, you have 72 00:07:00,800 --> 00:07:06,680 different type of language and annotation and other type of infrastructure of different things, 73 00:07:06,680 --> 00:07:13,439 So it becomes a lot of know how on how to manage it, and 74 00:07:13,480 --> 00:07:18,319 in many cases it's kept in a very selected few individuals' minds where to set 75 00:07:18,680 --> 00:07:29,480 what Talking about dashboards and visibility to executive level is something that very rarely found, 76 00:07:29,959 --> 00:07:32,680 So identifying where the sensitive data is would be the number one step. 77 00:07:32,720 --> 00:07:38,120 I think, yeah, that makes a lot of sense, because I think 78 00:07:38,519 --> 00:07:45,720 from my own perspective, my gut reaction to any problem is to start building 79 00:07:45,759 --> 00:07:50,519 something to solve that problem. But actually taking a step back and documenting where 80 00:07:50,560 --> 00:07:58,079 this problem exists, where it's used, would change the perspective because then you 81 00:07:58,160 --> 00:08:01,720 kind of have a better understand of the size and the scope of the problem 82 00:08:01,720 --> 00:08:09,800 that you're trying to solve exactly. I would say that afterwards, once you 83 00:08:09,839 --> 00:08:16,639 have that mapped, you probably want to sort them by the most impactful type 84 00:08:16,639 --> 00:08:22,759 of identities to the listed platforms, right, which one has access to many 85 00:08:22,800 --> 00:08:28,720 resources, privileged access, et cetera, and then try to deal with them 86 00:08:28,759 --> 00:08:35,600 first, because the virtual blast reduce should I say, of somebody's accessing those 87 00:08:35,639 --> 00:08:45,080 can be the most significant negatively significant to the organization. Ideally, you don't 88 00:08:45,120 --> 00:08:50,120 want to maintain something that is lasting forever, right, So any type of 89 00:08:52,360 --> 00:08:58,039 credential, any type of access, should be limited in time for a reasonable 90 00:08:58,120 --> 00:09:03,600 duration. When I say reasonable, it cannot be ten years or fifteen years, 91 00:09:03,639 --> 00:09:07,039 because in that time you can do a lot of them. I'm talking 92 00:09:07,080 --> 00:09:11,200 in many cases minutes maybe hours to perform some kind of tasks, but not 93 00:09:11,360 --> 00:09:18,919 much more than that. Yeah, you know, it was just about a 94 00:09:18,039 --> 00:09:28,120 year ago I stumbled across the open id connect, I think OIDC and I 95 00:09:28,039 --> 00:09:33,559 haven't really seen it talked about a lot in many places, but I've actually 96 00:09:33,559 --> 00:09:39,360 fallen in love with it, and we've updated a bunch of our infrastructure to 97 00:09:39,559 --> 00:09:43,840 use that for that specific reason, Because whenever you go to take an action, 98 00:09:43,720 --> 00:09:48,440 the OIDC gets a set of short lived tokens and then you can scope 99 00:09:48,480 --> 00:09:56,919 those scope the access permissions for those credentials down to just the exact deployment that 100 00:09:56,000 --> 00:10:00,000 you're dealing with at that time. And I thought that was such a cool 101 00:10:00,240 --> 00:10:03,159 idea. It's relatively easy to implement, but it doesn't seem to be very 102 00:10:03,200 --> 00:10:09,480 popular. Yeah, I think O I d C is positioning as one of 103 00:10:09,519 --> 00:10:18,279 the slowly but one of the most popular authentication methods for humans. It's in 104 00:10:18,320 --> 00:10:22,399 my opinions, it's second to summon, which is more legacy one but still 105 00:10:22,799 --> 00:10:28,799 very widely used. But I think that over time we will start to see 106 00:10:28,840 --> 00:10:33,399 more and more. This is kind of the evolution of some and we start 107 00:10:33,440 --> 00:10:37,960 to see more and more relying on O I d C. The foundation or 108 00:10:39,000 --> 00:10:46,600 the underlying technology is basically all OFF or JOT authentication, which is very popular 109 00:10:46,679 --> 00:10:54,440 for application type of authentication. A lot of c CD platforms today are providing 110 00:10:54,639 --> 00:11:03,240 a temporary signed job that can be used to verify to identify the actual runner 111 00:11:05,039 --> 00:11:09,600 and the right context of what kind of project idea, who trigger the job 112 00:11:09,919 --> 00:11:18,080 or what kind of resources running, et cetera, and all those attributes both 113 00:11:18,120 --> 00:11:26,399 coming from Native job authentication or YDC can be leveraged for access permissions, and 114 00:11:26,440 --> 00:11:31,480 that's very handy. Like imagine that you log into a platform and all of 115 00:11:31,519 --> 00:11:37,759 a sudden you have all the types of permission associated with your identity without the 116 00:11:37,879 --> 00:11:43,600 need or the operational hussle of managing those same permissions in two different platforms, 117 00:11:43,720 --> 00:11:50,360 one being the actual infrastructure, the other one being the secret management site. 118 00:11:50,559 --> 00:11:54,720 Right, So basically take the same like if you modify something in your IDP, 119 00:11:54,679 --> 00:12:01,159 the identity provider automatically, it reflects to the same its management and the 120 00:12:01,200 --> 00:12:07,519 access permissions you have there. So from an administrative perspective of managing identities, 121 00:12:07,559 --> 00:12:16,120 that's a very easy and convenient approach where identities live only in one place according 122 00:12:16,120 --> 00:12:26,039 to one policy. Yeah, and that's there's just so many, so many 123 00:12:26,080 --> 00:12:28,360 wins to take away from that. The security team loves it, but also 124 00:12:30,200 --> 00:12:35,919 just the it and the support folks like it too because then it's just less 125 00:12:35,000 --> 00:12:41,559 chainsaws to be juggling at the same time. Absolutely absolutely, And I think 126 00:12:41,600 --> 00:12:48,559 another thing that I was talking about the adoption of different tools and technologies to 127 00:12:48,600 --> 00:12:56,279 the develops environment, and one thing that still is not there is the unification 128 00:12:56,440 --> 00:13:00,960 of those tools. In terms of visibility, Okay, how many many tools 129 00:13:01,000 --> 00:13:05,840 you have, how many different users, both human users and applications are using 130 00:13:05,879 --> 00:13:11,039 specific flows, et cetera. The fact that you're using a centralized platform for 131 00:13:11,240 --> 00:13:20,080 secrets management is giving you implicitly giving you visibility to all types of activities in 132 00:13:20,120 --> 00:13:22,720 the develops world. Right, so you can see, oh, this client 133 00:13:22,799 --> 00:13:30,159 is connecting from CICD platform disguise, this application is connecting through a communities cluster, 134 00:13:30,879 --> 00:13:35,879 this flow is coming from configuration management. This is a human authenticating to 135 00:13:35,000 --> 00:13:43,480 my Jenkins webuy wherever it may be. But because of the fact that any 136 00:13:43,679 --> 00:13:52,639 entity requires access to secrets, this gives you implicitly a wide visibility to what's 137 00:13:52,639 --> 00:13:58,320 going on inside your organization. And that's gold for security officers because there is 138 00:13:58,320 --> 00:14:03,000 no other way that I can think of to see all those activities coming from 139 00:14:03,080 --> 00:14:05,279 different platforms. Maybe in one infrastructure, like if you're running on a single 140 00:14:05,279 --> 00:14:11,000 cloud provider in a single flow, maybe that is another way to see that. 141 00:14:11,080 --> 00:14:13,559 But if you're multi cloud or hybrid, if you're using different kinds of 142 00:14:13,600 --> 00:14:18,039 tools in different locations, the only good way to show that it might be 143 00:14:18,200 --> 00:14:24,799 it would be through secrets Management Central. Yeah, so the secret manager at 144 00:14:24,799 --> 00:14:31,200 that point not only becomes the source restoring your secrets, but also the like 145 00:14:31,279 --> 00:14:37,559 the audit tool for defining the footprint and and use of the secrets across it 146 00:14:37,879 --> 00:14:43,559 entire organization. Agreed, Yeah, hundred percent. And maybe as an evolution 147 00:14:43,279 --> 00:14:50,360 as a next step, applying some kind of AI based logic on this audit 148 00:14:50,440 --> 00:14:58,200 log can detect different kinds of anomalies, like this activity is not something usual 149 00:14:58,320 --> 00:15:01,759 for this time of day, or is a day of week or something like 150 00:15:01,840 --> 00:15:07,720 that. The number of requests here seems unusual with respect to previous weeks. 151 00:15:07,840 --> 00:15:13,960 This application is behaving really in terms of accessing different kinds of secrets. And 152 00:15:15,480 --> 00:15:20,440 maybe, I mean it's not something that is part of modern solutions as far 153 00:15:20,480 --> 00:15:22,399 as I know today. But maybe as a next step, this could be 154 00:15:22,440 --> 00:15:31,080 interesting in helping humans detecting breaches. Security breaches attacks something that would be hard 155 00:15:31,120 --> 00:15:35,159 to detect otherwise. Oh for sure, that's actually a pretty cool idea. 156 00:15:37,000 --> 00:15:45,159 So if let's talk a little bit about how you gain like support and sponsorship 157 00:15:45,240 --> 00:15:48,480 for this type of project. If you want to do the full audit to 158 00:15:48,519 --> 00:15:56,000 gain to improve your security plusture, what are some of the tools or stories 159 00:15:56,039 --> 00:16:00,799 that someone should be thinking about to help sell the to their management team and 160 00:16:02,440 --> 00:16:06,840 get people on board with it. Yeah. I think that this can be 161 00:16:06,840 --> 00:16:18,000 approached in two ways. One from the security perspective, identifying areas and technologies 162 00:16:18,000 --> 00:16:26,440 that are not well protected today and defining what would be the impact if specific 163 00:16:26,559 --> 00:16:33,320 credential specific identities would be exposed or breached. That's one motivation. Another one 164 00:16:33,360 --> 00:16:41,879 is to facilitate as I mentioned, unified view from an operational perspective. A 165 00:16:41,919 --> 00:16:48,919 third approach would be to meet with certain requirements to compliance regulations, etc. 166 00:16:49,759 --> 00:16:53,600 Like in order to be compliant to a certain standard, you have to have 167 00:16:53,639 --> 00:17:03,519 something like that, so different triggers by different business units. And also about 168 00:17:03,519 --> 00:17:07,240 the model, I think that model that you tell you you took about sponsoring 169 00:17:07,319 --> 00:17:15,200 that this can be sponsored by the main driver, some kind of centralized entity 170 00:17:15,200 --> 00:17:22,680 in the organization like the CSO or the CIO or something like that can also 171 00:17:22,720 --> 00:17:29,400 be done by the IT department if we're talking about the operational side of things, 172 00:17:30,720 --> 00:17:34,880 and it can also be shared shared sponsorship in a sense that it's very 173 00:17:34,960 --> 00:17:45,319 easy to know on using a centralized platform, which departments or which applications consume 174 00:17:45,960 --> 00:17:53,559 services from the secrets management. So ideally you can divide the payment based on 175 00:17:53,640 --> 00:17:59,240 internal shared model internal to the organization to say, okay, the department that 176 00:17:59,359 --> 00:18:04,480 is using the most would carry most of the costs of that sharing. So 177 00:18:07,839 --> 00:18:11,519 putting like the you know, the dollars aside for a moment, I think 178 00:18:11,559 --> 00:18:17,680 that the motivation can come from different angles. Each organization that we see is 179 00:18:17,720 --> 00:18:22,000 coming from a different reason, or maybe a combination of different reasons. But 180 00:18:22,079 --> 00:18:30,160 it's definitely definitely becoming a defacto standard for large organizations and getting lower and lower. 181 00:18:30,160 --> 00:18:34,480 Like if in the beginning it was just for large enterprises or corporates, 182 00:18:34,920 --> 00:18:42,680 Today we see even SMBs asking about secrets management because it's obvious that you should 183 00:18:42,759 --> 00:18:51,759 have some solution. Yeah, for sure, Like the number of stories that 184 00:18:51,839 --> 00:18:57,119 we hear about every day just keeps growing. It seems like the people who 185 00:18:57,119 --> 00:19:03,519 are actually impacted most by that are the SMBs. You know. The enterprises 186 00:19:03,599 --> 00:19:10,680 I think typically have a larger they have more people, more resources to work 187 00:19:10,720 --> 00:19:14,680 with, so maybe they're a little bit better positioned. But you just here 188 00:19:14,720 --> 00:19:19,079 a day after day of small and medium businesses that have been shut down, 189 00:19:19,200 --> 00:19:29,319 locked out, or been unable to continue business because of security breaches. Yeah, 190 00:19:29,599 --> 00:19:33,240 and bridges is not something that happens once. And that's it. I 191 00:19:33,279 --> 00:19:42,240 mean the fact that hacker gains access to even side applications something that looks maybe 192 00:19:42,319 --> 00:19:48,559 less relevant. There is the lateral movement, you know, like when you're 193 00:19:48,559 --> 00:19:52,920 starting small and expanding the knowledge and gaining more and more access and more and 194 00:19:52,000 --> 00:20:00,559 more possession of infrastructure and resources inside organization and waiting for this special moment doomsday, 195 00:20:00,680 --> 00:20:06,119 when something like that is exploding, and when it explodes them it becomes 196 00:20:06,119 --> 00:20:14,119 a big business problem for this particular vendor or this particular organization. So detecting 197 00:20:14,160 --> 00:20:18,359 it when it's still small, relatively small, and the impact is still scoped 198 00:20:18,880 --> 00:20:27,279 and known. The ability to detect and also remediate that problem right by restricting 199 00:20:27,319 --> 00:20:33,599 access to this application, rotating set of credentials, revoking access to certain applications, 200 00:20:34,400 --> 00:20:41,559 all that is very important in the process of securing the organization. And 201 00:20:41,599 --> 00:20:45,119 that ties right back into the mapping exercise that you mentioned at the start of 202 00:20:45,119 --> 00:20:51,160 the episode, because now you know what credentials this application use, what services 203 00:20:51,160 --> 00:20:56,759 it talks to, and where else those components are used in your infrastructure. 204 00:20:59,000 --> 00:21:03,440 Yes, an interesting concept that I think that is getting more and more attraction 205 00:21:03,839 --> 00:21:08,720 of the time is the use of just in time credentials. Historically, like 206 00:21:08,799 --> 00:21:17,440 if you're at many years in the industry like myself, the war files configuration 207 00:21:17,519 --> 00:21:23,559 files with static credentials using m passwords, token's API keys, and typically they 208 00:21:23,680 --> 00:21:30,319 lasted four years. If somebody got a got a view of them, they 209 00:21:30,319 --> 00:21:36,519 can keep using them without any ability to detect that This is a misuse right 210 00:21:36,559 --> 00:21:40,960 from if you look from the back inside of the service side perspective, it's 211 00:21:41,200 --> 00:21:45,680 a value authentication of an authorized entity. What we see more and more is 212 00:21:45,720 --> 00:21:52,880 that there is no reason to have standing privileges in systems across the environment. 213 00:21:52,440 --> 00:22:00,839 Okay, only when an application argument needs access for a certain reason for a 214 00:22:00,880 --> 00:22:07,079 certain task. Only then the credentials will be generated, and they will also 215 00:22:07,119 --> 00:22:11,440 be a thermeral like meaning they have time to lead. They have a duration 216 00:22:11,640 --> 00:22:17,720 that after this time they will be revoked automatically without any human intervention in the 217 00:22:17,759 --> 00:22:23,240 process. And that model is becoming more and more popular for two main reasons. 218 00:22:23,279 --> 00:22:30,119 One is the impact like if I forget my workstation open, if somebody 219 00:22:30,480 --> 00:22:34,160 grabs access to a certain set of credentials, they can do so much with 220 00:22:34,240 --> 00:22:40,880 it until they expire. But secondly, it's also enforcing the use of a 221 00:22:40,920 --> 00:22:44,839 centralized system. Imagine that we're talking about humans, and humans are very lazy 222 00:22:44,839 --> 00:22:48,200 by nature, and that's very normal, and they say, Okay, why 223 00:22:48,240 --> 00:22:53,480 should I log into a secrets management platform statch and use them password over and 224 00:22:53,559 --> 00:22:59,480 every day and to connect to my database? Right the second time you do 225 00:22:59,559 --> 00:23:00,599 that, you say, hey, I can keep a copy of that because 226 00:23:00,599 --> 00:23:04,240 it's static. I can keep it in my notepad and a story not need 227 00:23:04,559 --> 00:23:10,200 to log in anymore. And that's true if you're talking about static secrets, 228 00:23:10,200 --> 00:23:14,079 But what if there is no static secret anytime you need to get dynamic secret, 229 00:23:14,160 --> 00:23:18,200 then you're basically forced or enforced to do that the right way. Now, 230 00:23:18,359 --> 00:23:25,759 our job is to make it easier and less painful to people like that, 231 00:23:26,079 --> 00:23:30,519 in the sense that there is single sign on integration you mentioned OIDC before 232 00:23:30,559 --> 00:23:34,200 and some and also you don't have to retype over and over your credentials to 233 00:23:34,519 --> 00:23:41,279 get some access. But secondly, it's mostly done by applications, and applications 234 00:23:41,279 --> 00:23:48,519 can use their trusted identities, like if they're running on cloud service providers infrastructure, 235 00:23:48,960 --> 00:23:52,519 they can use the cloud IAM to authenticate to a kill is similitly like 236 00:23:52,599 --> 00:23:56,920 you don't have to have an additional set of credentials. If you're working on 237 00:23:56,039 --> 00:24:03,359 modern infrastructure like Cobernetti's clus, they can use the Cobernetus identities to authenticate similar 238 00:24:03,400 --> 00:24:07,799 stame fetch credentials. So you find ways to make it easy but secure to 239 00:24:08,039 --> 00:24:15,519 authenticate to secretsman on the platform rely on just in time credentials to apply the 240 00:24:15,759 --> 00:24:22,359 principle that don't have so what's called zero standing privileges, and also making sure 241 00:24:23,200 --> 00:24:27,839 that the credentials are biding with the right policy in terms of access the authorization 242 00:24:27,960 --> 00:24:34,119 layer, which means that if here it applies to the principle of least privilege, 243 00:24:34,200 --> 00:24:40,319 you don't provide anything beyond what the application or the human requires for this 244 00:24:40,440 --> 00:24:45,440 particular task. If using standing credentials, you would have to have tons of 245 00:24:45,720 --> 00:24:52,240 sets of users and only a very educated person would pick the right one for 246 00:24:52,359 --> 00:24:56,240 this task. But when you use dynamic secrets or just in time access, 247 00:24:56,680 --> 00:25:00,279 it's very easy because you have access only for read or the operations, only 248 00:25:00,359 --> 00:25:06,279 for specific set of secrets that are required for this application. So it's helping 249 00:25:06,359 --> 00:25:11,160 in so many ways. And I think that this is a trend that we 250 00:25:11,240 --> 00:25:15,279 see more and more, and I think that in a few years time from 251 00:25:15,319 --> 00:25:22,480 now, it would be very rare to see static credentials in production environments. 252 00:25:22,599 --> 00:25:26,880 Yeah, that would be cool, Like like you have been doing this for 253 00:25:26,960 --> 00:25:32,720 a long time, and I remember many times whenever someone would say we need 254 00:25:32,759 --> 00:25:38,039 to rotate these keys, and everyone would just cringe because we knew that it 255 00:25:38,160 --> 00:25:42,079 was going to involve production downtime, because nobody knew where they were used, 256 00:25:42,079 --> 00:25:45,000 and it was going to be painful and we were going to have everyone mad 257 00:25:45,039 --> 00:25:52,640 at us. It's a huge project for many organizations. Sometimes they run it's 258 00:25:53,000 --> 00:25:57,599 funny because we have other ways to do that. But I so places that 259 00:25:57,599 --> 00:26:03,640 they run campaigns, like they said the same messages, have you rotated this 260 00:26:03,200 --> 00:26:06,920 set of users? Have you've done that? Please send me confirmation, Please 261 00:26:06,960 --> 00:26:10,599 do that. It takes months to do that. It's very painful, like 262 00:26:10,680 --> 00:26:14,400 you, Like you said, it's very scary. What would be the impact 263 00:26:14,400 --> 00:26:19,119 of that? And I have to be honest, that is something that is 264 00:26:19,160 --> 00:26:25,400 not going away soon. Like using just in time credentials is very common, 265 00:26:26,039 --> 00:26:30,680 but not necessarily for privileged accounts like break class admins or something like that. 266 00:26:30,680 --> 00:26:37,200 That we have to stay and for that, the solution is to use rotated 267 00:26:37,240 --> 00:26:40,880 secrets, but to do that in an automated fashion, meaning that something that 268 00:26:40,920 --> 00:26:45,119 you don't even think about. You have a pretty fine configuration how often you 269 00:26:45,160 --> 00:26:52,319 want to rotate those privileged privileged credentials, and at that time an automated task 270 00:26:52,440 --> 00:26:56,319 is performed and doing that, including the validation of it, in a similess 271 00:26:56,359 --> 00:27:00,599 manner, and the new version is kept in the management and the previous version 272 00:27:00,680 --> 00:27:06,759 is still available in case you want to roll back or revert that change, 273 00:27:07,960 --> 00:27:12,599 and therefore no human intervention in the process. Therefore no need to have complex 274 00:27:12,680 --> 00:27:22,160 and expensive campaigns to force people to do that. It simply happened. It's 275 00:27:22,160 --> 00:27:26,279 a non event. Yeah, and I think that's you know, we have 276 00:27:26,359 --> 00:27:30,839 all the tools to do that, the technology exists. I think part of 277 00:27:30,839 --> 00:27:33,480 that is just a comfort level, you know, because it takes a high 278 00:27:33,519 --> 00:27:40,839 level of confidence in your tooling to just put it on autopilot like that and 279 00:27:40,880 --> 00:27:44,200 say, yeah, just rotate the creds whenever you think it's good. I'll 280 00:27:44,759 --> 00:27:48,359 I'm sure it's going to be fine. The only way that you can achieve 281 00:27:48,400 --> 00:27:55,559 that is if all the systems, all the applications, all the humans are 282 00:27:55,599 --> 00:28:00,119 working with a centralized secrets management because if there are two source of one of 283 00:28:00,160 --> 00:28:04,720 them will break one the other one. Yeah, so it has to be 284 00:28:04,960 --> 00:28:10,880 relying on that, and that's one of the biggest advantages I think of a 285 00:28:11,000 --> 00:28:18,200 centralized system. Yeah, you know, because it's specifically in areas where you 286 00:28:18,240 --> 00:28:23,640 have like multi cloud organizations. It's so easy with AWS to just use secrets 287 00:28:23,640 --> 00:28:29,079 Manager or in GCP use their secrets manager. But then whenever you have to 288 00:28:29,119 --> 00:28:33,799 bridge both of those, you've got to step back to something that's external to 289 00:28:33,200 --> 00:28:38,079 both of those, and so then you have this big social campaign. So 290 00:28:38,160 --> 00:28:44,200 now you've got to socialize your new secrets manager to your engineering teams who are 291 00:28:44,200 --> 00:28:52,200 writing the code so that they know that this other thing exists and that they 292 00:28:52,240 --> 00:28:56,720 should be using that rather than building in using the built in native tools. 293 00:28:56,799 --> 00:29:00,079 And I think that social component of it is probably one of the hardest things 294 00:29:00,160 --> 00:29:04,839 for a lot of people. I know it is for me personally because I'm 295 00:29:06,160 --> 00:29:11,400 very I like doing things very technical, I'm not really good at socializing things. 296 00:29:11,799 --> 00:29:18,680 But that's a huge component to making that type of effort successful. Yeah, 297 00:29:18,680 --> 00:29:25,119 one hundred percent agreed, and add to multi cloud legacy environments on premise 298 00:29:25,720 --> 00:29:30,480 something that does not interact well with cloud, So you get yourself a lot 299 00:29:30,480 --> 00:29:38,640 of secret silos, different policies, different processes, different automation scripts, whatever 300 00:29:38,680 --> 00:29:44,000 you want to call that. That's in the good case that you're automating or 301 00:29:44,039 --> 00:29:49,119 trying to automate. The other alternative is worse that it's simply like that forever 302 00:29:49,160 --> 00:29:56,119 and everybody's afraid of touching, so something would break. Yeah, I think 303 00:29:56,160 --> 00:30:02,440 that's a That's something I've encountered in the past, is people hesitating to do 304 00:30:02,480 --> 00:30:07,839 this because they're afraid of breaking it. One argument I've used to overcome that 305 00:30:07,880 --> 00:30:11,799 in the past is saying, look, it's going to break either way. 306 00:30:12,000 --> 00:30:17,759 We can either choose to break it intentionally right now for the purposes of fixing 307 00:30:17,799 --> 00:30:22,960 it, or we can wait for it to break at some random, undetermined 308 00:30:22,000 --> 00:30:26,880 time in the future that we can absolutely guarantee is not going to be convenient 309 00:30:26,880 --> 00:30:30,559 for anyone. So it's it's our choice. Yeah, And I would add 310 00:30:30,559 --> 00:30:40,480 to that, maybe not following recommended practice when it comes to production environment for 311 00:30:40,599 --> 00:30:47,079 different reasons. It can be costs, it can be laziness. Ideally you 312 00:30:47,119 --> 00:30:52,359 would want to have a staging environment or a dev environment or testing environment that 313 00:30:52,519 --> 00:30:56,640 is identical to your production environment, so you are able to test something before 314 00:30:56,680 --> 00:31:03,920 it applies or affects production workload. Maintaining that is something that is expensive, 315 00:31:03,920 --> 00:31:11,200 both in the amount of resources that you need to duplicate, but also humans 316 00:31:11,279 --> 00:31:15,039 or engineers that need to maintain it to make sure it's synchronized, to make 317 00:31:15,039 --> 00:31:19,880 sure it's aligned, etc. But once you're at that point, you can 318 00:31:19,960 --> 00:31:23,240 simulate a lot of scenarios. What happens if I rotate this value, how 319 00:31:23,319 --> 00:31:27,839 what's the impact? What would break? And you do that before it's impacting 320 00:31:29,759 --> 00:31:36,200 customers, before it's impacting business, and that would be ideal. I mean, 321 00:31:36,240 --> 00:31:40,839 if I look at our production environment the way that it's structured, it's 322 00:31:40,920 --> 00:31:45,440 part of our pipeline. You cannot do a single change to production if it's 323 00:31:45,480 --> 00:31:52,559 not passing all the tests, all the validation steps that we have in staging 324 00:31:52,640 --> 00:31:56,599 environments prior to that. Now it costs money, right, you need to 325 00:31:56,640 --> 00:32:02,119 basically double the dollars you pay for production, but it buys you reliability, 326 00:32:02,880 --> 00:32:12,000 which in some sense values for money for our customers. Okay, imagine it's 327 00:32:12,039 --> 00:32:21,079 something like that business critical system like secrets management is not accessible. This means 328 00:32:21,119 --> 00:32:27,440 automatically that our customers are bleeding money pages all over the place. I mean, 329 00:32:27,480 --> 00:32:32,240 it's it's becoming a mad place. But we need to be very confident 330 00:32:32,279 --> 00:32:37,680 about the changes that we do, and I think that our customers, many 331 00:32:37,680 --> 00:32:43,960 of them, are following same practices to achieve that goal of not being afraid 332 00:32:43,960 --> 00:32:51,680 of doing changes, being less afraid. Right, an circling back to the 333 00:32:51,720 --> 00:32:58,400 c CD integrating with security thing, what are the what are the different areas 334 00:32:58,440 --> 00:33:04,880 in a CD c C pipeline that you think are our stop points or security 335 00:33:04,920 --> 00:33:15,000 checkpoints. So today a lot of CICD platforms are integrating the SEM with the 336 00:33:16,640 --> 00:33:22,000 part of the deployment. Okay, so checking out code is a honish, 337 00:33:22,119 --> 00:33:25,160 it's part of the same platform. You don't have to authenticate to a remote 338 00:33:25,200 --> 00:33:31,000 kit tabripo or something like that. In the past it used to be like 339 00:33:31,039 --> 00:33:35,559 that, Like I mean, I don't know, using Jenkins or something like 340 00:33:35,599 --> 00:33:39,400 that, you have to authenticate to a remote It triple and the second part 341 00:33:39,480 --> 00:33:45,160 is about the deployment, the CD part of things. Right, So when 342 00:33:45,200 --> 00:33:50,960 you deploy something, it normally involves two phases. One of them is building 343 00:33:51,000 --> 00:33:55,759 the artifact and uploading it to some kind of artifactor or artifactory serving. It 344 00:33:55,839 --> 00:34:01,599 can be a container registry that holds the recent version of the image. It 345 00:34:01,640 --> 00:34:07,519 can be a few sets up binaries that you stage somewhere in the kind of 346 00:34:07,039 --> 00:34:13,639 a street bucket or something equivalent to that. And the second phase is to 347 00:34:13,920 --> 00:34:22,320 apply the new artifacts in the production environment. That can be by applying restart 348 00:34:22,400 --> 00:34:30,000 rollout to your communities, deployment, or reinstalling certain components in software to pick 349 00:34:30,039 --> 00:34:37,000 them up. All of that is like a typical CICD flow, checking out 350 00:34:37,000 --> 00:34:40,199 a piece of code, building something, getting artifacts, uploading them somewhere, 351 00:34:40,440 --> 00:34:45,519 applying it to production environment, all those steps without any exception. Maybe just 352 00:34:45,559 --> 00:34:52,800 the buill part will require a set of credentials okay to authenticate to get to 353 00:34:54,000 --> 00:35:00,599 doctor hub or whatever registry you have Kubernitis, et cetera. And typically it's 354 00:35:00,639 --> 00:35:05,440 not for a long time, like you need it for just a minute or 355 00:35:05,480 --> 00:35:10,519 two for the authentication. So just in time is a perfect match to this, 356 00:35:12,360 --> 00:35:15,679 to this flow, and it's very diverse, so you see a lot 357 00:35:15,679 --> 00:35:22,599 of technology. Sometimes you even use database to query something in order to decide 358 00:35:22,639 --> 00:35:28,800 where to apply or what to do something that's another security checkpoint to authenticate to 359 00:35:28,840 --> 00:35:35,000 that database. So I believe that if you look at the flow, you 360 00:35:35,039 --> 00:35:42,840 will see a lot of a lot of integrations with the secrets management that's yeah 361 00:35:42,840 --> 00:35:46,320 for sure. Yeah, just pretty much every step along the way you need 362 00:35:46,679 --> 00:35:52,960 a different set of credentials or different set of secrets for that step. Yeah. 363 00:35:54,639 --> 00:36:00,840 Right, So we're saying that the secrets management platform has all of our 364 00:36:00,880 --> 00:36:07,239 secrets, So how do we how do we set up the secrets management platform 365 00:36:07,119 --> 00:36:14,679 to be secret itself? Right? I'm guessing that you're aiming, how would 366 00:36:15,199 --> 00:36:22,000 an application CICD pipeline, for example, would authenticate to a secrets management platform 367 00:36:22,079 --> 00:36:28,400 without having an initial secret by itself. Yeah, and that's an interesting point. 368 00:36:28,440 --> 00:36:32,480 I mean, talking about legacy workload, that probably was the case. 369 00:36:32,519 --> 00:36:38,119 I mean, there wasn't any kind of underlying or fancy underlying infrastructure just run 370 00:36:38,159 --> 00:36:46,000 on burn metal hosts with no type of identification for this particular workload, let 371 00:36:46,039 --> 00:36:50,639 alone in a trusted manner. So you had to have something like that. 372 00:36:51,039 --> 00:36:58,559 Today, most of the infrastructure is running on top of modern infrastructure. May 373 00:36:58,599 --> 00:37:04,440 it be a cloud service provider, different kinds of services. There comberneties, 374 00:37:04,480 --> 00:37:09,719 clusters, CICD platforms, and all of them are providing some kind of trusted 375 00:37:09,800 --> 00:37:14,920 identity. When I say trusted, it means that it can be verified by 376 00:37:14,920 --> 00:37:20,480 a third party. If we were talking about this job authentication, it means 377 00:37:20,480 --> 00:37:25,719 that the cicity platform is holding a sensitive private key that is used to sign 378 00:37:25,840 --> 00:37:32,480 this job for a short duration, and it's also providing an external endpoint with 379 00:37:32,599 --> 00:37:38,519 access to the public matching public key that any third party can just validate if 380 00:37:38,559 --> 00:37:45,239 this is signed by this trust identity. Cloud service providers are doing something similar 381 00:37:45,239 --> 00:37:52,119 to that, using different service and SDS service and others to be able to 382 00:37:52,159 --> 00:37:57,679 validate. And if you're still if you're still using a legacy workload running on 383 00:37:57,719 --> 00:38:04,840 burmetals or VMS on prem there are ways to bypass that. We have implemented 384 00:38:04,880 --> 00:38:12,159 something an authentication method called we call it universal identity. The concept is to 385 00:38:12,320 --> 00:38:21,320 have tokens that are frequently and rapidly rotating. So there is an initial token, 386 00:38:21,360 --> 00:38:28,119 but immediately after that it's been constantly and frequently rotated. Each rotation is 387 00:38:28,280 --> 00:38:36,519 invalidating the previous version of the token. So the reason it's it's considered more 388 00:38:36,559 --> 00:38:44,159 secure is because a random hacker that gets access to this improvement has no identity 389 00:38:44,199 --> 00:38:47,199 to still outside of that environment. Like, if I see this token, 390 00:38:47,920 --> 00:38:51,599 I can maybe take it and try to use it elsewhere. In a second 391 00:38:51,599 --> 00:38:54,840 from now, it will no longer be valid because by then it was rotated. 392 00:38:57,440 --> 00:39:00,039 One of the questions that I asked when you when you say short lived, 393 00:39:00,039 --> 00:39:05,039 you're talking numbers of seconds. Numbers of seconds? Wow, right on, 394 00:39:06,800 --> 00:39:10,440 yes, And what I'm being asked is, in order to rotate a 395 00:39:10,519 --> 00:39:14,960 token, you need to have access to the token itself, right, This 396 00:39:15,039 --> 00:39:21,239 is the identity that allows you to perform the rotata operation. So somebody asked 397 00:39:21,280 --> 00:39:27,800 me once, what if this hacker is rotating the token before the valued application 398 00:39:27,960 --> 00:39:30,119 is even though it's we're talking about seconds, we're still quick enough to do 399 00:39:30,199 --> 00:39:36,440 that. That may be the case, But one of the events that would 400 00:39:36,880 --> 00:39:40,119 because as a result of that is the rotation of operation of the valued application 401 00:39:40,199 --> 00:39:45,920 would fail. And that event alone can be triggered. Can be triggered in 402 00:39:45,000 --> 00:39:50,119 order to revoke access to the application something is bad happening. I simply revoke 403 00:39:50,239 --> 00:39:53,880 access to anyone who's using this identity. So in any case, this random 404 00:39:54,039 --> 00:39:59,519 hacker would not be able to enjoy or to get access to secrets, and 405 00:39:59,559 --> 00:40:05,880 that's based taking an old school environment and making it a trusted environment or trusted 406 00:40:05,920 --> 00:40:09,320 identity without the secret zero problem or the chicken and an egg problem like that 407 00:40:09,400 --> 00:40:17,199 you descript right on, and that ties kind of into the difference between authentication 408 00:40:17,800 --> 00:40:25,320 and authorization, right, So the sign the token is the authentication piece of 409 00:40:25,360 --> 00:40:32,679 that, and then the contents of the token itself are the requested authorization that 410 00:40:32,880 --> 00:40:38,039 may be granted once the sign token is validated. Right to be precise, 411 00:40:38,199 --> 00:40:44,599 the token contains a set of attributes which in the back end are associated with 412 00:40:45,320 --> 00:40:50,519 an authorization layer. It's in our case, it's it's based on role based 413 00:40:50,559 --> 00:40:54,800 access control or our back So it's definitely relying on the attributes that are part 414 00:40:54,800 --> 00:40:59,119 of that token, but that the loan is not the access role because it's 415 00:40:59,280 --> 00:41:04,840 the language is more reached and just holding it in a token, it's about 416 00:41:04,880 --> 00:41:07,280 capabilities, what kind of access rules, which kind of secrets, what type 417 00:41:07,280 --> 00:41:13,679 of permissions based on crude attribute. So you have a lot of data behind 418 00:41:13,719 --> 00:41:19,480 the scene and holding it inside a token that's supposed to be relatively small in 419 00:41:19,599 --> 00:41:32,039 size is not realistic. Gotcha cool? So from someone just getting started on 420 00:41:32,199 --> 00:41:38,440 this or just trying to gain traction on it. The mapping exercise to understand 421 00:41:38,480 --> 00:41:45,280 the scope of the problem, prioritize it, to attack the or to address 422 00:41:45,360 --> 00:41:54,360 the biggest risk items first, and then use that to start bringing in other 423 00:41:54,440 --> 00:42:00,400 teams to sell it to them and show them the benefit or why they may 424 00:42:00,440 --> 00:42:05,679 have a vested interest in this, and then from that point you may have 425 00:42:05,719 --> 00:42:07,920 a pretty good idea what your implemented solution is going to look like to sound 426 00:42:07,960 --> 00:42:13,400 about, right, Yeah, actually it's a it's a fair description of our 427 00:42:13,440 --> 00:42:20,519 discus piece of cake. Just an afternoon's work, right, absolutely, It's 428 00:42:20,519 --> 00:42:28,280 always like that. Yeah, cool, All right, Well, I think 429 00:42:28,360 --> 00:42:31,800 we are coming up on an hour here. Is there anything else that you 430 00:42:31,840 --> 00:42:39,800 would like to share or offer as words of wisdom to someone taking on their 431 00:42:40,360 --> 00:42:49,599 security journey. I think we've covered pretty much the main stuff that I wanted 432 00:42:49,639 --> 00:42:55,400 to discuss. Obviously we can expand on different areas. Yeah, I see 433 00:42:55,400 --> 00:42:59,760 different topics, but I don't think we have enough time to cover everything. 434 00:42:59,800 --> 00:43:04,920 So I think it's a good start and maybe in future sessions. Yeah, 435 00:43:04,960 --> 00:43:08,320 it sounds like you just teed us up for a part two of this conversation. 436 00:43:09,800 --> 00:43:19,480 Why not right on cool? So let's do let's do some picks just 437 00:43:19,519 --> 00:43:24,719 to introduce something cool. My pick for today is going to be the gov 438 00:43:25,159 --> 00:43:30,039 Lights go v G, o V E E dot Com. I put some 439 00:43:30,159 --> 00:43:35,360 of these lights. We have this recessed ceiling in our living room, so 440 00:43:35,360 --> 00:43:39,079 I put some up there and it's just been super cool and you can control 441 00:43:39,119 --> 00:43:49,000 it all with your app and it uses it connects to your Wi Fi and 442 00:43:49,079 --> 00:43:51,679 you know, I think one of the biggest concern I have with all of 443 00:43:51,719 --> 00:43:59,280 these smart lights is giving them access to my network. And yeah, so 444 00:43:59,320 --> 00:44:01,960 I don't know if you is any secure, any more secure than any of 445 00:44:01,960 --> 00:44:07,280 the others. This is not a security endorsement. The only disclaimer I'll say 446 00:44:07,280 --> 00:44:10,760 there is I do have an isolated Wi Fi network, And yeah, I 447 00:44:10,800 --> 00:44:14,360 separate the networks. I don't know, it's something that I put in the 448 00:44:14,400 --> 00:44:20,320 past. One for the computers and sensitive information and all the rest for all 449 00:44:20,360 --> 00:44:24,079 the unknown devices that I purchase online. And I don't know what the hell 450 00:44:24,159 --> 00:44:28,559 are doing exactly. Yeah, I run three networks. I have the one 451 00:44:28,559 --> 00:44:31,360 for my work computer and then the one that the rest of the family uses 452 00:44:31,360 --> 00:44:35,360 with their phones and computers. And stuff. And then there's the third one 453 00:44:35,440 --> 00:44:39,199 for anything that wants to claim its smart like, okay, well you can 454 00:44:39,199 --> 00:44:45,760 go be smart over there. Absolutely, And once when I had the time, 455 00:44:45,840 --> 00:44:50,079 I even tracked. I don't know, I took some TCP dams to 456 00:44:50,079 --> 00:44:52,559 see what kind of activity is this device doing when I'm not doing anything. 457 00:44:53,199 --> 00:44:59,119 You'll be surprised how many packets it's sending two different IP addresses across the globe 458 00:44:59,119 --> 00:45:02,719 where I did get a chance to investigate. But as long as it's not 459 00:45:02,840 --> 00:45:07,159 able to access the local network at the computer network, I'm quite okay with 460 00:45:07,239 --> 00:45:12,719 it. Yeah, for sure, you just got to limit your exposure. 461 00:45:12,960 --> 00:45:15,960 It's about all you can do. Absolutely. I'm also I'm also dealing with 462 00:45:16,639 --> 00:45:24,039 like improving my smart home devices. It's a project that I started many years 463 00:45:24,039 --> 00:45:30,639 ago, when before all the easy to plug in devices were selling online. 464 00:45:30,719 --> 00:45:36,000 I started with a small r the window project. The initially just to turn 465 00:45:36,039 --> 00:45:42,199 on and off a light a lot bulb. Later on, it was so 466 00:45:42,320 --> 00:45:45,599 embarrassing to buy something much cheaper than the than the board itself to do everything 467 00:45:45,679 --> 00:45:52,800 for you, plus connecting to the internet and Wi Fi. And today I'm 468 00:45:52,840 --> 00:45:57,239 combining it all in a mobile application. So it's very easy sometimes, like 469 00:45:57,440 --> 00:46:00,320 when I'm driving home, like I turned on the see when when it's hot 470 00:46:00,320 --> 00:46:05,320 outside. So I get home and everything is all brazy and nice, opening 471 00:46:05,360 --> 00:46:10,400 the the winds, the shields in the morning and closing them at night and 472 00:46:10,440 --> 00:46:15,239 all that. So it's a project that is ongoing, but I enjoy you 473 00:46:15,280 --> 00:46:19,239 playing with it when I have the time. Yeah, for sure. Time 474 00:46:19,280 --> 00:46:23,480 is a big commitment there because I find it super interesting. But meanwhile, 475 00:46:23,320 --> 00:46:28,039 when my wife is like, well you just stop, leave it alone, 476 00:46:28,320 --> 00:46:32,280 I just want it to work exactly. You need to have a fair sef 477 00:46:32,280 --> 00:46:36,599 meccas and is something that all defence and stuff is not working, you still 478 00:46:36,639 --> 00:46:39,079 have a knob to get what you wanted to do. Then I need a 479 00:46:39,119 --> 00:46:45,360 staging environment for my home automation so that I can keep production of time and 480 00:46:45,480 --> 00:46:49,760 keep it with a secrets management for all the sensitive day that you have exactly 481 00:46:50,199 --> 00:46:54,920 exactly cool, So go VI lights or my pick. What what have you 482 00:46:54,920 --> 00:47:01,199 got for? Sorry, it's it's hard because most of the innovation that I'm 483 00:47:01,199 --> 00:47:09,039 playing with is related to what I do at work. So recent evolution that 484 00:47:10,199 --> 00:47:17,400 a small gig that I did is related to application monitoring. You know, 485 00:47:17,480 --> 00:47:22,920 sometimes it's hard to identify what specific flow in the application is the one causing 486 00:47:23,760 --> 00:47:30,000 an unexpected use of resources, whether it's CPU, memory and other stuff. 487 00:47:30,000 --> 00:47:34,119 There are many tools to do that today, but the interesting part is how 488 00:47:34,159 --> 00:47:38,760 to facilitate that to the developers so they can see exactly what's the problem, 489 00:47:38,840 --> 00:47:45,519 capturing this very moment and facilitating that. So we had a different solution part 490 00:47:45,519 --> 00:47:52,840 of our product for accessing web applications. The challenge was that this data is 491 00:47:52,880 --> 00:47:59,400 textual and can be converted to an HTML, but it's required to do some 492 00:47:59,480 --> 00:48:04,920 kind of an operation to run or to execute the process before the page is 493 00:48:07,199 --> 00:48:14,199 proper or rendered. So I combine that with a small LUA script that runs 494 00:48:14,239 --> 00:48:17,519 on Engine X and that this triggers the command to populate the HTMIL. It's 495 00:48:17,559 --> 00:48:21,639 fast enough so you wouldn't notice in the browser that something is happening in the 496 00:48:21,639 --> 00:48:25,159 background, but it's in a click of a button you're able to see the 497 00:48:25,199 --> 00:48:30,039 application flow. So that's that's something I work in the site. It's not 498 00:48:30,360 --> 00:48:34,800 directly related to what I do, but it was a nice project that I 499 00:48:34,840 --> 00:48:37,880 claim, right, and that's super cool cool. So if people want to 500 00:48:37,880 --> 00:48:42,519 get in touch with you, talk more about security. How can they do? 501 00:48:44,840 --> 00:48:50,199 I think the best way through my email. It's already at a kidos 502 00:48:50,239 --> 00:48:54,440 dot io. I cannot promise an immediate or fast response, but I can 503 00:48:54,559 --> 00:49:00,599 promise a response, so fair enough, give it a try. Awesome, 504 00:49:00,920 --> 00:49:04,039 Well, thank you so much for coming on the show. It's been a 505 00:49:04,079 --> 00:49:07,679 great conversation and I look forward to having you back on to talk more about 506 00:49:07,719 --> 00:49:12,280 this. Thank you very much, Will for hosting me here. It was 507 00:49:12,519 --> 00:49:16,079 truly pleasure and fun, and I look forward to talk against right on. 508 00:49:16,199 --> 00:49:17,719 Thanks everyone, we'll see all next week.