Workloads Shouldn’t Whisper: Ditching Secrets to Secure Non-Human Identities at Cloud Native Now 2024

Hello, everyone. My name is Asher Kune. I am the head of technical product marketing here at Ambit, and I'm happy to be joining the Cloud native now, uh, powered by Techstrong Learning with a webinar I'm calling Workloads Shouldn't Whisper.

So we're gonna be looking at, uh, what we can do with secrets. How to ditch secrets to secure non-human identities. Uh, I've been in the security space for over 20 years, although I have marketing in my title.

Uh, I kind of do a bunch of other stuff. I started off as a developer on Cisco firewalls, uh, and did a lot of remote access edge, uh, type of security. Uh, then I moved into other roles including Field CTO.

Uh, I enjoy seeing what's available out there in the market and how to make it better. Uh, and that's what we're gonna talk about today, right? So the first thing we wanna look at is, uh, non-human identities.

And there are many names, uh, that people call non-human identities. Some people think it's just service accounts, and it's really beyond that. So it's anything that has to do with how services talk to each other, how applications talk to each other, how machines talk.

Um, so it's not just, um, service accounts. Uh, some folks say, oh, non-human identity is, is not a person that's a service account, but it's a lot more. Uh, and there's a few things that are unique about, uh, NHI on human identity.

Uh, but one of the things that we know for sure that it's, this is a big problem. Credential theft is big, uh, when it comes to human users. Um, and it's also, uh, really big when it comes to non-human users.

And we'll take a look at why in a bit. But this is some statistics that I pulled from the Verizon Data Breach Investigation report from 2024. I've been tracking this thing for many, many years.

Um, and every year it's the same thing. It's the use of stolen credentials, things that are leaked. Uh, that's when you know, when you hear about a breach.

There's a lot of information that gets put out there, like social security numbers and addresses and names. But the thing that most often gets used to continue, uh, to dig deeper into an organization and steal other things, are these stolen credentials. So this problem has been around forever, uh, and it's been addressed in some ways when it comes to humans.

Uh, but we wanted to start addressing this for non-human and talk about what you should be considering when you're looking at how you protect, um, NHI service, accounts, machine identity, whatever you wanna call it. So, let's look at some of the advances that have been made, uh, on the human identity side. And I think this is important because, um, some of these need to also be addressed for workloads and APIs.

Uh, and some of these are being addressed. Some of these, um, there might be a workaround around how you actually try to address it. So in terms of non-human identities, we started off with, uh, in some cases, there was no credentials that need to be, uh, used.

So think of, you know, the late, late nineties or mid nineties when, uh, you would go into the office. Um, if you're that old, if you're as old as I am, you go into the office, you get on the wifi, uh, really, um, you could just log in. E credentials weren't, weren't actually needed.

Then the credential got stepped up to username and password, and then there was MFI multifactor authentication. This could be a pin, this could be a, uh, one-time password. It could be something physical like a UV key.

Um, but that helped. Now, one, your credentials were stolen. People still couldn't get in because there was more information that was needed.

Then they started using biometrics. This became even more popular with, like, uh, mobile devices where I can put in my fingerprint, or I can have it, uh, scan my face, uh, or retina scan, things like that. So biometrics are being used.

Uh, but again, this is your password plus something else that you have. Uh, and then there was posture assessments. So is it the right device?

Is my device healthy? Am I running my corporate software like antivirus, and am I doing, uh, disc encryption? So there was a lot of other checks and balances that happened before access was given.

Geolocation is another one where if I know all my employees are in a certain geography, I'm not gonna, uh, allow users to come in from other places. This could be using IP location, um, which can be kind of faked, or it could be using GPS from a mobile device. Then there was also SSO single sign-on, uh, which means I log in once, and then that authentication, uh, gets used over and over again to, uh, give me authorization to use other software.

And then UEBA, so user and entity behavioral analytics. Um, if I am logging in Monday through Friday, 8:00 AM to 6:00 PM that's when I do my work. And then all of a sudden there's a connection on Saturday night at 2:00 AM that might not be me.

So we might want to step down access or ask for one other step of authorization. So all of these advances have been made over the last five to 10 years, maybe a little bit more, uh, in terms of human identities. But what we found, especially talking to, um, folks that are really looking into walking down their networks, uh, with, with distributed applications, is some of these things weren't created for non-human identities.

So let's look at how non-human identities are unique, and then we'll look at possible solutions, uh, to solving this. So one of the things, uh, that is clear and the numbers are, are a little, uh, hard to find exact numbers, but one of the things that that's clear is the volume of non-human identity, uh, authentication and authorizations. And even the communication is a lot more than what humans are.

