Securing the Spectrum: Enterprise Secrets Management for Humans, Workloads, and Things

Welcome to our KuppingerCole webinar, Securing the Spectrum, Enterprise Secrets Management for Humans, Workloads, and Things. In this webinar, we will look at the broader market secrets management, which includes aspects like what is nowadays popular as non-human identity management, machine identities, etc., but more from an enterprise perspective. I hope that Odette will finally be able to make it. He's the CEO of Akeyless. Akeyless is supporting this webinar. Thank you for that. Due to an unexpected issue, he is not yet here.

If not, I'll cover the various questions we're figuring out, and hopefully he can solve the issue. Just as a side note, I'd like to proceed directly to the housekeeping and then looking into the agenda and all the other aspects. From a technical perspective, if audio control, you are muted centrally, so we are controlling these features. Nothing to do from your end. We will run one poll during this webinar only. We will have, if Odette arrives, a conversation.

Otherwise, I'll go through some questions and merge it into the Q&A session, but you will have at any time the option to ask your questions. There's an area of questions. You'll find a button on the lower right area of the webinar tool. We are recording the webinar, and I will make available the slide deck shortly after the webinar. A quick look at the agenda.

The plan is that I talk, and that's what I will anyway do, about enterprise secrets management and some of the results and perspectives we gathered during the work on the leadership conference on this topic on enterprise secrets management. In the second part, there will be some additional insights on a series of themes that we decided to look at together, so either Odette with me or only me.

As I've said, we will anyway merge this a bit into the Q&A session, so at that point, really feel free to provide your questions at any time so that we can also pick up your questions and provide answers and perspectives to you on these. Having said this, I'd like to go to the first poll, and that is one which is maybe a bit for the more experienced in this segment, but when we look at this entire market, then we have secrets management, which is something I'll explain a bit later, more detail what I see beyond that.

We have the non-human identity management area, which also sometimes is referred to as machine identity management, which is, I would say, overlapping.

With that, we have keen cloud infrastructure entitlement management, which is out a bit longer, which is basically focusing on getting a grip on the entitlements services, so specific type of non-human identities have on resources, particularly in cloud environments, but also in sort of connected clusters and other sort of dynamic HR workloads, and privileged access management, which is more the traditional perspective of both humans and functional accounts, technical accounts, and their access to services.

This is a bit of a situation in the market where we have multiple areas, which all, in one way or the other, have overlaps to other areas, and what I'm curious about, and we'll leave this poll for a bit, is whether you expect, from your perspective, a convergence here or not, or maybe just the partial conversion. One of the seasons I sometimes bring up is that keen with the perspective on access of services to resources, in some ways, an NHAA, a non-human access management, and so there might be largely areas of conversions, but I'm really curious about your perspective.

Having said this, so let's look at what we covered in this composite on enterprise secrets management for humans, workloads, and things. It's long title, and it had a focus on holistic solutions.

That is a bit different, so when you take the currently popular NHAA market, and this is clearly a market that, in some way or another, is here to stay, it will be interesting to see, as I said, how solutions evolve, what converges, what stays separate, where do we see new types of solutions, maybe even being added, but what you also see from an enterprise perspective is that I say, okay, we already need to manage various types of secrets, and I'll touch what secrets are in a second.

For humans, we need to deal with whatever, FIDO2 tokens, we need to deal with SSH keys, SSH certificates, we need to traditionally deal with passwords, we right now see whatever API keys emerging in others, and we don't want to have too many solutions there, so where are the solutions that help us to do things that are similar, that can be handled in a similar manner, in this similar manner? So, this is basically why we went for this leadership compass first.

My colleague, Nitish, currently is starting to work on another leadership compass, which is in focus, devoted to the non-human identity management market segment, so that one is way more specific, and way more targeted, and all from a product and market segment perspective, while this one is really more from a user perspective, where we hear the organizations asking for who could be a provider that covers a wide range of secrets in a certain manner. So, when we look at secrets, as I've mentioned, there are many out of these.

Passwords, which had a minor focus in this leadership compass, the passwords are a bit different, we didn't really focus on password management, password walls, anything like that, but API keys, encryption keys, the private keys of certificates, API tokens, you name it, passkeys, et cetera, interesting topic for enterprises, for instance, how can you get a control about passkeys, but not having a passkey only bound to a single device, with people frequently using multiple devices, but if you want to allow passkeys only for corporate devices, then you have some new interesting challenges.

