Keeping Track of Secrets – Itzik Alvas, Entro Security

This is Techstrong tv. Hi everybody. Mike Rothman here, general manager of Techstrong Research for another Techstrong TV interview.

Uh, I am joined today by its Alga. Hopefully I got that right. I didn't butcher it too much.

Good stuff. Got, okay. C e o of a, of a company called Intro Security.

And, uh, they're into the secrets business. Right? And, and I think that's actually a very important, you know, thing to dig into because it's one of these kind of behind the scenes capabilities and really requirements, uh, that you don't really know, you haven't done well with until your stuff is all over the place and you have no idea, you know, who has access to what and, and, and what kind of API keys and, and, and database credentials and, and all sorts of other machine to machine and application oriented, uh, types of, of credentials and, and secrets are, are kind of out there and, and really unmanageable at this point.

So that's what Intro is, is focused on. But don't let me tell Iik story. He can tell it himself.

So, IIK, welcome to the show. Great to see you. Uh, why don't you just introduce yourself a little bit and tell us, uh, about Intro and, you know, again, kind of correct all the stuff that I'm sure I screwed up.

No, you got it. You got it. Correct.

Uh, thanks Mike for having me. And, and yeah, I'm, it. Kaba, the co-founder of Security.

I spent the last two years building security, uh, and today we are the first and only end-to-end holistic secret security. Uh, we are helping CISOs and security teams to reclaim control over their secrets and also helping organization at the point they have hundreds or thousands of secrets, uh, to secure them. Uh, I actually started my career as a software engineer at one of the intelligence units, uh, of the idf.

Uh, after that I was a cso, I was responsible for the security and the DevOps and Microsoft Defender Azure. Um, and now I'm the co-founder, uh, n c O of, uh, of security. And I've seen our secrets are the building blocks of any application and cloud applications and the power that secretive, um, and how they are being created and end then without any security oversight.

That's right. And, and, and let's kind of dig in cuz I'm, I, you know, some folks may not be as familiar with kind of the integral role that secrets play in, uh, a lot of these new modern applications, right? So, you know, in the old days everything was, you know, kind of big and monolithic and, and we had, you know, kind of R P C and, and other mechanisms to communicate between all these different application components.

But as we've, you know, really kind of broken up and, and, uh, you know, kind of disintermediated a lot of these different application components as we've embraced microservices, right? You know, kind of a lot of and, and PAs and, and a lot of cloud aspects, right? You know, we're not building these monolithic applications.

What we're doing is assembling a whole mess of different components. And all of those components really communicate via APIs. And in order to know that the component is, you know, both what they say it is, and that's the authentication piece of it, as well as the authorization piece of it, meaning you can actually do this stuff, uh, within the context of that application is all driven by secrets, right?

So within that context, you, you know, you understand secrets can be, you know, pretty important, uh, underlying, again, foundational aspect of that. So, you know, when you're working with some of these customers, I mean, do they even have any idea where a lot of their secrets are, uh, from that standpoint? Or are they just kinda like, well, I don't know.

Right? You know, and then, uh, when they have some kind of issue, they realize that they have a secret problem. So, so what tends to be the catalyst for folks to want to get their arms around this, uh, problem on an enterprise basis, Right?

So you touched many points, and, and I agree, I I get going like a runaway train. Sometimes it's, you know, that happens. I, I fully agree with, with all of them.

I mean, CS have been with us forever, right? Even, even within, um, old applications or monoliths and, and et cetera, they needed to authenticate against their databases or storage. And in order to do that, they needed a secret.

So essentially, uh, secrets are programmatic access keys. So every application that is being developed within any organization needs to use other services today, cloud services such as databases or storage accounts and et cetera. And in order to do that, they need a key.

And those keys are secrets. They can be API keys, access tokens, connection streams. Um, so, so yeah, secrets are been with us, uh, for a long while, but you are fully correct with the cloud services, the rise of the cloud services, different cloud services, and then microservices.

And each one of them requires at least one key. Today, small organization have at least 500, uh, different, different keys. And I've asked, I think at least 300 CISOs if they know how many secrets they have, and none of them have any idea how much secrets or how many secrets they have, and where are they stored.

So that's, that's, that's a real issue, right? Because those are the keys to your kingdom. Um, so yeah, it's, it's a great question.

