Governing Non-Human Identities with Proven IGA Principles [Introductory]

What is really interesting, sometimes even the difference between human and non-human are not that obvious. If you think about it, you have your personal device and the device is authorized to do some actions on your behalf. So it's you doing them or the device. So is the device acting on you so it's still you or it's more the device itself, the non-human? But it's not important because at the end it's still an account and we have to manage it somehow.

But, just my point, it's not that easy to even differentiate what is still human and what's not because everything is so connected and automated these days. And it's even accentuated by zero-trust principles. Without that, we can just trust that the machine will communicate somehow and it's okay. But if we want to implement zero-trust, then we won't because there are so many security issues and problems these days. So we need to authenticate everything and make sure if the devices or services are communicating with each other, it's secured.

So we need identity or at least some credentials for each communication and that brings us to non-human identities. So the non-human identities are there. There's a lot of them. We have to embrace that and we need to learn how to manage and to govern them. And I will be talking more about it today. So why are non-human identities interesting and important? First of all, it's the number of them. You might not even realize, but current estimates are that you have 20 to 50 times more non-human identities than human ones. It's natural.

Just imagine you have several personal devices and each of them is probably authenticated to something. You have different apps running for it. And your whole IT infrastructure is using many service and technical accounts to do stuff in the background. So if you think about this, this number is not that surprising and my estimate is it will grow even more over time.

Also, non-human identities are often overlooked. So imagine some IT administrator creating a new service and he just needs to call an API of external service. So it's easy to create some API keys and just call it and be that way. But if this is happening and your IT guys are doing these things quite naturally, you have no control. You don't know how these identities are created, if they are managed properly, and if they are decommissioned, if they are not used. So even monitoring of the usage might be a problem.

So you might not even know how many of these identities you already have in your IT. These two things together, the number and you don't have the control of the life cycle, bring us to potential security issues. Because it creates a huge attack surface that potential attackers can use. So you have to handle it somehow. And the problem, which accentuates the thing with non-human identities, is that they are privileged by design. The non-human identities typically do system-wide things and they need system-wide accesses to do that.

Or even if you have some assistant acting on your behalf, it probably can access all your data. So again, privileged by design. It just makes the problem even worse. And thinking about it, non-human identities are harder to manage. So the problem is obviously the scale. There are so many of them. And you don't even know where to start. Because with human accounts, you always have the owner, the person that has some position and some task to do. With non-human identities, it's hard to do this inventory of them and to even find out who is responsible. And it might not even be a single person.

Maybe it's the whole team. And if the whole team is responsible, sometimes no one is responsible because it's in the team, right? But having a single person who knows what the identity should do might be difficult to track. So what are the types of non-human identities? I already named some of them just for completeness.

Obviously, it's typical service account or administration account. So admin account, root account on Linux devices. Or several specialized accounts like database administrator and so on. Many of these may be not used regularly. It's like your last resort. If all admins lose their personal access, you have this backup account. So it exists there. There are accounts for devices. It might be a printer, it might be your personal device. You can imagine a sheer amount of them. If you have IoT, this is a lot of devices with these accounts. So this is part of it as well.

Accounts for your application, either again personal or something that's deployed on server. It can be microservices, if microservice architecture is popular. And all these services need to communicate with each other.

And again, you need accounts for that. Different type of automated agents, AI agents, some bot, web crawlers. All of these are non-human identities. And obviously in the IT. So integration code, CICD pipelines, workloads, and many others. So there are really a lot of them. What is the typical approach to management of non-human identities? If you look around even on this conference, most people start thinking of non-human identities from a low level. So obviously there is this huge potential attack surface on them. So we are thinking about security, how to make it more secure.

And the first thing that typically pops in mind are credentials management. Because these identities act autonomously, so the credentials have to be stored somewhere. So when you start a service, identity can just start calling APIs and do what it's supposed to do. And to make it secure, we need to manage the credentials, rotate them. And if you have people who are responsible for the identity and can have access, they might leave the organization and then you need to change your credentials and so on.

So this is the typical approach, how we handle credentials, rotating them, making them more secure. Then we are thinking about what the identity is supposed to do. So we are thinking about authorization, how to protect APIs and limit what the identities can do.

And again, by that, go over the attack surface. And then we can combine it with general monitoring. So try to discover all the non-human identities that we have, what they are capable to, have some risk assessment, taking it from this angle. And there are many existing specialized solutions for each of these individual problems. So if you look around on this conference, I guess you will see a lot of them. But we want to offer a different view on non-human identities. We are Evolvium, which is a European company, and we are developing our own IGA solution called Midpoint, which is open source.

And we were thinking, naturally, how this fits in our way to thinking, how non-human identities fits into identity governance and administration. So for that, we are thinking how we can put it in. And to be honest, the identity governance can be the essence of managing non-human identities. Because this is a completely different view, rather some high-level approach to non-human identities. And we want to answer the basic questions. Why each individual non-human identity exists? What is the purpose of this identity? And when we have that, we can think, who is responsible?

Either a single person or even a whole team, both are fine. But for each non-human identity, we should have a responsible person. We should be able to trace it.

