All right, here we go. So what I would like to start out with is the initial situation that I found, and it was, it was quite interesting actually. So when I took over the role in group, we already had a privileged access management system, which more or less was introduced by me, basically by staff members and team leads like alpha, look, you know, head of this and look what we have here. And when I looked at that, I was a little bit surprised given that privileged access management systems are a significant investment for a company and running a program to actually utilize this well is quite an effort. So what we found is that the Pam system had really been implemented on initiative of the central it operations and security team. There hadn't really been an alignment with the business side in terms of, okay, what kind of risks do we want to mitigate?
Why do we need this? And it was a little bit also under the radar of it, top management throughout the various business units we had. So, so it was, I mean the guys of course tried to do something good. Like they understood, we run certain risks, we need a system like that. And then they went out and implemented it. But without top management alignment, it's very hard to really get the benefit. So what they managed to do is that in their own operations, they identified the privileged accounts. They connected them to the systems, but there wasn't really a global initiative to connect, to identify and connect privileged accounts across the company. Also, it was a bit unclear. What do we want to protect against? Is this mainly to protect against external attackers with the, with the intent of, of stealing intellectual property or doing Tage or introducing ransomware is this to counter internal fraud.
It was a little bit unclear why we're actually doing it. And given all of that, there was of course, a reluctance by the it management in the various business units to, to introduce Pam, of course, there's a certain cost involved. You would cross charge the cost for the system. And of there's also certain management effort involved. There were also concerns from workers representatives, Hey, are you are now logging our activity? Why are you doing this? Do you not trust us? So it was not totally well communicated. And, and also when we looked into cyber incidents, we saw that not all the privileged accounts were properly protected. So from that starting point in the following years, we actually in, went into a program to take the asset we already had and turn it into, into a, an asset with high cybersecurity value, which we didn't have in the initial state.
And I would like to cover a few topics that might be relevant for such a project so that you, when introducing Pam might hit it in the first attempt and not like we did in the second attempt, first of all, what is important to figure out is what is really the risks you want to mitigate? What are the risks? I mean, when we look through the main functionality of a privileged account management system, and basically there's three things that it can do, right? And, and I mean, we covered a lot of that already this morning. I mean, there is the, there is the password management functionality that protects the passwords for the privileged accounts, puts them into an encrypted vault, rotates them, for example, after every use. So that even an intercepted password cannot be U reused and enforces the policies, of course, using functionality like this mainly protects against the outside actors.
So when thinking about introducing a Pam, you need to link this functionality obviously to threats that you perceive with regards to outside actors, trying to, to attack your enterprise and, and perform malicious activity. Then the second bucket of functionality is the access management where you implement processes for actually requesting access to a privileged account where you can implement a four I principle so that every admin requesting account to requesting access to an account has to get a sign off from another employee with a respective authority. And of course you can also create the respective audit trails who has accessed what, in order to perform what obviously such functionality serves to prevent an unsupervised and unauthorized access by an inside actor and can help to pro protect against risks from single inside actors who might be interested to, to perform a malicious action or who accidentally might perform an action that should rather not be doing so here again, the question is, is this the risk we want to mitigate?
Third important bucket of functionality is the session management where you record the user session, where you create the session logs and where you can implement monitoring functionality to report unwanted user behavior, or even prevent the behavior so that the session wouldn't accept certain commands that you're not interested in, or that, that, that you would deny the, the, the user to run. He, again, it's more about misuse from a user who already is legitimized to use the account. And again, we need to ask ourselves the question is this the risk we want to protect against? And without having this link between the risks you perceive, the risks you want to mitigate and the functionality inside the Pam system, it becomes very hard to clarify your intent in the internal discussion and to justify the investment. So I think this is a very important element. And in the second round, we spent a lot of time to discuss what is it really you want to use the pump system for so that we have the maximum value in terms of risk mitigation.
Next very important element is to ask yourself, how is the pump system implemented in the technical infrastructure of the company? Are we actually set up so that we benefit from the Palm system, or are there certain things that we should rather be doing before implementing privileged account management to actually be able to get this benefit? Let me give you a few examples, starting from the top, when you implement a privileged account management system, you of course need to ask yourself, how do I administrate this actually, because suddenly when you introduce a privileged account management system for the first time you're dealing with, with a system with a, with a very high security requirement itself, because obviously if I can get access to the Pam system and admin administer it, I can give whatever rights to access a privileged account to whoever I want. So obviously I need to give the administration accounts for this system maximum level protection.
Like I would give for example, accounts with which I can administer an active directory domain or other such highly relevant zero systems. And only if I can answer this question, and I have insured that the administration of the pump system itself safe, it makes sense to actually use it because otherwise I do not introduce security. I introduce lower security than before. Next question is in the process, my users will look onto the privileged account management system to request access to the various privileged accounts. So I need to ensure that the identities of these users are actually secure so that I am sure if an administrator requests access, it is really this administrator and not someone who has stolen the credentials or such like otherwise. I would kind of invalidate the security. I try to introduce with the system. So here again, introducing privilege account management only makes sense. When I, when I have achieved an, a satisfactory security level for the identities of my it users that will later use the system.
Another important point is to think about, have I actually secured the systems for which I use the privileged accounts from my perspective, it doesn't make a lot of sense to introduce privileged account management for a software service that I have not protected in itself. So if the software service that I'm using or the, the, the disturber that I'm running has existing vulnerabilities is not properly updated. It's not properly patched, it's not properly configured. Then protecting the administrative accounts for that system is not very helpful because thinking about an outside actor, then the outside actor can circumvent my measures by attacking the vulnerable service and avoiding to try to go after the, after the credentials to use the system. And at least in my experience doing proper vulnerability management, doing proper patch management is of course, an effort, but resource wise, it's still a lower effort than properly configuring, maintaining and run privileged account management processes.
So clearly it's necessary to start with hardening and protecting the individual services. And then on top use the privileged account management and not forgetting about the basic vulnerability and patch management in the first place. Last point is you need to really think about how do I ensure also from a, from a technical perspective, that all the privileged accounts that I want to protect are actually detected and covered. Why am I mentioning that let's face it. Humans are humans in the middle of the project. I can remember I did a visit to an it operations center, one of our it operations centers. And then I sat down with the guys and they showed me everything. We very proud of their work. And then, then I looked at someone working on a system that I considered quite critical. And it was like, ah, what is it? Oh, yeah, it's software system XYZ.
And it was like, ah, you're administrating it. Yes, I am. And I went like, I have not seen you accessing the privileged account management system. Ah, that's very cumbersome. So I'm using a local account here so that I can do my work in a more efficient manner. Oops. And then we had a quite interesting discussion, obviously why this behavior, which is perfectly understandable from the perspective of the individual administrator is not at all helpful when trying to use a privileged account management system to come to a higher degree of security. So, and, and of course you write policies for that. You do trainings for people, which is all great, and most people get it, but you also have to have technical measures to be able to detect here is here are events and here are accounts that look as if they're circumventing the, you need that in order to, to, to complete your portfolio of technical security measures, besides all of these things, it's also important to deal with the stakeholders.
As I said, initially, we found a situation where the privileged account management system had been decided and bought on a fairly low level in the it organization. And from that up, it's very hard to come to a program that allows you to configure processes and to configure technology across the business so that you get the maximum benefit from the pump. So before going out and making the purchase, I think it's highly relevant to think about the key stakeholder groups and ensure that their approach is well aligned. Let me name a few things. Number one, since the, the Palm, if you holistically implemented is a sizeable investment of resources on end and of funds, you need to ensure that you have business leadership on board that starts of course, with very basic things. So, so of course, business leadership needs to have an understanding what are the cyber risks we are facing? And you need to have an agreement what the cyber risks are. So which normally leads to should lead to a situation where you have a cybersecurity strategy that is aligned between the business, the risk management and the it function. And the privileged account management obviously is a part of that when it comes to protecting against outside actors or inside, inside our threats.
Of course, when you ask for such an investment, it's helpful if business leaders have at least a basic understanding, what is it you're trying to do? So in our case, we spend quite some time to discuss with business leaders across the various units. Look, here's certain servers that you're facing EG theft of intellectual property. How, how can, how do you need to protect against this? How can a Pam system help? So that there's at least a basic understanding also on the business side, what do I get for my money? And then obviously you have to check where are you in implementing your programs? Is the Pam program the best value option, so to speak, or are there other things that you should be doing first? Like in my previous example, introducing proper vulnerability and test management also on the it leadership side, you need to ensure that that alignment is there.
Of course it leaders have a key understanding what privileged account management is. Yeah, really, to be honest, we found that we also had to do quite a bit of education until we had all senior it leaders in the company on board with regards to what we're trying to do with the privileged account management system. Also, it must be clear. We are talking about a holistic program. We need to look at processes. We need to look at how we run the systems. We need to look at it architecture. And not only at implementing a tool that protects a certain number of accounts with, with certain technical steps. So understanding this holistic thought is important. And then of course, alias need to be willing to invest, to invest money, and they need to invest money every year. Because once you implement such a system, such processes, there is a year on year cost, and also they need to be ready to help with the necessary change, to help people to understand where they must actually use the system.
On top of that, of course, there's also other stakeholders in co determined countries like here in Germany, of course you need to be clear, is this functionality aligned with workers, representatives and workers' councils because normally monitoring and blogging employee activity is something that falls under the co determination laws. So you need to get these guys on board. You need to make sure that in general, it is clear to it. Admins, why they are being asked to undergo more cumbersome process. And also you need to align with your security teams and your sock, how they will use the monitoring capability that the system brings because only the monitoring and logging data that you generate is being understood and used by the so team, you, you can actually benefit from the functionality. This is a short overview of what we encountered when trying to implement Pam. I could talk about this at length, but since my time for this meeting here is up. I would leave the floor to some questions. If you like.
