Itzik Alvas -- Secrets Security and Management

Itzik Alvas, Co-founder and CEO of Entro, is an expert on secrets security.
Itzik joins Chris and Robert to discuss the significance of understanding and managing secrets, emphasizing the importance of knowing how many secrets an organization has, where they are located, and their potential impact. He elaborates on the three pillars of secrets management: listing and locating secrets, classifying and understanding their potential blast radius, and monitoring them for any abnormal behavior.

The conversation takes a turn towards the future of secrets management, where Itzik believes there's a need for a shift in mentality. He stresses the importance of education in this domain, urging listeners to seek knowledge, understand the potential risks, and start with actionable steps. Itzik's perspective on prioritizing risks, investing in processes, and the challenges of remediation offers a fresh take on application security.

As the episode wraps up, Itzik shares a key takeaway for the audience: the importance of getting educated about secrets, understanding their potential risks, and starting with quick, actionable steps. Chris Romeo, the host, and Itzik also touch upon their love for sci-fi, adding a personal touch to the conversation. This episode is a must-listen for anyone keen on enhancing their understanding of secrets security and management.


Helpful Links:
Entro -- https://entro.security/

Recommended Reading:
Foundation by Isaac Asimov -- https://www.amazon.com/Foundation-Isaac-Asimov/dp/0553293354
Ringworld by Larry Niven -- https://www.amazon.com/dp/B0B1911GL1
Seveneves by Neal Stephenson -- https://www.amazon.com/Seveneves-Neal-Stephenson/dp/0062334514

FOLLOW OUR SOCIAL MEDIA:

➜Twitter: @AppSecPodcast
➜LinkedIn: The Application Security Podcast
➜YouTube: https://www.youtube.com/@ApplicationSecurityPodcast

Thanks for Listening!

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Transcript

Chris Romeo: 0:00

Itzik Alvas started his cybersecurity journey 17 years ago, when he was selected to join the elite cybersecurity unit of the IDF, Israel Defense Forces. He was introduced to the cybersecurity ecosystem there and gained enormous knowledge and experience on a nation state level. After serving for five years, he moved to the real world, where he held various positions in the industry, including developer, DevOps, cybersecurity researcher, and CISO of a major healthcare organization, before becoming the head of security and SRE at Microsoft. Now, he's the co founder and CEO of Entro Security. Itzik joins us to explore secret security and management. We discuss common challenges, why this issue is growing, and how secret tools help companies of all sizes. We hope you enjoy this conversation with Itzik Alvas. Hey folks, welcome to another episode of the original application security podcast. I'm just trying to mix it up a little bit for you as listeners because you've heard me say the same thing Roughly 260 times over the last seven years. This is Chris Romeo I'm the CEO of Kerr Ventures and a stealth startup joined by my good friend and comrade in application security, Robert Hurlbut. Hey, Robert.

Robert Hurlbut: 1:54

Hey, Chris. Yeah. Robert Harbert and principal application security architect and threat mulling lead at Aquia. And uh, yeah, it's seven years, right? Uh.

Chris Romeo: 2:03

We are, we are the original application security podcast. Like we were the first people out of the gate, and now there's a lot of people that are, there's a lot of other, there's a lot of other great podcasts out there that are, that are doing. Talking about application security and I don't mind saying who they are. I don't care. I mean Application Security Weekly I've been a guest on that show. There's Absolute AppSec, that's another great show. So there's a lot of good. There's a lot of good content out there, but we hope you're enjoying listening to Our approach for how we talk about AppSec. So let's jump in. Itzik Alvas is our guest here today. And Itzik, we always like to jump right into the deep end with people's security origin story. We give you exactly zero seconds to warm up for the conversation. We're just like, welcome to the show. Where are you, you know, how'd you get into cyber slash application security?

Itzik Alvas: 2:51