And then, of course, we are thinking what the non-human identity is allowed to do. So what are the authorizations for it? And this is exactly what IGA is doing, naturally. So let's just apply it to non-human identities. So which governance principles are applicable to non-human identities? And the more I'm thinking about it, the more I'm discovering basically all of them. You just need to slightly modify them and apply what you already have for your users, for humans, to non-humans. So first of all, it's lifecycle.

We want to have strict control how non-human identities, each one of them, is created and how it is decommissioned. So we want to know who is creating it for what purpose, who is the owner, and then have a control of the lifecycle. And the non-human identity can have even, for humans, we have joiner, mover, leaver. And the same thing can be applied to non-humans, because joiner is how it's created, leaver, how it's decommissioned. And mover is also a natural thing. Let's imagine you have a backup solution and you are connecting a new system to your infrastructure which needs to be backed up.

So even this existing identity needs to get new access rights, right? So this is also part of the basically mover process in some way. Then obviously access request and app rules, because it's natural for humans. But if we apply it to non-human identity, we will get more control. Because then people are not just using it randomly just because they can, but we have a process. We have approvals, so someone is responsible, someone approves it. And when we have approvals, we can have access certification. In the same way, we are doing it for users to make sure that we have no stale accesses.

We can do it for non-humans in the same way. And it's even more important, because for humans, we have some at least generic sense of control. Because people are joining and leaving, and we can act on that. With non-humans, it's basically working automatically. So nobody is observing it directly. So having some process like access certification periodically, checking if the accesses are still valid. Or checking even the existence, if the existence of non-human identities still should be there. It's really important. And then we have this obvious benefit of IGA.

If we have all the information in a single place, with owners, with accesses, responsibilities, we have nice audit logs, so if we want to check something, or we want to do a security audit, we have all the data that we need already in place. We can have notification, just informing us what's happening.

Reporting, of course. And we can do even some advanced identity analytics, like automated risk assessment on non-human identities. In the same way we are doing it for humans, the same principle. Just check how many accesses, if they are used, and run some either risk assessment, or even use outlier detection to find out something that's standing out, and it's worth doing review.

So, what's our generic view on non-human identity governance? So, as I just explained, most of the IGA principle can be just straight applied to non-human identities. Most important thing is to do inventorization of the human identities. Just discover them, put them in your IGA solution, and start governing them. Ownership management is second thing that should immediately follow. I have the inventory, so part of the inventorization is to trace the owners. And that already is good foundation for any further management.

And we can use this natural thing in the IGA, where if I have owners, I can react on the changes in the owners. If owner of non-human identity is company, I can follow up on that, and have some process either to select new owner, decommission the identity, or at least report it as a potential risk and do something with that. How do we discover our non-human identities? For IDM and IGA softwares, we are typically using connectors, being directly connected to your sources and target systems.

So, if you have that, you can just simply discover them and start process automatically, discovering what's there, trying to map owners either automatically or manually. So, IGA will help you with that.

But, with some devices, IOTs, you probably don't have the connectors, or it will be too expensive to build. So, we need some combination of these automatic processes and manuals.

Then, you can think about short-lived identities. Like, if I have some jobs that are run, you probably don't want to store in the IGA the identity that lives for five minutes.

But still, this job submission system has something like a master identity that you can track, if ownership, if life cycles. And this short-lived, I just derived from that, that you have to monitor that in the IGA.

And, of course, IGA can still integrate with all the specialized tools, like for credentials management or extra security, API protection. This is still supported.

So, to conclude my talk, existing IGA principles are fully applicable to non-human identities. And most of you already have some IGA or at least IDM solution deployed within your organization.

So, for non-human identities, you can just start with that. Because you already have your pieces, and you just need to load your non-human identities in and start the government process. And this is minimal investment. You don't need to deploy extra components. You already have the IGA. You have processes for your human identities.

So, just put non-human identities there. And from that, you can either start implementing more IGA processes, like some life cycles, notification reporting, or you can start integrating with different tools, like for credentials management.

But, again, IGA gives you at least some basic information. This account should exist, and we should rotate credentials for that.

So, my recommendation is to start with your existing IGA, start with inventory, building it, find and store your owners, and take it from there. So, that concludes my talk. Most of the time, I'm available at the Evolvium booth in the upper level.

So, you can find me there. We can talk more. And I will be happy to take any questions now. Thank you for attention. Thank you so much. Do we have questions in the room?

Okay, well, I have a question for you. We talked about ownership.

So, what advice would you give to teams or to organizations on clarifying the ownership? It can get quite complicated, since the account might be a team account.

So, what's your best approach to that? Yeah, I would recommend to start identifying at least the team.

So, the team can be the owner, and it can be completely fine. But still, someone in the team should be responsible or aware.

So, probably the team leader should acknowledge this is the team responsibility, and if no one from the team can reply, at least the team owner should solve it somehow. So, this is a good start, and it can work. If you can name individuals, it's usually better, because individual is always better than shared responsibility, but team is also fine.

Yeah, great. Thank you so much.