Demystifying Non-Human Identities: A Foundational Guide to Workflow and Machine Identity Management [Intermediate]

Thank you. Yeah, good morning, everyone. Happy to have you here. So much audience for the next hour.

You know, today is conclave day, so the doors will be locked and you are kind of locked in for the next hour. I have the honor to start the NHI Management Workshop with Demystifying Non-Human Identities, a foundational guide to machine and identity management. So I think I've covered all different opinions within the analysts and the NHI vendor community on how to name it. It's a little bit challenging because I have 20 minutes. For a foundational talker, you roughly need probably one hour, but I'll try my best not to go much over the time. For those who don't know me, I'm Heiko.

I'm the CEO of Nexis, 20 years in the IAM industry, helping customers with Nexis in the area of authorization, governance, and governance risk and compliance, which has some relations to non-human identities as well, but you will see it later. I'm here the whole conference, so feel free also to visit me later on. Non-human identities have been in the press for a while. Probably not mentioned as non-human identities, but if you have a look at the data breaches that have occurred in the past, basically a lot of big names have been cached, and it's not about blaming someone.

It's just a question today it's them, and tomorrow it will be you. So basically, you have to think about how to take care about this.

And as you see, there's a kind of famous and good brands with good tech teams, and they have kind of breached, and not because of, let's say, a security bug in the implementation, but because non-human identities in kind of any format have been cached, figured out, stored somewhere, and so someone has had the key to the kingdom, and basically not breaking in, but unlocking the door, opening the door, and kind of prepping data, reading data, or changing data whatsoever.

So why it matters, and why are we talking about non-human identities today, on the one hand, and why is so much interest from the audience? So it's one of the number one identity threats nowadays, driven by the big change we have seen in IT the last decade, probably trend to cloud native, to go to the big platforms of the hyperscalers, the zero trust adaption, and basically all those have a need for NHI that have to be probably secured. Non-human identities outnumber the number of human identities.

You have been used to work within the past when it comes to identity management, when it comes to IGA or access management, by the factor of 25 to 50, so there are different numbers out there, but that's a kind of very good and a very broad range, and when you imagine you are a company with 50K employees or 100K employees, when you are a little bit larger, times 50, it's quite a huge number, and a quite a huge number of people have not been used to manage.

At the same time, you have, I assume at least, that most of you have very weak controls in place, so you have had huge efforts in the past to secure human identities, your workflows, your employees, your external partners, your contractors, freelancers, and even your customers with initiatives like IGA, joint and mover levers, SSO, multi-factor authentication, probably nowadays PASKs as well, but most likely, you haven't had those processes in place for non-human identities.

It was a topic of the IT, of various development teams, and everyone did it on their own, and with nice standards that really made the access management pretty nice, like OpenID Connect, you have another angle of where we have to think of securing non-human identities, because nowadays, every business user can kind of use them. We will dive deeper later on.

There has been a good study by the Cloud Security Alliance on non-human identities, and one key finding was that companies drive very fragmented approaches to lead, very fragmented approaches to secure non-human identities, and basically those lead to security incidents. So you have currently not the topic that you go all in, kick off an initiative for doing something. You have a bit there, you have a bit there, and so it's quite a mixed place, which makes it hard for having a proper security across the enterprise.

Diving a little bit deeper on the various types of non-human identities, if you have not been aware, I made a selection now of nine, so probably we can discuss whether these are complete, whether these are overlapping, but anyway, what you see here, it's completely different types. So when you think about the classic identity and access management, you have humans. So me and you, we look different, but basically we are the same. We behave the same when we are employees, we are in an HR system, we are on the payroll, we get a salary, so a lot of things are a common denominator between all of us.

It's different with non-human identities when you think about API keys, when you think about service accounts, when you think about certificates or SSH keys, which are kind of cryptographic tokens. When you think about OAuth apps, you integrate, and basically this is the scenario when you as a business user, so I assume there is quite a lot of vendor folks in, but also users when you connect your Outlook mailbox to services like Calendly to HubSpot or Salesforce, it's a kind of non-human identity interaction because something is done automatically without any human interactions.