Yeah. So Chris, first of all, thanks for, thanks for having me. I started, uh, at the Israeli army, at the Israeli Defense Force, um, was a part of, uh, one of the intelligence units was on the offensive side of things. Um, so, you know, I've been there for, for several years. Uh, it was 17 years ago. Um, and then, you know, after the army, I became Developer and DevOps and, you know, went back to the cyber industry, uh, after about two years. Um, so I've been working, you know, as, as AppSec, it wasn't the name of it then, but you know, it was an AppSec role. Um, but quickly I became a manager. Um, I always find, you know, managing teams and then, um, maybe divisions and et cetera, being, being more. My kind of thing to do. Um, so before, uh, before, you know, my current role, Um, I was, uh, in charge for the security, internal security of, uh, Microsoft Defender for Azure. And then, uh, prior for that, prior to that, uh, I was, uh, a CISO of, uh, the largest, uh, healthcare organization in, uh, both Israel and then Europe. Uh, and... You know, now I'm, I'm the CEO of, uh, Entro Security, uh, and we, uh, protect, uh, secrets. I'm, I'm always saying, uh, that being a CISO is, you know, harder than, uh, creating your own company. So, you know, it's, it's a, it's a tough role. Yeah.

Chris Romeo: 4:28

I understand. I've never been a CISO, so I can't say... I've started my own company, but I've never been a CISO, so I don't know how to compare that. But now I'm curious, why, why would you say being a CISO is harder than starting your own company?

Itzik Alvas: 4:40

Yeah. So a lot of, a lot of responsibility and what you really want to do is, you know, enable the business because that's what everyone wants to do, right? And enabling the business is basically enabling Marketing, enabling R& D, enable sales, enable everyone, but you are the gatekeeper, right? Uh, so you must make sure that everyone is, you know, safe and protect the company. Um, so you are putting some guardians in places and it's, you know, it's a chaos trying to balance all of that together. Uh, enable everyone and then, you know, keeping everyone safe. Uh, it's a lot of work. And then, you know, you're always Short of stuff, right? So, a good, yeah, so a nice balance is like one security guy for 20 engineers so that's like a proper balance and it's still, you know, one for 20 and in most cases it's like one for 50 and etc. So it's, you know, it's a tough call.

Chris Romeo: 5:47

Did you find the CISO role is something that was like a 24-7 responsibility, and you were always getting.... because like as a startup founder, yes, it's a hectic lifestyle sometimes, but you can inject work life balance properly. It's not always work life balance, but you can inject some of it, but I'm curious like as a CISO, is it really 24-7? Are you getting called in the middle of the night on the weekends and have to jump on calls and deal with stuff?

Itzik Alvas: 6:13

Um, so, so yeah, I mean, hopefully it's not the case for, you know, most companies, but then you have your IR team, right? Um, which you are responsible for, and then it's, it's incident response, right? So every incident, of course, if it's a security incident, you need to be involved. And then you, you know, you have strict deadlines with compliance and regulation and et cetera. So again, you need to enable the business, but keep everything, you know, in place. Um, so yeah, 24-7. Um, yeah, it's, it's, it's kind of, you know, um, a position like that. And then, of course, you're, you're C, C level, so you are reporting to management that they would like to get things done the sooner the better, so it's, you know, it's, uh, yeah, 24-7 role, definitely.

Robert Hurlbut: 7:06

I can imagine. So just to dive into our topic today, uh, it's, it's, um, In the context of application security, can you explain, and this is, I know, your focus area, but what secrets and secrets management is and why it's so crucial for protecting sensitive information within applications? All

Itzik Alvas: 7:26

Yeah, sure. I mean, even, even more general than that, right? Because, you know, secrets are basically the, the pigment block. So, so let's maybe define a secret, uh, shortly. So in, in the most simplest way, uh, secrets are programmatic access keys. And, you know, what, what does that mean? Um, every application that is being developed within, Uh, every company, uh, they need to use infrastructure or other services such as databases or storage accounts and etc. And in order for those applications to authenticate against, uh, the infrastructure, they need, uh, keys such as passwords, API keys, connection strings, access tokens, and etc. And, uh, those, those are secrets. And, I mean, as you can imagine, you would like to keep your keys safe. Um. So, so, yeah, they are crucial, crucial part of, you know, securing your environment because you have a lot of keys out there. Um, and those keys can access your most, you know, sensitive resources. Um, so, yeah, I mean, that's, that's important topic for any security guy.

