Analyst Chat #42: Ephemeral Credentials

Welcome to the KuppingerCole Analyst Chat, I'm your host. My name is Matthias Reinwarth. I'm an analyst and advisor at KuppingerCole analyst. My guest today is Alexei Balaganski. He is lead analyst with KuppingerCole and he works out of Duisburg. Hi Alexei.
Hello Matthias. It's good to be on this podcast again.
Good to have you back. It's always a pleasure to have you. And the topics that we are talking about are really interesting and often very innovative. And we will see if this is true for today as well. Today, we want to talk about ephemeral certificates. More and more vendors are integrating so-called ephemeral certificates into their product as an alternative way to provide access to systems. What is the idea behind that? And what is the concept?
Well, I guess as always, we have to start with the definition, right? So ephemeral credential, what's it all about? It sounds fancy, but when you were literally translated from Greek, it means lusting for a day. So ephemeral credential is something which is not permanent, which is not stored for later reuse, which is only given you to fulfill a certain task. And then it just parishes. And next time you do different tasks, calls the same task. Again, you get a new credential and the idea behind that is definitely nothing. You technically speaking, your one-time password app on your mobile phone is a generator of ephemeral credentials and auth talking. Your phone gets to work with Twitter. For example, is also powered by ephemeral credentials and so on. I guess the whole concept, the whole idea of this thing and why it's becoming hot gain recently. It's how do you make all the credentials ephemeral?
Right? Understood. So as you've already mentioned, this, this nothing really new, but it's gaining more traction just right now. So I, as the practice lead, I am here at KuppingerCole. I have seen this recently showing up in several products in the privileged access management space, where they use these ephemeral credentials, ephemeral certificates for providing access to for example, SSH systems. What other benefits of these ephemeral credentials?
Well, the most obvious benefit of course, that they are worthless after they are used. So if someone steals your ephemeral password or whatever, other kinds of credential, like an SSH certificate, we won't be able to use it for hacking or impersonating you at a later time, because it's only, it's only valid for one particular purpose for specific, hopefully very short period of time.
So that doesn't mean that you are no longer providing permanent access to a system, but it's really this kind of just-in-time provisioning.
Exactly. And again, if you kind of step back and look at the bigger picture, this is a major trend in the whole area of identity management and cybersecurity nowadays, instead of making a coarse grained and permanent long term excess decision, like for example, giving you a permanent access to a system or a sober for a year to the next review, you are only given a short just-in-time access to a specific service or application or task. And as long as soon as you are done with a task, your excess expires, that's the whole idea. And there are many concurrent developments in different areas. Some probably touch areas as a strong authentication, others refer to continuous authentication and behavior monitoring solutions, which basically ensure that if you are no longer, you had someone impersonating you on your computer, then your access is also remote. That's also in a way a possible implementation of ephemeral credential.
But of course this term is more often used for specific use cases. As you mentioned earlier, the certificates, for example, if you were, we're talking about like the web browser certificate source for X dot five or nine certificates, which are used for web based access solutions are usually managed centrally. So if a certificate is stolen or is no longer usable, it can be revoked. And when we are talking about SSH certificates or a key switch, you are, you should to access a Linux server for example, or an embedded device. Those are not centrally managed. So those are a real security threat because if you have an outdated, weak, or a stolen recitation, the difficult, it's a perfect whole security hole for an attacker to enter your systems. So making those certificates ephemeral is a major security boost. So we really
Get a grip on those formerly decentralized and then copied somewhere else, managed certificates. So this is really something that needs to be protected. And I think there's this making them fade away approach is really a good one. So where else do these ephemeral credentials play a role? I think it's not only Pam, but that was my entry point, but there's much more right.
Or of course, I mean, Pam is an obvious pain point for many interventions nowadays because when you are dealing with legacy platforms, mainframes, embedded devices, IOT, okay. On that, not technically IOT, but like OT, those industrial devices, which have been, which haven't been pitched for 10 years. Now, those are real pain points because there is probably even no solution or still available to give you a new credential, those devices, right? The traditional approach would be some kind of a proxy. So you access a different system like a Bastyr on or a proxy server and not thorough will ensure that your access from that point to the actual device would be monitored and managed through a Pam solution. So basically that was the old school approach, if you will. So you have to deal with a massive sprawl of those legacy, outdated credentials by trying to account each of those and to keep them in a secure world and only give access to those, to a validated administrator that approach worked, but it's extremely inconvenient and extremely prone to oversight. Or if you overlook a certain system, or if you forget about an SSH key left or third-party contractors, laptop, you are in trouble. But if you can ensure that each of your controlled systems is only accepting authentication with ephemeral certificates, then you are automatically freeing yourself from all the burden. You don't have to worry about all certificates when they expire on their own. Ideally within minutes after they are. No
One use case I can think of is something that I just covered in a recent episode with, with John Tolbert, we were talking about the zero trust architecture by mist. And of course, zero trust relies on secure access on secure communicating within a potentially hostile environment. Does this make sense in a zero trust environment as well?
It depends on kind of the way you use the term, but on the most strategic level, of course, it makes all the sense in the world. Because when we are talking about zero trust, many people will usually only think about networking security or incorruption and stuff like that, but authenticating you as a person and your device before actually giving you access to a certain system, it's the most crucial part, right? And if your authentication can be faked or hijacked through those legacy and three credentials, then it kind of negates all the benefits of the zero trust architecture. So yes, could have strong authentication, sometimes powered by ephemeral credentials makes all the sense because they don't try.
Okay, great. So this is really the, the initial connection before. So the handshake between communicating partners to make sure that the overall channel that we are communicating through is protected in the first place. When we talk about securing access, of course we, again and again, talking about getting rid of the password. Is this something where this also can support? Is this a use case to, to replace one or the other usages of passwords can be just replaced by that? Well,
Again, it depends. So if we are talking about people with human users, probably not, there are more sensible fellowships for that, like biometrics, Fido keys, and so on, or those or multifactor authentication you might assess, unfortunately for non-human solutions like applications or Soros or legacy systems, they have to be authenticated as well. Biometric probably won't work, but this is exactly where ephemeral credentials will do wonder compared to old school static passwords, especially if you're talking about developers, writing their applications and then hard coding an API key, or even a password or a certificate directly into the code. This is one of the very popular, or rather, I would say very wide spread fret vectors for exploiting applications and linking the data to avoid it. There are multiple approaches, but again, no traditional pain solutions have offered certain algorithms for, for dealing with those as well. For example, your application could be trained to check out a password from a volt and then the procurement, and back in the end of the session, this works, this is proven, but replacing that passport is an ephemeral credential makes it more secure because even if your application quote, unquote forgets to do it properly, or if a third party men in the middle Hecker manages to steal that password and that credential it's worthless because it cannot be reused for later attack,
Right? So this application to application privilege management is something that can be extended in a more decentralized fashion and in a more, more agile fashion and a more secure fashion, actually, because as you've mentioned, the key is no longer valued. So that, that is really an interesting aspect. And that's that also changed the way administration can be done when it's done in the more decentralized manner?
Well, to be honest as an administrator, I would probably prefer not to think about managing any key to passwords at all. I just want to press the key, get access to a system, do my job after I am done with that. I want to move on right now. There are fewer extra security steps I have to do in that process. The batteries for me, for my employers and for my customers, which are built. And if a solution be to PEM solution or a cloud security solution, let's say for your AWS console or something else, if that solution can take this away from me, this burden of worrying about securing my credentials, what would be great, and the ephemeral credentials make it much easier for me because I don't have to even think about that. I can just throw
Them away. Right? And I think, especially of course, we have to get to the term dev ops here as well or sec dev ops. That is something that might help in these more agile, more constantly changing ways team work right now that might support you as well. So if you assign access, not on a manually maintained assignment of access rights to a single person, but mainly for example, on a group membership at run time. So that would be something where, which could be safe, is more agile. It meets, of course it needs to be well controlled, but that would really enable a much more agile, yet secure way of dealing with these types of access rights. Yeah.
Correct. In fact skin or some people still believe that Dave ops and dev ops is all about automating processes through absolutely. It will never work perfectly until you will. I think in about humans as well, developers, as people are important to a creative process of making a new application, it's any kind of scripting that automation, right? Maybe when the more important and the biggest challenge is to make security or put them with a neutral part of the routine when they are working on applications. And again, if there is a solution which will completely remove that responsibility and burden of thinking, well, how do I manage the keys? How do I manage this credential securely? And why should they even bother? I'm a developer, I'm not a security guy, but if someone can take away this responsibility from me as a developer, I will be happy and happy developer means happy customers. Great.
So maybe we close the session with one. I know it's a bit of a mean question, but if I ask you as an analyst, how would you look at the concept of ephemeral credentials or ephemeral certificates in general? Is this just an interesting addition to the various ways of providing access to systems? Or is it something more revolutionary?
Well, that's a really tricky question because it's a little bit of both on one hand, as I mentioned earlier, the idea is absolutely nothing new. This is it's, it's always been understood that this is the way an ideal, properly secure and kind of easily manageable authentication systems should work. Unfortunately, due to technical debt or legacy applications, technology limitations on, we were unable to implement them that way everywhere. So basically in an ideal world, every password, every certificate, every token Emery API key should be ephemeral. We are not there yet, but if runners are working to make their solutions more advanced, more consistent in the direction, they are basically cleaning the alone time mess. And this is how it's supposed to work in the future. So it's not a revolution, but it's definitely moving the industry in the right direction.
Right. So that also sums it up very well. So if the audience is interested in learning more about that topic, I would highly recommend the one of the earlier episodes together with John Tolbert about the zero trust aspect, because this is also very closely connected to that. There is a great zero trust blog post by John Tolbert on our website. And there is much more coming up right now. I know that, but it's not yet published about the topic zero trust. I would highly recommend the leadership compass about privileged access management solutions, because of course, this is also a topic that shows up there as well. At least there's a glimpse here and there in some products. Do you have anything else to recommend Alexa, where we have information available or where yeah. Where our audience could look?
Well, again, our, although kind of, if you just go to our website and search for the word ephemeral, you probably won't find many dimensions of it yet, but again, it's all about the terminology. Technically this idea, this concept is extremely relevant for many different fields of cyber security and identity management from API security tool, throng and multifactor authentication to pen, if you just mentioned and zero trust. So the concept is relevant for anything. We just have to forget about the narrow definition or, and stop thinking about certificates and stuff, thinking about ideas and approaches and not forget about involving the human and the internet, because after all, it's all about making them more secure,
Right? So the concept alone is not enough involving the right people and embedding these, these concepts well into an overall architecture. So to make sure that this is used there, where it makes sense. I think that is also an important aspect. And of course, creating architectures, creating cybersecurity architectures is something where we as keeping a Cola, happy to talk to anybody who's interested in there. So just get in touch, especially when you want to talk also to Christopher, our colleague with his yet very, very fresh and upcoming cybersecurity fabric. So then that's it for today. Thank you very much, Alex, for joining me today. Thank you. And looking forward to having you in an upcoming episode again. So for the time being thanks to the audience for listening, thanks to you, Alex, for being with me. And bye. Bye. Bye .