WEBVTT 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.