Chris Romeo: 8:40

So in a general, let's just pick a large enterprise. How many secrets exist? you

Itzik Alvas: 8:48

Yeah, so,

Chris Romeo: 8:49

you know, based on a large enterprise?

Itzik Alvas: 8:51

yeah, so, you know, our, uh, current, the current average we're seeing is about 30 secrets. Uh, for every engineer. Um,

Chris Romeo: 9:00

30 secrets for every engineer?

Itzik Alvas: 9:02

yeah. So that's, I know, right? Uh, and then you, you know, you have, um, so, so I saw maybe, maybe I can find the link for it, but I saw an article that says that, uh, you have eight workloads or eight, uh, machines, um, and, and that's, I mean, not endpoints, you know, servers and, and, Kubernetes, and Cloud Workloads. So eight Cloud Workloads for every employee. So that's also insane, right?

Chris Romeo: 9:34

That's a big, that's a big number. I'm still stuck on 30 secrets per developer per engineer, so. But that's gonna, that's gonna include everything though, right? Like, that's gonna be, um, you know, development, development environments, staging environments, production environments, like. It's not, it's not 30 production level secrets. It's 30 secrets total across everything that they have access to.

Itzik Alvas: 10:00

yeah. Yeah, yeah, of course. Um, and you know, another problem is, you know, trying to understand if you have any, you know, cross accounts. If you have production secrets that are laying around on your development environment and etc. And, you know, you have, um. Test, uh, environment or test workloads that are, um, connecting to, with, you know, production secrets connecting to production, uh, resources and et cetera. So yeah, you know, it's, it's a challenge.

Chris Romeo: 10:32

Now, when you think about a proper enterprise secrets management, scratch enterprise, proper, any, any company, a proper secrets management program, let's call it a program.

Itzik Alvas: 10:45

Yeah.

Chris Romeo: 10:45

What are the two or three pillars of that program? when it comes to doing proper secrets management, whether I'm a startup or whether I'm a hundred thousand people enterprise.

Itzik Alvas: 10:57

Yeah. You know, so I guess the first one, uh, is having a secret inventory, right? It, it makes sense, but it's, it's not easy. I mean, trying to understand how many secrets you have, where are they, uh, a proper secret inventory, how many keys I have. Where are they? That's, that's like number one. And then, um, so, so secrets if, you know, if you've ever seen one, it's, it's a long string. So it's, uh, if you see it, you have no information about it. You don't know what it can do, you don't know what cloud service it can access, with what privileges, when it was last replaced or rotated. Um, so trying to figure out what that secret can do, that's, uh, pillar number two, right? So, you know, get a list of all of your secrets, understand how many secrets you have, where are they? and then try to, you know, visualize, um, what they can do, which application are using what secret to access, which cloud service with what permission, who created that secret, when, why, you know, get, get some context over it, um, to classify it, enrich it, and, and, you know, understand what the severity or blast radius of each one of your secrets. So that's, that's pillar number two. And then, um, if you are following the, um, You know, the latest reports of Secrets targeted attacks are among the top three attack vectors out there. Number one, most costly, most destructive kind of attack. You know, we've seen LastPass, we've seen Slack, SolarWinds. We've seen a lot of, you know, companies getting breached by Secrets. So, you know, maybe the third one is monitoring them for any abnormal behavior. So if your Secrets are being accessed from China and you don't have business over there. I guess you would like to monitor that and get an alert about that, right? So, abnormal behavior, secrets, um, misuse, abuse, and etc. So that, that will be pillar number three. So, first of all, get a list. Understand how many secrets you have, where are they, then enrich them, classify them, understand their blast radius, and then monitor them for any anomaly. If that,