So, this was a bit, the scopes, secrets, and this is a non-comprehensive list, but that is basically where we started our work on this leadership compass, and that lifecycle of managing secrets is relatively complex. So, when you look at the number of boxes, it is a nine plus one box lifecycle, which is rather long, and it basically starts with the creation of an identity, and this is also where we need to be very careful, so we have something that has a secret.

So, there are different elements, so something is created, it could be ideally, it's, so to speak, directly inventorized, but in many cases, that is part of the challenge we are seeing, especially in the growing non-human identity management field, that this happens somewhere, and that there's a need for a discovery, so that we first need to get a grip on this entire scene. We need a classification, what is it?

Vaulting, so putting it into a safe place, sort of getting a grip, getting control about it, managing ownership, so everything, every identity and secret, they should have owners, responsible persons. So, there needs to be approaches that make the assignment of secrets and identities to owners. We have the area of posture management, so what is the security posture?

This is going really into effective risk mitigation, I would say, monitoring what is happening, rotation, so we all know that the attackers are getting faster and faster, so we need to develop the ability to react, to exchange secrets relatively fast, so we need to rotate them without breaking anything, and we also need to decommission stuff that isn't needed anymore, and on top of this, we need a secrets governance across everything.

When we look at this market from the perspective we took for this leadership compass, we observed that the majority of solutions in the market still has limited their coverage of identity types and or secrets types, and or the stages of the secrets management lifecycle. So, there are solutions that are very strong, for instance, in discovery, across many identity and secrets types.

There are solutions that are very strong for non-human identity or that are strong for human identities, as well as identities of devices and things, so it's really a bit of a mix, and it's an emerging market, not yet fully there, which we need to look at. So, this is very important to keep in mind, because there are effectual limitations you need to keep in mind when choosing your combination of tools, and on the other hand, I think it's very clear we need to get better, especially for the workload identity part. I think for the human identity part, we are a bit more mature.

We did a lot of things over the years, not everything perfect, but we did it, but when you look at the DevOps cycle from planning to creation, verification, packaging, releasing, configuring, monitoring, then we have a lot of places where different technologies come in, so sharing of non-human credentials in repositories, in Slack channels, everywhere.

We also have, when we look at DevOps, clearly software issues, malware-injected test systems, another identity problem, access to infrastructure, the lack of security for CICD management tools, lack of probably protected services, and from the technologies we look at, so the NHI management plays a role for non-human credentials. KEEM plays a role for the access to the infrastructure, to the services.

PAM, when it comes to the access of humans to CICD pipelines, et cetera, as well as IGA. Cybersecurity for malware aspects, software security for the pipelines. Generally speaking, cybersecurity, again, for the protection of services, as well as IGA when it comes to the access of the services. There are really many elements we need to secure, things that we need to bring together, these things, and this, again, is the reason why we looked at this enterprise secrets management perspective in a bit of a broader angle. Some of the key findings.

Workload identities are essential to enterprise secrets management, but enterprise secrets management is bigger than that. It spans human workload and device identities, and we looked at centralized enterprise-grade management, which we preferred our point solution. If we don't have it, we obviously have massive risks, so we need to do it. No other way. It's evolving well beyond traditionally KCM. It's another market. This was more the enterprise key certificate market to support new types of secrets, as well as the extensive NHI field.

The big challenge with NHI clearly is the vast number of what's called machine or non-human identities, which are often unmanaged or not well-managed, which are frequently a shorter lift, but also popping up pretty fast, so what we definitely need is automation. Automation is a key aspect here, and what we need to release is integrated lifecycle management, governance, and automation, and finding a way to get control about a walled spring, which is a tricky theme. I'll touch this later on when we look at some of the questions we have in scope.

Emerging trends of convergence between NHI and KCM, something I expect to happen more and more, and we see some of the players in the market also being quite good on the access side. We also expect that solutions are increasingly integrated well with the DevOps tools, because this is really where we need to offload security tasks from developers and come to a joint approach that works for the developers as well as for the security teams. When we look at the types of solutions here in enterprise secrets management, then basically, we have the ones who come from ...

The full solutions are, and what we covered in this report, are various combinations of these capabilities. Some are whatever human identity, delivering strong human identity and strong device or sinks, identity secrets management. Others are more on the workload side. Some are more the discovery side. Some excel more in the PKI and cryptographic key management side. It's usually that solutions can do a couple of these things, but not everything. As I've said, this is still an emerging market, especially when we look at it from an enterprise secrets perspective.

