Challenges of Secrets Management – Oded Hareven, Akeyless

This is Textron TV. Hey guys. Thanks for the throw.

We're here with Odin Harvin. And he's the CEO for a keyless and we're talking about Secrets management, which is not necessarily a new topic, but it sure is top of mind for a lot of folks. These days are dead.

Welcome the show. Hey. Hey Mike.

How are you? It's good to be here. Thank you for inviting me.

What exactly is the fundamental issue with Secrets management developers have been trying to manage Secrets forever with mixed success. It seems like it's always been a problem and we're more aware of the issue these days what exactly is there hurdle? What keeps tripping us up here?

Yeah, so secret sprawl is been a phenomenon that have been you might say. In the old days right having a passwords within a source code or within a certain configuration file was not you know was not something special because in the on-prem perimeter right now everyone thought about it seems like it's okay. No one would get into our Network and that would be fine.

The new secret sprawl problem is about having thousands of containers that need to communicate with each other and suddenly you have much more secrets than you used to have. There are devops platform today with infrastructure's code with everything is code with automated processes that are running and basically the magnitude of the problem became much more severe having more servers than employees than what we used to have 10 years ago. Everything my way everything by the way is as a result of the cloud transformation and they adoption of devops methodologies.

So how do we solve this problem? Because to your point we do have this brawl. So is this something I solve on the developer side, or do I solve it in my cicd devops workflow where exactly is the point of attack for solving the issue?

Well and all of those places, well, you can start slowly but surely with your devops environments which requires plugins your plugging in whatever that needed in order to connect our secrets management system. That would allow the fetch of those of those Secrets Iran time. Okay, so After that, you can go to the actual code and then use sdks in order to fetch those secrets in one time.

You would need both because for instance Jenkins and whatever you're using for cicd or kubernetes classrooms would expect those secrets to be there and code specifically would be able to use any sdks, right? So it depends where you want to start but that's not the whole thing. Right?

So for source code configuration find that would be good. So you have the ci/cd you have cooperated and you have the sdks as we've mentioned but there are other places like the traditional Excel sheet that people still use so for that we provide also CLI and we also provide browser add-on that would allow you to basically completely eliminate the secrets that you're using. There are SSH keys that most the are kept just on the disk itself and we're providing and mechanism that allows you to completely migrate to SSH certificates.

So all of those all together, it's a 360 Degrees, you know problem and a solution that you need to solve. So yeah. With the Common Thread seems to be that we need to put the secrets in some sort of repository that's isolated from the rest of the code so that they when they code is compromised the Secrets Don't Go With It.

Exactly. This is exactly the notion of Secrets management the elimination of whatever secrets that you have whenever they are. And by the way, we haven't defined the term Secrets right passwords credentials certificates and keys, right?

This is a combined world of both IAM and the pki encryption World altogether. So all of those objects need to be eliminated as much possible to be reduced in terms of the potential compromise, whatever they are being breached. Are the bad guys getting smarter at looking for this stuff that they know what they're looking for.

Are they creating specific types of tools to go after it? I mean, what is the level of threat that we're seeing the same specifically at these types of Secrets? Well, even if they're not getting smarter the fact is that almost every breach famous breach that you've heard adjust the recent Uber and Toyota have some type of secret involved.

Right? What used to be the privilege document problem 10 years ago or 15 years ago. No becomes much more severe again as a result of the rise of that phenomena of secret scroll.

So basically again every famous breach today have some kind of credentials hacked certificate exploited encryption key that was found somewhere. So it becomes even simple for for attackers to basically search for that because they are there in their thousands right just as a result of the way that early working speaking of that. It's almost sounds like you know, our culture is as big as a problem as the technology itself.

So how do we change the culture among folks who are kind of used to being shall we say maybe a little careless with their secrets? Well, I wouldn't say that there are careless. And as far as what we've seen there's a good friend in the market today of more and more people that are more aware of where they put their credentials especially among the devops community.

