Privileged Access Management – Moving from Cost to Service Centre

So within the next 20 minutes we will more focus on not this so much future kind of stuff and fancy that. We have already talked about a lot on this conference on more about approach that is representing the kind of status quo I face in a day-to-day business. So privilege access management, moving from cost to service center, having the point of view towards how a service oriented approach actually can benefit the whole organization. We will also look a little bit more into detail when it comes to the terminology of identity and accounts and why it's important to differentiate those two terms.

What is identity security and what is account security on the other side. And then focus on how a shared account principle actually can support an overall zero trust approach. So let's start by the classical I am or Pam requirements.

We have, and this is more unique for the banking industry within Germany, but Dora coming up within the next, I don't know, few weeks, days, no, probably takes a bit longer. But the auditing will apply for more companies in the financial industry and all service providers related towards the industries. So in the banking industry we have a lot of regulatory audit coming up. So auditing is done in internal external. There are a lot of authorities and what they all do is kind of monitoring the compliance new very closely. And those requirements, they evolve over time as well.

So they get adjusted, change a bit, get a more focus on different areas and that's why there's always room for improvement. And in order to improve them compliance level, you need to allocate project budget. So this is mostly the start of initiation pro project, executing IT security measures within the area of identity and access management and previous access management.

And by executing achieving the project goals here, you can actually then leverage your risk mitigation, gain a sort of non-financial risk reduction and with that achieving yeah acute liabilities with use to those risk identified within this compliance level. And then closing the loop again, you get an positive impact by executing those projects on the compliance level, leveraging up and you not only achieve those requirements, you also can get an IT security. This is more mature which has more resilient.

And by using new technologies and innovations within those projects, you can also leverage up on process efficiency And having these three bubbles in mind, this is what I call are these three main drivers or stakeholders for what we call a privileged access security service. So we are just not implementing a PAM tool for instance. We have a holistic approach showing we have stakeholders in place, they are service consumption units and we need to consider their requirements as well. So we have the regulatory point of view, they want to have traceability, transparency, temper proof audit files.

They want to know how to report easily to report. They want to show if the compliance department gets in demand from an external authority, they press a button, get the report and are fine. Whereas IT security is more related towards how privileged access management, how identity access management can integrate with their eco cosmos. So central passport management session, isolation session management in terms of how we can prevent privileged escalation, how micro segmentation can be integrated within a privileged access security service, how zero trust can be supported and so on and so on.

So I have a lot of going on within the IT security and the process efficiency point of view is more towards related the end user, how usability can be used. Our velocity can be achieved on the extent of my automated processes can be support as a privileged access security service. And this is a kind of a customer intended view. We have end users, we have the information security and I'm put here C level as the yeah main actor in terms of risk management, risk reduction and risk exposure.

And C-level support is also very important to have to get the right attention within the company in order to actually execute what is called a privileged access security service. And by talking to those stakeholders you have to understand that they all have different demands, different business needs and have actually different expectation what a privileged access security service actually should benefit from them.

So whereas IT security wants to have different things as I compliance wants different things as the end user and it all comes to identity security and account security and not by talking to those stakeholders they have all have slightly different understanding what is actually an identity and what is an account. And by talking to Pam tool providers as far such as psychotic cyber or even Microsoft accounts and identity are often used interchangeable. But from my point of view, coming from a strong IM background identities and that accounts are two separate things.

They have to be considered in a different way and have to be secured differently. And that's why we have the security lifecycle, the identity security lifecycle where accounts are taking place right on the right hand side within the targets systems where the action actually takes place. Where the end user is working in an identity is more towards related and central identity hub. But we will get there in a minute.

So starting on the left hand side we have something that's called the identity state and this streamlines through all the end-to-end process and the identity state is kind of changing over time. We start with the identity state person, natural human being, you and me in this room here for instance can be an external employee. Internal employee can be some form of collaboration or partnership and they all have the demand of working this on the IT system of an organization. And by entering the IT systems they first need to get an identity which comes from the identity source.

And the identity source in classical terms is provided by an HR system, keeping track on the employee status, keeping track on the contracts, even payroll information, other personal attribute attributes are maintained there. And you eco even have different identity sources for different kind of stakeholders that you have in place in your company. And what they all have in common is they actually provide you a master U I D and identify a kind of fingerprint that then they can be used in all other downstream systems in order to have identify you and make sure accountability is secured.

Who is actually working within U IT system with what action? With the digital identity that is provided by the identity source, the actual identity security starts. So we have the identity lifecycle within the central identity hub presented often by a central IM or i I I solution. So lifecycle process such as join a mover lever process are taken there or emergency access where you can log out an employee immediately due to malicious activity for instance. This is it for more IT security related topic. Then you have a second layer which is kind of the governance core.

They're the management of accounts and entitlements has taken place creating a sort of desired state together with the first layer and desired state is then actually executed by the provisioning. The third layer, the provisioning layer and the provisioning layer then talks to the target systems. And this is where we actually change the state again and actually talk about accounts and account security within the target systems. So there's often one target system which is providing you a primary account for login information, day-to-day routine.

When you log in within your client, you can have different direct target system connected to your central identity hub can be databases, can be operating system or applications and whatsoever. And this interface can be either manually or automated depending on how, how much legacy environment you have in your, in your organization. And there's one target system which is has kind of unique position they call themself identity providers.

So we have an active directory directory service and this, in this case it's an Azure active directory but can be aws, GCP or even Pam two providers such as cyber A, having this function being identity provider. But what does this mean identity provider? Is it the identity source? From my opinion, no. They are just using those information within their directory services, getting those attributes from the central identity hub and the identity source and they're providing a service for indirect target system to actually use mission such as authentication and authorization.

