The Gap in the Current Identity World for Non-Human Identities Which Act as Humans!

Thank you all. Welcome to our session. Yeah. I hope you enjoyed your break and you are ated now. Yeah.

And yeah, thank God they have enough coffee because there's two days. Yeah. More so. Yeah. And we want to talk in this session about the gap in the current identity world with non-human identities, which act as humans. And my name is Les, I'm m architect at Benz, and I work in the field of authentication. And with me, I have Eric Siper and I, I'm leading the digital identity capability at DXC.

And yes, because we are an enterprise, we also brought an agenda. Yeah. Because I learned now in, in the iCare you don't, you start direct into the talk and you don't have an agenda. But yeah. Bear with me. You have to go through with that with me. Yeah. So the agenda is we want to first talk about the history of non-human identities as, as we see it or as we, we have have it in in most enterprises. Then I want to talk about robot process automation. What is robot process automation and what are the challenges with robot process automation as we found it.

And then we want to talk about the core principles we Yeah. Applied and or thought about to, to close the gap regarding those. And afterwards a short QA. So regarding history of non-human identities in, in the early days, yeah. There were some applications and they had to interact with each other or they had multitaskers or they had SQL and such stuff. Yeah. And then yeah, technical accounts were created. Yeah. You probably know all of them. Yeah. te TE service, something like that. Yeah. They were created with non expiring passwords. Yeah. And it worked for beginning and then Yeah.

Some security guys came and said, Hmm, okay, that's maybe not that secure. Yeah. Let's think about, yeah. To implement some policies regarding the password rotation. Regarding password lengths and Yeah. Also something like lifecycle and a adoo where you can put the identities in where only specific admins can manage them and also about authorization. Yeah. They talk to each other over applications. Yeah. And you have to authorize them. Yeah.

And then we had something like SOAP where you also had identities which authenticated there, and then we got with or O of two, 2.0 client credential grant where an, yeah. An entity authenticate to the IDP and then authorizes to APIs there. And that's what most platforms now have as, as, as a standard you have a machine identity or specific identity like in in, in Google or AWS Enter, enter I idea, which also indicates to an IDP and can do specific task as a technical in a background process. Yeah. And also we as Mercedes Benz have that. Yeah.

We have that in in our zero trust as an own cornerstone. Yeah. And we have a dedicated team for that. And we also think about machine identities at our site. Yeah. But what about this? Yeah. So you see this. Yeah. Not that modern looking ui. Yeah. And most enterprises still have those. Yeah. And those applications where you have an UI somehow. Yeah. But it lacks on APIs or you have applications which are only human centric. Yeah. Where no APIs at all. Yeah. For example, a good example that our side is always this spicy plant. Yeah. The menu. If you go to the canteen Yeah.

And there is no API, the only API is there to put the food stuff in. Yeah. But you can't interact more with that. Yeah. And so those applications Yes. Somehow also has to put in, into some automation flows. Yeah. And for those robot process automation was invented. Yeah. Invented. Yeah. And what is robot process automation? It's some kind of software automate, which interacts with applications. Yeah.

They, they log in, they insert data, they retrieve data, they go into other applications and do simple stuff there. Yeah. A good example is, for example, you have a warehouse, for example, now Mercedes there where you, you have pistons Yeah. And where you check if it's below a special threshold and if it's below a special threshold Yeah. Then you go into another tool or you open an email program and you send an mail or a task to a supplier Yeah. To stock up the, the pile. Yeah. So you have enough pistons to go on with the production. Yeah. And we saw that on our side.

It's getting more and more. Yeah. The issue with that is, yeah. And on the right side you see a screenshot of power automate. Yeah. But it's the same with your I power for other RPA platforms. Yeah. That you have to enter passwords in there. Yeah. And they are stored there. And if you have enough of those robots Yeah. They accumulate a specific thick amount of authorization and Yeah.

So they, they sometimes are Yeah. More authorized than an an intern Yeah. Who's who also, you know, collect enough authorization when he's going through company. Yeah. And yeah. And that's what's a, a challenge for us. Yeah.

And, and, and we looked Yeah. In the outside world. Yeah. How is there standard for, for RPA with authentication? Yeah. Is there something like that? Yeah. And we didn't find that and Yeah.

And we, we looked what, what the challenges do we have with, with the RPA use case. Yeah. And we have several Yeah. We have web Yeah. That are not having APIs like I said. Yeah. Or they just are there for human interactions Yeah. Where a robot cannot do anything. Yeah. And we have no real identity there. Yeah. We have machine ident like said we platform have those machine identities. Yeah. But a special current, they they are connected to to a machine. Yeah.

And, and can retrieve token, but they cannot interact with the ui. So Yeah.

The, the RPA guys use everything. Other accounts Yeah. They use external accounts, they use internal accounts, they use technical accounts just to get the automation running. And the next case is, yeah. What about MFA if you have application protected with, with MFA. Yeah. And the machine is the bot is running. Yeah. And MFA. Yeah. MFA is not thought about. Yeah.

