All right, here we go. Welcome everyone to another episode of Adventures and
deva Ops. I'm your host, Will Button and today joining me in the
studio our special guest Ory Moncli. How are you or very well? Nice
to speak to you, you too, welcome, Welcome. Can you give
us a little introduction, a little bit about your background? Sure? Absolutely?
First of all, I'm doing software development and anything related to tech since
I was since I can remember myself, sally. It was just a hobby
a long time, it became a profession and last twenty plus years I'm doing
different kinds of engineering work in the industry, starting as a software developed and
in the recent years i'm mostly managing development teams. My current position, I'm
heading the engineering team at a Kinness in Security. Still enjoying writing software and
learning more about different areas of technologies, things that are renewing all the time.
So that's my passion and that's what I do for a living, right,
And that's a hard balance, having a management role but still being able
to maintain or enjoy your technical skills. Agree. I mean, I can
see that management is an easy gateaway for somebody that doesn't love doing something like
that, and kind of switching roles to something else for me out of choice.
I'm trying to keep myself up to date. I'm very down to the
details. I like to keep maybe small projects not in the critical path of
the development, still keeping my hands dirty and doing some work. But it's
a matter of choice eventually, if you like it and you find the time
to do it, Yeah, for sure, for sure. So one of
the things we're going to talk about today was security in the CICD pipeline.
Right right, I mean security, This to me comes with the context of
doing things the right way, sometimes corredated to doing things a little bit slower
than usual because it has to be the right way, and a lot of
hurdles for their teams. Right, you need to do things, You need
to get confirmation from different authorities making sure that this is appropriate. This is
according to the standards, according to whatever rule least privilege, zero, standing
credentials, et cetera. Our job at a Kills, among other things,
is to make the security standards high, or keep the security standards high without
the negative impact on velocity, like making it simple, making it easy,
and in some cases making it even easier than usual. Path right, instead
of thinking where I should store this whatever, a secret, whatever piece of
information that I have, what would be the right repository, the right storage.
Now you have a place to do that, and it integrates well with
a lot of technologies, authentication types, different infrastructures, platforms, cloud,
the providers, etc. Yeah, for sure. And I think the like
putting it in cic D, I think really opens up some interesting possibilities for
you because then you can automate it, and I think that's where security really
I think that's really where you can start to gain ground on security. Like
you mentioned, if you can make the right thing the easier choice than doing
it the wrong way, that's really where you start to see the gains from
that. Yeah. Absolutely. I think that in the recent years we see
a lot of growth and adoption of a lot of develop tools, develops,
tool change, should I say, things related starting from configuration management to CICD,
platforms, container orchestrations. A lot of technologies evolving in this domain,
and this becomes a very convenient tool for automation, not necessarily just for releasing
an artifact production, but also to have like jobs to help maintaining the usual
work the build environment, and related to that, and as such, it
becomes an interesting target for potential hackers. Right, if you gain access to
this centralized platform that has access to your cloud service, provide to databases in
the organization, a lot of that, that's that's an easy target for hacking
credentials and accessing those systems. That's what I think we should we should,
Yeah, we should look at when when talking about security, how to protect
the identities, workload identities, how to protect different environments. Uh, and
to do that without adding overhead on the process. Yeah, right on.
So what would be your for someone who's just acknowledging the security should be part
of your organization? What would be the number one thing you would point the
map first, or the first thing to say, hey start here. Ideally
it would be mapping what kind of sensitive information, sensitive data? What kind
of different identities and permissions you have spread across your systems? Because creating identities
and giving access is very easy, right. You simply create another application,
another tool, I request access, and all of a sudden it fails up
with touns of identities without much of control over it. Like when I ask
a develops person how many applications do you have and what kind of permissions each
in every application has to perform on a different type of infrastructure. That's not
a simple question to answer because in many cases you simply don't have the visibility.
This problem is sometimes referred to as a secret sproll problem because you have
a lot of different storages to maintain secrets, to keep access, different different
kinds of ways to manage policies access policies. One cloud provider, you have
different type of language and annotation and other type of infrastructure of different things,
So it becomes a lot of know how on how to manage it, and
in many cases it's kept in a very selected few individuals' minds where to set
what Talking about dashboards and visibility to executive level is something that very rarely found,
So identifying where the sensitive data is would be the number one step.
I think, yeah, that makes a lot of sense, because I think
from my own perspective, my gut reaction to any problem is to start building
something to solve that problem. But actually taking a step back and documenting where
this problem exists, where it's used, would change the perspective because then you
kind of have a better understand of the size and the scope of the problem
that you're trying to solve exactly. I would say that afterwards, once you
have that mapped, you probably want to sort them by the most impactful type
of identities to the listed platforms, right, which one has access to many
resources, privileged access, et cetera, and then try to deal with them
first, because the virtual blast reduce should I say, of somebody's accessing those
can be the most significant negatively significant to the organization. Ideally, you don't
want to maintain something that is lasting forever, right, So any type of
credential, any type of access, should be limited in time for a reasonable
duration. When I say reasonable, it cannot be ten years or fifteen years,
because in that time you can do a lot of them. I'm talking
in many cases minutes maybe hours to perform some kind of tasks, but not
much more than that. Yeah, you know, it was just about a
year ago I stumbled across the open id connect, I think OIDC and I
haven't really seen it talked about a lot in many places, but I've actually
fallen in love with it, and we've updated a bunch of our infrastructure to
use that for that specific reason, Because whenever you go to take an action,
the OIDC gets a set of short lived tokens and then you can scope
those scope the access permissions for those credentials down to just the exact deployment that
you're dealing with at that time. And I thought that was such a cool
idea. It's relatively easy to implement, but it doesn't seem to be very
popular. Yeah, I think O I d C is positioning as one of
the slowly but one of the most popular authentication methods for humans. It's in
my opinions, it's second to summon, which is more legacy one but still
very widely used. But I think that over time we will start to see
more and more. This is kind of the evolution of some and we start
to see more and more relying on O I d C. The foundation or
the underlying technology is basically all OFF or JOT authentication, which is very popular
for application type of authentication. A lot of c CD platforms today are providing
a temporary signed job that can be used to verify to identify the actual runner
and the right context of what kind of project idea, who trigger the job
or what kind of resources running, et cetera, and all those attributes both
coming from Native job authentication or YDC can be leveraged for access permissions, and
that's very handy. Like imagine that you log into a platform and all of
a sudden you have all the types of permission associated with your identity without the
need or the operational hussle of managing those same permissions in two different platforms,
one being the actual infrastructure, the other one being the secret management site.
Right, So basically take the same like if you modify something in your IDP,
the identity provider automatically, it reflects to the same its management and the
access permissions you have there. So from an administrative perspective of managing identities,
that's a very easy and convenient approach where identities live only in one place according
to one policy. Yeah, and that's there's just so many, so many
wins to take away from that. The security team loves it, but also
just the it and the support folks like it too because then it's just less
chainsaws to be juggling at the same time. Absolutely absolutely, And I think
another thing that I was talking about the adoption of different tools and technologies to
the develops environment, and one thing that still is not there is the unification
of those tools. In terms of visibility, Okay, how many many tools
you have, how many different users, both human users and applications are using
specific flows, et cetera. The fact that you're using a centralized platform for
secrets management is giving you implicitly giving you visibility to all types of activities in
the develops world. Right, so you can see, oh, this client
is connecting from CICD platform disguise, this application is connecting through a communities cluster,
this flow is coming from configuration management. This is a human authenticating to
my Jenkins webuy wherever it may be. But because of the fact that any
entity requires access to secrets, this gives you implicitly a wide visibility to what's
going on inside your organization. And that's gold for security officers because there is
no other way that I can think of to see all those activities coming from
different platforms. Maybe in one infrastructure, like if you're running on a single
cloud provider in a single flow, maybe that is another way to see that.
But if you're multi cloud or hybrid, if you're using different kinds of
tools in different locations, the only good way to show that it might be
it would be through secrets Management Central. Yeah, so the secret manager at
that point not only becomes the source restoring your secrets, but also the like
the audit tool for defining the footprint and and use of the secrets across it
entire organization. Agreed, Yeah, hundred percent. And maybe as an evolution
as a next step, applying some kind of AI based logic on this audit
log can detect different kinds of anomalies, like this activity is not something usual
for this time of day, or is a day of week or something like
that. The number of requests here seems unusual with respect to previous weeks.
This application is behaving really in terms of accessing different kinds of secrets. And
maybe, I mean it's not something that is part of modern solutions as far
as I know today. But maybe as a next step, this could be
interesting in helping humans detecting breaches. Security breaches attacks something that would be hard
to detect otherwise. Oh for sure, that's actually a pretty cool idea.
So if let's talk a little bit about how you gain like support and sponsorship
for this type of project. If you want to do the full audit to
gain to improve your security plusture, what are some of the tools or stories
that someone should be thinking about to help sell the to their management team and
get people on board with it. Yeah. I think that this can be
approached in two ways. One from the security perspective, identifying areas and technologies
that are not well protected today and defining what would be the impact if specific
credential specific identities would be exposed or breached. That's one motivation. Another one
is to facilitate as I mentioned, unified view from an operational perspective. A
third approach would be to meet with certain requirements to compliance regulations, etc.
Like in order to be compliant to a certain standard, you have to have
something like that, so different triggers by different business units. And also about
the model, I think that model that you tell you you took about sponsoring
that this can be sponsored by the main driver, some kind of centralized entity
in the organization like the CSO or the CIO or something like that can also
be done by the IT department if we're talking about the operational side of things,
and it can also be shared shared sponsorship in a sense that it's very
easy to know on using a centralized platform, which departments or which applications consume
services from the secrets management. So ideally you can divide the payment based on
internal shared model internal to the organization to say, okay, the department that
is using the most would carry most of the costs of that sharing. So
putting like the you know, the dollars aside for a moment, I think
that the motivation can come from different angles. Each organization that we see is
coming from a different reason, or maybe a combination of different reasons. But
it's definitely definitely becoming a defacto standard for large organizations and getting lower and lower.
Like if in the beginning it was just for large enterprises or corporates,
Today we see even SMBs asking about secrets management because it's obvious that you should
have some solution. Yeah, for sure, Like the number of stories that
we hear about every day just keeps growing. It seems like the people who
are actually impacted most by that are the SMBs. You know. The enterprises
I think typically have a larger they have more people, more resources to work
with, so maybe they're a little bit better positioned. But you just here
a day after day of small and medium businesses that have been shut down,
locked out, or been unable to continue business because of security breaches. Yeah,
and bridges is not something that happens once. And that's it. I
mean the fact that hacker gains access to even side applications something that looks maybe
less relevant. There is the lateral movement, you know, like when you're
starting small and expanding the knowledge and gaining more and more access and more and
more possession of infrastructure and resources inside organization and waiting for this special moment doomsday,
when something like that is exploding, and when it explodes them it becomes
a big business problem for this particular vendor or this particular organization. So detecting
it when it's still small, relatively small, and the impact is still scoped
and known. The ability to detect and also remediate that problem right by restricting
access to this application, rotating set of credentials, revoking access to certain applications,
all that is very important in the process of securing the organization. And
that ties right back into the mapping exercise that you mentioned at the start of
the episode, because now you know what credentials this application use, what services
it talks to, and where else those components are used in your infrastructure.
Yes, an interesting concept that I think that is getting more and more attraction
of the time is the use of just in time credentials. Historically, like
if you're at many years in the industry like myself, the war files configuration
files with static credentials using m passwords, token's API keys, and typically they
lasted four years. If somebody got a got a view of them, they
can keep using them without any ability to detect that This is a misuse right
from if you look from the back inside of the service side perspective, it's
a value authentication of an authorized entity. What we see more and more is
that there is no reason to have standing privileges in systems across the environment.
Okay, only when an application argument needs access for a certain reason for a
certain task. Only then the credentials will be generated, and they will also
be a thermeral like meaning they have time to lead. They have a duration
that after this time they will be revoked automatically without any human intervention in the
process. And that model is becoming more and more popular for two main reasons.
One is the impact like if I forget my workstation open, if somebody
grabs access to a certain set of credentials, they can do so much with
it until they expire. But secondly, it's also enforcing the use of a
centralized system. Imagine that we're talking about humans, and humans are very lazy
by nature, and that's very normal, and they say, Okay, why
should I log into a secrets management platform statch and use them password over and
every day and to connect to my database? Right the second time you do
that, you say, hey, I can keep a copy of that because
it's static. I can keep it in my notepad and a story not need
to log in anymore. And that's true if you're talking about static secrets,
But what if there is no static secret anytime you need to get dynamic secret,
then you're basically forced or enforced to do that the right way. Now,
our job is to make it easier and less painful to people like that,
in the sense that there is single sign on integration you mentioned OIDC before
and some and also you don't have to retype over and over your credentials to
get some access. But secondly, it's mostly done by applications, and applications
can use their trusted identities, like if they're running on cloud service providers infrastructure,
they can use the cloud IAM to authenticate to a kill is similitly like
you don't have to have an additional set of credentials. If you're working on
modern infrastructure like Cobernetti's clus, they can use the Cobernetus identities to authenticate similar
stame fetch credentials. So you find ways to make it easy but secure to
authenticate to secretsman on the platform rely on just in time credentials to apply the
principle that don't have so what's called zero standing privileges, and also making sure
that the credentials are biding with the right policy in terms of access the authorization
layer, which means that if here it applies to the principle of least privilege,
you don't provide anything beyond what the application or the human requires for this
particular task. If using standing credentials, you would have to have tons of
sets of users and only a very educated person would pick the right one for
this task. But when you use dynamic secrets or just in time access,
it's very easy because you have access only for read or the operations, only
for specific set of secrets that are required for this application. So it's helping
in so many ways. And I think that this is a trend that we
see more and more, and I think that in a few years time from
now, it would be very rare to see static credentials in production environments.
Yeah, that would be cool, Like like you have been doing this for
a long time, and I remember many times whenever someone would say we need
to rotate these keys, and everyone would just cringe because we knew that it
was going to involve production downtime, because nobody knew where they were used,
and it was going to be painful and we were going to have everyone mad
at us. It's a huge project for many organizations. Sometimes they run it's
funny because we have other ways to do that. But I so places that
they run campaigns, like they said the same messages, have you rotated this
set of users? Have you've done that? Please send me confirmation, Please
do that. It takes months to do that. It's very painful, like
you, Like you said, it's very scary. What would be the impact
of that? And I have to be honest, that is something that is
not going away soon. Like using just in time credentials is very common,
but not necessarily for privileged accounts like break class admins or something like that.
That we have to stay and for that, the solution is to use rotated
secrets, but to do that in an automated fashion, meaning that something that
you don't even think about. You have a pretty fine configuration how often you
want to rotate those privileged privileged credentials, and at that time an automated task
is performed and doing that, including the validation of it, in a similess
manner, and the new version is kept in the management and the previous version
is still available in case you want to roll back or revert that change,
and therefore no human intervention in the process. Therefore no need to have complex
and expensive campaigns to force people to do that. It simply happened. It's
a non event. Yeah, and I think that's you know, we have
all the tools to do that, the technology exists. I think part of
that is just a comfort level, you know, because it takes a high
level of confidence in your tooling to just put it on autopilot like that and
say, yeah, just rotate the creds whenever you think it's good. I'll
I'm sure it's going to be fine. The only way that you can achieve
that is if all the systems, all the applications, all the humans are
working with a centralized secrets management because if there are two source of one of
them will break one the other one. Yeah, so it has to be
relying on that, and that's one of the biggest advantages I think of a
centralized system. Yeah, you know, because it's specifically in areas where you
have like multi cloud organizations. It's so easy with AWS to just use secrets
Manager or in GCP use their secrets manager. But then whenever you have to
bridge both of those, you've got to step back to something that's external to
both of those, and so then you have this big social campaign. So
now you've got to socialize your new secrets manager to your engineering teams who are
writing the code so that they know that this other thing exists and that they
should be using that rather than building in using the built in native tools.
And I think that social component of it is probably one of the hardest things
for a lot of people. I know it is for me personally because I'm
very I like doing things very technical, I'm not really good at socializing things.
But that's a huge component to making that type of effort successful. Yeah,
one hundred percent agreed, and add to multi cloud legacy environments on premise
something that does not interact well with cloud, So you get yourself a lot
of secret silos, different policies, different processes, different automation scripts, whatever
you want to call that. That's in the good case that you're automating or
trying to automate. The other alternative is worse that it's simply like that forever
and everybody's afraid of touching, so something would break. Yeah, I think
that's a That's something I've encountered in the past, is people hesitating to do
this because they're afraid of breaking it. One argument I've used to overcome that
in the past is saying, look, it's going to break either way.
We can either choose to break it intentionally right now for the purposes of fixing
it, or we can wait for it to break at some random, undetermined
time in the future that we can absolutely guarantee is not going to be convenient
for anyone. So it's it's our choice. Yeah, And I would add
to that, maybe not following recommended practice when it comes to production environment for
different reasons. It can be costs, it can be laziness. Ideally you
would want to have a staging environment or a dev environment or testing environment that
is identical to your production environment, so you are able to test something before
it applies or affects production workload. Maintaining that is something that is expensive,
both in the amount of resources that you need to duplicate, but also humans
or engineers that need to maintain it to make sure it's synchronized, to make
sure it's aligned, etc. But once you're at that point, you can
simulate a lot of scenarios. What happens if I rotate this value, how
what's the impact? What would break? And you do that before it's impacting
customers, before it's impacting business, and that would be ideal. I mean,
if I look at our production environment the way that it's structured, it's
part of our pipeline. You cannot do a single change to production if it's
not passing all the tests, all the validation steps that we have in staging
environments prior to that. Now it costs money, right, you need to
basically double the dollars you pay for production, but it buys you reliability,
which in some sense values for money for our customers. Okay, imagine it's
something like that business critical system like secrets management is not accessible. This means
automatically that our customers are bleeding money pages all over the place. I mean,
it's it's becoming a mad place. But we need to be very confident
about the changes that we do, and I think that our customers, many
of them, are following same practices to achieve that goal of not being afraid
of doing changes, being less afraid. Right, an circling back to the
c CD integrating with security thing, what are the what are the different areas
in a CD c C pipeline that you think are our stop points or security
checkpoints. So today a lot of CICD platforms are integrating the SEM with the
part of the deployment. Okay, so checking out code is a honish,
it's part of the same platform. You don't have to authenticate to a remote
kit tabripo or something like that. In the past it used to be like
that, Like I mean, I don't know, using Jenkins or something like
that, you have to authenticate to a remote It triple and the second part
is about the deployment, the CD part of things. Right, So when
you deploy something, it normally involves two phases. One of them is building
the artifact and uploading it to some kind of artifactor or artifactory serving. It
can be a container registry that holds the recent version of the image. It
can be a few sets up binaries that you stage somewhere in the kind of
a street bucket or something equivalent to that. And the second phase is to
apply the new artifacts in the production environment. That can be by applying restart
rollout to your communities, deployment, or reinstalling certain components in software to pick
them up. All of that is like a typical CICD flow, checking out
a piece of code, building something, getting artifacts, uploading them somewhere,
applying it to production environment, all those steps without any exception. Maybe just
the buill part will require a set of credentials okay to authenticate to get to
doctor hub or whatever registry you have Kubernitis, et cetera. And typically it's
not for a long time, like you need it for just a minute or
two for the authentication. So just in time is a perfect match to this,
to this flow, and it's very diverse, so you see a lot
of technology. Sometimes you even use database to query something in order to decide
where to apply or what to do something that's another security checkpoint to authenticate to
that database. So I believe that if you look at the flow, you
will see a lot of a lot of integrations with the secrets management that's yeah
for sure. Yeah, just pretty much every step along the way you need
a different set of credentials or different set of secrets for that step. Yeah.
Right, So we're saying that the secrets management platform has all of our
secrets, So how do we how do we set up the secrets management platform
to be secret itself? Right? I'm guessing that you're aiming, how would
an application CICD pipeline, for example, would authenticate to a secrets management platform
without having an initial secret by itself. Yeah, and that's an interesting point.
I mean, talking about legacy workload, that probably was the case.
I mean, there wasn't any kind of underlying or fancy underlying infrastructure just run
on burn metal hosts with no type of identification for this particular workload, let
alone in a trusted manner. So you had to have something like that.
Today, most of the infrastructure is running on top of modern infrastructure. May
it be a cloud service provider, different kinds of services. There comberneties,
clusters, CICD platforms, and all of them are providing some kind of trusted
identity. When I say trusted, it means that it can be verified by
a third party. If we were talking about this job authentication, it means
that the cicity platform is holding a sensitive private key that is used to sign
this job for a short duration, and it's also providing an external endpoint with
access to the public matching public key that any third party can just validate if
this is signed by this trust identity. Cloud service providers are doing something similar
to that, using different service and SDS service and others to be able to
validate. And if you're still if you're still using a legacy workload running on
burmetals or VMS on prem there are ways to bypass that. We have implemented
something an authentication method called we call it universal identity. The concept is to
have tokens that are frequently and rapidly rotating. So there is an initial token,
but immediately after that it's been constantly and frequently rotated. Each rotation is
invalidating the previous version of the token. So the reason it's it's considered more
secure is because a random hacker that gets access to this improvement has no identity
to still outside of that environment. Like, if I see this token,
I can maybe take it and try to use it elsewhere. In a second
from now, it will no longer be valid because by then it was rotated.
One of the questions that I asked when you when you say short lived,
you're talking numbers of seconds. Numbers of seconds? Wow, right on,
yes, And what I'm being asked is, in order to rotate a
token, you need to have access to the token itself, right, This
is the identity that allows you to perform the rotata operation. So somebody asked
me once, what if this hacker is rotating the token before the valued application
is even though it's we're talking about seconds, we're still quick enough to do
that. That may be the case, But one of the events that would
because as a result of that is the rotation of operation of the valued application
would fail. And that event alone can be triggered. Can be triggered in
order to revoke access to the application something is bad happening. I simply revoke
access to anyone who's using this identity. So in any case, this random
hacker would not be able to enjoy or to get access to secrets, and
that's based taking an old school environment and making it a trusted environment or trusted
identity without the secret zero problem or the chicken and an egg problem like that
you descript right on, and that ties kind of into the difference between authentication
and authorization, right, So the sign the token is the authentication piece of
that, and then the contents of the token itself are the requested authorization that
may be granted once the sign token is validated. Right to be precise,
the token contains a set of attributes which in the back end are associated with
an authorization layer. It's in our case, it's it's based on role based
access control or our back So it's definitely relying on the attributes that are part
of that token, but that the loan is not the access role because it's
the language is more reached and just holding it in a token, it's about
capabilities, what kind of access rules, which kind of secrets, what type
of permissions based on crude attribute. So you have a lot of data behind
the scene and holding it inside a token that's supposed to be relatively small in
size is not realistic. Gotcha cool? So from someone just getting started on
this or just trying to gain traction on it. The mapping exercise to understand
the scope of the problem, prioritize it, to attack the or to address
the biggest risk items first, and then use that to start bringing in other
teams to sell it to them and show them the benefit or why they may
have a vested interest in this, and then from that point you may have
a pretty good idea what your implemented solution is going to look like to sound
about, right, Yeah, actually it's a it's a fair description of our
discus piece of cake. Just an afternoon's work, right, absolutely, It's
always like that. Yeah, cool, All right, Well, I think
we are coming up on an hour here. Is there anything else that you
would like to share or offer as words of wisdom to someone taking on their
security journey. I think we've covered pretty much the main stuff that I wanted
to discuss. Obviously we can expand on different areas. Yeah, I see
different topics, but I don't think we have enough time to cover everything.
So I think it's a good start and maybe in future sessions. Yeah,
it sounds like you just teed us up for a part two of this conversation.
Why not right on cool? So let's do let's do some picks just
to introduce something cool. My pick for today is going to be the gov
Lights go v G, o V E E dot Com. I put some
of these lights. We have this recessed ceiling in our living room, so
I put some up there and it's just been super cool and you can control
it all with your app and it uses it connects to your Wi Fi and
you know, I think one of the biggest concern I have with all of
these smart lights is giving them access to my network. And yeah, so
I don't know if you is any secure, any more secure than any of
the others. This is not a security endorsement. The only disclaimer I'll say
there is I do have an isolated Wi Fi network, And yeah, I
separate the networks. I don't know, it's something that I put in the
past. One for the computers and sensitive information and all the rest for all
the unknown devices that I purchase online. And I don't know what the hell
are doing exactly. Yeah, I run three networks. I have the one
for my work computer and then the one that the rest of the family uses
with their phones and computers. And stuff. And then there's the third one
for anything that wants to claim its smart like, okay, well you can
go be smart over there. Absolutely, And once when I had the time,
I even tracked. I don't know, I took some TCP dams to
see what kind of activity is this device doing when I'm not doing anything.
You'll be surprised how many packets it's sending two different IP addresses across the globe
where I did get a chance to investigate. But as long as it's not
able to access the local network at the computer network, I'm quite okay with
it. Yeah, for sure, you just got to limit your exposure.
It's about all you can do. Absolutely. I'm also I'm also dealing with
like improving my smart home devices. It's a project that I started many years
ago, when before all the easy to plug in devices were selling online.
I started with a small r the window project. The initially just to turn
on and off a light a lot bulb. Later on, it was so
embarrassing to buy something much cheaper than the than the board itself to do everything
for you, plus connecting to the internet and Wi Fi. And today I'm
combining it all in a mobile application. So it's very easy sometimes, like
when I'm driving home, like I turned on the see when when it's hot
outside. So I get home and everything is all brazy and nice, opening
the the winds, the shields in the morning and closing them at night and
all that. So it's a project that is ongoing, but I enjoy you
playing with it when I have the time. Yeah, for sure. Time
is a big commitment there because I find it super interesting. But meanwhile,
when my wife is like, well you just stop, leave it alone,
I just want it to work exactly. You need to have a fair sef
meccas and is something that all defence and stuff is not working, you still
have a knob to get what you wanted to do. Then I need a
staging environment for my home automation so that I can keep production of time and
keep it with a secrets management for all the sensitive day that you have exactly
exactly cool, So go VI lights or my pick. What what have you
got for? Sorry, it's it's hard because most of the innovation that I'm
playing with is related to what I do at work. So recent evolution that
a small gig that I did is related to application monitoring. You know,
sometimes it's hard to identify what specific flow in the application is the one causing
an unexpected use of resources, whether it's CPU, memory and other stuff.
There are many tools to do that today, but the interesting part is how
to facilitate that to the developers so they can see exactly what's the problem,
capturing this very moment and facilitating that. So we had a different solution part
of our product for accessing web applications. The challenge was that this data is
textual and can be converted to an HTML, but it's required to do some
kind of an operation to run or to execute the process before the page is
proper or rendered. So I combine that with a small LUA script that runs
on Engine X and that this triggers the command to populate the HTMIL. It's
fast enough so you wouldn't notice in the browser that something is happening in the
background, but it's in a click of a button you're able to see the
application flow. So that's that's something I work in the site. It's not
directly related to what I do, but it was a nice project that I
claim, right, and that's super cool cool. So if people want to
get in touch with you, talk more about security. How can they do?
I think the best way through my email. It's already at a kidos
dot io. I cannot promise an immediate or fast response, but I can
promise a response, so fair enough, give it a try. Awesome,
Well, thank you so much for coming on the show. It's been a
great conversation and I look forward to having you back on to talk more about
this. Thank you very much, Will for hosting me here. It was
truly pleasure and fun, and I look forward to talk against right on.
Thanks everyone, we'll see all next week.