So the indirect target system has a trust on the identity provider. The identity provider gets this information from the center identity hub, the center identity hub relies on the information from the identity source and this is how we make sure accountability is achieved. And if you have a gap between those layers somewhere that you can't make sure, then you don't know actually who's, who's using an account here. And by doing this, this is very important from my point of view. The digital identity can be just one digital identity, just one idea.

And talking about sales or identity, this applies even more about coming through organization. But you have one digital identity with multiple accounts and multiple target systems that can be used and that need need to be secured. So we have to secure the identity within the digital identity state as well as the accounts within the accounts security in order to prevent malicious activity for instance. And looking at the accounts, I brought an example which has caused a shared account principle that is used to kind of support is your trust approach and a company.

So on the left hand side we see the integration before path. We have personal admin accounts and person one and two they're working within their privilege entitlements indicated with these keys here. And we have even a shared account where passport is shared amongst each other in terms of accountability, this is really bad.

So, so you do, you don't want to have shared accounts because you do not know who's actually using them. By providing shared accounts, you actually can kind of challenge the organization. Do you actually need all your privileged entitlement on your personal account? And the answer is often no you don't do not need all them all the time. So you can split up the shared accounts and craft chat accounts upon use cases.

So we have a use case born here and these two entitlements are used for instance for incident management and the blue key for instance is used for user provisioning or business administration or whatsoever. And you give the person via your tool access to that chat account and this, this, by doing this you achieve that. You have less privileged entitlements to an account which prevents p privilege escalation and so on.

And you, you can reduce risk by splitting up in those use cases. Another advantage is, is off and onboarding of people. So occasionally maybe person one comes to you and saying, ah, from time to time business administration use administration, I got a delegation I need, I need those rights. Then you can easily onboard him by just giving him access to that chat account. And this applies also for person three or four depending on the use case.

You can craft it as you want on the business needs on the requirement coming out from the business side, this means that your, your target system actually hasn't changed within the account structure and in the entitlement structure that if you have manual provisioning, for instance user provisioning in the target system, you can reduce the workload. You can even use that account set for blueprints rolling out automatically shared accounts when deploying for instance a new machine, a new operating system, what so whatsoever.

The third advantage is you can reduce actually the number of accounts in total. Cause if you have shares accounts they do not need to to work all the time at the same time within one target system, if you have a team of 10 people working as a user administrator, probably you need maybe five, four or three accounts for them in order to form perform their task.

So you can reduce the total amount of shared accounts, which means less risk, risk reduction, you control them via the privileged access management tool and you give them controlled access and have an easy on and off-boarding and actually how can you measure those, those things. We have came up with some, how you say KPIs with some ideas how actually maturity of a privileged access security service can be achieved. So in in the right in the middle is a number of privileged identities.

So how can we reduce privileged identities by reducing privileged accounts, by reducing the fit risk on their side. So the number should be gone as well. Then we have, which is very important, the number of logins with past managed accounts in general there should be now account bypass passing, a privileged access management solution. All accounts should be managed and should be exited by a PAM tool for instance. But bypassing the solution can have a valid use case for instance.

Or if you have emergency procedures that's valid, but the ZM guys or sock guys should very closely monitor who's actually logging in with what kind of network connection. Then in terms of IT security, you can measure the security incident related towards those accounts and how those accounts are used. And by doing this you have get an overall risk reduction process efficiency. Can we easily measured how many tickets actually you get was your privileged access security service and users are doing having problems with the new service?

So the amount of tickets should decrease if you have a mature IT security service and at this place, number of manual password we set can be reduced as well because of automated password management and as well number to click the, the target should be go down as well. So the usability kind of how user administrator for instance can reach the, the different targets within operating system. This isn't different applications or databases. So this can be measured as well.

And in terms of the compliance level severity and the extent of severity should be gone by mature and meeting those regulatory requirements, then you can measure the capital, capital commitment through those risk provisions. So the acute liability I mentioned at the beginning there should be reduced because of risk mitigation and reducing the non-financial risk part of site and toward the end, the extent of second line and third line marks with go on as well.

So in total you achieve a very mature and resilient IT security by meeting regulatory requirements and also providing this kind of end user view by process efficiency. So that's about it. Thank you for your attention and I'm happy to discuss anything towards related new, new fancy stuff of role based versus policy exit and how this can be integrated within account security. This is a very interesting point and especially how pipelines like infrastructure as a code and Kubernetes clusters can be integrated in the picture that I made today. So thanks. Thank you.

You, there's one thing in this presentation that you talking about shared accounts and it seems like you've kind of inverted the, the sort of cons wisdom that you should never have a shared account, right? So how are you satisfied that that's secure in what you showed on that slide? I mean before, before we had a, Yeah, this one Pemp tool solution shared accounts, we, we, we went through the company said shared accounts for forbidden are bad, bad, bad, do not do shared accounts.

But in order we kind of, yeah, make the process easier for on and off-boarding, which was a big point and we can use them as blueprints in order to roll them out. And this give us a big advantage in terms of process efficiency and velocity and we can monitor those chat accounts quite closely and they are not longer related towards a single identity, more or less they're related towards the security by this privileged access management tool. So each person is an individual identity, huh? Yes. Yeah. So four identities can share that account? Yes. Right. Okay.

So, and for instance, depending on the target system, if they can use this at the same time, but if you have for instance, directory accounts, so they, you can give them access to one single account, but if, if the target system do not allow similar sessions, you probably need to craft more than one chat account in order to make sure that more than one people can work at the same time. Any questions from the audience on that?

Okay, well thank you so much. Excellent presentation. Thank you. Thank you.