It's a market that is under constant change. That also means that several of the vendors are highly specialized vendors, which don't cover the full scope of enterprise secrets management, maybe not yet. That was also interesting to see that even since we finalized the report, since we released the report, some of the vendors came up and said, okay, we added right now quite some interesting workload identity capabilities here, or we added this here, or expanded in this field. We see this market moving very fast.

It's definitely important to have always a look at where's the market standing, not just rely on this, but using this maybe as something to figure out who to look at first, so vendors like Akeyless and others. From an overall leadership perspective, we see a couple of players that are in this leader areas like CyberArchitalis, BeyondTrust, Linea, SSH, and Akeyless. Vendors that are usually having quite some legacy that have a broad coverage of different types of secrets and quite a broad set of capabilities.

It's also interesting to see that some of the established PAM vendors are doing more and more in the non-human identity space, so moving in, but also clearly benefiting in an overall leadership perspective from the breadth of capabilities. When you look at a product leadership perspective, it's mostly the same set of vendors, but closer together.

I think what also is important, if you just take the height of the challenger segment, which we have displayed fully in this slide, and see that we only have a part of the leader segment, so the top segment here, it becomes very clear that the vendors are not, so to speak, at the upper end of the top end of the leader segment yet, which means there's still some way to go in capabilities, both in breadth and depth for every vendor. This really is still a market segment that is under evolution, which you should just keep in mind when making decisions.

On the other hand, we have a situation where we have quite a number of very interesting, very compelling offerings there, which should enable you to build your solution by starting with one vendor, which potentially delivers the fit you need for you, challenges your specific capability requirements, and potentially expanding with others. This is a bit the perspective here.

As I've said, soon to come, there's leadership focused on specifically the workload identity management or non-unit identity management aspects that is work in progress, where we then dig deeper into the part, segment of the market. As I've said, due to an unexpected issue, I'll do the second part basically myself, and merge it with the Q&A session. There are some things I'd like, or we'd like to dig deeper into, where I'll provide some perspectives. If you have any questions, then you already can enter your questions using the questions tool. Feel free to do so.

It always makes it more interesting, a webinar. I'm looking forward to receiving your questions here. While I've said this, given that right now mainly me talking, I'll go here on the big screen. Large screen, you will see sometimes some background information we will display. I think one of the interesting points to look at is why became enterprise secrets management, and especially the workload identity management, non-unit identity management, machine identity management, why did it become a topic now? It's not that many of the secrets are out for long.

They are not just popping up now, but they have been here for a very long time. Right now, it became way more popular. I think there are maybe three aspects coming together. The one is, we see an overall increase in the way we handle cybersecurity. One aspect clearly is, we are more conscious about security. We learned from effects that all these different types of secrets are under attack. We know we need to do more.

We have, I would say, on the non-workload side, new types of secrets that really change what we need to cover, what we need to manage, like FIDO2 tokens, like pass keys. On the other side, we have this...

Basically, we had the learning that there are a lot of the other things out there, like API tokens and all the other things that are workload related. I think a very important learning here is that these are way more volatile. They come from DevOps, from actual development. They go faster, they change faster, and they are way more. Together with the fact that we have more consciousness, more scale here, and volatility as well, and new types of secrets. When we look at enterprise secrets management, the enterprise secrets management really then...

This perspective started to get more and more popular because we don't want to have too many... Our enterprises don't want to have too many disparate solutions. You can't afford having something for that, and that, and that. This is not really helping security, not helping in governance. Too expensive, too hard to manage, too much risk of leaving gaps. From a machine identity, non-human identity perspective, I think the point is simple. We learned about a problem, and we saw, oh God, there are so many out of these. Then it's about figuring out new types of solutions.

This is, I think, the starting point why this really became popular now. I think when we are realistic, it's not entirely new. Some of the vendors are in the market for quite a while, for several years. I think the problem, consciousness, and awareness really came with the increase in risks. That is the one thing I'd like to look at.

And so, this is my perspective on this part. When you think about where to start with secrets management, for instance, the question, is it discovery?

Then, yeah, I think, again, that is an interesting, it's a good question. And it's not an easy question to respond.

So, I have a bit of two different answers to that. The one is, yes, it is discovery to understand which types secrets are around and where they come from. That would be the one way to do it.

So, really starting at discovery, because I learn about what is happening, where does it come from, et cetera. The other starting point would be stakeholder management. But stakeholder management clearly is simple when you did some level of discovery, because then you better know who are the stakeholders. Stakeholder management is, for me, a super important starting point, because especially when we go into the workload identity space, we are dealing, or we have security identity developers, software architects involved.