For, for RPA that's the same like with test automation. Yeah. And so probably that's the first contact you have with the RPA guys. Yeah. Could you please give us an exception for this user to not do MFA and Yeah, of course the answer is no, not at all. Yeah. Think about anything else but no, we cannot let you through with without MFA. Yeah.

And yeah, like yeah, said they can automate nearly everything. Yeah. And what they do is they, yeah, they automate MFA, so they have VMs with, with OTP generators installed there where they log to the, the VM open the, the OTP, get the OTP and answer that one into the authentication Yeah. Flow.

So, so they are authenticated and Yeah. Like that they are creative to automate things they shouldn't automate. Yeah. And also we thought, hmm, what will be with, with with ai. Yeah. So I think there was a session from Patrick Parker who said, yeah, if you have have an API and you have an ai, you have a tool. Yeah. I would like to add to that. Yeah. If you have an ai, if you have RPA and yeah.

A web ui, you also have a tool. Yeah.

So yeah, I think that that is a gap we have. Yeah.

And we, we need to think about Yeah. And we looked into the outside world. Yeah. Is there tool, is there some standard for that? Yeah. And we didn't find something and so we yeah. Defined some core principle for us to to to close the gap and yeah. This I taking over. Yeah. So thanks Bella.

It's just, just said we identified several core principles to close this gap. So what can you do to basically go against these challenges and close them? And we identified three main principles which I wanted to talk about today. And the first is create an dedicated identity type in your environment. Yeah. We talked about it. There are externals and others. And I have a short exercise if you want for you, when you are coming back next week from the Ike, go to your collaboration platform, your global address list and enter bot in there.

Look for accounts which have bots in their names and especially if you're from a larger organization, I'm pretty sure you will find some. Yeah. Maybe at the beginning, maybe at the end, maybe in dashes, maybe within brackets and what and so forth.

And yeah, you will probably find them. And when you then look into the identity types as said, you will probably also find all identity types and how should you control this, how should you manage them in the future? That's not really possible if you're not having a dedicated identity type. And that's the baseline for everything else. So that's one of the core principles start to have an RPA and entity in your environment offer this also and then work around this.

And with this we are leading directly to the second core principle, which is built your unique identity processes around these identities. Yeah. Because as we just talked about, they are neither machine identities, neither human identities. They're somewhere in the middle. Yeah. And you cannot apply your standard processes most properly. Just taking the example I mentioned to you, you probably find bots in your co collaboration platforms and often you can even chat with them, give it a try, send to them Hello.

They will probably not answer to you because that's not where they are intended to do. Yeah. They're doing some automation, but they used maybe an external account and you have some birthright roles configured on your external accounts. So you automatically provision collaboration accounts to them. That's why they're having it but not using it. So on the one hand you use licenses, which you pay your vendor for things you don't need. And on the other hand, you probably have more security risks. Yeah.

So these are some examples which you can really consider and think about if you're working with RPAs. Another example is when the IIGA space, we all love our HR integrations in IGA. So all of you we are working in IGA, you know about this. How about changing this for RPA as well and taking your core platforms like a blue Prism or UiPath or whatever you're using as your HR source. So connect to the system and as soon as in bot developer the uses or creates a new use case, you automatically create the identity in your environment.

And as soon as they stop working on this or they close this use case on their side, you're automatically disabled identity. So that you don't need to think about anymore about who's the owner. Is it still in use or not? You're really tired. Like we do it in HR to a source of truth in this case your RPA platforms. But more importantly, and just as ELA said is also your access management flows.

If you're having dedicated identity flow, you can basically go to your IDPs and define a u, a really good authentication flow for this specific identity and only this identity, which is then fitting your corporate requirement and also following or using the technologies you're having in your environment to fulfill the stuff that maybe MFA or what can you do with not MFA and stuff like this. And then you can build a dedicated authentication flow for this users and only this users alone and do not intervene with any other normal human interactions.

And another example which we wanted to talk about is palm use cases. Yeah. These robots, as Bill just said, they tend to get a lot of access rights. Yeah.

We say, we now say each use case has their own ex identity and they keep their short access rights. But when you then think about what is a bot, A bot never does something on its own. Yeah. It always does what the machine operator or the bot operator is telling them to do. So when you're then thinking about segregation of duty checks and what access rights these persons have or this bots, you should not do it against the bot, but rather against the bot owner who often holds the credentials and their access to all of this.

And then you do an accumulated SOD checks against these identities, that's far more reality in your environment than doing it against your bots. If you then are aware that maybe an owner has really high privileged bots, you can then put your account controls you're having on this human identity rather than maybe on the bots. And that will give you, again, more flexibility to understand your environment, govern it, govern it, and do all the necessary steps there.