Chris Romeo: 13:06

I guess another, another part of the program is how you get them into production at the right time. There's like the injection of secrets as well, right? That would, that would sit, I mean, all those other things are supported, but their ultimate goal of those other things is to protect the secrets so that you can inject them into a production image at the right time, limiting the amount so that you don't load the secrets up at the beginning of the build pipeline and let them ride along through the whole CICD pipeline. There's that, that magic step in the pipeline where you inject secrets and then push the container out to the world. You know, at the last second. So I guess that's, that's, that's the other part I'm thinking about when I think about secrets management is, is that injection point of when it goes into the wild, nah, not the wild. My Kubernetes cluster is not the wild. I guess it could be, but hopefully it's not the wild.

Itzik Alvas: 13:59

it could be, but, you know, the, the whole secret creation is, is a challenge because... How do you create secrets, right? So maybe you are using a database, um, a MongoDB, for example, and then you have developers or, or DevOps or SREs, and they are, um, creating those secrets. So what they will do, they will connect into the MongoDB management UI, and then they will, will create a secret over there. And then... They will need, you know, to store the secret somewhere, right? For the application to fetch it from that location and use it to access that MongoDB. So, you know, the entire creation process is a complete mayhem because that DevOps will probably download that secret into his personal laptop, right? And then he will upload it to somewhere. You know, secret storage of some kind, um, so, so yeah, I mean, secret creation and, you know, the entire process has been done without any security oversight, um, so yeah, I'd say it's, I totally agree it's a challenge, but, you know, again, trying to understand how many secrets you have, trying, uh, to classify them and then monitor them for every, for every risk, I think it's, those are the, the larger chunks because, You can't really control everything. So let's say you have the entire creation process secure. Let's say you have the, you know, the, the secret that is being shipped to the, to the container on the right time and, and everything, you know, is built out right. And then you have a developer that is basically printing out that secret into log, or maybe, you know, in, in some sort of an exception. So we've seen a company that, you know, They had an error, they couldn't connect into their database, and on their commercial website you would see the error message with an exception with the secret within it. So, you know, it's a challenge, developers make mistakes, everyone is, you know, telling them to move fast, and you need to monitor how your secrets are being used and from where.

Chris Romeo: 16:01

Yeah. Yeah. So I feel like we've, we've kind of explored the complexity of the problem. Like, why is this such a complex problem? Because there's so many. There's 30 secrets per developer and you have a thousand developers. That's a lot of secrets moving around. So to your point about inventorying, understanding, controlling, managing those secrets, that certainly breeds a high amount of complexity to any organization. And I feel like we've already talked about common challenges as well, because you highlighted You know, developers downloading secrets onto their devices and those getting pushed up. Developers writing secrets into log files. Any other challenges that you can think of that, um, other than downloading secrets, uh, or exposing them in log files? Like, what are, what are a couple other... to top the biggest, biggest challenges or biggest problems that developers have working with secrets.

Itzik Alvas: 16:54

Yeah, so you know, the name of the problem is Secrets for All. It's basically, you know, developers and devops are scattering secrets all over the place. Um, so something we, you know, everyone is seeing all of the time is those secrets are being committed into code, uh, by mistake. Um, so you know, you have, you have a developer who is working on his environment, his, his personal laptop, and then when he commit that. You know, that code into production environment, you leave the secret over there. Um, so your secrets are being committed into code, and a lot of the time those, you know, are public, are repositories, so that's wide open. And then, you know, a common practice we see all of the time is uh, developers that are basically copying out secrets and sending them over Slack or Teams to their peers, because, yeah, you know, I need to connect to my storage account, how can I do it? Oh, here you go, take... They just use it using that command. Um, you know, within manuals, that's something we are seeing all of the time. So, you know, within Asana or Confluence or maybe support system, um, so within manuals, Wikipedias and et cetera, we are seeing secrets being saved all of the time. Yeah, it's a huge problem. It's a huge problem. Um, but I guess, you know, number one is, uh, secrets that are being committed to code and then the second one is secrets that are being, you know, sent over. Slack, and etc. And a lot of the time those are public channels. Um, so yeah. Yeah.