And this makes the spread pretty broad and everyone is affected. And at this point, probably it's a good time to blame the industry for some things because industry still is teaching us bad behavior. So those of you who are using, for sure just for private reasons, a chat GPT from OpenAI, you can go into the settings and you can copy your API key and you can copy this API key into your text editor like Obsidian and do some integration on your desktop environment, but you can copy this key somewhere in the cloud service as well.

And if you don't take care about it, you can copy it somewhere else and someone can steal it and basically access your OpenAI chat GPT data. And it's really a shame that nowadays, industry still provides every end user who are not literate with IT security these possibilities to handle tokens and API keys and that an easy way without educating them about the consequences later on.

Last year, I spent a bit of time in doing research and enjoying a bit of free time off so somebody might know. And I tried to make a definition of energize. I think I've published it in a discussion with Lalit and it's a pretty long one, so I don't go deeper. So feel free to take a picture and the slides will be available later on in the Kupinger code system as well. So I tried to make a summary and a kind of a meta study what analysts are saying, what different vendors are saying and getting the common denominator out of it. At least it was a try.

Some others are using less words and they're just saying it's a programmatic access to a process or data where a human is not required to be involved. So when things are just done automatically. When you think now, how do non-human identities spread across the enterprise? I gave you some example with the OAuth integration thingy but basically you find at least three different patterns. Let me start with humans creating energize. So when humans are creating a kind of API key, an API token and spread it, number one. Humans are authorizing energize.

That's the kind of OAuth, OpenID Connect case where you kind of authorize an NHI to act on your behalf. So you delegate your responsibilities on all principle in IM anyway. And probably the most dangerous one is making those things in a kind of acting kind of autonomously. So NHIs creating energize. When you think about DevOps pipeline that create resources in AWS, that can be probably other deployment units that create additional resources and so on. And you can imagine it can end up in quite a mess if you don't clean up those things or if you don't manage them pretty well.

What's now a couple of the root causes where we should have a look on to manage them well. So basically, most likely you don't know your NHIs within the enterprise. You know some of them, but it won't be a complete overview. You have not assigned ownership. For human identities is clear. Normally everyone in an employee in an enterprise has a manager or should have.

If not, there is at least HR who's paying your salary. So a kind of responsibility, a responsible unit. And when you leave the company, most likely they stop paying you. And at the same moment in time, they kick you out of the IT systems in an ideal world. But I think community has solved these issues pretty much already. It's different with non-human identities as they are just created being there. And especially when non-human identities creating non-human identities, the owner is often unclear. So is it the developer Heiko who built a DevOps pipeline and submitted it into a repository?

Likely, but what does happen when I'm leaving the company? What does happen when I'm leaving the project team? What happens when I'm on vacation? So with human identities, you have normally escalation workflows when it comes to approvals and this kind of stuff. It's different with non-human identities. And last but not least, you often have no policies in place. So you have a clear understanding in the workforce landscape and also in the time landscape who is allowed to do what.

You have either RBAC, ABAC, you have policies in place, kind of something related to access management where you govern and where you give people and identities authorizations to do something in your systems. It's often not the case with non-human identities or it's done in a kind of informal way that some developers, that some people in the business departments give it, but it's not managed, it's not governed, which is kind of the root cause for this big risk exposure. It's now the hardest slide, so let me have a sip before then you have a little bit time to read it.

It's very hard to break in such a short session key capabilities, whatever key capabilities are, drill them down and sorting them correctly. There are different opinions at the analysts community within the non-human identity management group, but they have all great resources. So if you want to go deeper later on, check the non-human identity management group website, check the Kuping et al research, and you can dive deeper and you get a little bit more explanation and all that stuff.