And the last one, and this is maybe not necessarily one which is unique for RPA, but in this case maybe even more important we talked about is they automate everything. If you do something they don't like, they will find a workaround and automate it. That's their business. That's what they do every day. Eight hours. Yeah. So work with your community from day one. That's really something which we experience is the core principle. Sit with them together, ask them what are their pains. They will probably tell you, I don't want to use passwords, I don't want to have expiring password.

Please disable MFA and all these things because they just want to get to the system. The security is not necessarily their concern. Yeah.

So you, you tell, I say, okay, I understand this, but we have also requirements. You have corporate pro policies, we have this and this. So sit together, explain them your situation. And out of this you can come together and find a way. And the next recommendation we source start with really early prototypes. Yeah. Go with them together. Go under one of their machines or then take a machine and check with them what you think fits in your environment. Yeah. Or using your technologies, their technologies, and check if this is working.

And when you're then having the prototype, you can get the feedback and then go with sprints further and further to find a solution which fits your RPA fors, but also you in security. And with this, you can basically create an win-win situation for security, but also for your IRPA fors. And in our opinion, that's the only solution to solve it. Yeah. Otherwise you will not be successful to really properly controlling your RPA identities. And yeah.

With Mercedes after the first POC, when we did it like this, we got so much feedback and so many requests that we were not able to handle them at the beginning. So they needed to queue until they were able to use it as well. And I think that was a really good sign that it works what we are doing there. And with this, we're already coming to the summary because we have only four minutes left and want to keep some time for all questions. Yeah. Let's sum it up again with three main points, which I think are super important. The first thing is do not collect your RPAA comments.

I hope the last 15 minutes showed you why you should not neglect them. And when you hear about them, don't think I will do it tomorrow. Really consider them and think what you can do with them. They might expose a bigger security risk than you think right now because you might not even be aware of what is happening in your environment. Avoid quick solutions is the second step. Yeah. In the short term, you always need to have a quick solution. Yeah. You might have something wherein process is not working fair enough.

But for the mid and long term, you should not think about some exceptions because that will not help you. You will end up in some issues over the time. Maybe you will find a security finding or whatsoever. And the last one, as we emphasize it often today because we experienced it and I'm also with other clients, is build fit for purpose processes in this environment yet don't do something where, which is not working for them.

Again, they will automate it, they will find our workarounds. Yeah. And they are super creative with this. That's their job. Yeah. And with this, we have three minutes left, we want to wrap it up and are we open for questions? Yeah. So first of all, a big thank you to both of you guys and yet let's open up to the audience for questions. Does anybody have something they'd like to ask maybe while you're thinking about it? A question for you, what was the most surprising about running this POC with Mercedes?

What, what did you not expect to encounter? I think what, what they can automate. Yeah. So they can really automate everything if they had got hands on identity with the, with the authorization. Yeah. That's what what Eric also said. Yeah. Look at the RPA, what they are doing, what authorization they have. Yeah. And I think that that was most surprising. Yeah. What the technology does and with, I think with the combination of ai, I know it's a buzzword now. Yeah. But RPA with ai. Yeah. I think that will be, yeah. Crazy stuff that will come up.

Yeah, Absolutely. And from your perspective. Yeah. And you will probably not find just the big portals like your i plus Prism, which you might know about, but you will probably find someone in your organization who does this on its own with power automate or some own written stuff. So you will find this in your environment where you haven't ever even thought before that this exists there. So that was, I think another fine. You have the big players, this, you might be aware, but also probably many smaller ones sitting at their own PC and making their life easier with some automation. Yeah.

Yeah. Great. Thank you. A last call. Yes. Let me come to you.

Oh, I've lost you. Where are you there? Thank you. I'm just wondering, do you have any means to make sure that the purpose of an RPA account is not misused for, for different purposes? So when the team is automating bots, they think of what kind of access they need and that might come up in a request for them for something else which needs similar or the same permissions. And instead of requesting a, a separate RPA account, they just say, oh, we got one for that and we, let's use that.

So how, how do you ensure that they're not, the usages or the use cases are duplicated or they're separate use cases for for one RPA account? Or you say that that doesn't really matter. Thank you. In the end, you, you, you still have the, the standard mechanisms. They are user Yeah. You have an access review, something like that. Yeah.

They, they have a organization policy that they have only to use a bot for specific use case and something like that. Yeah. But that's also something if, if you have bots in your organization Yeah. You have to also implement some policies and talk with the guys. And that's one of the points Eric said. Yeah. I think one additional advantage now when you're following the core principles, they still need to request the access. Yeah. Through your IGA environments and now an application owner, which still probably needs to approve, this is now at least at where that is an RPA user saw in the past.

They might not have even this visibility and, but at the end it's up to the individual situation, what gets approved or not. Yeah. That's not full control at the end. Yes. Thank you for the questions and thank you very much for bringing your expertise to the stage. Thank you. Thank you. Thank you.