Chris Romeo: 18:23

You're making me feel a little bit guilty here. It's like, so I have not, I can, I can say beyond a shadow of a doubt, I have not committed a secret into code because I, but I have been guilty of passing secrets over a team's message, for example, because I needed to get a secret to somebody quickly. So, guilty, as charged, I get it. I just want to let our audience know, if you're sitting there feeling like, Oh, I've done all of these things, uh, listen, I've been doing security for 26 years at this point. And, uh, I have, in the last number of months, transferred a secret. over a team's message. Then I deleted it after with the hope that it would never be found again. It's still this. I have this problem too, just like everybody else in the industry. Robert probably doesn't because Robert is an AppSec professional to the stars and he, uh, would never share a secret in such a way that I would.

Robert Hurlbut: 19:15

definitely make sure I keep aware, but I'm sure there is at some point I've done it. Um, so, you know, we talked a bit about the challenges, but. Uh, is this an issue that's growing exponentially? Are we seeing it more and more now? Are we more aware of it now?

Itzik Alvas: 19:34

Yeah, so you know, we are seeing more and more of it. Um, you know, with the rise of cloud services, and you know, each different cloud service needs at least one secret. They need probably a few secrets, each one. So I'm not really sure how many services there are within AWS, but. A lot. And then, you know, other SaaS services and etcetera. And if your application needs to authenticate against, um, MailChimp, they need a secret. If they need to authenticate against, um, you know, HubSpot or MongoDB or etc. They need another secret and another one and another one. So with the rise of, you know, cloud services, um, and that's growing, uh, so yeah, you need a secret pair, you know, pair, pair cloud service. And then... You have your microservices, right? So that that's the thing for the last like what five years and now you have a lot of Ports and containers and each one of those containers needs a set of secrets, right? Um, so yeah, I mean that's that's growing all of the time and People just lose track of how many secrets they have and you know, yeah, it's it's a huge huge number of secrets per company.

Chris Romeo: 20:49

Yeah, that's a good, that's a good point. And, um, let the record show I'm out on microservices. I know people, there are people in the industry that still believe in them. I believe microservices work for the top 5 percent of the tech companies in the world that can pull off a microservices architecture. Everybody else just join the rest of us. Come back to the monolith. Love the monolith for what it is, because if you're not Netflix or somebody like that, you can't, you can't do microservices in the way that, and this is a bit of a soapbox moment I'm realizing. So I'm going to come back around to what we're actually talking about here.

Itzik Alvas: 21:22

Yeah, but you have lambdas, you have functions, you have, you know, a lot of, a lot of stuff in the, in the cloud are, you know, kind of a microservice.

Chris Romeo: 21:32

That's true. That's true. I mean, the Lambdas of the world and Azure key function. I think they're key functions, maybe, or whatever they call them. Yeah, like, um, I would love to build an entire SAS platform on my, on, um, Lambdas. It's got to be possible to, to build an entire infrastructure and... Because then you don't have to ever worry about scalability. Like, how do you scale? I don't. I just sit here. You can have a million people hit our site and it will not fall over because we're all in lambda functions. But, um, that's a whole other conversation perhaps for another day. So it's like when you think about the future of, of secrets management, this, this field that you're a part of right now with intro security. What, what, how can we improve, how can we improve technologically based on secrets management and, and this field of this discipline practice?

Itzik Alvas: 22:24