And organization don't, or security teams don't really have any idea about how many stickers they have, where are they, what are the risks that are associated with them, what cloud services they can access, and most crucially, how to protect them. You bet. So, so let, let's kind of start to, you know, kind of unpack that a little bit bit, right?

So yeah, customer says, yeah, you know, all these applications are happening and, and obviously they're using secrets because they have to, right? You know, in this, you know, kind of cloud base and, and microservices driven, uh, environment, how do they get started, right? I mean, it's, do I do it for one application and try to get my arms around those secrets and then go to the next one, go to the next one.

Do I kind of try to get an inventory of everything that's happening in my AW s or my Azure or my G C P, uh, on that front and then kind of aggregate all that information and then do risk analysis? I mean, what tends to be the most effective means to get going, right? Because if you go to a typical customer, go, you've got 10,000 secrets, and you have no idea where any of them are, their head goes pulled, right?

And, and, and they don't know where to start, right? So, so how do we get started with trying to get your arms around the, the, the, the, you know, size and depth of this problem, Right? So, so the problem name is actually Secrets Pole are in which secrets are scattered around the organization.

And the, the problem is that the teams that are creating those secrets are not responsible to secure them. So you have the DevOps teams and developers, so r and d teams, uh, that are creating secrets. So, so on from your DevOps will go to a database instance for an example, and, and it will create a secret key over there, and then he will store it somewhere and the application will fetch it, uh, and use it to authenticate to that, to the database.

But the problem is that today, uh, the, the teams are placing, storing, or scattering, those secrets are everywhere. So they're using vaults and vaults are basically storages in which you can store your secrets. But then if you have a main vault solution such as aws, ticket manager or vault, uh, which is great, you probably need one for each environment, uh, or for each region.

So you have a lot of different roles. Uh, if you're using Kubernetes, you probably have Kubernetes Secrets. If you're using Jenkins or other c cd, you have Secret Store over there, uh, GitHub Secret Store over there.

So you have many Vault solutions, uh, at least five per organization. And then as, as you correctly, a lot of different, uh, uh, secrets out there. Uh, so yeah, security teams have no oversight about their secrets and where are they?

Uh, and, and even if, if you ever seen a secret, it's basically a long stream. So even if you find a secret, you have no information about it, you can really tell me which application are using it, uh, what cloud service it can access, what are the privileges of that secret within the cloud service? What are the risks that are associated with that secret?

Uh, so to your question, it's, it's a, it's a, it's a big challenge. Um, but yeah, organization must have secret in the to know how many secrets they have, where are they? And because you want to enable the business and enable r and d, you want to let them use as many secret stores they need, or place the secret wherever they or the application is as.

So what you should do is try to integrate to different places and compose the list and then to enrich that list with data. So you can say which application are using what secret to authenticate, to what cloud service and other vital data around the secret in order to protect it. So let, let's kind of think like an attacker for a sec, right?

Because you, you know, again, and I'll just play devil's advocate for a sec, right? So, you know, this thing's a big long string. I don't really understand what it goes to.

I don't have the context. I don't, you know, obviously it's called from within an application. So the application knows, you know, which secret it needs to hit on, and it's got a, you know, unique, uh, an rrn and, you know, a w s lingo or, you know, kind of a, a, a, you know, resource ID in, in Azure.

Um, right? So, so, uh, this thing's laying on the floor, you know, what can I do with it if I'm an attacker, right? Why am I concerned about this?

I mean, besides just, you know, kind of, we like to have a tidy closet, right? You know, you don't wanna open the door and, you know, you get dumped on by a bunch of stuff, but what, what's the real risk of, of these things lying around without proper security? Right?

So those are the keys to your infrastructure, to your cloud services, to your data, to your customers data. What is the risk? If you lose your house key, uh, someone can use it to access your, your home, right?

So someone can use it in order to access your databases storage, uh, and and et cetera, and, and extract all of the data from Dell. But not only that, you can use it to create more keys, more permissions, and you will keep reaching your organization in endless way. So if you lost the key, or if an attacker owns one of your keys or your secrets, it's game over.

Yes. Uh, also, I will just say that according to recent research organization are leaking at least 6 million different secrets every year. 4 million per one breach.

