Welcome to the KuppingerCole Analysts chat. I'm your host. My name is Matthias Reinwarth. I'm analyst and advisor at KuppingerCole Analysts. My guest is, again, Martin Kuppinger. He is the principal analyst and one of the founders of KuppingerCole Analysts.
Hi, Martin. Hi, Matthias. Great to have you again. And we continue a conversation which many are leading today. But of course, we have the bigger picture as analysts. This is a bit arrogant, of course, but why not? So we're looking at NHI, although even people debate that term, and rightfully.
But we, for today, stick with it, non-human identities. And parts thereof are workload identities. And apart from the terms, there has been a development just recently, which makes the management of those workload identities, especially longer-lived workload identities, more easy for the developers, but less secure. What has happened? So the discussion basically was around the fact that AWS, Bedrock, now supports long-lived API keys to access generative AI models.
So until then, it was only short-lived, and then it shifted towards saying, okay, we also support long-lived API keys, which triggered some, let's say, critical reactions. And when you then follow that discussion, that's right on LinkedIn, I think the main argument raised was that this is easier to handle for developers, they don't want to care about this. That was basically the point why people said this was changed. And this is very much in contrast to other areas where whatever the lifetime of SSL-TLS certificates is increasingly reduced. So it's really an opposite evolution.
It is a very specific area of workload or non-human or machine identities. And I think one thing that I usually say, maybe in the third sentence, is usually workload identities are to be considered as privileged. They have elevated access, they do a lot of things while they're alive, and allowing for a longer lifetime, of course, increases the attack vector, the potential for those credentials that go with this identity to be compromised. So usually cybersecurity is not about making it easier for developers, but finding a balance between both. Let me bring in one point ahead.
In this case, we're talking specifically about AI-related use cases. So an area, I think we have talked in this podcast already about AI identity, I talk a lot about AI identity, we're talking about an area where we definitely are not, by far where we should be from an identity and security perspective. So I would say this is to make matters even worse.
Absolutely, and I think we talk about, when we talk about agentic AI, about AI identities, we're talking about things, we're talking about processes where we cannot predict how they behave because they learn, they evolve, they spawn new identities. And all of this is now allowed to continue the work within guardrails, but as you said, in preliminary versions of somehow guardrails. So this is not yet there where it should be. So I think there is room for improvement at that point.
And I think there are two aspects we should look at today, primarily, and you probably have more on your list you'd like to discuss with me. But the one aspect is, in general, what should be our strategy on short-lived slash ephemeral types of secrets in the broadest sense? The other is, what do we need to do to simplify the life of developers and increase the level of security? So maybe to start quickly with the latter, or just to add one sentence around it, this is again one of these convenience versus security things.
Talking about convenience versus security doesn't make, or balancing security with convenience doesn't make sense at all. Our goal always must be to increase, to improve both. Because if you balance it, that means security goes up, convenience goes down. If convenience goes up, security goes down. Doesn't make any sense. So our thinking also as security people always must be about, what can we do to get both?
Right, and if we take one step back and move back briefly to human identities, when we redesigned our identity fabric, and especially the reference architecture, we also added the terminology of time phases. So we say, okay, a session is not only the initiation of a session to understand, yes, this is Matthias, he has presented his MFA, he has been assigned with access, be it roles, be it policy-based access, but we look into in-session governance. So while Matthias is logged in as a person, the context could change, the device could change, the network could change.
So that could be a change in the security posture, it might lead to changing access, and even maybe to restriction or termination of the session. And that is something that has just made its way into many people's heads into our reference architecture. And at the same time, we're doing the opposite for long-lived workload identities, which really is at least counterintuitive. But maybe this is an issue we should deal with more intelligently.
Are there workload identities that we should think of being capable of having longer lifetimes for their identities, maybe even reacquire the same identity for that workload after termination and re-instantiation? I want to start my response a little bit different. What you talked about, and I think that's one way to tackle a challenge, is basically what you said is if we sort of monitor what's going on and provide signals to the authorization systems, then we can mitigate risks of long-lived sessions.
Basically to translate it, if we use ITDR, Identity Threat Detection Response, to deliver signals to authorization systems that then make decisions or trigger the authentication system for a step-up authentication, then we can work in sessions with longer-living sessions. The other point is clearly, I think for the other part of the question, we also should differentiate again, and I think we did this in a recent podcast or you did it in a recent blog post, where you looked at terminology for all of that. The identity, I believe, should be long-lived.
I think we need, for instance, to distinguish very clearly between a workload and an instance of it that is executed. The workload, again, is part of a service, of an application, which consists of various workloads. Then there are people, you're talking about this, there are secrets used. We have secrets, we have identities, we have entitlements, and I definitely can only recommend that everyone looks at the blog post you recently published, because I think this is part of the challenge.
The secret itself, in an ideal world, is very short-lived, because attackers are actively looking for these secrets, the API keys, et cetera. They have processes in place to gather them or steal them, to sell them, to purchase them, to build up an environment with a high degree of similarity, to execute their attacks in a highly automated manner. The time window we have goes down, and yes, we can take countermeasures. We should take countermeasures, even when they're already good, but we must not only rely on countermeasures.
While a secret should be very short-lived, an identity could be longer-lived, but we must enable developers to do that. Basically, the point I think about is, when we reduce the lifetime of TLS certificates, whatever down to 30 or 15 days, then the next step will be, oh, we go down to 10 or 5.
Ideally, we go down to a value that is lifetime that's so short for each of these things, that is so short that an attacker can't, or attackers can't do the entire process of gathering, doing the sales process, setting up the attack, running the attack. We're talking about going down probably to seconds, maybe minutes or so.
Very, very short-lived. In that sense, really close to ephemeral.
That is, I think, the way of thinking. There are consequences that protocols must change. Workloads or traffic in the network will be higher, et cetera.
Again, to reduce the traffic, we need to be smarter in the way we renew that. We need a continuous renewal and stuff like that, but I think this is something we should think about in security. That would solve that part of the problem. The other part of the problem, my thinking is that we need to figure out ways that make it simpler for developers. I think there are some really great examples of how things like that can work.
OPA, Open Policy Agent, is one of these examples for authorization, externalization of authorization out of applications. Gained rapid attraction in the developer market. Why? Because authorization always was a burden for developers, and instead of thinking about how to manage authorization, they removed it to, so to speak, one API call. That is way simpler.
Everything with secrets must be basically something where we remove the burden from the developers, so that they just have an environment where there's automated care for them, where at best, they have an API call, but when they need a fresh one, a new, the first time one, but everything else, the entire lifecycle should be automated. I think we need to move towards such an environment, because otherwise security always will be the afterthought. But just saying, okay, then work with longer-lived API keys, that can't be the solution.
The solution must be that we work with as short-lived as possible secrets, in the broadest sense, and handle them automatically with a minimized burden on the developers. Right, and I think the distinguishing between the actual identity and its instance and the associated credentials, I think that is the important part. Because from a developer's perspective, achieving persistency, that is a valid request to say, okay, I want to have this same instance, even in one day, it's time to have the same status in there.
Might be a good thing to have, although persistency can be achieved also differently. But the question is, how do they authenticate? How do they get their access towards other systems, and how do they get the information about how to re-instantiate that? And then there might be a need for having some service that helps in re-instantiating without having long-lived secrets. So there might be something needed that handles that. I believe we need to be much smarter, and we need to think from a developer's perspective. For developers.
So at the end of the day, you know, when I talk with vendors in the NHI management space, virtually every vendor and every briefing comes up with API keys ending up in Slack channels. And that's because they're long-lived. That's because they're long-lived, on one hand. And the other thing is, people need to think about API keys. But that's the other side of it. There should be something which helps people not to think about this, which removes that part which is security. And there are two things. You need to know which API you use.
You even need to have a bit of an understanding of an instance or session you're using. But secrets are secrets, and should be secrets. But then we need something that cares for that. Right. Because one argument usually is that we need to do that at scale because there are so many yes, but therefore we have automation, and so that should be doable. We need to have the identity or the instance account, although this is disputed as well whether we need an account in that NHI continuum. I think we do.
And Spiffy and Spire provide very good accounts for different instances of workloads within a cloud environment. That's what they're for. So assigning them the right credentials to that, short-lived, quickly, I think that is the way to move forward. And as you said, the more we can take out of the hands of the developers, because it's not their job to take care of that, that is an identity job, maybe not of the IAM team, maybe of another team, but we need to have governance on that. That would be a good starting point. And as a side note, I run two websites and I pay for HTTPS certificates.
And I just got the bill for these new Google-ish 30 days renewal process. And this is actually, in German, we say this is a license to print money because I pay a six time the amount of money for my SSL certificate than last year because the price has not changed. But there is no price involved for issuing my own new certificates other than I have to do it.
And also, honestly, the effort to reissue it five times, the 180 day period, compared to only once every 100 days, never is six times as much if you do it right, if you automate it right. So, but a good thing is that at the end of the day, there will be market pressure and some will say, okay, if I automate, it's not that much more expensive.
And yes, we need to think about how can we just lean and reduce costs. But the answer can't be ignoring the fact that everything that is long lived as a secret is a risk.
And I, you know, it's not that this is new, this is the thought, hey, since when do we have password change cycle? Right. And automation has appeared on the mainframe. Yes.
So, it's not new. And so, why do we repeat the same mistakes again and again? Right. Every PAM solution comes with automated key rotation once the secret has been extracted from the vault. This is a fundamental functionality and we should have that alongside.
Of course, I want to have my long running chatbot having memory of what it did yesterday for me. This is a valid requirement, but do I need to implement it really on an account basis or do I achieve persistency somewhere else? I think that is the question here. Yeah.
So, I think… And again, that would be, do I need to have a session living endlessly or is it about saying I can re-instantiate that session in a secure manner, which are two very different things. And as you said, do I get a persistency in another way? Exactly.
So, the question is how important is a vault in that context? I would hope not important, maybe not even existing. The more short-lived, the less vault. Exactly.
So, the idea of ephemeral identity can work with persistency. I think that there is no contradiction in there.
So, that should be doable. To put it the other way around, NHI, to use that term again, does not mean reinventing the wheel because there are patterns that we have seen before in human identities, in personalized identities and privileged accounts.
And again, we need to distinguish between the same terminology that we mentioned, entity, identity, account, credential, entitlements, though this is nothing new and that also applies to all these new shiny software workload identities. We just need to make it right at scale. And that is the new thing, to make it right at scale. And even finding those identities that have been managed by somebody without a proper process is something that we do when we clean up an ID.
So, this is something that has happened before. So, really detecting identities is not an unsolved problem, just we increased the scale. Any final thoughts before we close down here, Martin? I think the thought which passed my mind is that this wasn't the easiest-to-digest podcast.
But yeah, maybe still important. Because many people are running around, hands in the air and screaming AWS is doing it wrong. The question is, what is the outcome? What is the solution? What should be done better? And as you said, we need to take this responsibility out of the hands of those people who don't care. And if I wasn't a developer, this is not my core business to provide for cybersecurity. That's exactly the point. I think this is achievable. I'm absolutely convinced about it. I had these conversations before.
So, when we look at non-human identity management and getting a grip on different types of walls, it's not saying we only allow wall A and B, because there will be a couple of them. Not everything, but a list that is not super short. Because you have AWS, you have Google, you have Azure with all their own walls and so on. And then you need something which helps developers that when they need something, they get it, but deployed in a secure manner, hardened from the beginning, well-managed, well-governed. But that they don't need to ask and wait back for getting something.
It must be a very smooth process that enables them to work the way that is required by them. Sometimes just a wish, sometimes a requirement. Right. And one final thought. Don't think that you go undetected when you do it in that insecure manner. This is a business model. There are pre-trained AI systems available that you can just rent to find these credentials. This is a business model and then people are actively attacking you if you are not doing it properly. There is a good reason, even if it is not your core business, to be secure because you are under attack.
That is really something that... And it's so cheap because AIs can do searching for these accounts for API keys for whatever you try to protect. They are around and if it's longer lived, chances are higher that you get caught. As I always say for years, decades probably, once you are connected, you are under attack. Right. Exactly. And I don't mention the other saying, just because you're paranoid does not mean that they're not after you. Yes. They are tracking you. Exactly.
Thank you, Martin, for being my guest today. As you said, that was not the usual, or it's not usual, the slide fair. This was really something more to chew on, but nevertheless important. And we will follow up on that and hopefully we find technologies. And maybe as analysts, we see the vendors and technologies and standards around that help in mitigating that issue.
So again, thanks, Martin. Looking forward to having you soon again. Bye-bye. Bye-bye.