Yeah. So I think the mentality, you know, needs to shift. Um, so, you know, the current solutions out there are mostly secret storages. All places in which we can, you know, store our secrets, but they are solutions for developers and, you know, the people that are creating the secrets, as mentioned earlier, are creating them, you know, without any security oversight, but truly, those are, you know, Passwords, and those are passwords for your most sensitive data and your customers data and etc for infrastructure. So the mentality needs to change and you know Security needs to own that process and not, you know, not the R& D team, not the developers, not the SREs, not the DevOps. So yeah, I mean secret storage are nice, but you know, you have a lot of them So maybe you are using AWS Secrets Manager. Maybe you are using Azure Key Vault or you know, Ashikov Vault, but then if you are leveraging Kubernetes all of a sudden you are probably leveraging the Kubernetes Vault, the Kubernetes Secrets and Then you know, GenKey Secrets and GitHub Secrets and etc. So you have a lot of vaults and because you know, developers are using what's It's in front of them and easy and, and, you know, fast test. Um, so you need protocols and you need, uh, security to own that. Uh, but, you know, enforcing those protocols can be a challenge also, right? Uh, so you need some sort of, you know, monitoring tool to understand, um, that people are using the, the, the right, you know, solutions for that problem. Um, and then, going back to the start of the conversation, you don't want to limit no one. You want to enable your R& D team. Uh, so you would like maybe a system, um, that you can just plug any, any vault, or any secret storage, or any secret input, and it will keep it secure and compliant, and you can, you can achieve that. Um, but, but again, you know, the first step is to understand that those secrets should be managed and controlled by the security teams and then you can find out that the right solution for it.

Chris Romeo: 24:32

So you're, you're advocating for almost like a secrets workflow management approach. So, and it's, it's bigger than just, uh, key, uh, AWS Key Manager or Azure Key Vault, which just lets you dump the secrets in, but it gives you none of the, none of the policy, none of the process that goes around it. I mean, I guess it gives you a little bit, but it doesn't, it doesn't force, it doesn't provide an easy way if somebody is a website and they somehow generate a secret. Like it doesn't allow that they have to copy paste it and move it around to get it into it. So like, so is it, am I on the right track here? Like is work, is secret workflow management kind of what, how you're thinking is the best way to solve this problem? Or is it something else?

Itzik Alvas: 25:19

Yeah, so, you know, it's it's a part of it. But so you need you know, you have compliance on the regulation and I guess, you know, security people would like to see secrets getting rotated and replaced. Um, and that should happen at least every 90 days according to SOC 2 and other regulations. So, of course, you know, processes around that or workflows around that make sense. But, again, does, you know, does a secret vault answer the problems or, you know, what we talked about earlier of, you know, understanding how many secrets they have, where are they, what they can do, and monitoring that. Um, so, I, I guess you need to reach that, that point. Uh, of course, using a vault, it's, it's a good solution and you should use a vault, but it's not, you know, having a vault and maybe automated the secret creation around it. It's, it's not, you know, it's, it's not a holistic approach to keep your secrets secured. Yeah,

Robert Hurlbut: 26:20

Okay.

Itzik Alvas: 26:21

uh, because again, you know, what, what about your secrets that are committed into code? I know you haven't done it, but people, a lot of developers are doing that, so, you know.

Robert Hurlbut: 26:32

So, again, just talking about the, the workflow, um, are there any other, uh, best practices or, or strategies that, um, you know, enterprises or even small companies, uh, thinking about this and, and reviewing what they have done? Are there any other things that you can recommend?

Itzik Alvas: 26:54

So, yeah, I mean, uh, there's a, there are, you know, a lot of things you can do, uh, but what you really want to achieve is maybe placing an air tag over your secrets, uh, so from the moment it was created you want to understand who's using it, when, who modified that secret, who duplicated it, who committed it to code, who sent it over Slack, um, so you would like to track, to track that secret and, and hopefully delete it some, someday, right? A lot of the time. Something that we are seeing, you know, often is idle secrets and those are secrets that are being created. No one is using them and those are enabled access keys that, you know, are waiting to be exploited. And then you have your systems that are already deprecated because they don't need those systems anymore, but no one deletes those secrets. So, so again, start with a list of how many secrets they have and then maybe you can, you know, start deleting those secrets and start protecting them. Um, so. First thing is, is get a list of how many secrets they have, where are they? That's probably the best advice I can share.