And then again, they're getting more secrets and keep breaching that organization, Right? And, and, you know, just to put a plug into why we wanna deal with this problem sooner rather than later is it's not like we're gonna have less secrets tomorrow, right? We have new applications, we've got new data sources, we've got new, so we're gonna keep, you know, kind of mushroom, ru mushrooming, uh, in terms of the number of these secrets.

So, you know, getting ahead a bit early and, uh, and, and often in continuously, right? I mean, that's the key thing. So let's kind of, so once we figure out where all these things are, right?

You mentioned in Richmond, and you mentioned context to understand what applications and, and what they're doing. One of the things we were talking about earlier is, you know, the idea of least privilege, right? And making sure that the keys have the right permissions to only be used for what they're supposed to be used for.

So, so how do you go about doing that? Is it a, you know, big brain machine learning thing? Do you have a whole bunch of, you know, folks in the back room, you know, checking out stuff?

Uh, what, what's, I, I probably, it's probably not that, um, that seems like a very 1950s type of thing, but, uh, h how do you guys take, take the approach of, of figuring out what the appropriate privileges are for those secrets and then, you know, applying that, you know, to the specific policies that would govern? Right. Soto does a lot of, a lot of different stuff around, uh, secret security and, and one of them is, as you mentioned, uh, the list privileged principles.

So we are using a API course and we are leveraging access logs. Um, and, and we are able to not only discover all of the secrets within your environment and say how many secrets you have and where are they. We are then classifying and enriching each secret.

So we are integrated to all places in which secrets can be stored or exposed by data because they, they are committing secrets into code. They're sending them through Slack messages or other collaboration. They are saving them within Confluence manuals, uh, and then world solutions and cloud services solutions and et cetera.

Uh, so we are able to find all of the secrets within the organization, and then we are able to visualize a map around them and basically to enrich them with context or to classify them and create a secret lineage map of which application is using what secret in order to authenticate to what cloud service and other vital data around that secret, such as what are the privileges of that secret? Yeah. Uh, who created it, when, who is using it?

What are the risks that are associated with it? Uh, and then we are constantly monitor those secrets for any abnormal behavior or anomaly detection around that secret. So if your secrets are being used, uh, from China, Russia, or any country in which you don't have business in, uh, we will let you know.

Uh, so we are, we are continued continuously monitor those secrets for any abnormal behavior. And that give us a lot of a lot of insights that one of them to your question is the list privilege. So let's say you have an application which is using a secret with right permission in order to authenticate against the database, and that database is only doing read operation, but the secret is if right permission, you can and probably should decrease the permission over that secret, but it's also a great mitigation step.

So let's say we found an exposed secret within your code, and it's, it's a challenge to remove it from there because of many reasons. Okay? At least in the meantime, decrease the permission of that ticket and remove it from the code, from the exposure location afterwards.

Yeah. Yep. Well, good.

So we kinda went through visibility and discovery and making sure that you understand where all these secrets are across your entire environment, cloud platforms, Kubernetes, environment, C I C D, content sharing, right? You know, kind of Jira, confluence, you know, those kind of things. Talk a little bit about, um, the importance of, of actually having policies to, you know, control the use of those and, and, and really to continuously monitor that environment.

Because again, it's always changing. It's very dynamic. Developers do what developers do, right?

Which is, uh, try to get their job done. So they're going to, and they don't view it as a shortcut, right? They don't view it as cutting corners.

They don't view it as doing the wrong thing, right? What they do is take action to get their job done right. And sometimes it means over permission or over permissive policies on that front because they're just trying to get stuff done.

And that, you know, what happens in dev tends to follow into test and then into par, and then all hell breaks loose on that front. So keeping track of it, I think is, is pretty important, uh, on that front. Uh, it a thanks for giving us a, an overview, uh, of secrets.

I think it is an important and, and emerging, you know, kind of concern that, that folks have to worry about if they wanna learn more about secrets or, or intro, you know, how do they get in touch with you guys Easily? Um, security, https, s security, you can reach us, you can reach me on LinkedIn, or you can just look it up on Google. Well, great.

So, uh, ITVA, thanks so much for being here. Uh, co-founder and c e o intro security, we were talking about secrets and the importance of really the foundational aspect, uh, of secrets within the environment. Uh, so with that, let's send it back to the studio for our next interview.