I've seen statistics that say it's a 10 to one ratio. I've seen it all the way up to 45 to one or a thousand to one. If you're just looking at connectivity, uh, how often applications are trying to talk to each other and how often they're trying to authenticate.

So the volume is really high. Uh, the other piece of it is the non-human identity is actually used a lot. I mean, think of distributed applications.

Think of anything that's automated. All of that stuff is trying to talk to each other. You might have a distributed application where you're, you know, pulling in some, uh, weather information.

You're pulling in credit card information, you're making, uh, financial transactions. There's a lot of communication that's happening behind the scenes. Uh, and even the most si even the simplest application, uh, is probably writing data somewhere.

So you're accessing a database. So these non-human identities are really used in a lot of places. A lot of times, if you're just using a simple API key, these are very long lived credentials.

Um, I've seen, uh, guidance that says, rotate your credentials every quarter, so every three months. So if these credentials get stolen, they're being used for many, many days, uh, before somebody's rotating them. And, uh, hopefully stopping that, uh, access and attack from happening.

Uh, also these cred, the, these credentials are not aware of context. And when I talk about, um, context, this could be like, uh, services don't know where the connection is coming in from. Uh, so back to the geolocation, uh, ip, uh, IP white listing and things like that.

There's a lot of context around the system that it's coming from, the source that it's coming from, that not only these systems, uh, aren't aware of, they actually don't care. In some cases, there isn't even a mechanism to go and assess posture or look at some of that stuff. Uh, in terms of authentication, uh, a lot of, a lot of, uh, SaaS software that, uh, enables, APIs are getting better at this, but there's still a lot of them that all you need is a simple API key, um, or all you need is your username and password.

And anyone in the organization at some point can create this and can pass authentication. What we're seeing is this is getting a little bit better. 0.

They're using three-legged off. Um, but there's still many organizations that, uh, don't allow that. And there's very, very few organizations, uh, that do MFA.

So when I started investigating MFA for APIs, I found that, uh, AWS does it and says, you know, like, there's a lot of write-ups about, you know, MFI for AWS on the API side, not on the admin side, it's purely on the API side. But then when you look at the details, it's only for a few services. So, you know, let's say there's a hundred to 200 services, I think there's MFA for less than a dozen services.

So even, even the MFA that's there is very limited. Um, and it, and it seems like the SaaS vendors, uh, are just taking kind of their sweet time to add things like three-legged off or, um, MFA or any of that stuff. So, so just keep in mind that there's limited authentication methods for non-human machine identities.

Uh, and then the other, uh, last thing here is, um, for the most part, when you look at API guides and things like that, there's always the insistence or the, the guidance that authentication should be in code. Um, so it's always like, eh, this is, this is required. Like, it's not gonna work.

Um, there's very few APIs that are kind of anonymous or just open. A lot of them require authentication. And what happens here is you'll see organizations that, um, they'll take the code that they've generated and they'll upload it to a public repository.

So now they have uploaded, uh, basically credentials. Uh, and two things can happen there. One, uh, what we're seeing is obviously, uh, breaches happen.

And then the other one, uh, which is kind of, um, another way to steal from an organization is, uh, you start using those credentials not to attack the company, but to get free service. And we started seeing this really around like LLMs, LLMs, most of them you pay per API call. So if I can keep, take your API key and I can run a hundred calls a day, that's, you know, each one's a few cents, but I'm stealing from the organization.

I'm not breaching the organization, uh, in the sense where I'm stealing data. I'm just stealing resources. Okay, so now we're gonna look at how, uh, folks are handling this stuff today.

And really, we're gonna talk about a journey in a minute. But one of the things that we found, um, talking to large organizations, small organizations, is they're kind of all over the place. And within an organization, you'll find that there are, you know, the, there's the main application that's handled well, and then there's a bunch of things in the DevOps space.

In the dev security ops space or individual, uh, developers are using things all over the place. So some of the things we found are good old fashioned post-It notes, um, somebody will create a API key or are using password, they'll write it down. It might be shared among a couple developers.

Um, and we just know that these things can get lost. They get misplaced, or somebody, when they leave an organization, they just take it, pop it in their pocket, and now, uh, they have credentials for an organization that they shouldn't have. The other one that's still fairly popular is spreadsheets or confluence pages.

Uh, and again, these things are, they're easily copied, uh, and they're hard to maintain. Like if somebody goes and changes a password or API key as part of rotation, but they don't go and update the spreadsheet, now you can't access, uh, the resource you're trying to access. The other one is, uh, I just generically will call it vaults, but these are your password or secrets managers.

Um, and these are also hard to maintain. And then they have another added issue where day one, a new developer starts and the developer is given a task to go use some API, and then now they gotta go track down and get access to the vault and figure out what the best practices are. And it's just kind of a hassle to, to maintain these vaults as well.