So, we have different parties, and I think the ones of you who are from enterprises, you have that experience of it's not necessarily so that developers and security people talk much with each other. So, we need to bring them on board, because every solution we create, every solution we find in that space must work for both.

So, it must enable developers to do their job and get rid of the burden of security, but not at a cost of losing functionality, losing speed. It must help them. It must be something that enables them to be more efficient and not care about security while delivering things in a secure manner. And security needs to get control about it.

So, I'll touch this in a minute with respect to another of the talking points we had prepared. And again, if you have questions, enter your questions now. It could also be comments so that we maybe have a bit of an interaction here. I know it's warm, at least over here in Europe, which doesn't make it easier.

So, that is one of the points, but I think that the stakeholder thing is really super important. Discovery is, overall, a good means to understand what is out there, with whom to talk, et cetera. And we got one question. I'll pick up in a minute.

So, back to the developer scene. And I think this is an interesting point, because it's not that we start, even when you look at the workload identity, we don't start on a ... Organizations have deployed, whatever, several instances of Azure core vaults, Azure key vaults, vaults in AWS, GCP, but also traditional PAM vaults. And the question is, how can we get a grip on these? Rip and replace, or integrate, or manage? I think that there's a simple part in the answer, which is most of that is nothing we can easily rip and replace.

We may consolidate some sort of instances of the same type of vault, but usually these vaults have a specific need, a specific role, and they are needed by the developers. So, as I said, a bit of convergence might be possible. But I think in the strategy we take, we even must consider that there might be new vaults coming.

So, we may need to enable someone to request also new instances of vaults. In our solutions, our approaches should help in sort of securely provisioning and managing the vaults and the secrets, so having them under control, but delivering what the it is at the end of the day, also not technically.

So, integration, yes, because we need to integrate them into the scope of our secrets management solutions. So, we need to have secrets management being connected to these. In that sense, it's an integration, but we also should accept there will be multiple instances of that. And by the way, it's that really new, when we look at identity management.

So, what is one of those things we do in identity management since basically since IAM exists? So, the older ones of us might remember meta directory services. And meta directory services were here to deal with multiple silos of identities, their attributes, and their secrets.

So, nothing new here. At the end of the day, it's just another facet of the problem. And to a bit, it's a facet where we have to solve these problems on, so to speak, on steroids at much bigger scale.

So, another talking point we had here before I come to the question, the one which is already here, another talking point is that secrets management comes with the involvement of security departments and developers. How to make them work together? I think it's something I already touched a bit. First is involved everyone.

So, it can't be something you do in security without involving developers and can't be the other way around. It must be a joint effort. This is the first point. I think without that, it will not work. And the other is understand what you do in enterprise secrets management as a service. A service in the sense of service has to do with serving. You serve the others. You provide something, a service to them, which is what they need. Really do it as a service that provides the walls, that provides the security capabilities, ensures the hardening, that helps.

That is, I would say, the really essential aspect to make this work. And think it from the other side. If you want to be successful, if you want to work with someone together, and that's a pretty simple and generic learning from years, put yourself into the shoes of the other side.

So, if you're security, we need to understand the developer side of things or the OT and IIOT side of things. And not come, so to speak, arrogantly with a good amount of self-esteem and say, okay, right now, security is the most important thing in the world, and we tell you what to do. This will not work. Think about what they need and how can you deliver it to them. And these conversations will be much simpler.

So, I'm through the talking points we had prepared. And I'd like to pick the one question which is here. If there are further questions, feel free to enter them. But this is, I think, a very interesting one. Question is, ideally, secrets would expire before attackers have a chance to exploit them. Since that's not the world we live in, how can we effectively protect secrets in the meantime?

So, this alliance was a thought I had a bit ago. And the thought basically came up when some of the players in the market reduced the lifetime of SSL TLS certificates. And I think we also have done this situation that for any type of secret that's used in attacks, there's a time needed for an attacker to gain it, to sell it, to exploit it.

So, build an automation that then really works. And that is a relatively, due to the level of automation many attackers are using, it can be a relatively short time span.

So, when I take this, we reduce that lifetime. Then at some time, the next step might be, oh, we reduce it again, and we reduce it again. There's a certain point probably where getting it, selling it, exploiting it still takes a couple of minutes, a few hours, a few days.