A couple of things which is quite common between all approaches when it comes to non-human identity management is you have to have discovery and governance. So basically, as you don't know where your NHIs reside, you have to have some functionality to figure them out and identify them by scanning your hyperscalers and making them visible and adding them to a kind of risk management approach, be it which are exposed to more risk and which are not. And then it's the first step of kind of really govern them.

You can then working on adding ownership to those NHIs, which is another first step to get a little bit back of control. Very much combined is life cycle management and authorizations. So basically, non-human identities appear, they have a certain lifespan, and then they have to disappear. So kind of adapting what we know as a join-and-move-a-lever process there, whilst a join-and-move-a-lever process with human identities is most of the time longer. So within the probation period, we have normally a couple of days or weeks, months, or when it comes to employee tenures, even years or decades.

With non-human identities, it can be very short, speaking of minutes and hours or even less. So it gets a little bit more tricky as we have completed different dimensions that we have been used to in the industry.

However, it's important to have those processes to get finally rid of them. Some of you might have been sorted very well. So I was doing consultancy in the past, and I had 2010 already customers that managed service accounts as a part of non-human identities in their identity management system for humans.

Kind of assigning an owner, having a process to setting them up, not probably to provision them into the systems, but at least you have a paper, kind of paper-based process in an IT system to say, okay, this service account exists, Lalit is responsible for it, and basically can answer questions. And at a certain point in time, you have to do kind of recertifications that it's still needed. That's most likely not that case for every customer or for every enterprise, and especially not for every kind of NHI. You have to set up kind of threat detection and response.

You remember I shared the examples of the data breaches within the big companies in the past, and you can figure out this abnormal behavior, this deviation from the normal course quite easy when you have the right tools in place, because when you're used to have a token from an application talking to another application within the same AWS cloud room, within a European tenant, within your own ownership, it's clear when there is out of a sudden an access request coming from Russia, from China, that this might be somehow a smelly and bad behavior, and you can act and suppress the interaction.

And nowadays, the kind of machine learning capabilities are so great that you basically are really good in detecting those. So it's not preventing beforehand, so it's even most of the time better to keep everything sorted upfront, but if it's happened, you have the capabilities to detect it as well. Let me have a bit of a focus of NHI compliance, kind of aligning it to the standards where you have most likely to comply with, whether it's PCI DSS, whether it's an ISO 27.0.1, whether it's an SOC or a DORA instance.

You normally keep track of your risks, IT risks, and your compliance with IT risks in kind of GRC tools, where you document on how you intend to seek your applications, and how you intend to do IAM for various types of identities. And this is important for compliance and NHIs as well.

And this can be an enabler for you if you want to kick off a project, and basically when you have to acquire a budget, because at the end of the day, you can map the risks to a financial value, what it means for the enterprise, either because you have to pay a penalty for GDPR violations, or you have a risk for reputational damage, kind of various thing. If you have an Euro amount assigned to it, your conversations will be completely different as you say, okay, there is a new kit on the block, there is a very cool NHI software, I want to play around with it.

Most likely your management won't approve it, but if you have a good business case there, and when you make the risk transparent, via the CISO line, you have a good enabler for your project in the CIO line, and saying, okay, I can de-risk it, and that's a game changer for corporate security. For time reasons, I probably skip secret management that most of you might be aware. So getting started with NHI, I really like the format of assessments.

I have a long-lasting consultancy background, and what I've always seen is when it comes to, I have to do something, but for sure I don't want to spend half a million, or even more money on kicking off a project, acquiring a software, bringing consultants in and kicking off a project without having a clear idea. Therefore, a kind of small assessment, 50, 70, 80 days or so, are quite helpful for getting you sorted and preparing yourself for making you ready to kicking off those initiatives. So define scope and requirements. What do you really want to secure? What are your goals?

Who's responsible for the project? Mapping out your landscape processes and your inventory, so what you already know, and make a good review about it. Often we see in projects that people don't have a clue what they actually want. If you write it down before you have a good memo for internal discussions to scope or de-scope various items. Identify quick wins. It's always good to have a win. It's good for the motivation. It's good for management awareness as you have the ability to justify your project, and you can probably set up kind of basic hygiene measures to clean up.