Um, but this is kind of the progression. And then there's also, uh, organizations, if they have a, what I just call an encapsulated application, it's all in one place. You're not going across cloud service provider.

So it might be an application that lives just in AWS, uh, many organizations are, are handling the NHI, uh, authorization and authentication problem by using Kubernetes Sealed Secrets. Uh, and again, this works, uh, fine if you are within one CSP, uh, but a lot of organizations we work with and talk to, uh, they're using some outside services and they're handling those a little bit differently, or they have, uh, disaster recovery across a different region or across a different CSP. Their main application is in AWS and they have some things backed up in Azure.

Now they're trying to figure out how do I, uh, let these two things communicate, uh, going beyond Kubernetes sealed secrets. So looking at the non-human identity journey, uh, every organization we talk to, they tell us that, Hey, at some point, uh, using any of these things that we just talked about, uh, is kind of high risk. It's high risk from the standpoint we mentioned that this thing, uh, can walk away.

Uh, and it's hard to maintain, but it's also high risk, uh, from the perspective of the developer experience. Uh, we, you know, we talk to a lot of developers. We talk to DevOps.

Um, there's a, there's a phenomenon that's happening now where the question is, do developers need to be security engineers? Um, and does a security engineer need to, uh, put in best practices for developers that is, uh, impeding on the developer experience? A developer says, Hey, I'm an expert in this one area I wanna focus on there.

Um, find me a solution that'll help me with all the other stuff I should be worried about without me having to do any work. Um, so that's where something like a workload identity and access management tool, uh, can come in. Uh, and when we look at how this thing gets implemented, uh, there are ways to implement this without affecting code.

Um, and, and that's really helpful for the developer experience. It's like, hide all the security and access bits away from the developer and let them focus on what they're truly good at. So looking at the NHI journey, one of the questions I wanted to ask you guys is, where are you in the journey and where would you like to be?

Uh, ideally everybody says, okay, I wanna be the most secure, have the best experience, and things like that. But I'd really love to hear from, uh, you and the audience. Um, and after, at the end, we'll kind of talk about how you can, uh, get ahold of me, but really think about where you are in the journey and where you'd like to be and think about this, uh, across all different phases of the organization.

So what is QA doing? Uh, what do you do when it comes to test or staging? What happens in production?

Uh, really think about all, all of it and, and, uh, let us know what's going on in terms of workload, IEM, uh, what I call kind of the next frontier, and the evolution of, you know, we've solved the user IAM problem. Uh, and now we're looking at what do we do for workloads? Uh, I just wanted to give you guys a few points of consideration.

Okay? The first one is discovery. Okay.

And, you know, we're, we're one of the vendors out there, but I kind of keep my, uh, eyes open in the view of all the other vendors. Uh, there's different approaches to what discovery means. Uh, some think that, you know, by discovery, we're looking at service accounts and roles and things like that.

Others are thinking that it's the service itself, right? So, on one hand, I look at service accounts, I look at API keys, and I see is there any overlap? Are there passwords that are used over and over again?

If there is, I should fix all that stuff, but I also should be looking at the services themselves, uh, what's actually being accessed. I can do this by looking at the code itself, um, and finding out what services that are outside my organization are being called. Um, and this, there's tools for this.

Sometimes this stuff gets cut caught in things like unit testing. Uh, but the other approach is also looking at things like DNS calls and traffic. Where is my application, uh, making a call to, and how can I categorize this stuff?

So, uh, visibility should be holistic, uh, and not just look at like, um, I'm looking at my identities and lemme see how I can ma make these identities better and clean them up. Uh, the other thing we wanna look at is, uh, the access policies. So in terms of access policies, I don't want to just send credentials to anyone.

Um, I want put in a policy that says, uh, validate the, uh, system that it's coming from, validate the state of the system. Um, look at the, you know, time of day and a bunch of other things before I send credentials. So it should be like really a access policy, very similar to the access policies, um, and acceptable use policies that we implement today for users.

Uh, we also want to try to integrate with existing stacks. This could be your security stack, this could be your network stack. Really, anything that you have implemented today, you should.

Uh, the workload I am should be able to go and find out, like, Hey, um, I, you know, I'm using, uh, let's say I'm using, uh, CrowdStrike to do posture assessments on my devices for user authentication. I should be doing the same thing for my workloads. Um, in any case where the service supports short-lived tokens, I should try to convert any long lived token, any set of user name and password credentials, anything that can be converted to short-lived tokens, uh, you should be doing that.

And if you're doing, um, no-code authentication, a lot of that stuff should be hidden away from developers anyway. So the developers shouldn't see this. Uh, we wanna try to minimize the need for, uh, password rotation, um, especially when the password rotation has to be done because someone's leaving.