So, the more ephemeral a secret would be, the better it is that it can't be exploited. But that would require that we change, in many cases, standards, that we have a very efficient rotation approach, which also would trigger more workload in the network, which is, I think, not problematic in most areas, but might be a challenge in some areas.

So, if you go to the IIoT field, then it will become a challenge. But that is something to keep in mind.

And so, that is basically the situation we have. So, we should, I think, from a standards perspective, work on reducing the lifetime of every secret going, so to speak, close to ephemeral. That would be the best thing. In the meantime, it means we need to have approaches in place that help us spotting secrets very, very quickly.

So, the discovery is very important. Ideally, we have an environment in place where secrets are already created, a defined process, and a defined lifecycle, so that we have them under control from the very beginning. And then we can create the appropriate measures of vaulting, of managing access entitlements that the identities trapped to the secrets have. And we can also implement ITDR, so Identity Threat Detection Response, or User Behavior Analytics for these types of identities.

So, let's say user behavior, so this monitoring aspect, to my understanding, to my perspective, is really essential, so that we permanently can monitor if there's some weird behavior. And clearly, we should also move to an approach, and that is also something where we can support developers with the right tools, that we don't end up with sort of super user workload identities, which is a bit of a tendency that popped up when the team, the Cloud Infrastructure Entitlement Discussion, occurred the first time.

Then we were in a situation where we basically learned that by analyzing the entitlements of service accounts to cloud resources, that some of them are probably worse than a domain admin in your active directory, because they have so many entitlements. And so, we need to move to an approach where we can have sort of more granular identities with limited entitlements for specific use cases. And the easier we make it in handling this in a secure manner, the more willing, potentially, developers are.

And if there's something which is overloaded with entitlements, we need to either monitor it very closely, or to work with the developers on sort of splitting it a bit up. This was where the Cloud Infrastructure Entitlement Management thing came in.

So, these were the points I'd like to cover. As I've said, due to an unexpected issue, Audit wasn't able to attend today, which is a pity. But I think I know the reasons they are, that they are fully understandable.

So, with that, I'm screwed up. I don't see any further questions.

So, I say thank you to you. Oh, there's one question popping in. Let's wait just to thank you.

Oh, yes. Great question. The question here, like synthetic accounts, what types of solutions are being developed to manage AI agent identities?

So, I see those as personas. That's what the people, the person asking, of the top-level identity. If I have agents operating on my behalf, with a subset of my access, what is the best IGA approach? Okay. That would be a topic for a couple of additional webinars to fully answer it, because it's a complex question. And I think AI agents are a very interesting type of a non-human identity that is, in some areas, relatively close to a human identity.

So, it acts, behaves a bit like a human. It is sometimes linked, sometimes not, to humans. It may act on behalf of different humans.

And so, this raises quite a number of questions. So, I'm a bit reluctant whether it's an HEA thing, primarily.

So, I think the aspects, when we look at this, I tend to call this entire theme AI identity, so for the intersection of AI and identity. So, in AI identity, I think the first thing is we need to understand on whose behalf an agent is acting. And having ways to control or to monitor whether the actions of the AI agent are within the allowed, so to speak, realm of what the agent is entitled to do.

So, we have, in that sense, a bit of a transition of entitlement. Another interesting aspect around that is also, for instance, learning.

So, what is an AI agent allowed to learn? An agent that is acting on behalf of different people.

So, not necessarily everything an agent does on behalf of me should be part of the learning for others. Other things might be very valuable to learn.

And so, I think the... And then we have also clearly a secret aspect.

So, how do we grant constrained access on my behalf to an AI agent? So, how do we, so to speak, delegate certain of my entitlements to this AI agent? And I have to admit, I think we're currently more in a situation where we can start defining the questions and the areas we need to solve and really come up with the solutions. At our European Identity Conference, and if you have a Copenhagen membership or if you attended the European Identity Conference this year in May, I also gave a talk about the identity.

That might be very worse to look at the video because I've really digged a bit deeper into this theme. Also, still more from a questions perspective than from a... This is the final solution to solve it.

So, we see, I think, a lot of players looking at currently more AI security in the sense of how can I, whatever, secure LLNs, et cetera. I think that the entire AI identity theme is still one where we have a bit of a green field for both established vendors and startups. Okay.

With that, I would say thank you to you. I would say thank you. I want to say thank you to Akeyless for supporting these webinars. You can easily get in touch with me. There's a QR code here as well. I'm easy to find on LinkedIn. Thank you for listening to this webinar and hope to have you soon back at one of our upcoming webinars.