Robert Hurlbut: 28:03

So, you talked about, um, deleting, so, you know, I think about rotating, that's, that's fairly common, but you're really talking about a full life cycle then for a secret, right? Uh, creation, usage, who's using it, who's accessing it, uh, rotating, but also potentially, uh, end of life, you know, for, for services that are no longer in use, but secrets are still out there, uh, and, and, uh, and available and, and potentially, um, accessible. And, you know, if somebody is reusing a secret or, or maybe a service is, is just, like I said, not attended anymore, but there's a way in. Um, yeah, so that's truly a full life cycle for a secret. Sounds like.

Itzik Alvas: 28:49

Yeah, and you know, that's phase one, you know, phase two Just as an example, right? So those secrets have permissions. I can create a secret with a read capability over my MongoDB and then I can create an admin secret or a secret with write permission over my MongoDB write. So... Again, you need to probably monitor the usage of that secret, and if your application is only doing read operations against the database and the secret have admin capabilities, probably you want to decrease the secret permissions, right? So you know that there are phases, number 2 and 3, but again, start with, you know, having a list and understand how many secrets you have, are those enabled, are those in use, who is using them, how, why, and then, you know, start. One by one, uh, to, uh, reduce your, your attack surface.

Chris Romeo: 29:39

Very good. Okay, so before we go to the lightning round, which Robert will lead you through as our resident lightning round expert, I want to know what your company does. So let the record show, Itzik is not doing anything other than answering my question. So give me the 30 second pitch on Entro Security because now I'm curious as to how, after you explained how your, your kind of philosophy behind secrets management, now I want to know what your company does. So I'll give you 30 seconds to get to give us that pitch.

Itzik Alvas: 30:09

Yeah, so, you know, we are bringing, bringing, uh, secret security for security teams. That's, that's what we are doing. We are actually out of band system, uh, that is able to create that secret inventory. So we are able to scan your entire environment, if it's, um, secrets within vaults, or secrets that are being committed into code, or within your CICD, or within your Wikipedia, Slack, or wherever, wherever they are, and we will provide that secret inventory and then, uh, then we are able to enrich each secret, uh, and basically, you know, visualize it, uh, and understand who is using it, which application, when it was created, when it was last rotated, um, what are, you know, the risks that are associated with, with each, uh, secret. We are also monitoring those secrets. We can understand if, you know, you have an application that is fetching two secrets and now they are fetching ten. Um, so, you know, if those secrets are being, uh, abused, uh, we will let you know. Also, uh, vaults misconfiguration, because a lot of the time you are, you know, onboarding, uh, a secret storage, but then you keep it open to the, to the World Wide Web. Um, or any other misconfiguration around secret, uh, uh, or secrets vaults, we will, uh, again, let you know. Uh, we're, we're gonna also discover all of your secret vaults out there, so if someone onboarded you to Kubernetes secrets and you didn't realize that, uh, we will let you know. Of course, public leakage of secrets, we will let you know. Dark web leakage of secrets, we'll let you know. Uh, the over permissive secrets that we talked about, yeah, we will let you know. Uh, everything around it. If you have a developer that Uh, left the organization and he created a token. You were responsible, you deleted his user, the token he created is still, you know, it's unrelated, it's still active and enabled. Um, so, yeah, we will let you know, hey, you are, you know, a past employee who left the organization and... They still have an active token. And if someone uses the token, again, we will, we will alert you about that token is being in use. So it's a holistic solution for, for secret security, out of band, um, the developers can keep doing their own thing, the DevOps can keep doing their own thing, but, you know, we will let, um, we will let security know what's up and, and protect the secrets, uh, and we will give you automated ways to do that.

Chris Romeo: 32:28