Again, if you're hiding the credentials from developers, then they don't have any credentials that can walk away with them. And this could be achieved, uh, depending on the way, uh, your workload IM is implemented. So there's really three ways, uh, that these, this can be done.

And some vendors have, uh, one of these options and some have one or more. So the first one is the proxy. So putting a, a proxy, uh, and the proxy is doing the inspection.

These proxies usually sit right next to the application before, uh, it's exited or before, you know, it could be something like a Kubernetes pod that's sitting, um, next to your other Kubernetes pod. That's where your application lives. Um, and as the traffic is exiting, uh, they look at things like, um, they look at things like where the call is being made, uh, and then if matches policy, then it injects the, uh, credentials there.

Uh, the other option, uh, for organizations that don't want to con uh, install proxies, or maybe you can't do it anyway because you're using something serverless like AWS Lambda or you're going SaaS to SaaS. Then there's also the option of APIs, uh, for workload IM And what basically happens here is, uh, you make an API call to the workload IM and then you get back a short-lived token. And these short-lived tokens are really, uh, used in a matter of seconds.

Uh, so they expire right away. Uh, the possibility of these things leaking is, uh, minimal. Uh, but when you absolutely can't go the way of the proxy, uh, APIs is, is another way to approach this workload.

Im problem. And then, uh, you'll see organizations that are talking about agentless or agents. And a lot of times these agentless organizations, uh, basically are doing APIs.

Uh, but there are also agents that, uh, sit on the server itself. It's not like the proxy that sits kind of one level, uh, below it, but there are agents that sit on it very similar to having like a, um, A VPN client on your machine, uh, where those agents will intercept calls and then either inject credentials or go fetch credentials and then put 'em in there. So each one is, uh, useful, has its advantages and disadvantages.

Um, and, you know, depending on your needs, depending on how flexible you want, you'll wanna look for a workload. Im, uh, that, uh, supports, uh, more than one of those. Alright, uh, now let's just take a couple minutes to talk about zero trust.

'cause you know, we all kind of know zero trust in terms of users and machines and remote access and things like that. But what about U zero trust and non-human or machine identities? So for that, like I kind of broke it down into four high level categories, um, and I'm just gonna give you some examples of, of how the zero trust, uh, framework fits into, uh, non-human identities.

So in terms of workload identification and attestation, and this word attestation, uh, might be new to some folks, but, um, the workload identification, first I wanna know, is this a vm? Is this a server? Is this serverless?

'cause each one, um, I can get a lot of information about it to help identify it. Um, it could be things like, uh, a pod name for Kubernetes and I use very specific pod names and I validate that, hey, this, this is the only pod name that is my production pod. Uh, I'm gonna inject my production credentials for this thing only if I have my QA pod.

Or if I have a server and the name is something else, then I can't identify the system. I'm not gonna, uh, allow it to, uh, get any of the, of the credentials that it's trying to get. Uh, attestation is, how do I attest to the identity of this machine?

Um, it's, it's, uh, a cryptographic check, uh, based on a lot of other information. And this could be information that comes from the cloud service provider. This could be, um, something that comes from, uh, just other, other methods than the system itself.

And I go and identify the system and say, okay, you told me who you are now lemme go check with somebody else to see if the information you've actually given me, uh, is correct and true. Alright, the second thing is posture assessments. Okay?

The state and the health of the system. Um, again, this is not always, uh, an option, especially if you're going serverless, but I wanna be able to do a posture assessment. I wanna be able to make sure that anything that else that should be running on the system or any third party validation I can do, uh, of the state of the system.

Uh, I'm taking advantage of that. In terms of conditional access, I gave you a couple examples already, but these are kind of real world examples. Um, one is like geolocation.

So if I'm running my application out of AWS, uh, east, and I'm in the Ohio, uh, I'm in the Ohio Data Center, uh, I should be able to get a list of IP addresses, valid white listed IP addresses for that location. And, you know, to pass my geolocation check if I am running a brawn job or there is specific communication that's happening at a known day and time, I wanna make sure that I'm only allowing, uh, connectivity at that time. And then the last one, uh, which is one of the most important things is the least privileged access.

I wanna be granular as I can across the board. I want to be able to segment during the software development lifecycle. So again, development, qa, staging, production.

I wanna be able to, uh, be granular in terms of things like region, um, and then the employee type. Is this a contractor? Is it a, a employee?

So all of those things are possible, uh, when you're looking at, uh, implementing IAM for non-human identity. All right, with that, we're gonna wrap it up. I just wanna say thank you all, uh, again, uh, my name is Asher Canoon.

io. With that, again, I wanna say thank you and have a great, uh, rest of cloud native NOW conference. Thank you.