By the way, although there are people that are still saying there is a security there's a infrastructure and they would never work together devops in general. We find them to be more and more responsible for what then they produce it's true that they care about the bottom line how to get faster to results. But in terms of response responsibility, you know, there's a point in time and speaking also as an infrastructure person like 20 years ago, if you have a password here and there that's true that what we used to have but today the problem is jumping right at you and you feel that there's something that you need to do with it because it's it's not just a security thing rather than operationally you're not able to Basically manage all of those altogether and you need something to be able to not just vote your secrets and not just rotate the passwords that you have or issue new certificates rather than dynamically create just in time credentials whenever they are needed so it becomes now a question not just about security but for devops, it's now a question of efficiency right whether I would be able to not just leverage an existing credentials rather than creating them on the fly it releasing that we that's credentials as as much as I do that or the same that I've do it as a devops person with my resources, I Define resources and then they are being released.

Therefore credentials need to be defined and to be deleted. It's smart both on the security and in terms of the operational aspect. Are the cybersecurity folks getting more involved or compliance people starting to become aware of this issue where they asking tougher questions and that's part of this whole shift towards devsecops that we're talking about.

Well, generally speaking credentials certificates have always been within the regulations and whatever compliance that was there stock to specific for SAS companies is definitely relevant in terms of rotating password for dating credentials. So we do see movement out of there and good motivation to start motivation to start dealing with Secrets management, but to be very honest with you, it is becoming a best practice. So we're not even waiting for regulation to be very specific about Secrets management within workloads within devops platform rather than just seeing it as a best practice within whatever devops security system or program that yeah.

So are you cautiously optimistic about the future state of application security are we really getting better? Or I wonder if we have so many applications out there with so many issues in it that the technical debt is overwhelming as it is and we'll never solve this issue. Well, I'm optimistic by Nature.

So it's hard for me to answer differently, but I'll tell you this 20 years ago or 17 years ago. I was managing a team or commanding a team in the Israeli films forces that was specialized with Consulting to application systems and application the system development teams and back then the tools that we've had in order to understand how to secure the application. We're so narrow we were trying to get the attention of the developers and it was like elephants speaking with I don't know with whatever with with alligators.

Okay. We did not have any any common language today to see applications security Engineers speaks with a different engineer or devops. They even have the concept of deaf Secaucus whether it is widely used or not but to have to see all of those engagement and Collaboration around it it is tremendously different than what we used to have it like 20 years ago.

So definitely optimistic about how we're going to make it and how we're gonna make it better. Do you think we might have to create a new role called the security engineer in these processes? Because you know, we've seen site reliability engineers.

And so we'll security Engineers emerged to lock down our software Supply chains. Oh not a question. Well devsecops is kind of, you know part of it.

I've seen application security Engineers as part of R&D, so it is starting to happen. And I think that we should well we already see product security within software companies, but I think that the trend would become even more Broad and maybe more early in the development Cycles. The aspect of security needs to be spoken much earlier, right?

But again today it's a complete different thing than what we used to have. So the trend is very very positive. So what's that one behavior that you see people doing in organizations?

That kind of just makes you shake your head and what's your best advice for fixing it? Communicate I think that communication among infrastructure teams security teams, but I'll I'll make it even more specific for you. I see unfortunately sometimes teams within the security team more more of larger Enterprises, right?

I am that does not necessarily speak with the security infrastructure with the network security infrastructure, and you'll be surprised how ztna is close to privilege Texas management. I see cases where pki are not necessarily speaking with devops. Although it is very very close.

Right devops require those kind of certificates, but the pki sometimes can be more traditional thinking right. So this whole realm and by the way, this is what fascinates us about what's Happening Here is transitioning and there are a lot of different systems that used to be the spirit and siled. And today we Secrets management it is kind of you might call it as a swiril that takes all of those use cases all together with certificate automation with key management with credentials management password management privilege access management all those all together with a core of Secrets at the center.

So what we see is that organizations that are you know, smart to actually communicate between all those teams, they gain a lot of value and at the end of the day also, they can reduce a lot of a lot of clutter and a lot of costs in terms of how those use cases. Yeah. get sold All right, folks.

Well, I guess loose lips still sink the proverbial digital ship. So keep those Secrets close. Hey debt.

Thanks for being on the show. Sure, anytime Mike. Thank you for having me.

All right back to you guys in the studio.