That's very good. Very good. Awesome. Thanks for sharing that with me. I did, I really did want to understand how you approached it based on how you answered all these other questions. That was really, really helpful. So Robert lightning round. I wish we had some music to queue up. We don't, I don't have any music for the lightning round yet, but it's coming. We're going to, we're going to create some, but Robert, take us through the lightning round, please.

Robert Hurlbut: 32:47

We'll do. All right. So, um, what's your most controversial opinion on application security and why do you hold this view?

Itzik Alvas: 32:54

Yeah, so, I think they are creating, um, a lot of risks and, and probably they should prioritize them better and, and, you know, even better than that, they should invest more in creating processes and not, you know, uh, create more risk that the R& D or the technical teams needs to handle because they are busy, right? Uh, and, and if you are using a system that can find vulnerabilities, uh, within your code, uh, that's great, but then, you know, it's, it's a challenge to remediate that. So pick and choose your battles. They probably need to do that better and, you know, let's, let's bring it into the, into the secret world. I can scan, you know, your code and find a thousand secrets over there and I can, you know, ask the, the CTO to remove that thousand secrets. But I can maybe dip a bit farther and understand that 800 of them are already disabled at the cloud service level. So who caress leave them at your code, but end those two enable 200 enabled secrets. So, so yeah, I mean, maybe deep dive a bit better and then, you know, only handle, uh, the most critical risks and, and if you can create a process to automate that, that will be, that will be great. Um, so, you know, be more kind to your, you know, fellow R&D teams.

Robert Hurlbut: 34:20

Makes sense. So what's your, um, or sorry, what would it say if you could display a single message on a billboard at the RSA or Black Hat conference?

Itzik Alvas: 34:32

Yeah. Uh, you know, I, I, I can do it and we are doing that. Um, so it's, it's. Yeah, it's protect your secrets. Most definitely. It's already, you know, one of the top three attack vectors out there. So, you know, pay, pay attention to those, you know, if you are, if you are protecting your human users that can access your emails and, you know, drive, I guess you should protect your machine users and passwords that can access your databases.

Robert Hurlbut: 35:01

Very cool. And then finally, what's your top book recommendation? It can be really any topic. We've focused mostly on security in the past, but we've had some really, really good recommendations that are not security specific. But what is it and what do you find valuable about it?

Itzik Alvas: 35:20

Yeah, so, you know, I'm, I'm a sci fi fan. So I, you know, I'm also an Harry Potter geek. But I, but I won't use, I won't use Harry Potter. So I guess maybe Foundation or Ringworld. Yeah, by Larry Neville, I think. So go ahead, read that great sci fi book. Also, again, I love sci fi, so you need the list. Feel free, hit me up over LinkedIn, uh, they will provide the list. Yeah, so I'm keeping the security books outside. Also, I have a great list about those.

Chris Romeo: 35:57

It's good to work outside of our discipline sometimes. Like I'm reading a great sci fi book right now called Seven Eves. And, uh, so that's just, you mentioned sci fi, I'm gonna throw it out there as well. I can't remember off the top of my head who wrote it, uh, but Seveneves, it's, it's, it's a really good, really good sci fi story. So, um, check that one out as well. So, Itzik, thank you, uh, for, for being a part of the show with us. How about a key takeaway? Like, um, give us just a simple key takeaway that our audience can, can put into action here.

Itzik Alvas: 36:26

Yeah, so, you know, get yourself educated about it. You know, find blogs, uh, search the web, understand what, you know, those secrets can do, how to best, uh, how to best protect them, how to best manage them, and, and, you know, start with the quick wins. Start, start easy. Don't, you know, create a plan that you will execute in two years. Pick something you can do tomorrow, start easy, and do it.

Chris Romeo: 36:53

It's like, thanks for being with us. Thanks for sharing your expertise

Itzik Alvas: 36:56

for the time.

Chris Romeo: 36:56

the stories. And we really enjoyed it and learned a lot about secrets management. So once again, thanks for being on the show.

Itzik Alvas: 37:02

Yeah, thanks for having me.