The thing it's like, like with your kitchen, if you never clean up your kitchen, it's getting a dirty mess. If it's a dirty mess, start immediately and clean up the first things and then establish a process to have continuously a clean kitchen at home. And basically target, first of all, high-risk application or high-risk gaps to get rid of them. And last but not least, set up a roadmap and a project plan because it won't be a project that you have done in two months time. So line out what you want to do, line out what you have to secure.

And as I said, topics like ownership, authorizations are often unclear. Those things won't be solved by a tool. You have to have the business discussions upfront to get those things sorted. So let me summarize as time goes by. Act and act immediately.

Right now, it's always the right time to start. There are things you can do. You can clean up immediately. It's without spending budget. And if it's just cleaning a bit, it's better than cleaning nothing. Build your strategy based on an NHI assessment and a roadmap and have a clear focus on those high-risk areas to break them down into actionable pieces. If you want to discuss more, we have a booth out there. So feel free to meet me for further discussion. Go to the Non-Human Identity Management Group booth. That's the largest booth, the black one here over at the Nexus booth.

And we're hosting an exclusive dinner with Asterix on Thursday and the Amonas on Wednesday. That's the QR code for the dinner registration. It's nearly sold out. So I have to excuse myself that I can't host everyone here, but some of you might be sailing on the Berlin River. So that won't be a problem right now. Thank you very much. And we have zero seconds left for a discussion. Thank you. Thank you. Thank you.

Yeah, thank you very much, Heiko, for these insights and a problem that also like, yeah, is with me nearly my whole career. Maybe one or two questions I have. So I have one from the audience and one I have in mind. I always wanted to ask someone, so be prepared. First of all, are non-human identities the same as non-personalized identities?

If not, what are the differences? Oh, that's a question. So non-personalized identities, I don't know whether that's a kind of defined term. That reminds me of the discussion we had on the weekend with Philip Messerschmidt from Copernicus Recovery, when it comes to the different types of A, B, C, like RBAC, ABAC, those access control things, it's not defined. So if you think about non-personal identities, not non-personalized identities in the sense of a service account, yes, then it's the same.

If you have a different opinion or a different thought behind that, I'm happy to have a discussion later on to get a proper understanding what's your terminology for this term. Maybe another question that comes around always when talking about this end, like impacting the heart of your company, because when you are now working between the applications, there could be the moment you are killing something.

And now expect you are, or imagine you are introducing this project to a board member or someone, and with solving a particular risk, you're possessing another risk of killing all your applications and impacting the business. Maybe out of your head, what would you say would be like the top three arguments, but maybe the top argument for doing it? So life is risky, life is risky. So for sure, if you manage non-human identities too harsh, if you kind of enclave them or kick them out, you might violate your business.

But the same argument goes for decades now when it comes to recertification of employees. So when you're a department leader managing a department of financial analysts or so, and you have to have a continuous review process required by DORA and Barfin and so on. So you have to check regularly all your employees, are they allowed to access their resources they have in the IGA system? The best thing you can do as a manager is do nothing, because when they have been able to work yesterday, they will be able to work tomorrow.

And whether there's a risk for your company or not, most likely you won't be personally affected. Independent from that, everyone from us, and it's a common sense that you have to do it, so we are doing it. With the risk that I remove some authorizations, some roles from some of my team members, because I know that Susan is not responsible for this area, so I remove her permissions. If she likes, if I was wrong, or if she wants to access the systems, she won't be able to do it. But I think you have to wait with the risk versus the damage. And I think the answer is clear.

De-risk it, and probably you have damage every now and then, and then you have to have process in place to kind of roll those changes back immediately, and then all should be done. Perfect. Thank you very much a lot for these insights, and yeah, to tackle one of the biggest challenges we have in this area. Thank you very much. Thank you. Thank you.

Please, a round of applause.