Jens Bertel Nykjær: Implementing PAM, How Did We Get Support and Buy-In From the Organisation?

Yeah, as I said, I'm, I am solution architect in, we have 28,000 employees and Denver is a leader in, within several areas of energy management, like cooling, heating, electrification, and hydraulics. I'm placed in a team that is in a cross-functional organization part where we have security as some of our colleagues and integration as some other ones, our team is responsible for Asia ad and on, and the systems that I just mentioned. Yep. That was sort of introduction.

Pam has it sort of turned out during some of the other speeches today that Pam is not a product that everyone in the organization is waiting for. It doesn't sell more products or does it, Pam is just as attractive as audits. So you have to prepare your sales information and prepare what and how you really need to be clear on the reasons for introducing Pam.

Is it only because your department needs it or is some requirements from security or a company have requirements to have a Pam solution or either specific departments who express the needs perhaps due to maintaining an old homeroom system, or it's not supported any longer what they have. Then you have to look into what we did at least look into.

If you have some arguments that could be external requirements for setting up up solution, like from, if you're in finance, pharmaceutical manufacturing area, or energy legal, or that could be some ISO requirements that you have to comply with, then business demands like internal standards that you have to comply with that could be workload on existing systems, leg of control, security, demands, demands, or even security breaches. That's probably one of the best selling points, but one of the more expensive ones.

So you should work for having it in place before indirect indirect demands could be that you have some customers of yours who demand you to be in control due to GDPR or regulations indirect or direct demands from audit and security that they expected to do life cycle of access to our accounts and passwords or different password policies that need to be imposed, reduce the direct access to passwords, audit, and approval flow of access. When you found this arguments really need to be clear on what you want to achieve. What is your argument for implementing Pam?

And then find some other departments who could be body in crime, like audit or security or compliance, or perhaps a server team, because they have a lot of passwords that need to manage and look for departments who have a lot of passwords. So you can get a critical mass of accounts into your system and prove that it really works. It can manage a lot of accounts and they hopefully become satisfied users that can be used to yeah. To sell your, your product.

To us, be clear on the goals you are aiming for, be clear on the ownership of the solution. That's very important. So then ensure a dialogue with security and audit before and under the implementation. It helps a lot.

For instance, if you have good contact to your audit department or security, and they realize that SAP, for instance, have a lot of accounts where they're not in control of the passwords, or they do not comply to the policies you have, then you have a chance to offer them a solution with your plan solution, get them on onboard both to help them and to get you some, get some more users into your system. If your company has some internal standards, you need to read and understand them because you will probably be challenged under them. At some states.

You'll also need a, a good support from your CIO, a CFO, depending on when the organization you are, because some admins will probably say, why fix what is working? We have our sticky notes, or we have our Excel seats. So why move them into a new system And then take your own real estate. Get in control of the most critical accounts. First enterprise admins, the main admin system admins, Facebook or Twitter. If you are doing a lot of public information through these systems, then ensure that you're in control of accounts. This is specially important.

If you are in a department where those accounts are used, we quite a few domain admins in our team. So we picked up those the first ones and then ensure that the access tool, your Pam solution is working out of the box. It's you have already set up to request an approval flow. So have the access to the different accounts have secured that the SSO and it's working. So there's not any sort of technical hindrance for, for using the P solution afterwards. Yeah. What has worked for us when you have the critical accounts in the P solution, you can start on strengthening the security around these.

For instance, passwords ensure that those who need to use a domain admin, for instance, they have to check it out. And then they have a password that is valued for say five minutes or something. And then the system will automatically rotate the passwords. In that sense, you, you you're really securing the, the misuse of it.

And, and doesn't matter if that person have a domain admin access, soon, as soon as you let go of that person, that password will for sure have been changed several times before work towards using APIs towards critical accounts in order to ensure that passwords are not stored in scripts and so on. When you have them on one, start cleaning up, look into if you really need that many permanent domain admin or some just using it once or twice a year, then they may have to request it and have an approval flow and have it approved when they need to use it. Non-human accounts. Yeah.

Get them out of domain admins, clean them up. Then when you're done with the most critical accounts, it's time to onboard systems. There are some for sure, some departments, it should be strange if you don't have departments who have Excel sheets or SharePoint tables to manage the passwords, heard of a governmental department who had their passwords in a safe, locked up during the night. So they had an envelope with the account name on, and the password was on a note inside those envelopes. So physically, and they thought this is very secure.

Over time, the passwords were rotated and there was not added a new note into the envelopes or the, they were edited into a different envelope than the one with. So, so password and account didn't match. So when they really need to use it, they were info. So start onboarding these accounts. How did we onboard accounts? We created templates, what you see in the blank part, sort of a folder structure, where you have different departments having their own folder and differentiate differentiated access.

So only if you're in that department and it's approved by your manager, you will get access to, to the client, for instance, and within client, we have three sub folders and import and managed then unmanaged. So if you are import a lot of new ones, you can just add them into the import and then you can sort them out with those that need to be managed, where you want to rotate them, where different policies are impaired. You can handle on managed. They're just there. Make sure that you have a, a proper access and request system in place. Yeah.

Then after you have imported these, you can set up policies on these passwords so you can accept them as they are, but new ones would have to comply with your company policies. You can set up notifications what we have done to some of these system owners saying that you still have X number of accounts that do not comply to the 10 for standards for passwords and complexities. I do not recommend that you forward these information to audit or security.

I think that should be something audit and security should ask the solution owners for otherwise will just be the bad showing that they are not in control. Then you'll not be a preferred partner to with. So I think you should keep things apart that you can inform the solution. The state and security are interested, can contact or to get that information. Yeah.

The, the, the benefits of centralizing is that you, you can ensure MFA access to the, to the Pam Porwal. You can secure user life cycle management, that if users are leaving there, do not have access to the password any longer you can monitor who has access, who have had access. And one thing that I think is, is very good here, or two things is that you can, all these passwords that a person have had access to when that person is either leaving by himself or he's kicked out of your company, then you can rotate all the passwords that he have actually had access to in the Pam solution.

So even if you want to, and, and if you don't want to, he'll not be able to access these systems any longer. And the centralizing of the ownership of putting Pam solution. There's also a great benefit, for instance, during mass labor off genes in departments, or COVID 19 flock, where you ensure that you still have a system, and it's just a matter of managing access to, to the client team model, the server team, then those who should still have access will have access.

You do not need to run around and log into different Excel sheets and figure out which one is valued for today or for next this year. And you're not sharing them on yeah, Porwal online where you can do guest invites. I think that's some very important things, least for us. So where are we now? I think we have made ourself an attractive player to get in control of these different passwords. And we are not forcing the solution owners to comply by day one, but we are informing them on, on the state of nation and, and leaving up to them and audit to agree on when that has to be in place.

When I wrote this, I had two requests. Now I had three requests from different departments who want to test out our Pam solution and, and onboard their accounts. The next step is that we are looking into creating system accounts, like service accounts, whatever in 80, all the non-human accounts directly in the Pam solution, that one create the password. And then we will share access to that person who requested the account to pick up and see the password in, in the P solution.

Instead of sending it around the mails, my recommendations be very clear on the company policies for passwords and set these in your Pam solution, make sure that they comply or are similar to those. In 80, we had set up some complexities in our P solution, which were more strict than those in 80. So when a password was created, it did not create in the Navy by another system.

It did, did not fit into our P solution. And they had to reset the password on these accounts because they were too strict. We required to capital letter to digits and so on where you can only set one, you can set, you want a capital and a digital, whatever in 80, you cannot set numbers. So something like that, get that in place. And then set goals, set some, some point in time where you want to have all the critical accounts like enterprise domain, et cetera, in your past, in your system, or when you want to have rotation of passwords, reporting, set some goals that you can, you can aim for.

And then not all systems are equal. Some are more critical than others. Some can handle more complex passwords and others. So be pragmatic, move step. Some systems will be faster and easy and some will take a year, perhaps before your billing control show off, do PR on the internet, town hall, whatever cellular Pam solution to potential users. If you have some heavy users that is not from your department, ask them to right, or, or do a, a little promotion thing on your internet to sell it. We have had anyway, great success by, by doing it this way.